Click here to Skip to main content
Click here to Skip to main content
Go to top

Parallel Branching and Scoping in BizTalk Orchestrations - Advanced Concepts

, 14 Mar 2006
Rate this:
Please Sign up or sign in to vote.
This article explains the various tricky issues in parallel branching in BizTalk Server 2004 Orchestrations.

Parallel branching and scoping

Generally, parallel branching is used when you need to execute different un-related activities simultaneously.

Example 1: In your business process, if you need to call a web service and perform a transform. Since these two activities are un-related, they can be executed in parallel using a "Parallel" shape:

What is a scope?

A "scope" is a unit or a block which is executed as a context and is associated with a transaction type. In order words, a scope defines a context which maintains the state for a defined unit-of-orchestration code. If you were to open the *.ODX files in Notepad, you would notice that the scope shape placed in an orchestration would create the following:

scope
{
    task
    {
        // Can be a transform or an expression shape.
    } 
}

Each scope shape in the orchestration maps to a "scoped" segment of code. A segment defines the boundaries where the control is passed back to the BizTalk engine to persist data in the MessageBox store, thus enabling consistency and durability.

The scope shape in orchestration has two important properties:

  • Synchronized: This is a boolean flag which can either be "true" or "false".

    When two scopes in a parallel branch are set to Synchronized="true", then they would be executed independent of each other in such a way that each branch assumes that it is the only one being executed in the system.

    When an orchestration variable needs to be shared across several parallel branches, in that case, the scope's synchronization flag must be set to "true" or the 'Transaction Type' must be set to "Atomic".

  • Transaction Type: The 'Transaction Type' property can have the following values:
    1. Atomic
    2. Long Running and
    3. None

Note: An orchestration (*.odx) file also has a 'Transaction Type' property.

Transaction types

The classical definition of a transaction is - an atomic unit of work which results in moving the system from one consistent state to a new consistent and durable state. A transaction can either be "committed" or "rolled back" depending on various conditions. Note that a transaction which cannot be rolled back needs to be "compensated". This means that if an operation 'f(x)' has been performed on some data, in order to revert it back we need to perform an operation 'f(y)', which essentially performs an undo operation, this is known as "compensation" in simple terms.

Orchestration 'Transaction Type'

  • A non-transactional orchestration cannot have 'scope' shapes set to either "Atomic" or "Long Running".
  • If an orchestration's transaction type is set to "Atomic", then the orchestration cannot have any other transactions within its 'scope' shapes.
  • Atomic transactions cannot contain nested transactions or catch exception blocks. However, they can have compensation blocks.
  • Long running transactions cannot be isolated from other transactions. However they can contain other atomic transactions and can have catch exception and compensation blocks.

The image above highlights the various key properties to be set for an orchestration.

Note: These properties are applicable only when the 'Transaction Type' is set to 'Atomic'.

  • Batch: A boolean value that determines if this transaction can be batched with other transactions across multiple instances of the orchestration. The default value is "true". It may improve performance with the possibility of losing isolation data.
  • Isolation level: This property defines the degree of isolation between the state changes performed by different atomic transactions. This is not applicable for Long-Running transactions. BizTalk supports three isolation levels. These are 'Read Committed', 'Repeatable Read' and 'Serializable'. The last one being the default value.
  • Retry: A boolean value which specifies that the atomic transaction can be retried in the event of a failure. Perform the following for Retry-"throw an instance of Microsoft.XLANGs.BaseTypes.RetryTransactionException" within the transaction boundary.
  • Transaction type: Can be either "Atomic" or "Long Running" or "None".

Parallel branches - an example

The above image shows two parallel branches whose "synchronized" property is set to "true". The reason being, both the branches set the "CityCode" value, hence the use of shared data.

The message assignment shape "Assigning 10" has the following lines of code:

OutputXMLMessage = InputXMLMessage;
OutputXMLMessage.CityCode = 10;

The message assignment shape "Assigning 20" has the following lines of code:

OutputXMLMessage = InputXMLMessage;
OutputXMLMessage.CityCode = 20;

Code walkthrough

Line 1: The InputXMLMessage is assigned to OutputXMLMessage.

Line 2: The property CityCode is set to "10" and "20" respectively.

An error message appears, if the synchronized property is not set:

'OutputXMLMessage': if shared data is updated in a parallel 
then all references in every task must be in a synchronized 
or atomic scope

Timeouts

  1. If the orchestration's transaction type is set to 'Atomic', then the default timeout value is 60 seconds. In this case, the time out value is an Int64 value.
  2. If in the scope shape the transaction is 'Long Running', then the TimeoutException is thrown when the set timeout expires. In this case, the timeout value needs to set using:
    new System.Timespan(1,0,0,0);
  3. If in the scope shape the transaction is 'Atomic' and timeout occurs, it is considered as an attempt failed.

Quick orchestration takeaways

  1. A parallel branch need not have a scope if the orchestration 'Transaction Type' = "none" and if no variable is being shared across the branches.

License

This article, along with any associated source code and files, is licensed under The Code Project Open License (CPOL)

Share

About the Author

Naveen Karamchetti
Architect AT&T Wi-Fi Services
United States United States
Naveen has done his Masters (M.S.) in Computer science, has started his career programming the mainframes and now has more than a decade of programming, development and design experience. Naveen has a sharp eye and keen observation skills. Naveen has worked for several companies and strived hard to build large scale business applications and bringing better solutions to the table.
Quite recently Naveen has built a fairly complex integration platform for a large bank. His hobbies include training, mentoring and research. Naveen spends his free time visiting National Parks nationwide.
 
Naveen has developed the BizTalk Control Center (BCC)
http://biztalkcontrolcenter.codeplex.com

Comments and Discussions

 
Questionisolation types PinmemberWael Al Wirr13-Apr-11 22:46 
AnswerRe: isolation types PinmemberWael Al Wirr13-Apr-11 23:00 
QuestionParallel Branching Related PinmemberHari Panda18-Jun-07 6:21 
AnswerRe: Parallel Branching Related PinmemberNaveen Karamchetti18-Jun-07 8:58 
GeneralDefault Timeout for Long Running Transaction PinmemberKarthikcse14-Mar-07 21:03 
GeneralRe: Default Timeout for Long Running Transaction PinmemberNaveen Karamchetti15-Mar-07 3:12 
GeneralNice Article Pinmember_ABHILASH_MS_22-Mar-06 0:17 
Good to see more biztalk authors in code project.
Man you are on rampage an article a day ! Keep going !
 
www.abhilash.in
www.biztalkcafe.com
http://biztalkland.blogspot.com

General General    News News    Suggestion Suggestion    Question Question    Bug Bug    Answer Answer    Joke Joke    Rant Rant    Admin Admin   

Use Ctrl+Left/Right to switch messages, Ctrl+Up/Down to switch threads, Ctrl+Shift+Left/Right to switch pages.

| Advertise | Privacy | Mobile
Web02 | 2.8.140922.1 | Last Updated 14 Mar 2006
Article Copyright 2006 by Naveen Karamchetti
Everything else Copyright © CodeProject, 1999-2014
Terms of Service
Layout: fixed | fluid