SX.e (v6) connectors implementation

7 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.

The following is a list of suggested tasks to follow and review during the implementation of this connector.

Turn on the connector

Connector enablement settings are global.

Enter the parameters for Company and Refresh Warehouse.

The SX.e Version is used to trigger version-specific functionality of the integration.

The SX.e Company number determines which company the integration will leverage in the ERP.

The SX.e Web Order Number represents the field in SX.e that the Configured Commerce Web Order # value will be submitted to.

The Refresh Warehouse is used for specific product information gathered from a default ICSW record instead of ISCP.

The Starting Order Number is used to limit how far back the refreshes need to go to pull order or invoice updates.

The SX.e Integration Connection that will be used for SXe. API calls. Setup of this connection is outlined below.

Set up the Integration Connection

Select the type of SXe API.

The API Endpoint should be the URL or IP to the App server that is accessible from the website for example https://mycompany.com/sxapi

The SX.e API endpoint is often set up in a DMZ to segregate it from the network and the app server host is configured to be accessible through the firewall.

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 being acquired from multiple SX.e companies but the API must only have a single, numeric company number for calls.

The App Server Host is typically something like Appserver://mysxserver.mycompany.com:7282/testsxapiappsrv

The appserver address is based on where the API server is and how it accesses the SX.e app server. An IP address can also be used rather than a DNS reference.

The User Name and Password must be entered conforming to the security and user setup in SX.e.

The Client ID, Client Secret, Token User Name, and Token Password fields are not used for this version of SX.e.

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

Set up the WIS SiteConnections.config table with an entry to the new Integration Connection.

This presumes you already have the WIS installed, the machine registered as a valid integration server and a valid user with the role of ISC_Integration

Optional: Chain the jobs together. It is a common practice to set up the first job as recurring so that it runs every night 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

The following section outlines business considerations for particular Configured Commerce SX.e integration jobs. Based on how a customer has implemented & configured SX.e, various jobs may need to be adjusted accordingly.

SXe 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. Those being managed from another system or method should be removed from the query and/or mapping.

SXe 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.

SXe 05 :Customers

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

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.

SXe 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.

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 exampledefault 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.

This should be done in batches if there are a large volume of records being processed.

During this backfill process, turn OFF the delta dataset option so that multi-threading can be used to improve performance.

Make sure to confirm each clause is referring to the same time period being backfilled..

Optional: Turn Use Delta Dataset back on if desired. This will send only the net changes to Configured Commerce instead of all records.

Adjust the lookback days as needed. The intent is that we are using the

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.

SXe 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.

SXe 09: Shipments

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

It takes up almost no resources so it is not required to be deleted for performance concerns if these records do not exist.