Overview of Connectors for A+

Audience and purpose

This document series outlines the integration elements included in the Optimizely B2B Commerce (ISC) 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 B2B implementation.

Optimizely's A+ connector uses standard integration mechanisms between A+ and ISC. This document focuses on Optimizely customers implementing a version of B2B 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 B2B 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

ISC 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 B2B 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): B2B 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): B2B 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)