SX.e (v6) connectors overview

This article outlines the integration elements included in the Optimizely Configured Commerce connector for Infor SX.e 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 SX.e, there may be customer-specific requirements that you need to incorporate into a customer's Configured Commerce implementation.

Optimizely's SX.e connector uses standard integration mechanisms between SX.e and ISC. This document focuses on Optimizely customers implementing a version of Configured Commerce and integrating it with Infor SX.e version 6, 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 SX.e. See SX.e documentation for definitions of those tables and potential values.

Configured Commerce relies heavily on the Pricing and Availability APIs, so Optimizely assumes the SX.e 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.

SX.e's order submit assumes that only authorizations are being committed for credit card orders through CenPOS. Our recommendation is to not run credit card transactions as Sales in Configured Commerce to prevent downstream issues with the ERP.

Versions of SX.e older than 6.1.09 do not have the ability to use the CenPOS integration our connector calls to. While other calls should work as expected, Order Submit would need to be customized by an Optimizely partner and older versions are not explicitly supported.

While Order Submit can be customized, credit card payment gateways cannot be customized in our cloud environment, and we do not support 19-digit card tokens.

The integration tasks between SX.e ERP 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 SX.e to provide product, customer, order history, and invoice data. Refresh tasks are typically run at scheduled intervals to synchronize new or updated data with ISC. Direct calls to the SX.e database are used for refreshes.

Direct API Calls (Real-Time): Direct calls to the exposed SX.e API are made for things like the A/R Summary, inventory, and pricing.

Submit (Push): Configured Commerce relies on the Infor SX.e 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 for refresh jobs. The mapping documents below call out the standard connector logic and it is up to the implementation partner or customer to adjust as needed for their particular project needs.

For example, by default, the product length/width/height are not visible in the Admin Console, and therefore are not available in the Field Mapper. The SX.e connector query will retrieve this data from the ERP, but it will not be in the standard field map tool to populate the Configured Commerce database. If the field is configured to be available via the application dictionary, it must be added to the field mapper in order for the data to flow into ISC.

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.

The following is the list of standard APIs used for integration we will use the applicable versions based on the SX.e version being integrated: