Saltar al contenido principal
Lerian SPB es orientado a eventos. La emisión de eventos no está garantizada para cada operación o cambio de ciclo de vida: algunos emisores son opcionales o best effort, y EMISSION_REQUIRED tiene false como valor predeterminado. Define EMISSION_REQUIRED=true en un despliegue cuyos sistemas downstream dependan de estos eventos. Entonces el bootstrap falla cerrado a menos que la emisión de eventos esté conectada por completo. Lerian SPB publica todas las familias de eventos en el backbone de streaming. Los sistemas downstream leen el estado de liquidación de los eventos de streaming settlement.* y spb.ldl.* y no hacen sondeo.

​
Familias de eventos

Los avisos entrantes de BACEN también publican eventos dedicados. Consulta Mensajería entrante desde BACEN.

​
Integración con el ledger

Tu consumidor de ledger debe recibir las familias str.operation.*, settlement.* y spb.ldl.* en el backbone de streaming. El evento str.operation.accepted señala la aceptación del despacho, no la liquidación en BACEN, así que úsalo para registrar un asiento pendiente. Registra la posición final a partir de los hechos settlement.* del backbone de streaming. La transición de negocio detrás de settlement.settled ocurre cuando la pata R entrante mueve el mensaje STR de la transferencia a CONFIRMED. La entrega del broker es al menos una vez y puede reenviar el hecho. El ce-id es determinista, así que deduplica por el par (ce-source, ce-id). Las liquidaciones LDL, los depósitos LDL0022, el pago LTR0004 y los avisos LDL y LTR0005R2 no solicitados no tienen hecho settlement.*. Regístralos a partir de los hechos spb.ldl.*:
  • La respuesta R1 a tu comando: deposit-confirmed o deposit-failed para un depósito OT, y settlement-confirmed o settlement-failed para todos los demás comandos.
  • Un crédito LDL0020R2 que corresponde a un crédito OT esperado: credit-received.
  • Todos los demás avisos: third-party-settlement-received.
Un crédito entrante que no responde a ninguna operación tuya llega como str.operation.received, así que registra ese crédito a partir de este evento. Un retorno de una TED que enviaste llega de la misma forma. Su campo numCtrlSTROr contiene el número de control de tu TED original. Un retorno devuelve un crédito TED que recibiste, como una transferencia propia. str.operation.returnRequested señala la aceptación del despacho del retorno, y el settlement.settled o el settlement.failed del propio retorno da su posición final. Lerian SPB no mantiene ninguna posición contable. El riel transporta el mensaje y su estado de liquidación, y tu ledger registra el dinero.

​
Convenciones de la API

  • La autenticación es un Bearer token.
  • Las escrituras son idempotentes mediante el header X-Idempotency. Un envío reintentado no despacha dos veces.
  • Las lecturas del log de mensajes no exponen el frame firmado que viajó por la red. Lees un solo mensaje por su NUOp para obtener datos estructurados. Cuando el riel retuvo un frame, lee su XML reconstruido por la ruta de frame dedicada y autorizada por separado. No retiene por separado los bytes literales enviados.
  • Los ids desconocidos devuelven un not-found uniforme. La respuesta nunca revela si existe una operación que tu institución no posee.