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).

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.

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			SMTP
Twitter			Twitter API
File			Windows Network Share
			FTP
			Dropbox
			SkyDrive*
			gDrive (Google Drive)*
Fax			MS-Fax
			RightFax (Open Text)
			Faxlogic
SMS Messaging			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.