Routing strategies and benefits

You can route outgoing messages by creating routing rules. These routing rules then apply to any message that’s not sent on a specific channel.

Routing is a way to select which channel a message should send on. Find out more about the place of routing in the introduction of the message bus architecture.

If you’re sending through either the local, database or HTTP API you can leave the channel ID empty to have the router assign a channel. If you’re testing from the Auron SMS Server manager set the channel to ‘<< Any Channel >>’ to have the routing rules apply.

You can find a description of how to add routing rules here. On this page we’ll discuss:

• Basics and benefits of routing;
• Basic routing rules with examples;
• Proportional routing rules with examples;
• Congestion based routing rules with examples.

Basics and benefits of routing

Routing rules consist of these parts:

• Message Type. The rule applies to all messages of this type;
• Target channel. This is the channel the message should send on if the rule matches;
• Condition. This is a SQL expression that should match the message.

The first rule that matches is applied. If a message is not sent on a specific channel and doesn’t match any routing rule, it’s send round-robin over any channel that matches the message type.

There are a couple of reasons why you may want to setup routing rules. The most common are:

• Optimize for cost. You can optimize for cost by having routing rules that select a provider based on destination;
• Optimize for performance. You can optimize for performance by routing to channels either proportionally or based on congestion;
• Select a channel based on type of message. You may want to route WhatsApp messages to a different provider than SMS messages.

The following sections address some common ways to create routing rules.

Basic routing rules

Basic routing rules either optimize for cost or are based on the type of message.

For instance; Send all messages that start with +31 or +32 to a Dutch based operator (HTTPDUTCH) and all messages that start with +1 to a US based one (SMPPUS):

ToAddress LIKE '+31%' OR ToAddress LIKE '+32%'

ToAddress LIKE '+1%'

Messages that fall through are sent round-robin over any channel that matches them.

Or send e-mail messages that have a subject starting with ‘Alert’ from your alerting e-mail address (SMTPALERT) and send other e-mail messages over your customer support e-mail address (SMTPSUPPORT).

Subject LIKE 'Alert%'

1=1

The simple condition 1=1 is always true. This way no outgoing e-mail is going to be sent round-robin which gives us full control over how e-mails are sent.

Proportional routing

There are couple of cases when proportional routing is useful. The following sections provide examples.

Exclude a channel from automatic routing

Say for instance you have 4 SMS channels called: SMPP1, SMPP2, SMPP3 and SMPP4. Only channels 1, 2 and 3 should be routed to automatically. Channel 4 is always enabled for manual sending and testing, but the router should not use it.

You would define the following routing rules:

dbo.fnRouteProportional(RAND(ID), 3) = 0

dbo.fnRouteProportional(RAND(ID), 3) = 1

dbo.fnRouteProportional(RAND(ID), 3) = 2

The conditions may look a little intimidating but the important part is at the end of the condition.

With ‘fnRouteProportional’ we create a ‘randomized’ version of the ID of the message which is divided by 3 and take the remainder.

Since we’re taking the remainder of a division by 3 the result can only be 0, 1 or 2. So by creating a routing rule for each of these cases no SMS message can fall through. This means that no SMS ever routes to SMPP4 while SMPP1, SMPP2 and SMPP3 are equally addressed.

Route 75% to one channel and 25% to another

You can use the same way of routing to distribute messages unevenly. Say that you’d want 75% of the message go over channel SMPP1, have 25% go over SMPP2 and leave the other channels unused by the router:

dbo.fnRouteProportional(RAND(ID), 4) IN (0, 1, 2)

dbo.fnRouteProportional(RAND(ID), 4) = 3

The expression is the same as in the previous example. Only the end of the expression changes. We’re using ‘4’ to divide all traffic up into 4 equal parts. Parts 1, 2 and 3 are sent to channel SMPP1 and part 4 is sent to SMPP2.

Details about this condition

Calling: fnRouteProportional(RAND(ID), 4) translates to the following expression: (CONVERT(INT, RAND(ID)*10E8) % 10000) % 4.

The expression ‘(CONVERT(INT, RAND(ID)*10E8) % 10000)’ is important because it uses the value of the ID field from the message table. Just using ‘ID % 3 = 0’ causes problems since there’s a pattern in the ID field. Just using ‘RAND() * 1000 % 3 = 0’ causes a problem because now the number is different for every routing rule and messages may still fall through. A tricky problem about plainly using RAND(ID) * 1000 is that using the ID field that always increases by small intervals, creates random numbers that are too similar on the left side (larger side) of the number. We get around this by increasing the number by a large factor and then taking the ‘small’ part of it by taking the remainder of a division by 10000.

The ‘CONVERT’ part of the statement converts the return from RAND(ID)*10E8 to an integer. We need this since RAND produces a real number and the modulo operator requires an integer number.

Congestion based routing

With congestion based routing we can setup a preference for one channel and send the overflow to another channel.

Say that we always want to use channel HTTP1 since that channel is cheaper to send. But if we’re flooded with messages we don’t mind using SMPP1 to be able to stay responsive to our users.

You can setup the routing rules like this:

dbo.fnNumQueued('HTTP1') < 80

1=1

The route for HTTP1 matches any message as long as there are no more than 80 messages already in its send queue.

The route for SMPP1 always evaluates to true so all messages that don’t go to HTTP1 go to SMPP1.