THIS IS A TEST INSTANCE. ALL YOUR CHANGES WILL BE LOST!!!!
...
| Code Block | ||
|---|---|---|
| ||
<route>
<from uri="direct:start" />
<to uri="schematron:///usr/local/sch/schematron.sch" />
<log message="Schematron validation status: ${in.header.CamelSchematronValidationStatus}" />
<choice>
<when>
<simple>${in.header.CamelSchematronValidationStatus} == 'SUCCESS'</simple>
<to uri="mock:success" />
</when>
<otherwise>
<log message="Failed schematron validation" />
<setBody>
<header>CamelSchematronValidationReport</header>
</setBody>
<to uri="mock:failure" />
</otherwise>
</choice>
</route> |
...
| Tip | ||
|---|---|---|
| ||
Schematron rules can change with business requirement, as such it is recommended to store these rules somewhere in file system. When the schematron component endpoint is started, the rules are compiled into XSLT as a Java Templates Object. This is done only once to minimise the overhead of instantiating Java Templates object, which can be an expensive operation for large set of rules and given that the process goes through four pipelines of XSLT transformations. So if you happen to store the rules in the file system, in the event of an update, all you need is to restart the route or the component. No harm in storing these rules in the class path though, but you will have to build and deploy the component to pick up the changes. |
Schematron rules and report samples
Here is an example of schematron rules
...