|
Home > Archive > BizTalk Server Orchestration > August 2005 > Stopping BizTalk from 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 |
Stopping BizTalk from Orchestration
|
|
|
| I have a termination shape in my orchestration. I look for value in error
node and if it is true then I terminate processing of this message. But if
the messages are getting terminated sequentially then that means there is
some problem like non-availability of Database. Under this circumstances (if
10 messages are failed in sequential order) then I wish to stop the BizTalk
Services so that the rest of the messages may be processed after Database is
restored.
Can we do this?
May Gurus please reply?
Thanks,
RR
| |
| Jon Flanders[MVP] 2005-08-04, 5:56 pm |
| I wouldn't stop the process - I'd stop the orchestration using WMI. As long
as the orchestration is enlisted - the messages will queue up in the message
box until the orchestration is stopped.
--
Jon Flanders
http://www.masteringbiztalk.com/blogs/jon/
"RR" <RR@discussions.microsoft.com> wrote in message
news:43E618EA-306B-4114-BC07-4FDA65545411@microsoft.com...
>I have a termination shape in my orchestration. I look for value in error
> node and if it is true then I terminate processing of this message. But if
> the messages are getting terminated sequentially then that means there is
> some problem like non-availability of Database. Under this circumstances
> (if
> 10 messages are failed in sequential order) then I wish to stop the
> BizTalk
> Services so that the rest of the messages may be processed after Database
> is
> restored.
> Can we do this?
> May Gurus please reply?
>
> Thanks,
> RR
| |
|
| Thanks Jon.
Exactly.
Stopping orchestration is more appropriate than stopping the BizTalk Service.
I think I can call an object and its method ( that consists of WMI code to
stop Orchestration) from an expression shape ?
However, what problems should I anticipate by stopping orchestration this
way.
Any other better way of doing?
Thanks,
RR.
"Jon Flanders[MVP]" wrote:
> I wouldn't stop the process - I'd stop the orchestration using WMI. As long
> as the orchestration is enlisted - the messages will queue up in the message
> box until the orchestration is stopped.
>
>
>
> --
> Jon Flanders
> http://www.masteringbiztalk.com/blogs/jon/
>
> "RR" <RR@discussions.microsoft.com> wrote in message
> news:43E618EA-306B-4114-BC07-4FDA65545411@microsoft.com...
>
>
>
| |
| Jon Flanders[MVP] 2005-08-04, 5:56 pm |
| to stop incomign messages coming in to the messagebox you'd have to stop the
service - I think that is the best thing to do.
--
Jon Flanders
http://www.masteringbiztalk.com/blogs/jon/
"RR" <RR@discussions.microsoft.com> wrote in message
news:7FA32D47-8907-4E1E-9340-E6C96A5CCDD6@microsoft.com...[vbcol=seagreen]
> Thanks Jon.
> Exactly.
> Stopping orchestration is more appropriate than stopping the BizTalk
> Service.
> I think I can call an object and its method ( that consists of WMI code to
> stop Orchestration) from an expression shape ?
> However, what problems should I anticipate by stopping orchestration this
> way.
> Any other better way of doing?
>
> Thanks,
> RR.
>
> "Jon Flanders[MVP]" wrote:
>
| |
|
| John,
I got your point that by stopping orchestration, subscription failures may
occur as messages still will be entering into messagebox. may be I should
disable the receive port using WMI so that other orchestrations continue to
work.
Thanks for the information.
RR
"Jon Flanders[MVP]" wrote:
> to stop incomign messages coming in to the messagebox you'd have to stop the
> service - I think that is the best thing to do.
>
> --
> Jon Flanders
> http://www.masteringbiztalk.com/blogs/jon/
>
> "RR" <RR@discussions.microsoft.com> wrote in message
> news:7FA32D47-8907-4E1E-9340-E6C96A5CCDD6@microsoft.com...
>
>
>
| |
| Stephen W. Thomas 2005-08-04, 5:56 pm |
| Hello.
If you suspend the Orchestation the messages will continue to be routed via
the Convoy to the Orchestation instance but not be processed until you resume
your process. Only problem is if you terminate the Orchestation the messages
... well.. are still around just you have to look for them in HAT.
Another approach would be to use a logical “Continue To Process” indicator
inside your Orchestation. That is, when you detect your stop conditions you
set this bProcess to False. When bProcess is false, you send messages to a
file (or anyplace) for reprocessing later. In the past, I have appended a
sequence number on the message so I know the order. Reprocessing of these
messages was done via a 2nd Orchestation. You can even build in automated
process to change bProcess back to true when the conditions are right.
If you are using an adapter that isn’t synchronous on the client site (i.e.
like MQ, File, MSMQ) stopping the Receive process would be a great way to go
since the messages will queue up until the Receive Process resumes. In my
case, we were using HTTP Posts so we did not want to client to fail when our
backend system was down.
Hope this helps.
Stephen W. Thomas
http://www.biztalkgurus.com
"RR" wrote:
[vbcol=seagreen]
> John,
> I got your point that by stopping orchestration, subscription failures may
> occur as messages still will be entering into messagebox. may be I should
> disable the receive port using WMI so that other orchestrations continue to
> work.
>
> Thanks for the information.
> RR
>
> "Jon Flanders[MVP]" wrote:
>
| |
|
| Stephen,
We are using File adapter and hence stopping the receive process is a good
option.
Thanks for your information.
RR.
"Stephen W. Thomas" wrote:
[vbcol=seagreen]
> Hello.
>
> If you suspend the Orchestation the messages will continue to be routed via
> the Convoy to the Orchestation instance but not be processed until you resume
> your process. Only problem is if you terminate the Orchestation the messages
> .. well.. are still around just you have to look for them in HAT.
>
> Another approach would be to use a logical “Continue To Process” indicator
> inside your Orchestation. That is, when you detect your stop conditions you
> set this bProcess to False. When bProcess is false, you send messages to a
> file (or anyplace) for reprocessing later. In the past, I have appended a
> sequence number on the message so I know the order. Reprocessing of these
> messages was done via a 2nd Orchestation. You can even build in automated
> process to change bProcess back to true when the conditions are right.
>
> If you are using an adapter that isn’t synchronous on the client site (i.e.
> like MQ, File, MSMQ) stopping the Receive process would be a great way to go
> since the messages will queue up until the Receive Process resumes. In my
> case, we were using HTTP Posts so we did not want to client to fail when our
> backend system was down.
>
> Hope this helps.
>
> Stephen W. Thomas
> http://www.biztalkgurus.com
>
>
> "RR" wrote:
>
|
|
|
|
|