Calling a Web Service

Overview

module guide 1190 1

The example shows the two most relevant modules for calling a Web service:

  • XSLT Converter for creating the Web service request

  • Web Services Medium or Output Connector for sending the request and for receiving the result (if there is any):

    • A Medium Connector can be used if the Web service returns a result that is to be processed further in the workflow.

      The Medium Connector sends the request, waits for the result and hands it over to the subsequent module in the workflow. In this way, the result be written, for example, into a database or processed for other systems.

    • Using an Output Connector makes sense, if the request calls up a one-way operation without any return value and no further processing is required. Technically, an Output Connector reacts in the same way as a Medium Connector, which means that the Output Connector also waits for a result and keeps it.

Configuring the Web Services Connector

Proceed as follows

  1. Create a Web Services Output Connector. When configuring it, define that the definition of the Web service that is to be called is stored directly at the module.

  2. In the Web Services Editor specify where to load from the WSDL of the invoked Web service and load the WSDL.

    For testing, you may use the Web service, refer to Providing a Web Service. If this Web service exists and is published, do the following: At the right end of the row click the button and select Show published services (refer to Invoked Service Tab). A list of all Web services is displayed in the Web browser. Click the link [NameofYourWebService]. The WSDL is displayed. Copy its URL into the clipboard and insert it in the Invoked Service tab into the URL field.

  3. Publish the connector.

  4. Create a Technical Workflow and insert the Web Services Output Connector.

Creating the SOAP Request

Proceed as follows

  1. Create an XSLT Converter. When configuring it, select the option Ignore input message.

  2. Add the XSLT Converter to the Technical Workflow.

  3. Open the XSLT Converter for editing.

  4. In the XML target file area, click module guide 1189 0 and select Open from > Web Services Explorer. The following dialog opens up:

    module guide 1191 3
  5. Select the Web Services Connector and the operation which you want to call (relating to Request). Click Finish to close the dialog.

    The structure of the SOAP requests, which the Web Service expects, is displayed.

  6. Drag the root element of the SOAP messages up onto the xsl:template element.

  7. Adjust the values in the XML source area, for example:

    module guide 1192 1
  8. Publish the XSLT Converter.

  9. Testing:

    1. In the Technical Workflow define a start point at the XSLT Converter.

    2. From the context menu select Start test without file.

      After the test is finished open the watchpoint behind the Web Services Connector to display the result, the SOAP response.

To create dynamic Web service calls, add other modules before the XSLT Converter, which, for example, read the Web services parameter from a database and hand them over to the XSLT Converter. The, in the XSLT Converter map these parameters onto parts of the SOAP message.

Setting Session Cookies

If the web service response contains a set cookie header, its contents are written in the XML variable WSCallerCookies using the following structure:

<Cookies>
    <Cookie uri="http://192.168.109.1" name="vmware_soap_session" domain="192.168.109.1" path="/" version="0">
    678E5BDC-52FC-4E38-B975-6880792AF6FA
    </Cookie>
</Cookies>
  • uri

    URL called (without path)

  • name

    name of the cookies

  • domain

    domain name the cookie is valid for

  • path

    path/path prefix the cookie is valid for

  • ports

    comma-separated port list (not set by default)

  • version

    • 0

      using the Netscape syntax

    • 1

      using the syntax based on RFC 2965/2109 (default)

The following web services calls read the WSCallerCookies variable. For web service calls, the corresponding cookies are set automatically. The cookies' domain/path must match exactly the web services called.

If you have implemented workflows with several consecutive web service calls, and these calls need session cookies, you have to ensure that the WSCallerCookies variable is passed to the next module.