Things change but stay the same
App Connect Enterprise (ACE) has been out for a while.
As an integration tool, one of the patterns teams use WMB/IIBACE for is the scatter gather pattern .
If you haven't used this pattern before, it is a way to aggregate data from different sources and send the response back in a single response.
So, if you want to know what stock is on hand, you might send a "get stock message" to an ACE msgflow.
The msgflow send out a request to "wharehouse1", "wherehouse2" and "wherehouse3" services (queues, http endpoints etc..).
ACE then aggregates the the results so that the caller can know how many widgets that they can order it total from all the warehouses.
There is a good WMB/IIB centric article that covers it here .
The nodes required when developing this type of flow using WMB/IIB are :
AggregateControl node:
AggregateReply:
and
AggregateRequest:
In WMB/IIB these flows, behind the scenes, makes use of "hidden" or "private" queues to manage state. So you need an MQ running to make use of them.
The upgrade from WMB/IIB to ACE involved re-engineering to support easier deployment to the cloud. This included reducing the dependency on an MQ install/deployment.
ACE introduced some new nodes to work using the scatter/gather pattern without the need to integrate with IBM MQ/Websphere MQ.
The new nodes are similar in the way they work in the previous versions of ACE (WMV/IIB). More details can be found here and another good medium article covering it here .
领英推荐
Like in my previous article about timers, flows with this sort of logic is difficult to test. So anything that we can to help reduce coding issues or bugs with static analysis of the code helps.
So to support these new nodes, we introduced a number of new rules:
These rules help to check for spelling mistakes in the nodes group to make sure that they will match. If they don't all match the logic can't function.
By keeping the nodes in a single flow they it makes the logic easier to understand. It also ensures that they cannot be only partially deployed where 1 flow is that contains half the process is deployed and another flow that contains the rest is not. Or is deployed in a separate runtime and they cannot communicate behind the scenes.
Using the same group name will cause issues if flows are deployed in the same runtime.
I had thought that a rule to suggest replacing the AggregateControl node with the GroupScatter node might make sense. It will assist with determining how much work and effort is involved in migrating flows from WMB/IIB to ACE.
So that gives me something to look at next.
More information on our products and on pricing can be found on our website:
You can also reach me via email at:
Or contact me via the contact page on our website:
Regards
Richard