| 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:
Single SMS request
...
|
To receive additionally info about SMS status next request must be sent:
Single SMS status request
|
And response will be next:
Single SMS status response
|
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, 'text', '2FA') |
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).