Configuring Your Core

For a detailed walkthrough of how the Core framework works, please refer to the Custom Coreflows page.

Basic Configuration

Your configuration/settings.py file should have a placeholder for adding your core:

# CORE CONNECTIVITY
# Core calls are OFF by default. To enable, uncomment the 'CORE =' line below
# If DEBUG is set to True above, Core responses will be mocked
# If DEBUG is set to False above, Core calls will call AdapterPassThru from hq_api
# Replace the line below with a reference to a module that contains a Core instance
#     - This can either be a core that comes with the q2_cores package or one that you write yourself
#     - Example below show how to import the Symitar core

# CORE = 'Symitar'

To configure your set of extensions to use the Symitar core, you would simply uncomment that last line. If the imported core required extra configuration, your server would prompt you next time you ran q2 run:

$ q2 run
./configuration/Symitar_Core.py file missing. Try running `q2 generate_config Symitar_Core`

After this is set up, all calls to self.core in your extension will make Symitar style queries and expect Symitar style responses.

Any importable path will work in that variable, so if you build your own core called MyAwesomeCore, replace CORE = q2_core.Symitar with CORE = MyAwesomeCore

Dynamic Configuration

An advanced setup might require that your extension works with more than one core. This is supported through the use of the DYNAMIC_CORE_SELECTION static attribute in your extension:

class FooHandler(q2_sdk.core.web.Q2RequestHandler):
    ...

    DYNAMIC_CORE_SELECTION = True

This one simple change has a lot of side effects! For one, q2 install will ask a series of core-related questions:

This extension allows for dynamic core selection. Which one should this installation use?

    1)  None
    2)  Metavante
    3)  MiserCohesion
    4)  OSI
    5)  Symitar
    6)  UltraData
    7)  Users

Please make a selection and press Return: 5
Symitar

Symitar. Good deal. That requires additional configuration to run properly. Leave blank to install with default (value in [])
CARD_PREFIX: [1]
DEVICE_TYPE: [Q2]
UNIT_NUMBER: [1]

This moves the configuration portion from build time to install time. The configurations will be stored not in your codebase, but rather in the database.

Calls to self.core will still work the same way, though their information will be coming from the database configuration. This means the same extension can be deployed in a multitenant fashion. It also means changes to the core configuration can be updated without rebuilding the container.