Skip to main content

An example of proxy transforming a JSON response and merging multiple responses into single response.

The API Gateway has a default mediation flow for the API invocation requests that it receives. You can extend this default mediation flow to do additional custom mediation for the messages in the API Gateway. An extension is provided as a synapse mediation sequence. You design all sequences using a tool like WSO2 Developer Studio and then add the sequences to the API.


Prerequisite

Download WSO2 Developer Studio (version 3.7.1 is used here) from http://wso2.com/products/developer-studio/ and open it by double clicking the Eclipse.app file inside the downloaded folder.

Need to have an existent account with the WSO2 API Cloud.

Steps:
  • In the normal manner create the API providing a name and context. (You can follow the tutorial here [1]) 
  • Before specifying the resource select the ‘Implement’ button. You will be asked whether to include a wild card resource select yes and proceed to the next step. 
  • Here there will be a button which asks whether you will need to include a custom sequence. Before this you will need to create the below sequences after which you can upload them in this page. 
  • Go to the Developer Studio option in the title bar and select open dashboard. 
  • Select the ESB Config Project and create a new project 
  • Right click on the project and add two sequence names . I have created the in sequence as IteratingSample and the out sequence as AggregateMediator.
  • What we will be doing in this will be to iterate the post request made by the customer id and make individual requests to the service.
  • In the In sequence It will iterate through the list. The xml file corresponding to the sample can be found here. Below is the sequence used for the sample. The expression to iterate is chosen as “//customerIds/customerId “as that is the format of the json payload we passed into the POST method. More details about the mediator can be found here. 
iteratingSample.png

For the out sequence we need use an aggregate mediator which will wait until and the responses are received made by the in sequence and then we aggregate all the results and return as a single response. The following is the sequence used for the out sequence. The sequence can be found here. More details about the aggregate mediator can be found here.

aggregate.png
  • Now we have completed creating the sequences, 

  • Next we need to add these two sequences to our API through the publisher 

  • In the API's implement tab you will need to add it as mentioned in this tutorials step 16. Add the IteratingSample.xml as the in sequence and the AggregateMediator.xml as the out sequence.


  • Next Manage and select the tiers. 
  • Save and Publish the API. Then go to the store and subscribe to this API and generate the access token. 
  • Go to the API Console of the API. 
  • Expand the POST method and give the payload as follows and Try this. What we have done here is sent a list of ids for which we need to retrieve the information about. 

{ "customerIds": { "customerId": [ "123", "124", "125" ] }}

You will be able to see a json response which has merged multiple responses into one response. This is what you will be able to see. The requests have been processed parallel.




Special Notes:

The endpoint [3] by default only has the payload for the customer id "123" if you need to add more entries for the respective ids you can post the values to the endpoint using the following payload format.

{ "Customer": { "name": "Sera" }}

References:

Comments

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

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"        ...
1 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