Getting Started With ODI

Introduction

Thank you for your interest in our Operational Data Integration (ODI) product. This page is intended as a high-level overview of information about ODI and provide pointers to more in-depth information as warranted. Within this page there will be information on how to obtain access to the ODI product if interested in adding it to your solution.

What is ODI?

ODI is considered a data broker for Jack Henry’s (JH) providers. The primary providers of ODI data currently are the banking cores CIF 20/20, Core Director and SilverLake. ODI is a middle ware that allows for a publisher/subscriber-based system to be setup where the providers deliver data to ODI and Consumers subscribe to receive only requested data from ODI.

ODI is designed to be a solution for providing consumers with just the data they need, while removing stress from the core systems. This eliminates the need for custom programs pulling data from the provider datastores and reduces costs for the programming and maintenance of the custom integrations.

ODI is a separate SQL data store of batch data, not a direct, real-time connection to the providers. ODI data is updated during the nightly update (end of day) processing. Once all nightly updates have occurred, the updated data is transmitted to ODI to be reviewed and parsed to the subscribers.

Setting Expectations

ODI is great middle ware for moving data from provider to consumer, though there are some expectations that need to be communicated about ODI.

ODI is not:

• A data warehouse – ODI does not store a complete history of data, only a current snapshot as determined by the provider settings.
• An online storage system for subscribers – It is understood that a consumer will copy the subscribed data to their own application database and then disconnect.
• A real-time query mechanism – ODI is a batch system and thus does not offer real time connectivity to provider data. For real time connections, we offer our jXchange product.
• A knowledge base – ODI does not have a data dictionary of the data it moves.
• A data normalizer – Consumer products must understand the differences in data content between the providers. ODI does not perform and normalization.
• A data preloader - ODI cannot be configured to assist with preloading of a time period’s selected data.

How does ODI work?

While ODI is a robust product, the basic functionality it performs is straightforward. ODI is a publisher and subscriber based system. Providers use SFTP to publish their data to ODI SQL tables during the end of day processing. ODI then reviews the provided data and parses the data into individual subscriber data stores. Subscribers have the option to:

• Attach to their subscribed SQL views and download the data directly to a local datastore.
• Receive the data in the form of a CSV file via SFTP retrieval or transmittal.

It is highly recommended that ODI subscribers review the ODI Consumer Interface Guide for more in depth information.

ODI Data Availability

• ODI gets its data during the banking core end of day processing.
• ODI subscribers have the option to select to receive their data as:
  • A full output of the daily snapshot.
  • Delta difference from the previous day’s output.
• ODI receives daily updates Monday – Friday and a full extract is provided every Sunday regardless if full or delta option is selected. There are no updates provided on Saturday. Any data changes that occur on Saturday will appear within Sunday’s release.
• ODI subscriber data is kept for 14 calendar days. This includes both SQL table data and CSV files. Once the data is aged out, it is no longer available to retrieve.
• ODI subscriber data options are not intended to be a complete selection of the data available from the provider. ODI extracts are only the most requested data elements within the provider systems.
• Consumers can elect to use one of the two methods for knowing when to retrieve their ODI extracts.
  • Timed schedule based on an extrapolation of when the bank provider’s end of day completes.
  • Use of the Enterprise Event System to receive a 50040-ODI Data Ready event broadcast to a consumer’s listener. See Enterprise Event System for more information.

Getting Started

Determine the Data Needed

The logical first step for a consumer wanting to utilize ODI’s potential is to review the available data extracts/elements and determine what, if any, would be beneficial to a consumer’s solution. There are two ways to review the available extract.

• Review the ODI Extracts portion of this portal.
• Use the ODI Element Mapping spreadsheets that are located within the ODI Documentation:
  • ODIElementMapping_CD_ConsumerVersion - Core Director extracts
  • ODIElementMapping_CIF2020_ConsumerVersion - CIF 20/20 extracts
  • ODIElementMapping_SL_ConsumerVersion - SilverLake extracts

We also offer a small subset of sample data on our Development Portal ODI Documentation. The filenames for each of the samples are labeled with ODI*SampleFiles.zip.

Requesting ODI Extract Access

Once a review of the available extracts and data elements has been completed and finalized, the next step in requesting a subscription to the data is to fill out an appropriate ODI Element Mapping spreadsheet discussed in the previous section. The spreadsheet is grouped by the extract name and then the available data elements within the extract. On the far right of the data element entry is a field labeled Selection for Consumer. For each data element desired, change the value of that column to Y to indicate a request for it to be added to the consumer subscription.

Next create a request using the appropriate case creation link, within the Case Summary state a request for an ODI subscription be created for your institution or solution and attach the completed ODI Element Mapping spreadsheet(s).

• If you are a Jack Henry client, please log a case via the For Clients Portal.
• If you are a VIP Member, please log a case via the Vendor Portal.
• If you are not a Jack Henry customer or VIP member, please see the Vendor Integration Program (VIP) section for information on joining the Vendor Integration Program.

The Developer Relations team will review the request and perform the necessary steps to complete the subscription request. Timelines to complete the request vary and will be provided within the request case, if requested.

Testing Subscriptions/Making Changes

After the subscription is configured and data provided, it is recommended that a consumer receive and compare several extracts, at a minimum, to ensure that the subscription is setup as expected and to observe how ODI provides the data.

During this testing period is the best time to request changes to the subscription. We can make the changes easily within the DMZ Development Sandbox environment. Once we receive notice to finalize the subscription for production, changes to the subscription can take longer due to production environment request backlogs. To request a change to the subscription, use the original ODI Element Mapping spreadsheet and make the necessary changes only to the elements/extracts that need to be revised. We use the spreadsheet to recreate the subscription so any changes to the spreadsheet will reflect on the updated subscription. Then enter a request case noting the need for a correction.

Finalizing and Moving to Production Environments

Once testing and review of the subscription has been performed within the DMZ Development Sandbox environment; a new case will need to be opened notifying Developer Relations that testing is completed and the solution is acceptable. The Developer Relations team will perform the necessary steps to lock the subscription solution and prepare the required documentation for the JH Implementations team to implement the solution within the proper bank environment. Any additional steps required at this point will be communicated via the associated case.