Asked by:
Process Inbound 997 using Orchestration in BizTalk 2010

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!
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
-
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.