pix-api
pix-api copied to clipboard
bacen
Período de Consulta online
Bom dia!
Existe um período obrigatório para retorno das consultas online da API?
Exemplo: Cliente faz a requisição da api \PIX dos recebimentos Pix de QR e transferências, efetuando a busca por um grande período. Dependendo do volume de pagamentos que o cliente possuir, pode dar um erro de time out.
A instituição pode criar uma regra de "expurgo" de dados online, para performar o retorno das APIs, disponibilizando outra forma de retorno para grandes volumes/períodos e incluir períodos máximos de busca?
Obrigada!
@biancaOliveiraSantos , bom dia.
Exemplo: Cliente faz a requisição da api \PIX dos recebimentos Pix de QR e transferências, efetuando a busca por um grande período. Dependendo do volume de pagamentos que o cliente possuir, pode dar um erro de time out.
apenas tentando entender: a paginação não resolve esse problema?
A instituição pode criar uma regra de "expurgo" de dados online, para performar o retorno das APIs, disponibilizando outra forma de retorno para grandes volumes/períodos e incluir períodos máximos de busca?
Essa só o DECEM pode responder em [email protected]
@biancaOliveiraSantos ,
A paginação ajuda, mas não resolve completamente.
Pode entrar em detalhes técnicos?
@ninrod, o problema de paginação não resolve, considerando como limite máximo 1000 x cobv por página, uma vez que o payload de cada cobv pode conter um vetor de infosAdicionais[] bem como um vetor de pix recebidos cada qual com devoluções.
Ai, tem dois potenciais problemas: 1) tempo das buscas (sub-selects da base, ou chamadas a microserviços) por exemplo para incluir os pix + devolucoes e 2) tamanho da resposta, considerando eventuais limites corporativos de gateways de APIs etc.
Como dado concreto, temos um caso de gateway com limite de 5MB de retorno, aí, 1000 x cobv = 5KB por cada JSON completo.
No caso do GET /lotecobv com lotes grandes, tanto o custo da consulta como um eventual limite de tamanho pode ser problemático, considerando uma página com 1000 lotes, cada qual com uma lista de cobs[], cada uma contendo txid, status, data e, potencialmente, um Problema com um vetor de violações ..
Tem uma outra questão que também vejo como problema com relação ao tempo da query que é o fato de termos que contar quantos registros foram encontrados dentro do período informado para então paginar os resultados.
Um exemplo: um cliente que recebe 100.000 Pix diários via pagamento de COB imediata, tenta obter a listagem de pix recebidos no período de 01/01/2021 à 31/12/2023. Por mais que a primeira página tem um limite de 1.000 pix a serem exibidos, será necessário devolver o valor total de transações no período.
Dado o exemplo, não seria interessante ter um limite no fornecimento dos parâmetros de data? Talvez 12 meses, por exemplo?
Outro ponto é, o cliente vai poder consultar transações "antigas"? Sei que o Pix é algo novo, porém o cliente vai poder solicitar listagem de Pix ocorrido a 6 anos atrás, por exemplo?
Tem uma outra questão que também vejo como problema com relação ao tempo da query que é o fato de termos que contar quantos registros foram encontrados dentro do período informado para então paginar os resultados.
Um exemplo: um cliente que recebe 100.000 Pix diários via pagamento de COB imediata, tenta obter a listagem de pix recebidos no período de 01/01/2021 à 31/12/2023. Por mais que a primeira página tem um limite de 1.000 pix a serem exibidos, será necessário devolver o valor total de transações no período.
Dado o exemplo, não seria interessante ter um limite no fornecimento dos parâmetros de data? Talvez 12 meses, por exemplo?
Outro ponto é, o cliente vai poder consultar transações "antigas"? Sei que o Pix é algo novo, porém o cliente vai poder solicitar listagem de Pix ocorrido a 6 anos atrás, por exemplo?
Não tem soma de valores de transações de GET no /cob, então não entendi o problema apontado.
Sobre o outro tema, enquanto não houver uma nova definição do BACEN, vai poder consultar desde Novembro de 2020. Se sua casa entende que isso não é ideal, pode propor ao BACEN uma revisão na spec.
Acredito que me expressei mal, quando disse valor total queria me referir a quantidade total de registros encontrados com os parâmetros fornecidos (campo quantidadeTotalDeItens).
Acredito que me expressei mal, quando disse valor total queria me referir a quantidade total de registros encontrados com os parâmetros fornecidos (campo quantidadeTotalDeItens).
Mas aí não é uma questão de correto design de banco de dados para que uma transação COUNT() não seja onerosa ?