XML validation ensures that the service interfaces, configured during design time, enable the one-time delivery of messages from the sender adapter to the receiver adapter. XML validation ensures that no errors occur either in the PI system or in the receiver system.
In general, the following statements are valid regardless of where the XML validation is configured to take place:
The validation is performed on the Java stack only.
There is no difference between synchronous and asynchronous configuration with respect to XML validation.
XML validation can be configured to determine when XML validation occurs and the prerequisite steps that must be taken.
This lesson provides more details about the different XML validation configuration options.
XML Validation in an Integrated Configuration
In an integrated configuration in which pipeline processing takes place in the AAE, XML validation can only occur during pipeline processing. While error messages are stored in the Java Message Store, the sender is not informed.
Configuration of Inbound XML Validation in an integrated Configuration
In the figure, Configuration of Inbound XML Validation Before Pipeline Execution in the AEX, at runtime (step 1), the Adapter creates the XIMP 3.0 message with SOAP header, SOAP body, and payload. The payload is defined as abstract Web Services Description Language (WSDL) in a defined XML Schema Definition (XSD) in the ESR. The Adapter calls pipeline processing in the AEX using the URL http://<host>:<port>/HttpAdapter/HttpMessageServlet? and hands over the XIMP 3.0 message.
XML validation configuration is done on the Inbound Processing tab page of the integrated configuration (step 2 in the figure). In this context, only one option is available for performing XML Validation, that is, during pipeline processing.
If XML validation is requested, the assigned XSD of the abstract WSDL is read directly from ESR cache, at step 3 in the figure, Configuration of Inbound XML Validation Before Pipeline Execution in the AEX, and is used for XML validation. In this case, the value in the MaterialID field must be between 6 and 10 digits.
If XML validation fails, in step (4) of the figure, Configuration of Inbound XML Validation Before Pipeline Execution in the AEX, the message is set to a waiting status in the Java Message Store. This can be seen in the Message Monitor of the AEX (pimon). The error displays in detail in the Message Log tab page. The message status is set to System Error after a certain time period.
To see the message in the Message Monitor, it is required that at least BI=1 for Staging is set in the Java System Properties of your AEX system. You’ll find more details in Unit 7, Lesson "Logging and Staging".
The sender is not informed, which means that no HTTP response with status code 500 is returned to the sender. However, the error can be seen in the Java log.
Configuration of Outbound XML Validation in an Integrated Configuration
The configuration of XML validation, step (5) in the figure, is performed in the Outbound Processing tab page of the integrated configuration. This applies to both synchronous and asynchronous modes.
If XML validation fails, in step (6) of figure: Configuration of Outbound XML Validation Before Pipeline Execution Starts in the AEX, the message is set to a waiting status in the Java Message Store. This can be seen in the Message Monitor of the AAE (pimon). The error is shown in detail on the Message Log tab page.
After a certain time period, the message status is set to System Error. If the error occurred on entering or exiting pipeline processing, this can be seen in the interface referenced in the log. Another possibility is the appearance of the appropriate settings of the Java Properties are required indication in the detailed view of the message.
Differences Between Synchronous and Asynchronous Communication
With synchronous communication, the response is also validated against the XSD. It is not possible differentiate between a request and a response.