Contrato de datos operativos A2P SMS: campos y semántica

Qué resuelve un contrato de datos operativos

En tráfico A2P SMS —mensajes enviados desde una aplicación o sistema hacia una persona— varias organizaciones pueden registrar el mismo mensaje en momentos distintos y con vocabularios diferentes. Un contrato de datos operativo reduce las ambigüedades al especificar qué significa cada campo, quién lo informa y cómo se relacionan los eventos.

No es una norma universal ni garantiza entrega. Es un acuerdo entre las partes para intercambiar y conciliar información. Debe distinguir las decisiones propias del acuerdo de los requisitos de una interfaz o especificación técnica aplicable. Las referencias normativas, como SMPP o HTTP, se deben consultar directamente antes de atribuirles requisitos concretos.

• Acordar el esquema antes de integrar o modificar el intercambio de datos.
• Documentar definiciones, formatos, vocabularios y responsabilidades junto a los campos.
• Tratar la interpretación de estados como un acuerdo explícito, no como una equivalencia asumida entre sistemas.

Actores y límites de responsabilidad

Una cadena puede incluir a la empresa que origina el tráfico, una plataforma de mensajería, uno o varios proveedores y un operador móvil. La ruta concreta y la participación de cada entidad dependen del acuerdo y de la configuración del servicio; no conviene presuponer una cadena idéntica en todos los casos.

Para cada dato, indiquen quién lo genera, quién lo transmite, quién puede transformarlo y quién responde de su interpretación. Por ejemplo, el emisor puede declarar el tipo de tráfico; una plataforma puede asignar un identificador interno; y un proveedor puede comunicar un estado recibido de otro sistema. Estas son posibles asignaciones de diseño, no responsabilidades universales.

Separar responsabilidades ayuda a investigar discrepancias: una parte puede confirmar que aceptó una solicitud sin afirmar que la red la entregó, mientras otra puede informar un resultado posterior con el alcance que permita su fuente.

• Asigne un propietario a cada campo y a cada transición de estado.
• Declare dónde termina la responsabilidad informativa de cada parte.
• Incluya un contacto y un procedimiento de conciliación para discrepancias, sin asumir que todas las partes observan los mismos eventos.

Campos mínimos y significado

El conjunto mínimo depende del objetivo: operación, soporte, conciliación o análisis. Conviene empezar por los datos necesarios para correlacionar una solicitud con sus eventos posteriores, y añadir solo los campos que las partes puedan producir y usar de forma definida.

Documente como mínimo un identificador de mensaje por sistema y, cuando corresponda, los identificadores de correlación entre sistemas. Incluya el destino con su formato acordado; el remitente; la clasificación declarada del tráfico, por ejemplo OTP, transaccional o marketing; y la ruta declarada si se conoce. No presente una ruta declarada como prueba independiente de la ruta efectivamente recorrida.

También conviene incluir el estado, el origen del estado, la marca temporal del evento y el código de error cuando exista. Si se comparte operador de destino, indiquen cómo se obtuvo y cuándo se determinó. Un campo de operador desconocido no debe rellenarse por inferencia. Definan además la versión de las condiciones o del acuerdo operativo aplicable, con su identificador y fecha o vigencia acordada.

• Identificadores: identificador del mensaje en el sistema emisor y referencias de correlación disponibles.
• Contexto: destino, remitente, clasificación de tráfico, ruta declarada y operador cuando se conozca.
• Evento: estado, origen del estado, fecha y hora, código de error y versión de condiciones.
• Por cada campo, especifique tipo, formato, obligatoriedad, vocabulario y significado.

Estados: aceptación, envío, DLR y resultado desconocido

No reduzca todo el ciclo a un único campo genérico de “estado”. Defina las etapas que el acuerdo necesita distinguir: por ejemplo, solicitud aceptada por una interfaz, intento de envío informado por una parte, informe de entrega recibido o resultado todavía desconocido. Los nombres exactos y las transiciones se deben acordar para cada integración.

Un DLR es un informe de estado recibido desde una fuente determinada. Registre quién lo emitió o transmitió y qué significa en ese contexto. No lo trate, por sí solo, como verificación independiente de que el mensaje apareció en el terminal o fue leído por la persona.

Mantenga un estado desconocido cuando no haya información suficiente para concluir. No convierta automáticamente la ausencia de un DLR en fallo, ni un estado favorable reportado en una garantía de recepción. Si dos fuentes discrepan, conserve ambos eventos y documente cuál utiliza cada proceso y por qué.

