The BizTalk Orchestration Services hold a pivotal role within BizTalk Server 2000, since this part will run the XLANG schedules that will be responsible for the data flow of your BizTalk application.You will use the BizTalk Orchestration Designer to implement your business processes and link them to the BizTalk Messaging Services or COM+ and Windows Scripting components. Before you start drawing diagrams, you need to have a firm picture of which business processes you need to implement, and you must know what the information is that will populate this application.Without the use of a design methodology, you will never be able to get a complete picture of the business process and information
»involved.The applications you build with BizTalk Server are object oriented, so using a methodology that is based on UML (Unified Modeling Language) is a good choice. For the purpose of example, we use ICONIX in this chapter to demonstrate the use of a good design method.The most prominent benefit of using a UML method is that at the end of the design process, you have all the information you need to start the implementation, and in a format that speeds the implementation. The same information can be used by all members of the development team, each doing his or her part of the puzzle.The person responsible for diagramming the business processes will use the BizTalk Orchestration Designer.
The BizTalk Orchestration Designer lets you create XLANG schedule diagrams in which the business process flow is linked to messaging or component implementation object.The business flow itself does not handle any data; it only controls how the data, wrapped in XML messages, flow from one implementation object to another. As you open an empty diagram stencil, you will see that it is divided in two parts: the left side can be used to draw the business process flow, and the right side holds the implementation objects. Only the Action shape, which is one of the available Flowchart shapes, in the business process diagram can be, or better to say "must be," linked to an Implementation shape at the right side. The Divider bar not only separates both sides of the stencil, it also forms an abstraction layer, by means of ports.These ports do the actual binding between an Action shape and Implementation shape, by means of defining the messages that are available at the port.
To be able to populate the messages, you must use the Data Flow stencil that every XLANG schedule diagram has. Since you need a message to populate another message, the schedule will most of the time start with receiving a message that is the trigger to start a business process. The Data Flow stencil holds all messages that are defined on the Business Process stencil. By drawing data flow arrows from one message field to a field in another message, you are able to populate new messages.
An important implementation aspect that needs to be addressed in the business process diagram is "transactions."This is so important because it is able to influence the business process flow.The purpose of a transaction is to group a part of the diagram that holds more than one Action shape in such a way that it acts as one shape.Therefore, if one of the actions fails to complete or produces an error, the entire transaction fails and needs to undo all actions it performed before the failure. If such a transaction has only performed updates on a database, it is easy to automatically undo the transaction, since the SQL server has the capability to take care of that. However, if the transaction communicates with other applications—for example, through messaging—undoing an action is not trivial. In these cases, you can create separate flowcharts that take care of the undo or compensate for the failure.These Compensation flowcharts become an integral part of the business process, since compensation might imply sending a message to the other application (or trading party) to inform them of the compensation action you take. It is obvious that the other party needs to understand these messages and know how to handle them.
Once you have the XLANG schedule diagram ready, you have to compile it to an XLANG schedule, which is a diagram translated to a BizTalk XML file that can be run by the XLANG scheduler engine. The compilation also checks the diagram for correctness and completeness.The correctness has more to do with restrictions that are imposed on the implementation of XLANG schedules than errors in the diagram. The restrictions are there to minimize the chance that a schedule encounters an unexpected runtime error and crashes.
This chapter uses a simple banking example to show how to go through the ICONIX design process and eventually implement it in BizTalk Orchestration Designer. It demonstrates the usefulness of an object-oriented design methodology, and how the design result can easily be turned into a BizTalk XLANG schedule implementation.
Was this article helpful?