IBM App Connect Enterprise (ACE)-Group Nodes

Yasothar Arulnayagam
6 min readSep 18, 2020

Introduction

Just like Software Design Patterns there are Enterprise Integration Patterns and they come in handy when designing middle-ware solutions. In this write-up, we’ll look at a example for Scatter-Gather pattern, one commonly used and very useful Enterprise Integration Pattern. As the name indicates this pattern scatters request messages, sends it to single or multiple end-points and gathers response messages. Assume there is a service, which when we pass a user id, responds with user information. Our requirement is to get a list of user information as response, calling the service multiple times with different user ids. This can be achieved by App Connects’ Group Nodes. Prior to version 10, this scenario required an IBM MQ and aggregation nodes. But with the introduction of Group Nodes in version 10, this mediation has become simple and straight forward. Let’s see how this can be achieved by the following example.

Example REST Project

For this exercise we are going to use the free online API found at https://jsonplaceholder.typicode.com/. You can check the functionality of this API using Postman and check out their documentation. For example when I call this end point https://jsonplaceholder.typicode.com/users/1, user information for id 1 will be returned. Below is the response I got.

{
"id": 1,
"name": "Leanne Graham",
"username: "Bret",
"email": "Sincere@april.biz",
"address": {
"street": "Kulas Light",
"suite": "Apt. 556",
"city": "Gwenborough",
"zipcode": "92998–3874",
"geo": {
"lat": "-37.3159",
"lng": "81.1496"
}
},
"phone": "1–770–736–8031 x56442",
"website": "hildegard.org",
"company": {
"name": "Romaguera-Crona",
"catchPhrase": "Multi-layered client-server neural-net",
"bs": "harness real-time e-markets"
}
}

This API has a set of users ranging from user id 1 to 10. What we are going to do is develop a REST API which takes in two parameters start and end, fetch all those users between a given range and consolidate as a single JSON response. For example if I pass start = 1 and end = 3 user information 1,2,3 will be given as a single response.

Let’s see how we can achieve this with the help of IBM App Connect Enterprise group nodes.

First I created a REST API project with query parameters start and end. start and end parameters would act as the range indicators of user ids.

REST API description
Figure 1 — REST API description

Below would be my message flow implementation.

Message flow canves
Figure 2 — Message flow canvas

One by one I’ll list the code listing and node properties.

Compute node getParams will be setting up the stage. It copies all the InputRoot and InputLocalEnvironment values, so that they can be used in the preceding node.

SET OutputRoot = InputRoot;
SET OutputLocalEnvironment = InputLocalEnvironment;
SET Environment.Destination.GroupScatter.Context = InputLocalEnvironment.Destination;

Take note of the line where GroupScatter.Context is being set with the LocalEnvironment destination. This line indicates, once all the processing is complete, where the response should be sent, the actual initiating source.

Next would be the group scatter node where the fan out process begins.

Figure 3— Group Scatter node properties

Take note the Group name property we have given. This would be unique for Group Gather and Group Complete nodes.

Next is the prepareInputs compute node. As the name indicates this is the node where the preparation of request occurs for the subsequent HTTP Asynchronous Request node. Between the BEGIN and END block following ESQL code should be written.

DECLARE I,J INT 1;

SET I = InputLocalEnvironment.HTTP.Input.QueryString.start;
SET J = InputLocalEnvironment.HTTP.Input.QueryString.end;
WHILE I <= J DO
SET OutputLocalEnvironment.Destination.HTTP.RequestURL = 'http://jsonplaceholder.typicode.com/users/' || CAST(I AS CHARACTER);
SET I = I + 1;
PROPAGATE TO TERMINAL ‘out’;
END WHILE;
RETURN FALSE;

First two lines are variable declarations. Next two lines are getting the query parameter values and setting them for the declared variables. Next is a loop which will iterate from the start to end values. Take note that the RETURN is FALSE. This is to stop the compute node from moving to the next node before completing all the iterations . With each iteration the endpoint will change based on the value of I which is found at the end of the URL as path parameter.

Figure 4 — HTTP Asynchronous Request node Basic tab properties

Next would be the HTTP Asynchronous Request. Properties would be Unique identifier and Web service URL. I have given a dummy value for Web service URL since this value would be overridden in the ESQL code in the previous compute node.

Figure 5— HTTP Asynchronous Request Group tab properties

In the Group tab of properties tick the Add request to group and provide a Request folder name. This name will be used to gather the responses in the consolidateMsgs compute node.

Following will be the HTTP Asynchronous Response node properties.

Figure 5 — HTTP Asynchronous Response properties

Next is the Group Gather node and Group Complete nodes. Always keep in mind that the Group name property should be the same. Finally a compute node to consolidate received response messages. This is will be the ESQL between the BEGIN and END block.

DECLARE card INTEGER;
DECLARE idx INTEGER 1;
DECLARE Ref_grpRef reference TO InputRoot.ComIbmGroupCompleteNode.Group.Replies;

CREATE FIELD OutputRoot.JSON.Data.result IDENTITY(JSON.Array)result;

SET card = CARDINALITY(Ref_grpRef.FLDREMP[]);

WHILE idx <= card DO
SET OutputRoot.JSON.Data.result.Item[idx] = Ref_grpRef.FLDREMP[idx].Reply.Root.JSON.Data;
SET idx = idx + 1;
END WHILE;

SET OutputLocalEnvironment.Destination = InputRoot.ComIbmGroupCompleteNode.Group.Context;

RETURN TRUE;

First two lines are a declarations. Next line would be a reference to InputRoot.ComIbmGroupCompleteNode.Group.Replies We create a JSON array to store the JSON responses. Get the cardinality of the FLDREMP where the responses got stored. We iterate and build the consolidated response in the next few lines and tell the App Connect where the response need to be sent by the following line of code.

SET OutputLocalEnvironment.Destination = InputRoot.ComIbmGroupCompleteNode.Group.Context;

That’s it, we have done a basic sample for group nodes using IBM App Connect Enterprise. I’m not going to put the combined response since it will take up space but if done correctly, this code and configuration will work without any issues.

Conclusion

Service orchestration or implementing a Scatter-Gather Pattern is simple and straight forward in IBM App Connect just as any other middle-ware . In the IIB previous versions Aggregate nodes gave the same functionality but required an IBM MQ. With Group Nodes, need of an IBM MQ is eliminated. Few points to consider when developing the message flow,

  • GroupScatter, GroupGather, GroupComplete should contain the same Group name property (In this example I have given GRPTST).
  • Value of the Request folder property in the HTTP Asynchronous Request node would be referred while consolidating the messages using InputRoot.ComIbmGroupCompleteNode.Group.Replies.
  • Timeouts should be carefully set for large groupings based on the API response times for GroupScatter, HTTP Asynchronous Request, and Group Gather nodes.
  • HTTP Asynchronous Request and HTTP Asynchronous Response should have the same Unique identifier property
  • In the given message flow error/exception handling is not done. You can observe most of the terminals are not connected. Only the happy path scenario is given here. For a complete solution all the terminals should be connected and errors/exceptions should be handled correctly.

References

--

--

Yasothar Arulnayagam

Integration developer, worked on WSO2, IBM integration stack. Java, Spring, Micro-services aficionado.