Saltar al contenido principal
Lerian SILOC expone operaciones tipadas sobre la superficie /api/v1/siloc. A través de una sola conexión con Núclea, recibe los mensajes de SILOC y enruta cada uno, y envía las solicitudes propias de la institución. El servicio también mantiene los registros de participantes, certificados y cobertura que respaldan este trabajo.

Ciclo de vida de la conexión del gateway

Un descriptor de conexión MQ de SILOC completo activa el procesamiento entrante de SFN. Luego, el servicio abre y mantiene una conexión de gateway de mensajería con el SILOC de Núclea a través de la red del sistema financiero nacional. Cuatro protecciones resguardan la conexión:
  • un disyuntor que se activa tras fallos repetidos,
  • reconexión automática con un backoff limitado,
  • una parada por credencial deshabilitada que detiene el gateway tras la revocación de un certificado, y
  • una sonda de readiness que informa la conexión y el estado de salud del gateway.
Sin el descriptor, el servicio arranca sin conectividad SILOC en vivo, y un descriptor parcial impide que el servicio arranque. Consulta Variables de entorno. Con el descriptor completo configurado, el servicio descifra y decodifica los mensajes entrantes desde el envelope regulado antes de enrutarlos.

Envío entrante de SFN

Después de la decodificación, la ingesta selecciona una ruta a partir de una política cerrada de (CodProdt, CodMsg): La retransmisión a SLC actúa al llegar el mensaje. El servicio aparca todos los demás mensajes enrutados y los aplica después: PAG0101 cuando STATUS_REPLAY_ENABLED=true, y el resto cuando OT_REPLAY_ENABLED=true. LDL0020, LDL0006 y cualquier otro par de producto/código fallan de forma cerrada hacia una excepción operativa, y el servicio nunca los retransmite como financiamiento de liquidación. Un mensaje con un BCMSG.NUOp en blanco sigue la misma ruta de fallo cerrado.

Envío al menos una vez con desduplicación duradera

La fuente puede reenviar un mensaje, por lo que la retransmisión a SLC es al menos una vez. Para un frame de financiamiento de SLC decodificado correctamente con un BCMSG.NUOp no vacío, el servicio verifica la desduplicación duradera antes de retransmitir. La clave es la parte del mensaje: su BCMSG.NUOp y su número de parte, NumSeq. Un mensaje enviado entero es la parte 1. El servicio escribe el registro de mensaje procesado solo después de una retransmisión exitosa y antes de confirmar la recepción a la fuente. No crea ese registro para un mensaje no decodificado o no admitido. Un fallo antes de que el servicio escriba ese registro puede dejar el mensaje elegible para otra entrega. No trates este comportamiento como una garantía incondicional de exactamente una vez de extremo a extremo.

Resultados de fallos

  • Un fallo reintentable, como una caída del almacén de datos, devuelve el frame a la cola de recepción, y el servicio lo recibe de nuevo después de MQ_BACKOUT_DELAY. El servicio aparca en su base de datos, para un operador, un frame rechazado más de MQ_BACKOUT_THRESHOLD veces, y genera INBOUND_QUARANTINED. El frame sale de la cola de recepción solo después de que el servicio lo aparca.
  • Un fallo no reintentable, como un par (CodProdt, CodMsg) no admitido, falla de forma cerrada hacia una excepción operativa duradera. El servicio confirma el mensaje solo después de que se confirme ese registro de excepción.
  • Cuando la retransmisión a Lerian SLC está caída, el servicio aparca el frame de financiamiento como un fallo de retransmisión y genera RELAY_DOWN. Un operador lo vuelve a procesar después de que la retransmisión se recupera.
  • Antes de aplicar un mensaje aparcado, el servicio lo valida contra el XSD oficial. El servicio nunca aplica un mensaje que el esquema rechaza, y genera INBOUND_SEMANTIC_REJECTED. Mientras el validador no responde, el mensaje espera y el servicio genera XSD_VALIDATOR_DOWN.
  • El registro de mensaje procesado protege solo los mensajes decodificados correctamente y admitidos descritos arriba. No promete la retención de cada frame ni efectos de exactamente una vez en todos los sistemas downstream.

Observabilidad de la ingesta

  • Listar mensajes retransmitidos: el feed de auditoría de los mensajes de financiamiento que el servicio retransmitió a Lerian SLC.
  • Leer el estado de la retransmisión: el estado de salud de la retransmisión (HEALTHY, DEGRADED o DOWN), si la liquidación de tarjetas está bloqueada, y la marca de tiempo de la última retransmisión.

Solicitudes salientes

