Skip to main content

Validating XML messages against more than one XSD with WSO2 ESB Validate mediator

Request validation is one of the important feature of any ESB. If you do not validate the request, it will go through your system and make unnecessary traffic on your resources. If you could validate the requests at the beginning of your message flow, that would help you to respond quickly and avoid resource utilization for wrong requests.

WSO2 ESB is the world's fastest one most comprehensive open source ESB available in the market. It is driven by the award winning WSO2 Carbon platform which you can use for any of your SOA implementations.

WSO2 ESB provides an OOTB (Out Of The Box) feature for request validation. This is called the Validate Mediator. This will provide you the capability to validate your request against any number of XSD schemas. If you are validating the request against a single XSD file, you can refer the below blog post written by Amani.

http://sparkletechthoughts.blogspot.com/2012/09/how-to-use-validate-mediator-to.html


In this blog post, I am going to discuss about a bit complex scenario where you have more than one XSD file to validate against. In this scenario, you have a XSD file A which has a reference to another XSD file B. In this kind of scenario, you need to take additional care when you implement your scenario.

1. Create your XSD file clear and make the references correct.

This is the main XSD(HelloSchema.xsd) file which we are validating the request against. This XSD has a reference to another XSD file(Hello.xsd)

HelloSchema.xsd
===============

<xs:schema xmlns:xs="http://www.w3.org/2001/XMLSchema"
xmlns:q1="http://www.wso2.org/hello"
xmlns:ns1="http://org.apache.axis2/xsd" xmlns:ns="http://www.wso2.org/types"
attributeFormDefault="qualified" elementFormDefault="qualified"
targetNamespace="http://www.wso2.org/types">
 <xs:import namespace="http://www.wso2.org/hello"
               schemaLocation="hello.xsd" />
<xs:element name="greet" type="q1:hello">
</xs:element>
</xs:schema>

In this schema definition, you can find there is a reference to the schema xmlns:q1="http://www.wso2.org/hello" which is defined in a secondary schema file. type "hello" is defined in the secondary schema given below.

Hello.xsd
==========

<xs:schema xmlns:xs="http://www.w3.org/2001/XMLSchema"
xmlns:ns1="http://org.apache.axis2/xsd" xmlns:ns="http://www.wso2.org/hello"
attributeFormDefault="qualified" elementFormDefault="qualified"
targetNamespace="http://www.wso2.org/hello">
<xs:element name="hello" type="ns:hello"></xs:element>
<xs:complexType name="hello">
<xs:sequence>
<xs:element minOccurs="1" name="name" >
 <xs:simpleType>
        <xs:restriction base="xs:string">
            <xs:minLength value="1" />
        </xs:restriction>
    </xs:simpleType>
</xs:element>
</xs:sequence>
</xs:complexType>
</xs:schema>

Now you are going to validate the request against the HelloSchema.xsd file which has a reference to Hello.xsd file.

2. Once you create your XSD files, upload them to WSO2 ESB registry under the path \_system\conf\. Now your XSD files should be in the below registry paths.

/_system/config/Hello.xsd
/_system/config/HelloSchema.xsd

3. Create the proxy service to validate the incoming request.

<?xml version="1.0" encoding="UTF-8"?>
<proxy xmlns="http://ws.apache.org/ns/synapse"
       name="MyValidateProxy"
       transports="https,http"
       statistics="disable"
       trace="disable"
       startOnLoad="true">
   <target>
      <inSequence>
         <log level="full">
            <property name="Message" value="Inside Insequance"/>
         </log>
         <validate>
            <schema key="conf:/HelloSchema.xsd"/>
            <resource location="hello.xsd" key="conf:/Hello.xsd"/>
            <on-fail>
               <makefault version="soap11">
                  <code xmlns:tns="http://www.w3.org/2003/05/soap-envelope" value="tns:Receiver"/>
                  <reason value="Invalid Request!!!"/>
                  <role/>
               </makefault>
               <log level="full"/>
               <property name="RESPONSE" value="true"/>
               <header name="To" action="remove"/>
               <send/>
               <drop/>
            </on-fail>
         </validate>
         <respond/>
      </inSequence>
      <outSequence>
         <send/>
      </outSequence>
   </target>
   <description/>
</proxy>
                               
In this proxy configuration, you can find the validate mediator configuration like below.

 <validate>
            <schema key="conf:/HelloSchema.xsd"/>
            <resource location="hello.xsd" key="conf:/Hello.xsd"/>
            <on-fail>
               <makefault version="soap11">
                  <code xmlns:tns="http://www.w3.org/2003/05/soap-envelope" value="tns:Receiver"/>
                  <reason value="Invalid Request!!!"/>
                  <role/>
               </makefault>
               <log level="full"/>
               <property name="RESPONSE" value="true"/>
               <header name="To" action="remove"/>
               <send/>
               <drop/>
            </on-fail>
         </validate>

Here we are validating the request against the schema key conf:/HelloSchema.xsd it has a reference to another xsd which is stored with the location="hello.xsd". This value is the one we referenced inside the HelloSchema.xsd file like below.

 <xs:import namespace="http://www.wso2.org/hello"
               schemaLocation="hello.xsd" /> 

