Biztalk Orchestration

It is used in Specify Later port binding option. In this model the orchestration ports are bound to messaging ports using BTS.SPID,BTS.ReceivePortID or other related properties.

A scope configured as Atomic or Long running can have compensation blocks added, but scopes that are configured with no Transaction type cannot.

Scopes are used for following reasons:

☛ To configure transaction (long running and atomic)

☛ To handle exceptions

☛ To trigger compensating logic

You construct a message any time that you introduce a message into your orchestration, either by receiving it or by assigning values to a message variable. There are several ways to create a new instance of a message in an orchestration

No, It is not possible to use the If Then Else Logic inside the message Assignment. It has to be used in the expression shape.

BizTalk Server architecture is asynchronous for scalability reasons. However, the architecture of the BizTalk Messaging Engine enables exposing a synchronous message exchange pattern on top of these asynchronous exchanges. To do this, the engine handles the complex task of correlating the request and response messages across a scaled-out architecture by linking together a number of asynchronous message exchanges to expose a synchronous interface.

No. General exception in BizTalk is similar to writing a Try-Catch block but without the exception object thus not possible to get the exception object.

The Orchestration can not promote the properties to message context by default like pipelines can do by using the msg.Context.Promote() method. Inside Orchestration one has to create a correlation set and intialize that correlation set while publishing the message. Then the BizTalk Engine will promote the property to the message context.

Any exception which is not caught within the exception handlers of the orchestration causes the orchestration instance to be moved to the Suspended state. By applying the appropriate error handling in an orchestration it can be prevented entering the Suspended state.

One of the best practices when implementing orchestrations is to use orchestration patterns when possible. These patterns are basically design pattern, which is a general reusable solution to a commonly occurring problem within a given context of BizTalk orchestration. This article will provide some useful resource links to aid you in using patterns when implementing an orchestration.

A correlation type is a list of properties that eventually populates with values for use in routing messages.

There are no limitations on the number of branches which can be used in a parallel shape.

The term binding refers to the configuration of orchestration ports in order to control the creation of subscriptions and/or promoted properties. Binding is used to control how messages will be routed to or from orchestration ports by the subscription mechanism.

Calling an orchestration will use the same thread to run another orchestration while using Start Orchestration will create a new thread to run the started orchestration.

A Call Orchestration returns the control back to the caller. A Start Orchestration shape starts the orchestration in a non-deterministic way.

As a conclusion, Calling an Orchestration will be synchronous operation where the caller waits for a response, while Start Orchestration is asynchronous operation.

Pro's:

☛ Loose coupling

☛ Not bounded to any physical port (explicitly)

Con's:

☛ Can lead to subscribing to messages published by another publisher

Correlation is the process of matching an incoming message with the appropriate instance of an Orchestration.

A message is received through a receive location defined in a given receive port. This message is processed by the pipeline associated with the receive location, and if there are any inbound maps associated with the receive port they are executed. The resulting message is then published to the MessageBox database. The MessageBox evaluates active subscriptions and routes the message to those orchestrations, and send ports with matching subscriptions. Orchestrations may process the message and publish messages through the MessageBox to a send port where it is pushed out to its final destination.

Yes it is possible. You can do so by setting "Build Action" property of that orchestration to "None". By default value of this property is "BtsCompile".

No it is not, since it forms cyclic dependency.

The message metadata is called Context Properties and on receiving the message, both the adapter and the pipeline will add information to the context.