If you read my blogs over the years, you may be thinking: “SOAP to REST? Didn’t he write this a couple of years ago?”. And you would be right 🙂

When using API Management, you are securing, publishing and analysing your own REST APIs.
When using Open Connectors, you are drastically simplifying access to non-SAP cloud applications.

Today I would like to show how you can build your SAP Cloud Platform Open Connector – using a SOAP service in the backend. The goal is not to give you in-depth knowledge about Open Connectors, but rather to get you started – or give you an idea on how simple Open Connectors can be used.

If you want to know more about Open Connectors, I would highly recommend looking at Divya’s excellent Blog Series.

Let’s start with a couple of theoretical things…

SAP Cloud Platform Open Connectors

“Compose with a world which you cannot control”

At SAP, we have understood that the world is changing fast.

Especially the Cloud is being very disruptive since customers can leverage any kind of service they need, quickly and usually pretty simply. This freedom comes with price: communicating – eg. integrating – with these services can be complex. Why?

• Technology may be the same (HTTP) but the details will be killing you: SDK, OAuth, SAML, SOAP, REST, OData, Certificates, different resource names, different error codes, bulk limitations….
• Interfaces may change without your knowledge, making you – and your business – vulnerable: “Oh! That used to work yesterday and I did not touch a line of code…”

These two problems are being addressed by SAP Cloud Platform Open Connectors. By harmonising access to third-party cloud solutions and by maintaining them centrally, you end up with “Connectivity-as-a-service” – which can be used by either developers or integration experts to greatly ease their daily jobs.

Taking a step further: once your colleagues are using Open Connectors, why not also use this service to provide them with a connector to your company’s services? For instance a REST API pointing to a SOAP service… In that way, your colleagues continue to use the one central Open Connector service, which decouples and harmonises your interfaces across your IT Landscape…

Hands-on…

Prereqs

In the next steps we will build a Connector using an existing SOAP service.

Hence we’ll need a public SOAP service (so everyone can implement the following steps). The information about the Service can be found here: http://www.dneonline.com/calculator.asmx

Especially the WSDL can be found here:
http://www.dneonline.com/calculator.asmx?WSDL

Later in the exercises, you will be able to either upload the WSDL file or directly point to the URL.

From an SAP perspective, you will need an SAP Cloud Platform environment where you can use the Open Connectors service from. Either you already have purchased it, or you can use the free trial.

Let’s go

Now that we have sorted the details, let’s get rolling!

Login into your SAP Cloud Platform Open Connector environment. I will assume that you know what you are doing here 🙂

Click on “Connectors” on the left-hand side menu.

Here you can see the available connectors, including those you are already using (can bee seen with the blue indication of number of instances).

Click on “Build new connector” at the top-right of the screen.

As I said earlier, we want to create an Open Connector from a SOAP service, so we’ll do that in the next screens.

Click on “Import”.

Select “SOAP” and paste the URL from the SOAP service. You could also upload the WSDL.

http://www.dneonline.com/calculator.asmx?WSDL

Once the SOAP service is imported, you can select the resources you want to publish within your Connector. This would be a good moment to get rid of anything you don’t want to be available to your integrators or developers.

I simply selected all – for the sake of simplicity – and clicked “Import”.

In the next step we’ll do 2 things:

• add the base URL: this is the original URL of the webservice.
  http://www.dneonline.com/calculator.asmx
  • get rid of the authentication: here you could map the existing authentication to something different. In our case we’ll simply remove the authentication alltogether by selecting “custom”.

Save your changes by clicking the “Save” button.

Your end result should look like this:

Now you may have noticed that the Connector name at the top isn’t very user friendly. Let’s change this by clicking on the “Information” menu item at the top.

Change the name, description (and even the logo!) to something meaningful – and save.

So far, so good. Let’s now focus on the actual REST API.

As for now, the “add” action has been mapped to a resource name and to the HTTP “POST” verb. Also, the query is passed as body, in a SOAP envelope.

For the API to be inline with restful principles, we’ll change all that:

• The resource “Add” will accept two query parameters
• POST shall become GET

To do so, click on “Resources” at the top of the screen and select the “Edit” button of the “add” resource:

Now add two “empty” parameters and define them as follows:

First row, corresponding to how the parameter is defined to the API user:

Name: FirstNumber
Type: query
Data Type: integer
Source: request
Description: First number

Second row, the mapping to the actual backend parameter (“vendor’s information”):

Name: intA
Type: bodyToken
DataType: integer

Do the same for “SecondNumber” and “intB”.

The result should look something like this:

We don’t need the “body” anymore, so let’s remove that using the red trash bin icon.

Last step: change the HTTP method to “GET” instead of “POST”. You will notice the blue background 🙂

Now, save everything: first the resource, then the Connector.

Click on the “Save” icon of the “add” resource, then on the “Save” button of the connector, top-right corner.

Once done, let’s test everything by creating an “Authenticated Instance”.

Give your authenticated instance a name and create it as follows:

Once your authenticated instance is available, you can test it using the “API docs”.

Within the documentation, click on the “GET” method of the “add” resource, then on “Try it out”, and fill in the parameters. Click on Execute.

Et voilà!

You should have the result of your sum!

Wrap-up

Open Connectors is extremely useful when it comes to introduce “Connectivity-as-a-Service” to your organisation. Not only can you harmonise, thus simplify, the access to Cloud Applications, you can also add your own connectors. In that way, integration experts and developers can really focus on what they are good at: building integration flows or applications, without being bothered to understand the details of every service they need to use.