BizTalk Server Orchestration - resume orchestration from middle steps

This is Interesting: Free IT Magazines  
Home > Archive > BizTalk Server Orchestration > November 2005 > resume orchestration from middle steps





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 resume orchestration from middle steps
walter

2005-11-20, 5:50 pm

Hi there, we have a case that need to restart the orchestration from the
point that it fails.The situation is that we have a orch which reference 3-6
services.When one of the services fails , after the problem is fixed, we want
the orch to start from the failure point instead of running from the
beginning. This is because most of time the problem is system-related ,not
business-related.

Well , I can make the orch to check if the step has been processed in the
earlier run, but I'm wondering if there is any other way.

Any inspiration is appreciated.
Stephen W. Thomas

2005-11-21, 2:48 am

Hello.

There are a few different ways to go about it.

In the past, I have typically built this all into your main Orchestration
and had the Orchestration keep the status of that message. Then, when a
problem occurs that step is marked as error. So, when the message is
reprocessed it will only go to this step. This approach uses a convoy.
Reprocess message come in through a different port so they could be
identified. After the fact, this turned out to be a lot of overhead and
seemed to add a lot of complexity.

If I had it to do over, I would add additional optional attributes to my
message. I would keep the Orchestration stateless and un-convoyed – let the
message track status. When a process has a problem, a file would be written
to disk making it as needed. So, when it is reprocessed it would only be
sent to the required steps. Every message would do into the top of the
Orchestration and Decision shapes would be used to determine if the branch
needed to be run.

You could take this one further and separate out your different steps into
separate Orchestrations. Then, use content based routing to send messages to
each Orchestration either in order or all at once. I saw a demo doing
something like this using the Rules Engine.

Hope this helps.

Stephen W. Thomas
http://www.biztalkgurus.com
http://geekswithblogs.net/sthomas/


"walter" wrote:

> Hi there, we have a case that need to restart the orchestration from the
> point that it fails.The situation is that we have a orch which reference 3-6
> services.When one of the services fails , after the problem is fixed, we want
> the orch to start from the failure point instead of running from the
> beginning. This is because most of time the problem is system-related ,not
> business-related.
>
> Well , I can make the orch to check if the step has been processed in the
> earlier run, but I'm wondering if there is any other way.
>
> Any inspiration is appreciated.

walter

2005-11-21, 5:51 pm

Stephen, your answer is really valuable to me. I like the idea of making orch
stateless and use messagebox filter to control the flow. But this approach
lose the ability to visualize the overall biz flow. --visualization is almost
the only reason for me to accept orch concept.

"Stephen W. Thomas" wrote:
[vbcol=seagreen]
> Hello.
>
> There are a few different ways to go about it.
>
> In the past, I have typically built this all into your main Orchestration
> and had the Orchestration keep the status of that message. Then, when a
> problem occurs that step is marked as error. So, when the message is
> reprocessed it will only go to this step. This approach uses a convoy.
> Reprocess message come in through a different port so they could be
> identified. After the fact, this turned out to be a lot of overhead and
> seemed to add a lot of complexity.
>
> If I had it to do over, I would add additional optional attributes to my
> message. I would keep the Orchestration stateless and un-convoyed – let the
> message track status. When a process has a problem, a file would be written
> to disk making it as needed. So, when it is reprocessed it would only be
> sent to the required steps. Every message would do into the top of the
> Orchestration and Decision shapes would be used to determine if the branch
> needed to be run.
>
> You could take this one further and separate out your different steps into
> separate Orchestrations. Then, use content based routing to send messages to
> each Orchestration either in order or all at once. I saw a demo doing
> something like this using the Rules Engine.
>
> Hope this helps.
>
> Stephen W. Thomas
> http://www.biztalkgurus.com
> http://geekswithblogs.net/sthomas/
>
>
> "walter" wrote:
>
Stephen W. Thomas

2005-11-21, 5:51 pm

I’m not a BAM expert, but I would think you could use BAM to monitor across
multiple Orchestration calls? From that I’ve done in 2006 at least this
seems possible.

You might still want to look at isolating your separate service calls into
other Orchestrations, if you do not do so already. You could still use a
single Orchestration to control the message flow to those other
Orchestration, but at least you have the flexibility to change them or call
them from some other process if needed. In my past solution, this was
something I did not do and wish I would have.

Using a single Orchestration, you are correct that there is no easy way to
stat it in the middle.

Best of luck.

Stephen W. Thomas
http://www.biztalkgurus.com
http://geekswithblogs.net/sthomas/


"walter" wrote:
[vbcol=seagreen]
> Stephen, your answer is really valuable to me. I like the idea of making orch
> stateless and use messagebox filter to control the flow. But this approach
> lose the ability to visualize the overall biz flow. --visualization is almost
> the only reason for me to accept orch concept.
>
> "Stephen W. Thomas" wrote:
>
Sponsored Links






Free braindumps | Software forum | Database administration forum

Copyright 2003 - 2008 webservertalk.com