A+ connectors overview
Important
Optimizely's ERP connectors do not support .NET 8. Work with your partner or development team to take the open-source code and modify it to work with .NET 8 for your projects.
Note
Optimizely lets partners and the implementation community build ERP connectors to increase the number of ERP connectors and enhancements available to customers. Optimizely offers existing ERP connectors in their current state, and partners can access the connector code for future enhancements.
This article outlines the integration elements included in the Optimizely Configured Commerce connector for Infor A+ 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 A+, there may be customer-specific requirements that you need to incorporate into a customer's Configured Commerce implementation.
Optimizely's A+ connector uses standard integration mechanisms between A+ and Configured Commerce. This document focuses on Optimizely customers implementing a version of Configured Commerce and integrating it with Infor A+, with implementation assistance from Optimizely partners.
Connector requirements
Optimizely based this integration on the following:
- Versions Supported:10.x - on premise
- On-Premises Implementation You need to install the Optimizely Windows Integration Service application on a local Windows machine to orchestrate the integrations
- Payment Gateways: CenPos
- Tax Calculators:Avalara or any supported through API using order simulation
- Freight: Using ISC's shipping engine
Complete the following pre-requisites before attempting this integration:
- Infor APlus APIs must be in place and accessible to both a pilot/test instance and the production instance
- The APlus APIs must be accessible from the internet over port 443
- The Configured Commerce integration agent (Commerce Integration Service) must be up and running in the customers environment and have direct access to the databases
- An OLE-DB or ODBC connection to the database for direct access for refreshes
Features not supported
There are many features in APlus and some of these are worth calling out as not being supported by the standard connector including:
- Corporate Groups
- Alternate warehouses by customer/warehouse
- Start/End dates on restriction codes
- Ship-to overrides on restrictions (usms.cmckrs, addr.sackrs)
- State/Province support on restrictions via integration (can be done manually)
- Multiple units of measure as stocking units
- Customer: Backorders allowed by customer (cusms.cmacbo)
- Invoice History with multiple orders associated (mainly getting A/R information only)
Business issues/considerations
Many portions of this document refer to tables within A+. See A+ 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 A+ 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.
Overview of integration jobs
The integration tasks between A+ 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 A+ 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 A+ database are used for refreshes.
Direct API Calls (Real-Time): Direct calls to the exposed A+ API are made for things like the A/R Summary, inventory, and pricing.
Submit (Push): Configured Commerce relies on the A+ 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 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.
Deletion strategy
For each entity being refreshed, there needs to be a strategy on how to handle records that are not in the dataset retrieved from the source tables. The 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 (that is the whole table is being retrieved)
- Are we processing the data as delta datasets (net changes only)
- Are there child collection considerations (records that hang onto a parent such as invoice history lines are 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 a list of APIs used for standard integration we will use the applicable versions based on the A+ version being integrated to:
- Pricing & Availability: GetAvail (Line Item Price and Availability)
- A/R Summary: ARSummary
- Tax Calculation/Order Simulate: CreateOrder
- Order Submit: CreateOrder
- CustomerSubmit: Not Available via API (future implementation)