Windows Integration Service - WIS

The Windows Integration Service (WIS) offers a secure means of exposing enterprise data and services to your Optimizely Configured Commerce website. Typically, your commerce site will reside on a hosting platform or within your DMZ. The WIS is installed within your firewall and will poll your commerce site looking for both real-time and batch integration jobs to perform. Once it has performed these jobs it will return the results to your commerce site. Additional information on the WIS can be found in the WIS section of the SDK Support site.

The configuration can be seen in the diagram below:

The WIS server has certain requirements for installation. See Preparing the Hosting Environment for the WIS.

An integration job's pre- and post- processors run on the Configured Commerce website server, while the integration processors run on the WIS server. For development purposes only, the integration processor can also be set to run on the Configured Commerce website server. The SiteConnections.config file can be placed within the web applications root folder. On application startup, the site will pick up the integration processor and will start running an instance of the WIS using that connection information on the website server instead.

📘

Note

Hosting the WIS on the Configured Commerce website server is not recommended for production due to performance, connectivity, and integration capabilities to other systems.

Integration architecture conceptual model

The following diagram is another high-level view or conceptual model of the integration architectural points between the WIS, the ERP, and the Configured Commerce website:

Refresh vs. submit

The integration tasks within Configured Commerce can be separated by the source and destination of the dataset - we have designated two types of integration tasks:

Refresh (pull)

Configured Commerce relies on data from the ERP system, such a s products, inventory, and customers for use on your website. This data is pulled from the ERP using Refresh tasks. These tasks run in scheduled intervals, looking for new or updated data in order to synchronize it with Configured Commerce.

Submit (push)

Because Configured Commerce acts as the front-end for customers, data created on your website must be pushed (a.k.a submitted) into the ERP. Examples of Submit tasks include the Order Submit and the Customer Submit.

Direct database vs. web service calls

The integration tasks between the ERP and Configured Commerce can be accomplished through direct database or web service calls. Direct database calls are often used when there is a large dataset and/or when performance is important. Typically customer, product, and inventory refreshes are conducted via a direct database call. Web service calls are typically used when complex business logic needs to be applied during integration. Order submission is a typical example of when a web service call is used.

Real-time calls

Configured Commerce can conduct real-time calls to pull data from the ERP to be displayed on the web site in an on-demand fashion. This data is not stored within the Configured Commerce database. It is stored temporarily while the user is accessing the data. Some examples of real-time calls include inventory validation at checkout, product inventory and pricing, and credit card authorization processing by the ERP. Because real-time calls typically require direct access to the ERP, the site becomes dependent on the ERP. Because of this dependency, a fallback process should be defined for the site to follow upon the event that the ERP is not available. Real-time calls also need to operate efficiently and not detract from the user experience.

Configured Commerce Admin Console (AC)

For many of the integration processes to run successfully, they require certain configuration or seed data to be present within the AC. This data is often provided manually by either importing, or manually entering data in the AC. For example: Product Category, Product Attributes, Warehouse/Locations and so on will be entered manually in a typical implementation.

Integration architecture historical information

Configured Commerce 3.4 introduced a new architecture and strategy for integration. This strategy was adopted to accomplish the following goals:

• Move towards metadata/configurable data extractions so that code is not required to add in pulls of various data elements from the source system
• Enable both pulling and pushing of data (that is exports)
• Enable "direct" data interactions
• Standardize our ERP integration points with well-defined interfaces and methods
• Significantly better logging and alert system
• Enable delta datasets to minimize workload and data transport
• Accommodate very large datasets (broken down for transport)
• Use asynchronous processing to eliminate web service call delays and timeouts
• Multi-threaded data transcription
• Model or direct (stored procedure) transcription (flexible post processing)
• Single Windows Integration Service to handle unlimited connections
• Allow multiple sources of data

The new integration architecture also offers the ability to be run side by side with the legacy integration architecture.