Create an Incredibly Robust ACORD XML Validation Facility That Can Be Used to Describe Arbitrarily Complex Validation Rules
The eiConsole for ACORD allows you to perform ACORD XML Validation and do away with the time consuming & error-prone process of desk checking sample feeds. It offers an incredibly robust data validation facility that can be used to describe arbitrarily complex validation rules. Once the validation model has been established, it can be used in place of manual processes to facilitate implementation. Once in production, the same set of validation rules can be used to maintain data quality – catching errors closer to the source and reporting them in an easily understood format. (Note that PilotFish is also the engine behind ACORD’s own TCF (Testing and Certification Facility). ACORD is also a licensee of the eiConsole. ACORD members should visit the ACORD website to find out details about a special license for the eiConsole for ACORD for members.)
Within the eiConsole for ACORD, the process for ACORD XML Validation is very straightforward.
In the example (below) – we show a simple eiConsole interface that will read data from a directory, validate it, and then drop the results in another directory.
Generally, ACORD XML Validation is handled by the Validation Processor within the eiConsole for ACORD. The user is presented with a Processor dialog box (shown below).
The Validation Processor is pointed at a particular validation model made up of several Model Files. Each Model File represents a set of rules to be run against the inbound data. Validation Models are developed either in XML by hand, or using the eiConsole’s Validation Model Editor.
The eiConsole for ACORD’s Validation Model Editor defines a set of rules to be run against the inbound document. These Rules can also be executed against a subset of nodes within a document as described via an XPath expression. Below in the tree, you see the red node representing the root, the blue nodes representing different node sets against which you’ll run rules, and the green nodes representing the validation rules themselves.
Validation rules are configured by selecting a validator and configuring it. The eiConsole for ACORD comes with a list of predefined validator types. For instance – you can validate the format of a date, use XSLT to validate, use the W3C standard Schematron, and validate numeric ranges and patterns using XML schema, etc.
To add a rule or create a new rule, you would select its validator, and then customize that validator with the appropriate configuration options.
Once you’ve configured all of the rules for a document, there’s a testing panel where you can load a sample file and execute the validation rules against it.
Validation results are depicted as an HTML report. Each row invocation will result in a row in the grid, including the level of information, the rule that was executed, and the associated error or success message.
You’ll note that many of the different error messages are easily understood. This is not the case when using things like a SOAP fault, or when using other standard schema validation tools.
Once you’ve finished configuring the validation model, you continue to configure the rest of the Processor. Note that there are a number of different types of Validation Reporters available. The Validation Reporter drop-down allows you to specify how this error information will be passed to the rest of the interface. You’ll note that the default is the HTML Validation Reporter. This means that the output will be an HTML page. This is easily readable, but not easily transformed into another format.
If you want to create something that could be transformed into a spreadsheet, or some other custom error report – you would use the XML Validation Reporter, followed by a subsequent XSLT transform to translates this into the format that you wish to pass along. For a more in-depth look at the ACORD XML Validation Video Demo or call us to schedule a custom WebEx.