Tag Archive: EDI

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.

Manual profile

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.

Unable to add identity

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.

Profile Error

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.

BusinessProfile Before

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).

BusinessProfile After

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.

Last week I ran into a really interesting issue. When I was running Visual Studio unit tests to validate instances of XML formatted EDIFact messages (see my previous blog post on BizTalk testing for more details on schema testing) I found that my tests just seemed to take forever and timed out with no reason provided.


I decided to apply a break point in my unit test and debugged it.  Much to my surprise when I stepped into the line of code that was actually validating the instance file I saw the below.

EDIFact Properties

Well, that’s really painful.  The unit test was timing out because it was waiting for user input on the above screen, however unless the test was being run in debug mode the screen was not being displayed at all.

So far I haven’t found any way to get the out of the box ValidateInstance method to work on EDIFact schemas because I can’t supress the above screen.  Interestingly enough, if the instance file actually fails validation then the test will fail rather than time out.  Another alternative I explored was to use some non standard test methods to test instances of EDIFact messages against my schemas.  In my previous blog post discussing BizTalk unit testing I mentioned that I regularly use non standard methods to extend my schema unit tests anyways since the out of the box ValidateInstance method doesn’t return an error message upon failure, and it also doesn’t work when your schemas import/include from other schemas.  I chose to use only these extension methods (as described here), bypassing the out of the box testing methods altogether and the tests now complete succesfully.  Note that in the below screenshot the TestExtensions.ValidateSchema method contains an extension method as described here.


While working on a BizTalk project that required the exchanging of EDI messages with external partners, I came across a situation whereby the partner’s EDIFact messages contained data elements which exceeded the maximum lengths as dictated by their Message Implementation Guide (MIG), which also happened to be the default maximum length in the out of the box BizTalk EDI schemas.  And even though they exceeded the maximum lengths, our trading partner still insisted that they were valid values!!!

This specific EDI message was of the COPARN (Container Announcement Message) variety, and the element in question was the temperature element as defined in the below out of the box Coparn D95B schema.

You’ll notice that the minimum and maximum lengths are both set to 3 (as supported by the trading partner’s MIG), so we would expect all temperature setting values to be 3 characters long.  These are just out of the box xsd schema properties, pretty simple.  Regardless whether the data type is string or int, the exact same validation should occur.

The catch is that it was possible (and extremely likely) for refrigerated containers to have negative temperatures, and the trading partner in question pointed us to some documentation which advises that the minus character in negative numbers is a special character which mustn’t be counted towards the length of a data element.

This article states that Numeric data element values are to be sent as positive. Although conceptually a deduction is negative, it is represented by a positive value: eg in a credit note all values are sent as positive amounts, and the application software will take note of the message name code (DE 1001) and process the values accordingly. In addition some data element and code combinations will lead to implied negative values, eg DE 5463 with code value “A” (allowance) in an ALC segment in an invoice. Again, the values are sent as positive amounts.

If, however, a value has to be explicitly represented as negative, it must be sent immediately preceded by a minus sign, eg -112. The minus sign is not counted as a character when computing the maximum field length of the data element.

Since refrigerated container temperatures could potentially be greater or less than 0, it is necessary to explicity precede negative numbers with the minus sign, and thus it is not counted.

I haven’t seen any documentation from Microsoft that claims that they have catered for this requirement in any fashion, nor was I able to find any blogs by anyone else at that time that suggested any ideas.

In this specific scenario we took the easy way out and just raised the Maximum Length on the temperature element to be 4 as we really didn’t have any time left to waste in the project to cater for what was essentially a big surprise to us given the lack of documentation (that I could find at least) around this.

Does anyone have a good way to deal with this or is this the only (or just the easiest) option?  I would be extremely wary of this in the future given how big EDI schemas tend to be, and will always discuss this specific scenario with trading partners first rather than trusting their MIGs before settling on using the out of the box schemas.

%d bloggers like this: