Free 30 Day Trial
Find the root-cause of your cloud, hybrid-cloud
or on-prem performance issues
|
||
|
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:
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:
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.