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. 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 withPayload(DataFile) or withPayload(String) can be used. |
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 |
|
errors |
List<XSDValidationError> |
a (potentially) empty collection of record validation errors/warnings |
XSDValidationError
Property | Type | Notes |
---|---|---|
severity |
Severity |
one of: |
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 |