FIX: The BizTalk Server EDI Adapter only supports a limited set of document types in BizTalk Server 2004

The Microsoft BizTalk Server EDI Adapter only supports a limited set of document types. The EDI Adapter will not work with any document types other than the ones for which it provides schemas. You may receive the following error message when you try to use your own schemas for document types for which BizTalk Server does not provide schemas:

Service pack information

To resolve this problem, obtain the latest service pack for Microsoft BizTalk Server 2004. For more information, click the following article number to view the article in the Microsoft Knowledge Base:

Hotfix information

Prerequisites

No prerequisites are required.

Restart requirement

You do not have to restart your computer 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 tool in Control Panel. Note Because of file dependencies, the most recent hotfix that contains these files may also contain additional files.

Install notes

1. Unzip or copy all files in the root of your BizTalk 2004 installation directory. By default, the installation directory is C:\Program Files\Microsoft BizTalk Server 2004.
2. Run the updateEDI.sql script that is located in the EDI\Adapter\Bin\Config folder against the BizTalk Base EDI database (BizTalkEDIDb), or by optionally using the updateEDI.bat batch file (Modify the server name and the database name first).

Microsoft has confirmed that this is a problem in the Microsoft products that are listed in the "Applies to" section. This problem was corrected in BizTalk Server 2004 Service Pack 1.

When you install this hotfix, BizTalk Server 2004 can work with any EDI document type, even for those document types for which BizTalk Server does not provide XSD schemas.

Out-of-the-box delivered schemas

The following schemas are included with BizTalk Server 2004:Important At the time of release, only these schemas are tested with BizTalk Server 2004. They are the only schemas that are known to work with BizTalk Server 2004.

Format versions supported

The following format versions (Control Segments versions) are supported by the Base EDI Adapter, for the X12 and EDIFACT standards, after you apply this hotfix.

X12

The Base EDI Adapter supports the following X12 format versions: 2040, 3010, 3020, 3030, 3040, 3050, 3060, 3070, 4000, 4010, 4020, 4030, 4040 and 4050.

When an interchange is received that has a higher version of the control segments than the 4050 version (for example, when the version that is indicated in the ISA segment is higher than "00405"), the system will try to parse it with the highest version (for example, 4050).

This format version is not related to the transaction version. The transaction version is specified in the GS segment. As long as the user has a schema that represents the transaction type and transaction version that the user wants, the system can accept that version on the inbound and will generate it on the outbound.

EDIFACT

The Base EDI Adapter supports the following EDIFACT format (or Syntax) versions: UNOA and UNOB, versions 1 through 3.

Note The following Microsoft Knowledge Base (KB) article describes a design-change hotfix that enhances envelope support in the Base EDI Adapter:The EDIFACT interchanges must have the correct indication of the syntax in the UNB segment. Interchanges that are received that have an indication of a certain syntax in the UNB segment (for example UNOA) must follow the character set that belongs to that syntax. The syntax identifier in the UNB segment is mandatory.

Subsets of the main standards

Note that only the main standards are supported with the Base EDI Adapter. For example, the following subsets exist within the X12 standard:

• VICS
• WINS
• UCS
• TCIF

The following subsets exist within the EDIFACT standard:

• EANCOM
• ODETTE
• Inovert

No subsets are supported by the Base EDI Adapter that is included with BizTalk Server 2004. To support these subset variations, you must use Covast�s EDI Accelerator.

Authorizing schemas that did not ship out-of-the-box

For all the schemas that ship out-of-the-box, you can configure the ones that are authorized or not on the Send Port and Receive Location dialog boxes for the Base EDI Adapter transport.

For the schemas that do not ship out-of-the-box, you can only specify that they are (all) allowed (on the Receive Location dialog box) and the default format version to use for the X12 and EDIFACT instances on the outbound (on the Send Port dialog box).

These settings can be found in the "Supported Document Types" category on the Receive Location and Send Port Base EDI Adapter transport settings dialog boxes. For inbound authorization, set Accept all unlisted documents to Yes in the Receive Location configuration. For outbound authorization, set Accept all unlisted documents to Yes in the Send Port configuration.

Also, set Default X12 format version for X12 or Default EDIFACT format version for EDIFACT, or both, to the correct format (envelope) version.

Base EDI Adapter schema requirements

When you create customized EDI schemas to use with the Base EDI Adapter, those schemas must follow a number of rules. BizTalk Server 2004 is much stricter than earlier versions of BizTalk Server. This section describes the rules and requirements to use custom or migrated schemas with the Base EDI Adapter.

EDI element and segment declarations

