none
Sending 997s in Response to Received 997s RRS feed

  • Question

  •  

    We have two instances of deployed operations where BizTalk appears to be sending a 997 in reply to a 997, which should not happen.  One scenario:

     

    We send an outbound 810

    The trading partner sends a 997 acknowledgement to the 810

    We send a 997 acknowledgement to the 997

     

    Here is an example of the second 997.  Notice it is a response to an 810 transaction, which we only send and do not receive.

    ISA*00*          *00*          *01*US             *01*THEM           *080229*2110*U*00401*000011045*0*P*:
    GS*FA*US*007941230*THEM*2110*246*X*003030
    ST*997*0246
    AK1*IN*244
    AK2*810*0244
    AK5*E*5
    AK9*E*1*1*1
    SE*6*0246
    GE*1*246
    IEA*1*000011045

     

    Has anyone seen this before?

     

    Thanks,

     

    Jim

    Monday, March 3, 2008 6:46 PM

Answers

  • Microsoft is now working to reproduce the error and provide a fix.  In the meantime, I have found a workaround.  Again, to summarize the problem.

     

    We receive inbound X12 transactions from a trading partner through a receive port which uses the EDIReceive (or AS2EDIReceive) pipeline.  The EDI pipeline correctly generates a 997.  We receive 997 transactions from the trading partner in reply to our outbound transactions.  The EDI pipeline incorrectly generates a 997 transaction for these as well.

     

    The EDI pipeline should NOT generate a 997 in reply to a received 997.   There are no circumstances in X12 where this is acceptable behavior.  The only rationale that I figure for this situation was that these 997 messages were for internal routing for some reason.

     

    That let me to examine the context properties of "good" 997 transactions and "bad" 997 transactions.  I found the promoted property IsSystemGeneratedAck, which is set to true for good 997 transactions and is set to false for bad 997 transactions.  This property allowed me to further refine my filter on my send ports to my trading partners by adding the "IsSystemGeneratedAck == true" statement to the filter so that only good 997 transactions were sent.  I created a send port to capture the bad 997s and dump the to a folder so that they would not show up as suspended, using the reverse statement "IsSystemGeneratedAck == false".  The full filters include, in addition to the IsSystemGenerate ==" statement,

    statements for the ReceivePortName, the ISA06 == trading partner identifier, and ST01 == 997.

     

    Jim

     

    Tuesday, March 11, 2008 5:22 PM
  • Final Resolution of this problem as was concluded by us and MS support ----

     

    The EDIReceive pipeline produces two types of XML 997 transactions when serializing EDI.  Given a HOME party and a TRADING PARTNER:

     

    1.  XML 997s that acknowledge receipt of an X12 transaction other than a 997 from TRADING PARTNER

     

    2.  XML 997s that have been received from TRADING PARTNER.

     

    Unfortunately, the context properties of both, including the ISA party identifiers, is identical. This is unexpected as from an EDI perspective the sender/receiver information should logically have flipped for the first type of 997.  This means the filter:

     

    STO1 == 997

    ISA06 == TRADINGPARTNER

     

    will not distinguish between the two types even though from an EDI perspective:

     

    1.  type one should have HOME as the ISA06 (since the 997 is going from HOME to TRADING PARTNER)

     

    2.  type two should have TRADING PARTNER as the ISA06 (since the 997 came from TRADING PARTNER to home)

     

    Thus the above filter on a send port will result in both types of 997s being sent through that send port, thus causing the appearance that R2 is replying to a 997 with a 997.

     

    The IsSystemGeneratedAck property provides the means to separate the two types.  In effect, IsSystemGeneratedAck == true means that BizTalk generated the 997 from "scratch".  IsSystemGeneratedAck == false means that the acknowledgement is a serialized version of a received 997.  Thus the filters to route the 997s should be

     

    STO1 == 997

    ISA06 == TRADINGPARTNER    ----- 997 to be sent to TRADING PARTNER

    IsSystemGeneratedAck == true

     

    STO1 == 997

    ISA06 == TRADINGPARTNER    ----- 997 received from TRADING PARTNER

    IsSystemGeneratedAck == false

     

    This writeup refers only to the 997 acknowledgement; the same is true for the other EDI acknowledgement types.

     

     

     

     

     

     

     

    Friday, March 21, 2008 8:20 PM