This is a very important reference and you should carefully understand this reference. This will make sure that the validate mediator can resolve the references correctly.

Now you have the proxy and the XSD files in place.

4. Send a request to the proxy service with the correct request like below.

<soapenv:Envelope xmlns:soapenv="http://schemas.xmlsoap.org/soap/envelope/">
   <soapenv:Header/>
   <soapenv:Body>
      <p:greet xmlns:p="http://www.wso2.org/types" xmlns:q="http://www.wso2.org/hello">
         <q:name>chanaka</q:name>
      </p:greet>
   </soapenv:Body>
</soapenv:Envelope>

Here you can see we are using two namespaces

xmlns:p="http://www.wso2.org/types" xmlns:q="http://www.wso2.org/hello"

which we have defined in two different xsd files. Once you send this request, it will respond with the same request since it validated the XSD correctly.

If you send a different request like below it will respond with a failure response.

<soapenv:Envelope xmlns:soapenv="http://schemas.xmlsoap.org/soap/envelope/">
   <soapenv:Header/>
   <soapenv:Body>
      <p:greet xmlns:p="http://www.wso2.org/types" xmlns:q="http://www.wso2.org/hello">
         <q:name></q:name>
      </p:greet>
   </soapenv:Body>
</soapenv:Envelope>

This will respond with the below response.

<soapenv:Envelope xmlns:soapenv="http://schemas.xmlsoap.org/soap/envelope/">
   <soapenv:Body>
      <soapenv:Fault>
         <faultcode xmlns:tns="http://www.w3.org/2003/05/soap-envelope">tns:Receiver</faultcode>
         <faultstring>Invalid Request!!!</faultstring>
      </soapenv:Fault>
   </soapenv:Body>
</soapenv:Envelope>

Here we go !!! The wrong request has been sent back with the fault message.

Comments

  1. I have tried above example and worked fine for me
    But I am trying to apply validation on dynamically created XML.
    But got some error.
    Please see below link

    http://stackoverflow.com/questions/25748669/wso2-esb-xsd-validation-on-xml/25749632#25749632

    Thanks for your help. :)

    ReplyDelete
  2. How to validate dynamically created xml file against xsd

    ReplyDelete
  3. Excellent article and this helps to enhance your knowledge regarding new things. Waiting for more updates.
    Angular CSS
    Angular Material

    ReplyDelete

  4. Awesome article! You are providing us very valid information. This is worth reading. Keep sharing more such articles.
    Data Science Course in Chennai
    Data Science Online Training
    Data Science Course in Coimbatore

    ReplyDelete

Post a Comment

Popular posts from this blog

WSO2 ESB tuning performance with threads

I have written several blog posts explaining the internal behavior of the ESB and the threads created inside ESB. With this post, I am talking about the effect of threads in the WSO2 ESB and how to tune up threads for optimal performance. You can refer [1] and [2] to understand the threads created within the ESB. [1] http://soatutorials.blogspot.com/2015/05/understanding-threads-created-in-wso2.html [2] http://wso2.com/library/articles/2012/03/importance-performance-wso2-esb-handles-nonobvious/ Within this blog post, I am discussing about the "worker threads" which are used for processing the data within the WSO2 ESB. There are 2 types of worker threads created when you start sending the requests to the server 1) Server Worker/Client Worker Threads 2) Mediator Worker (Synapse-Worker) Threads Server Worker/Client Worker Threads These set of threads will be used to process all the requests/responses coming to the ESB server. ServerWorker Threads will be used to pr

How puppet works in your IT infrstructure

What is Puppet? Puppet is IT automation software that helps system administrators manage infrastructure throughout its lifecycle, from provisioning and configuration to orchestration and reporting. Using Puppet, you can easily automate repetitive tasks, quickly deploy critical applications, and proactively manage change, scaling from 10s of servers to 1000s, on-premise or in the cloud. How the puppet works? It works like this..Puppet agent is a daemon that runs on all the client servers(the servers where you require some configuration, or the servers which are going to be managed using puppet.) All the clients which are to be managed will have puppet agent installed on them, and are called nodes in puppet. Puppet Master: This machine contains all the configuration for different hosts. Puppet master will run as a daemon on this master server. Puppet Agent: This is the daemon that will run on all the servers, which are to be managed using p

How to configure timeouts in WSO2 ESB to get rid of client timeout errors

WSO2 ESB has defined some configuration parameters which controls the timeout of a particular request which is going out of ESB. In a particular  scneario, your client sends a request to ESB, and then ESB sends a request to another endpoint to serve the request. CLIENT->WSO2 ESB->BACKEND The reason for clients getting timeout is that ESB timeout is larger than client's timeout. This can be solved by either increasing the timeout at client side or by decreasing the timeout in ESB side. In any of the case, you can control the timeout in ESB using the below properties. 1) Global timeout defined in synapse.properties (ESB_HOME\repository\conf\) file. This will decide the maximum time that a callback is waiting in the ESB for a response for a particular request. If ESB does not get any response from Back End, it will drop the message and clears out the call back. This is a global level parameter which affects all the endpoints configured in ESB. synapse.global_timeout_inte