Content Based Routing

Version: 17.01

Supported Since: 17.01

Use case description

University XYZ, has a legacy students results calculation service and they decided to upgrade their system and maintain separate services for each department due to the different procedures they have to follow to calculate the GPA of the given subjects. Although there are changes in the actual back end, they don’t want to introduce this dependency to the front end system and maintain their front end system completely interdependent of multiple results calculation web service end points.

Proposed Solution

University XYZ, decided to introduce an ESB to mediate their front end calls to respective department wise back end services as shown in below diagram

ESB will extract the relevant department based on the field in the input message and route the received message to the respective department’s result calculation endpoint. If it couldn’t find matching a matching department or the received department doesn’t have it’s 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 doesn’t 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:9000/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.

Implementation of the Solution

Prerequisite

In order to implement above use case you must first select following dependencies when you are creating an empty Ultra project

HTTP NIO dependency from the connector list.
Flow Control and Content Extractor dependencies 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 “university-xyz-content-based-routing”. 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. HTPP Ingress Connector should be filled as below table to expose a single web service on port 8280 and under "/service/getResults" service path to calculate results using above department specific and legacy web services.
Add a JSON Path Extractor processing element to extract out department name from the input message. As per following input message, JSON path for the department tag should be "$.Registration.department". Let’s save the extracted value as a variable with name "Department" to use in next processing elements.

{
  "First name": "John",
  "Last name": "Carlton",
  "Registration": {
    "id": "090097G",
    "department": "Computer Science",
    "batch": "batch-09"
  },
  "Subjects": [
    {
      "id": 12295,
      "subject-code": "CS309",
      "name": "Advanced Algorithm",
      "category": "compulsory"
    },
    {
      "id": 12280,
      "subject-code": "CS103",
      "name": "Database Systems",
      "category": "compulsory"
    },
    {
      "id": 12325,
      "subject-code": "CS209",
      "name": "Computer Vision",
      "category": "optional"
    }
  ]
}

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 "Department" variable and forward the message to the respective HTTP egress connector. For this, basic parameters of this processing element should be filled as in the following table.
Add a Switch Case processing element to evaluate departments and select the result calculating endpoint based on the department name. This processing element should look for the value of the "Department" variable and forward the message to the respective HTTP egress connector. For this, basic parameters of this processing element should be filled as in the following table.
Add three Case processing elements for each possible value of the "Department" variable which should be evaluated at the Switch processing element.
Add three HTTP Egress Connector elements to send message to respective departments results calculation service.

Each element of the flow should be filled as below

1	HTTP Ingress Connector
2	JSON Path Extractor
3	Switch Processing Element
4	Case Processing Element
5	Case Processing Element
6	HTTP Egress Connector
7	HTTP Egress Connector
8	HTTP Egress Connector

Now you can run the integration flow and check the content based routing execution. As per the configured values,

if the department 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 department 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 department 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.

Terms of Use