Notes on creating EDI schemas for BizTalk Server 2004
Originally BizTalk Server 2004 has the limitation of adding new EDI schemas. However SP1 now allows to add new schemas and the KB article 840113 describes how to implement EDI schemas for BizTalk. I had implemented new EDI schemas with the KB article. But I realized right away that some information is missing.
I summarized additional information which the KB article doesn’t mention. I hope this would be helpful to someone who wants to implement EDI schemas, especially EDIFACT schemas.
1. The KB 840113 says that the codelist attribute is allowed only when the edi_datatype attribute is ID. But, EDIFACT doesn’t have the date type “ID”. In the case of EDIFACT, the codelist is also allowed when edi_datatype is AN.
2. When you use “N” as edi_datatype, you should restrict it with <xs:restriction base="xs:float" />.
3. You have to specify minOccurs=”0” attribute when the segment is conditional.
4. You have to specify maxOccurs=”unbounded” when the number is over 9999.
5. When you create “the segment with composite segment”, you have to be careful of the order of elements and composite segments.
You can specify the order by the element names. For example, The BGM segment in EDIFACT/2911 should have BGM02, BGM03, BGM04 elements and C002 composite segment.
The important thing is that you have to start BGM composite-element names from BGM02 rather than BGM01. It drives that C002 composite segment will be first place in BGM followed by BGM02, BGM03, and BGM04. The composite segment name doesn’t matter regarding this order.
6. If you look into the schemas provided by default, you may be surprised to see lots of annotation elements. Actually, you don’t have to do that when you create your own schemas.
The annotation child element isn’t necessary to the element which refers other element.
For example, in the following example, the annotation child element isn’t necessary for #1 case.
#1. <xs:element ref="BGM" />
#2. <xs:element name="BGM">
<xs:annotation>
Bla bla bla
</xs:annotation>
7. The recipient and sender information in UNB header could have the conditional “Address for reverse routing” element. But, the address isn’t allowed in UNG header. You have to be careful when receiving the EDIFACT messages if they use UNG headers and the UNB includes the “Address for reverse routing” value like following.
UNB+UNOA:1+7654321:ZZ:7654321+1234567:ZZ: +040906:1448+24022++PAYORD'
UNG+PAYORD+7654321:ZZ+1234567:ZZ+040906:1448+11923+KE+1:911'
To process such messages you need some extra configuration before process it.
1) You need a sender party with URI EDI://7654321:ZZ:7654321
2) You have to add the alias EDI://7654321:ZZ: to the sender party of 1)
(The last colon of the alias of 2) is mandatory.)
3) You have to create two receive locations for both EDI://7654321:ZZ:7654321 and EDI://7654321:ZZ:.