- This topic has 2 replies, 1 voice, and was last updated 7 years, 3 months ago by
.
-
Posts
-
-
Hey! Need some urgent assistance please! In our Biztalk farm environment, we have an orchestration (sequential convoy pattern). The correlation ID initialized on the Receive shape is on the OrderID. As expected, Biztalk spawns as many orchestration instances as the unique order ids in the inbound file. After processing, the orchestrations sends the files to a destination. we have set Ordered delivery on the physical send port. What we observe is there is only instance of the send port getting created and hence sending the files takes a lot of time? we need ordered delivery only for a particular OrderID and not for the complete input file i.e. there should be as many sendport instances as the orchestration instances. any thoughts on how we can do this?
-
The sendport is separated from the orchestration by a pub/sub database. It is subscribing to messages with a particular BTS.SPTransportID ( when you bind your port to the orchestration, the orchestration will add this property to outgoing messages on this logical port). If you set Ordered Delivery then only one instance of this port will be initiated to guarantee messages are sent in order. There is no way of making the sendport convoy (or orchestration instance) aware that I know of.
One possibility is to reset the ordered delivery option on the physical port and use Delivery Notification on the logical port. This will cause the orchestration to block on sending a message until it has been delivered, hence guaranteeing order by orchestration instance. Not sure what this will do to overall performance? Might make it better or worse depending on where the message is going, how it is getting there (adapter being used) and what sort of latency there is.
Can you explain a bit about the orchestration and why it is a sequential convoy, how many messages does each orchestration instance consume and how many messages does each instance send. Is there another way of doing this that does not involve a sequential convoy?
-
Hello ,
thanks for the response.the process followed:
a flat file comes in containing orders.
in a given flat file there could be Order created rec, order modififed rec etc.
for e.g the first rec could be order create and the 10th rec in the flat file could a mod on the same order.
we want the same orchestration to process so that mod does not happen
before create. so only we thought of sequential convoy..as i said, orchestration is correlated onOrder ID.
Regards,
-
-
- The forum ‘BizTalk 2004 – BizTalk 2010’ is closed to new topics and replies.