[ 1 ] [ 2 ] [ 3 ] [ 4 ] [ 5 ] [ 6 ] [ 7 ] [ 8 ] [ 9 ] [ 10 ] [ 11 ]

First of all, we receive the purchase bid. We then calculate the minimum prices we are willing to accept depending on the items ordered and the organization that tries to place the order. This could result in one of 3 different scenarios:

1)       No prices were named and the order cannot be completed. All we can do now is send a quote and end the scenario (rule: “No Prices Named”).

2)       Prices were named, but they were not acceptable. In this case, we deny the bid and end the scenario (rule: “Else”)

3)       The bid is acceptable and we proceed fulfilling the order (rule: “Bid Acceptable”).

If we can accept the bid, we send an approval notice proceed with two different scenarios. For one, we create an invoice and send it to the organization that placed the order. This branch ends after the invoice has been sent. The other branch proceeds to updating our registration database (if the order contained products we register such as software) before the appropriate shipper is determined. Again, there are 3 different options:

1)       We need to ship the product ourselves (rule: “EPS Ships Product”).

2)       A third party ships the product for us (rule: “Third Party Ships Product”).

3)       The product doesn’t need shipping. This can be the case if the ordered item simply was a license, or if the product already has been shipped, a novelty that can occur in the case of West Wind shipping a product such as Visual WebBuilder.

If no shipping is required, the scenario simply ends here. If we ship it ourselves, we figure out who is responsible for shipping the product within EPS, alert them, and eventually update the status of the order to “shipped”. If a third party needs to ship the product, we forward the shipment request to them and wait for a status update (this could take a while). No matter who ships the product, eventually we will create a shipment notice so the organization that ordered the item knows that it’s coming.

This completes the design of our purchase order process. By now you probably think “oh well, another diagramming tool, what’s the big deal?” But wait, there is more to come!

Implementing the Business Scenario

What’s really unique about the BizTalk Application Designer is the fact that although it appears to be a simple diagramming utility, it really is a developer tool in the same way the Visual FoxPro Class Designer is. In fact, we will now proceed to add the implementation to the diagram and compile the application right from within the Application Designer.

To keep the example simple, I will only implement a small subset of the diagram displayed and explained above. Here are the first few steps from the diagram above (stretched out to make it easier to view) with the implementation:

[ 1 ] [ 2 ] [ 3 ] [ 4 ] [ 5 ] [ 6 ] [ 7 ] [ 8 ] [ 9 ] [ 10 ] [ 11 ]