SX.e (v10) connectors overview

  • Updated

Audience and purpose

This document series 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 10, with implementation assistance from Optimizely partners.

Connector requirements

Optimizely based this integration on the following:

  • Versions Supported: 10.3 On Prem
  • On-Premises Implementation You need to install the Optimizely Windows Integration Service application on a local Windows machine to orchestrate the integrations
  • Payment Gateways: The Order Submit job assumes you use CenPOS with SX.e
  • Tax Calculators: Configured Commerce can call Avalara or an SX.e API to execute an order simulation, which returns tax amounts

Complete the following pre-requisites before attempting this integration:

  • Infor SX.e APIs must be in place and accessible to both a pilot/test instance and the production instance
  • The SX.e APIs must be accessible from the internet over port 443
  • The Configured Commerce integration agent (Windows Integration Service) must be up and running in the customer's environment and have direct access to the databases
  • OpenEdge ODBC driver (32 or 64 bit) must be installed and able to connect to the databases
  • If web promotions are used which may impact line level pricing, the global setting for OverridePrice in the Business Rules area of SX.e must be set to true. In the alternative, you can set the EDI Price override flag on individual customers to true (arsc.ediprcfl) since the APIs used for order submission are treated similarly to EDI orders.

Business issues/considerations

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

Technical issues

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.

Known limitations

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.

Overview of integration jobs

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.

Refresh mapping

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.

Deletion strategy

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:

  • Is the data being snapshotted? (The whole table is being retrieved)
  • Are we processing the data as delta datasets? (Net changes only)
  • Are there child collection considerations? (Records that relate to a parent, such as invoice history lines being children to the invoice history header table)
  • Are we retrieving the data in separate queries? (Such as Customer Bill-Tos and Ship-Tos.)

Each refresh will define the standard deletion strategy being used.

API list

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:

  • Pricing & Availability: sxapiOEPricingMultipleV3
  • A/R Summary: sxapiARGetCustomerBalanceV2
  • Tax Calculation/Order Simulation (if 3rd-Party Tax system is not used): sxapiSFOEOrderTotLoadV4
  • Order Submit: sxapiSFOEOrderTotLoadV4