Skip to main content

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="org.apache.axis2.transport.jms.JMSSender"/>-->

We need to enable to JWT token generation by adding the below to the api-manager.xml found in the location APIM_HOME/repository/conf/api-manager.xml.

<EnableTokenGeneration>true</EnableTokenGeneration>

After you have done these changes restart the API Manager. 

Let's get started.

Now let's take a look at how we can carry out a use case with the call mediator. I will be creating an API which calls an endpoint which displayed details of a given capital city. For the production endpoint I have given a static endpoint and will be demonstrating how we can use the call mediator within the sequence.

1). Create an API as per the image below with a query parameter to input the capital name we need to use the call mediator to invoke.


2) For the production endpoint I am using a static endpoint. Here you can give whatever the endpoint you like the response to be.

3) Next we need to add our custom sequence which will use the call mediator to call another endpoint and get the response within the sequence. Below is the custom sequence and you can also download it from HERE. We will be using the query parameter passed as capital to dynamically call the call mediator's endpoint. The call mediators endpoint displays information based on the capital. We are removing the property REST_URL_POSTFIX here since we don't actually need this query parameter when invoking our actual production endpoint. 

<sequence xmlns="http://ws.apache.org/ns/synapse" name="callMediatorSampleSeq">
<property name="uri.var.capital" expression="$url:capital"/> 
<property name="REST_URL_POSTFIX" scope="axis2" action="remove"/>
    <call blocking="true">
        <endpoint>
            <http method="get" uri-template="http://restcountries.eu/rest/v1/capital/{uri.var.capital}"/>
        </endpoint>
    </call>
<log level = "custom">
<property name = "Sequence name" value="In the call mediator sequence"/>
<property name = "Capital name" expression="get-property('uri.var.capital')"/>
<property name="JSONPayload" expression="json-eval($.)"/>
</log>
</sequence>


4) Add the sequence to your API as shown below into the in sequence section [3]. Next add the desired tiers and save and publish your API.


5) Next when we invoke the API we can see that the response of the call mediator has been received inside the sequence before calling the actual endpoint. The swagger console will show that of our actual backend endpoint.


You can see the payload received from the call mediator endpoint execution in the backend console.


Simillarly you can use this payload received from the call mediator inside the in sequence to pass to other endpoints. You can modify the payload and set it accordingly before calling other endpoints using the Payload factory mediator. [2]

Also you can try the same use case using the WSO2 API Cloud where you would not need to do the steps in the pre requisite section since they have already been done in our cloud deployement. You can signup and login to the WSO2 cloud using this link
Hope that this blog has helped in using the call mediator to call endpoints other than the API endpoint in order to get the response to carry out other manipulations.

Comments

  1. UnknownMarch 28, 2018 at 12:10 AM

    the blog is good and Interactive it is about Mulesoft API Developer it is useful for students and Mulesoft Developers for more updates on Mulesoft mulesoft Online training hyderabad

    ReplyDelete

Post a Comment

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 ...
Post a Comment
Read more

Configure WSO2 Identity Server for single sign on with Moodle - Part I

Introduction Moodle is a learning platform designed to provide educators, administrators and learners with a single robust, secure and integrated system to create personalized learning environments.[1]. This is commonly used in the education sector and there might be occurrences where it would require to use SAML to login to Moodle instead of the default basic authentication. For this we would need to have an Identity Provider capable of issuing such SAML tokens and Moodle configured to accept the tokens in order to do the authentication I will be discussing this in two parts. Part I - How to configure moodle for SSO with WSO2 Identity Server Part II - How to carry our user provisioning and attribute profile mapping with Moodle and WSO2 Identity Server Let's see how this can be achieved using a SAML authentication plugin provided by one login. Prerequisite  You need to have a working version of Moodle installed. If you want to try this tutorial from scratch you can ...
1 comment
Read more