This section discusses the known requirements that an XSD schema must meet to be accepted and to be correctly used by the Base EDI Adapter. Starting with the lowest level object, the following are the element declaration requirements for an EDI schema:

Elements

Every EDI element is defined in XSD as xs:attribute. If the element is a child of a composite element, the element must use the following naming convention:For example, if the parent segment is named C040, the child elements must be named C04001, C04002, C04003 and so on. The composite element is defined later in this section.

The important attributes within an EDI element are in the b:fieldInfo node and are as follows:

• edi_datatype This attribute must be one of the following values: N, N0 � N9, R, ID, AN, DT, TM. Any other value in this attribute is not permitted.
• format This attribute is mandatory when the edi_datatype attribute is either DT or TM.
  • When the edi_datatype attribute is DT, the format must be one of the following values: DDMMYYYY, MMDDYYYY, YYYYMMDD, DDMMYY, MMDDYY, YYMMDD.
  • When the edi_datatype attribute is TM, format must be one of the following values: HHMMSS or HHMM.
• codelist This attribute is optional and maps to a set of values within EDICodelist.mdb. By default, this Microsoft Access database is located in the %ProgramFiles%\Microsoft BizTalk Server 2004\EDI\Adapter\CodeLists folder. You only use a set of values from this code list when the edi_datatype attribute is ID. An alternative to using a code list is to use an Enumeration under the simpleType node.
  
  Note To extend the codelist database, see the "Additions and changes to code lists" section.
• sequence_number This attribute is used to define the sequence within the parent node. It is optional. The default order of elements is the order that they appear in the file.

Composite elements

Composite elements contain a set of elements that are related to each other. The usage of composites implies that special separators are used in the native EDI files. In EDIFACT for example, components of a composite are separated by default by a : instead of the usual element separator +.The name attribute is mandatory. It has to meet a rule. When it is the first occurrence, it should correspond to the value of the tag_name attribute in the recordInfo child of this segment. When it is not the first occurrence of this segment, an _ should be added with a unique sequence number, as shown in the following example: The value of the tag_name attribute is prescribed by the X12 or EDIFACT standard, and should not be chosen randomly.

The important attributes within an EDI composite element are in the b:recordInfo node and are as follows:

• tag_name This attribute must match the composite name without the sequence number. For example, if the composite element is either C040 or C040_1, the tag_name attribute must have the value C040.

Segments

• Segments with composite element

  <xs:element name="name of segment">
   <xs:annotation>
    <xs:appinfo>
     <b:recordInfo 
  	tag_name="value defined according to X12 or EDIFACT standard"
  	structure="delimited" 
  	delimiter_type="inherit_record" 
  	field_order="postfix" 
  	escape_type="inherit_escape" 
  	count_ignore="yes" 
  	trigger_field="" 
  	trigger_value="" 
  	xmlns:b="http://schemas.microsoft.com/BizTalk/2003">
          Insert definition of zero or more conditions 	
     </b:recordInfo>
    </xs:appinfo>
   </xs:annotation>
   <xs:complexType>
    <xs:sequence>	
     Refers to definition of composite. 
     <xs:element ref="name of composite">	
        <xs:annotation>
       <xs:appinfo>
        <b:recordInfo 
  	structure="delimited" 
  	delimiter_type="inherit_record" 
  	field_order="postfix" 
  	escape_type="inherit_escape" 
  	count_ignore="yes" 
  	xmlns:b="http://schemas.microsoft.com/BizTalk/2003">
        </b:recordInfo>
       </xs:appinfo>
      </xs:annotation>
   </xs:element>
    </xs:sequence> 
     Insert definiton of zero or more elements.
   </xs:complexType>
  </xs:element>
  

• Segments without a composite element

  <xs:element name="name of segment">
   <xs:annotation>
    <xs:appinfo>
     <b:recordInfo 
  	tag_name="value defined according to X12 or EDIFACT standard"
  	structure="delimited" 
  	delimiter_type="inherit_record" 
  	field_order="postfix" 
  	escape_type="inherit_escape" 
  	count_ignore="yes" 
  	trigger_field=" "
  	trigger_value=" "
  	xmlns:b="http://schemas.microsoft.com/BizTalk/2003">
          Here, definitions of conditions can be inserted. 	
     </b:recordInfo>
    </xs:appinfo>
   </xs:annotation> 
   <xs:complexType>	
  	Insert definition of one or more elements.
  </xs:complexType>
  </xs:element>
  

The name attribute is mandatory. It has to meet a rule. When it is the first occurrence, it should correspond to the value of the tag_name attribute in the recordInfo child of this segment. When it is not the first occurrence of this segment, an _ should be added with a unique sequence number, as shown in the following example: The value of the tag_name attribute is prescribed by the X12 or EDIFACT standard, and should not be chosen randomly.

