The Internet as most of us perceive and use it, consists of billions of websites and web applications that we access and interact with on a daily basis. Most of the time, we are taking an active part in this process and search for specific information.

But there is also another way where we don’t search the Internet site by site, but use a web service, to get the information we need.

Services that an operator offers on the Internet and which are used by other software systems via interfaces are called web services.

A simple example is the price search for a certain article on the Internet. Either we search in different webshops until we find the cheapest provider, or we use the second method and let the web service do the actual work. The Web Service will request the different shops independently and provide a list of prices from all vendors for comparison at the end.

Some of the best-known web services belong to Google and Amazon.

How does SOAP fit into the picture?

A web service communicates with its clients (users) by transmitting XML-based messages via Internet protocols (http).
Three standards are defined: SOAP, WSDL and UDDI.

SOAP is an XML-based communication protocol. It contains the message that is exchanged between server and client. The combination of transmission (XML and http) makes the protocol independent of programming language and platform.

WSDL (Web Service Description Language) is an XML-based language that describes the interface of a web service.

In the UDDI (Universal Description Discovery and Integration) directory, all web services can be registered so that the client can find the appropriate web service on request.

Different software systems often need to exchange data with each other, and a web service is a method of communication that allows two software systems to exchange this data over the internet. The software system that requests data is called a service requester, whereas the software system that would process the request and provide the data is called a service provider.

Web Service Architecture

To sum it up

There are three stakeholders: The Server (Service provider), the Client (Service requester) and a UDDI directory (Service broker).

As a provider, I give a description of the web service with information about the interface and the communication protocol in WSDL format to a UDDI directory for registration.

Each client can now send a request to the UDDI directory and receives the exact address with which the web service can be reached. There he can request a description of how to use the interface (WSDL) from the provider. Using the communication protocol (SOAP), the client is able to send his request to the interface of the server and thus use the web service.

What information does the WSDL document contain?

When we create a SOAP connector with the Simplifier, we are interested in the structure of the WSDL document. This file contains the following elements to define the interface of a web service:

  • < types > = used data types
  • < mesage > = abstract description of the messages that are transmitted
  • < portType > = callable operations and the associated parameters
  • < binding > = used communication protocol
  • < service > = communication endpoint
WSDL file example

Example WSDL File

How to create a SOAP connector in the Simplifier?

Creating a SOAP connector in the Simplifier is very easy. To create the connector, you only need to specify the WSDL URL and two parameters within the connector calls.

The following video gives an insight on how to create a SOAP connector in Simplifier.

As an example, we would like to get the corresponding country name from a web service when inserting an IP address. The matching WSDL file is available on the Internet at (last used on September 27, 2017, the functionality of the link is not checked).

Step 1: Creating a SOAP Connector

You can add a new connector in the tile “Connectors”. After assigning a name and selecting the correct type (SOAP) you can add a login method. For our example we don’t need any extra authentication, so we jump to the specific data. The connector only needs the WSDL URL.

Step 2: Creating a connector call

There are two Input parameters required for the connector call: “bindingName” and “operationName”. They can be copied from the WSDL file. In addition, we need a third Input parameter, the IP address so that the connector can find the corresponding country name. Therefore we use the notation soap/<operationName>/<parameter>. The parameter can be find in the WSDL document as well.

You can simply use a / as Output parameter to get all the data back.

Step 3: Using the connector

To use the connector in an application, you can insert it within the Process Designer using the Data Object activity. In the Input dialog we can assign all the parameters that the connector needs. In the Output dialog we define which widget should display the data that the connector returns.

Test the Simplifier for 3 month. Or register for a guided demo so we can answer your questions and show you the basic functions of the Simplifier.