OOW 2012 XML Business Rules Validation Schematron - Emiel Paasschens

Business Rules Validation

in the SOA Suite with

Schematron

PROGRAM

• XML, XSD, X-Path, XSLT

• XML (Business Rule) Validation

• Validation Gap: Schematron

• Examples

• Schematron in the SOA Suite

• Business Rules Case

• Discussion

XML

XML: eXtensible Markup Language

Store almost any kind of data in a structured form that applications running on any platform can easily import and process and is human readable.

XML became the underlying standard for manynew Software standards:

• Web: XHTML, RSS, Atom, XMPP (chat), AJAX

• Web Services: WSDL, SOAP (Simple Object Access Protocol)

• Documents: ODF (Open Document Format), MS Office OOXML (docx), Apple iWork

• Etc., etc

XML EXAMPLE

<?xml version="1.0"?>

<dining-room>

<manufacturer>The WoodShop</manufacturer>

<table type="round" wood="maple">

<price>$199.99</price>

</table>

<chair wood="maple">

<quantity>6</quantity>

<price>$39.99</price>

</chair>

</dining-room>

XML Schema:

• Define structure of xml including data type of elements

and contstraints

• Schema is also in XML format

So there is a XML schema that defines an XML

schema

• Can be seen as the “ERD” or “DB Design” for XML

XSD

XSD EXAMPLE

<?xml version="1.0" encoding="UTF-8" ?>

<xsd:schema xmlns:xsd="http://www.w3.org/2001/XMLSchema"

xmlns="http://amis.nl/schematrondemo/common"

targetNamespace="http://amis.nl/schematrondemo/common"

elementFormDefault="qualified">

<xsd:element name="Employees" type="tEmployees"/>

<xsd:complexType name="tEmployees">

<xsd:sequence>

<xsd:element name="Employee" type="tEmployee"

minOccurs="0" maxOccurs="unbounded"/>

</xsd:sequence>

</xsd:complexType>

<xsd:complexType name="tEmployee">

<xsd:sequence>

<xsd:element name="Name" type="xsd:string"/>

<xsd:element name="Salary" type="xsd:decimal"/>

</xsd:sequence>

<xsd:attribute name="id" type="xsd:long" use="required"/>

<xsd:attribute name="manager_id" type="xsd:long" use="optional"/>

</xsd:complexType>

</xsd:schema>

XPATH

XML Path Language (XPath):

• Is primarily used to address the nodes of an

XML document modeled as a tree of nodes

• Is named after its use of a path notation for

navigating through the hierarchical structure

of an XML document

• Uses a compact, non-XML syntax to form

expressions for use in Uniform Resource

Identifier (URI) and XML attribute values

• Fully supports XML Namespaces

• Is designed to be used by XML applications

and XSLT (and XQuery)

XPATH EXAMPLES

//price 2 element nodes

/*/*/@wood 2 attribute nodes

//@wood/.. 2 nodes (table and chair)

