Welcome!

XML Authors: Roger Strukhoff, David Smith, Michael Bushong, Elizabeth White, Jason Bloomberg

Blog Feed Post

SOAP-to-REST with Parameterized URLs and content-based routing using the Vordel API Server

The world is moving from SOAP to REST. Many applications continue to send old-style SOAP messages. Therefore, a very common usage of the Vordel API Server is to convert from legacy SOAP messages into REST API calls. This provides the best of both worlds: (1) Existing SOAP apps continue to work and don't have to be re-coded, and (2) going forward, REST APIs are used instead.

I've put together an example of this below. In this case, I'm using the common Parlay-X format which is SOAP-based, and I'm converting to the GSMA OneAPI, which is a REST API. The example I'm using is the common "amountCharging" service, which, here in Vordel, we often encounter with our telecoms customers [Side note: Here is some information about how BT, 3 UK, Telefonica, and TIM Brasil are using Vordel with their telecoms services]. 

Here's an example of a legacy SOAP message to our Parlay-X API:


<?xml version="1.0" encoding="UTF-8" standalone="no"?> <soap:Envelope xmlns:soap="http://schemas.xmlsoap.org/soap/envelope/"> <soap:Body> <par2:chargeAmount xmlns:par2="http://www.csapi.org/schema/parlayx/payment/amount_charging/v2_1/local"> <!-- Element must appear exactly once --> <par2:endUserIdentifier>www.abc.com</par2:endUserIdentifier> <!-- Element must appear exactly once --> <par2:charge> <!-- Element must appear exactly once --> <description>a</description> <!-- Zero or one occurrences --> <currency>a</currency> <!-- Zero or one occurrences --> <amount>1.0</amount> <!-- Zero or one occurrences --> <code>a</code> </par2:charge> <!-- Element must appear exactly once --> <par2:referenceCode>a</par2:referenceCode> </par2:chargeAmount> </soap:Body> </soap:Envelope>


You can see above that this is a charge for some "Game Currency", of the amount of 25 US Dollars. 

We want to convert this to a REST API call like this:

http://api.myhostname.com/1/payment/6175551234/transactions/amount

You might notice, in the example, that the "endUserIdentifier" value in the SOAP message must be mapped into part of the URL used by the REST API. This is sometimes called a "Parameterized URL", or REST API parameterization.

Let's see how this is configured at the Vordel API Server...

The first step is to register the Parlay-X WSDL. I am doing this within the API Server's Repository, which I am accessing using the Policy Studio (Under "API Server" -> "Business Services", then right-clicking on the group I want to import the service into, and selecting "Register Web Service"). 



I am choosing the "chargeAmount" operation, as shown above, by selecting it. I simply follow through the rest of the steps as default, and for the final step, I'm choosing to deploy under a group called "Default Services", which has a number of HTTP listeners, and an SSL listener, as shown below:

The API Server will automatically create the mapping from the inbound path to the policy for our Parlay-X service. 

Finally we hit "Deploy" to deploy our new SOAP service to the API Server. 


The next step is to map from the SOAP message to the REST API call. Let's see how this is done.

Here is the WSDL for the virtualized Parlay-X service at the API Gateway. I load this up into the free Vordel SOAPbox tool (or SOAPUI) in order to generate a sample SOAP request to this Parlay-X service. 


I then save this sample request as a file called "SampleSOAPMessage.xml". We will use this in order to tell the API Server how to look up the "EndUserIdentifier" value from the SOAP now.

When I registered the Parlay-X WSDL, a sample "handler" was created for me. I am going to delete this, and configure my own handler, which reads the value from the SOAP and dynamically constructs the REST API requests based on the "EndUserIdentifier" value. So first let's delete the default handler:


Next, I drag in a "Set Service Context" into my empty canvas, and I choose the WSDL for the Parlay-X service I just imported. What I am doing here is telling the API Server (and Vordel Analytics) the name of the SOAP service, so that this shows up in monitoring and Analytics. 


Remember to select "Set as start" for this filter. Otherwise it will continue to be grayed out and will not run. Here I am setting it as start:


In the next step, I am setting Schema Validation for my incoming message. Note that, if we don't want to schema-validate the message, you can skip this step. I put a green arrow from the "Set Service Context" filter into the "Schema Validation" filter. 


Next, I am using a "Retrieve from message" filter to select the value of the EndUserIdentifier field from the XML. As you can see below, I am using the XPath Wizard in Policy Studio with the sample message which I made from SOAPbox (or SOAPui if you prefer). I select the place where the EndUserIdentifer is to be found in the message, and I set that it will be placed into an attribute (variable) called "EndUserIdentifier". 



Next, I am using a "Switch" filter to switch based on the content of that "EndUserIdentifier" variable. You can see that I'm saying "If it starts with '617', use routing policy 'Route to Px Service 1", "If it starts with '212', use routing policy 'Route to Px Service 2", etc. This Switch filter is very powerful.


At this point your policy should look like this next screenshot:


So let's look at one of the routing policies which we are calling from our Switch filter. This is a routing policy which is creating a REST API request. It consists of four simple steps. 

Step one is to rewrite the URL, taking into account the EndUserIdentifier value which we read in from the SOAP message. You can see it below with the syntax ${EndUserIdentifier}


Step two is to set the verb to "GET". Because the incoming SOAP message was sent using a POST verb, but we want to use GET to connect to our REST API, I am using a "Set HTTP Verb" filter to convert the verb to "GET".


Step three is to use a "Static Router" filter to set the hostname and port of my REST API server which I want to route to:



Step four is to place a "Connection" filter after the "Static Router". I accept all the default for the "Connection" filter. Note that if I was connecting over SSL to the API, I'd have to make sure I checked the boxes for the certificates used at the endpoint, so that they are trusted.


And that's it! What we achieved here is:

1) Converting from a legacy SOAP request to a REST API call
2) Parameterization of a URL, based on a value read from a SOAP message
3) Conditional routing based on the value from a message (content-based routing).

If you'd like to see more "recipes" like this, check out the tutorials on the Vordel website.

Read the original blog entry...

More Stories By Mark O'Neill

Mark O'Neill is VP Innovation at Axway - API and Identity. Previously he was CTO and co-founder at Vordel, which was acquired by Axway. A regular speaker at industry conferences and a contributor to SOA World Magazine and Cloud Computing Journal, Mark holds a degree in mathematics and psychology from Trinity College Dublin and graduate qualifications in neural network programming from Oxford University.