Introduction to MXO Data Adapters
The MXO Data Adapter framework provides a mechanism for accessing various data sources and making that data available for building Eligibility Rules.
Data Adapters are the component of MXO that communicate with your existing web services.
MXO provides a number of out-of-the-box Data Adapters, including Geo Location and Salesforce.
We build and provide industry adapters using open standards that communicate with external web services such as RESTful JSON.
What do Data Adapters do?
Data Adapters provide access to external data sources, such as your existing CRM, to enrich the data used for decisioning and to allow you to expand the breadth of the information you can use when designing Eligibility Rules for any given customer.
The MXO Data Adapter framework has been designed to simplify data access. Customers can add more Data Adapters at any point to give them more access to more data sources or services as required.
How do Data Adapters work?
The MXO Data Adapter framework consists of a generic API that works across all Data Adapters and a number of implementations for specific data sources including both common industry and bespoke customer data sources.
MXO only interacts with data sources through the API, meaning any data source that can be implemented under that API can be accessed by MXO . This means direct access to your data repository is not required.
The API provides two main functions: describing data and retrieving data.
Data description
Before MXO can make use of any data, a Data Adapter must provide details about the information it has available. To retrieve this information, MXO calls the (getDataContainerDefinition) method. The (getDataContainerDefinition) method returns information about the structure and further details of the data that is returned by that Data Adapter.
For example, you have a data source that can provide information about the current balance, the average balance, and the last transaction date for a customer's bank account. The definition of this data could be:
Account Details
Current Balance (numeric)
Average Balance (numeric)
Last Transaction Date (datetime)
With this structure and type of information MXO can inform business users about the available data and how that data can be used in decisioning.
Data retrieval
To access data, MXO calls the (fetch) method of a Data Adapter with a data key. The data key is the identifier for resolving the data. For example, imagine a data store that contains various details about a customer. In order to access data for a specific customer the Data Adapter needs to indicate which customer needs to be looked up. This information is provided through the data key. The data key might be a customer number, account number, email address etc. depending on how the data source is configured.
A data key is similar to a primary key in a database table; it is used to look up data. As with primary keys, it is possible to have composite data keys. A data key can consist of multiple keys, for example, customer name and date of birth.
Lazy loading and caching
Having lots of data enables business users to build more powerful business Eligibility Rules. It is essential, however, to limit access to Data Adapters from an operational point of view for the following reasons:
If there are too many Data Adapters and they are all consulted for every interaction this might lead to latency issues.
In addition to latency issues, some data sources can be expensive because they have to be paid for, for example, credit scores.
MXO addresses these issues by only accessing data used by business Eligibility Rules in a lazy fashion. This means that during the execution of any business Eligibility Rules, Data Adapters are accessed only if data is needed to complete a calculation.
In addition, the MXO Data Adapter framework also provides caching functionality. Every Data Adapter can be configured to cache retrieved data for a certain period of time to prevent redundant calls to retrieve the same data. Caching is configured for individual Data Adapters using the MXO user interface.
Subsequent calls execute faster because that info is kept in memory. The data is not, however, persisted in the system. For example, in a situation where the target system is offline, if specific data is called by an Eligibility Rule, the Data Adapter behaves as if the information is unavailable.
