Hace unos días, ya conté que empezamos las pruebas de un nuevo sistema de rutado de llamadas, pues bien, con casi un millón de llamadas rutadas podemos darlo por graduado y quitarle las comillas de “en pruebas”.
Aunque hemos tenido algún susto que otro, han sido menos de los normales en estos casos.
Os recuerdo que este sistema de rutas es, básicamente lo que podemos llamar una “Routing Virtual Machine (RVM)”, un procesador muy especializado que se limita a ejecutar un programa en un lenguaje DSL (Domain Specific Language) inventado por nosotros para un solo propósito : elegir por donde se enviará una llamada determinada.
Actualmente tenemos un compilador temporal que recoge la información de plan de numeración y de rutas del sistema que utilizábamos hasta ahora. Este sistema es el típico, una página web que modifica la información existente en una base de datos.
Pero el sistema que estamos preparando ahora es muy diferente, se trata de archivos de texto, con una estructura fácil de leer y con un compilador y una macros tipo m4, que eliminan mucha redundancia y facilitan la lectura.
Lo más complejo es la definición del plan de numeración, ya que, además de contener mucha información es la base para otros procesos de la compañía : simulación de tarifas, informes de consumo, listas de precios, etc.
Como ejemplo, aquí tenéis la definición de un nodo después de procesarse:
[-] .BA.MOB : Mobile 6 [ 11 ] x3876xTag : MOB path : .BA.MOB name : Mobile flags : NEEDS_RATE,NEEDS_ROUTE,SHOW digits : 6 prefix : x3876x lengths : [ 11 ]
Este nodo es Root + (.BA) Bosnia and Herzegovina + (.MOB) Móvil y se puede ver la información que se agrupa en cada nodo, algunos campos son :
Tag: Indica un etiqueta para poder agrupar nodos independientemente de su posición en el árbol, ejemplos de tags son : tipo (móvil, fijo, premium, …), atendiendo a sus precios (volatile, stable, strategic), etc.
Flags : comportamiento del nodo en el plan, aquí se ven solamente tres, pero actualmente tenemos 12 flags diferentes.
NEEDS_RATE implica que al procesar una lista de precios, es obligatorio que exista una tarifa para este nodo, de lo contrario saltará un error, lo mismo es NEEDS_ROUTE para la tabla de rutas, SHOW implica que a la hora de presentar informes de trafico, este nodo debe agrupar totales, en caso de que no estuviese, el tráfico que caiga en este nodo se sumará al primer nodo padre que tenga SHOW , y así hasta 12 flags diferentes.
Lengths : Simplemente una lista de longitudes permitidas, en este caso los móviles de B&H solamente pueden tener 11 dígitos, de modo que si llega una llamada que cae en este nodo con mas o menos de 11 dígitos, puede rechazarse directamente sin consumir mas recursos.
Tenemos un problema aún no resuelto y es como organizar la actualización, edición, depuración y puesta en marcha de toda esta información, lo mas probable será utilizar un control de versiones y un sistema de integración continua (probablemente Subversion y Hudson) para llevar estos datos hasta producción.
Lo mejor de este sistema es que si se nos ocurre otro flag, otro campo u otra estructura en el futuro, no es necesario modificar el RVM, solamente el compilador que produce el código de rutado.
Publicado por: |