none
Process Inbound 997 using Orchestration in BizTalk 2010 RRS feed

  • Question

  • MS,

    After reviewing and trying all the topics related to Inbound 997, I am creating this new topic that appears to have worked for some of the forum users.  So here is what I did:

    First Attempt:

    • Created a simple Orchestration that has a receive port listening to the folder (on a FTP server) where our trading partner (THEM) drops a 997 when we (US) send them an 850.
    • The Orchestration basically writes the XML schema to another folder C:\Rcvd997 using a Send Port.
    • We have a receive port listening to this C:\997Drop folder. 
    • The first receive shape in the orchestration has a Filter expression BTS.MessageType == "http://schemas.microsoft.com/Edi/X12#X12_997_Root".
    • We confirmed that the BTS.MessageType is a promoted property when the message is received.  This clearly indicates that the receive port/location is reading in the file (and of course the file gets deleted from C:\997Drop when it is read).
    • We get an error

    The output message of the receive pipeline "Microsoft.BizTalk.Edi.DefaultPipelines.EdiReceive, Microsoft.BizTalk.Edi.EdiPipelines,

    Version=3.0.1.0, Culture=neutral, PublicKeyToken=31bf3856ad364e35" failed routing because there is no subscribing orchestration

    or send port. The sequence number of the suspended message is 1.

    • There is no XML file written to C:\Rcvd997.  We also added writing to the Event logs in an expression shape within the Orchestration with no luck.

    Second Attempt:

    • In addition to that, we added a new SendPort called "EDI-997BadPort" with Filters BTS.MessageType == http://schemas.microsoft.com/Edi/X12#X12_997_Root and EDI.IsSystemGeneratedAck == false.  Both these values are promoted in the message received.
    • This processes the file dropped in C:\997Drop folder and also completes the process successfully with no errors in the Administration console.
    • However, the message was never picked up by the orchestration. 
    • In addition, the new file created on port "EDI-997BadPort" uses the EDI fallback settings in the ISA segment for Receiver and Sender for some reason.  But the rest of the EDI seems to be correct.

    Third Attempt:

    • Tweaking the Party agreements did not make any difference.  We unchecked the trading partner "Local BizTalk processes messages received by the party or supports sending message from this party
    • The Transaction Set list is blank in trading party both (US --> THEM and THEM --> US)  agreement tabs.

    Fourth Attempt:

    • We also created a custom EDI pipeline hoping that will disable the default behavior of EDI-997.

    We have tried several things since then with absolutely no luck.  So why do we need to do this - because we are exchanging EDI files over FTP and we need to do some custom processing once we receive 997 from THEM when we send them a 850.

    Why is there no way to intercept or disable what EDI does when it receives a 997?

    Any ideas, suggestions, recommendations?

    Thanks!

    Tuesday, October 30, 2012 7:04 PM

All replies

  • Hi At Te,

    I had this same issue and the response I got is that this issue may be resolved in the next cummulative update for BizTalk 2010 that should be out in early 2013.  Here's the link to my similar question:  http://social.msdn.microsoft.com/Forums/en-US/biztalkediandas2/thread/2933be31-eff0-4d7e-830e-32d7cf434b19

    I am currently using a tedious programmatic workaround and axniously awaiting a resolution to this issue.

    Thanks!

    JSlatton


    JSlatton

    Wednesday, November 21, 2012 6:41 PM
  • Hi

    Can you please let me know if there is any solution for this. I tried to process the inbound 997 files but receive the same error.

    The output message of the receive pipeline "Microsoft.BizTalk.Edi.DefaultPipelines.EdiReceive, Microsoft.BizTalk.Edi.EdiPipelines,

    Version=3.0.1.0, Culture=neutral, PublicKeyToken=31bf3856ad364e35" failed routing because there is no subscribing orchestration

    or send port. The sequence number of the suspended message is 1.

    Tuesday, September 9, 2014 1:42 PM