XML Validation

Slash B2B Integration Timelines with the Automated XML Validation Component of the eiConsole

One easily discounted aspect of business-to-business integration initiatives is the time and money spent in communication.

An industry standard is as flexible as it is powerful. Such standards provide a common vocabulary, and a fantastic head start on interfacing systems – but they do not guarantee plug & play. Differences in versions, interpretations, and use of optional data elements necessitate what can become a protracted dialog between trading partners. That’s why companies have discovered that they need automated XML validation.

When partners are finally ready to exchange messages, “live” testing is proceeded by e-mail exchanges of test instances and desk-checks of those files. It takes a substantial amount of time to review these and to document what is “right” and “wrong” about them. Also, people have many priorities – so each testing cycle might be coupled with a communication delay. The result is missed deadlines and project overruns.

Enter the eiConsole’s XML Validation component.

The XML Validation component of the eiConsole allows developers and analysts to codify all of the conditions that a message must meet to ensure that it can be successfully processed by the backend system(s).

Validation Models can be developed in the XML Validation Editor, which supports field, file, and external-context validation.

Taken alone, XML Schema can enforce “field level” restrictions. How often can this field occur? What type is the data? The Validation Module can test for these low-level conditions based on the specific industry schemas, or an implementation-specific sub-schema. Other types of field-level validations, including regular expressions and restricted code lists, are also available.

The XML Validation Module also includes Schematron and XSLT-driven validators to enforce “file context” restrictions. This allows more complex validation (such as interdependent fields) to be modeled. If the Policy Type is “X,” do any coverages of types other than “A,” “B” and “C” appear?

Finally, Business Rules Validation is available. Does the inbound policy number match a policy issued by this agent? Does the ZIP code match the City and State provided? The XML Validation component also supports:

• XML Schema Validation
• Schematron Validation
• Business Rules Validation

Once a Validation Model has been created, testing of trading partner messages is fully automated. A sample received via email (or other preferred protocol) is intercepted and tested. An HTML report is generated and immediately returned to the sender. No more desk checking. No more delays. No more hassle. No more late delivery.

This validation model will allow you to accomplish three levels of validation. At the core, this validation is field level, which can be accomplished through XML Schema. At the next level, you can implement validation rules that cross boundaries between fields to check items like the conditional requirements of one field based on the content of another. These rules can be implemented through XSLT, Schematron or custom validation modules. The third level is external context validation. This will allow you to validate the inbound data stream against external sources (files, databases, contextual information). The details of how these modules are set up are available in additional reference materials. These are all configured using the Validation processor.

The easy-to-use graphical interface offers a simple drop-down menu; you choose the Validation Processor from the Add Processor menu.

The XML Validation component is feature rich. For example, the Validation Processor configuration includes Model Files. Model files are XML files that specify the validation rules that need to be run. Models can be aggregated in a particular Processor such that these rules can be layered on top of one another. For instance, you might have one Model File that does basic schema validation for all messages that fall under a particular standard. Each transaction may have a separate Model File that is used for specific rules in an implementation guide. On top of that, vendor or system specific rules can be implemented. These Model Files may be added to the list using the Add button in the configuration window shown below.

The user would then navigate to any Model Files that you would like to implement.

The aggregation of these Model Files can be saved as a name Validation Model under the Validation Processor Configuration. When data passes through the Validation Processor, these Model Files will be executed by the Validation Engine. Each Validation rule that executes successfully will be noted. An unsuccessful validation can be used to generate either an HTML based validation report or to throw an exception, which will trigger an alternate system processing.

With the eiConsole XML Validation is fully automated, reducing needless testing delays and communication errors. Try our Free 90-day Trial of the eiConsole to see what it can do for you.