none
Party Agreement UNB3.1 issue RRS feed

  • Question

  • Hi,

    For some EDI files i have received does not have the recipient Id in the UNB segment. I have created a schema for UNB segment in the EDI file and kept the element (UNB3.1) as optional. But UNB 3.1 is mandatory in the Identifiers part of the Party Agreement.

    So is it possible that i keep "ABC" as the default value of the node in the UNB Schema and give the same value "ABC" in the Identifiers part of the Party Agreement and so that the schema will be identified based on the agreement??


    Regards, Vivin.

    Friday, September 12, 2014 10:10 AM

Answers

  • I'm also learning new things here as I'm helping you out, so after reading that MSDN link 137 times, I think I made a mistake:

    I think you should not put 'ABC' as receiver but use the default 'HostEdifactRecvr' as UNB3.1 and specify 'BT' as UNB 3.2. To trigger the 'Sender' only resolution. (Sorry about the confusion).
    But again, I never did party resolution pure based on the Sender values, you should try to setup a test project to see if you agreement resolution works

    To answer your questions about the quote

    Your agreement is always bi-directional. 
    That means that you have '2-way communication' Party A -> Party B and the other way round Party B -> Party A. In your Agreement Properties you will see configuration for both directions and both directions together form a bi-directional agreement.



    Glenn Colpaert - MCTS BizTalk Server - Blog : http://blog.codit.eu

    • Proposed as answer by GlennColpaertMVP Wednesday, September 17, 2014 6:48 AM
    • Marked as answer by Angie Xu Thursday, September 18, 2014 1:32 AM
    Monday, September 15, 2014 7:50 AM

All replies

  • You cannot simply add the UNB segment in the EDI schema and assume it will work. It will not work like that. 
    The only way to manipulate UNA and UNB without using a proper Party Setup (prefered way) is by overwriting the context properties in the pipeline (or orchestration). 

    http://technet.microsoft.com/en-us/library/dd223988(BTS.70).aspx

    Is there any reason why you are receiving EDI files without UNB3.1? Because UNB3.1 is mandatory and if it's not present your EDI message is per definition invalid.

    http://www.stylusstudio.com/edifact/40100/UNB_.htm


    Glenn Colpaert - MCTS BizTalk Server - Blog : http://blog.codit.eu


    Friday, September 12, 2014 11:58 AM
  • Hi Glenn,

    Our current requirement is to download the information received in CODECO file into DB. We have not added the UNB segment in the CODECO schema. But instead we have created a seperate schema for UNB segment alone. And have two schemas (UNB Schema and CODECO Schema) as inputs for mapping.

    Also we are aware of that UNB3.1 information is mandatory but we have been processing these type of files for a long time using our oracle procedures. Also we have requested the sender to provide the information in the file but it is taking too long for them. So i was looking for any workaround with this issue.


    Regards, Vivin.

    Friday, September 12, 2014 12:08 PM
  • So you bascially receive 'UNB3.1' as empty or as 'ABC'?


    Glenn Colpaert - MCTS BizTalk Server - Blog : http://blog.codit.eu

    Friday, September 12, 2014 12:17 PM
  • We receive UNB 3.1 as empty

    Regards, Vivin.

    Friday, September 12, 2014 12:19 PM
  • Agreement Resolution works as follows:

    • Try a match on sender and receiver in the interchange header
    • Try to resolve it only based on sender with fixed values of the receiver
    • Use the fallback

    (http://msdn.microsoft.com/en-us/library/bb246089.aspx)

    Never did it that way, but I would try like you suggested and put 'ABC' in the UNB3.1 to trigger a mismatch on the first resolution (sender + receiver combination). BizTalk will then try to resolve it based on the sender qualifier and identifier.



    Glenn Colpaert - MCTS BizTalk Server - Blog : http://blog.codit.eu

    Friday, September 12, 2014 12:25 PM
  • Also in the files received the sender qualifier will not be received since it is not mandatory.

    Regards, Vivin.

    Friday, September 12, 2014 12:42 PM
  • You can set the Sender Qualifier (UNB2.2) in your Agreement properties to <NotValued>

    Glenn Colpaert - MCTS BizTalk Server - Blog : http://blog.codit.eu

    Friday, September 12, 2014 12:51 PM
  • So the receiver field can have any value and biztalk will only check now the sender and its qualifier if there is no matching agreement for the sender and receiver combination???

    Regards, Vivin.

    Monday, September 15, 2014 6:46 AM
  • Should work, indeed...
    But to be tested for sure, as you are in a rather special situation with the missing UNB3.1

    Check following quote from MSDN (http://msdn.microsoft.com/en-us/library/bb246089.aspx):

    If BizTalk Server cannot resolve the agreement using all four sender and receiver qualifiers and identifiers, it will attempt to resolve the agreement using just the sender qualifier and identifier. For EDIFACT, these fields are UNB2.1 and UNB2.2. As with a match of sender and receiver properties, BizTalk Server matches the values in the interchange header with the agreement properties defined in the Identifiers page of the direction-specific agreement tabs of the Agreement Properties dialog box. If only the sender qualifier and identifier are used to resolve the agreement, the receiver qualifier and identifier should be undefined in the bi-directional agreement tab of the Agreement Properties dialog box.

    If no agreement is found, then BizTalk Server uses the fallback trading partner agreement, unless the port setting requires authentication. If the port setting requires authentication (if either Drop messages if authentication fails or Keep messages if authentication failsis selected on the General page of the Receive Port Properties), an agreement is required for any interchange received by the receive port. In this case, if the agreement is not resolved by matching the interchange header with agreement properties, using the fallback agreement properties to determine the agreement is not allowed. The interchange will be treated as though authentication had failed if no agreement is found, and will be suspended.


    Glenn Colpaert - MCTS BizTalk Server - Blog : http://blog.codit.eu

    Monday, September 15, 2014 6:59 AM
  • Hi Glenn,

    I am not clear on what is being said in the below quote

    "If only the sender qualifier and identifier are used to resolve the agreement, the receiver qualifier and identifier should be undefined in the bi-directional agreement tab of the Agreement Properties dialog box."


    Regards, Vivin.

    Monday, September 15, 2014 7:07 AM
  • I'm also learning new things here as I'm helping you out, so after reading that MSDN link 137 times, I think I made a mistake:

    I think you should not put 'ABC' as receiver but use the default 'HostEdifactRecvr' as UNB3.1 and specify 'BT' as UNB 3.2. To trigger the 'Sender' only resolution. (Sorry about the confusion).
    But again, I never did party resolution pure based on the Sender values, you should try to setup a test project to see if you agreement resolution works

    To answer your questions about the quote

    Your agreement is always bi-directional. 
    That means that you have '2-way communication' Party A -> Party B and the other way round Party B -> Party A. In your Agreement Properties you will see configuration for both directions and both directions together form a bi-directional agreement.



    Glenn Colpaert - MCTS BizTalk Server - Blog : http://blog.codit.eu

    • Proposed as answer by GlennColpaertMVP Wednesday, September 17, 2014 6:48 AM
    • Marked as answer by Angie Xu Thursday, September 18, 2014 1:32 AM
    Monday, September 15, 2014 7:50 AM
  • Thanks a lot for your explanation Glenn. Actually i was confused abt "the receiver qualifier and identifier should be undefined". Now i am clear on it.

    Regards, Vivin.

    Monday, September 15, 2014 7:55 AM