Docs

.gitignore

@@ -18,4 +18,5 @@ node_modules
 
 *.pem
 
+
 dist/*

README.md

@@ -2,29 +2,21 @@
 
 Monorepo de servicios / workers para centralizar los procesos de las SIM con sus subscripciones
 
-[[./imgs/diagrama-servicios-sim.png]]
+![diagrama-sim](./imgs/diagrama-sim.png)
 
 El objetivo es que al lanzar peticiones REST a la parte visible, que se
 comprueben y se manden al broker para que los servicios de las compañías
 los puedan consumir.
 
-La idea es que las peticiones de activación, pausa, etc. no necesiten
+La compañia a la que pertenece cada peticion y por tanto el servicio que lo va a consumir se resuleve en el gateway, que anota en cada mensaje cual es la empresa propietaria de la sim, extrayendo la informacion del ICCID.
-tener una compañía especificada.
 
 ## Decisiones pendientes
 
-- [ ] La capa worker según acción y la de operaciones de proveedores
+- [x] La capa worker según acción y la de operaciones de proveedores, se podrían unir en una sola con un enrutamiento por acción y compañía, pasando de tener claves `sim.[acción]` a `sim.[compañia].[acción]`. *Se ha aplicado el cambio ahora las routing keys tienen la estructura `sim.[compañia].[acción]`*
-      se podrían unir en una sola con un enrutamiento por acción y compañía
+- [x] La estructura de RMQ se genera por medio del JSON, igual habría que definir cada cola en el worker que la consuma para poder añadir workers sin parar el RMQ. *Se ha aplicado el cambio, ahora solo se define en el json el broker principal para garantizar que exita sin servicios consumidores. Sin embargo tal como estan estructurdos los proyectos no es posible reiniciar solo un servicio*
-      pasando de tener claves `sim.[acción]` a `sim.[compañia].[acción]`.
-- [ ] La estructura de RMQ se genera por medio del JSON, igual habría que
-      definir cada cola en el worker que la consuma para poder añadir
-      workers sin parar el RMQ.
 - [ ] Versionado de la API.
-- [ ] Método para sacar la compañía a partir del iccid, o buscar en la
+- [x] Método para sacar la compañía a partir del iccid, o buscar en la BDD si no es posible. *De momento es un objeto Map en el servicio de gateway*
-      BDD si no es posible.
+- [ ] Cola de mensajes que no se han podido procesar. Distinguir según error de red; se reintenta; o error del propio mensaje; se envía a la cola de errores. v2 Se ha creado una cola de delay pero no se distingue el tipo de error, despues de n reintentos el mensaje va a la cola de dead-letter.
-- [ ] Cola de mensajes que no se han podido procesar. Distinguir según
-      error de red; se reintenta; o error del propio mensaje; se envía
-      a la cola de errores.
 
 ## Versión con consumidores basados en la compañia
 
@@ -34,5 +26,12 @@ las compañías, en principio se podría sin consultar la bdd si los caracteres
 
 ALAI: (34)9090
 NOS: (35)1031
+OBJENIOUS (33)2011a
 
-[./imgs/diagrama-servicios-sim-v2.png]
+## Diagrama de las colas de Rabbitmq
+
+Actualmente la topologia de las colas consiste en un exchage principal que recibe todos los mensajes y los redistribuye en las colas de cada empresa y a la de logs. Para evitar reintentos de mensajes instantaneos, que podrian ser inutiles si algún servicio se ha caido, se ha añadido una cola de delay que alamcena los mesajes fallidos durante n segundos antes de ser reenviados al exchange principal. Si despues de n reintentos el mensaje sigue fallando se envia a la cola de dead-letter para ser procesado manualmente.
+
+![img](./imgs/diagrama-rabbit.png)
+
+La decisión del numero de reintentos y la cola de dlx se hace en los servicios, con una configuracion global en shared.