Blog Post

Biztalk
Orchestrations
Muhammad Omer 0 Comments

BizTalk: Thoughts on Orchestrations, Messaging, Workflows, BPM

  1. Provisioning: An information worker can package information needed by other participants in a business process into a seed package.
    Seed created by hub system can contain a broad range of things, including BizTalkServer_Overviewassemblies from orchestrations, BAM views, and BAM activities, a profile for system generating the package.
    After a system receivies a seed package, its administrators can deploy it, and then return seed package of its own that contains its profile.
  2. Scalibility: BP may run for a seconds, or a few months. This is where biztalk derives its capability from, i.e. it persists BPs that are idle or waiting for  messages into sql and retrieves them when appropriate.
  3. Property promotion: is used to extract property value from xml document using XPath expression and placed on message context so that it can be used for message routing ( needs to have default or fixed value ).
    An xml message can include zero or more envelopes. It includes field values for property promotion and demotion. Can combine several xml docs into a single interchange.
  4. Hosts: can be marked as ‘authentication trusted’, biztalk will trust security related info.
    – Hosts load schemas from assemblies into memory, to validate xml document e.g in pipeline, if you change any schemas, make sure that you bounce the host, otherwise, you will keep getting same error as before, no matter what you do.
  5. Maps in Ports: If the only business logic is to do some mapping, then it’s better to use ‘inbound’ and ‘outbound’ map property of receive pipeline.
  6. Long-Running Orchestration: It is important for long-running orchestration to keep track of its state and to report errors as they occur, so that you can resolve problem accurately. Long-running transactions possess consistency and durability, but not atomicity and isolation.
  7. Scope: is a framework for grouping actions. It’s primarily used for transactional execution and exception handling. You can’t nest a transactional scope within a scope/orch that is not transactional. By synchronizing a scope, you ensure that any shared data that is accessed within it will not be written to by one or more parallel actions in your orchestration, Atomic orchestrations are always synchronized. Actions in compensation handler are not synchronized. Scopes can be nested inside each other upto 44 levels.
    Each scope is represented at runtime by scope context object, and each variable declared at scope level is represented by an internal field of that class.
    Outer scope variables are copied at runtime to inner scope, but essentially every scope has his own copy of variables.
  8. ConstructMessage: You can only modify message that you specify as “Message Constructed”.
  9. Messages: Every Message in reality is a multi-part message, and biztalk insists that it should have at least one part ( designated as body part ), but makes an exception for web messages, but one would still need to create an empty message, this will can be easily done by construct message shape.
    – Messages are immutable, only to be altered in construction block.
  10. Message in Orchestration: Within an orchestration, biztalk uses Microsoft.XLANGs.BaseTypes.XLANGMessage to represent individual messages and Microsoft.XLANG.XLANGPart  to represent individual parts of that message.
  11. Message Types: Message can of three types; .NET classes, schemas and multi-part messages ( web messages are in reality multipart message used in conjunction with SOAP-based web services ).
    1. Schemas is essentially a multi-part message but just with one part, but this part is not visible, when you assign things to the message, it is going to the part.
    2. Multipart messages must have at least one part designated as ‘body’ part ( this rule is relaxed for web messages ). Which part is body-part, might be a non-issue for orchestrations, but certainly becomes a problem when message is passed through a pipeline, where it is accessed by IBaseMessage interface.
  12. External Assembly: If you want to call an assembly from biztalk, just add reference to biztalk project, and call it in an expression shape.
  13. Correlation:
    – It is used whenever an orchestration doesn’t have an explicity way of determining or separating different msgz. Correlation relate msgz on basis of properties defining correlation type.
    – Correlation set is an instance of correlation type, which is initialized by a receive. It contains values with the properties, unlike correlation type, which just contains properties.
  14. Convoy: Convoys are group of related msgz that intended to be handled in specific order within orchestration.
    – Biztalk detects a convoy when orchestration is enlisted. At this point, an entry is inserted into ConvoySets table inside MsgBox that lists properties used in convoy set. Every time a msg comes, it is checked, if it is part of convoy or it should start a convoy. If it should start a Convoy, an entry is inserted into the ConvoySetInstances table that routed messages to the correct instance.  If it is part of an existing Convoy (i.e. it has the sample Convoy properties of an existing Convoy set), it is routed to the Service Instance listed inside the table. This database level message routing creates a type of virtual subscription on top of the standard subscriptions inside the message box.  This is set up internally using a series of tables.

Related Posts

♥2

Author

Muhammad Omer

Muhammad Omer is the founding partner at Allied Consultants. Areas of interest for him are entreprenuership in organizations, IT Management, Integration and Business Intelligence.