|
Home > Archive > BizTalk Server Orchestration > March 2006 > dynamic calling of orchestrations based on message data
You are viewing an archived Text-only version of the thread.
To view this thread in it's original format and/or if you want to reply to
this thread please [click here]
| Author |
dynamic calling of orchestrations based on message data
|
|
| rnorthedge@hotmail.com 2006-03-08, 5:53 pm |
| I wonder if anyone could help me with this question about Biztalk 2004.
Would it be possible to take all my messages into a master
orchestration, but then route off to a dynamically chosen child
orchestration based on the contents of an element in the message data?
So the message would come in with an element like
<orchestration_to_call>OrchestrationA</orchestration_to_call>, and it
would be routed to the orchestration named "OrchestrationA". And if I
created a new OrchestrationB, and changed the XML in the incoming
message to OrchestrationB instead, I could get the message to route to
OrchestrationB without altering the master orchestration?
Thanks for any help,
Richard
| |
| ashok.sandya@gmail.com 2006-03-08, 5:53 pm |
| I can think of a couple of ways to do this, not sure if there is a
better way -
1) Expose Orchestration A and Orchestration B as web services and then
you can decide to call either one using a Decide shape in your master
orchestration.
2) The master orchestration can just send the message directly to the
message box using Direct binding, Orchestration A and Orchestration B
will subscribe to the messagebox and they will have a filter to pick up
the message they need from the messagebox.
| |
| Greg Forsythe 2006-03-08, 5:53 pm |
| You may not even need the master orchestration.
This can be achieved with content based routing.
You promote the orchestration_to_call element from the message into the
message context
For OrchestrationA would have a filter on the Receive shape:
MyProperties.OrchestrationName = OrchestrationA
You can declare each orchestration Receive shape to be direct or you can
bind each orchestration to the same receive port.
If a message arrives with orchestration_to_call = OrchestrationZ and there
is no OrchestrationZ you will get a Routing Failure.
If the master orchestration is required for some common pre-processing, the
same result can be achieved using direct ports in the send and receive
orchestration and promoting the same element. Although there is a trick to
promoting the element when sent from an orchestration. You need to define a
correlation set using this property and initialize the correlation on the
send shape of the master orchestration.
Greg
<rnorthedge@hotmail.com> wrote in message
news:1141833864.303373.151680@p10g2000cwp.googlegroups.com...
>I wonder if anyone could help me with this question about Biztalk 2004.
> Would it be possible to take all my messages into a master
> orchestration, but then route off to a dynamically chosen child
> orchestration based on the contents of an element in the message data?
> So the message would come in with an element like
> <orchestration_to_call>OrchestrationA</orchestration_to_call>, and it
> would be routed to the orchestration named "OrchestrationA". And if I
> created a new OrchestrationB, and changed the XML in the incoming
> message to OrchestrationB instead, I could get the message to route to
> OrchestrationB without altering the master orchestration?
>
> Thanks for any help,
> Richard
>
| |
| rnorthedge@hotmail.com 2006-03-10, 7:53 am |
| Thanks for the responses - they have given me some ideas, which I will
investigate.
My master orchestration will need to be called from a web service (this
will be the external interface for the whole thing). Incoming messages
may sometimes require a synchronous response, so the whole business of
pre-processing, handing off to a chosen child orchestration based on
message data, getting a result back and passing that out of the master
orchestration would have to happen synchronously. In other cases, the
same thing might happen asynchronously. I was assuming that any
MessageBox based routing wouldn't be possible because of the need to
sometimes work synchronously.
Anyway, thanks again - we will see what happens.
Richard
|
|
|
|
|