As before, a simple scenario is the best way to make clear how BizTalk Server supports system workflow. The figure below shows an example of how an organization might use this product to automate the process of placing an order.
The system workflow itself—the logic that controls this process—is implemented in a BizTalk orchestration, as shown above. Because different applications represent information in different ways, BizTalk Server also provides data transformation tools to map between these diverse data formats. And since a variety of approaches are used to communicate with applications, BizTalk Server relies on adapters to implement different options. The product includes adapters for communication via queues, via Web services, through the Windows file system, and using other technologies. Microsoft also provides adapters for interacting with popular packaged applications, such as those from SAP and Oracle.
In this example, suppose an inventory application determines that some item needs to be reordered. It sends an order request to BizTalk Server via an appropriate adapter (step 1). This request starts an orchestration, which then creates a message requesting a purchase order (PO) for this new item and sends it to this organization’s ERP application (step 2). As always, communication between BizTalk Server and this application relies on some adapter, and BizTalk Server also performs any required data transformation. Next, the ERP application creates the purchase order and sends it back to BizTalk Server (step 3). Once this message is received, the orchestration creates another message to actually place the order, then sends it to the fulfillment application (step 4).
All three of the applications used in this process might be inside the same organization, making this an example of enterprise application integration. It’s also possible that, say, the fulfillment application is located at a supplier firm, which makes that part of the process qualify as business-to-business integration. In either case, the system workflow implements the controlling logic for this process, while each of the applications the workflow relies on carries out its own responsibilities.
In this example, suppose an inventory application determines that some item needs to be reordered. It sends an order request to BizTalk Server via an appropriate adapter (step 1). This request starts an orchestration, which then creates a message requesting a purchase order (PO) for this new item and sends it to this organization’s ERP application (step 2). As always, communication between BizTalk Server and this application relies on some adapter, and BizTalk Server also performs any required data transformation. Next, the ERP application creates the purchase order and sends it back to BizTalk Server (step 3). Once this message is received, the orchestration creates another message to actually place the order, then sends it to the fulfillment application (step 4).
All three of the applications used in this process might be inside the same organization, making this an example of enterprise application integration. It’s also possible that, say, the fulfillment application is located at a supplier firm, which makes that part of the process qualify as business-to-business integration. In either case, the system workflow implements the controlling logic for this process, while each of the applications the workflow relies on carries out its own responsibilities.
No comments:
Post a Comment