The Windows Integration Service (WIS) offers a secure means of exposing enterprise data and services to your Optimizely <<product-name>> 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 <<product-name>> 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 <<product-name>> 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.
Hosting the WIS on the <<product-name>> 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 <<product-name>> website:
## Refresh vs. submit
The integration tasks within <<product-name>> can be separated by the source and destination of the dataset - we have designated two types of integration tasks:
### Refresh (pull)
<<product-name>> 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 <<product-name>>.
### Submit (push)
Because <<product-name>> 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 <<product-name>> 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
<<product-name>> 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 <<product-name>> 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.
### <<product-name>> 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
<<product-name>> 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.