Jump to content
Notícias do ACBr

click.png

click.png

click.png

click.png

click.png

click.png

logo_acbr_paygo.png

TEF ACBr PayGo
Seja um revendedor e ofereça uma solução completa para seu cliente.


Saiba mais

beneficios.png

click.png

click.png

click.png

Erro ao consultar protocolo


jcmferreira
  • Este tópico foi criado há 1081 dias atrás.
  • Talvez seja melhor você criar um NOVO TÓPICO do que postar uma resposta aqui

Recommended Posts

Boa tarde pessoal!

Estou com um problema estranho, ocorre de forma aleatória e que ainda não consegui identificar. Em muitos dos nossos clientes, quando tentamos consultar o protocolo com o método Consultar, seguindo rigidamente o padrão implementado pelo projeto ACBr eSocial.

ERRO: WebService Consulta Status serviço:
- Inativo ou Inoperante tente novamente.
Erro Interno: 10060
Erro HTTP: 0

Alguém tem ideia do que seja isso? Meus fontes já estão no Trunk2.

 

Agradeço antecipadamente pela ajuda!

Link to comment
Share on other sites

Sabe dizer a frequencia com que isso corre? 
É normal esse tipo de time out, porém não frequentemente. 
Basta consultar novamente que dará certo. 
A única observação sobre isso é se vc estiver sobrecarregando o servidor de consulta com consultas desnecessárias, o eSocial já informou nos manuais 
que se a aplicação ficar consultando indevidamente um lote que ainda não foi processando ele vai limitar o acesso e poderia ocorrer um time out. 
Normalmente 1 min é o suficiente para o eSocial processar o evento (Tem exceções como o S-1299) @jcmferreira

Edited by Alisson Souza Pereira
Link to comment
Share on other sites

16 horas atrás, Alisson Souza Pereira disse:

Sabe dizer a frequencia com que isso corre? 
É normal esse tipo de time out, porém não frequentemente. 
Basta consultar novamente que dará certo. 
A única observação sobre isso é se vc estiver sobrecarregando o servidor de consulta com consultas desnecessárias, o eSocial já informou nos manuais 
que se a aplicação ficar consultando indevidamente um lote que ainda não foi processando ele vai limitar o acesso e poderia ocorrer um time out. 
Normalmente 1 min é o suficiente para o eSocial processar o evento (Tem exceções como o S-1299) @jcmferreira

Alisson, valeu pela preocupação!

Esse "erro" (caso confirmado o timeout mencionado por você) está ficando com uma frequência relativamente chata agora. Passou a gerar incomodo em alguns casos.

Nossa solução está da seguinte forma:

  1. Enviamos um lote (nunca em paralelo)
  2. Dependendo do retorno (caso resposta positiva e exista o protocolo), realizamos a primeira consulta (aqui, o tempo não chega em 1 minuto... é na sequencia mesmo)
  3. Caso haja 101, tentamos ver se a tag de tempo estimado veio (nunca vi na vida, pra ser sincero). Caso negativo, damos um intervalo de 3 minutos para a próxima consulta.
  4. Fica no "loop" repetindo os passos acima até finalizar todos os lotes que precisam ser enviados, de todos os eventos.

Talvez, o problema esteja na consulta imediatamente após o envio do lote, não? Mas confesso que se sim, começou faz coisa de um mês apenas.

Link to comment
Share on other sites

Verifiquei por cima os meus eventos 10.000 eventos 5 time outs.

No meu caso estou trabalhando com thread, excetuando os evento de tabela é possível enviar vários eventos e ir consultando de forma gradativa, e como a conexão é assincrona
não tem porque vc enviar esperar a consulta deste evento para poder enviar o próximo, basta criar uma regra de encadeamento para os eventos que possuem dependencia respeitarem a sua ordem. 

No meu caso pouco importa quantos time out dê, me parece que são servidores distintos(esocial envio / esocial consulta), as consultas estão dando time out mas o envio continua funcionando, quando o servidor de consulta 
volta a funcionar, as consultas passam a ser realizadas normalmente e os lotes que deram time out serão consultados de forma AUTOMÁTICA...

no seu caso quando dá time out vc tem que intervir??
Não consegui entender qual está sendo o seu problema, porque mesmo que dê o time out a própria mensageria sabe que quando o eSocial voltar a funcionar este evento deverá ser consultado. 

Link to comment
Share on other sites

1 hora atrás, Alisson Souza Pereira disse:

Verifiquei por cima os meus eventos 10.000 eventos 5 time outs.

No meu caso estou trabalhando com thread, excetuando os evento de tabela é possível enviar vários eventos e ir consultando de forma gradativa, e como a conexão é assincrona
não tem porque vc enviar esperar a consulta deste evento para poder enviar o próximo, basta criar uma regra de encadeamento para os eventos que possuem dependencia respeitarem a sua ordem. 

No meu caso pouco importa quantos time out dê, me parece que são servidores distintos(esocial envio / esocial consulta), as consultas estão dando time out mas o envio continua funcionando, quando o servidor de consulta 
volta a funcionar, as consultas passam a ser realizadas normalmente e os lotes que deram time out serão consultados de forma AUTOMÁTICA...

no seu caso quando dá time out vc tem que intervir??
Não consegui entender qual está sendo o seu problema, porque mesmo que dê o time out a própria mensageria sabe que quando o eSocial voltar a funcionar este evento deverá ser consultado. 

Alisson,

Na verdade, apenas queria entender o contexto do erro. Uma forma de resolver isso transparente, sem precisar aprofundar muito na lógica. Mas já que vc entrou nesse assunto, o nosso sistema, na prática, é um web service próprio (desenvolvido por nós mesmos) que fornece uma série de APIs rodando pesadamente em multi-thread e totalmente assíncrono. O RH3 Smart é o produto responsável por todo esse gerenciamento do eSocial dentro do ambiente dos clientes. Tudo de forma transparente e sem interferência do usuário em quase 90% dos casos (salvando-se os eventos que são requisitados para auditoria pré-envio).

A descrição feita foi um pequeno trecho do processo de envio de lote e sequencial consulta do protocolo. Mas isso, de forma macro, está ocorrendo em paralelo com outros lotes e consultas, sempre respeitando as regras impostas pelo eSocial. Alguns de nossos clientes na fase de adesão, chegaram a enviar mais de 100.000 eventos em mais de 2.000 lotes de forma assíncrona.

Buscamos dignificar o resultado das respostas exibidas aos usuários, numa tratativa mais elegante que um erro HTTP de código "genérico" ao usuário.

 

Link to comment
Share on other sites

  • Este tópico foi criado há 1081 dias atrás.
  • Talvez seja melhor você criar um NOVO TÓPICO do que postar uma resposta aqui

Create an account or sign in to comment

You need to be a member in order to leave a comment

Create an account

Sign up for a new account in our community. It's easy!

Register a new account

Sign in

Already have an account? Sign in here.

Sign In Now
×
×
  • Create New...

Important Information

We have placed cookies on your device to help make this website better. You can adjust your cookie settings, otherwise we'll assume you're okay to continue.