How does Boomerang Work | Boomerang Notification Services for SQL

How does Boomerang Work?

Architecture – Introduction

SQL Server

Boomerang is a bolt-on solution for MS-SQL Server. The application interface of Boomerang is entirely based on SQL Server (MS) meaning that each notification service has a corresponding table object that represents the service in question. For example to send and email out you would insert a record into the OUT_EMAIL table. To send a fax you would insert a record into the OUT_FAX table.

You will communicate with Boomerang in exactly the same way whether is it with ASP.Net application, bar-code device running a Mobile OS, or TomCat application connecting over Ruby on Rails.

Notification Services

A set of heavy-duty background Windows services is connected to the Boomerang database. Each service is multi-threaded and caters to a specific kind of output like emailing, faxing and twittering. Services work independently from each other, although one Boomerang task (Event) may comprise of several kinds of output (Jobs).

Boomerang Notification Services | Architecture Overview

Notification Framework Objects

As mentioned above the application interface of Boomerang is entirely based on SQL Server (MS) meaning that each notification service has a corresponding table object that represents the service in question. These database objects can be categorized into Outbound Notifications and Inbound Notifications.

Outbound Notifications

Event

You can think of Event as an application task. The  Event is represented by a single record in the EVENT_MASTER table. These Event records do not carry delivery data, however they may carry application specific keys used to tie events to sources which generated them. Examples of such keys may include a help desk id, an application source id, a customer order number, a client lead unique identifier.

Job

Each event comprises one or more jobs. A job represents what is being delivery, such as e-mail, fax or print. Each job declares delivery data of its own kind. For example, a print job will define at the minimum an applicable printer path. A e-mail job will contain data like e-mail subject, body and urgency. Some type of jobs may extend data to one or more auxiliary tables. For example e-mail jobs list e-mail recipients in a separate table called OUT_EMAIL_RECIPIENT.

Feature Table Description Event Handler
Email Out OUT_EMAIL Main table for the e-mail out service. Records inserted into this table will be emailed out. sp_After_Email_Job
OUT_EMAIL_RECIPIENT This table contains destination e-mail address/name
Fax Out OUT_FAX Main table for the fax out service. Records inserted into this table will be faxed out. Available fax connectors: MS-Fax, RightFax and FaxLogic sp_After_Fax_Job, sp_On_Fax_Status
File Out OUT_FILE Main table for the file out service. Records inserted into this table will be saved to a network share, ftp, Dropbox, SkyDrive or gDrive location. sp_After_File_Job
Print Out OUT_PRINT This table is the main table for the print out service. Records inserted into this table will be printed to a network printer. sp_After_Print_Job
Twitter Out OUT_TWIT This table is the main table for the Twitter out service. Records inserted into this table will be posted to the Twitter account associated with Boomerang. sp_After_Twit_Job
SMS Out OUT_SMS This table is the main table for the SMS out service. Records inserted will be sent to referenced cell phone number. Available SMS connectors: Twilio sp_After_Sms_Job, sp_On_Sms_Status

Event Content

Many jobs will have content or attachments for which a common storage table is designed and called EVENT_CONTENT. For example, a fax job may be set to deliver a MS SQL Reporting Services report in addition to a fax cover sheet. In this case the event content table would reference the URL path to the where a RDL report (SSRS) has been deployed.

Event Status

Each job maintains its own status and repetition schedule in a table called EVENT_STATUS. Such schedule defines whether or not a job should fire immediately or wait a certain time delay. Also it defines whether or not the job should be retried or not in the case of failure and if so, then also the number of times and interval. Default values  for number of retries and intervals are managed from the Boomerang Management Console.

Event Log

As jobs are processed an event log is being generated regardless of the completion outcome. Some jobs establish a feedback mechanism with target device. For instance, the fax service will alternate job status based on notifications it receives from MS Fax Server. The e-mail service will “listen” to the delivery reports from SMTP relay agent and will log them in association with the original e-mail job.

Boomerang Notification Services | Framework Objects

Illustration shows how the above described Boomerang framework objects fit together.

Event Handlers

After completion of the notification process event handlers like After Email Job (sp_After_Email_Job) are automatically called. These event handlers can used to continue processing the notification event and/or start a new outbound notification.

Inbound Notifications

Inbound or incoming notifications does not by it self require any application since it is an integrated part of the Boomerang Notification Services. Inbound notifications are instead configured (once) in the Boomerang Management Console.

As with all notification services in Boomerang, inbound notifications are managed in SQL as tables and stored procedure objects.

Feature Table Description Event Handler
Email In IN_EMAIL Main table from incoming emails. Contains Subject, Body, From etc. sp_On_Email_In
IN_EMAIL_CONTENT Contains all attachments for each received email.
IN_EMAIL_HEADER Email header information
IN_EMAIL_RECIPIENT All recipients for each received email.
File In IN_FILE File name and file as varbinary sp_On_File_In
Twitter In (Twitter Message Stream) IN_TWIT Main table for incoming Twitter messages. Contains Twitter Id and Twitter message. sp_On_Twit_In
IN_TWIT_HEADER Contains Twitter header information such as Language, Geo location, Name, Description
SMS In IN_SMS Main table for incoming SMS messages. Contains to and from phone number, message details. sp_On_Sms_In

Tracking

The Email In and SMS In notification services also contains a feature for tracking. If the inbound e-mail or text message was originally sent by Boomerang (as an Email Out or SMS Out notification) the inbound notification will be tagged with the original outbound identifier i.e. job key.

This is a helpful feature when you need to manage threaded conversations e.g. a help desk scenario with multiple answers and replies pertaining to same issue.

Communication Connectors

To support outbound and inbound notifications a number of communication connectors are available in Boomerang. These connector are configured (once) and managed from Boomerang Management Console

The following communication connectors are included in the Boomerang Notification Framework for inbound and outbound notifications.

Feature Outbound Inbound Connector
Email Boomerang Notification Services for SQL Server Boomerang Notification Services for SQL Server SMTP
Twitter Boomerang Notification Services for SQL Server Boomerang Notification Services for SQL Server Twitter API
File Boomerang Notification Services for SQL Server Boomerang Notification Services for SQL Server Windows Network Share
Boomerang Notification Services for SQL Server FTP
Boomerang Notification Services for SQL Server Dropbox
Boomerang Notification Services for SQL Server SkyDrive*
Boomerang Notification Services for SQL Server gDrive (Google Drive)*
 Fax Boomerang Notification Services for SQL Server MS-Fax
Boomerang Notification Services for SQL Server RightFax (Open Text)
Boomerang Notification Services for SQL Server Faxlogic
SMS Messaging Boomerang Notification Services for SQL Server Boomerang Notification Services for SQL Server Twilio

Administration

Boomerang Management Console

Boomerang Notification Framework ship with a Microsoft Management Console snap-in. You can use the administration console to configure important service parameters, as well as Boomerang database. You may also manage Boomerang printers and all communication connectors.

Boomerang Notification Services Web Portal

Boomerang Notification Services Web Portal (BNSWP) ships separately to Boomerang Notification Framework and is not needed for any functionality in Boomerang. BNSWP is an open source web based front end that is used for easy management of deployed notification solutions.