Windows Integration System overview

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.

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.

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:

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:

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.

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.

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.

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.

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

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

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