Skip to main content
O Lerian SPB é orientado a eventos. A emissão de eventos não é garantida para cada operação ou mudança de ciclo de vida: alguns emissores são opcionais ou best effort, e EMISSION_REQUIRED tem false como padrão. Defina EMISSION_REQUIRED=true em um deploy cujos sistemas downstream dependem desses eventos. O bootstrap então falha fechado, a menos que a emissão de eventos esteja totalmente conectada. O Lerian SPB publica todas as famílias de eventos no backbone de streaming. Os sistemas downstream leem o estado de liquidação dos eventos de streaming settlement.* e spb.ldl.* e não fazem polling.

​
Famílias de eventos

Os avisos de entrada do BACEN também publicam eventos dedicados. Consulte Mensageria de entrada do BACEN.

​
Integração com o ledger

O seu consumidor de ledger deve receber as famílias str.operation.*, settlement.* e spb.ldl.* no backbone de streaming. O evento str.operation.accepted sinaliza a aceitação do despacho, não a liquidação no BACEN, então use-o para registrar um lançamento pendente. Registre a posição final a partir dos fatos settlement.* no backbone de streaming. A transição de negócio por trás de settlement.settled acontece quando a perna R de entrada move a mensagem STR da transferência para CONFIRMED. A entrega pelo broker é pelo menos uma vez e pode reentregar o fato. O ce-id é determinístico, então deduplique pelo par (ce-source, ce-id). Uma conversão de redesconto informa dois fatos settlement.*: o novo empréstimo e a quitação do empréstimo convertido, cujo settlementId termina em -PGTO. O seu RDC0005 e o RDC0015 que o BACEN envia no fechamento do STR informam dessa forma. As liquidações LDL, os depósitos LDL0022, o pagamento LTR0004 e os avisos LDL, LTR0003R2, LTR0005R2 e LTR0006R2 não solicitados não têm fato settlement.*. Registre-os a partir dos fatos spb.ldl.*:
  • A resposta R1 ao seu comando: deposit-confirmed ou deposit-failed para um depósito OT, e settlement-confirmed ou settlement-failed para todos os outros comandos.
  • Uma perna que o trilho ou dois operadores encerraram antes de o STR liquidá-la ou recusá-la: o fato de falha, com refusal.railClose no lugar de um código do STR. Quando os operadores declaram a perna liquidada a partir de uma resposta retida do STR, o fato de liquidação.
  • Um crédito LDL0020R2 que corresponde a um crédito OT esperado: credit-received.
  • Todos os outros avisos: third-party-settlement-received.
Um crédito TED de entrada que não responde a nenhuma operação sua chega como str.operation.received, então registre esse crédito a partir desse evento. Uma devolução de uma TED que você enviou chega da mesma forma. O campo numCtrlSTROr traz o número de controle da sua TED original. Uma devolução devolve um crédito TED que você recebeu, como uma transferência própria. str.operation.returnRequested sinaliza a aceitação do despacho da devolução, e o settlement.settled ou o settlement.failed da própria devolução dá a sua posição final. O Lerian SPB não mantém posição contábil. O trilho carrega a mensagem e o seu estado de liquidação, e o seu ledger registra o dinheiro.

​
Convenções da API

  • A autenticação é um bearer token.
  • As escritas são idempotentes pelo header X-Idempotency. Um reenvio não despacha em duplicidade.
  • As leituras do log de mensagens não expõem o frame assinado que trafega na rede. Você lê uma única mensagem pelo seu NUOp para obter dados estruturados. Quando o trilho reteve um frame, leia o XML reconstruído pela rota de frame dedicada, autorizada separadamente. Ele não retém separadamente os bytes literais enviados.
  • Ids desconhecidos retornam um not-found uniforme. A resposta nunca revela se existe uma operação que a sua instituição não possui.