PI 7.3 - XML Validation

[rodrigoalejandro_pertierr]

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.

1. Configuration

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.

1. For XML validation, you must save the required schemas from Enterprise Services Repository in the file system by creating the following directory structure.

2 Validation on the Integration Server

Create the following directory for validation on the Integration Server in the path:

<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>

3 Validation on the central and decentralized Adapter Engine

1.     Create the following directory for validation on the central and decentralized Adapter Engine in the

<SAP Installation directory>/<SystemID>/<Instance number>/j2ee/cluster/server0/validation/schema/<GUID of the software component version, to which the service interface is assigned>/<Repository namespace of the service interface>/<Service interface>

If there are additional server nodes, the same copying process will have to be repeated for each one of those nodes.

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. If the schema contains the targetNamespace attribute in the XSD definition, proceed as follows:

• Create the /<targetNamespace> directory in the directory mentioned above.

<SAP Installation directory>/<SystemID>/<Instance number>/j2ee/cluster/server0/validation/schema/<SWCV ID> / <Repository namespace of the service interface>/<Service interface>/<targetNamespace>

• Export the schema (Message Type) and save it in the /<targetNamespace> directory.

<?xml version="1.0" encoding="UTF-8"?>

<xsd:schema targetNamespace="http://test.com/sample" xmlns:p7="http://test.com"

xmlns:xsd="http://www.w3.org/2001/XMLSchema" xmlns="http://test.com/sample">

                <xsd:import namespace="http://test.com" schemaLocation="Schema1.xsd" />

<xsd:element name="TestValidSource_MT" type="p7:Orders_DT" />

</xsd:schema>

<SAP Installation directory>/<SystemID>/<Instance number>/j2ee/cluster/server0/validation/schema/<SWCV ID> / <Repository namespace of the service interface>/<Service interface>/< http://test.com/sample>

Repeat step 2 to convert <targetNamespace> into a valid folder name.

4.      If the targetNamespace attribute does not exist in the schema, export the schema and save it in the /<Service-Interface> directory.

1. a. If the main schema contains references to other schema by using the import namespace tags, 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.

Example

The content of MainSchema.xsd contains an import statement for the Data Type:

<?xml version="1.0" encoding="UTF-8"?>

<xsd:schema targetNamespace="http://test.com/sample" xmlns:p7="http://test.com"

xmlns:xsd="http://www.w3.org/2001/XMLSchema" xmlns="http://test.com/sample">

                <xsd:import namespace="http://test.com" schemaLocation="Schema1.xsd" />

<xsd:element name="TestValidSource_MT" type="p7:Orders_DT" />

</xsd:schema>

<SAP Installation directory>/<SystemID>/<Instance number>/j2ee/cluster/server0/validation/schema/<SWCV ID> / <Repository namespace of the service interface>/<Service interface>/<import namesapce>

     • 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.

     • Save every referenced schema in its corresponding directory /<import nam

5.      It is necessary to configure the Integration Directory to enable the schema validation.  This task is configured in the Sender Agreement.

2. Disadvantages

XML validation is a much-requested feature enhancement for PI 7.1. But, due to its current design we must take its implementation and management into consideration.

Considerations:

1. The XSD cannot be managed via PI tools. It must be copied to the OS file system, with directory paths hard to decipher.

2. Because of the use of the OS file system, lifecycle management becomes an issue. There are no transport mechanisms to support it.

3. The Message Type and the XSD to validate it are disjointed. This means that changes to the Message Type will not automatically update the XSD; these 2 objects are   

    not synchronized. Manual update process must be performed.

4. Access to the OS file system by the developers can be problematic, especially from the security perspective, so Its necessary to interact to other areas. So the    

     configuration will be associated with the availability of the resources of others areas

5. The maintenance of the XSDs becomes increasingly complex as the XSDs become more complex, especially when imports are used in the XSDs with different namespaces.

6. Due to resource requirement during the validation process, hardware sizing must be considered during the planning phases.

7. Be extremely careful when using asynchronous/synchronous bridge in the sender JMS adapter. Since the service interface is configured as synchronous, the validation      error will be  returned to the sender. However, JMS is an asynchronous adapter, therefore, will not be able to receive the response containing the error. As a result, the      error cannot be seen any place. At the same time, the message will not go thru and there is no monitoring to indicate so in RWB or the Integration Server.

8. If there are multiple errors in the same XML document, then the RWB only displays the first error.

9. Since messages are not persisted after XML validation error occurs in the Adapter Engine the alerts and navigation using message IDs will not work.

3. Conclusion

It is recommended to implemt this functionality  in special cases such:

1. Its is not possible way to validate the data at client side.

2. Critical Implementation time of the scenario.

3. Other cases to be analized.