|
Home > Archive > BizTalk Server Orchestration > September 2004 > Guaranteed Order of Message Delivery using webservices
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 |
Guaranteed Order of Message Delivery using webservices
|
|
| Rob Baines 2004-09-28, 8:14 am |
| Here is the scenario we are currently facing.
We have an orchestration that receives XML messages which are incremental
changes to some of our company data.
Eg. add,change, delete etc.
Message 1 = add and record;
Message 2 = change a record value x=20;
Message 3 = change a record value x=30;
.... etc.
Therefore for retaining integrity they must always be processed in arrival
sequence.
1,2,3 etc.
We have an orchestration sending these changes to another app using a web
service. When everything is running perfectly this is the case.
Message 1,2,3 etc gets processed.
However when there is a failure the messages can get out of sequence.
Eg.
Message 1 is delivered.
The web service becomes unavailable.
Message 2 fails to be delivered.
The web service becomes available.
Message 3 is delivered.
The retry mechanism on the port sends message 2 after x mins delay.
No we have processed our updates in the wrong order.
We have also implemented the solution using message queing. And messages are
delivered in the correct sequence. But our companies preferred architecture
is web services.
What I wondered was is there another alternative within an orchestration I
could use instead?
I have tried implementing the "Resequencer" EAI pattern with limited success
in an orchestration.
Are there any best practices for fault handling of web service calls?
Tighter exception handling in the orchestration, instead of relying on the
retry mechanism?
Any advice would be most appreciated.
Regards
Rob Baines
| |
| Dave Howe 2004-09-28, 5:52 pm |
| Hi Rob,
Setting the Delivery Notification property to Transmitted on the send port
within your Orchestration which handles the messages may help here. See
Kevins blog for info on ACKs and NACKs for more detail.
http://blogs.msdn.com/kevinsmi/arch.../03/172574.aspx
HTH,
Dave
This posting is provided "AS IS" with no warranties, and confers no rights.
"Rob Baines" <Rob Baines@discussions.microsoft.com> wrote in message
news:FA787365-2D61-4D5E-B8FD-4DD455EA9FDD@microsoft.com...
> Here is the scenario we are currently facing.
>
> We have an orchestration that receives XML messages which are incremental
> changes to some of our company data.
>
> Eg. add,change, delete etc.
>
> Message 1 = add and record;
> Message 2 = change a record value x=20;
> Message 3 = change a record value x=30;
> ... etc.
>
> Therefore for retaining integrity they must always be processed in arrival
> sequence.
> 1,2,3 etc.
> We have an orchestration sending these changes to another app using a web
> service. When everything is running perfectly this is the case.
> Message 1,2,3 etc gets processed.
>
> However when there is a failure the messages can get out of sequence.
> Eg.
>
> Message 1 is delivered.
> The web service becomes unavailable.
> Message 2 fails to be delivered.
> The web service becomes available.
> Message 3 is delivered.
> The retry mechanism on the port sends message 2 after x mins delay.
>
> No we have processed our updates in the wrong order.
>
> We have also implemented the solution using message queing. And messages
> are
> delivered in the correct sequence. But our companies preferred
> architecture
> is web services.
>
> What I wondered was is there another alternative within an orchestration I
> could use instead?
>
> I have tried implementing the "Resequencer" EAI pattern with limited
> success
> in an orchestration.
>
> Are there any best practices for fault handling of web service calls?
> Tighter exception handling in the orchestration, instead of relying on the
> retry mechanism?
>
> Any advice would be most appreciated.
>
> Regards
>
> Rob Baines
| |
| Alan Smith 2004-09-28, 5:52 pm |
| Hi Rob,
You could try the resequencer, or use a sequential convoy. I have created
examples of BizTalk implementations of these patterns here:
http://www.gotdotnet.com/Workspaces...6c-b28093ed7149
Cheers,
Alan
"Rob Baines" wrote:
> Here is the scenario we are currently facing.
>
> We have an orchestration that receives XML messages which are incremental
> changes to some of our company data.
>
> Eg. add,change, delete etc.
>
> Message 1 = add and record;
> Message 2 = change a record value x=20;
> Message 3 = change a record value x=30;
> ... etc.
>
> Therefore for retaining integrity they must always be processed in arrival
> sequence.
> 1,2,3 etc.
> We have an orchestration sending these changes to another app using a web
> service. When everything is running perfectly this is the case.
> Message 1,2,3 etc gets processed.
>
> However when there is a failure the messages can get out of sequence.
> Eg.
>
> Message 1 is delivered.
> The web service becomes unavailable.
> Message 2 fails to be delivered.
> The web service becomes available.
> Message 3 is delivered.
> The retry mechanism on the port sends message 2 after x mins delay.
>
> No we have processed our updates in the wrong order.
>
> We have also implemented the solution using message queing. And messages are
> delivered in the correct sequence. But our companies preferred architecture
> is web services.
>
> What I wondered was is there another alternative within an orchestration I
> could use instead?
>
> I have tried implementing the "Resequencer" EAI pattern with limited success
> in an orchestration.
>
> Are there any best practices for fault handling of web service calls?
> Tighter exception handling in the orchestration, instead of relying on the
> retry mechanism?
>
> Any advice would be most appreciated.
>
> Regards
>
> Rob Baines
| |
| Rob Baines 2004-09-29, 3:03 am |
| Thanks for the replies.
Alan I'll take a look at you resequencer solution. I was trying to use an
arraylist directly in the Orchestration but I think yours is a tidier
solution. (I also discovered orchestrations don't allow arrays in the code,
which I never knew till now)
Regards
Rob Baines
"Alan Smith" wrote:
[vbcol=seagreen]
> Hi Rob,
>
> You could try the resequencer, or use a sequential convoy. I have created
> examples of BizTalk implementations of these patterns here:
>
> http://www.gotdotnet.com/Workspaces...6c-b28093ed7149
>
> Cheers,
>
> Alan
>
>
>
>
> "Rob Baines" wrote:
>
|
|
|
|
|