Monitoring the BizTalk Server
BizTalk server includes a document interchange engine, a business process execution engine, a business document editor, a business document mapper, and a set of business document and server management tools. Initially, an agreement should be made between the organizations, to determine the following:
- the source and destination locations of the business documents
- the transportation medium to be used,
- the source and destination formats of the business documents
After the agreement, the business process diagram should be drawn by using the VISIO style-drawing tool. The business process diagram is then compiled to a XLANG file using XLANG Scheduler tool given by the BizTalk Server environment. The XLANG engine loads the XLANG file at runtime environment.
The sender application (say Application 1 of Organization A) is responsible for generating business documents in well-defined XML format (for e.g., a purchase order). This business document is submitted to the BizTalk server. Then, the business document has to be transformed using Schema transformations. Here, a mapping is done to transform the business document from the source organization’s native representation to the representation requested by the destination organization (for e.g., the source organization may submit an XML document, but the destination organization may require the document in EDI format). The source XML document is parsed to determine the well-defined XML standard. Encoding and encryption is done when specified. Until this stage, the documents are available in the work queue. Then, the document is serialized to the standard that is ready for transmission. The document in the interchange form will be available in the scheduled queue. By using the specified transportation medium, the document interchanges are transmitted to the destination location that has been specified in the agreement. Decryption and decoding of the business document is done at the receiving end (Application 2 of Organization B) if necessary. At this stage, the business document is in the target representation form. It is received by the target application that is running in Organization B. The business documents and interchanges will be in the retry queue when the BizTalk server is overloaded. In this case, the documents and interchanges are re-submitted to the BizTalk server automatically. When any error happens during the above stages, the documents and interchanges are moved to the suspended queue and cannot be re-submitted to the BizTalk server.
Since a BizTalk server acts as a bridge between systems having heterogeneous inputs, it is critical for the BizTalk server to perform optimally so as not to choke the performance of the system being integrated. The eG Enterprise of products is capable of monitoring the BizTalk server 2000 inside out. The BizTalk monitoring model that is used by the eG Enterprise for monitoring the BizTalk server is shown in Figure 1.
Figure 1 : Layer model of a BizTalk server
Each layer of Figure 1 is mapped to tests that report a wide variety of metrics revealing the internal health of the BizTalk Server. Using the metrics so reported, administrators can find quick and easy answers for many persistent performance queries, such as the following:
- Is the rate of interchange decodes and interchange decrypts unusually low?
- How is the transport mechanism functioning? Could problems in this mechanism be causing a slowdown in the reception and transmission of the interchange?
- Can the BizTalk server encode, encrypt, and serialize interchanges?
- Are applications able to receive and submit documents quickly to the BizTalk server?
- Is the BizTalk server experiencing any delays in document processing?
- Is the BizTalk server able to map documents?
The details about the 5 layers at the bottom of Figure 1 are available in the Monitoring Unix and Windows Servers document. The sections to come will therefore discuss the top 2 layers only.
