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

[ Post a follow-up to this message ]

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

[ Post a follow-up to this message ]

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...br />
93ed7149

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 a
re
> delivered in the correct sequence.  But our companies preferred architectu
re
> 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 succe
ss
> 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

[ Post a follow-up to this message ]

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... />
8093ed7149
>
> Cheers,
>
> Alan
>
>
>
>
> "Rob Baines" wrote:
> 

[ Post a follow-up to this message ]