|
Home > Archive > BizTalk Server Orchestration > October 2005 > Routing a message dynamically in the orchestration?!
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 |
Routing a message dynamically in the orchestration?!
|
|
|
| Hi all,
Currently, we have a single main project containing all of our
orchestrations. This project has references to all of other different
projects. the reason behind that was because each project is mapping or
doing something differently to send a message out. (i.e. A project per
client).
The normal process for the main orchestration is that it receives a message
from our central database and then it goes through many Decide shapes in
order to route it to the correct direction usually calling or starting an
orchestration in a different project!!
We usually spend a huge amount of time and effort in changing the main
orchestration to include new client or project, deplyoment, dealing with
dependencies and dependency order issues.
The message has a promoted property which we use to route using the Decide
shapes but is there any better way(s) of routing the message without having
to undeploy, modify the orchestration and deploy again?
In other words, I would like the message received to be routed dynamically
by using a local SQL database table.
Any idea, help, links or suggestions would be highly appreciated.
Thank you very much and hope to hear your inputs very soon..
Kam
| |
| Tomas Restrepo \(MVP\) 2005-10-28, 5:03 pm |
| Kam,
> Currently, we have a single main project containing all of our
> orchestrations. This project has references to all of other different
> projects. the reason behind that was because each project is mapping or
> doing something differently to send a message out. (i.e. A project per
> client).
>
> The normal process for the main orchestration is that it receives a
> message
> from our central database and then it goes through many Decide shapes in
> order to route it to the correct direction usually calling or starting an
> orchestration in a different project!!
>
> We usually spend a huge amount of time and effort in changing the main
> orchestration to include new client or project, deplyoment, dealing with
> dependencies and dependency order issues.
>
> The message has a promoted property which we use to route using the Decide
> shapes but is there any better way(s) of routing the message without
> having
> to undeploy, modify the orchestration and deploy again?
>
> In other words, I would like the message received to be routed dynamically
> by using a local SQL database table.
What you need is to change is so that you can leave your main routing
orchestration in such a way that you don't have to touch it all the time.
One technique I've used for this is this:
1- Remove all those decide shapes from your main orchestration
2- Use the Business Rules Engine or a custom .NET component to implement
your routing rules. You can base the rules on taking the document to route
and return a routing key value
3- In your main orchestration use n. 2 to find out the routing value and use
it to promote a property on a new copy of the message
4- Use direct-bound ports to send the message from the main orchestration to
the processing orchestration using the MessageBox as intermediary. This
allows you to decouple the main orchestration from the individual process
orchestrations (and version them independently). In the other
orchestrations, use direct bound ports as well, combined with a filter
expression that uses the key value
IOW, define a key value for each processing orchestration, and then the
routing is just finding out from the message contents what key value to
promote. The rest is done automatically by the Pub/Sub infrastructure in the
message box.
You can find out more from using direct binding here:
http://geekswithblogs.net/cyoung/articles/19546.aspx
--
Tomas Restrepo
tomasr@mvps.org
http://www.winterdom.com/
| |
|
| I was thinking on the same line and I came into the idea of promoting a
field in the schema that can be used to filter the incomin message and route
it accordingly.
The idea I had is to utilise the receive port that is used to retrieve the
messages from the database and then create a send port for each destination
and a Send Port Group to add all send ports and specify their filter
properties to the promoted property in the schema.
I haven't tested the above yet but I think it should work.
Any inputs are welcome.
Thank you.
Kamal
"Tomas Restrepo (MVP)" <tomasr@mvps.org> wrote in message
news:uufupB82FHA.1420@TK2MSFTNGP09.phx.gbl...
> Kam,
>
an[vbcol=seagreen]
Decide[vbcol=seagreen]
dynamically[vbcol=seagreen]
>
> What you need is to change is so that you can leave your main routing
> orchestration in such a way that you don't have to touch it all the time.
>
> One technique I've used for this is this:
> 1- Remove all those decide shapes from your main orchestration
> 2- Use the Business Rules Engine or a custom .NET component to implement
> your routing rules. You can base the rules on taking the document to route
> and return a routing key value
> 3- In your main orchestration use n. 2 to find out the routing value and
use
> it to promote a property on a new copy of the message
> 4- Use direct-bound ports to send the message from the main orchestration
to
> the processing orchestration using the MessageBox as intermediary. This
> allows you to decouple the main orchestration from the individual process
> orchestrations (and version them independently). In the other
> orchestrations, use direct bound ports as well, combined with a filter
> expression that uses the key value
>
> IOW, define a key value for each processing orchestration, and then the
> routing is just finding out from the message contents what key value to
> promote. The rest is done automatically by the Pub/Sub infrastructure in
the
> message box.
>
> You can find out more from using direct binding here:
> http://geekswithblogs.net/cyoung/articles/19546.aspx
>
>
> --
> Tomas Restrepo
> tomasr@mvps.org
> http://www.winterdom.com/
>
>
| |
|
| I have had a similar situation before and I struggled with this...
Suppose you want to collect responses from all the child orchestrations and
create a single combined response message in the master Orchestration - how
would you do that? Using correlation? Wouldn't that degrade performance?
If you are using direct binding - the flow becomes asynchrounous isn't it?
"Kam" wrote:
> I was thinking on the same line and I came into the idea of promoting a
> field in the schema that can be used to filter the incomin message and route
> it accordingly.
>
> The idea I had is to utilise the receive port that is used to retrieve the
> messages from the database and then create a send port for each destination
> and a Send Port Group to add all send ports and specify their filter
> properties to the promoted property in the schema.
>
> I haven't tested the above yet but I think it should work.
>
> Any inputs are welcome.
>
> Thank you.
>
> Kamal
>
>
>
>
> "Tomas Restrepo (MVP)" <tomasr@mvps.org> wrote in message
> news:uufupB82FHA.1420@TK2MSFTNGP09.phx.gbl...
> an
> Decide
> dynamically
> use
> to
> the
>
>
>
| |
| Tomas Restrepo \(MVP\) 2005-10-29, 2:48 am |
| RKris,
>I have had a similar situation before and I struggled with this...
>
> Suppose you want to collect responses from all the child orchestrations
> and
> create a single combined response message in the master Orchestration -
> how
> would you do that? Using correlation? Wouldn't that degrade performance?
It's one possible way.
>
> If you are using direct binding - the flow becomes asynchrounous isn't it?
Not necessarily, You can use Direct-binding with request/response ports,
making it much easier to just have the main orchestrations wait for the
smaller ones to finish. One way direct bound ports and correlations work
just fine, as well (that's actually what biztalk does underneath for a two
way port, I think, anyway)
--
Tomas Restrepo
tomasr@mvps.org
http://www.winterdom.com/
|
|
|
|
|