Biztalk Xslt

When a group of correlated messages could potentially be received at the same time, a race condition could occur in which a correlation set in a particular orchestration instance must be initialized by one of the messages before the other messages can be correlated to that orchestration instance. To ensure that all of the correlated messages will be received by the same orchestration instance, BizTalk detects the potential for such a race condition and treats these messages as a convoy.

Convoy is a term which we use to describe a class of application protocols, specifically it is a set of application protocols which have a race condition as described above. Let’s take an example. Say you are a hospital and want to have a service which handles all information about each patient. For a given patient you have three types of messages, an admittance message, status messages, and a discharge message.

If you look at your protocol, you will have built a service which just receives. Now let’s think about what could happen. Let’s say you send the patient admittance message and it goes through the system using maybe a synchronous protocol like HTTP. That means when you get the 202 back, you know the message has been delivered. But what if the BizTalkServer host which is actually supposed to process the message hasn’t started yet (i.e. the NT service is stopped). Maybe you had a power outage, maybe some intern decided to “hit this button”, who knows.

So the orchestration instance which is supposed to handle all messages for patient X has not physically started. The message is in the database (MessageBox) and if you look in HAT you will see the orchestration is marked as ready to run, but it can’t start cause there is nowhere for it to start.

Business Activity Monitoring (BAM) is a collection of tools that allow you to manage aggregations, alerts, and profiles to monitor relevant business metrics (called Key Performance Indicators, or KPIs). It gives you end-to-end visibility into your business processes, providing accurate information about the status and results of various operations, processes, and transactions so you can address problem areas and resolve issues within your business.

The BAM Framework provides an easy, real-time, transaction-consistent way to monitor heterogeneous business applications, and to present data for SQL queries and aggregated reports (OLAP). Through queries and aggregations, you can include not only the data that is present during the running business process, but also the state and the dynamics of the running business process, independent of how the business is automated.

Fundamental to BizTalk is the Publish / Subscribe Architecture. This architecture basically comprises of 2 main components. First of all, a publisher, who would be responsible to publish the message in the message store. And secondly, a subscriber, who will subscribe to messages of a particular format so that he gets them whenever they are published.

Publishing refers to the process of inserting the messages in the message box database. Normally, a receive port, an orchestration or solicit send port would be involved in publishing any message to the message box. A receive port would receive the message from the pipeline and publish it to the message box for an orchestration or a send port to pick up.

An orchestration would publish the message usually while sending it using the send shape. A solicit response port would actually publish the message when it receives a response from the end system.

The subscribers would indicate the message they would like to receive by a set of criteria or filters.

Thereby, whenever a message is posted or published to the message box database, a subscriber will be able to get the message based on the filters or criteria mentioned while subscribing. The filters can be specified only on the promoted fields on the message.

☛ A Compensation section is generally written, in order to UNDO the effect of a transaction.

☛ The Compensation section for a scope gets activated only when the scope terminates normally or the scope completes its execution.

☛ Unlike exceptions, a compensation section can be written for a “Atomic” as well as a “L-R”

☛ A Compensation section needs to be explicitly invoked, using the Compensation Shape in order for it to execute.

☛ A Compensation section for a scope does NOT automatically undo the effect of a transaction. The compensation section must have the undo logic in place in order to have such an effect.

☛ A Compensation shape can be used to invoke/execute a compensation section. The control returns to the next operation after compensation shape, once the execution of the compensation section is complete.

☛ Is it possible to share variables across two branches in a Parallel shape

yes it is possible you just need to set the “Synchronized” property to true.