Infor CSD connectors implementation

9 min

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 provides a list of suggested tasks to follow and review when implementing this connector.

Turn on the connector

Connector enablement settings are global.

Enter the parameters for Company and Refresh Warehouse.

The CSD Web Order Number represents the field in CSD to which you will submit the Configured Commerce Web Order Number.

The CSD Integration Connection is the connection that you will use for CSD API calls. The setup of this connection is outlined below.

Set up the Integration Connection for API endpoints. This will be used for real-time calls.

Select the type of SXe API.

Ensure that the API Endpoint is the URL to the API that is accessible from the website (for example, https://mycompany.com:port/).

Since CSD is a multitenant solution, we recommend explicitly denoting the full API endpoint (for example, https://DOMAIN/TENANT/SX/web/sxapirestservice/).

Note: We automatically append the default path of the ION API, "infor/SX/rest/sxapirestservice/", to the end of the API endpoint if you do not designate a specific path.

Set up the Integration Connection for Compass.

Select the Type Name of ApiRopcEndpoint.

Set the Token Endpoint in the following format, where ENVIRONMENT is the name of your CSD tenant: https://mingle-sso.inforcloudsuite.com:443//as/token.oauth2

Set the API Address as the base address used for CSD: https://mingle-ionapi.inforcloudsuite.com

Set the Resource as the specific route used by Compass, where ENVIRONMENT is the name of your CSD tenant: //DATAFABRIC/compass/v2/jobs

Insert the Token Username, Token Password, Client ID, and Client Secret as provided in your .ionapi file.

Enter the Company Number. We intentionally have the company associated with the API connection separate from the one used for refreshes.

This allows for the circumstance where data is acquired from multiple CSD companies yet the API must have a single, numeric company number for calls.

The App Server Host is not required for V11, as it uses the REST APIs.

Enter the User Name and Password, conforming to the security and user setup in CSD.

The Client ID and Client Password are the credentials from CSD for accessing the API.

The Token User Name and Token Password are the credentials for retrieving the authorization token from CSD.

The Token Endpoint is the URL from which to retrieve the bearer token.

Assign the connection to the generated integration jobs in the Admin Console.

Optionally, you may chain the jobs together. It is a common practice to set up the first job as recurring nightly and then chains from job to job through the chain of refreshes ending with rebuilding the search index. This keeps your jobs from attempting to run concurrently.

Business considerations

This section outlines business considerations for specific Configured Commerce CSD integration jobs. You may need to adjust some jobs based on how a customer has implemented and configured CSD.

CSD 03: Product

Determine if you want to have the Catalog (ICSC) table retrieved by Configured Commerce in addition to the ICSP table.

If you do not want to bring catalogs in, go into the first step to the WHERE clause and delete everything from UNION and below.

If you want other products (such as kits) to flow into Configured Commerce, modify the WHERE clause to include those item types.

If you are integrating product data with another source, make sure to determine which fields are derived from SX.e and which from another system or method. Remove those being managed from another system or method from the query and/or mapping.

CSD 04: Product Cross Sells

This pulls records with record type of U (upgrades) and S (substitutes) from the ICSEC table into the Cross Sells related product type.

You can adjust this by changing either the SELECT clause for the desired relationship and/or the WHERE clause for the records to select.

You can also clone the job definition or add additional steps to include different sets of related products as needed. If doing this, confirm that the Product Relationship exists in the System Lists table.

CSD 05: Customer Refresh

Decide if you want to assign inside or outside sales reps to the customer. The default is outside sales rep. This drives the ability for a sales rep to sign into Configured Commerce and access their assigned customers.

Select the country code to use as a default if none is defined in the SX.e database. The default for the job is US.

CSD 07: Order History

The following points relate to the lookback period, which differ in integration versus the settings that control the default behavior on the site.

Do not use the delta dataset option on this job.

Fill in the Order Status Mapping table in the Configured Commerce Admin Console for order status codes to get the descriptions desired. Below is an example default setup:

0 = Entered

1 = Ordered

2 = Picked

3 = Shipped

4 = Invoiced

5 = Paid

9 = Canceled

We suggest you backfill order history by adjusting this job so the WHERE clause using the transdt uses a range of orders or has an enterdt to only retrieve orders from a certain date.

Do this in batches if there are a large volume of records being processed.

Be sure to confirm each clause is referring to the same time period being backfilled on each step.

Adjust the lookback days as needed.

Once the backfill is done, set the Starting Order Number setting in Settings.

The starting order number should be old enough to cover any open orders that may incur changes, but new enough to limit the number of records pulled by the query for performance reasons.

CSD 08: Invoice History

The strategy for invoices is identical to orders, especially since the data comes from the same source tables (OEEH, OEEL). This set of queries will only return records in Invoiced and Paid status to limit its scope. Follow the Order History instructions above to load the initial tables and then set the job for ongoing refreshes.

CSD 09: Shipment Refresh

This job is optional if you do not have any OEEHP records.

It takes up almost no resources, so it you do not need to delete it for performance concerns if these records do not exist.