In this scenario, sequence number is only used when the segment has been repeated. For example, if BGM exists, the next occurrence of BGM must be named BGM_1.

The important attributes within an EDI segment are in the b:recordInfo node and are as follows:

• tag_name This attribute must match the segment name without the sequence number. For example, if the segment is named either BGM or BGM_1, the tag_name attribute must have the value BGM.

Loop-segments

Loop-segments may contain any one or more of the following:

• Other loop-segments
• Segments with composite elements
• Segments without composite elements

Loop-segments may not contain elements. Loop-segments must use the following naming convention: The important attributes within an EDI loop-segment are in the b:recordInfo node and are as follows:

• There must not be a tag_name attribute.

rootNode

This part of the XSD is mandatory.The rootNode can only contain one or more of the following items:

• Loop-segments
• Segments with composite elements
• Segments without composite elements

The rootNode must use the following naming convention:

• X12_[value of standards_version]_[value of document_type]
• EFACT_[value of standards_version]_[value of document_type]

Note The format that is used depends on the actual EDI standard, the EDI version, and the document type.

<xs:schema>

This part of XSD is mandatory.The b:schemainfo node appears under xs:schema. The important attributes within xs:schema are in the b:schemaInfo node and are as follows:

• root_reference This attribute should match the name of the root node.
• document_type This attribute must be the actual document type. For example, this attribute must be � 850 for the X12 document type or INVOIC for the Edifact document type.
• standard This attribute must have a value of either X12 or EDIFACT.
• standards_version This attribute must be the version for the particular standard. For example, this attribute must be one of the following: � 4010 for X12 or d93a for Edifact.
  
  Note The standards_version must match the standards_version part of the rootNode name exactly, including being case-sensitive.

EDI schema element and segment structure

Within XSD, there are many ways to obtain the desired output. With the Base EDI Adapter for BizTalk Server 2004, there is only one acceptable structure for an EDI schema. Each segment must have a declaration at the root of the schema. The segment must then use a reference node to denote where it fits in the document. The following two examples illustrate both an incorrectly formatted structure for the Base EDI Adapter and a correctly formatted structure for the Base EDI Adapter.

Example 1: Incorrect form for the Base EDI AdapterExample 2: Correct and acceptable form for the Base EDI Adapter

Additions and changes to code lists

Code lists for format versions that are not shipped out-of-the-box must be added to the code list database manually. The name of the code database is Edicodelist.mdb (Microsoft Access database).

The Edicodelist.mdb file is in the Program Files\Microsoft BizTalk Server 2004\EDI\adapter\Codelists folder. The database contains a table for every format version, When you add a new format version, you can copy a similar table and then rename it.

The table name must have the following format: Standard_StandardsVersion. For example, "EDIFACT_D93B" or "X12_4050".

Other code set values must be added or be removed manually from the Edicodelist.mdb database. Entries can be added to existing tables to extend the number of code sets.

This information is only used at design time. The tables are accessed when the user executes the ValidateSchema function for an EDI Schema in the BizTalk Solution Explorer. The following XSD features are not supported:

• Inheritance
• Substitution groups
• No group order except "sequence" is allowed. Specifically, "choice" and "all" are not supported.
• anyElement
• anyAttribute
• Import
• Include
• Redefine

Miscellaneous EDI schema limitations

• No floating segment support. This limitation is the same as in Microsoft BizTalk Server 2002.
• Very limited binary segment support. This limitation is the same as in BizTalk Server 2002.
• EDI Envelope data is not conveyed on the inbound. Therefore, the data is not available for use in the BizTalk Mapper or in orchestrations. This limitation is the same as in BizTalk Server 2002.
• EDI Envelope layouts cannot be customized or modified. This limitation is the same as in BizTalk Server 2002.
• The list of supported X12 Functional Group Identifiers is fixed according to the 4050 version. This means you cannot use transaction sets that were introduced after the 4050 version, because the system does not know which functional group identifier belongs to it (because that is not part of the schema).
• The EDI Annotation <b:RecordInfo count_ignore="yes"> is ignored by the Base EDI Adapter. The Base EDI Adapter uses hard-coded technology to count the segments in EDI transactions.
• The BizTalk Server 2004 Base EDI Adapter uses stricter EDI character set validations than BizTalk Server 2002. For example, when an EDIFACT UNOA interchange is received, it will validate the characters in the interchange according to the defined character set that belongs to the UNOA syntax (which is a subset of ISO-646).

For additional information, click the following article number to view the article in the Microsoft Knowledge Base: