Convoy Processing in BizTalk Orchestration

Document Sample
Convoy Processing in BizTalk Orchestration Powered By Docstoc
					Convoy Processing in BizTalk
       Orchestration
What is a Convoy?
     Party1:                Party2:              Party3:
     Broker1                 Bank                Broker2




                     DepositMsg: TXN=1023




StockMsg: TXN=1023         Clearing         StockMsg: TXN=1023
                            House




                          TXN:1023
          Convoy Definition
A message may contain a field, or set of fields,
whose values identify it as a member of a group
of related messages, for example a unique PO
number, or a SSN. A convoy scenario is one in
which:
– The values are not known before the arrival of the first
  message. That is, the first messages "defines" the
  group.
– Succeeding messages in the group may arrive before
  any further processing or synchronization takes place.
– All messages in the group must be processed by the
  same handler.
Scenarios Supported by BizTalk:
        Parallel Convoy
– The messages may be of different types. There is no
  defined order in which the messages are expected to
  arrive. The handler accepts them in any order and
  may process them in parallel.
– Clearinghouse example.
     Parallel Convoy Restrictions
1.   If one of the tasks of a parallel has an activatable
     receive as the first shape, all of the tasks of that
     parallel must have an activatable receive as the first
     shape and all of these receives must initialize at least
     one correlation.
2.   If a particular correlation is initialized on more than one
     task of a parallel by a receive, each of the concerned
     receives must initialize exactly the same correlations.
3.   If a particular correlation is initialized on more than one
     task of a parallel by a non-activation receive, each one
     of such receives must also follow (i.e., non-initialized
     correlation reference) the same correlation set.
Scenarios Supported by BizTalk:
  Uniform Sequential Convoy
– The messages are all of the same type from the same
  party. There is no defined order to the messages. The
  handler processes them sequentially as delivered.
– Streaming example.
Scenarios Supported by BizTalk:
Non-Uniform Sequential Convoy
– The messages, all from the same party, may be of
  different types; however the order in which the
  messages are expected to arrive is predefined. The
  handler processes them in the expected order.
– Heath care example.
                       Convoy Set
• A Convoy-set for a particular receive shape, is the set of
  correlation sets that are initialized by another receive
  shape and followed by this particular receive shape.
   – Any correlation set that is being followed by a send shape
     (chronologically) prior to the particular receive shape is not
     considered as a part of the Convoy-Set.
       • This caveat in in-place more because of limitation of the current
         implementation rather than any other semantic concerns. The
         problem being that given a single service it is impossible to detect
         whether convoy processing would be required in such cases – it can
         really be totally determined after looking at the partner service and
         examining the protocol. This is a useful warning to provide so that
         the user can examine the program & the protocol and take
         corrective action. (Warning 4014)
    Sequential Convoy Semantic
              Checks
1. All the correlation sets that constitute a Convoy
   Set for a particular receive shape must be
   initialized by one and only one preceding
   receive shape.
2. The port for a particular receive shape, that
   requires convoy processing, must match the
   port for the receive shape initializing the
   convoy set.
3. If a sequential convoy is initialized by an
   activate receive, then the follower receives
   cannot be inside a service called from the
   activated service.
     Additional Semantic checks for
      Uniform Sequential Convoys
1.   Message types being received for a particular receive
     shape, requiring convoy processing, must match the
     message type for the receive shape initializing the
     convoy set unless the receive shape is operating on an
     Ordered Delivery port.
2.   All receives participating in a particular sequential
     Convoy must follow all the correlation sets that are
     initialized (or followed) by the initializing receive unless
     operating on an Ordered Delivery port.
3.   If a sequential convoy is initialized by an activate
     receive, then the activate receive cannot have a filter
     expression unless operating on an Ordered Delivery
     port.
      Associated Orchestration Build
             Error Messages
•   ERROR 2257: if a parallel has an activatable receive then all its' tasks must be
    activatable
•   ERROR 2022: a sequential convoy which is initialized by an activate receive may not
    call or compensate a service with a receive participating in the convoy.
•   ERROR 2258 : in a sequential convoy receive all correlations must be initialized in a
    single receive
•   ERROR 2259 : in a sequential convoy receive the ports must be identical
•   ERROR 2260 : in a sequential convoy receive the messagetypes must be identical
    unless the port is marked for OrderedDelivery
•   ERROR 2261 : in a parallel convoy receive the correlations must be identical
•   ERROR 2262 : a parallel activate receive convoy must initialize correlations
•   ERROR 2263 : in a sequential convoy receive there cannot be an activation filter
    unless the port is marked for OrderedDelivery
•   ERROR 2264: in a sequential convoy receive the correlations must be identical
    unless the port is marked for OrderedDelivery

•   WARN 4014: convoy processing will not occur -- check your protocol if you were
    expecting it
Questions?