ЕСОЗ - публічна документація

Skip to end of metadata
Go to start of metadata

You are viewing an old version of this page. View the current version.

Compare with Current View Page History

« Previous Version 5 Next »

Purpose

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

<message>
<service id="
single" start="время начала" validity="период  source="исходящий номер"/>
<to ext_id=«опциональный ид. сообщения»>номер получателя</to>

<body content-type="тип содержимогоencoding="кодировка"
тело
</body>

</message>

The response is received:

Single SMS response

<status id="ид сообщения" date="дата и время" ext_id=”опциональный ид. сообщения если был передан”>

<state error="сообщение об ошибке">статус</state> </status>


To receive additionally info about SMS status next request must be sent:

Single SMS status request

<request id="ид сообщения">status<request>

And response will be next:


Single SMS status response

<status id="ид сообщения" date="Wed, 28 Mar 2007 12:35:00 +0300">

<state>Delivered</state>
</status>

Next values are available for statuses:


SMS StatusDescription
AcceptedSMS was accepted by IP2SMS platform, but without attempt to deliver it yet
EnrouteSMS still in the delivery process
DeliveredSMS was successfully delivered
ExpiredTime limit was richer and there won't be attempt to deliver SMS
DeletedSMS was deleted from system by admin
UndeliverableSMS can't be delivered
RejectedSMS was rejected because had some errors
UnknownSMS 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

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 nameDescription 
id
phone_number
type('verification', 'medication_request)
body SMS text 
gateway_idstatus_id from response
gateway_statusSMS Status (see the table above)
status_changed_atdate from status response 
updated_atTIMESTAMP
inserted_atTIMESTAMP

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).




  • No labels