Configuration and usage of Aucerna Execute's real-time AFE data validation with external systems.
This document describes how to use Aucerna Execute’s Enterprise Validation functionality. The Aucerna Execute Enterprise Validation functionality enables Aucerna Execute to call out to external systems, via industry standard SOAP, HTTP, or by calling out to a standalone EXE, for additional data validation upon “release for approval” or “route for review”.
Enabling External AFE Validation
Configuration samples for the external AFE Validation functionality resides in the “plugins_available\custom_validation” folder:
- validation_afe_route_release_soap_wsdl.config.sample – Validate AFE (Route or Release) against external SOAP service using a WSDL.
- validation_afe_route_release_soap_simple.config.sample – Validate AFE (Route or Release) against external SOAP service using document-style SOAP.
- validation_afe_route_release_exe.config.sample – Validate AFE (Route or Release) using an external validation program (EXE).
- validation_afe_route_release_http.config.sample – Validate AFE (Route or Release) using an external service via HTTP Post.
To add/enable Enterprise Validation copy the appropriate configuration sample from the “plugins_available\custom_validation” folder into the “plugins” folder, remove the .sample suffix, and modify the configuration in the file itself using the inline documentation in the configuration file.
Validation Messages
The validation message sent to the external system will conform to the “afe-validate.xsd” schema that is included in the online documentation index. A validation message includes details on the AFE state (including most data on the AFE as defined by the “afe.xsd” schema) and the user who is trying to validate the AFE.
The external system is expected to return a message according to the “afe-validate-result.xsd” schema. It may either return a success message or a list of one or more validation failures which would be included alongside any internal Aucerna Execute validation requirements and presented to the user. In addition, a list of warnings may also be returned (for Success or Failure) and those are shown to the user but will not prevent the action the user is trying to take.
Examples
A successful response would look like:
<AFEValidateResult xmlns="http://energynavigator.com/xml/afe/validate-result/2">
<Success/>
</AFEValidateResult>
A failure response would look like this:
<AFEValidateResult xmlns="http://energynavigator.com/xml/afe/validate-result/2">
<Failure>
<ValidationErrorMessage>Too big</ValidationErrorMessage>
<ValidationErrorMessage>Too small</ValidationErrorMessage>
</Failure>
</AFEValidateResult>
In the event of any response other than a properly formatted “success” response, the AFE action (release for approval or route for review) will not proceed. Any communication failures will be logged to the System Notification log. This means that if the external system is unavailable, users will be unable to route or release AFEs. However, this also means that no AFE will be routed or released without first having been verified by the external system (if configured). Validation messages are necessarily processed synchronously and therefor require the validation service to be fast and reliable.