This article outlines the integration elements included in the Optimizely Configured Commerce connector for IFS Cloud (formerly IFS Aurena). It identifies and defines default integration points along with details related to field mapping and high-level technical processes.. While these integration points and jobs cover a majority of the integration requirements with IFS Cloud, a customer may have specific needs to incorporate into their Configured Commerce implementation.
Optimizely's IFS Cloud connector uses standard integration mechanisms between IFS Cloud and Configured Commerce via the standard Odata API. This article is for Optimizely customers implementing a version of Configured Commerce and integrating it with IFS Cloud with assistance from Optimizely partners.
Optimizely based this integration on the following:
- Versions Supported: Optimizely based this connector on IFS Cloud Version 10, Update 8. Because we are using standard APIs, we expect that future versions should 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: There are no specific payment gateway considerations for IFS Cloud.
- Tax Calculators: Configured Commercecan call external tax services, but otherwise you can import tax rates on a per-state level from IFS. There is not an IFS Cloud-specific Tax Calculator.
Complete the following pre-requisites before attempting this integration:
- Create a user in IFS for Configured Commerce to access its Odata endpoints.
- Depending on your configuration, IFS Cloud may use ROPC Authentication, so be aware that the connection type created in Configured Commerce should be of type “APIROPCEndpoint”, not “APIEndpoint” in that case.
- Review the tenant requirements if you are using Azure authentication with IFS Cloud. Your token endpoint will look something like this: https://login.microsoftonline.com/[tenant guid]/oauth2/token
Many portions of this document refer to tables or objects within IFS Cloud. Please refer to IFS documentation for definitions of those tables and potential values.
Configured Commerce relies heavily on the OData APIs in IFS Cloud, so 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.
- IFS’s OData endpoints do not allow joining of table data or significant manipulation of the returned data. As such, you may need to run jobs in a multi-step configuration to retrieve all the data necessary, if it not available in one OData call.
- There is not a pre-existing tax calculator for IFS Cloud. Tax data will need to be calculated with an external service (IE Avalara), or by importing state tax rates from the ERP.
- The Real-Time Pricing calls for IFS Cloud use the “Price Query” functionality within IFS Cloud. While there is not a limitation here, know that this will populate records on the Price Query screen. You may wish to create scripts in the ERP to regularly purge this data.
Overview of integration jobs
The source and destination of the datasets and the mechanism used to implement the integration separate the integration tasks between IFS Cloud and Configured Commerce. The three types of integration tasks are Refresh, Submit or Direct.
- Refresh: Pull data in batch via OData APIs
- Configured Commerce relies on IFS 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. OData API calls are used for refreshes.
- Submit: Push a transaction
- Configured Commerce relies on the OData 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 Odata APIs.
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 IFS Cloud 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 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:
- 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.
The following is the list of standard APIs used for real-time integration:
- Pricing: PriceQueryHandling.svc
- Availability: InventoryPartInStockHandling.svc
- Order Submit: CustomerOrderHandling.svc