Schema Discovery

Goal: 

To describe how Schema Discovery is done within Engine Receive and Engine Send pipelines.

Engine Receive: 

A schema is required to validate and transform the envelopes/headers and the individual documents within the interchange during parsing. All the envelope validation is done against the control schemas shipped within BaseArtifact.dll. Once the envelope validation is done, R2 engine uses the following concatenation process to discover an individual schema:

{NameSpace}#{Standard}_{VersionRelease}_{DocType}

For example: http://schemas.microsoft.com/BizTalk/EDI/X12/2006#X12_00401_810

In the above example

• NameSpace = http://schemas.microsoft.com/BizTalk/EDI/X12/2006
• Standard = X12 (or EFACT for EDIFACT)
• VersionRelease = 00401
• DocType = 810

X12

NameSpace:

• NameSpace comes from the party to which the document resolves to, otherwise from Global Settings*

Version/Release:

Applicable if GS07 is valued as X

• The first 5 chars of GS08 give the relevant information
  • Char 1 to 3 provide version
  • Char 4 to 5 provide release

If GS07 is not equal to X or GS08’s first 5 characters don’t provide a match

• ISA12 provides the version/release information

DocType:

• ST01 gives the DocType

EDIFACT

NameSpace:

• NameSpace comes from the party to which the document resolves to, otherwise from Global Settings*

Version/Release:

• UNH2.2 gives the Version
• UNH2.3 gives the Release

DocType:

• UNH2.1 gives the DocType

*For each party, there is a default NameSpace defined under Party as Interchange Sender/Interchange Processing Properties section. This default NameSpace is used in most of the cases, however R2 gives customers the ability to override this default NameSpace through the use of Custom Transaction Set definitions. In case of X12, customers can define their target NameSpace for a party based on GS2 and ST1 of the document. If these 2 fields in the document match the one specified in PAM, the namespace defined in the target namespace will be used rather than the default namespace.

This is useful in cases where a 850 schema out of the box is deployed and is used for the majority of the cases. However tomorrow if a new partner wants to modify the existing 850 schema and setup a trading partner relationship with your business, you can deploy the modified 850 schema under a modified namespace, match the GS2 and ST1 from the instance in your PAM settings and can continue processing both the scenarios!

Once the engine has all the information, it uses this info to match the schemas deployed in the schema repository and uses that schema to parse the document.

Engine Send:

For individual transaction sets, Engine Send uses the individual transaction set schemas to validate/serialize those documents. For BIBO processing mode, Engine Send uses the control schema to validate all the envelope fields, and uses the individual transaction set schemas to validate individual transaction sets.  

Like Receive, Engine Send uses the same concatenation process to discover an individual schema:

{NameSpace}#{Standard}_{VersionRelease}_{DocType}

However all this information is already present in the XML document itself.

Individual Transaction Sets:

 <gen0:X12_00401_810 xmlns:gen0=http://schemas.microsoft.com/BizTalk/EDI/X12/2006>

<ST>

<ST01>810</ST01>

<ST02>3313</ST02>

</ST>

……

……

<SE>

<SE01>90</SE01>

<SE02>3313</SE02>

</SE>

In the above example, the first line contains all the information. The first part after X12 gives the version/release (in this case it is 00401), the second part gives the DocType (in this case it is 810), and the namespace is http://schemas.microsoft.com/BizTalk/EDI/X12/2006.

BIBO:

The node TransactionSet DocType has all the information

<TransactionSet DocType=http://schemas.microsoft.com/BizTalk/EDI/X12/2006#X12_00401_810 TransactionSetActivityId=”“>

<ns0:X12_00401_810 xmlns:ns0=http://schemas.microsoft.com/BizTalk/EDI/X12/2006>

As you see, it has the same format as the individual transaction set, and the same logic is applied. 

Once the engine has this information, it uses this info to match the schemas deployed in the schema repository and uses that schema to serialize the document.

End Note:

I hope this information has been useful to you. As always, your comments/questions are more than welcome!

Thanks

Mohsin Kalam