REST Service Mediation

Version: 17.07

Supported Since: 17.01

Use Case Description

An organization has a REST service and wishes to mediate the invocation of this REST service with the ESB. Any response going with HTTP "Location" headers from the back end REST service needs to be switched to ESB, so that all traffic to the REST service goes through the ESB.

Figure 1. REST Service Mediation Overview

Proposed Solution

As shown in the above diagram, instead of directly talking to the REST service, UltraESB acts as the proxy for all the requests going to the back-end server.

To demonstration purposes we will use https://openweathermap.org/current as the REST service backend and mediate requests to that through the ESB.

UltraStudio Configuration

UltraESB-X Configuration

Implementation of the Solution

Prerequisite

In order to implement above use case you must first select following dependencies when you are creating a new Ultra project.

NIO HTTP Connector from the connector list
Message Logger from the processor list

If you have already created a project, you can add above dependencies via Component Registry. From Tools menu, select Ultra Studio → Component Registry and from the Connectors list and Processors list, select above dependencies.

Implementation

To implement above use case, first let’s create our integration flow named “rest_service_mediation” and then add required processing components by going through following steps in order.

Add a NIO HTTP Ingress Connector from the Connectors → Ingress Connectors list, to accept REST requests. NIO HTTP Ingress Connector should be configured as shown below to expose a single web service on port 8280 and under "/service/rest-proxy" service path.
Add a NIO HTTP Egress Connector from the Connectors → Egress Connectors list, to forward request to back end REST service. It should be configured as shown below table. Connect the Processor out port of the previously added NIO HTTP Ingress Connector to the Input of this egress connector.
Add a Logger processing element from the Processors → Generic list. This should be configured as shown below. Note that the usage of logger element is not essential and it is used just log the response. Connect the Response Processor out port of the previously added NIO HTTP Egress Connector to the Input of this Logger element. Also connect the Next out port of this processing element back to the Input of the Netty HTTP Ingress Connector to send back the received response.

The completed integration flow should look like below (Figure 2).

Figure 2. REST Service Mediation Flow

Design View

Text View

.

1.HTTP NIO Ingress Connector

2.NIO HTTP Egress Connector

Notice the use of PREFIX as the Destination Address Type here. It is used to forward the incoming requests to "api.openweathermap.org".

3.Logger Processor

.

1. NIO HTTP Ingress Connector

Http port

8280

Service path

/service/rest-proxy

2.HTTP NIO Egress Connector

Destination Address Type

PREFIX

Destination Host

api.openweathermap.org

Service Path

/data/2.5/weather

Notice the use of PREFIX as the Destination Address Type here. It is used to forward the incoming requests to "api.openweathermap.org".

3.Logger Processor

Log Template

@{message.payload}

Log Level

INFO

.

Now you can run the Ultra Project and check the functionality of the integration flow. Create an UltraESB Server run configuration and start it.

Property Configuration

In-order to test this sample project in UltraESB-X distribution, no property externalization is required

Navigate to $ULTRA_HOME/bin directory. Next you can run the UltraESB-X distribution with following command to start the engine with this sample project deployed.

./ultraesbx.sh -sample rest-service-mediation

Testing the Integration Project

Send a HTTP GET request to http://localhost:8280/service/rest-proxy?q=London&APPID=4f39ab00e0ea663ad801b6bd12799cb6. (You can use the HTTP/S Client shipped with Ultra Studio Toolbox for this purpose).

Note that the APPID query parameter is the application id for the openweathermap API.
You can observe the response as follows.

HTTP/1.1 200 OK
Cache-Control: no-cache, must-revalidate
Access-Control-Allow-Origin: *
Access-Control-Allow-Credentials: true
Access-Control-Allow-Methods: GET, POST
X-Cache-Key: /data/2.5/weather/?APPID=4f39ab00e0ea663ad801b6bd12799cb6&q=london
Pragma: no-cache
Date: Tue, 17 Jan 2017 10:19:21 GMT
Content-Type: Optional[application/json; charset=utf-8]
X-Powered-By: Fat-Free Framework (http://fatfree.sourceforge.net)
Server: AdroitLogic UltraStudio UltraESB-X
Content-Length: 446
Connection: close

{"coord":{"lon":-83.45,"lat":39.89},"sys":{"type":1,"id":2171,"message":0.1952,"country":"US","sunrise":1484657521,"sunset":1484692581},"weather":[{"id":500,"main":"Rain","description":"light rain","icon":"10n"}],"base":"stations","main":{"temp":284.46,"pressure":1014,"humidity":100,"temp_min":283.15,"temp_max":286.15},"visibility":11265,"wind":{"speed":5.7,"deg":160},"clouds":{"all":90},"dt":1484646060,"id":4517009,"name":"London","cod":200}

Terms of Use