none
What will happens if UNB 3.1 mismatched? RRS feed

  • Question

  • I found a intesreting scenario here and will appreciate your comment to tells me whether I did something wrong or it is a by design behaviour in Biztalk.

    My client is sending me EDI file with following UNB header

    UNB+UNOA:1+GGG:ABC+NNN:ABC+060108:1135+212869'

    I had set GGG as UNB2.1 and NNN as UNB3.1 with ABC at both UNB2.2 and UNB3.2.

    The client sent a message with one of the value in the message that does not meet the enumeration set for the elements and the message get suspended. (expected).

    Somehow the client sent another file with a different value in UNB 3.1, but surprisingly the file could still be processed, but without the validation on the EDI schema and it had never been suspended..

    I had read thru http://msdn.microsoft.com/en-us/library/bb246089(BTS.20).aspx and I understand that BizTalk should match all 4 sender and receiver identification and qualifier....

    Therefore i am puzzled with the scenario with UNB3.1 mismatched and hope to get some advise here..thanks!



    Wednesday, March 10, 2010 4:13 PM

All replies

  • anyone?
    Thursday, March 11, 2010 9:25 AM
  • Just thought..

    If the particular field is optional then BizTalk won't get suspended. If that is must then BizTalk will suspend the interchange.


    Thanks, Raja
    Thursday, March 11, 2010 10:48 AM
  • Hi,
     

    To perform party resolution, BizTalk Server proceeds as follows:

    1. Resolve the party by matching the sender qualifier and identifier, and the receiver qualifier and identifier, in the interchange header with those in the properties of a party.
    2. If step 1 does not succeed, resolve the party by matching just the sender qualifier and identifier in the interchange header with those in the properties of a party.
    3. If step 2 does not succeed, use the global properties.

    Now UNB2.1 and UNB2.2 are sender qualifier and identifier.
    and  UNB3.1 and UNB3.2 are receiver qualifier and identifier.

    So in first step it will try to match all four values but if not succeed then look into step 2 it will try to match only sender qualifier and identifier that is UNB2.1 and UNB2.2.

    So think in your second message UNB2.1 and UNB2.2 matched. So it resolved to the party.

    And one more thing is if it does not resolve to any of the party then it goes to Global party resolution.

    Let me know if your problem is not resolved yet.


    Thanks
    Gyan


    If this answers your question, please mark it as "Answered".
    Friday, March 12, 2010 4:33 AM
  • Hi,
     

    To perform party resolution, BizTalk Server proceeds as follows:

    1. Resolve the party by matching the sender qualifier and identifier, and the receiver qualifier and identifier, in the interchange header with those in the properties of a party.
    2. If step 1 does not succeed, resolve the party by matching just the sender qualifier and identifier in the interchange header with those in the properties of a party.
    3. If step 2 does not succeed, use the global properties.

    Now UNB2.1 and UNB2.2 are sender qualifier and identifier.
    and  UNB3.1 and UNB3.2 are receiver qualifier and identifier.

    So in first step it will try to match all four values but if not succeed then look into step 2 it will try to match only sender qualifier and identifier that is UNB2.1 and UNB2.2.

    So think in your second message UNB2.1 and UNB2.2 matched. So it resolved to the party.

    And one more thing is if it does not resolve to any of the party then it goes to Global party resolution.

    Let me know if your problem is not resolved yet.


    Thanks
    Gyan


    If this answers your question, please mark it as "Answered".

    Basically this is not a problem..but just to get better understanding of how's thing works.
    Yes. I agree that it resolved to the party when UNB2.1 and UNB2.2 matched. That's why there is nothing suspended.

    However, what is weird is that

    1. when all UNB2.1 and UNB2.2, UNB3.1 and UNB3.2 matched, it resolved to the party as well, and also able to point out that a value in the message does not met the enumeration set in the schema and suspended the message.  --> this behavior is acceptable

    2. when only UNB2.1 and UNB2.2 matched, it resolved to the party as well, but allow the processing, without pointing out that the value in the message does not meet the enumeration set in the scheme and did not suspend the message.

    Point #2 is what I do not understand why.




    Friday, March 12, 2010 6:35 AM
  • Hi,
        Sorry I missed one thing here. It tries to match UNB2.1 and UNB2.2 only when party setting does not contain UNB3.1 and UNB3.2. So it does not resolve to your party but it will resolve to Global party.

    And I think in the party you have made to validate it for Edi Type. that is not present in the Global party. So because of that it is getting processed. You can generate 997 to see what exactly is wrong in your instance.


    Thanks
    Gyan
    If this answers your question, please mark it as "Answered".
    Friday, March 12, 2010 1:03 PM