Windows Integration System Overview PDF

Windows Integration System overview Updated 7 months ago FollowNot yet followed by anyone 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...

Windows Integration System overview Updated 7 months ago FollowNot yet followed by anyone 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. 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. Avoid using the real-time thread unless it is actually necessary. The recommended approach is to use API calls into the target system for real-time order submission rather than rely on the WIS. Instead, reserve the real-time function for those cases where there is not an externally available API and the WIS must respond with data in a near-real-time fashion. Order submit and external queries are examples of when it would still be appropriate to use. Configured Commerce admin console (AC) 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. 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. Windows Integration Server (WIS) overrides Overview of Windows Integration Server (WIS) overrides. Suggest Edits Optimizely has a set of processes to check for changes in method signatures and constructors that are in the public surface area and call those out for documentation if we have to make changes - these are considered "breaking changes" and we document them. In Cloud, if the custom code references something in the private surface area, it will not be allowed in the environment and will fail our deployment checks. The WIS stands on its own and that code is not deployed in the site and is not specifically checked for backwards compatibility. Please be aware that if you override anything in the WIS, it is subject to breaking since we do not guarantee any backwards compatibility in the WIS - we just make sure we didn't break functionality.