Post Training presentation on BizTalk orchestrations (tips and tricks), part 1 of 2.
http://alliedc.com/services/eai-services/enterprise-application-integration/
2. 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
3. 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
4. Orchestration Life
Started
Hydrated/Re-hydrated, Dehydrated
Completed, Suspended, Terminated
6. 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
7. 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
8. 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)
9. 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
10. 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
11. 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
12. 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
13. 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
14. 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)
15. 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
16. 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