Saltar al contenido principal
Lerian SILOC es la integración de mensajería nativa de Lerian para SILOC, el sistema de liquidación diferida neta que Núclea opera para los flujos de boleto y tarjetas. Estableces estas variables en el momento del despliegue. Un cambio surte efecto solo después de que reinicies el servicio. Para conocer los parámetros que se comportan igual en todos los servicios de Lerian en Go (postura de despliegue, telemetría y convenciones de almacenamiento de datos), consulta Fundamentos de configuración de BYOC. En las siguientes tablas, Obligatorio marca una variable que debes establecer, ya sea de forma global o bajo la condición indicada. — significa que no hay valor predeterminado.

Runtime y servidor

Autenticación

Lerian SILOC autoriza las rutas protegidas mediante Access Manager. AUTH_ENABLED no tiene valor predeterminado, así que el servicio se niega a iniciar hasta que lo establezcas.

PostgreSQL

La réplica recurre al host primario cuando dejas DB_REPLICA_HOST vacío (predeterminado de nodo único).

Redis

Conectividad de liquidación de SILOC

Lerian SILOC mantiene una única conexión IBM MQ con el gestor de colas de liquidación de SILOC de Núclea. Establecer MQ_HOST, MQ_CHANNEL, MQ_QUEUE_MANAGER, MQ_SEND_QUEUE o MQ_RECEIVE_QUEUE hace que el servicio valide todo el descriptor de conexión de forma cerrada en el arranque. Las demás variables MQ_* por sí solas no activan esa validación.

Mensajes salientes

El servicio envía las solicitudes de la institución a Núclea solo cuando los dos identificadores de certificado y MQ_SEND_QUEUE están establecidos. Establece los dos identificadores o ninguno: uno sin el otro impide el arranque.

Validación de mensajes

El servicio valida los mensajes entrantes que aplica y los mensajes salientes que envía contra los esquemas XSD oficiales, mediante un sidecar validador. El sidecar escucha en XSD_VALIDATOR_ADDR (predeterminado 127.0.0.1:9091), y su propio AUTH_ENABLED no tiene valor predeterminado. El servicio no envía ningún token bearer al sidecar, así que ejecuta el sidecar con AUTH_ENABLED=false en una dirección de loopback literal.

Certificados

Confianza y custodia

Procesamiento en segundo plano

Los cinco interruptores *_ENABLED de esta tabla no tienen valor predeterminado. Establece cada uno en true o false, porque un valor vacío impide el arranque. Con false, el runtime queda apagado y su verificación de readiness reporta skipped. Con true, el servicio reintenta un runtime que no arranca hasta que se ejecute, y su verificación de readiness reporta el motivo sin fallar.

Declaración de permisos

El servicio puede publicar su propio conjunto de permisos en Access Manager durante el arranque. Solo IDP_DECLARATION_ENABLED=true lo activa. Con la publicación activa, una variable faltante de las siguientes impide el arranque.

Observabilidad

Si STREAMING_EVENT_POLICIES define enabled=false para un evento de comando de tarjeta (siloc_command.accepted, siloc_command.answered, siloc_command.refused o siloc_command.failed), el consumidor de comandos de tarjeta no arranca. Si define enabled=false para siloc.relay.inbound, el procesamiento de mensajes entrantes no arranca. En ambos casos, el error nombra el evento.

Salud y readiness

Lerian SILOC expone GET /health (liveness), GET /readyz (readiness) y GET /version en el puerto HTTP principal. El servicio se niega a arrancar cuando PostgreSQL no responde en un plazo de 10 segundos. Arranca antes de que Redis y la conexión de liquidación sean accesibles. /readyz reporta la salud de cada dependencia. Mientras el queue manager de SILOC de Núclea no es accesible, siloc-mq reporta down y no hace que /readyz pase a 503. siloc-mq hace fallar el readiness cuando el queue manager rechaza la configuración de esta implementación, y nombra el ajuste que hay que corregir. Consulta Salud y readiness para conocer el contrato de las sondas.