SMS Server SMTP based interface for application developers and ISV integration

Email based approach to application integration

BNS Enterprise SMS Server is Windows server VM running in your datacentre or your private cloud.

Using internal email allows any application programmer to send an SMS with minimal effort.

Benefits of using internal email together with the platform include:

• Avoids any future re-programming should the underlying SMS provider change
• Avoids using proprietary REST APIs unique to a single SMS provider 
• Allows high availability message routing within the enterprise messaging backbone (eg: multiple exchange transport servers)
• Allows production to DR failover of SMS traffic
• Allows multiple SMS providers to be supported for high availability at the SMS provider level 
• Primary and backup SMS providers are switched automatically without any application changes
• Industry standard SMPP implementation at the SMS server supports many SMS service providers allowing best possible contract rates to be negotiated
• Allow distributed applications to use internal email as a store and forward system
• SMS Server provides built-in safety guards.  For example it will check for duplicate messages to the same mobile over a 24 hour period.  This is configurable

The maximum size of an SMS request via SMTP is determined by which SMS Service provider(s) are used with the deployment. Contact your system administrator to determine what is the maximum you can send from your application to be within the SMS Service provider limit. 

Internal email such as Microsoft Exchange server directs specific address space eg:   @Brand1.sms   @Brand2.sms to one or more SMS servers. 

Exchange administrators route the SMS traffic to specific SMS servers to control the flow of messaging. 

Applications have to be registered within the SMS server.   Applications are registered based upon a sender e-mail address.

A business application can use the Email subject or the email body to create the SMS message.  The default for a business application is using the subject.   If an application can only use the message body of an email the administrator must add a keyword into any of the Custom fields of the application profile. 

Keywords:

• bnsmemo means that the SMS server will use the email body part from that application and select the configured number of characters for the SMS message. 
• bnsmemorp means that the SMS server will use the email body part from that application and remove excess spaces in the message then select the configured number of characters for the SMS message.   

Example using Outlook. 

The example below shows how you application could send an SMS using the subject and also inject custom fields. 

Custom fields what are they?  

Custom fields are values which are written to the SQL database for that transaction.   Examples include:  Campaign reference, Customer account number,  invoice number etc.  Any reference data which is meaningful to your organisation.  

In the example above, the application creates a simple e-mail, the subject of which is the SMS message to be transmitted. The recipient mobile number should be in the full international format plus any key words in the message body.

The SMS platform can be configured to auto replace prefixes such as 04 with 614 so that Outlook users can supply a mobile number in the form 0412869531@Brand1.sms because msXsms will parse the number based upon a rule set to present the correct international number.  However, applications should be responsible for presenting the full international number eg: 61412001002.

If an application is a proxy for another logical application or business unit a keyword [FromEmail=BusinessApplicationEmailAddress] would be supplied in the message body to identify to msXsms which business application table controls to use. More on that later. 

SMTP/MIME parameters

There are 3 important parameters to supply when sending an SMS message using SMTP/MIME.

• Sender Email Address
• Recipient To: email address
• Recipient Display Name (contained in the MIME message)

Applications which set the Recipient Display Name can also make use of the intelligent caching of msXsms. 

Recipient Display Name in msXsms is limited to 100 characters.

System architects can leverage the Recipient Display Name to contain any information about the recipient of the SMS such as: customer account number, Campaign ID etc. 

If 2 way dialog with SMS recipients is required, it is highly recommended that the tools used by your development team can supply the Recipient Display Name when constructing the SMTP/MIME message.

To best illustrate this, the example below uses Outlook as an application which does this.

If your application can supply the Recipient Display Name then any message replies from your SMS recipients will provide meaningful information to users of those applications.

This example shows how a Recipient Display Name could contain customer account information so that a reply (inbound SMS) is then presented as that sender of the SMS. 

By way of example only, refer to the Outlook contact screen below to see the recipient display name (Display as) in that context.  

Notice how a reply SMS  sender display name contains Customer number AU1234567, followed by the Customer’s name plus other information.

Default values established for each application sender email address

Administrators register details of all business applications in SQL via a configuration program called the Web Console.

The configuration program allows default values to be established some of which can be overridden by the application on a per message basis.

Firstly, lets understand what the administrator of the system can setup for your application.

Example shows:

1. your application's email address app1@yourdomain.
2. Company name for reporting
3. Sender SMS ID.  Example here is an approved alpha value 'BNSGroup'.   Alpha is one way SMS. 
4. Cost centre for reporting and billing
5. Send confirmations back to your application for failed SMS. 
6. Not to send confirmations back to  your application for successful SMS. 
7. No custom field defaults or commands (so your application will use the subject of the SMTP message you create for the SMS message).