FIX: The EDIFACT document is suspended if it contains a UNH2.5 segment in BizTalk Server 2006 R2

Consider the following scenario:

• You use the Electronic Data Interchange (EDI) Receive pipeline in BizTalk Server 2006 R2 to receive Electronic Data Interchange For Administration, Commerce and Transport (EDIFACT) messages from a trading partner.
• You receive an EDIFACT message from a trading partner that contains an assigned code (UNH2.5 segment).

In this scenario, no schema is discovered for the incoming EDIFACT document. Therefore, the document is suspended without additional processing. Additionally, an error message is logged in the application event that resembles the following:For example, you receive an EDIFACT document that contains a UNH field such as UNH+12345+INVOIC:D:93A:UN:ABCDEF. The EDI Receive pipeline discovers the schema in the following namespace to process the message:
If you have not deployed a schema with the root node name EFACT_D93A_INVOIC_ABCDEF, the EDIFACT document is suspended because there is no schema found to process it. Therefore, to avoid this problem, you must deploy a specific schema for each D93A_INVOIC with a different UNH2.5 segment.

This problem occurs because of an error in the EdiReceive pipeline. If UNH2.5 is present in the message, the EDI Disassembler will try to find a matching schema by using the value of UNH2.5 as part of the schema name. For example, "EFACT_D93A_INVOIC_ABCDEF". If no schema is deployed for the UNH2.5 segment, the EDIFACT document is suspended.

After you apply this hotfix, the EDI Disassembler will try to find a matching schema by using the value of UNH2.5 as part of the schema name when a received message contains a UNH2.5 segment. If no matching schema is found, the EDI Disassembler will try to finda schema without the UNH2.5 value.

In this manner, you can use schemas for partners with specific UNH2.5 values. Also, you can use standard schemas that do not contain UNH2.5 information.

Hotfix information

A supported hotfix is available from Microsoft. However, this hotfix is intended to correct only the problem that is described in this article. Apply this hotfix only to systems that are experiencing this specific problem.

If the hotfix is available for download, there is a "Hotfix download available" section at the top of this Knowledge Base article. If this section does not appear, submit a request to Microsoft Customer Service and Support to obtain the hotfix.

Note If additional issues occur or if any troubleshooting is required, you might have to create a separate service request. The usual support costs will apply to additional support questions and issues that do not qualify for this specific hotfix. For a complete list of Microsoft Customer Service and Support telephone numbers or to create a separate service request, visit the following Microsoft Web site: - Note The "Hotfix download available" form displays the languages for which the hotfix is available. If you do not see your language, it is because a hotfix is not available for that language.

Prerequisites

You must have Microsoft BizTalk Server 2006 R2 installed to apply this hotfix.

Restart requirement

You do not have to restart the computer after you apply this hotfix. However, you must restart the BizTalk Host Instance service after you apply this hotfix.

Hotfix replacement information

This hotfix does not replace any other hotfixes.

File information

The English version of this hotfix has the file attributes (or later file attributes) that are listed in the following table. The dates and times for these files are listed in Coordinated Universal Time (UTC). When you view the file information, it is converted to local time. To find the difference between UTC and local time, use the Time Zone tab in the Date and Time item in Control Panel.

Microsoft BizTalk Server 2006 R2

Microsoft has confirmed that this is a problem in the Microsoft products that are listed in the "Applies to" section.

For EDIFACT-encoded messages, BizTalk Server determines a custom namespace by using the message type (UNH2.1), message version number (UNH2.2), message release number (UNH2.3), assigned code (UNH2.5), functional group ID (UNG2.1), and application send code qualifier (UNG2.2) from the header of the incoming interchange. Then,BizTalk Server tries to find a match between these values and the values for the UNH2.1, UNH2.2, UNH2.3, UNH2.5, UNG2.1, and UNG2.2 properties in the Enable custom transaction set definitions grid on the EDIFACT interchange processing properties page. If it finds a match, it will use the Target namespace identified in the same row of the grid to determine which schema to use to validate and process the message. If the target namespace is not determined, then the default target namespace is used. If no namespace is identified in the Default target namespace field, or if no party is identified, BizTalk Server will use the target namespace identified in the global party properties. By default, it ishttp://schemas.microsoft.com/BizTalk/Edi/EDIFACT/2006.

For more information about party resolution, schema discovery, and authorization for received EDI messages in BizTalk Server 2006 R2, visit the following Microsoft Developer Network (MSDN) Web site: For more information aboutconfigure EDIFACT interchange processing properties, visit the following Microsoft Developer Network (MSDN) Web site: