Web Service Clients

Web Service Clients. 1

Introduction. 1

SOAPUI 1

Creating and Using a SOAPUI Project 1

What if the Message Format Changes?. 1

Jazz Message Formats to SOAP Messages. 1

Pros and Cons of SOAPUI testing. 1

Introduction

JazzUGSOA2.htm showed you how to develop your first web service, providing the time from your computer. JazzUGSOA4.htm extended this to more useful services, providing and updating data held in files on your mainframe. This chapter is about testing your web service providers, and developing web service clients – programs operating from Windows, a Web Page, or a mobile app that invokes the web services that you have developed with Jazz.

This shows you how to use a general test utility, SOAPUI, that can be used to invoke any web service. This is a convenient tool to use when a web service is being developed, especially when you want to find out if your new service is actually getting the messages that you send it, and responding with something, or when you aren’t sure whether an error is in the web service or in the client program.

SOAPUI

Creating and Using a SOAPUI Project

SOAPUI is a free test tool, SOAPUI, that you can download here. I created a SOAPUI project: -

Click [OK] and the web service is discovered, and a project created. Expand the project to locate the request node, which is at the lowest level.

Double click this, and the test form opens. Fill in the input data (left hand panel), in this case giving the length and value for Name.

Then click and the message is sent to the service, and the results displayed in the right-hand panel: -

Note that we didn’t have to give any information about the format or names of the messages, the URI was sufficient to find the WSDL, and this gave SOAPUI everything it needed. In the same way we can create SOAPUI projects to test WSPG1 using URI http://192.86.32.59:9014/MNJZPROV/WSPG1?wsdl, and WSPG2 using URI http://192.86.32.59:9014/MNJZPROV/WSPG2?wsdl. We can give a domain name in place of the IP and port: for example we can create a SOAPUI test of the test services on the Jazz Software web site with http://jazzsoftware.co.nz/SOATest1.svc?wsdl.

What if the Message Format Changes?

When you formed the SOAPUI project the WSDL was read and the message formats retrieved. Especially during initial development these formats may change. If the input message changes its format then the test won’t work any more, but will fail with a SOAP error. Here’s an example from program WSPG2 testing: -

Here CICSFault has value

<CICSFault xmlns="http://www.ibm.com/software/htp/cics/WSFault">DFHPI1007 02/28/2016 15:20:56 CICSTS51 00477 XML to data transformation failed because of incorrect input (UNDEFINED_ELEMENT jz_custf_Skip) for WEBSERVICE WSPG2.</CICSFault>

To fix this, create a new web service. Unless you first delete the now-failing SOAPUI project, you’ll need to give it a different name. Here I deleted SOAPUI project WSPG2, then created a new one with the same name and URI as before. The web service is now invoked and results returned normally: -

Jazz Message Formats to SOAP Messages

The form of the WSDL reflects the Jazz input and output definitions, but has undergone some transformations. The message formats for GetTime were defined with VARCHAR fields: -

In the transformation from Jazz to COBOL the Varchar fields have become COBOL groups with a length field and a data field

001290 01 IGetTime.

001300 03 Name.

001310 49 JZL-Name PIC S9999 COMP-5 SYNC.

001320 49 JZD-Name PIC X(20).

Where you have used a COBOL reserved word this is prefixed with “JZ-“. Thus the field name “ERROR” becomes “JZ-ERROR” in COBOL.

In translation from COBOL to WSDL the hyphens become underscores.

All these changes are reflected in the message formats, so that we see a result like

<soapenv:Envelope xmlns:soapenv="http://schemas.xmlsoap.org/soap/envelope/" xmlns:get="http://www.GETTIME.IGETTIME.Request.com" xmlns:SOAP-ENV="http://schemas.xmlsoap.org/soap/envelope/">

<SOAP-ENV:Body>

<jzl_Result>35</jzl_Result>

<jzd_Result>Hello Robert The time in Dallas is 27 Feb 2016, 18:09:37</jzd_Result>

</Result>

<jz_error>

<jzl_error>0</jzl_error>

<jzd_error/>

</jz_error>

</Ogettime>

</gettimeResponse>

</SOAP-ENV:Body>

</soapenv:Envelope>

Pros and Cons of SOAPUI testing

Advantages of testing with SOAPUI, or similar tools, are: -

· You can quickly test a service, without any client-side programming

· You can see exactly what SOAP messages are being sent, and what are being returned

· You can easily test situations prevented by your client programs. For example, in the client page to test WSPG2 client-side logic prevents non-numeric data being entered into numeric fields, ensures that the value of BillingCycle is within the range 1 – 12, and so on. There is no problem testing these situations with SOAPUI.

The disadvantages: -

· It is possible for a client program to return invalid results.

· Each test has to be carefully set up. With a VARCHAR field you must set the correct length as well as the correct text. When testing a program like WSPG2 you have to carefully copy Viewstate values from the output message to the next input message to test updating.