Message bus architecture

The core of the Auron SMS Server is its message bus. To get the most out of the Auron SMS Server it helps to understand the basics of the message bus.

The message bus is further optimized for maximum responsiveness by the notification broker. Find message states and state transitions in more detail here.

This is a schematic representation of the message bus:

As you can see there are 3 main parts to it. The following sections describe them.

The channels

The channels are communication channels to the outside world. They can either send or receive or do both. Channels operate in their own context. This means that each instance of a channel lives in its own process and, while managed by the Auron SMS Server, they function independently. This has a number of advantages:

• Channels operate asynchronously. This is an important benefit to performance;
• Channels are extremely reliable. A problem with one channel doesn’t affect the rest of the system;
• Add or remove channels dynamically. Stopping or starting channels does not affect the operation of the rest of the Auron SMS Server;

Channels are instances of a channel type, e.g. an SMPP channel to connect to an SMPP provider or a GSM channel to connect to a GSM device. You can create multiple instances of the same channel type. In the schematic it shows 3 different channels for 3 different message types. However, it’s possible to have as many channels as required and have multiple channels for the same message type.

Find out more on how to configure channels here.

Router and Queue

The message queue is where messages are received, processed and sent from. In this case it’s a table in the server database. Having the message queue be a table in the database has a some practical advantages:

• Accessibility. It’s easy to inspect, read to or write from the queue directly from your integration;
• Concurrency. The database handles concurrency in a uniform and well defined way;
• Scalability. You can use database tools to scale up performance and reliability in a transparent way. By using a cloud based or clustered database for instance;

To ensure consistent performance you can archive to keep the message queue small. However, performance should remain consistent for up to several hundreds of thousands or even millions of records, depending on your database server.

If an outgoing message doesn’t specify a channel the router will choose one. This is done by applying predefined routing rules and blocking rules. These are very easy to setup since routing and blocking conditions can be simple SQL expressions.

You can add messages directly to the queue to send them automatically. Find out more about this here. Find out more about message states and state transitions here.

Triggers

Triggers are actions to perform when a message reaches a predefined state. A trigger has two properties:

• The trigger condition. This SQL expression determines if a trigger should run;
• The trigger script. This script runs when a message matches the trigger condition;

Trigger scripts can be either VBScript, Javascript or SQL script. This depends on what you’re most comfortable with.

Trigger scripts are allowed to:

• Create new messages;
• Change existing message properties;
• Run applications;
• Connect to external databases;
• Make HTTP(S) API calls;
• Make use of COM objects;
• Read, modify or create Excel or any other data files;
• And much more;

You have full freedom to do anything in a trigger script. You can use this API to manipulate messages in the Auron SMS server from your trigger. A trigger script has these properties:

• Multiple triggers run in order, synchronously;
• Global variables are kept between handling messages. The trigger only reloads on a change or when restarting the service.
• With overlapping conditions you can chain triggers together;
• By setting a message status to ‘Processed’ you can prevent subsequent triggers from executing on that message.

Find out more on how to configure triggers here.