none
Multiple records in MessageInOutEvents table RRS feed

  • Question

  • I have enabled tracking the message body in my receive port before the file is processed but I get two entries available in the [dta_MessageInOutEvents] table due to which the BTS.MessageId is returning the message id of the second entry for which no message tracking is available in the [Tracking_Parts1] table.

    Kindly advice how the insertion of the second entry can be avoided?

    Also there are two entries for a message in the Custom] for which no tracking is enabled.

    Kindly advice.


    Regards, Vivin.


    Monday, June 2, 2014 4:54 AM

Answers

  • You can't (and shouldn't). The tracking is there for a purpose, even though you don't need them for what you are doing right now, disabling tracking is not recommended.

    Morten la Cour

    • Marked as answer by Vivin Muthu Tuesday, June 3, 2014 4:28 AM
    Monday, June 2, 2014 1:46 PM
  •  I do not need these.. How can I remove these from inserting.

    Is this causing a problem? What you're seeing is the default behavior of BizTalk, it's the same for everyone, everywhere, all the time :)

    Again, I agree with la Cour, you could disable Global Tracking but you should not. It won't save you from having to maintain the databases and you would be eliminating a significant source of telemetry in case you needed to troubleshoot or isolate a bug.

    • Marked as answer by Vivin Muthu Tuesday, June 3, 2014 4:31 AM
    Monday, June 2, 2014 6:03 PM

All replies

  • You will get two entries in the dbo.dta_MessageInOutEvents for each instance always (status = 0 for receive and status = 1 for send). This has nothing to do with Message Tracking. 

    So even if you do not have message tracking enabled you will get these two entries. 

    The insertion could be avoided, if you disabled tracking on the Pipeline, but this is not recommended.

    Morten la Cour

    Monday, June 2, 2014 5:17 AM
  • I am using the EDIReceive pipeline and when the tracking is disabled no records is inserted but I need to insert the  record which has message body. To be simple I need to get the messageId inside the orchestration for entry which has message body tracking.

    The BTS.MessageId is returning the id of the second record '534B9E5E-E486-4247-99EF-974DDBAB5EAC' but I need to get the id 'CAC9B565-5661-4570-B721-8E66C7B24957' for which the message body is tracked.


    Regards, Vivin.

    Monday, June 2, 2014 5:57 AM
  • You can't (at least not directly), the Orchestration and it's messages has no knowledge of the Instances (Ports) that executed before the Orchestration. 

    Also like we discussed earlier, I don't think you are using the correct approach here. You cannot rely on Tracking in the Application, since tracking is an asynchronous action that happens with a delay (your EDI Pipeline Tracking may happen as late as a minute after the message actually went through the Port, which means that the Orchestration might not find anything in the Tracking_Parts table anyway). 

    Morten la Cour

    Monday, June 2, 2014 6:39 AM
  • I am not trying to get the message content as earlier in the orchestration since u told it wont be available during message processing. Instead I am now trying to get the corresponding message Id and store it so that I can use later to get the body of the message.

    Like I said in the previous message the BTS.MessageId is returning the second id in the  [dta_MessageInOutEvents] table whereas I need the first id for that message. Kindly advice how the same can be got?


    Regards, Vivin.

    Monday, June 2, 2014 7:18 AM
  • I would agree with la Cour, retrieving content from the Tracking database is not an ideal approach.

    If you need the EDI content later in the app, then you should take steps to keep it in the running app.  You can do this by using a PassThrough in the initial Receive, then let an Orchestration manage it through the whole process.  You can parse/debatch the EDI in a Receive Pipeline through a Loopback Adapter (http://social.technet.microsoft.com/wiki/contents/articles/12824.biztalk-server-list-of-custom-adapters.aspx), then correlate back to the Orchestration which holds the original EDI message for further processing.

    You are getting the MessageID of the second (Send) message because that is what's is hitting the Orchestration, the original message (Receive) no longer exist because the Disassembler creates a new message.  You can relate them through the uidServiceInstanceId which is the id of that Pipeline instance.

    Monday, June 2, 2014 11:29 AM
  • There are two entries inserted for a message in the [dta_MessageInOutEvents] table for the send port [WCF-Custom] for which tracking is not enabled. Kindly advice how to

    Regards, Vivin.

    Monday, June 2, 2014 12:27 PM
  • How to what?

    I already told you that the MessageInOutEvents table WILL get two entries (status = 0, status = 1) regardless of message body tracking being enabled or not.

    Morten la Cour

    Monday, June 2, 2014 12:44 PM
  • If you could see the first screenshot I attached along with the question, the first four entries are for the same message. In that the first two is the OracleDB [WCF-Custom]. I do not need these.. How can I remove these from inserting.

    Note: Tracking is not enabled in send port.


    Regards, Vivin.

    Monday, June 2, 2014 1:01 PM
  • You can't (and shouldn't). The tracking is there for a purpose, even though you don't need them for what you are doing right now, disabling tracking is not recommended.

    Morten la Cour

    • Marked as answer by Vivin Muthu Tuesday, June 3, 2014 4:28 AM
    Monday, June 2, 2014 1:46 PM
  •  I do not need these.. How can I remove these from inserting.

    Is this causing a problem? What you're seeing is the default behavior of BizTalk, it's the same for everyone, everywhere, all the time :)

    Again, I agree with la Cour, you could disable Global Tracking but you should not. It won't save you from having to maintain the databases and you would be eliminating a significant source of telemetry in case you needed to troubleshoot or isolate a bug.

    • Marked as answer by Vivin Muthu Tuesday, June 3, 2014 4:31 AM
    Monday, June 2, 2014 6:03 PM
  • Thanks for the information Morten and boatseller:)

    Regards, Vivin.

    Tuesday, June 3, 2014 4:32 AM