none
Routing 997 on the Trade Agreements RRS feed

  • Question

  • I have this problem where I have an orchestration that routes the claims based on the transaction. I have the orchestration to send all the messages to mailboxes based on the field inside the file. The orchestration works to perfection. I can route messages and it works fine.

    The problem I am having is generating the 997 for the trade parner. For some reason, it is routing the 997 along with the output file to the same destination. I am trying to route the 997 to a specific folder and the other file to another folder. I am trying to set up the filters, but for some reason I can not stop it from routing the 997 to the destination. When I add a filter, it duplicates the send message for some reason. Does anyone have any ideas please? :-)
    Thursday, February 4, 2010 5:43 PM

Answers

  • 997 transactions are generated in the EDI pipeline for inbound traffic if the party flags are set to do so.  Unless you specifically set the filters to route them they are treated as any other message.  The 997 as generated is XML, thus you will get the 997 along with all other traffic into your orchestration.  For example, outside an orchestration your would have a send port to handle all but the 997 and the filter would be ST01 != 997.  You would have a send port to return the 997 to the sender with the filter ST01 == 997.  There are a couple of other aspects to the filter as well, but this is the basic step.

    It sounds to me like the second 997 your are getting is because you are not setting the != 997 there.

    Hope this helps


    Jim -- Pro Mapping in BizTalk 2009, Apress Books, March 23, 2009
    • Marked as answer by Carlos T. _ Tuesday, February 9, 2010 3:22 PM
    Sunday, February 7, 2010 6:51 PM
  • With receive shape filters you have to surround the value in the filter with quotes. I am guessing it is having trouble with the GS08 filter. Try using quotes around the 004010X098A1 value.

    Thanks,



    If this answers your question, please use the "Answer" button to say so | Ben Cline
    • Marked as answer by Carlos T. _ Tuesday, February 9, 2010 3:22 PM
    Monday, February 8, 2010 6:59 PM
    Moderator

