Ordered Delivery with BizTalk 2016

Ordered Delivery POC Scenarios with BizTalk

BizTalk honor it. I set out to test a variety of scenarios using BizTalk’s built-in ordered delivery capabilities.

Setup:

 I exposed a BizTalk receive location (File Adapter) which receives the XML file and process it. A simple Orchestration is sending messages to WCF services, and WCF services will insert records in SQL. These WCF services publish the data to a database table, thus letting me see the exact order of messages delivered.

There are 2 WCF Services (EmpDBService & StudDBService) which is inserting records respectively. 

Scenario 1: Send port, no ordered delivery:

When a series of messages are published to the receiving location and routed to the subscriber without ordered delivery, the result may look like this:

As you can see, even on my single development machine, the order gets processed at the same time. This is due to batch processing and the multi-threaded nature of BizTalk message distribution.

  

Scenario 2: Send port, ordered delivery turned on

To turn ordered delivery on, all we need to do is check a box on the send port (this assumes that your inbound transport can deliver messages in order.

The result in the database looks like this:

3

So you can see timestamp that all the messages are inserted in order.

Scenario 3: Ordered delivery send port, “Stop sending subsequent messages on Current message failure” is Disabled and error in Stud WCF service

How about for an ordered delivery send port? What if there’s an error in the service call and also, the “Stop sending subsequent messages on Current message failure” is turned off. Check this out:

Here inserted 5 message for each service.

In Student service message 2 is failed but still, remaining messages are processed and In Employee service message 3 is failed but still, remaining messages processed.

The failed messages are suspended in BizTalk Group hub

Note: Here we are not able to resume the suspended (Non-Resumable) messages.

Scenario 4: Ordered delivery send port, “Stop sending subsequent messages on Current message failure” turned on, and error in service

What if we reproduce the previous scenario, BUT, turn “Stop sending subsequent messages on Current message failure” on? This flag can be set on the send port here:

What you’re telling BizTalk is that if any message fails for this ordered delivery port, stop processing until this error can be corrected. The result of this

Processing stopped after message #11 because message #12 failed and in second service processing stopped after message #7 because message #8 failed. The send port is still “started”, but you’ll find a suspended message. If you open it up, you’ll see that all following messages are queued up until the offender gets resolved.

Reaming messages are suspended in queue

Scenario 5: Ordered delivery send port, retries enabled, and error in service
How about for an ordered delivery send port? What if there’s an error in the service call, and retries are turned on for the port? Also, the “cancel if error” is turned off. Check this out:

The messages queue up waiting for the first one to retry, and hopefully succeed. We’ll see more of this in a moment.

Here Stud service is stopped.

After all 3 retries result for both service as below

After all 3 retries in BizTalk admin console 10 message instance suspended, 5 resumable  & 5 non-resumable.

Note 5 Non-resumable instances because of exception is not handled.

See the result after Student service is started and Resumable instances resumed.

Not able to resume the resumable instances and when try to resume getting exception

Uncaught exception (see the 'inner exception' below) has suspended an instance of service 'BTOrderedDeliveryPoc.Orch_ProcessMSG(5869f898-2830-51fa-c0c6-484381895d18)'.

The service instance will remain suspended until administratively resumed or terminated.

If resumed the instance will continue from its last persisted state and may re-throw the same unexpected exception.

InstanceId: eac1e3b2-23da-4c33-be98-d2e4d7ec4dbc

Shape name:

ShapeId:

Exception thrown from: segment -1, progress -1

Inner exception: An error occurred while processing the message, refer to the details section for more information

Message ID: {8A18CA78-CD20-402A-9894-285BFCAC0B07}

Instance ID: {3E85E45D-A9C4-46B9-84D3-BDD7985A52D3}

Error Description: System.Net.WebException: The HTTP service located at http://localhost/StudDBService/DBService.svc is unavailable.  This could be because the service is too busy or because no endpoint was found listening at the specified address. Please ensure that the address is correct and try acc

Scenario 6: Ordered delivery send port, NO retries, and error in service
this time, there’s an error in the service and no retries. Also, the“Stop sending subsequent messages on Current message failure” flag is still turned off. The result is:

So the messages still get delivered AFTER the bad message has been encountered. That’s expected, since we told BizTalk to keep going, even for the ordered delivery port.

Scenario 7: Ordered delivery send port, NO retries, “Stop sending subsequent messages on Current message failure” turned on, and error in service

What if we reproduce the previous scenario, BUT, turn“Stop sending subsequent messages on Current message failure” on? This flag can be set on the send port here:

What you’re telling BizTalk is that if any message fails for this ordered delivery port, stop processing until this error can be corrected. This is useful if you’re concerned that an “insert Emp record” message failed, but you expect an “insert Stud record” to be following. Clearly, the “insert Stud record” message will fail unless the “insert Emp” gets figured out. The result of this?

Processing stopped after message #1 because message #1 failed. The send port is still “started”, but you’ll find a suspended message. If you open it up, you’ll see that all following messages are queued up until the offender gets resolved.