El servicio envía a Núclea las solicitudes propias de la institución: transferencias, movimientos de colateral, consultas, confirmaciones y cambios de estado de participantes. Una solicitud que sigue DISPATCHED después de su plazo de respuesta genera UNANSWERED_REQUEST. Después de que el gateway acepta un mensaje saliente en la cola, Lerian SILOC registra su transición de SUBMITTED a DISPATCHED en la base de datos. Un fallo de despacho que admite reintento lo mantiene en SUBMITTED para otro intento, hasta que se agota su plazo. El día de movimiento de una solicitud es el DtMovto que lleva su documento, y una solicitud no sale cuando ese día terminó. Una consulta es la excepción: su DtMovto puede nombrar un día pasado, y su día de movimiento es el día en que la envías.
  • LTR0002, LTR0008 y SLC0004 pertenecen al ciclo LBTR de su día de movimiento. El ciclo va de las 06h40 de Brasilia a las 17h30, o hasta el cierre posterior que un operador registró para ese día (consulta Operar Lerian SILOC). Un mensaje almacenado antes de las 06h40 espera sin enviarse hasta que el ciclo abra. lastError indica que espera, y no se cuenta ningún intento. Un día que no es hábil no tiene ciclo: Lerian SILOC rechaza con 422 SILOC-0025 un LTR0002 o LTR0008 que envías para él, y un comando de Lerian SLC termina en FAILED con el motivo lbtr_closed.
  • Los demás códigos vencen cuando termina su día de movimiento, a la medianoche de Brasilia, o en el cierre posterior que un operador registró para ese día.
Una solicitud no enviada que vence pasa a FAILED, y lastError indica el motivo. Un LTR0002 o LTR0008 para una operación cuya respuesta anterior está SUBMITTED, DISPATCHED o ANSWERED no admite una segunda respuesta: se rechaza con 409 SILOC-0026, y no se almacena nada. Una respuesta anterior que terminó en FAILED o REFUSED reabre la operación, y una confirmación LTR0002 o LTR0008 respondida (C) todavía admite una respuesta D para la misma operación.

Solicitudes retenidas a la espera de respuesta

Cuando se agota su plazo, una solicitud que puede haber llegado ya a Núclea no se marca como fallida ni se envía de nuevo. Queda en SUBMITTED con heldForAnswer en true. Un LTR0002 o LTR0008 en DISPATCHED cuyo ciclo LBTR terminó sin R1 se retiene igual y sigue en DISPATCHED. Enumera estas solicitudes con GET /api/v1/siloc/outbound/messages?held=true. Si Núclea responde, la respuesta se aplica como de costumbre. Si Núclea nunca responde, dos operadores distintos cierran la solicitud:
  1. El primer operador pide el cierre, con la evidencia en reason.
  2. Un segundo operador aprueba el cierre. La solicitud termina en FAILED, y una alerta UNANSWERED_REQUEST abierta para ella se cierra.
Mientras un cierre posterior registrado para el día mantiene abierto el ciclo LBTR de una solicitud DISPATCHED, los dos pasos responden 409 SILOC-0009. Solo las personas pueden hacerlo. Una credencial de máquina recibe 403, y el operador que pidió el cierre no puede aprobarlo. Si la respuesta de Núclea llega a la solicitud antes de la aprobación, el pedido de cierre termina como sustituido y la solicitud queda como la dejó la respuesta. Una respuesta de Núclea retenida para la solicitud bloquea el cierre simple. Cuando el servicio rechazó esa respuesta por su contenido, los dos operadores declaran el resultado que indica la respuesta, y el primer operador la nombra en parkedAnswerId:
  • FAILED, para la respuesta E de la solicitud. La solicitud termina en REFUSED.
  • SETTLED con settledAt, para la respuesta R1 de un LTR0002, de un LTR0008 o de una transferencia PAG. La solicitud termina en ANSWERED. Para una transferencia PAG, el primer operador también escribe numCtrl (NumCtrlPAG) y situation (SitLancPAG), y settledAt es el DtHrSit de la respuesta. Quien aprueba escribe los mismos valores.
Las demás respuestas no se pueden declarar. Cada lectura de la solicitud muestra closeRequest y las respuestas retenidas en parkedAnswers, cada una con su mensaje en base64.

Directorio de participantes

Lerian SILOC mantiene un directorio de los participantes de SILOC para los que liquida. Tú registras, listas, obtienes y actualizas un participante, y lees el estado de un participante. Cada participante incluye su ISPB y su rol. El servicio mantiene el estado operativo de un participante por producto, y los mensajes PAG0101 de la câmara lo establecen. Registrar o actualizar un participante, o un cambio de su estado, emite un hecho de participante. Las escrituras de registro son idempotentes mediante el header X-Idempotency, de modo que un registro reintentado no crea un duplicado. El estado operativo usa el dominio de siete valores de estado de SILOC:

Certificados regulados

El servicio conserva los certificados regulados de la conexión como referencias, no como secretos. Tú registras un certificado público junto con una referencia de custodia externa. El servicio analiza el certificado para obtener su asunto, número de serie y ventana de validez, y no almacena ninguna clave privada. Luego listas, obtienes y revocas certificados a través de la misma superficie.

Cobertura de capacidades

Un listado de capacidades de solo lectura describe las capacidades de cobertura de liquidación como una superficie de transparencia. Para cada tipo de mensaje, informa la dirección, el estado de implementación y la disposición.