Install Q2 Cores

The next steps will install the q2-cores package, import a core into your code, and make an demographic call to prefill the Address Change form

Install The Q2 Cores Package

All of the available q2 packages can be found with the q2 upgrade command. For simplicity, the following command will target just the q2-cores package:

$ q2 upgrade -p cores

Pick the latest version and let the package install. Notice that the requirements.txt file was automatically updated.

Import A Core

This tutorial will focus on the CorePro core, but the same steps will apply to any of the cores in the q2-cores package. At the top of the extension.py file, add the following import line:

from q2_cores.CorePro.core import Core as CoreProCore

Note

This import line is stating: From the q2_cores package, CorePro core module, core file import the Core class and alias it as CoreProCore in the code.

Further down in the extension.py file, below the __init__ function, there is a section of commented out code that is a helper function for IDE’s autocomplete. It should look like this:

# # Uncomment this to allow the IDE to give you better hinting on a specific core (Symitar in this example)
# from q2_cores.Symitar.core import Core as SymitarCore
# @property
# def core(self) -> SymitarCore:

#     # noinspection PyTypeChecker
#     return super().core

For better ease of use, replace that section with the below code snippet:

@property
def core(self) -> CoreProCore:

    # noinspection PyTypeChecker
    return super().core

This will tell your IDE that self.core is an instance of the CorePro Core class, and to show code hints for that module.

Call For Demographics

Now that the core has been imported, lets make a core call to get the user’s address from the core. Replace the self.default method with the following code snippets.

async def default(self):
    """
    This is the default route, which will handle any POST requests submitted without
    a routing key.

    All methods of this request handler have access to the following properties:

    - self.form_fields - Python dictionary of any input fields from the
        HTML user interface calling this extension
    - self.online_user - Useful meta info of the user who initiated the call
    - self.account_list - Accounts that the online_user has access to view
    - self.request_name_elem - If the incoming request was xml, this will allow
        for interacting with it using 'dot notation' provided by lxml's
        objectify library. More info at http://lxml.de/objectify.html
        ex. self.request_name_elem.FormReq.Form.LanguageShortName
    """
    demographic_call = await self.core.build_demographic_info()
    demo_info = await demographic_call.execute()

    replacement_dict = {
        "address_1": demo_info.addresses[0].address_1,
        "address_2": demo_info.addresses[0].address_2,
        "city": demo_info.addresses[0].city,
        "state": demo_info.addresses[0].state,
        "zip_code": demo_info.addresses[0].zipcode,
    }
    template = self.get_template('index.html.jinja2',
                                 replacement_dict)

    html = self.get_tecton_form(
        "AddressChange",
        custom_template=template,
        # This argument tells the form where to route a form submission when the default submit button is clicked.
        # In this case, route to the submit method via its routing key "submit" as defined in self.router above.
        routing_key="submit",
        hide_submit_button=True
    )
    return html

Also replace the index.html.jinja2 file with the below snippets

<div class="q2-row">
    <q2-input
            class="q2-col"
            name="address_1"
            id="address_1"
            label="Address 1"
            oninput="validateInputEvent(event)"
            value="{{ address_1 }}"></q2-input>
    <q2-input
            class="q2-col"
            name="address_2"
            id="address_2"
            label="Address 2"
            optional
            oninput="validateInputEvent(event)"
            value="{{ address_2 }}"></q2-input>
</div>
<div class="q2-row">
    <q2-input
            class="q2-col"
            name="city"
            id="city"
            label="City"
            oninput="validateInputEvent(event)"
            value="{{ city }}"></q2-input>
    <q2-input
            class="q2-col"
            name="state"
            id="state"
            label="State"
            oninput="validateInputEvent(event)"
            value="{{ state }}"></q2-input>
    <q2-input
            class="q2-col"
            name="zip_code"
            id="zip_code"
            label="Zip Code"
            oninput="validateInputEvent(event)"
            value="{{ zip_code }}"></q2-input>
</div>
<div class="q2-row">
    <q2-btn id="my_submit" color="primary">Submit</q2-btn>
</div>
<script src="{{ this.base_assets_url }}/index.js"></script>

Now run the q2 run command and render the form in online.

Notice that the form fails to render, and there is an error in the terminal. The SDK is complaining that a core is being used, but it doesn’t match the name that is configured. A configuration needs to be added to the configuration/settings.py file. Please replace the line:

#CORE = 'Symitar'

with:

CORE = 'CorePro'

Running the q2 run command will again result in an error. Now that the SDK is aware of a core, it is looking for a configuration file that does not exist yet:

$ q2 generate_config CorePro_Core

A new file should appear in the configurations directory at the top level of the repo. This file auto populates with all the necessary configuration names needed to make a core call for a particular core. These configurations will vary from core to core. For the values specific to an FI’s core, contact the SDK team.

Note

While in DEBUG mode (such as in the sandbox environment or local dev), the configuration values are not necessary. This is because mock values are used for all calls in DEBUG mode. Connecting a core to the sandbox environment is not advised since the security is not as high as the Q2 Data Center environments.

Running q2 run should now work as expected, and the form inputs should now pre-populate with “core data”. Looking at the extension logs, the mocked information is presented as if the call was realtime. Adding the -l DEBUG flag to the run command will also show the raw bits being mocked in the logs.

Now that core data is populating on the form, the next set is to submit the address change back to the core. For this a core flow will need to be created.