While implementing an EDI exchange using BizTalk Server 2010 I ran into a rather perplexing problem. There was a requirement that the system should be able to support any identification qualifiers (in the UNB2.2 / UNB3.2 segments) that our trading partners prescribed, even if they were non-standard values. The grief-inducing scenario was that some of the trading partners wanted to use the qualifier ZZ which is normally used for mutually defined identifications in X12 messages, however the problem in this case was that we were dealing with EDIFact messages for which ZZZ is normally the qualifier for mutually defined identifications and ZZ is not supported.
I followed the steps documented in this blog post by Miguel Herrera which describe how to support custom values in the UNB2.2 and UNB3.2 segments and while I now get the ZZ option in drop downs in parties I still run into trouble.
The first thing I tried doing was create a Party/Profile and manually add an identity to the profile with ZZ as the Qualifier and the party identifier as the Value, providing an arbitrary value for the Name since it isn’t actually used by the BizTalk runtime.
I made an agreement using that profile and the first thing I noticed was that the identifiers for the Recipient party were not pre-populated and the value Recipient did not show up in the Identification drop down box. I then tried to manually enter these values in the identifiers section however when I tried to save the agreement I got the error – “An identity QualifierIdentity:ZZ:Recipient already exists in the profile”.
I then deleted my parties/agreements and started again from scratch. This time I created the parties/profiles but did not add any identities to them. I created an agreement and manually added the identification and qualifier (using ZZ which is in the drop down box since we followed the instructions in Miguel’s blog post) values as desired. This works at runtime however it does cause other problems. If you open the relevant profile you will notice that an identification record has automatically been created using the values that were manually entered in the agreement identifiers tab. However there is no name listed for this record. While one might think that this isn’t a big deal since the Name isn’t actually used at all at runtime, it will actually cause you major grief the next time you decide to update the profile.
One of the issues is if you try to manually add an identity to the profile you will get the error “An identity cannot have an empty name” since the identity that was automatically created when you saved the agreement has no name. You will most likely get this error if you try to make any changes to the profile and apply them.
If you try to add a name to the problematic identity you will run into the error “An identity QualifierIdentity:ZZ:Recipient already exists in the profile” since apparently the MMC doesn’t end up updating the identity but tries to add a new one.
You will also find that having an identity with no name will result in the BizTalk Documenter not working against your BizTalk group anymore, raising an error “System.InvalidCastException: Unable to cast object of type ‘System.DBNull’ to type ‘System.String'” since it always expects to find an identity Name.
I consider this to be a bug in the MMC and do intend to log it in the not too distant future. Until then I have found a quick workaround as described below (disclaimer : approach with caution and do this on dev environments only). Export your party setup to a bindings file (to do this choose to export bindings in the BizTalk Administration Console and ensure you choose to include global party bindings). Open the binding file using a text editor and search for the qualifier in question that is causing the problem until you find the appropriate business profile as below.
Now manually add a description node just above the qualifier node and give it an appropriate value (which will be fed into the identity Name).
Now you will need to delete the party (obviously this is an exercise you are undertaking on dev environments only, deleting parties/agreements on live environments is not at all recommended as you will lose any persisted information such as interchange control number counters etc…) altogether and then import the edited binding file. If you inspect the re-created profile you should see that the value in the Description node has been placed into the Name for your identity. You will now be able to use the BizTalk Documenter and add other identities to your profile.
I have only encountered this problem using BizTalk 2010 and am not sure if it can be encountered in other versions. I will update this blog post when this bug gets logged or if I find any more info. If anyone else has any alternative suggestions to achieve what I am trying to do then please do let me know.