• Defina cada estado mediante una descripción, su emisor y las transiciones permitidas.
• Separe el estado reportado de la evaluación interna que una parte haga del caso.
• Conserve los eventos originales para poder reconstruir la secuencia y resolver discrepancias.

Marcas temporales y orden de eventos

Una marca temporal debe permitir entender cuándo ocurrió o se registró el evento y en qué zona horaria. Acuerden el formato, la precisión disponible y si la fecha representa el momento del evento, el momento de recepción del informe o el momento de registro en el sistema.

No deduzca el orden únicamente de la hora de llegada a una plataforma: los eventos pueden recibirse en un orden distinto del que cada parte les atribuye. Mantenga identificadores de evento o secuencias si están disponibles y registre por separado las marcas de origen y recepción cuando sea necesario para la conciliación.

Si una fuente no proporciona zona horaria o precisión suficiente, declárelo. No complete esos datos como si fueran observados.

• Acordar formato de fecha y hora, zona horaria y precisión.
• Distinguir hora del evento, hora de recepción y hora de procesamiento.
• Definir cómo ordenar eventos cuando las marcas temporales coincidan o sean incompletas.

Origen del dato y nivel de evidencia

El mismo valor puede tener distinto peso según quién lo haya declarado y cómo se haya obtenido. Añada metadatos de procedencia cuando ayuden a interpretar el registro: sistema de origen, parte que lo transmite, momento de observación y si se trata de un dato declarado, un evento recibido o una observación independiente.

Por ejemplo, una ruta puede ser declarada por una plataforma, mientras un estado puede llegar en un informe de un proveedor. El contrato debe evitar que la transformación o agregación elimine esa distinción. Si no existe verificación independiente, indíquelo en lugar de insinuarla.

Establezca también qué evidencia se acepta para cada uso: soporte, conciliación o análisis. El valor que sirve para investigar no necesariamente basta para resolver una disputa comercial.

• Marque la procedencia del dato y la parte que lo comunicó.
• Distinga observación directa, declaración y evento recibido.
• No convierta un estado transmitido en una afirmación más fuerte que la fuente disponible.

Nulos, vocabularios y códigos de error

Un campo vacío puede significar que el valor se desconoce, no se recogió, no aplica o no se recibió. El contrato debe distinguir esos casos en vez de dejar que cada sistema los interprete a su manera. Si el formato de intercambio no permite representar esas diferencias, documenten una convención común y sus límites.

Definan vocabularios controlados para categorías y estados, y acuerden cómo tratar valores específicos de un proveedor. Conserven el código original junto con una categoría normalizada si se necesita comparar datos entre partes. La normalización no debería borrar el valor que permite investigar el evento en su fuente.

Antes de añadir códigos, estados o remitentes a una lista acordada, indiquen quién puede proponerlos, cómo se documentan y desde cuándo se aplican. No reutilicen un valor antiguo con un significado nuevo.

• Diferenciar explícitamente desconocido, ausente, no aplicable y no recibido.
• Mantener el valor original y, cuando se acuerde, añadir un valor normalizado.
• Publicar definiciones y ejemplos para los códigos propietarios, sin presentarlos como universales.

Versionado y cambios del esquema

Cada intercambio debería permitir identificar qué versión del esquema y qué versión de las condiciones operativas se aplicaron. Acuerden cómo se comunica esa versión y cómo se relaciona con el periodo del tráfico, en vez de asumir que un nombre de interfaz basta para identificar las reglas.

Definan de antemano un proceso de cambio: quién propone modificaciones, quién las aprueba, cómo se prueban y cuándo entran en vigor. Un cambio que añade un campo opcional puede ser más sencillo de adoptar que uno que cambia el significado de un estado o vuelve obligatorio un dato; clasifiquen el impacto con los consumidores reales.

Durante una transición, indiquen qué versiones pueden coexistir, cómo se identifican los registros y cuánto tiempo se conserva la compatibilidad si las partes acuerdan un plazo. Eviten modificar la semántica sin cambiar la versión o comunicarlo de forma inequívoca.

• Versionar el esquema y registrar la versión de las condiciones aplicables.
• Clasificar cambios según su impacto en productores, consumidores y procesos de conciliación.
• Acordar aprobación, pruebas, fecha de entrada en vigor y tratamiento de versiones anteriores.