/dining-room/*[price > 100]/@wood 1 attribute node

//price[1]/text() 2 text values! (both price are first)

(//price)[1]/text() 1 text value (first from result collection)

XML STYLESHEET (XSLT/XSL)

XSLT processing takes an XML source document and an XSLT stylesheet, and produces an output document

The XSLT stylesheet:

• Is an XML document itself

• Contains rules that map patterns in the input to static XML to send into the output

• Uses XPath expressions to get data from the XML source

• Can contain XSLT logic (if, choose) and operators (for-each) to process the XML source

The output document is typically another XML document, but XSLT can be used to create other plain-text documents as well.

XSLT EXAMPLE *

XML (BUSINESS RULE) VALIDATION

Three types of XML Validation

• On data / element itself:

Data type & Constraints

• XML Structure:

Element names & Child/Parent Constraints

• Between data elements:

Business Rules

XML (BUSINESS RULE) VALIDATION

Three types of XML Validation

• On data / element itself:

Data type & Constraints

XSD

• XML Structure:

Element names & Child/Parent Constraints

XSD partially! (no conditional)

• Between data elements:

Business Rules

??

SCHEMATRON

• Used for validating an XML Document

• Validation of Business Rules

• Validation of conditional structure

• Rules are defined in Schematron format whichis also XML

• Is built on XPath expressions

• Is an ISO/IEC Standard

• Basically is a double XSTL transformation

SCHEMATRON

Usage:

• Define your Business Rules in an XML

document in a fixed format and structure

(Schematron) with the usage of XPath

expressions

• Transform your Business Rules XML using the

Schematron XSLT to create your Business

Rules XSLT.

• Use your Business Rules XSLT to validate your

XML data (Transformation). Output are the

errors, so no output means the data is valid.

SCHEMATRON

• Double XSLT transformation:

• 1. Rules.xml with Schematron.xslt =>

Rules.xslt

• 2. Data.xml with Rules.xslt => Result

SCHEMATRON FILE


<schema xmlns="http://www.ascc.net/xml/schematron">

<pattern name="patternName">

<rule context="x-path">

<assert test="x-path condition">Error message</assert>

<report test="x-path condition">Error message</report>

...

</rule>

</pattern>

<pattern name="patternName">

...

</schema>

SCHEMATRON EXAMPLE 1


<schema xmlns="http://www.ascc.net/xml/schematron" >

<pattern name="Number of characters in an abbreviation">

<rule context="Afdeling">

<report test="string-length(@afk) < 2">There are not enough

letters in the abbreviation</report>

<report test="string-length(@afk) > 3">There are too much

letters in the abbreviation</report>

</rule>

</pattern>

</schema>

SCHEMATRON EXAMPLE 2


<schema xmlns="http://www.ascc.net/xml/schematron" >

<pattern name="Sum equals 100%.">

<rule context="Total">

<assert test="sum(//Percent) = 100">Sum percentage is not

100%.</assert>

</rule>

</pattern>

</schema>

SCHEMATRON IN THE SOA SUITE

• Default filename extension “sch”

• No report, so only assert tag! not(report)

• Define namespace prefixes with uri tag:<ns uri="http://amis.nl/schematrondemo/company" prefix="cmp" />

• Implemented in Mediator:

• „Feature‟: Generate HTTP error (e.g. return error with FireForget)

BUSINESS RULES CASE

Company HRM XML file company containing departments

containing employees:

• An employee may not be the manager of himself.

• All normal employees (so not a manager) must have a

manager.

• There is only one manager without a manager

(only one president).

• All employees should have less salary than any

manager

(manager = employee in department “Managers”).

• The relation manager and employee is a valid one, so

the manager of an employee must exist.

CASE EXAMPLE DATA

<Company><Department name="Ground Two" abbr="GR1">...</Department>

<Department name="Ground Two" abbr="GR2">

<Employees>

<Employee id="13" manager_id="20">

<Name>P. Pietersen</Name>

<Salary>1550</Salary>

</Employee>


<Name>S. Smit</Name>


</Employee>

</Employees>

</Department>

<Department name="Managers" abbr="MAN">

<Employees>

<Employee id="15">

<Name>M.A. Nager</Name>


</Employee>


<Name>L.E. Ader</Name>


SCHEMATRON BUSINESS RULE

IMPLEMENTATION

An employee may not be the manager of himself.

<pattern name="Employee may not be the manager of himself">

<rule context="//com:Employee[@manager_id]">

<assert test="@manager_id != @id">Employee may not manage himself</assert>

</rule>

</pattern>


IMPLEMENTATION

All normal employees (so not a manager) must

have a manager.

<pattern name="All normal employees have a manager">

<rule context=

"//cmp:Company/cmp:Department[@name!='Managers']/cmp:Employees/com:Employee">

<assert test="@manager_id">Employee must have a manager</assert>

</rule>

</pattern>


IMPLEMENTATION

There is only one manager without a manager

(only one president).

<pattern name="Only one manager without manager, mr president">

<rule context="//cmp:Company/cmp:Department[@name='Managers']/cmp:Employees">

<assert test="count(com:Employee[not(@manager_id)]) = 1">There should be

only one president</assert>

</rule>

</pattern>


IMPLEMENTATION

All employees should have less salary than any

manager

(manager = employee in department “Managers”).<pattern name="Managers earn more than normal employees">

<rule

context="//cmp:Department[@name!='Managers']/cmp:Employees/com:Employee">

<assert test="com:Salary <

min(//cmp:Department[@name='Managers']/cmp:Employees/com:Employee/com:Salary)">

Employee earns too much</assert>

</rule>

</pattern>


IMPLEMENTATION

The relation manager and employee is a valid

one, so the manager of an employee must exist.

<pattern name="Manager does not exist">


<assert test=

"//cmp:Company/cmp:Department[@name='Managers']/cmp:Employees/com:Employee[@id=c

urrent()/@manager_id]">No valid manager</assert>

</rule>

</pattern>

TOTAL SCHEMATRON BUSINESS RULE

IMPLEMENTATION<?xml version="1.0" encoding="UTF-8" ?>

<schema xmlns="http://www.ascc.net/xml/schematron">

<ns uri="http://amis.nl/schematrondemo/company" prefix="cmp" />

<ns uri="http://amis.nl/schematrondemo/common" prefix="com" />

<pattern name="Managers earn more than normal employees">

<rule context= "//cmp:Department[@name!='Managers']/cmp:Employees/com:Employee">

<assert test="com:Salary <

min(//cmp:Department[@name='Managers']/cmp:Employees/com:Employee/com:Salary)">Employee

earns too much: <value-of select="com:Salary"/></assert>

</rule>

</pattern>

<pattern name="Employee may not be the manager of himself">


<assert test="@manager_id != @id">Employee may not manage himself</assert>

</rule>

</pattern>

<pattern name="All normal employees have a manager">

<rule context=

"//cmp:Company/cmp:Department[@name!='Managers']/cmp:Employees/com:Employee">

<assert test="@manager_id">Employee must have a manager</assert>

</rule>

</pattern>

<pattern name="Only one manager without manager, the president">

<rule context="//cmp:Company/cmp:Department[@name='Managers']/cmp:Employees">

<assert test="count(com:Employee[not(@manager_id)]) = 1">There should be only one

president</assert>

...

DEMO

PERFORMANCE

When there are

1. a lot (hundreds) of Schematron rules and/or

2. your input data (payload) is huge

performance problems can arise.

PERFORMANCE

1. A lot (hundreds) of Schematron rules

This problem is the easiest to handle:

Split the Schematron file up in more files and

serialize them with Mediators.

Place the Schematron rules which fail most in the

first Mediator and the ones which fail least in the last

Mediator.

PERFORMANCE

2. Huge input data (payload)

This problem is quite tricky. Not only for Schematron

validation, but the SOA Suite in common!

Advise for Schematron validation is to split up the

payload (BPEL / OSB) in multiple chunks.

This can be a „vertical split‟, so divide at certain

elements.

But also an „horizontal‟ split, so ommit data which is

not necessary for the (chunk of) Schematron

validation rules.

Even a combination is possible!

With a split-join in the OSB or in BPEL with parallel

processing the output can be merged.

DISCUSSION

Statement:

“No Business Rules in the Middleware”