Home Page › Forums › BizTalk 2004 – BizTalk 2010 › Need your suggestion on this implementation
- This topic has 2 replies, 1 voice, and was last updated 8 years, 4 months ago by
community-content.
-
AuthorPosts
-
-
January 9, 2007 at 6:21 AM #17163
Hi All,
Need your suggestion on this type of implementation in Biztalk 2006
application.Scenerio:
One mqseries queue M1 receives messages of different type. Some messages are
of high priority and some are less. They wanted to create application with
multiple receive location pointing to the same queue(hope this is not
possible). They wanted this multiple receive location concept so that they
would specify "maximum messages in the batch" property to a specific number
for all the high priority messages and lesser number to the low priority one.
This would activate multiple orchestration instances based on the size so
that higher priority messages are processed faster.Implementation :
Since multiple receive location pointing to the same queue is not possible i
suggested creating a single receive location. Separate Orchestrations are
created for separate message type. I have specified the filter expression in
the receive shape to retrieve only the particular message type. In this
design how can i set multiple orchestration instance for the high priority
messages? To put it in a better way how could i configure/control the
orchestration instances?Is there any other way to implement the scenerio?
Appreciate your valuable information.
-
January 9, 2007 at 10:43 AM #17175
Anonymous,
lets see if I understood. You have one queue with messages having (let's keep it simple) two different priorities. Let's say high and low. You have two orchestrations which subscribe for messages on the queue and filter high and low messages as appropriate.
Now, your problem is to arrange that the high priority orchestrations get processed as quickly as possible, at the expense of the low priority items.
Is this correct?
One thing you don't mention is whether high priority items can interrupt already running low priority orchestrations. Anyway, assuming not, why not have a component which orchestrations ask "Can I go ahead?" Then it's very easy to tune the behaviour.
But I think the problem is that you don't really want the 'queue' behaviour – first-in, first-out. Perhaps if you have a component which is peeking at the head of the queue – if it's not high priority, then check if there is a high priority coming along and take that instead and drop that for an orchestration. Then just choke the number of orchestration instances.
I bet there's a ton of academic literature about modified queue behaviour with different priority messages!
John D.
-
January 10, 2007 at 12:18 AM #17187Hi,>>One thing you don't mention is whether high priority items can interrupt already running low priority orchestrations. Anyway, assuming not, why >>not have a component which orchestrations ask "Can I go ahead?" Then it's very easy to tune the behaviour.What do you mean by a component? Can you please explain it?Regards,-Baskar-
-
-
-
AuthorPosts
- The forum ‘BizTalk 2004 – BizTalk 2010’ is closed to new topics and replies.