Core Integration

Note

If you are looking to build a new coreflow, or desire a deeper understanding of how they work, check out our tutorial on Writing Custom Coreflows.

Overview

A core is a financial institution’s database of record, and interacting with it involves a different set of APIs and data shapes than those used to interact with a Q2 database. Our FIs use dozens of different cores, and each type has its own distinct methods, its own documentation, sometimes even its own query language! Many cores are decades old and have a lot of quirks and antiquated architecture. Getting what you need from a core can seem daunting, and even dangerous considering that real money is moving through it every second.

Our solution to the challenges presented by supporting all of these different technologies is the concept of the “Q2Core”. Each Q2Core inherits common functionality, such as standardized logging, error handling, and configuration management. The capabilities and data of the target core are exposed through “coreflows”, which are specialized Python functions that wrap core requests, designed to invoke a specific operation such as getting a user’s demographic information and return consumable data.

The Caliper SDK Team has built a library, q2-cores containing Q2Cores for many common core technologies, each with a roster of built-in coreflows. These provide a common interface by which SDK extensions can communicate with cores, while managing all the configurations, idiosyncrasies, and data patterns that differentiate one core from another. Some great benefits from using our q2-cores library are:

1. Coreflows designed, approved and tested by Q2 developers long accustomed to working with cores

2. Built-in response mocking. While you are building your code, the call methods will return accurate data shapes containing mock data, without the danger of interacting with a live production core. Once deployed into the Q2 Datacenter, your code will automatically target your actual, live core.

3. Clean interface that works with your extensions. No matter how complex the interaction with your core is, you can almost certainly accomplish it in just a few repeatable steps with minimal extension code.

4. 100% unit test coverage

To install, run the command q2 upgrade and choose q2-cores. This will download, install, and notate your choice in the requirements.txt file at the root of your repository.

Much like calls to HQ API, every core call will follow the same basic steps, regardless of the core operation. The basic structure is invoked in your extension like so:

mapper = await self.core.build_operation(param_one, param_two)
response = await mapper.execute()

And that’s it! build_operation will be a method included in the q2-cores library, and you simply need to supply the parameters. The first line builds all the query classes necessary to make the necessary core requests and queues them up to run. This object is called a Mapper.

Calling execute on the Mapper (line 2) executes the core requests, then parses them into a Python dictionary Model of a shape designated by the Q2Core. The Model will vary with the specific call, but all Q2Cores that implement a build_operation will return the same basic shape.

Configuring Your Core

Configuring the extensions contained in your repository to talk to a specific core is simple. In your settings file (configuration/settings.py by default), set the CORE variable to the name of your core. Options are listed at the bottom of this page:

# configuration/settings.py
CORE = 'Symitar'  # Now all calls will speak Symitar and expect Symitar responses

Sometimes, configuring a core in the settings.py file will prompt for additional REQUIRED_CONFIGURATIONS. This works the same way as in the online tutorial’s configuration section. You can provide these extra configurations with q2 generate_config CORENAME (Running q2 run will prompt you to do so if you forget).

Multitenant (Multi-Core) Extensions

The real power of the q2-cores library is revealed when the SAME extension code that communicates with a core can behave DIFFERENTLY depending on which core type it’s communicating with. Imagine you are building an AddressUpdate extension. If you know the core will always be Symitar, you are set with what we’ve learned so far. But if you want this AddressUpdate extension to be usable with multiple core types?

In that case, invoke the DYNAMIC_CORE_SELECTION attribute on your request handler. Set to False by default, if True, the choice of which core your extension is configured for is deferred until installation time, at which point the core type will be stored in the Q2 Database. This is useful under two scenarios:

• Building a multi-tenant extension to be deployed for multiple FIs

• Building a resilient extension that will not have to be updated during a core conversion or upgrade

Overriding The Functionality Of A Q2Core

All of the Q2Cores are composed in an object-oriented style, which means inheritance and overrides are the preferred way of altering logic. If you find the built-in functionality of a Q2Core doesn’t meet your needs, take a look at our tutorial on Writing Custom Coreflows.

