BizTalk Workflow

The functionality of BizTalk can be divided into five logical stages: receive functions, channels, messaging ports, scheduling, and administration. Receive functions accept incoming documents. Channels log the documents, manipulate them, and handle encryption and digital signature tasks . Messaging ports are used to communicate via messages and documents with trading partners . Scheduling is the transaction orchestration process. Administrative tools can be used to monitor and change the settings of BizTalk components . Each of these functions has a corresponding BizTalk tool.

A completed BizTalk solution therefore consists of many objects you have defined, connected by the workflow process (Figure 11.12).

Figure 11.12. BizTalk Workflow (Note: Directional arrows denote flow of data.)

Channels are used to logically define the processes and track the business rules that pertain to a particular group of documents. This architecture allows a number of developers to simultaneously tackle different business processes or different parts of the same process. The team may also specialize in different phases in the process. A developer, for example, may be assigned to the messaging ports for each channel.

BizTalk Editor

The BizTalk Editor (Figure 11.13) is the tool for creating source and destination document definitions. It is a graphical tool for building XML schemas. The BizTalk Editor can handle file types such as ASCII delimited or fixed-length data files, XML, and EDI, and it can also import and export XSD files.

Figure 11.13. BizTalk Editor

The left pane of the BizTalk Editor displays the hierarchical structure of the document, and the right pane shows the properties for the selected node in the data hierarchy. The BizTalk Editor is a productive interface for defining XML schemas. You can also import XML, Excel, and other file formats to provide a rapid starting point for the new schema.

BizTalk Mapper

The BizTalk Mapper (Figure 11.14) creates the links between two XML schemas and saves them as an XSLT map. You can drag and drop to establish the connections between data elements in schemas, and you can perform functions to transform data during this process. This visual programming is much faster and easier to understand than line-by-line transformations in code.

Figure 11.14. BizTalk Mapper

If the mapping of one source field to a destination field is one-to-one with no conversion required, these visual links suffice to map the data. In cases in which transformation is needed, BizTalk uses a functoid , which is a built-in data conversion function. These can perform parsing, concatenation, field type conversion, and other functions.

BizTalk Orchestration Designer

The BizTalk Orchestration Designer (Figure 11.15) is a graphic tool based on Visio that depicts business processes for developers and business analysts. BizTalk Orchestration allows design and execution of long-running transactions as well as creation of an executable XML representation of the transaction using a language known as XLANG. Typically a business analyst begins by creating a workflow process, consisting of steps such as the triggering of a product reorder from a supplier, the purchase order generation, and other steps.

Figure 11.15. BizTalk Orchestration Designer

BizTalk Orchestration Designer is a visual design environment that specifies the individual actions involved in a transaction. Actions are grouped into collections to provide a single unit of work that is either committed or rolled back as a whole. This approach is essential for long-running transactions, which consist of many actions spanning one or more services. BizTalk provides exception processing to handle transactions in the event of a processing error. Procedures can be developed for error processing using events such as On Failure.

Long-running transactions create a new challenge for the database. In a short-running transaction, affected rows are isolated while the transaction is running so no other user or process can update them at the same time and corrupt the data. While the transaction is running, it is not yet known whether the transaction will be committed or aborted so other programs cannot count on the integrity of the data. A second program seeking the same data must await the result of the transaction. For long-running transactions, this approach is a nonstarter. It would be impractical to isolate data for an indefinite period of time, and locks cannot be performed across databases in different organizations. Imagine a supplier dealing with lock requests on a product table from hundreds or thousands of customers at a time.

The solution to this riddle is to create a number of short-running transactions and embed them in a single long-running transaction. The short-running transactions are committed one at a time as the long-running transaction proceeds, so the data becomes available to other applications. If one of the transactions fails, however, the long-running transaction is aborted. This triggers rollbacks of all the short-running transactions that comprise the long-running transaction.

Server Administration

BizTalk provides a management console (Figure 11.16) to view the queues and monitor the number of message at each stage of the process. You can watch the messages flow through the system through this administrative user interface.

Figure 11.16. BizTalk Server Administration Console

The event viewer is quite handy for debugging your BizTalk solution. It allows you to trace the events such as security activities and errors raised by the application.

Document Tracking

BizTalk relies on SQL Server as its database. The BizTalk repository stores all messaging and related BizTalk Orchestration metadata, as well as incoming and outgoing document instances. BizTalk provides a user interface for tracking its message and schedule activity and an API for programmatic access to tracking information. You can access the database directly and perform queries and data mining of BizTalk documents and metadata as well.