none
997 not being routed to request-response port RRS feed

  • Question

  • I am receiving an EDI transaction over a request-response port and want the 997 to be returned to that port.  I have 'Route ACK to send pipeline on request-response receive port' checked in the party agreement properties.  The 997 is being created but gets suspended with 'failed routing because there is no subscribing orchestration or send port.'  Is there anything else that needs to be done to get the 997 sent back?
    Friday, November 7, 2014 5:11 PM

Answers

  • OK, got it working.  The solution is similar to this post.  This is what I think is happening.  Something in the receive port (adapter/disassembler?) creates a blank message before creating the 997.  This blank message also has RouteDirectToTP=True.  So it gets routed to the send pipeline in the req-resp port which closes the channel.  Then the 997 has nowhere to go and hangs in the messagebox.  So I created a pipeline component to check the messagetype.  If blank, set RouteDirectToTP=false.  Also, I needed to set the Outbound WCF message body source to Template with this xml:  <bts-msg-body xmlns="http://www.microsoft.com/schemas/bts2007" encoding="string"/>.  Now I am getting a 997 returned, with soap headers.
    • Marked as answer by FrankD302 Monday, November 10, 2014 9:18 PM
    Monday, November 10, 2014 9:18 PM

All replies

  • Hi,

    You are trying to send EDI Acknowledgment synchronously. 

    In this case if both a technical acknowledgment and a functional acknowledgment are enabled, the technical acknowledgment will be sent back synchronously, and the functional acknowledgment will be sent back asynchronously and because you don't have any other subscriber to subscribe to 997 acknowledgments it will suspend.

    Kindly ensure that you have not enabled TA1 Expected to return a technical (TA1) acknowledgment.

    I would have personally preferred to create a static one-way send port to send the 997 acknowledgment.

    Refer: Receiving EDI Interchanges and Sending Back an Acknowledgement

    Rachit


    Saturday, November 8, 2014 5:24 AM
    Moderator
  • Rachit, thanks for your response.

    TA1 Expected is not checked, only 997 Expected is checked.

    I should mention that I'm using a WCF-BasicHttp request-response port and hoping to return the 997 in the send pipeline of that port.  Do I need to create an orchestration for this or can it be done without one?


    • Edited by FrankD302 Saturday, November 8, 2014 5:48 PM
    Saturday, November 8, 2014 5:43 PM
  • Yes, you need to subscribe the message. The 997 incoming message to be received, has to be processed like any other EDI message.

    Refer: 

    http://www.44342.com/biztalk-f20-t563-p1.htm

    Rachit



    Saturday, November 8, 2014 6:33 PM
    Moderator
  • In this case I am trying to send a 997.  I have promoted 'RouteDirectToTP' and 'DestinationParty' but still the 997 does not get picked up by the send pipeline of the request-response port.  I've tried using the WCF-BasicHttp and WCF-WSHttp adapters but with the same result.  
    Monday, November 10, 2014 3:08 PM
  • OK, got it working.  The solution is similar to this post.  This is what I think is happening.  Something in the receive port (adapter/disassembler?) creates a blank message before creating the 997.  This blank message also has RouteDirectToTP=True.  So it gets routed to the send pipeline in the req-resp port which closes the channel.  Then the 997 has nowhere to go and hangs in the messagebox.  So I created a pipeline component to check the messagetype.  If blank, set RouteDirectToTP=false.  Also, I needed to set the Outbound WCF message body source to Template with this xml:  <bts-msg-body xmlns="http://www.microsoft.com/schemas/bts2007" encoding="string"/>.  Now I am getting a 997 returned, with soap headers.
    • Marked as answer by FrankD302 Monday, November 10, 2014 9:18 PM
    Monday, November 10, 2014 9:18 PM