All replies

  • It sounds like there must be an overlapping filter somewhere. You will get a duplicate message if two ports have the same filter. Also, if a receive shape in an orchestration has the same filter as a send port, this will cause a duplicate message too.

    Thanks,
    If this answers your question, please use the "Answer" button to say so | Ben Cline
    Friday, February 5, 2010 6:11 AM
    Moderator
  • Hi,
        Send port where you do not want 997 to come please give send port filter as
    BTS.MessageType != http://schemas.microsoft.com/Edi/X12#X12_997_Root



    Thanks
    Gyan
    If this answers your question, please mark it as "Answered".
    Friday, February 5, 2010 9:06 AM
  • Interestingly when I put that filter is when I get a duplicate 997. If I take the filter out, I only get one 997. I am beggining to wonder if my orchestration is currupt or something.
    Friday, February 5, 2010 1:06 PM
  • Hi,
       Are you getting the right behaviour. What is the problem you are getting now. Can you please explain?


    Thanks
    Gyan
    If this answers your question, please mark it as "Answered".
    Friday, February 5, 2010 3:22 PM
  • Two 997 messages go to the same location when I add the filter.
    Please Indicate "Mark as Answer" if this Post has Answered the Question
    Friday, February 5, 2010 3:23 PM
  • Please check following:

    1- 997 is generated for one group then make sure that you do not have 2 groups in the interchange for which you are testing this project.
    2- Any message in Message box gets replicated only when it subscribes to more than one Send port/Orchestration. So you should check for subscription.

    Hope this helps!!


    If this answers your question, please mark it as "Answered".
    Friday, February 5, 2010 3:32 PM
  • It would not bee good to set a filter to BTS.MessageType != http://schemas.microsoft.com/Edi/X12#X12_997_Root because this would be true for every message except the 997.

    You can compare subscriptions using the Subscription query, documented here: http://geekswithblogs.net/sthomas/archive/2005/10/03/55872.aspx. This does work in BizTalk 2009 too.

    Could you mention the filters you are using?

    Thanks,


    If this answers your question, please use the "Answer" button to say so | Ben Cline
    Friday, February 5, 2010 4:35 PM
    Moderator
  • No filters. I am handling everything through the trade partner. Though I am able to restrict the 997 if I like, but that is not doing me any good if I watn to respond. I am handling the whole project through orhchestration

    Thank you for the link. I will look at it now.
    Please Indicate "Mark as Answer" if this Post has Answered the Question
    Friday, February 5, 2010 8:23 PM
  • My question is, I have an orchestration that is routing the messages. The problem is that I can ot seem to route the 997 messages to a different location. All the messages are going to the same directory. For example, I have a recieve location for the claims and then route the messages to a destination, but the problem I am having is that the claim and then the 997 are going to the same destination. Thats is what is preventing me from getting this project to work. I am sure this is possible, but I can not seem to get it to work for some reason.

    As a test I went ahead and subscribed the 997 and I can get it to route just fine, but the problem is that I am still getting that other 997 to the destination that I explained earlier. Any help would be greatly appreciated.
    Please Indicate "Mark as Answer" if this Post has Answered the Question
    Friday, February 5, 2010 9:17 PM
  • Did you try to use any EDI Context properties? Something like EDI.ReuseEnvelope?
    For some project I use ReceivePortName, ReuseEnvelope and messageType!= 997root path.
    Why not promote some property with message before send?
    Friday, February 5, 2010 9:31 PM
  • I could use that, the problem I am haivng is that I need to have the receive location be dynamic becasue I do now know the type of transaction that I will receive. Therefore, I need to be able to read the transaction comming in. With that in mind, the way I have it now is the receive location to be xml and then have an expression that reads GS08 = xml_inbound(EDI.GS08); I then take that variable and make a decission based on the EDI filed. The problem is that it is failing because at this point, the 997 is already comming through. I have no idea why. Therefore, on the orchestration, I have the recieve location, then the receive shape, and right after thant the expression I just pasted above. The 997 is making it inside the orchestration where I would expect the 997 to come outside the orchestration where I can subscribe it on the trade partner. There is something that is not seting right for this thing which is what is confusing for me. I am getting an extra 997 and I can not stop it. I have looked at the subscriptions and I can not find where the 997 is tied to.
    Friday, February 5, 2010 9:53 PM
  • 997 transactions are generated in the EDI pipeline for inbound traffic if the party flags are set to do so.  Unless you specifically set the filters to route them they are treated as any other message.  The 997 as generated is XML, thus you will get the 997 along with all other traffic into your orchestration.  For example, outside an orchestration your would have a send port to handle all but the 997 and the filter would be ST01 != 997.  You would have a send port to return the 997 to the sender with the filter ST01 == 997.  There are a couple of other aspects to the filter as well, but this is the basic step.

    It sounds to me like the second 997 your are getting is because you are not setting the != 997 there.

    Hope this helps


    Jim -- Pro Mapping in BizTalk 2009, Apress Books, March 23, 2009
    • Marked as answer by Carlos T. _ Tuesday, February 9, 2010 3:22 PM
    Sunday, February 7, 2010 6:51 PM
  • Ok I tried that but on the orchestration when I try to put a filter in the recive location, I get an error that says invalid number, cannot implicitly convert system.Int32 to system.string, illigal active predicate.

    Let me share what I am trying to do and this may help. I am creating one port that will accept any x12 file and based on a value in the file, I will route the message. It seems that the orchestration is giving some problems becuase it is not cooparating with what I want to do. If I would add the filter and it works at the receive shape, I would be in bussiness, but I am doing something wrong. I added the filter (EDI.ST01 != 997) && (EDI.GS08 == 004010X098A1) and that is where I am getting the error. :-(
    Please Indicate "Mark as Answer" if this Post has Answered the Question
    Monday, February 8, 2010 2:07 PM
  • With receive shape filters you have to surround the value in the filter with quotes. I am guessing it is having trouble with the GS08 filter. Try using quotes around the 004010X098A1 value.

    Thanks,



    If this answers your question, please use the "Answer" button to say so | Ben Cline
    • Marked as answer by Carlos T. _ Tuesday, February 9, 2010 3:22 PM
    Monday, February 8, 2010 6:59 PM
    Moderator
  • I got it to work. It was a bit odd though becuase I had to create the filters in two places even though I had set it up on the orchestration. In other words, even though I had a filter on the receive shape on the orchestration, once I deployed it I had to go back to the send port and create another filter. I thoguht that was odd though, but it is working. Thank you all for your help.


    Please Indicate "Mark as Answer" if this Post has Answered the Question
    Tuesday, February 9, 2010 3:24 PM