Pesquisar na Comunidade
Showing results for tags '21 segundos'.
Encontrado 1 registro
-
Contexto UF Espírito Santo Revisão ACBR 20096 Projeto ACBrNFCe Configurações SSL WinCrypt XML MSXML2 {$DEFINE USE_MINGW} Habilitado O Problema Espírito Santo, em geral, nos dias de sexta-feira (com maior incidência) tendem a ter tempo de resposta no servidor SVRS bem alto, tempos geralmente acima de 21 segundos, e nós temos acompanhando um número ligações relacionadas a timeout, o que não seria um problema se o servidor não efetivasse a nota mesmo depois do timeout gerando uma duplicidade. Mas porque não entrar em contingência? Acontece que esses picos de timeout costumam serem passageiros e de curta duração, e não exclusivos da sexta-feira, e ficar na contingência não é um cenário ideal, sendo que a internet está sempre disponível. (na imagem acima, painel monitor para o SEFAZ Virtual RS, na última sexta-feira de manhã) (se você entrar nesse painel, não vai ver o ano de 2020, para conseguir visualizar, você precisa injetar o HTML com a opção de 2020) A Solução (que não está funcionando) Existem vários tópicos aqui no fórum, explicando sobre onde, como, e porque configurar o timeout, nós fizemos isso, definimos por média 60 segundos, porque era o máximo em condições normais que o servidor registrava, o que em teoria teria resolvido o problema, inclusive gostaria de registrar o seguinte: function TACBrWinHTTPReqResp.SetConnectionTimeOut: Boolean; A função WinHttpSetTimeouts estava recebendo o timeout de 60000 normalmente, conforme inspecionado em tempo de depuração. Porém em todas os testes que fizemos, com tempos de timeouts diferentes (60s, 240s e etc..), sempre o cronometro para em 21 segundos. Os testes foram realizados conforme vídeo do DANEL testando o timeout adicionando uma porta ao final das URL existentes no arquivo INI da ACBRNFe. (Exemplo do INI) (Pontos de verificação no WinHttpSendRequest, caso alguém for realizar os testes) C:\DL\T\ac\Fontes\ACBrTCP\ACBrWinHTTPReqResp.pas O "Possível" por quê Pesquisando sobre "Timeout" + "WinHttpSendRequest" encontrei um tópico justamente a respeito disso na MSDN americana, porém quem respondeu (segundo o autor) trabalhava no time de rede do Windows, dizendo: Segundo ele (se eu entendi bem), o uso de timeouts está descontinuado, e que não existe nenhum parte exposta via a API do WinHTTP para controlar esses tempos de troca de pacotes explicitados por ele na resposta. (Link Original Aqui) OpenSSL: A Solução (que funciona em partes) Os mesmos testes feitos com a OpenSSL funcionam corretamente, o timeout é respeitado conforme informado e com precisão, porém temos o problema dos certificados A3, logo as pessoas com certificado A3 continuariam com o problema. (Pontos de verificação na unit HTTP da OpenSSL, caso alguém for realizar os testes) C:\DL\T\ac\Fontes\ACBrDFe\ACBrDFeHttpOpenSSL.pas Em quanto terminava de escrever esse tópico senti a necessidade de testar na DEMO da ACBr diretamente, sem o Mingw, por segurança, e o mesmo ocorreu, porém no nosso programa testamos com envio da nota em homologação, e na demo com o status. A Pergunta Teria como alguém realizar os mesmos testes para confirmar isso? Existe alguma solução para A3 que não a Capicom e a WinCrypt? Alguém já passou por isso, e conseguiu uma solução?