Allied Consultants - Training on BizTalk orchestrations (1 of 2)

BizTalk Orchestrations
Wajih Arshad

Orchestrations: What they are?
 BizTalk provides application integration as well as
support for business process implementation
 Orchestration is BizTalk’s way to implement a business
process/workflow.
 Orchestrations help transforming messages from one
application into formats expected by other applications

Orchestrations: How they help?
 Orchestrations are visual implementations of business
workflows, and can help business analysts work with
programmers
 Orchestrations can help automate long business
processes which may span even on weeks
 Orchestrations are defined separate from data, and can
adopt to changes in business processes
 Orchestrations support usual programming constructs,
and can also use .NET assemblies for complex modules

Orchestration Life
 Started
 Hydrated/Re-hydrated, Dehydrated
 Completed, Suspended, Terminated

Orchestration States
 Deployed
 Bind
 Enlist
 Start
 Stop
 Unenlist
 Unbound
 Undeployed

BizTalk Ports
 Logical ports: Ports in an orchestration
 Physical ports: Ports which interface with
adapters (and send/receive locations)
Logical ports are bound with physical ports
during orchestration binding

Orchestration Port Bindings
 Specify Now
Specify physical port configuration while designing logical port
 Specify Later
Design logical port, but leave binding for later
 Direct Binding
Bind one orchestration with another through logical ports.
Avoids overhead of switching to MessageBoxDb

Property Promotion
BizTalk does not care about a message field/property
unless it is told to do so – through property promotion
 Promoted Properties
• Promoted properties can be used in expression shapes and
message routing (filters and correlations)
• Promoted properties are maintained in a “Property Schema”
 Distinguished Properties
• Distinguished properties can be used in expression shapes
and Decide shapes
• Distinguished properties are maintained in a “Message
Context” and do not require any schema (and hence are not
used in message routing)

Orchestration Message Passing
 Orchestrations communicate with message box, and
not with physical locations
 Orchestrations communicate with message box
through logical ports and pick subscribed messages
 While BizTalk can pick messages in various formats
depending upon adapters and pipelines, orchestrations
only operate on XML messages

Message Correlation
 Correlation is used to determine which instance of an
orchestration should be re-hydrated for a particular
message instance
 One or more promoted properties that can uniquely
identify a message are used to implement correlation
 Defining correlation requires:
• Property promotion
• Defining Correlation Type
• Defining Correlation Set from Correlation Type
• Initializing Correlation Set
• Following Correlation Set

Calling Orchestrations
An orchestration can be launched from another orchestration.
Orchestrations can pass parameters to other orchestrations.
Parent=Caller Orchestration; Child=Called Orchestration
 CALL Orchestration
• Parent can launch child orchestration synchronously -- parent
waits for child to return/complete
• Parent is maintained in memory and is not dehydrated
• Parent fails if the child fails
 START Orchestration
• Parent can launch child orchestration asynchronously – parent
does NOT wait for child to return
• Parent can be dehydrated or even removed from memory
independent of child
• Parent may still succeed even if the child fails

BizTalk Transactions
Two types of transactions:
 Atomic Transactions
ACID (Atomic, Consistent, Isolated, Durable) Transactions
Feasible when resource locks must be released as soon as
possible
 Long-running Transactions
For business processes that may take long (even days or weeks)
Provided to handle situations where resources cannot remain
locked over long periods

Atomic Transactions
 Cannot nest other transactions (Atomic or Long Running)
 Do not need Exception Handling (faults result in
automatic retries and rollbacks)
 Actions taken in Send, Receive and Start Orchestration
shapes do not take place until the transaction commits
 The message delivered to Atomic transaction is not
removed from message box
 Cannot have double-action Send/Receive
 Only Atomic Transactions allow use of non-Serialized
components

Long Running Transactions
 Ensure Consistency and Durability only
 Can have other transactions nested
 Exception handling must be explicitly done
 The message delivered to Long Running Transaction is
removed from message box
 All components must be Serialized (as Orchestration
may require hydration during transaction)

Atomic Transactions: Isolation Levels
 Serializable
• Default Level
• Ensures concurrent transactions are blocked from making changes to
data being used
 Read Committed
• Data “Writes” in one transaction cannot be read in a concurrent
transaction. Changes are only read when transactions commit
 Repeatable Read
• Provides least protection
• Transactions must acquire locks on shared data in order to change it.
• Transaction can read data before a concurrent transaction commits
• If a transaction reads data and then other locks and changes it, the
change will not be visible to first until it reads that again

Orchestrations as Web Services
 Orchestrations can consume web services
• Web Service to be consumed is added as a “Web Reference”
• SOAP adapter is used to communicate with consumed web service
 Orchestrations can be exposed as web services
• BizTalk’s Web Services Publishing Wizard is used
• Wizard creates an ASPX page and associated site to expose
orchestration as web service

Allied Consultants - Training on BizTalk orchestrations (1 of 2)

More Related Content

Similar to Allied Consultants - Training on BizTalk orchestrations (1 of 2) (20)

More from Allied Consultants (20)

Recently uploaded (20)

Allied Consultants - Training on BizTalk orchestrations (1 of 2)