Infor FACTS connectors overview

This document series outlines the integration elements included in the Optimizely Configured Commerce connector for Infor FACTS ERP. It identifies and defines the default integration points, along with the necessary details, including the field mapping and high-level technical processes. While these integration points and jobs cover a majority of the integration requirements with FACTS, there may be customer-specific requirements that you need to incorporate into a customer's Configured Commerce implementation.

Commerce implementations will use standard integration mechanisms between FACTS and Configured Commerce will be used wherever possible, using the native ERP's APIs. Modifications can be made to the integration processes to support a customer's unique business needs. This document focuses on Optimizely customers implementing a version of Configured Commerce and integrating it with Infor FACTS, with implementation assistance from Optimizely partners.

Optimizely based this integration on the following:

Complete the following pre-requisites before attempting this integration:

Many portions of this document refer to tables within FACTS. See FACTS documentation for definitions of those tables and potential values.

Configured Commerce relies heavily on the Pricing and Availability APIs, so Optimizely assumes the FACTS APIs are responsive. Any issues with the speed of the APIs may require an ERP expert to assist, as Optimizely does not have the resources or expertise to troubleshoot standard ERP APIs.

Version 7.8 of the FACTS ERP uses the table ar_slsp_terr instead of ar_salesperson_territory. If integrating to version 7.8, the salesperson refresh job will need to be updated with the correct table name.

There are many features in FACTS and some of these are worth calling out as not being supported by the standard connector including:

The integration tasks between FACTS and Configured Commerce are separated by the source and destination of the datasets and the mechanism used to implement the integration. The three types of integration tasks are designated as Refresh (Pull data in batch directly from the database), Submit (Push a transaction) or RealTime (direct calls to the APIs).

Refresh (Pull): Configured Commerce relies on FACTS to provide product, customer, order history, invoice data, and aged A/R data. Refresh tasks are typically run at scheduled intervals to synchronize new or updated data with Configured Commerce. Direct calls to the FACTS database are used for refreshes via the WIS.

Direct API Calls (Real-Time): Direct calls to the exposed FACTS API are made for things like inventory and pricing.

Submit (Push): Configured Commerce relies on the FACTS APIs for functions like order submissions that require data to be submitted to the ERP.

Refreshes use the Field Map capability of the Configured Commerce integration architecture. When we construct a connector, we create a series of job definitions that encode these mapping rules within the job definitions for refresh jobs. The mapping documents below will call out the standard connector logic and it is up to the implementation partner or customer to make adjustments as needed for their particular needs.

For example, by default, the product length/width/height are not exposed in the Admin Console unless exposed via the application dictionary. The query may obtain these fields, but they will not be in the standard field map since the fields are not exposed in the field mapper unless they are exposed via the application dictionary.

Note that the setting for the company number in FACTS is IntegrationConnector_FactsCompanyNumber and is incorporated into the standard jobs. The value of the setting name is case sensitive.

For each entity being refreshed, there must be a strategy on how to handle records that are not in the dataset retrieved from the source tables. The Configured Commerce options are to Ignore, Delete or Set a field such as IsActive or DeactivateOn. These strategies will depend on several factors, including:

Each refresh will define the standard deletion strategy being used.

There will be several real-time interactions with FACTS through the APIs, this document will outline the specifics of each API call as needed. Note that FACTS implements a set of specific APIs that can be used for website integration whereby records are added to an interface table named SMCATL. When the API is invoked against one of these APIs, it will normally consume those records and they will not show up again until the records are modified. There is a process to initialize these tables using menu SMF and the StoreFront Initialization option but the standard connector will be using ODBC for refreshes instead of APIs. There may be circumstances, however, that a partner may wish to leverage the SMCATL table instead. We are choosing to use ODBC for simplicity, control by the business user and consistency.

While we are not currently using these APIs for refresh jobs, we are providing additional information about them should a partner choose to implement a refresh that does.

There are some base fields and format that we would expect the refresh APIs to use a sample is below:

The RequestID is the name of the API we are calling. All will use the Company as established in the Connector Parameters. The ConsumerKey and Password will come from the Integration Connection settings.

Note that he RestartPoint is used to indicate a place to grab the next batch of records if the records are not coming from the interface table and may be set from the previous call. Only APIs with MaxRecords will support this function and it is only available when the API is NOT using the SMCATL interface table.

The MaxRecords is used to indicate the maximum number of records to pull back from the ERP which can be set by integration job (Processing Batch Size) or use the global batch size set in the Integration Settings. Not all APIs support this function. Depending on the API, if the RestartPoint is available, it will require that as a starting value for the next batch.

The Delete version of the same API can be invoked if it exists and those records will be appended to the processed dataset as Deletions.