NON-Uniform SEQ Convoy Issue

Home Page Forums BizTalk 2004 – BizTalk 2010 NON-Uniform SEQ Convoy Issue

Viewing 1 reply thread
  • Author
    Posts
    • #14072

      Hi,

      I have a NON-UNIFORM sequential convoy scenario with 2 MSGs.

      SCENARIO:

      MSG A – trigger message that indicates that a set of files were
      \”de-batched\” in an external application. This message contains the
      number of files that should be read.

      MSG Bs – a set of individual messages from a common batch that were
      \”de-batched\” in the external application.

      OBJECTIVE:

      The individual files (MSG Bs) are generated as soon as the
      \”de-batching\” process starts on the external application. The
      orchestration in question will only start once MSG A is generated (at
      the end of the \”de-batching process. The correlation is made of 3
      attributes.

      1 – After deployment and enlistment i check the \”ConvoySets\” table and
      a new entry is created.

      2 – I set the \”Order Delivery\” to True (i need to read first MSG A)

      ISSUE:

      During Test if i drop MSG A first, a BTS enters new record into
      \”ConvoySetInstances\” and the orchestration works fine. If I drop a MSG
      B first, i get en error \”Could not find matching subscription\”.

      $1M QUESTION:

      Why doesn’t MSG B set a correlation set instance and waits for the
      corresponding MSG A?

      I hope to hear from you.

      Thanks,

      Filipe

    • #14073

      Thanks for replying.

      The issue here is that the MSG A contains the data that will be used to
      \”grab\” the right MSG B. In other words MSG A sets the correlation for
      the consequent MSG Bs.

      If I parallel the first receive how will i be able to set the correlation?

      Mind you that this is a pattern of re-batching in which the correlation
      data is set with a different message and therefore the NON-UNIFORM
      title.

      >From what read in the documentation this would be possible.

      Thanks,

      FP

      • #14074

        Thanks for the reply.

        What do you think about this:

        1 – MSG B starts the orchestration and sets the correlation;

        2 – the orchestration stops for MSG A (that basically contains the number os MSG Bs that will have to be collected)

        3 – after MSG A is picked up, we follow the loop to pick all MSGs B accordingly to the initial correlation

        This is a variant of the NON-UNIFORM Sequential convoy where we pick a summary message (MSG A) prior to initiate the loop. This would correspond to a 3 operation port.

        • #14075

          Thanks guys.

          Actually I’m using \”order deliver\” property. That’s why i don’t understand why this scenario is not working. Order deliver should ensure a mechanism similar to a parallel convoy where if MSG B gets there first, it should be put on a table somewhere waiting for MSG A.

          To answer the other question.

          MSG A is actually correlated to MSG B so it needs to picked up first. In reality MSG A contains the batch ID and the amount of MSG B records that it will be processed. This way I’m trying to solve the scenario of knowing exactly when i have processed all MSG B files.

          $1M QUESTION
          —————–

          How does order deliver work…. REALLY? It seems to me that \”as is\” my orchestration should work. Does anyone knows the limitations of order deliver. Is it the fact that it only works for the same message type?

          Any ideas?

          Thanks,

          Filipe

          • #14076

            It’s because the first Receive for message A is set to Activate. This is the only way start the Convoy.

            If you need to have either A or B arrive first, you need a Concurrent (Parallel) convoy. I have a sample on this site under BizTalk 2004 Samples. Or you could receive the message as an Xml Document and check the message type (more work).

            Hope this helps.

            • #14077

              In your case, you have a requirement that Message A is received first. You need to ensure this happens. You will need to make sure you have order delivery enabled (see my lab on Message Debatching). Maybe you are just missing this setting on your Receive Port inside the Orchestration..

              If you can not guarantee A will arrive first you will need to build some other process to catch Message B and wait until Message A arrives. A few ways to do that – none that are very elegant.

              • #14078

                Sure, that sounds like it might work. Make sure you have Msg A and Msg B on different ports or they might get tied up behind each other.

                Now you need to make sure Message A never arrives before Message B. Let me know how it goes.

                • #14079

                  Ordered delivery is a 2006 feature, correct? I think Fililpe is using 2004.

                  Neal

                  • #14080

                    What can’t Msg-B be in a separate receive in a loop without being a convoy? Msg-A would be the activating receive, then you would loop until counter > msgA.maxMessages?

                    Neal

                    • #14081

                      Doc for: ITransportInfo.OrderedDelivery Property

                      If this property is set, then the messaging engine will guarantee that the messages will be delivered in the same order. [u:1076d36fc0]This is available only for transports supporting ordered delivery.[/u:1076d36fc0]

                      Doc for: Adding a Static Send Port Using BizTalk Explorer

                      Ordered Delivery:
                      This property is read-only, except for the [b:1076d36fc0][u:1076d36fc0]MSMQT adapter[/u:1076d36fc0][/b:1076d36fc0].
                      To guarantee ordered delivery of messages in BizTalk Message Queuing, select True from the drop-down list. This property is False and read-only for all other transports.

                      So I think maybe ordered delivery in BT2004 only works with MSMQ/MSMQT? BT2006 has much better support for ordered delivery, it’s one of the main new featuers.

Viewing 1 reply thread
  • The forum ‘BizTalk 2004 – BizTalk 2010’ is closed to new topics and replies.