5 Things you need to know about Routing Rules

Here at Redhound, we have a wealth of experience of enterprise integration and messaging projects. Here we’ll share some more of that experience with you around the Routing Rule Engine (RRE). At the end of it, you’ll have a better feel about how to implement one, but if you’d like to chat about it, just get in touch.().


So, let’s get on with it…


The RRE is the fundamentally essential component of enterprise integration and messaging projects. Without a coherently designed RRE implementation, you’ll very quickly have a trade flow or other message driven wokflow process that’s out of control. Not so much peeking in to Pandora’s box as ripping the lid off, kicking it over and shaking the contents out.

1. Save money- think strategically
You may think that your workflow is a simple affair. It has a single point of entry for actors. The progression is linear. Data flows to core app A then core app B then core app C. Why would you waste time on a RRE implementation? The answer lies in the addage, “Hope for the best. Plan for the worst”. Spending time thinking about a strategic way forward for your domain and what issues you may encounter in the future is an invaluable investment.


How soon will it be before you have to start handling breaks in your flow? Or you are required to add another core app? Or a recs process? The moment you have to start thinking about that, then your original message plumbing needs to be redone. Not just during your development but in a BAU production appplication stack – that sounds like a blast. It’s the enterpise integration equivalent of laying a gas main to a housing development and then having to dig it up again to lay the electricity cables. In short, it’s very expensive both in money and reputation.

2. Support dual routing
Messaging flows in enterprise domains are more often than not devilishly complicated. The Nirvana of a linear data flow is very rarely seen. More often than not, your incoming actor message will need to be directed to more than one destination. Your incoming trade needs to go to the recs process as well as to the accounting function. Your routing rules need to be able to cater for that in the most efficient way possible. At first glance, it would make sense to have a routing rule for each destination:

• Rule A with condition xyz is matched and the trade is despatched to the recs adapter
• Rule B with condition xyz is matched and the trade is despatched to the accounting engine

This is a logical implementation of a problem solution. However, across multiple destination nodes and complex routing rulesets, the overhead added to the RRE is significant. Additionally, this implementation clouds the vital diagnostics that can be gleaned from maintaining statistics around which rules are fired and how often (discussed later).


By far the best way we’ve seen to implement these rules is to incorporate multiple routing options at rule level. This reduces the load on the RRE by separating the decision making from the resulting required actions. Our example routing rule would then look something like this:

• Rule A with condition xyz is matched and the trade is despatched to this list of end points (recs, accounts)

This simple, yet powerful shift in thinking immediately halves the load on the RRE and makes working with the ruleset a much more manageable experience. It also makes testing the ruleset against your regression packs easier.

3. Embrace centralised rules
Most enterprise workflows require complex routing solutions. Actors can enter the flow at multiple points and there are routing decisions required at many waypoints. If you wish to save yourself a world of pain, bring your routing rules into a single, centralised solution. The problem with the label “Routing Rule Engines” is the “s” on the end. Your RRE should be developed and implemented as a central, visible service that is exposed to any waypoints that care to engage with it. Segregate your routing decisions on the rules themselves. For example, waypoint A will only be presented with those routing rules that are relevant to that waypoint. It doesn’t need to worry about segregation as this is inherent in the RRE service itself. Once again, this supports a distrubuted development and test project team and allows them to develop and test independantly. Additionally, the knowledge of what your data flow is, what it does and where it goes, can be seen in a single place.

4. Know your most popular rules
Without a doubt, the most powerful piece of MI that a RRE can produce is the break down of those rules that have been fired. This gives an immediate insight as to what is happening in your stack. Without out it, you need to rely on the core applications to provide this information. This means building out MI functions on numerous applications, in differing timezones, on differing platforms with all the associated expense in terms of both time and money that that would involve. When your MI is harvested at the core app level, the business context is lost. It is not possible to “re-tell” the story.

On numerous projects we have implemented rule firing MI on RRE solutions. Time and time again, it provides an holistic view of the business conversations that are taking place in your domain. It has even been possible to perform rules based data profiling activities and analyse data categories using this method.
The RRE is working hard for you – make the most of it and harvest the most MI you can from it.

5. Modelling tools
Modelling solutions are a particular speciality of ours at Redhound. If there’s a RRE involved in your solution then you’d better start modelling from the very start of your project. It will prove to be the best investment in time and effort you have ever made.

• Want to understand how data is going to flow in your solution? Model it.
• Want to see where your choke points are going to be? Model it.
• Want to be able to work in an agile way, seeing results immediately? Model it.

You can model effectively in the MS toolkit with Excel and Access. This is a great place to start, but to gain the absolute maximum benefit from your model, think about getting it to hook into your evolving solution. Modelling routing rules and then washing your domain data against them with immediate results without having to open up your fledgling adapter framework is a liberating experience. Your model should deliver your tested rules, drive out your adapter framework, your mature static data requirements and your asynchronous framework.
For further information on modelling, see my previous article Business Analyst’s Tools – Data Flow Model

The above will give you some real pointers into the areas that you need to think about when working in enterprise integration and messaging systems. We’ve found them to be project savers time and time again. For a further, in depth chat about routing rules, messaging and integration, just drop us a line. One final thought for you – the only thing more expensive than a good routing rules specialist is a bad one.

()