Skip to main content

Service Chaining with WSO2 API Manager/API Cloud

Introduction

In the real world we require to create use cases where we need to invoke more than one endpoint to get the response we need for the API. We may require to get the response from one endpoint and manipulate that response and send it to another.

In order to demonstrate this sample let's consider the following flow. We need to design an API which returns details about a country when a country code is entered by a user. One limitation we have is the endpoint which returns the country details expects a country name to be passed. Therefore to accomplish this task we need an intermediate service which gives us the country for the given country code (Service A). After we get the country name then we can pass it to our actual backend service. (Service B)

Flow of events. 

  1. User needs to input a country code 
  2. We need to pass that entered value to the service A which returns the corresponding name of the country back to us. This is the format it will return. {"country": "australia", "code": "au", "fullText": true}
  3. We then pass this country name to the service B and get the response.
Let's get started.

1. First lets create an API which takes the country code as an input and processes the response.
2. Create the API resource as shown below. Which has a uri template of /* and takes an input parameter of the countryCode.


3. Next lets specify the endpoint for this API. What we need to note here is we need this endpoint to be the one we need to invoke to get the details about the country.

Lets specify it as a parameterized endpoint so we can populate the value to it.

http://restcountries.eu/rest/v2/name/{uri.var.country}?fullText={uri.var.isfulltext}

4. Select a tier and save and publish you API.

5. Now we need to implement the intermediate logic which takes this country code, retrieves the country name and then passes this to the backend. For that we need to write a custom in sequence.

I have explained what happens in this sequence in pink text below. We can also add a custom error sequence to this. If so the sequence definition would change as below.

<sequence xmlns="http://ws.apache.org/ns/synapse" name="countrySequence" onError="countryErrorSequence">

I will explain how to add a custom error sequence within a sequence in my next blog post.


<sequence xmlns="http://ws.apache.org/ns/synapse" name="countrySequence" >
<property name="uri.var.countryCode" expression="$url:countryCode"/> 
<!-- This property store the input value we provide-->
<property name="REST_URL_POSTFIX" scope="axis2" action="remove"/>
<!-- Since we do not really need the country code parameter to be sent to out actual backend we need to drop this from the call. This property is used for that -->
    <call blocking="true">
        <endpoint>
            <http method="get" uri-template="http://www.mocky.io/v2/597058891000001b0471d8fc/countryCode/{uri.var.countryCode}"/>
        </endpoint>
    </call>
<!-- We make a call to the above endpoint passing the country code which returns the response with the country name -->

<property name="uri.var.country" expression="json-eval($.country)"/>
<!-- We extract the country name from that response as shown above and store it in a property mediator. We need to give the same name we gave when parameterizing our endpoint in step 3 -->

<property name="uri.var.isfulltext" json-eval($.fullText)/>
<!-- We are setting the value for our next parameter by extracting from the response -->

</sequence>



You can download the sequence from the link.

6. Next we need to add this sequence to our API. Go back to the publisher edit the API and navigate to the impelent page.

7. Select the option to add an in sequence and upload the sequence downloaded from the above linke.



Save and republish the API and go to the store. 

8. Subscribe and generate keys for this API as described in this doc

9. Next invoke the API. You should be able to see the response which we expected.



Now you have successfully completed a service chaining sample with WSO2 API Manager. The same can be achieved in WSO2 API Cloud. Create your WSO2 Cloud Account for free now. 




Comments

Popular posts from this blog

Processing large payloads with the esb script mediator iteratively

Overview WSO2 ESB uses Rhino engine to execute JavaScripts. Rhino engine converts the script to a method inside a Java class. Therefore, when processing large JSON data volumes, the code length must be less than 65536 characters, since the Script mediator converts the payload into a Java object. However, you can use the following alternative options to process large JSON data volumes. The script mediator which is used in ESB is powered by the Rhino engine. Therefore, when processing large JSON data volumes, the code length must be less than 65536 characters which is a limitation in the script mediator being used in the esb versions less than 5.0.0. In ESB 5.0.0 there is a higher capability to process larger payloads using script mediator. In order to process such large payloads we can follow the below two approaches. 1. Replace the javascript tranformation logic using java code by writing a custom mediator. [1] 2. Break down the large payload and execute them as sections using

Exposing a SOAP service as a REST API

In this post i will be explaining how we can transform a SOAP based backend to receive requests in a restful manner through the WSO2 API Cloud. Steps. First log into the WSO2 Cloud and navigate to the API Cloud. In the API cloud select the option to add a new API. We will be creating an API to demonstrate an invocation to the backend soap service ws.cdyne.com/phoneverify/phoneverify.asmx?wsdl Give a name, context and version to the API and add a resource name with a GET Method. The resource name can be anything which you like since we will invoke the actual service usiing a custom sequence. Mention the URI template as indicated in the below screenshot. Next go to the implement tab. And select the endpoint type as HTTP/SOAP Endpoint and specify the endpoint as http://ws.cdyne.com/phoneverify/phoneverify.asmx. There is an important step we need to do here. We need to set the SOAP version for this request. In order to do that we need to select the advanced option for the e

Invoking external endpoints using the call mediator in wso2 api manager

Introduction In API Manager if you need to do any service chaining use cases the call mediator comes in handy. If you need to use the response received by invoking one endpoint and then use it to invoke another endpoint you can use the call mediator in API Manager. The call mediator behaves in a synchronous manner. Hence, mediation pauses after the service invocation and resumes from the next mediator in the sequence when the response is received. You can read more about the call mediator in the wso2 esb documentation [1] . In api manager 1.10.0 the call mediator works in the blocking mode. Prerequisite Before we can use the call mediator in API Manager 1.10.0 we need to make the following changes to some configs. We need to comment the jms transport sender in axis2_blocking_client.xml found in the location APIM_HOME/repository/conf/axis2. This will resolve the jms sender initialization issues.   <!--transportSender name="jms"                      class