Validation from XSD

This page describes how an XML payload string or file validates against an XSD Schema. An XML Schema called an XSD is typically a file that defines the structure of the XML Schema such as, the attributes that can be in the XML elements.

Payload Validation from Dynamic Logic

The dynamic logic in context of any exchangeStep makes it possible to validate data against an XSD schema.

XSD Schema

An XSD schema is a validation source against which an XML file gets validated. It can either come from a datafile as part of a datafile set or an HTTP <uri>. Payload validation at present assumes that the XSD schema is self-contained, which means that the external references and/or schema-includes are not resolved.

When a datafile is set as the validation source, a typical example in this case is to create a datafile set (for a specific interface), with a collection of datafile XSD’s - one for every type of payload.

In case of Validation sources retrieved from HTTP <uri> it needs to be publically accessible, from the environment that hosts the Oracle Insurance Gateway application.

Payload Validation

The XML payload that gets validated against an XSD schema can either be a <String>, (raw payload) or a <DataFile>.

A payload for example can be retrieved from within the context of a particular exchange ( trigger payload). It is also possible to acquire payloads to be validated through other means; like a search builder query on a particular <DataFile> or by passing in a local <String>.

Caching

XSD Payload validation by default caches the underlying XSD Schema Objects. These objects are used to perform the validation. Caching can be switched off, through a configuration property on the PayloadValidation builder.

Typically, in a production situation it is advisable to use the default caching behavior. In a development environment, it is recommended to not use caching. It is suggested to make this property driven from within the dynamic logic code. Depending on the environment this property can drive caching on or off.

Payload Validation Example

    // acquire a payload validation builder and configure it
   def payloadValidation = PayloadValidation.xsd()
            .withDataFileDefinition("transfergateway-xsds", "tcr")
            .withPayload(payloadFromAStep)
            .writeErrorsToApplicationLog(true)

   // call validation and get the result
   def payloadValidationResult = payloadValidation.validate()

   // do something (extra) with the validation errors
   if( !payloadValidationResult.success ) {
      exchangeStep.addExchangeLog("Something wrong with payload")
   }

Payload Validation API

The following table explains PayloadValidation builder configuration and execution

PayloadValidation builder	PayloadValidation.xsd() to acquire a payload validation (builder)
method	purpose	allowed types/values	default value
withDataFileDefinition(String, String)	to reference a datafile that has the XSD validation source. NOTE: Here the first String is DataFileSet code and the second String is DataFile code.
withURIDefinition(String)	to reference a HTTP URI that has the XSD validation source
withPayload(DataFile)	to reference a payload that needs to be validated	DataFile
withPayload(String)	to reference a payload that needs to be validated	String
useCaching(boolean)	switches validation source caching on or off	boolean	true
storeErrorsInExchangeLog(boolean)	whether validation errors need to be written to exchange log	boolean	true
writeErrorsToApplicationLog(boolean)	whether validation errors need to be written to the Oracle Health Insurance application logfile	boolean	false
validate() :: XSDValidationResult	issues a validation on the configured payload using the configured payload validation

With respect to withPayload(Object) either of the types: the withPayload(DataFile) or withPayload(String) can be used.

The following tables show PayloadValidation execution results and errors:

XSD Payload Validation Results

XSD Payload validation results in a <validation result>. This is a result structure that exposes two individual properties. A <success> property that indicates whether the validation was successful and did not lead to any fatal errors. And an <errors> property that contains a collection of potentially multiple XSD validation errors or warnings.

It is possible for the validation to be marked as successful even though the <errors> collection is not empty. In such a case, the <errors> collection hold only validation warnings.

Along with a <validation result>, depending on the configuration of the PayloadValidation builder, validation errors or warnings get consumed by the Application Logfile and/or Exchange Logs. By default, validation errors or warnings are stored in Exchange Logs and are not emitted to the Application Logfile. This can be configured on a per validation basis.

XSDValidationResult

Property	Type	Notes
success	boolean	true: when no fatal or no error type, false otherwise
errors	List<XSDValidationError>	a (potentially) empty collection of record validation errors/warnings

XSDValidationError

Property	Type	Notes
severity	Severity	one of: warning, fatal or error.
lineNumber	int	line number of where the validation error/warning happened
columnNumber	int	column number within the line of where the validation error/warning happened
message	String	a message indicating the problem that was detected