> ## Documentation Index > Fetch the complete documentation index at: https://docs.lerian.studio/llms.txt > Use this file to discover all available pages before exploring further. # Como o Lerian STA funciona > Como o Lerian STA funciona: envio de saída e descoberta de arquivos de entrada para o BACEN, máquina de estados de protocolo, integridade SHA-256, limites de tentativas e TTL, e ações do operador. O Lerian STA move arquivos nas duas direções. Cada troca é uma **transferência**, um único arquivo que se move entre a instituição e o BACEN. Um **número de protocolo** rastreia a transferência ao longo do ciclo de vida de protocolo do BACEN. Cada ponta verifica o **SHA-256**. ## Envio de saída *** A instituição, ou um produto Lerian upstream, armazena o arquivo no bucket do Lerian STA e cria uma transferência cuja referência de arquivo é `outbound/`. Quando `TRANSFER_SCHEDULER_ENABLED` é `true`, um worker calcula o SHA-256 e o tamanho do arquivo e obtém do BACEN um número de protocolo que os declara. Ele envia os bytes do arquivo. O BACEN valida os bytes contra o SHA-256 declarado. Uma criação de transferência por `POST /v1/transfers` precisa de um header `X-Idempotency` de no máximo 256 bytes. Sem ele, o Lerian STA responde `400` com `STA-0001`. Se o seu serviço cria transferências em reação a um evento, envie uma chave derivada do identificador desse evento. Assim, as novas tentativas de um mesmo gatilho carregam a mesma chave. O Lerian CCS v1.0.0 envia os lotes ACCS001 sem o header `X-Idempotency`, e o Lerian STA v1.2.0 os recusa. Se você roda o Lerian CCS v1.0.0, mantenha o Lerian STA na v1.1.0. Durante 7 dias, uma repetição com a mesma chave e a mesma requisição reproduz a primeira resposta com `X-Idempotency-Replayed: true`. A mesma chave com uma requisição diferente retorna `422`. Depois dos 7 dias, o Lerian STA continua sem criar uma segunda transferência para a chave enquanto a primeira transferência existir. Depois de um `4xx` com um código `STA-NNNN`, envie a requisição corrigida com a mesma chave. Depois de um `5xx` sem o header `X-Idempotency-Fenced`, tente de novo com a mesma chave. Um `5xx` com esse header significa que a transferência pode existir. Com `true`, o Lerian STA recusa toda repetição da chave durante 7 dias. Com `false`, a chave não está protegida. Nos dois casos, consulte `GET /v1/transfers` e envie uma chave nova apenas se o Lerian STA não criou nenhuma transferência. A [lista de erros do STA](https://docs.lerian.studio/pt/reference/rails/sta/sta-error-list.md#idempotency-responses) descreve cada resposta de idempotência. A transferência avança pelo ciclo de vida do BACEN: | Estado | Significado | | - | - | | **Protocolo gerado** | O Lerian STA aceitou a transferência. O BACEN atribui o número de protocolo enquanto a transferência está nesse estado. | | **Transmissão iniciada / concluída** | O Lerian STA está enviando os bytes e, depois, concluiu o envio. | | **Verificação de integridade** | O BACEN está validando o SHA-256 declarado. | | **Recebido** | O BACEN recebeu o arquivo. | | **Entregue** | O BACEN entregou o arquivo ao seu destino. | | **Em processamento** | O BACEN está processando o arquivo. | | **Aceito** | O BACEN aceitou o arquivo. Um sucesso terminal. | | **Inconsistente** | Os bytes falharam na verificação de integridade do BACEN. Uma falha terminal. | | **Rejeitado** | O BACEN recusou o arquivo depois do processamento. Uma falha terminal. | | **Cancelado** | A transferência terminou antes de um veredito do BACEN, por exemplo por um operador, no teto de tentativas ou no TTL. Um estado terminal. | | **Respondido fora de banda** | O Lerian STA encontrou uma resposta de entrada separada para o protocolo. Esse estado terminal local confirma a chegada da resposta, não se o BACEN aceitou ou rejeitou o arquivo; ele registra o histórico de auditoria, mas não emite nenhum evento de resultado de transferência. | | **Criação de protocolo não confirmada** | Um estado terminal local. O Lerian STA não consegue confirmar que o BACEN atribuiu um protocolo. Um operador deve conciliá-lo. | | **Avaliação não confirmada** | Um estado terminal local. O TTL se esgotou enquanto o BACEN ainda devia um veredito. Ele não emite nenhum evento de resultado de transferência. | No teto, o Lerian STA cancela a transferência. Cada transferência também carrega um **TTL** em tempo real (44 horas por padrão), contado a partir do momento em que o BACEN atribui seu protocolo. Quando o TTL se esgota, o Lerian STA cancela a transferência, ou a marca como **Avaliação não confirmada** se o BACEN ainda devia um veredito. ## Descoberta e download de entrada *** Quando `TRANSFER_INBOUND_ENABLED` é `true`, o Lerian STA consulta o BACEN em busca de arquivos disponíveis. Cada configuração de origem de entrada define seu intervalo de polling, de 15 a 1.800 segundos. Para iniciar uma consulta de entrada na hora, envie `POST /v1/inbound-source-configs/{id}/trigger-poll` com um header `X-Idempotency`. Durante 7 dias, uma repetição com a mesma chave reproduz uma resposta `200` ou `202` e não consulta de novo. Para cada arquivo, o Lerian STA compara o **código de sistema do BACEN** do arquivo com as **configurações de origem de entrada**. Um arquivo que não corresponde a nenhuma recebe o produto de origem `unrouted`. Em seguida, o Lerian STA baixa os bytes. Ele verifica os bytes contra o SHA-256 informado pelo BACEN. Ele armazena o arquivo de forma durável no armazenamento de objetos. Quando o arquivo verificado é um arquivo ZIP com uma única entrada, o Lerian STA extrai a entrada e a entrega no lugar do arquivo ZIP. O claim-check então descreve o arquivo extraído: `object_key`, `file_name`, `size_bytes` e `sha256` se referem à entrada. O Lerian STA calcula esse `sha256` sobre os bytes extraídos. `TRANSFER_INBOUND_EXTRACT_MAX_EXPANSION_RATIO` e `TRANSFER_INBOUND_EXTRACT_MAX_EXTRACTED_BYTES` limitam o tamanho extraído. Quando o Lerian STA não extrai uma entrada, ele entrega o arquivo como recebido. O claim-check então carrega o hash e o tamanho que o BACEN informou. Quando o hash não confere, o Lerian STA faz até 3 tentativas por padrão e, então, termina a transferência como inconsistente. Quando um download falha, ele faz até 5 tentativas por padrão e, então, cancela a transferência. Quando o BACEN recusa autorizar o download, a transferência termina na hora como não autorizada. Em cada caso, o Lerian STA não entrega o arquivo ao seu produto de origem. ## Ações do operador *** Um operador apenas pode agir onde o estado e a configuração da transferência permitirem: * **Cancelar** quando a máquina de estados permite uma transição para `Canceled`, o que exclui **Verificação de integridade** e **Entregue**. O cancelamento é local. O Lerian STA não envia nada ao BACEN. * **Repetir** uma transferência de saída quando ela é não terminal, tem menos de 5 tentativas de envio e seu TTL não expirou. Esse limite continua em 5, qualquer que seja o teto configurado. Cada repetição conta como uma tentativa. * **Marcar como urgente**, quando `TRANSFER_INBOUND_ENABLED` é `true`, uma transferência de entrada em `AvailableForDownload` cujo produto de origem tem urgência habilitada em todas as configurações habilitadas. Fora isso, falha de forma fechada. This documentation is built and hosted on [Mintlify](https://mintlify.com), a developer documentation platform.