Descripción del conector SMPP smpp-connector-desc
Flujo de datos del conector SMS sms-data-flow
En esta sección se describe cómo gestiona los datos el proceso SMS.
Este es un diagrama de bloque de alto nivel que resume cómo el proceso SMS interactúa con su entorno.
El proceso SMS aloja 2 componentes importantes: el propio conector SMPP que gestiona la comunicación con el proveedor SMPP y una tarea en segundo plano para la reconciliación SR.
Flujo de datos para cuentas SMPP sms-data-flow-smpp-accounts
El proceso del SMS sondea nms:extAccount y genera nuevas conexiones en su conector SMPP, pasando la configuración de cada cuenta. La frecuencia de sondeo se puede ajustar en serverConf, en la configuración configRefreshMillis.
Para cada cuenta SMPP activa, el conector SMPP intenta mantener las conexiones activas todo el tiempo. Se vuelve a conectar si se pierde la conexión.
Flujo de datos al enviar mensajes sms-data-flow-sending-msg
-
El proceso de SMS selecciona los envíos activos analizando nms:delivery. Una entrega está activo cuando:
- Su estado implica que se pueden enviar mensajes
- Su periodo de validez no ha caducado
- En realidad es una entrega (por ejemplo, no es una plantilla, no se elimina)
- El conector SMPP podría abrir al menos una conexión para la cuenta externa vinculada al envío
-
Para cada entrega, el proceso SMS carga las partes de la entrega. Si la parte del envío se envió parcialmente, el proceso de SMS comprueba qué mensajes ya se enviaron comprobando el registro general.
-
El proceso de SMS expande la plantilla con datos de personalización de la parte del envío.
-
El conector SMPP genera una MT (SUBMIT_SM PDU) que coincide con el contenido y otras configuraciones.
-
El conector SMPP envía la MT a través de una conexión de transmisor (o transceptor).
-
El proveedor devuelve un ID para este MT. Se inserta en nms:providerMsgId.
-
El proceso del SMS actualiza el registro general al estado enviado.
-
En caso de error final, el proceso de SMS actualiza el registro general en consecuencia y puede crear un nuevo tipo de error en nms:broadLogMsg.
Flujo de datos al recibir SR sms-data-flow-sr
- El conector SMPP recibe y descodifica el SR (PDU DELIVER_SM). Utiliza expresiones regulares definidas en la cuenta externa para obtener el ID y el estado del mensaje.
- El ID de mensaje y el estado se insertan en nms:providerMsgStatus
- Después de insertarse, el conector SMPP responde con una PDU DELIVER_SM_RESP.
- Si algo salió mal durante el proceso, el conector SMPP envía una PDU DELIVER_SM_RESP negativa y registra un mensaje.
Flujo de datos mientras se recibe un MO sms-data-flow-mo
- El conector SMPP recibe y descodifica el MO (PDU DELIVER_SM).
- La palabra clave se extrae del mensaje. Si coincide con cualquier palabra clave declarada, se ejecutan las acciones correspondientes. Puede escribir en nms:address para actualizar la cuarentena.
- Si se declaran los TLV personalizados, se descodifican según su configuración respectiva.
- El MO completamente descodificado y procesado se inserta en la tabla nms:inSms.
- El conector SMPP responde con una PDU DELIVER_SM_RESP. Si se detecta algún error, se devuelve un código de error al proveedor.
Flujo de datos mientras se reconcilian MT y SR sms-reconciling-mt-sr
- El componente de reconciliación SR lee periódicamente nms:providerMsgId y nms:providerMsgStatus. Los datos de ambas tablas se unen.
- Para todos los mensajes que tienen una entrada en ambas tablas, se actualiza la entrada correspondiente nms:broadLog.
- La tabla nms:broadLogMsg se puede actualizar en el proceso si se detecta un nuevo tipo de error o para actualizar los contadores de errores que no se hayan clasificado manualmente.
Entradas de MT, SR y “broadlog” que coinciden sms-matching-entries
Este es un diagrama que describe todo el proceso:
Fase 1
- El mensaje se analiza, se formatea y se transmite al conector SMPP.
- El conector SMPP lo formatea como una SUBMIT_SM MT PDU.
- El MT se envía al proveedor del SMPP.
- El proveedor responde con SUBMIT_SM_RESP. SUBMIT_SM y SUBMIT_SM_RESP coinciden con su número de secuencia.
- SUBMIT_SM_RESP proporciona un ID proveniente del proveedor. Este identificador se inserta junto con el identificador de registro general en la tabla nms:providerMsgId.
Fase 2
- El proveedor envía una PDU SR DELIVER_SM.
- El SR se analiza para extraer el ID del proveedor, el estado y el código de error. Este paso utiliza expresiones regulares de extracción.
- El identificador del proveedor y su estado correspondiente se insertan en nms:providerMsgStatus.
- Cuando todos los datos se insertan de forma segura en la base de datos, el conector SMPP responde con DELIVER_SM_RESP. DELIVER_SM y DELIVER_SM_RESP coinciden con su número de secuencia.
Fase 3
- El componente de reconciliación SR del proceso de SMS analiza las tablas nms:providerMsgId y nms:providerMsgStatus periódicamente.
- Si alguna fila tiene ID de proveedor coincidentes en ambas tablas, las dos entradas se unen. Esto permite hacer coincidir el ID de registro general (almacenado en providerMsgId) con el estado (almacenado en providerMsgStatus)
- El registro general se actualiza con el estado correspondiente.
Afinidades y el conector de proceso dedicado sms-affinities
El conector de proceso dedicado ignora las afinidades, solo se ejecuta dentro del proceso SMS.
opciones de serverConf sms-serverconf-options
Algunos ajustes se pueden ajustar en serverConf.xml. Al igual que cualquier otra configuración de este archivo, debe especificarse en el archivo config-instance.xml. Todos los ajustes se encuentran en el elemento < mta2 >.
Esta tabla resume todas las configuraciones. Los valores sensatos mín./máx. dan una idea aproximada del rango que se debe tener en cuenta en la mayoría de los casos. El valor de depuración es el valor que se debe elegir al intentar encontrar problemas que no están relacionados con el rendimiento.