HCI: Using Eclipse WSDL Editor for SOAP-based integration

Introduction

For SOAP-based integration, SOAP receiver channels are used to consume web services whilst SOAP sender channels are used to expose HCI as a web service. When the target system is a SOAP web service, we can easily implement a passthrough interface in HCI and reuse the target system’s WSDL in the SOAP sender channel of HCI’s iFlow. Currently HCI only supports SOAP adapter as sender channel to expose synchronous web service interfaces. So if the target system is not SOAP-based (i.e. REST or OData), we will need to manually define the WSDL for the sender side of the iFlow in order to expose the service as a SOAP web service via HCI.

For those who are used to PI/PRO development, this is normally achieved by creating a sender Service Interface using Data Type (and Message Type) defined with the built-in Data Type Editor.

However, the current HCI development tool on Eclipse does not come with an easy-to-use Data Type Editor. For those who have a working PI/PRO installation, Service Interface definitions can be imported from PI/PRO. However, those who do not have PI/PRO, the WSDL for the sender will have to be manually created using other XML tools like XMLSpy, Oxygen, etc.

Fortunately, Eclipse also comes with it’s own native WSDL Editor. In this blog, I will share the steps on how the WSDL Editor can be used to generate a WSDL to be used in the sender SOAP channel of an HCI iFlow.

Component Details

Below are component versions of the Eclipse plugins that still do no have a native Data Type Editor. Hopefully SAP will port NWDS’s ESR Data Type Editor to a future version of HCI.

Eclipse Plugin Versions: Adapter 2.11.1, Designer 2.11.1, Operations 2.10.0

Creating WSDL for Sender SOAP Channel

For the example, we will create a WSDL for a synchronous interface. This WSDL will be configured in the sender SOAP channel of the iFlow. It will have the following structure.

Request

Segment/Field Name	Occurrence
OrderKeys	1 – unbounded
> orderNo	1
> orderDate	0 – 1

Response

Segment/Field Name	Occurrence
OrderDetails	0 – unbounded
> OrderName	1
> OrderID	1
> ItemCount	1

Step 1 – Create a new WSDL file

Right click on the wsdl folder and select New > Other…

Select WSDL File from the wizard, and provide a name for the file.

In the options screen, specify additionally the namespace and prefix, and accept the rest of the default values.

A skeleton WSDL file will be created and it will be opened in the WSDL Editor’s Design view as shown below.

Step 2 – Rename Operation

Operation is similar to a Service Interface’s operation in PI/PRO. Highlight the default NewOperation value generated by the wizard and rename it accordingly as shown below. The names for the input and output parameters will be updated automatically.

Step 3 – Define request structure

Define the request structure as per the above table.

Click the arrow next the to input parameter. An inline schema editor will be opened. By default, the input parameter is just a single string field named in.

Change the properties of the input parameter as shown below. For Type, select New, to create an inline Complex Type using any arbitrary name (Key is used in the example).

The input parameter will be updated as shown below. Basically it means that the input parameter is of Key complex type which can occur 1 or more times.

Next we proceed to define the structure for the Key complex type. In order to do this, click the button at the top left Show schema index view.

An overview of the schema with all elements, types will be displayed. To edit the complex type Key, double click on it.

It will bring us to the definition of Key. Here we can add additional elements to Key by right-clicking and selecting Add Element.

Add the first field orderNo of type xsd:string as shown below.

Repeat for the second field so that the final definition of Key is as shown below.

Step 4 – Define response structure

Repeat the steps above for the response structure per the definition table.

For the final outcome, the output parameter is named OrderDetails of complex type OrderDetail and occurs 0 or more times.

Similarly, the OrderDetail complex type is defined as follows with three mandatory fields.

With this, we complete the definition of the WSDL file.

Step 5 – Import WSDL into PI to verify (Optional)

As an optional step, we can import the WSDL into PI as an external definition to view and verify that the structures have been defined correctly.

Using WSDL in iFlow

Once the WSDL has been fully defined, it can be included in the SOAP sender channel of the iFlow.

After the iFlow development is completed and deployed. The actual WSDL for the HCI web service can be downloaded from the tenant. Select the IFLMAP node from the Node Explorer. Switch to Services in the Properties tab. Select the corresponding Endpoint of the HCI iFlow, right-click and select Download WSDL > Standard.

This final WSDL that is downloaded will be very similar to the WSDL created for the sender channel, except it will contain the endpoint to the service on the HCI tenant.

Additional Info

The WSDL Editor can be also used to create the WSDL file for asynchronous interfaces. For these, just delete the output parameter from the skeleton WSDL created by the wizard.

Conclusion

As shown above, we can utilize Eclipse’s built in WSDL Editor to assist us in defining WSDL files for SOAP based interfaces. It is relatively easy to use, and more importantly free compared to other license based XML editors like XMLSpy or Oxygen. We can also work with it within the same development environment for HCI iFlows without needing to launch another external tool.

Ideally it would be great if SAP ports the NWDS ESR Data Type Editor to HCI, but in the meantime we can at least rely on Eclipse’s editor.

Reference

Introduction to the WSDL Editor – Eclipsepedia