This article outlines the integration elements included in the Optimizely Configured Commerce connector for Infor Cloudsuite Distribution ERP (CSD). It identifies the default integration points along with details related to field mapping and high-level technical processes. While these integration points and jobs cover most of the integration requirements with CSD, a customer may have specific needs to incorporate into their Configured Commerce implementation.
Optimizely's CSD connector uses standard integration mechanisms between CSD and Configured Commerce through the standard ION API endpoints and the Compass API service. This article is for Optimizely customers implementing a version of Configured Commerce and integrating it with CSD with assistance from Optimizely partners.
Oprimizely based this integration on the following:
- Versions supported: Optimizely based this connector on CSD version 11.21.6. Because we are using standardized APIs, we expect future versions to integrate in the same way.
- Cloud implementation: The Optimizely Windows Integration Service application on a local Windows machine is NOT required for this connector.
- Payment gateways: The Order Submit job assumes you use CenPOS with CSD.
- Tax calculators: Configured Commerce can call Avalara or the ION API to execute an order simulation, which returns tax amounts
Complete the following pre-requisites before attempting this integration:
- Create a user in CSD for Configured Commerce to access ION API endpoints and Compass.
- Individual integration jobs must have the complete POST made to the CSD endpoints and you must update them with the correct user.
- If you use web promotions that may impact line level pricing, the global setting for OverridePrice in the Business Rules area of CSD must be set to true. Alternatively, you can set the EDI Price override flag on individual customers to true (arsc.ediprcfl), since order submission APIs are treated similarly to EDI orders.
This article contains references to tables or objects within CSD. Please refer to CSD documentation for definitions of those tables and potential values.
Configured Commerce relies heavily on Compass functionality and APIs. Therefore, Optimizely assumes that these endpoints 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.
Overview of integration jobs
The source and destination of the datasets and the mechanism used to implement the integration separate the integration tasks between CSD and Configured Commerce. The three types of integration tasks are Refresh, Submit or Direct.
- Refresh: Pull data in batch via Compass APIs
- Configured Commerce relies on CSD to provide product, customer, order history and invoice data. Refresh tasks are typically run at scheduled intervals to synchronize new or updated data with Configured Commerce. Refreshes use Compass API calls.
- Submit: Push a transaction
- Configured Commerce relies on the ION APIs for functions like order submissions that require data to be submitted to the ERP.
- Direct: Real-time API calls
- Inventory and pricing require direct calls to the exposed ION API.
Refreshes use Configured Commerce integration architecture's Field Map capability. When Optimizely constructs a connector, we create a series of job definitions that encode these mapping rules for refresh jobs. The implementation partner or customer can adjust the standard connector mappings for their particular project needs.
For example, by default, product length, width and height are not visible in the Admin Console, and therefore are not available in the Field Mapper. You can configure the CSD connector to retrieve this data from the ERP, but it will not be available in the standard field map tool to populate the Configured Commerce database. If you configure the field to be available via the application dictionary, it must be added to the Field Mapper for the data to flow into Configured Commerce.
For each entity being refreshed, there must be a strategy for handling 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:
- Are there child collection considerations? (Example: 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? (Examples: Customer Bill-Tos and Ship-Tos)
Each refresh will define the standard deletion strategy being used.
The standard APIs used for real-time integration are:
- Pricing & Availability: sxapiOEPricingMultipleV4
- A/R Summary: sxapiARGetCustomerBalanceV2
- Tax Calculation/Order Simulation (if 3rd-Party Tax system is not used): sxapiSFOEOrderTotLoadV4
- Order Submit: sxapiSFOEOrderTotLoadV4