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 resides on a hosting platform or within your DMZ. The WIS is installed within your firewall and polls your commerce site for real-time and batch integration jobs to perform. When it has performed these jobs, it returns the results to your commerce site.

The WIS server has certain requirements for installation. See Prepare 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, you can set the integration processor 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 picks up the integration processor and starts 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. There are two types of integration tasks.

Refresh (pull)

Configured Commerce relies on data from the ERP system, such as products, inventory, and customers for use on your website. It pulls this data 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 (submitted) into the ERP. Examples of Submit tasks include the Order Submit and the Customer Submit.

Direct database and web service calls

You can complete the integration tasks between the ERP and Configured Commerce through direct database or web service calls. Direct database calls are often used when there is a large dataset or when performance is important. Typically, customer, product, and inventory refreshes are conducted via a direct database call. Web service calls are used when complex business logic needs to be applied during integration, such as order submission.

Real-time calls

Configured Commerce can conduct real-time calls to pull data from the ERP to be displayed on the website on-demand. 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.

Real-time calls often require direct access to the ERP. Because of this dependency, you should define a fallback process for the site to follow if the ERP is not available. Real-time calls must also operate efficiently and not detract from the user experience.

Admin Console

For many of the integration processes to run successfully, they require certain configuration or seed data to be present within the Admin Console. This data is often provided manually by either importing or manually entering data. For example, product category, product attributes, warehouse/locations, and so on are entered manually in a typical implementation.