Using Schematron in Oracle SOA Suite 11g for Validating XML

Schematron is an XML schema language, and it can be used to validate XML contents in an XML payload. The following article will talk about how can we use the Schematron feature in Oracle SOA Suite 11g.

Schematron Basics

Schematron defines a set of rules and checks that are applied to an XML instance. Schematron takes a unique approach to schemas in that it focuses on validating document instances instead of declaring a schema (as the other schema languages do).

Schematron relies almost entirely on XPath query patterns for defining these rules and checks. With just a subset of XPath, powerful XSLT stylesheets can be created to process very complex XML instances.

Schematron Structure

A Schematron XML document consist of a schema element in the Schematron namespace: http://www.ascc.net/xml/schematron. The schema element contains one or more pattern elements. Pattern elements allow the user to group schema constraints logically. Some examples of logical groupings are: Text Only Elements, Valid Root Element, Check for ID Attribute.

Pattern elements have a name attribute. They may also have a see attribute that refers to a URL for user documentation of the schema.

Rule elements define a collection of constraints on a particular context in a document instance (for example, on an element or collection of elements). This is very similar to XSLT templates, which are fired with respect to a node or group of nodes returned by an XPath expression. If we go back to the XSLT stylesheet we defined earlier:

<xsl:template match='inputVariable'>

The match attribute causes the XSLT processor to evaluate the XPath expression inputVariable and then instantiate the template relative to the inputVariable element. The contents of a rule element operate within the context of the elements matched by its context attribute.

Rule elements may contain assert and report elements. Both elements are conditionally instantiated depending on the XPath evaluation of their test attribute. The only difference is that assert elements are instantiated if the XPath expressions evaluates to false, while the report elements are instantiated if it evaluates to true. (The general intent is that assert is used to detect errors, while report can be used to report affirmative qualities of an instance.)

The assert/report mechanism is similar to the XSLT xsl:if element in our example stylesheet above, which also has a test attribute that determines if the contents of the xsl:if element are instantiated in the resulting XML tree.

Note that a node can only be the context of a single rule (the first matching rule the processor comes across) within a pattern. However, a node can be matched multiple times within different patterns. Thus pattern groupings are important. Every match of a context node can be considered a discrete constraint.

These elements allow authors of Schematron schemas to provide functional (and humanly readable) feedback about invalid XML instances. The user-defined feedback makes Schematron’s unique approach to schema declaration more powerful than other schema languages.

Finally, assert and report elements have a name element to use for substituting the name of an element into the output stream. The name element has an optional path attribute which returns the node whose tag name will be inserted in place of the name element. If the path attribute isn’t specified the name of the current context node is used instead. This element is often used by assert and report elements to identify the tag name of an offending element within the validation message.

After a Schematron schema is defined, a Schematron XSLT stylesheet is used to transform the schema to a validating stylesheet. This stylesheet can then be applied to XML instances for validation purposes. There are several such Schematron stylesheets, each of which provides special functionality.

Getting Started

Prerequisites

• SOA Suite 11gPS2 in installed in your local machine.

• A SOA Domain is created in your local machine. For this tutorial i use a all in one single server domain.
  http://wiki.oracle.com/page/Oracle+SOA+Suite+11g%3A+Hown+To+Create+All+In+One+AdminServer

• JDeveloper is installed in your local machine.
• An Oracle Database (11g preferably) is accessible from the SOA domain.

Tutorial

Follow the step by step tutorial below. A lot of self explanatory things are shown as pictures here.

• Open JDeveloper and create a new ‘SOA Application’. Name it as ‘DemoSOAApplication’. Name the project as ‘DemoSOAProject’. Make sure that ‘SOA’ is selected as the project profile. Select the composite type as ‘Empty Composite’.
• For the purpose of this tutorial we create a simple File Adapter Component to read a simple xml file containing a Journal entry.
• We also create a Database Adapter Component to write the content of the file into a DB Table.
• We then pass this file to a Mediator Component that will do the following
  1. Validate the XML structure against the schema.
  2. Validate the XML with a Schematron file for some basic field validations.
  3. Transform the xml from a file source to the corresponding DB Adapter schema.
  4. Insert the modified message in the Database.
• Here is how the composite will look like

• Double Click on the Mediator component. Check the ‘Validate Syntax (XSD)’ option. Click on the icon at ‘Validate Semantic’ and use the schematron.sch file for Schematron validation.

• A sample file for the project is as under.

<schema xmlns="http://www.ascc.net/xml/schematron" >
<pattern name="Journal Validation">
<rule context="/Journal/File">
<assert test="JournalCount > 0">Journal Count Cannot be Zero</assert>
 </rule>
</pattern>
<pattern name="Batch Valiation">
<rule context="/Journal/File/Batch">
<assert test="BatchName = 'CRM'">Batch Name have to be CRM</assert>
<assert test="number(BatchTotal) >0">Batch Total cannot be less than Zero</assert>
<assert test="number(BatchRecordCount) = count(.)">Batch Record Count has to match the number of Batches</assert>
 </rule>
</pattern>
</schema>

Here is what semantic validation would do

1. Validate that the JournalCount is greater than zero.
2. Matches the BatchName in the Journal with a predefined string.
3. Validates whether BatchRecordCount matches the number of Batch elements in the Journal

• Now deploy the JDeveloper Project to the SOA Server. Drop a sample test xml file in the directory which the file adapter is polling.

 <Journal xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance">
 <File>
 <JournalCount>0</JournalCount>
 <TotalDR>425</TotalDR>
 <TotalCR>450</TotalCR>
 <JournalDate>2011-04-06T09:30:47Z</JournalDate>
 <Batch>
 <BatchName>HRM</BatchName>
 <BatchDescription>Sample Test Batch</BatchDescription>
 <SourceName>BRM</SourceName>
 <SetOfBooksName>JournalSample</SetOfBooksName>
 <BatchTotal>400</BatchTotal>
 <BatchRecordCount>4</BatchRecordCount>
 <Filler>InValid Batch</Filler>
 </Batch>
 </File>
</Journal>

• Login to the EM console to view the instance. You will observe that the instance status for the composite is ‘Faulted’.

• Click on the Instance ID to view the Audit trail for the exception. You can see that the exception is caught at the Mediator level and is related to the semantic validations. The error messages thrown are the same that we configured in our schematron.sch file. You can even use the Fault Management framework to action these faults.

• Now instantiate the composite again but this time with a valid file.

<Journal xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance">
 <File>
 <JournalCount>5</JournalCount>
 <TotalDR>425</TotalDR>
 <TotalCR>450</TotalCR>
 <JournalDate>2011-04-06T09:30:47Z</JournalDate>
 <Batch>
 <BatchName>CRM</BatchName>
 <BatchDescription>Sample Test Batch</BatchDescription>
 <SourceName>BRM</SourceName>
 <SetOfBooksName>JournalSample</SetOfBooksName>
 <BatchTotal>400</BatchTotal>
 <BatchRecordCount>1</BatchRecordCount>
 <Filler>Valid Batch</Filler>
 </Batch>
 </File>
</Journal>

• This time the Instance status is ‘Completed’. Click on the Instance ID to see the Audit trail.

• Also log in to the DB as the schema user to verify whether the DB insert did happen.

The SQL for the above project can be downloaded from here.

The JDeveloper workspace for the project can be downloaded here.

I have also discussed how you can use the Schematron feature from a BPEL process by using a custom Xpath function. See the example at the below link.

https://beatechnologies.wordpress.com/2011/08/03/schematron-validation-in-oracle-bpel-using-custom-xpath-function/