Program and Data Flow

[Previous] [Next]

Let's take a look at how our example is going to work. Figures 11-1 and 11-2 show the process flow between the Toy Carz and Toy Car Parts. As you'll recall from Chapter 9, these two companies employ Jean and David, the clerks who created and processed business documents. We are going to replace their tasks with two computer systems.

Figure 11-1. Workflow illustrating the process put into motion when a purchase requisition is started.

The process works like this: an event kicks off a process between the two companies. In Figure 11-1, an employee at Toi Carz wants to purchase something from Toy Car Parts. The employee creates a purchase requisition (PR), for which he will select an appropriate vendor, item, and preferred delivery date range.

This data is processed by an application that applies business rules in accordance with Toi Carz policies. First, the application checks an employee database to make sure the person entering the requisition has the authority to purchase the products requested. Then the application checks whether the items requested are already in stock. If so, the total number in the requisition will be adjusted accordingly. If the authority and stock queries pass, a purchase requisition is entered into a database. This database contains all purchase requisitions that have been run through the same process of verification.

At regular intervals, the purchase requisition database is scanned for the purpose of building purchase orders to send to Toi Carz vendors. That scanning process checks a vendor database for address information and builds BizTalk documents, each document containing a purchase order for the appropriate vendor. These BizTalk documents are sent to the vendors, one of which is Toy Car Parts. The Toy Car Parts program and data flow is shown in Figure 11-2.

Figure 11-2. Data flow within Toy Car Parts.

When the program at Toy Car Parts gets the BizTalk document, the program parses the document to obtain the necessary information, including the purchase order payload. The customer record is interrogated to make sure the Toi Carz account is in good standing—that is, that Toy Car Parts has a current contractual relationship with Toi Carz and that Toi Carz is paying its bills.

Then the program checks to see whether the items are in stock. If the items are not in stock, a reply document is sent to Toi Carz informing the company that the item is on backorder. If the items are in stock, a record is placed in the orders database and the inventory is adjusted accordingly. Finally, a BizTalk document is sent back to Toi Carz containing a confirmation of the purchase order.

Let's look again at Figure 11-1. The BizTalk reply document created by Toy Car Parts is sent to Toi Carz. The BizTalk document is received by an ASP application, which captures the relevant information and does two things to complete the requisition process: it updates the outstanding purchase order database to indicate that the purchase order has been received and confirmed by the vendor, and it notifies each of the people who initiated the workflow.