Making History, SAP Netweaver Process Integration 7.1 comes with the feature of XML validation requested by customers. It is important to test the XML message for a predefined schema, especially when using industry-specific adapters, such as Rosetta Net. XML validation allows you to check the structure of an XI message payload. The structure check is dependent upon stored data types.
Now, validation can take place in either the Advanced Adapter Engine or Integration Server but depend where it take places the system reacts in different.
The data types used for validation come from Enterprise Services Repository since PI 7.3.
During runtime, the target adapter translates an inbound message into the required PI message. The range of adapter functions allows the system to compare the payload to a configured schema. The adapter calls a central component for syntax validation, which calls an XML schema validation engine.
If the system detects an error, the Advanced Adapter Engine triggers an exception, stops the further processing of the message, and uses a synchronous response-call to inform the sender of the error. Industry-specific adapters inform the sender asynchronously, as is required by the RNIF and CIDX protocol.
The Advanced Adapter Engine does not make the message persistent; it can trigger an alert.
Even when the Integration Engine checks the XML structure, the data types come from Enterprise Services Repository. They must be exported by the Enterprise
Services Repository and copied into the file system. For the inbound and outbound processing of messages, XML validation is a new step in the pipeline. Whenever the structure of a message does not fit the stored schema, the Integration Engine creates an error description containing status information and a list of all structure errors. The error report is saved. The message is given an error status. The sender is not automatically notified when a message is validated in the Integration Server.
The Integration Server makes the message persistent and can trigger an alert. An administrator can continue to process the message using the Runtime Workbench and can restart the process, if necessary.
It s possible also,to check the schema in the receiver side so, In the receiver agreement, you can set the validation in the Integration Server.
When validation takes place in the Integration Server, a message is set to the error status in the event of an error and can be processed by the administrator in the Runtime Workbench.
in theory it looks perfect, but how to implement it for real? see the steps below to configure it.
You make available in the file system the schemas that should be checked by the Advanced Adapter Engine or Integration Server. The prerequisites for this are:
• You have created the RFC destination for AI_VALIDATION_JCOSERVER on AS ABAP and AS Java.
• You have the authorizations required for accessing and changing the directory structure for XML validation.
• You must have access to the schemas that are referenced using the Import namespace tag in the main schema.
Proceed as follows if you have PI 7.1. Remenber that with PI 7.3 there is no need to follow those steps because the schema is taken from the ESR
1. For XML validation, you must save the required schemas from Enterprise Services Repository in the file system by creating the following directory
structure.
Create the following directory for validation on the Integration Server in the <sysdir> /xi/runtime_server directory. /validation/schema/<GUID
for the software component version, to which the service interface is assigned>/<Repository namespace of the service interface>
Create the following directory for validation on the central and decentralized Adapter Engine in the <SAP Installation directory>/<System
ID>/<Instance number>//j2ee/cluster/server0 directory for non-cluster installation of AS Java: /validation/schema/<GUID of the software component version, to which the service interface is assigned>/<Repository namespace of the service interface>.
For cluster installation of AS Java, create the directory structure mentioned above and save it in the corresponding server node directories.
2. Convert the <Repository namespace of the service interface> into a valid folder name by changing the following characters to "~": /,\,:,*,?,",<,>,|,;,,,=,&,%,[,],# . If there are several special characters in a row, replace them with a single "~". For example, "A%&B" changes to "A~B". Periods (.) at the end of a name are automatically deleted.
3. Create the /<Service interface> directory in the directory structure mentioned above.
4. If the schema contains the targetNamespace attribute in the XSD definition, proceed as follows:
• Create the /<targetNamespace> directory in the directory mentioned above.
• Repeat step 2 to convert <targetNamespace> into a valid folder name.
• Export the schema and save it in the /<targetNamespace> directory.
5. If the targetNamespace attribute does not exist in the schema, export the schema and save it in the /<Service-Interface> directory.
6. If the main schema contains references to other schema by using the import namespace tags, proceed as follows:
• Create an /<import namespace> directory for every referenced schema in the /<Service-Interface> directory can be found in the Enterprise Services Repository on the WSDL or XSD tab pages.
• Repeat step 2 to convert <import namespace> into a valid folder name.
• Export the schema (XSD file) indicated by the <schemaLocation>attribute.
• Enter the name of the schema indicated by the <schemaLocation> attribute as the file name. (For example, if schemaLocation="
http://www.w3.org/2001/xml.xsd", then xml.xsd is the name of the file.)
• Save every referenced schema in its corresponding directory /<import namespace>.