opentravel web service test suite

If you're a travel industry developer writing an opentravel client for any platform or language, you will need a test web services server as part of your development infrastructure.

The open source JiBX project contains tools for web services development, including a complete xml to java binding for the opentravel message schema.

When you combine the JiBX tools with an open source web services platform such as servicemix and the tools available for java, you have an excellent platform for testing your opentravel messaging.

Let's start with the JiBX web services framework. Click on this link, and follow the directions to set up your web service.

If you need help setting up your test environment, take a look at this blog entry for step-by-step instructions on setting up a JiBX maven project in eclipse.

Now you're ready to customize your test code. Let's start with the code from our repository.

Take a look at this source code. In the res and resmodify method you will see some code like this:

Properties properties = new Properties();
properties.setProperty(BaseClient.FILENAME, "/OTA_HotelResRS.xml");
properties.setProperty(BaseClient.CLASSNAME, ResRQ.class.getName());
if (request.getOTAPayloadStdAttributes() != null)
 if (request.getOTAPayloadStdAttributes().getEchoToken() != null)
  if (request.getOTAPayloadStdAttributes().getEchoToken().startsWith("/"))
   properties.setProperty(BaseClient.FILENAME, request.getOTAPayloadStdAttributes().getEchoToken());
response = (ResRS)this.createMessage(properties);

This code is using the framework's ability to read a local message and marshal it to a Java object. You will see that all that is needed is the message class and location (You will find this message in the https://github.com/jibx/schema-library/tree/master/org.opentravel/_2012A/opentravel-ws/opentravel-hotel-ws-test-service/src/main/resources directory). In this test scenario I also have the option to pass the pathname of the the response message in the request message's echotoken attribute.




If you look at the checkpaymentcard method, you can see the power of using java objects to test for xml elements. This would be difficult to do in XPATH or DOM.


public void checkPaymentCard(PaymentCard paymentCard)
{
if (paymentCard.getSeriesCode() != null)
System.out.println("Good - Card info good");
 else
System.out.println("Error - Card info not good");
}



The utilities in the JiBX web services test suite can be used in the client and service modules. For a description of the other utilities, see my opentravel client test suite blog.




Cheers!




Don Corley

don@tourgeek.com

opentravel web services client test suite

If you're a travel industry developer writing an opentravel service on any platform or language, you will need a test web services client as part of your development infrastructure. Your client will send various messages to your service and then verify that the responses are correct.

The open source JiBX project contains tools for web services development, including a complete xml to java binding for the opentravel message schema.

When you combine the JiBX tools with all the of tools available for the java platform you have an excellent platform for testing your opentravel messaging.

Let's start with the JiBX web services client framework. The client framework is very flexible. It can be used by your client application, or used as a test platform. We'll be running our tests using the maven framework, but you can easily use straight java or run your tests in an OSGi container.

Now we're ready to customize our test code. Let's start with the code from our repository at: https://github.com/jibx/schema-library/tree/master/org.opentravel/_2012A/opentravel-ws/opentravel-hotel-ws-test-client. You should download this project and use it as your starting point.

Take a look at this source code here. Notice this source code in the start method:

Properties properties = new Properties();
properties.setProperty(ENDPOINT, endpoint);
properties.setProperty(FILENAME, "/OTA_HotelResRQ.xml");
properties.setProperty(CLASSNAME, ResRQ.class.getName());
runTest(properties); // By default, run the test once with no properties

This code is using the framework's ability to read a local message and marshal it to a Java object. You will see that all that is needed is the java class name and the message location (You will find these xml messages in the project's resource directory).

If you prefer unit tests, this project also contains a maven junit test. The source code is here.

If you scroll to the bottom of this code, you will see the checkResponseMessage method. You will notice that this method converts the java object to an xml string and prints it. It also converts the message to a DOM tree and does a test. The last line does an XPath test on the xml message.

This client code inherits code from the web services Utilities java class. Take a look at this code for the available tools.

This should be everything you need to write a web services client or a web services client test suite.

Don Corley

don@tourgeek.com

Creating an opentravel SOAP client and server for testing using soapui

If you are creating a web services client or server in the Travel Industry, you are probably using the opentravel messaging schema.

Sometimes the most difficult part of your project is creating a test client or server to verify your application code.

soapui is a great open source utility for easily creating manual and automated SOAP test suites.

I'm going to show you how to quickly set up a SOAP test client and a SOAP test server for an opentravel message pair using soapui.

The first thing you will need is a WSDL file. Luckily the ota-tools project has many open source resources for opentravel users, including a soapui project with sample WSDL file that we can use as a template.

You can download this WSDL file from the ota-tools source repository at:

https://sourceforge.net/p/ota-tools/code/ci/f0311dbe474aa80f7f12bcbed27695ac7b22675f/tree/java/ota-soapui/opentravel.wsdl

This WSDL is currently configured for the 2012A version of the Ping message pair. If you would like to use a different message pair, just change the import statements to point to your root schema.

For example, if I want to test the cancellation message pair, I would change:

<xsd:import namespace="http://www.opentravel.org/OTA/2003/05"
  schemaLocation="http://www.opentravel.org/2012A/OTA_PingRQ.xsd" />
<xsd:import namespace="http://www.opentravel.org/OTA/2003/05"
  schemaLocation="http://www.opentravel.org/2012A/OTA_PingRS.xsd" />

to:

<xsd:import namespace="http://www.opentravel.org/OTA/2003/05"
  schemaLocation="http://www.opentravel.org/2012A/OTA_CancelRQ.xsd" />
<xsd:import namespace="http://www.opentravel.org/OTA/2003/05"
  schemaLocation="http://www.opentravel.org/2012A/OTA_CancelRS.xsd" />

Then change the message root elements to match the root elements of the schema that you are testing. In this example, I would change:

<wsdl:message name="Request">
<wsdl:part element="ota:OTA_PingRQ" name="payload">
</wsdl:part>
</wsdl:message>
<wsdl:message name="Response">
<wsdl:part element="ota:OTA_PingRS" name="payload">
</wsdl:part>
</wsdl:message>

 

to:

<wsdl:message name="Request">
<wsdl:part element="ota:OTA_CancelRQ" name="payload">
</wsdl:part>
</wsdl:message>
<wsdl:message name="Response">
<wsdl:part element="ota:OTA_CancelRS" name="payload">
</wsdl:part>
</wsdl:message>

Now you are ready to create a test client and server in soapui.

From the soapui main menu, select, File -> New soapui Project

In the dialog box, click the browse button and open the wsdl file that you just edited:

Give your project and name and click 'OK'

Generate a default service

and give it a name:

Now you are ready to start your mock service. Click on the green 'Go' button in the upper left. Now your service is running and you can call it from soapui or the opentravel client that you are developing.

Now let's test our service. Open the sample request and,

press the green 'Go' button in the upper left. You should have a response message on your screen.

 Voilà!

Now you are ready to add some logic to your soapui test server and create a soapui client test suite. You will find a nice project with examples in the ota-tools soapui project.

This sample project is located in our source repository at:

https://sourceforge.net/p/ota-tools/code/ci/f0311dbe474aa80f7f12bcbed27695ac7b22675f/tree/java/ota-soapui/

Just download the opentravel-soapui-project.xml file and import it into soapui.

Now you're ready to test your opentravel client or server code!