Skip to main content

​
La edición que parecía no hacer nada

Una regla mal formada hace fallar toda la recarga, y la tabla anterior se conserva. Una línea incorrecta no desactiva una sola regla: rechaza el conjunto completo de tablas, y la pasarela sigue enrutando con la configuración que ya servía.Nada parece estar mal: el tráfico sigue fluyendo, el archivo en disco dice lo que quisiste decir, y el único rastro es Error parsing new routing table en nivel ERROR en el registro. Búscalo después de cada edición.
routingTable.conf se recarga en caliente: una edición se aplica en unos 200 ms, sin reinicio. Esa velocidad es exactamente la razón por la que el caso de tabla conservada es fácil de pasar por alto. No hay ningún reinicio que notar, así que “mi cambio no hizo nada” es todo el síntoma.

​
Qué hace el enrutador con un mensaje

1

A la sumisión se le responde primero

La pasarela envía submit_sm_resp, o el 200 REST, antes de que se ejecute el enrutamiento. Al cliente ya se le ha dicho que el mensaje fue aceptado, y se le ha cobrado por él.
2

El mensaje va a la cola del enrutador

El trabajo aceptado espera aquí. Consulta Colas y reintentos.
3

Se escanea la tabla `default`

Las reglas se prueban de arriba abajo y gana la primera coincidencia. Una regla puede enviar a un proveedor, a un grupo de proveedores o a otra tabla.
4

El worker elegido lo toma

El mensaje se encola en la propia cola de ese proveedor y sale a la velocidad que el proveedor permita.
Como el paso 1 ocurre antes del paso 3, un fallo de enrutamiento no puede informarse al cliente como un error de envío. Solo puede aparecer más tarde, como un acuse de recibo de entrega y una fila en cdr_rejected.

​
Las tablas son un grafo, no una lista

Una regla cuyo objetivo nombra otra tabla se encadena a ella, así que default → MESSAGE → cheapest es una forma habitual. Dos cosas acotan la recursión: Una tabla alcanzada dos veces por rutas diferentes no es un ciclo: default → a → c junto a default → b → c se carga con normalidad.

​
Las dos cosas que se cargan y luego se portan mal en silencio

Ambas aparecen en /ops/health bajo routing_warnings, y cada una se registra una sola vez cuando aparece por primera vez, no en cada publicación.
El catch-all va al final. Colocado por encima de otras reglas, hace que todo lo que esté debajo sea inalcanzable, y nada rechaza la tabla. Las reglas se analizan perfectamente, simplemente nunca se ejecutan. Un catch-all es una regla que no restringe nada: vendor1::default: en un archivo, o una regla sin condiciones y sin filtros en la base de datos.Una regla que lleva un filtro no es un catch-all, por mucho que lo parezca. Consulta Filtros.

​
Cuando los mensajes desaparecen

Antes de editar cualquier regla, descarta las tres causas que no tienen nada que ver con el enrutamiento. Solo reason = 'maxAttempts' en cdr_rejected significa enrutamiento; headerNotApproved, templateNotMatched, missingMandatoryTlv, insufficientCredit y filtered significan todas que el mensaje fue rechazado antes de llegar al enrutamiento. Consulta No se entrega nada.
Estas líneas están en WARN o ERROR y no requieren ninguna bandera de depuración:
routing.rule.broken se registra una vez por regla, no una vez por mensaje, y el contador solo se reinicia cuando se publica una nueva tabla. Un registro silencioso no es, por tanto, prueba de que el problema esté resuelto. Es igual de consistente con “ya notificado”.Vigila en su lugar el contador routing_rules_broken en /ops/health, que es el mismo hecho expresado como un número.

​
Preguntar por qué un mensaje no coincidió

Acepta un número de serie de mensaje o un id de cuenta. Cada regla contra la que se prueba ese mensaje registra entonces qué condición falló y qué contenía realmente el mensaje:
Se aplica en vivo, así que actívalo durante el incidente y bórralo después. Vacío, que es el valor por defecto, cuesta una lectura volátil por regla.
Esto no es outSms.routing.debug. Ese registra cada regla de cada mensaje y renderiza el objeto de mensaje completo para hacerlo, lo que lo hace inutilizable a los ritmos a los que realmente se plantean las preguntas de enrutamiento. Solo resulta útil en una pasarela inactiva reproduciendo un único envío.

​
Siguiente

Escritura de reglas

La gramática de cuatro partes, los operadores que engañan y los grupos de proveedores.

Enrutamiento por menor coste

Donde el orden de las reglas deja de significar nada.

Filtros

Condiciones nombradas, y por qué desactivar una reduce una regla a nada.

Colas y reintentos

Lo que ya está pagado y esperando en memoria.