Zones

Zones are a database feature for FIs that belong to parent or holding companies, allowing shared configurations, faster upgrade times, and several auxiliary benefits. Zones can have separate adapters, different core configurations, different SDK extensions, etc.

Behind the scenes, this is accomplished by adding zone information to Groups in the Q2_GroupToZone table, which can then be referenced on all HQ operations that reference that group, directly or indirectly.

For the most part, this is done completely transiently, and from an SDK perspective, HQ calls will return the same information with no additional work. For instance, the GetUserAccountList HQ API call takes an online_user_name as input. This belongs to a User, which ultimately belongs to a Zone:

UserLogon -> User -> Customer -> Group -> Zone

As such, by calling the GetUserAccountList, Zone is implied, and no extra work is needed to take advantage of the shared database.

One exception to this rule comes into play with core calls. If each Zone has a different core configuration, there are different adapters configured to talk with them. The existing call to communicate with your core through HQ (AdapterPassThru) takes in a string of raw data to forward to the core and HQ credentials. Neither of these inputs implies a Zone in any way. For cases such as this, there are HQ Endpoints with Zoned variants. For instance, AdapterPassThruZoned takes in the same information, but also a context_id and a context_type.

As an added benefit, the SDK provides a helper with self.core in your extensions. Any call to self.core will automatically forward the currently logged in user’s information, providing the relevant group/customer/etc info to the AdapterPassThruZoned call on your behalf, keeping your code focused while still giving you the full power of zones.

Here’s an example:

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

Nowhere in that code is zone referenced, but upon running mapper.execute, this call will forward the self.online_user information to the SDK’s built in core framework, and assuming the HQ version supports it, will invoke AdapterPassThruZoned, funneling the call through to the appropriate Adapter.

Note

If you do not have a self.online_user (such as in an Ardent Handler) you will want to create an online_user object yourself and configure self.core with it. This is done with self.core.update_configured_user(OnlineUserObj)