Sequential Processing of Normal Flow as well as Error Flow RRS feed

  • Question

  • All,

    I am designing a BizTalk solution which has 90+ interfaces spawning 8-9 systems.

    Requirement of Client is that BizTalk should process all the requests in FIFO model.

    Client also wants that failed messages to be stored in sql table and reprocessed in sequence.

    Traffic is not very high 4-5 messages per second.

    Please highlight if any special consideration I have to make while designing this solution.



    Tuesday, May 26, 2015 2:42 PM

All replies

  • Do the failed messages have to be processed in order relative to each other or should a failed message stop all processing?

    Tuesday, May 26, 2015 3:19 PM
  • OK Sorry ! Forgot to point that sequence needs to be maintained within interface only in normal as well failed scenario.

    And to answer your question.....failure should not stop all processing...only the failed message should be logged to sql table

    For interface 1 for example 2 messages failed

    Msg1 Interface1 seqnum1

    Msg2 Interface1 seqnum2

    So when I am re-processing from sql table, Msg2 cannot be processed until Msg1 is successfully processed.

    Tuesday, May 26, 2015 4:04 PM
  • hi Vikingss,

    As per me, I don't really worry about the seq num.. Use a kind of identity column that will keep on generating numbers. This usually expires(reaches upper limit) only after a few years. When retrieving you can get the ascending order for that particular interface.

    You might have already planned to use the sequential convoy in this scenario for ensuring ordered processing.

    Let us know if you have any specific issue you are facing or expect to face.

    Praveen Behara
    MCST : BizTalk Server 2006 R2, 2010

    Wednesday, May 27, 2015 2:22 PM
  • Ok, sounds simple enough.

    Using Ordered Delivery will get you probably 95% of what you need.

    As for replaying, just make sure the message are polled out of the table in the same order they were stored.  An alternative would be a queue such as MSMQ.

    Wednesday, May 27, 2015 3:00 PM
  • Yes I agree, But Downside of MSMQ would be that it does not allow flexibility to ignore a message by setting a flag. This I am able to achieve in SQL.

    And I am also pushing that all systems should communicate on MSMQ or WCF Service.

    Systems like SQL and SAP will generate their own sequence number so I am good on that part.

    I am more concerned about exception handling:

    1. Uncaught excpetions Scenario may create nightmare.

    2. I am also planning to restrict resuming instances from admin console and ESB Portal.

    3. All Destination Orchs will act as Resequencer(Sequential Convoy).

    I hope I have covered everything.



    Friday, May 29, 2015 5:20 AM