SQL API (Legacy)

The Windows service has been written to facilitate all the communication
between a locally installed application and our SMS gateway.

📘

Important: API Channel Activation for New Accounts and Sub-Accounts

When you create a new Account or Sub-Account, please be aware that by default, no API channels will be active. To enable API access and manage your Accounts and Sub-Accounts' API credentials and settings, please follow the steps outlined in the "API Keys" page.

Note for Accounts Created Before 6 June 2023: If you have an Account that was created before 6 June 2023, the API channels would have been automatically enabled. However, if you wish to switch to an alternative API or use additional APIs, you will need to create an API Key for the desired API.

Please note: To make use of the SQL API a Webservice API Key needs to be generated.

Overview

The Windows service is a two-part application, consisting of the following parts:

• Windows service (written in Microsoft .Net 2)
• SQL Server database

In order to utilise the service, Microsoft .Net 2 runtime and Microsoft SQL server (MS SQL) must be installed. The service simplifies the transport layer between an application (local environment) and the SMS gateway. The user can simply write data to a QUEUE table and have the service take care of the communication layer. It also caters for all updates of delivery receipts / replies.

The service was written for multi-user accounts. Each user account can have a different properties set that includes:

• Active (if false it won’t send for that specific user)
• Start and End hour (only send between the following hours)
• Poll interval on the Queue (the more aggressive the more the machine will work)
• Interval to fetch receipts and replies (the more aggressive the more bandwidth is consumed)

The service allows the following when sending:

• Queue messages into the future
• Assign priority to each message (the higher the priority the faster the service will process it)
• Send SMS messages only

Architecture

The Windows service was designed using a multi-threaded object orientated architecture, to simplify any future additions and to allow clients to customise the service to their specific requirements.

The threads work seamlessly together to create a non-blocking environment, to improve performance and message throughput. However, the throughput is ultimately determined by the speed of the Internet connection being utilised.

Configuration

The config file accompanying the service caters for specific database and network connection settings. This includes the connection string to the database (which can be on a different server) and the connection settings for your Internet connection. This is only relevant if a firewall / proxy server is being utilised in your environment.

All settings are controlled via the database and sending of data can be paused for a user mid-stream. The paused messages can then be removed from the queue or delayed for a future date.