none
Sequential convoy aggregator pattern issues- Duplicate messages RRS feed

  • Question

  • I use the sequential convoy integrator pattern as in : http://blog.tsathish.com/wp-content/uploads/2010/11/Orchestration.png this is for batching multiple single transaction set messages to a single file with multiple transaction sets. I follow this sample in this link: http://blog.tsathish.com/?p=154 The problem i face now while creating the batched 837 is somehow the transaction sets are getting duplicated. May be this has to do with the port configurations or batching logic that i have. Is it possible that I'm batching the same message twice? I have a receive port which gets multiple single transaction sets and send them each to a direct binded port (To msg box) and batch them after all the messages are received (by using a external trigger). Any ideas on why i end up having duplicate transaction sets is appreciated.

    Thanks!
    Ram
    • Edited by Ram36 Tuesday, December 14, 2010 1:52 AM t
    Tuesday, December 14, 2010 1:45 AM

All replies

  • Ram,

    It looks like your batch configuration has issues, can you post the filter expression for the receive port.

    Also there may be other messages already submitted for the same batch, waiting for the batch release trigger, when you release the trigger all the messages with the matching the filter expression will be batched together.


    Sathish - http://blog.tsathish.com - Please Indicate "Mark as Answer" if this Post has Answered the Question
    Tuesday, December 14, 2010 4:11 AM
  • Sathish,

    The problem I face is the same transaction sets getting duplicated, not the already submitted messages getting into the batch. The batch filter settings i have are:

    EDI.ISA06

    == XXXXXXXXX And

    EDI.ISA08

    == XXXXXXXXX And

    EDI.ST01 == 837

    The Send port's filter settings that i have are:

    EDI.DestinationPartyName =My Party  AND

    EDI.BatchName =My Batch AND

    EDI.ToBeBatched =false

    The Batch filter settings are different because they were the properties that are promoted. Let me know if this is a issue.

    Thanks!


    Ram
    Tuesday, December 14, 2010 2:45 PM
  • Do you have any other Batch set up for the same party, Also make sure you have no other receive ports submits the same file
    Sathish - http://blog.tsathish.com - Please Indicate "Mark as Answer" if this Post has Answered the Question
    Tuesday, December 14, 2010 3:17 PM
  • I have only one Batch for a particular party and I have the same party configured for producing the single transaction set 837's and the big Batched interchange with many transaction sets in it. The Send port (Physical port) that produces the single transaction files is used as a receive port for Batching. No other Receive port receives the same message. Could this be a problem with Orchestration, where I send the same message twice to the Msg box ?

    Thanks!

     


    Ram
    Tuesday, December 14, 2010 3:33 PM
  • I assume you have the Send Port that creates the Single ST-SE and the receive port for input to Batch points to the same File location. Stop the Receive port that receives the File with Single ST-SE File. Create the Single ST-SE file. Check whether Single ST-SE file has only 2 claims (as you suggested). If there are more than 2 claims then, the issue is with creating the Single ST-SE file. Else you you have to check your orchestration.
    Sathish - http://blog.tsathish.com - Please Indicate "Mark as Answer" if this Post has Answered the Question
    Tuesday, December 14, 2010 3:58 PM
  • I did check the Acknowledgement that gets created for receiving the 837's and found that there are right number of transaction sets getting generated. I did stop the receive location for the Batch process and found that it created the exact number of transaction sets it's supposed to create, just that the final Batched output had duplicates of each one of these transaction sets in it.

    Is there a easy way to debug the orchestration here? I do not get any suspended instance so that i could catch the Orchestration debugger from there.

    Thanks!


    Ram
    Tuesday, December 14, 2010 4:25 PM
  • What's the time delay you set in the orchestartion ? How many claims you have in the single ST-Se file
    Sathish - http://blog.tsathish.com - Please Indicate "Mark as Answer" if this Post has Answered the Question
    Tuesday, December 14, 2010 4:50 PM
  • Currently the delay is set to 1 min and i have less claims in my individual files --> less than 20 claims. Might have to modify the delay to be more than 40 mins for prod.

    Thanks!


    Ram
    Tuesday, December 14, 2010 5:15 PM
  • To Debug the Issue whether the orchestartion receives duplicate messages or not, place a send shape in the Orchestartion before the scope to create batched message and send the X12 Messages to a file location, If you do not have exact number of X12 Messages that you have in the single ST-SE then there is no issue with the Ocrhestartion.


    Sathish - http://blog.tsathish.com - Please Indicate "Mark as Answer" if this Post has Answered the Question
    Tuesday, December 14, 2010 5:45 PM
  • Sathish,

    I did try having a send port before the scope and pased the message to a different physical port and found that the message is getting duplicated in the Orchestration. Exactly double the number of messages are getting created for every individual message. Not sure why this is happening. Is it because of the loop logic? The listen shape has the receive shape that receives the message - it has the following correlation set being activated and the receive as such inside listen is not activated.

    Also thinking about my process the individual sets of Transactions are created in no time, all are  created almost the same time, could that be a reason? Its not like the second message came after few seconds of the first message. Am i missing something that's very basic to the convoy pattern ?

    Thanks!


    Ram
    Tuesday, December 14, 2010 7:29 PM
  • Make sure your Orchestartion First Receive Shape at top should have Activate = True and Initalizing correlation set should be set,

    While the Second receive shape inide the listen shape should have Activate = false and Following correlation should be set.

    Refer to http://msdn.microsoft.com/en-us/library/aa561843(BTS.70).aspx for Sequential Convoy Pattern


    Sathish - http://blog.tsathish.com - Please Indicate "Mark as Answer" if this Post has Answered the Question
    Tuesday, December 14, 2010 7:47 PM
  • Sathish,

    Yes, the first receive is activated and has a Initializing correlation set set to it and also the second receive in listen shape is not activated and has the following correlation set set to it. I do follow these, could the creation of correlation sets could be a problem? I downloaded your sample and followed it.

    What will happen if all the messages (Individual transaction sets) are dropped in the receive port for batching at the same time ? Will this cause the convoy to have duplicate messsages?

    Thanks!


    Ram
    • Edited by Ram36 Tuesday, December 14, 2010 8:14 PM d
    Tuesday, December 14, 2010 8:04 PM
  • Can you sent your Orchestartion Project to subscribe@tsathish.com
    Sathish - http://blog.tsathish.com - Please Indicate "Mark as Answer" if this Post has Answered the Question
    Tuesday, December 14, 2010 9:04 PM
  • Sathish,

    It's not allowed to send any code to personal id's. It's a serious security voilation and could result in irrevocable damages. So I'm left with very little choice here!! Might have to write down details as you ask!!

    Thanks!


    Ram
    Tuesday, December 14, 2010 9:34 PM
  • Ram,

    I believe the issue is not with orchestration or the Batch configuration. It may be due to File Location Polling.

    Since you have both the Send Port and receive Port configured to the same file location, there may be an overlap in the File Write and File Read Events.

    To Nail down the issue, Point Either the Send Port or the Receive location to different file location.

    Once the File is created through the Send port, copy the File manually to the Receive Location and let the orchestartion do the batching. I hope this should result in no duplicates.


    Sathish - http://blog.tsathish.com - Please Indicate "Mark as Answer" if this Post has Answered the Question
    Tuesday, December 14, 2010 10:03 PM
  • Sathish,

    I was about to try that option that you have suggested. does this : new System.TimeSpan(0,10,0) mean a time span of 10 minutes? I had this in my delay shape and looks like the orchestration is not kicking the activate batch shape even after a day...

    In real time cases there might be a chances of getting the individual 837 transaction sets once in every 10 mins, or the orchestration might need to wait for atleast 45 mins to see if nothing arrives then the activate batch can be invoked. I had set it for 10 minutes and did not get the batch even after a day...

    Thanks!


    Ram
    Wednesday, December 15, 2010 3:34 PM
  • Check whether  BatchControlMessageRecvLoc  receive location in BizTalk EDI Application is enabled .
    Sathish - http://blog.tsathish.com - Please Indicate "Mark as Answer" if this Post has Answered the Question
    Wednesday, December 15, 2010 3:39 PM
  • Sathish,

    Now I had the receive folder for the Batching to be a different folder from where the individual 837's are getting created. If i see the send port that sends the files that are got in a loop, i.e the send shape before the scope, it produces three times the number of transaction sets its supposed to produce. It was twice before and now its thrice...I'm not sure why this happens, may be I'm doing something thats wrong at a very basic level for a convoy orchestration...

    Now the the output of the batching process had twice the number of transaction sets in it and not the thrice...The send port that produces this output is a independent port and not associated with any orchestration, so to speak i do not need to bind this send port in any orchestration configuration.

    Thanks!


    Ram
    Wednesday, December 15, 2010 4:13 PM
  • I did click on the override button in the batch settings to see if any batch item that got missed in the previous batch to get created, there was no output that created by this. Guess I do not get the un processed batch into the new batch.

    Thanks!


    Ram
    Wednesday, December 15, 2010 4:22 PM
  • Ram,

    You have to understand the Sequential Convoy Orchestartion in detail, I am totally lost in understanding the details of your orchestration.


    Sathish - http://blog.tsathish.com - Please Indicate "Mark as Answer" if this Post has Answered the Question
    Wednesday, December 15, 2010 5:22 PM
  • Sathish,

    I will be able to send my orchestration project to --> subscribe@tsathish.com , is it ok?

    Thanks!

     


    Ram
    Wednesday, December 15, 2010 7:14 PM
  • Yes Go ahead and send it.
    Sathish - http://blog.tsathish.com - Please Indicate "Mark as Answer" if this Post has Answered the Question
    Wednesday, December 15, 2010 7:20 PM
  • Sathish,

    I will not be able to send all the projects in my solution, but just the Orchestration project, which will be having dependencies. I will send out a pic file that should be renamed as .zip

    Thanks!


    Ram
    • Edited by Ram36 Wednesday, December 15, 2010 8:51 PM z
    Wednesday, December 15, 2010 7:25 PM
  • Sathish,

    I could see the acknowledgement files getting into the send port that was available before the scope shape. I'm not sure why the acknowledgement files getting into this? The send port that listens to the acknowledgement files has a filter setting of the receive port that receives the individual transaction sets for batching, is that a issue here?

    Not sure of the reason that acknowledgement files are getting into the loop where we just receive the message of type 837.

    Thanks!


    Ram
    Wednesday, December 15, 2010 9:47 PM