Q2 Supported Cores

We provide support for a variety of cores within our system. Please note that the table below does not encompass all supported cores, but rather those included in the current q2-cores package. As you review the table, keep in mind that your core can may be categorized under a middleware. For instance, Fiserv DNA can be associated to either the CoreAPI or OSI middleware. If you are uncertain about which middleware to use, please submit a ticket on the developer portal, and we’ll assist you in determining the appropriate one for your core.

If your core isn’t listed in the table, there are two potential scenarios. Firstly, it’s possible that your core simply hasn’t been added to the q2-cores package yet, as Q2 supports a large number of cores. In this case, please reach out to us for further assistance. Secondly, if we confirm that Q2 does not support your core after reaching out, or if you need immediate functionality while we integrate the core into our package, you can utilze our base package to build the necessary functionality. This package is designed to follow the same structure that all of our cores adhere to and incorporates many of the base functionalities utilized by our supported cores. In fact, all of our cores inherit from this package.

Note

By default, all cores in this package will provide a build_demographic_info function to fetch demographic information from a given core. However, these can be expanded upon and the functionality can be inherited when creating custom coreflows as indicated in previous sections.

For core definitions, please visit our Q2 Fundamentals and Definitions guide.

Available Banking Cores and Middlewares

Vendor	Core Platform	Middleware	Q2 Core	Aliases
Corelation Inc	Keystone	Keybridge	Corelation	Corelation, KeyBridge, Keystone
EPL Inc	EPL	EPL	EPL	EPL CoreGatewayService, EplCore
FIS	Horizon	AllLink	FISHorizon	AllLink, Horizon core
FIS, Metavante	IBS	Connectware	Metavante	Financial Connect, Metavante Connect
FIS	IBS	Open API	FISIBSOpenAPI	Open API, Code Connect
FIS	Miser	Cohesion	MiserCohesion	MiserNet, Cohesion 3.x, Fidelity Aurum Miser
Fiserv	Cleartouch	Cleartouch (Connect)	FiservCleartouch	Connect, Cleartouch, FiservClearTouchConnect
Fiserv	Datasafe	Connect I.T.	Users	UsersConnect, Datasafe
Fiserv	DNA	CoreAPI	CoreAPI
Fiserv, Open Solutions	DNA	IRB, CMC	OSI	IRB, OSI 3.x
Fiserv	Precision	PCS	PCS	Precision Vision, PCS Banking
Fiserv	Premier	Communicator Advantage	FiservCommunicator Advantage	Communicator Advantage, Enterprise Service Framework, ESF
Fiserv	Premier	Communicator Open	FiservCommunicator OpenPremier	CommunicatorOpen
Fiserv	Premier, ITI	SOA	SOA	PremierSOA, FiservSOAPremier, Fiserv ITI Connect3 SOA
Fiserv	Signature	Communicator	FiservCommunicator Signature	CBS, Signature, FiservCommunicator
Fiserv	Spectrum	Pathways	Summit	Summit, Spectrum, Fiserv Summit Pathways
Fiserv	XP2	Apex	XP2	XP2, FocusXP
Harland Financial Solutions Inc	Phoenix	XM	Phoenix	Phoenix, PhoenixEFE
Harland Financial Solutions Inc	UltraData	Transaction Exchange	UltraData	UltraData Fusion
Jack Henry & Associates Inc (JHA)	Core Director	DataLink	JHACoreDirector	Core Director, DataLink
Jack Henry & Associates Inc (JHA)	Silverlake, CIF 20/20	JXChange	JXChange	Jack Henry Silverlake, CIF 20/20
Jack Henry & Associates Inc (JHA)	Symitar Mainframe	SymConnect	Symitar	SymConnect, Episys
Jack Henry & Associates Inc (JHA)	Symitar Mainframe	SymXchange	SymXchange	SymExchange
Q2	CorePro	CorePro	CorePro