July 31, 2006 at 9:13 PM #14072
I have a NON-UNIFORM sequential convoy scenario with 2 MSGs.
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.
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
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)
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\”.
Why doesn’t MSG B set a correlation set instance and waits for the
corresponding MSG A?
I hope to hear from you.
August 3, 2006 at 3:51 PM #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
>From what read in the documentation this would be possible.
August 8, 2006 at 4:12 PM #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.
August 9, 2006 at 3:30 PM #14075
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.
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?
August 2, 2006 at 5:14 AM #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.
August 4, 2006 at 6:32 PM #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.
August 9, 2006 at 1:05 AM #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.
August 9, 2006 at 3:19 PM #14079
Ordered delivery is a 2006 feature, correct? I think Fililpe is using 2004.
August 9, 2006 at 3:22 PM #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?
August 9, 2006 at 5:11 PM #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
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.
- The forum ‘BizTalk 2004 – BizTalk 2010’ is closed to new topics and replies.