How does Boomerang Work?
Architecture – Introduction
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.
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.
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.
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.
|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|
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.
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.
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.
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 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.
|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|
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.
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.
|File||Windows Network Share|
|gDrive (Google Drive)*|
|RightFax (Open Text)|
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.