Timeout + WinCrypt + 21 Segundos

[Data Lider]

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?

 

 

[Juliomar Marchetti]

Não utilize mais {$DEFINE USE_MINGW}

 

[Data Lider]

5 minutos atrás, Juliomar Marchetti disse:

Não utilize mais {$DEFINE USE_MINGW}

 

Obrigado por responder, eu já havia testado sem ela, o problema continua. 

[Daniel Simoes]

Existem várias situações possíveis de Erro de TimeOut... e realmente o Sistema Operacional, pode interferir...

Verifique ainda a propriedade TimeOutPorThread, na qual o próprio ACBR irá abandonar a conexão, quando o TimeOut ocorrer...

Mas pelo que você descreveu.. você não está tratando corretamente as situações de TimeOut...  e acionamento de Off-line

O fato do TimeOut ocorrer, não significa que o XML não foi entregue ao servidor... a lentidão poderia esta no caminho da resposta do XML, por exemplo...

Sempre que houver erro de TimeOut... você PRECISA consultar no SEFAZ, o Status do documento onde ocorreu o TimeOut...
Se ele existir no SEFAZ, você deve cancelar, pois essa Nota já foi tributada, pela nota emitida em contingência...

Aqui há uma coletânea de tópicos e vídeos, sobre esse assunto:

 

[Data Lider]

2 minutos atrás, Daniel Simoes disse:

Existem várias situações possíveis de Erro de TimeOut... e realmente o Sistema Operacional, pode interferir...

Verifique ainda a propriedade TimeOutPorThread, na qual o próprio ACBR irá abandonar a conexão, quando o TimeOut ocorrer...

Mas pelo que você descreveu.. você não está tratando corretamente as situações de TimeOut...  e acionamento de Off-line

O fato do TimeOut ocorrer, não significa que o XML não foi entregue ao servidor... a lentidão poderia esta no caminho da resposta do XML, por exemplo...

Sempre que houver erro de TimeOut... você PRECISA consultar no SEFAZ, o Status do documento onde ocorreu o TimeOut...
Se ele existir no SEFAZ, você deve cancelar, pois essa Nota já foi tributada, pela nota emitida em contingência...

Aqui há uma coletânea de tópicos e vídeos, sobre esse assunto:

 

Obrigado pela resposta, mas no caso, como o servidor está com o timeout acima de 21, não funcionaria o cancelamento também, e nem a verificação do status, ficaria para um tratamento posterior então?

[Daniel Simoes]

Quando você está Off-Line... está em Off-line... não tem consulta...

Depois de algum tempo, quando sua aplicação detectar que é seguro para voltar para On-Line... Apenas nesse momento, você deve tratar todas as pendências... (veja os vídeos no Post que indiquei)