All replies

  • Hi Jim,

     

    I haven't seen anybody else reported a similar issue. Which version of BizTalk server are you using currently? Can this issue always be reproduced on any other BTS machine with 810 interchange?

     

    Thursday, March 6, 2008 11:34 AM
    Moderator
  • We are seeing the problem with two customers.  We also have seen reports by others on blogs.  The issue is not with the 810, that was just an example.  The problem occurs with all outbound X12.

    We are on the phone with MS now.  I will post a detailed summary of the problem and hopefully cause/solution when we are off the phone.

     

    Jim

     

    Thursday, March 6, 2008 5:59 PM
  • Microsoft is now working to reproduce the error and provide a fix.  In the meantime, I have found a workaround.  Again, to summarize the problem.

     

    We receive inbound X12 transactions from a trading partner through a receive port which uses the EDIReceive (or AS2EDIReceive) pipeline.  The EDI pipeline correctly generates a 997.  We receive 997 transactions from the trading partner in reply to our outbound transactions.  The EDI pipeline incorrectly generates a 997 transaction for these as well.

     

    The EDI pipeline should NOT generate a 997 in reply to a received 997.   There are no circumstances in X12 where this is acceptable behavior.  The only rationale that I figure for this situation was that these 997 messages were for internal routing for some reason.

     

    That let me to examine the context properties of "good" 997 transactions and "bad" 997 transactions.  I found the promoted property IsSystemGeneratedAck, which is set to true for good 997 transactions and is set to false for bad 997 transactions.  This property allowed me to further refine my filter on my send ports to my trading partners by adding the "IsSystemGeneratedAck == true" statement to the filter so that only good 997 transactions were sent.  I created a send port to capture the bad 997s and dump the to a folder so that they would not show up as suspended, using the reverse statement "IsSystemGeneratedAck == false".  The full filters include, in addition to the IsSystemGenerate ==" statement,

    statements for the ReceivePortName, the ISA06 == trading partner identifier, and ST01 == 997.

     

    Jim

     

    Tuesday, March 11, 2008 5:22 PM
  • Final Resolution of this problem as was concluded by us and MS support ----

     

    The EDIReceive pipeline produces two types of XML 997 transactions when serializing EDI.  Given a HOME party and a TRADING PARTNER:

     

    1.  XML 997s that acknowledge receipt of an X12 transaction other than a 997 from TRADING PARTNER

     

    2.  XML 997s that have been received from TRADING PARTNER.

     

    Unfortunately, the context properties of both, including the ISA party identifiers, is identical. This is unexpected as from an EDI perspective the sender/receiver information should logically have flipped for the first type of 997.  This means the filter:

     

    STO1 == 997

    ISA06 == TRADINGPARTNER

     

    will not distinguish between the two types even though from an EDI perspective:

     

    1.  type one should have HOME as the ISA06 (since the 997 is going from HOME to TRADING PARTNER)

     

    2.  type two should have TRADING PARTNER as the ISA06 (since the 997 came from TRADING PARTNER to home)

     

    Thus the above filter on a send port will result in both types of 997s being sent through that send port, thus causing the appearance that R2 is replying to a 997 with a 997.

     

    The IsSystemGeneratedAck property provides the means to separate the two types.  In effect, IsSystemGeneratedAck == true means that BizTalk generated the 997 from "scratch".  IsSystemGeneratedAck == false means that the acknowledgement is a serialized version of a received 997.  Thus the filters to route the 997s should be

     

    STO1 == 997

    ISA06 == TRADINGPARTNER    ----- 997 to be sent to TRADING PARTNER

    IsSystemGeneratedAck == true

     

    STO1 == 997

    ISA06 == TRADINGPARTNER    ----- 997 received from TRADING PARTNER

    IsSystemGeneratedAck == false

     

    This writeup refers only to the 997 acknowledgement; the same is true for the other EDI acknowledgement types.

     

     

     

     

     

     

     

    Friday, March 21, 2008 8:20 PM
  • I'm having the same problem on outbound documents, whereas a 997 seems to be generated that Acks the outbound document.   Also, the current ISA control number and GS control number is incremented when the ack is generated.  After the ACK is wrappped in the new ISA and GS envelope, the Raw EDI data is not serialized correctly.  There is no segment terminator between the SE segment and the GE segment on the 997 that is generated with IsSystemGeneratedAck = false.
    Friday, April 11, 2008 8:34 PM
  • I saw this thread and wanted to mention I had the same problem. This occurred when I had checked to generate a 997 on the party properties but had not checked "route ACK to send pipeline on request response receive port." The generated 997 has the ISA and GS headers reversed so I use an orchestration to flip them correctly to send to my trading partner. I did run into the same issue as Jim Dawson in that inbound 997s from my trading partner would then get replayed back with response 997s. I think the IsSystemGeneratedAck should resolve the replayed 997.

    Thanks,
    If this answers your question, please use the "Answer" button to say so | Ben Cline
    Wednesday, April 29, 2009 4:03 AM
    Moderator