| Table of Contents |
|---|
...
We need to understand how stable, reliable and what is the performance of SMS channel processes. In order to be able to do that there are must be predefined metrics related to SMS process and we need to store counters and log data.
Logic
As for now there are 2 types of SMS - for verifications and for receiving info related to reimbursement.
We use IP2SMS to send SMS:
| Info | ||
|---|---|---|
| ||
<message> <body content-type="тип содержимого" encoding="кодировка" </message> |
The response is received:
| Info | ||
|---|---|---|
| ||
<status id="ид сообщения" date="дата и время" ext_id=”опциональный ид. сообщения если был передан”> <state error="сообщение об ошибке">статус</state> </status> |
To receive additionally info about SMS status next request must be sent:
| Info | ||
|---|---|---|
| ||
| <request id="ид сообщения">status<request> |
And response will be next:
| Info | ||
|---|---|---|
| ||
<status id="ид сообщения" date="Wed, 28 Mar 2007 12:35:00 +0300"> <state>Delivered</state> |
Next values are available for statuses:
| SMS Status | Description |
|---|---|
| Accepted | SMS was accepted by IP2SMS platform, but without attempt to deliver it yet |
| Enroute | SMS still in the delivery process |
| Delivered | SMS was successfully delivered |
| Expired | Time limit was richer and there won't be attempt to deliver SMS |
| Deleted | SMS was deleted from system by admin |
| Undeliverable | SMS can't be delivered |
| Rejected | SMS was rejected because had some errors |
| Unknown | SMS status is unknown |
| Unaccepted | SMS can't be accepted |
Terminated | SMS was processed (got one of the statuses: accepted, enroute, unknown, pending), but not delivered due to timeout |
Pending | SMS in progress of delivery |
All data must be stored in the table verification.sms_log which has next fields and updated according to the job (sms statuses update)
| Field name | Description |
|---|---|
| id | |
| phone_number | |
| type | ('verification', 'medication_request) |
| body | SMS text |
| gateway_id | status_id from response |
| gateway_status | SMS Status (see the table above) |
| status_changed_at | date from status response |
| updated_at | TIMESTAMP |
| inserted_at | TIMESTAMP |
As soon as there is a new verification SMS in verification.verifications table it's also must be replicated to verification.sms_log, though only one time (in table verification.verifications there are also field attempts count which must be ignored).