Version: 17.07
Supported Since: 17.01
University XYZ, has a legacy students' result calculation service and they have decided to upgrade their system and maintain separate services for each department due to the different procedures they have to follow, in-order to calculate the GPA of the given subjects. Although there are changes in the actual back end, they do not want to introduce this dependency to the front end system and maintain their front end system completely independent of multiple results calculation backend web service end points.
University XYZ, has decided to introduce an ESB to mediate their front end calls to respective department wise back end services as shown in below diagram
To solve this problem using header based routing, front end should send the department as a HTTP header for the back end service.
Let’s assume that front end sends HTTP requests with custom header xyz-department
which contains the department name.
ESB will read this xyz-department header from the input request and route the received message to the respective department’s
result calculation endpoint. If the ESB fails to find a matching department or the received department does not have
its own results calculation endpoint, then the received message will be routed to the legacy results calculation endpoint
which is generic for every department, but it does not have the capability of calculating GPA value for the given subjects.
The details of the back end services of each department and the legacy results calculation service is as below,
Computer Science Department - http://localhost:9001/service/department/computer-science
This service returns scores of each requested subject and calculates GPA score for given subjects based on the a specific
approach for Computer Science field
Electronics Department - http://localhost:9000/service/department/electronics
This service returns scores of each requested subject and calculates GPA score for given subjects based on the a specific
approach for Electronic field
Legacy Endpoint - http://localhost:9290/service/getResults
This service only returns scores of each requested subject. Since it’s not fair to calculate in a generic way, this service
doesn’t return a GPA value.
UltraStudio Configuration
UltraESB-X Configuration
In order to implement above use case you must first select following dependencies when you are creating an empty Ultra project
HTTP NIO Connector dependency from the connector list.
Flow Control dependency 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. |
To implement above use case, first let’s create our integration flow named “header-based-routing-flow”. Then let’s add required components by going through following steps in order.
Add a HTTP Ingress Connector from the connectors list, to accept the result calculating HTTP messages. HTTP Ingress Connector should be filled as shown below to expose a single web service on port 8280 and under /service/getResults service path to calculate results using above department specific web services and legacy web services.
Add a Switch Case processing element to check the department and select the result calculating endpoint based on the
department name. This processing element should look for the value of the transport header with name xyz-department
and forward the message to the respective HTTP egress connector. For this, basic parameters of this processing element should be filled as shown below.
Add three Case processing elements for each possible value of the department transport header which should be evaluated at the Switch processing element.
Add three HTTP Egress Connector elements to send message to respective departments results calculation service.
The completed integration flow should look like below.
Configuration for each element is as below. The numbering corresponds to the numbers shown in above diagram.
Design View
Text View
1. HTTP Ingress Connector
2. Switch Processing Element
3. Case Processing Element
4. Case Processing Element
5. HTTP Egress Connector
6. HTTP Egress Connector
7. HTTP Egress Connector
1. HTTP Ingress Connector
|
8280 |
|
/service/getResult |
2. Switch Processing Element
|
Header |
|
xyz-department |
|
String |
|
EQUALS |
3. Case Processing Element
|
Electronics |
4. Case Processing Element
|
Computer Science |
5. HTTP Egress Connector
|Destination Address Type | URL |Destination Host | localhost | Destination Port | 9290 |Service Path | /service/getResult
6. HTTP Egress Connector
|
URL |
|
localhost |
|
9001 |
|
/service/department/computer-science |
7. HTTP Egress Connector
|
URL |
|
localhost |
|
9000 |
|
/service/department/electronics |
Now you can run the Ultra Project and check the functionality of the integration flow. Create an UltraESB Server run configuration and start it.
In-order to run this sample in UltraESB-X distribution, no property modification 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 header-based-routing
After running the project, test the header based routing as per the configured values,
if the xyz-department header value is "Computer Science", then you should be able see the message is sent out to computer science department’s endpoint by checking the message path of the UltraStudio.
if the xyz-department header value is "Electronics", then you should be able see the message is sent out to electronic department’s endpoint by checking the message path of the UltraStudio.
if the xyz-department header value is not specified or not equal to either of above two, then you should be able see the message is sent out to the legacy endpoint by checking the message path of the UltraStudio.
All requests must be sent to http://localhost:8280/service/getResults URL.