none
Cannot match EDIFACT CONTRL message to custom schema - BizTalk 2013 R2 RRS feed

  • Question

  • Hi all,

    I am trying to process inbound EDIFACT CONTRL messages that must match a custom schema.

    The EDI Disassembler matches the correct Agreement which has the custom target namespace as described in https://msdn.microsoft.com/en-us/library/bb246089.aspx.

    All non Contrl messages are matched correctly, but for Contrl messages it always matches to the default EDIFACT Contrl schema, and given that the Contrl message that must be processed has a different structure i get validation errors and the message gets suspended.

    Is there any limitation when receiving Contrl messages and BizTalk must always use the default schema or am i missing any agreement or schema configurations that allows the correct matching?

    Sample Contrl message to be processed (new lines just for readability):

    UNA:+,?'
    UNB+UNOA:2+AFSENDER:ZZ+DKFOHUS:ZZ+120115:1123+REF0001'
    UNH+1+CONTRL:1:1:UN'
    UCI+DKFOHUS:ZZ+AFSENDER:ZZ+20121126003341+1'
    UNT+3+1'
    UNZ+1+REF0001'

    Thanks.

    Thursday, January 26, 2017 8:13 PM

Answers

  • I have not encountered this but I strongly suspect you are see the built-in behavior. Meaning CONTRL, like 997, have special handling and use the fixed namespace.

    On that though, it is highly, highly unusual that CONTRL would be customized.  Is this really required?

    Customizing business transactions is not uncommon but CONTRL/997 are fundamental types so consistency is important.

    Friday, January 27, 2017 4:13 PM

All replies

  • I have not encountered this but I strongly suspect you are see the built-in behavior. Meaning CONTRL, like 997, have special handling and use the fixed namespace.

    On that though, it is highly, highly unusual that CONTRL would be customized.  Is this really required?

    Customizing business transactions is not uncommon but CONTRL/997 are fundamental types so consistency is important.

    Friday, January 27, 2017 4:13 PM
  • Thank you for confirming my suspicion.

    I agree with you that CONTRL should not be customized, but sadly is a requirement in what we are developing.

    I guess ill have to write a custom pipeline component to bypass this.

    Thank you.

    Thursday, February 16, 2017 9:38 AM
  • Yes, unfortunately.  This is not a problem with BizTalk Server, you or your app.

    This problem is being created by the Trading Partner using non-standard EDIFACT.

    The first thing you need to do is tell your management that because the Trading Partner is using non-standard EDIFACT, you're going to have to spend a lot of extra time, meaning money, to accommodate them.

    How are they modifying it?  The fix might be relatively simple.

    Thursday, February 16, 2017 12:45 PM
  • The fix might be simple, but this CONTRL definition is done by a external entity and we do not control that.

    Tuesday, February 21, 2017 3:47 PM
  • Sure, but your situation is still the same.  Your side will have to spend a lot of money to accommodate their mostly non-compliance.

    What exactly is the change?  As I noted, the solution might be simple.

    Tuesday, February 21, 2017 4:54 PM
  • We basically have two types of controls

    • CONTRL 1.1 (like the example i placed in the initial question)
    • CONTRL 2.2 (which is exactly the same as the standard CONTRL 4.1 UN)

    The only change between version is in the UCI segment, where the reference number of the file being acknowledged changes position.

    1.1 -> UCI+DKFOHUS:ZZ+AFSENDER:ZZ+20121126003341+1'

    2.2 -> UCI+20121126003341+DKFOHUS:ZZ+AFSENDER:ZZ+1'

    The current solution to process these files is:

    1. Change the custom schemas we have in our solution to have a root node different than CONTRL
    2. When receiving these type of messages change the keyword CONTRL to the root node we defined, which then allows BizTalk to correctly match the message to the schema.

    But the real problem is that, even if the solution to correct the CONTRL is easy, the entity that should make the correction does not want to do it, so we are stuck between not being able to process those messages (which is not an option) or just accept it and spend time/money to make these type of workaround to a process that is wrong.


    Tuesday, February 21, 2017 5:42 PM
  • Yes, I totally get your predicament.

    Another member is having a similar problem and I also advised them, being totally serious, that your management should just ask the Trading Partner how they are going to pay for the change.  This is perfectly reasonable since they are not compliant with EDIFACT standards.

    If you have no option but to take the cost hit yourselves, what you describe is one option.  But, it look like all they did is get the elements out of order (how the heck that happens, I don't want to even think about :).

    So, what I would try first is to grab the CONTRL EDI before the disassembler and re-order the UCI segment so it's correct.  This is probably the first time ever I'd even consider string manipulation in a Pipeline Component, but CONTRL is pretty small.

    Tuesday, February 21, 2017 6:04 PM