ACBrLib.NFe não permite reescrever método CheckResult para tratar corretamente Timeout

[OFF-DEV]

Boa tarde pessoal,  a pedido do Daniel, vou postar aqui minhas considerações sobre como aproveitar a ACBrLib.Nfe para tratar corretamente o TimeOut e aí lidar corretamente com Contingência:

Como foi pensado no projeto da ACBrLib.NFe em C# para que eu possa reescrever o CheckResult dentro da minha aplicação?

Eu tentei fazer uma herança de ACBrNFe e reescrever o  método CheckResult (imagem), porém o método está protected e a classe que fizeram está sealed, ou seja, não dá para criar herança, o que limita, o que ao meu ver não deve ser feito desta forma.

Aquilo que eu queria de melhorar a detecção do Timeout  está descrito neste vídeo do ACBR, o problema que ele demonstra alterando o próprio código C# do ACBR e no desenvolvimento aqui nós não podemos alterar o código de vocês, o mais racional é criarmos uma herança de ACBrNFe e reescrever o método CheckREsult para tratar o Time Out.    Veja o vídeo por favor.

https://acbr.nutror.com/curso/27abfa7e547e651dbef313cc8bd11dbfc0bbd203/aula/4482733

Isso limita bastante o uso da ACBRLib.NFe em C# pois eu não posso usar herança.   OU foi pensado outra alternativa pra resolver isso?


Solução proposta:  Retirar o Sealead da Classe ACBrNFe para que os usuários da classe possam reescrever o CheckResult e implementar o controle de TImeOut conforme sugerido no video tutorial do ACBR.
 

Qualquer coisa estou à disposição aprofundar no tema.

Att.
Leandro S.
 

Editado 14 Novembro por OFF-DEV

[Diego Foliene]

Boa tarde!

Foi criada a #TK-6235 para análise do caso e parecer por parte da equipe de consultores.

Qualquer novidade será divulgada neste tópico.

[antonio.carlos]

Fazendo desta forma não resolveria ?

[OFF-DEV]

 

Olá Antonio,

 

Não resolveria porque o Exception não me garante que ele foi disparado devido a um timeout, ele é genérico.  No vídeo tutorial que eu postei do ACBR ele explica como escrever o código (vide novo anexo de imagem ) e passá-lo via personalização de um Exception.     

Como eu não posso alterar o código do ACBR (senão vou ter que alterar toda a vez que tiver atualização de versão),  eu prefiro fazer o mesmo na minha aplicação e obrigatoriamente preciso da herança, porém o Sealed na classe não deixa.  

Observação 1: eu poderia considerar todo Exception como TimeOut, porém existem ali alguns códigos de retorno que não são Timeouts e isso provocaria um tratamento incorreto dos erros pela minha aplicação, o que poderia influenciar até como o loop de tratamento da contingência funciona no SEFAZ.

abs.

[antonio.carlos]

Agora, OFF-DEV disse:

 

Olá Antonio,

 

Não resolveria porque o Exception não me garante que ele foi disparado devido a um timeout, ele é genérico.  No vídeo tutorial que eu postei do ACBR ele explica como escrever o código (vide novo anexo de imagem ) e passá-lo via personalização de um Exception.     

Como eu não posso alterar o código do ACBR (senão vou ter que alterar toda a vez que tiver atualização de versão),  eu prefiro fazer o mesmo na minha aplicação e obrigatoriamente preciso da herança, porém o Sealed na classe não deixa.  

Observação 1: eu poderia considerar todo Exception como TimeOut, porém existem ali alguns códigos de retorno que não são Timeouts e isso provocaria um tratamento incorreto dos erros pela minha aplicação, o que poderia influenciar até como o loop de tratamento da contingência funciona no SEFAZ.

abs.

Faça um teste, mesmo ele não sendo um timeout, veja se desta forma, você consegue tratar todos os retornos, sem precisarmos mexer nas classes do C#

[OFF-DEV]

Antonio,

 

Não vai funcionar nem no teste, você percebeu que o StatusServico  usa também o CheckResult?   Vai ter o comportamento que eu descrevi.

[antonio.carlos]

5 minutos atrás, OFF-DEV disse:

Antonio,

 

Não vai funcionar nem no teste, você percebeu que o StatusServico  usa também o CheckResult?   Vai ter o comportamento que eu descrevi.

Então vamos aguardar analise da #TK-6235, logo teremos um retorno, combinado ?

[OFF-DEV]

Combinado meu amigo, vc acha que pela simplicidade do tipo de solução poderá sair rápido?

[OFF-DEV]

Sugestão 2:

 

Trago uma segunda sugestão de implementação qué simplesmente implementar no LIB C# o TimeOutException para o usuário da lib possa saber quando ocorreu e dar inicio ao processo do loop de contingência.

 

Abs.

[Júlio Cavalcanti]

Bom dia, @OFF-DEV.

Caso use via SVN:

Perceba que o checkResult não é um método nativo da lib, apenas implementamos para lançar algumas exceções com base no retorno do método nativo. Podemos pensar em alguma forma de melhorar isso. Porém, precisamos validar se não teremos conflitos com quem já utiliza dessa maneira.

Para que tu não fique aguardando, uma possibilidade é implementar um método na tua aplicação que trata isso, por exemplo, checkException, e usar ele em vez do checkResult. Dessa maneira tu tem total controle da exceção que será lançada de acordo com o retorno do método nativo.

Ex:


Caso use via NuGet:

Para que tu consiga sobrescrever o método e tratar da maneira mais adequada para tua aplicação, precisamos realizar uma alteração no código fonte e verificar os possíveis conflitos para quem já utiliza da maneira atual (O que pode levar um tempo).

[OFF-DEV]

 

7 horas atrás, Júlio Cavalcanti disse:

Bom dia, @OFF-DEV.

Caso use via SVN:

Perceba que o checkResult não é um método nativo da lib, apenas implementamos para lançar algumas exceções com base no retorno do método nativo. Podemos pensar em alguma forma de melhorar isso. Porém, precisamos validar se não teremos conflitos com quem já utiliza dessa maneira.

Para que tu não fique aguardando, uma possibilidade é implementar um método na tua aplicação que trata isso, por exemplo, checkException, e usar ele em vez do checkResult. Dessa maneira tu tem total controle da exceção que será lançada de acordo com o retorno do método nativo.

Ex:


Caso use via NuGet:

Para que tu consiga sobrescrever o método e tratar da maneira mais adequada para tua aplicação, precisamos realizar uma alteração no código fonte e verificar os possíveis conflitos para quem já utiliza da maneira atual (O que pode levar um tempo).

 

Se eu entendi correto  isso cai no que eu disse lá em cima, eu vou ter que obrigatoriamente alterar um fonte em C# do ACBR o que vai gerar problemas no futuro pois toda vez que tiver atualização vou ter que rever este código se não tiveram outras alterações e inserir novamente meu código toda a vez, o que aumenta o custo do procedimento.  Não vou fazer isso, pois vai gerar problemas com certeza este tipo de coisa.

 

Complementando a minha sugestão do Exception, não poderia criar um flag passada via Nfce.Config.ThrowExceptionTimeOut=true (default  false)  para que ocorra o Exception?  Desta forma não afetaria ninguem que já usa a LIB e já resolveria o problema da detecção do TimeOut.  Pode ser?

 

 

 

 

 

Editado Terça as 21:52 por OFF-DEV

[Júlio Cavalcanti]

16 horas atrás, OFF-DEV disse:

 

 

Se eu entendi correto  isso cai no que eu disse lá em cima, eu vou ter que obrigatoriamente alterar um fonte em C# do ACBR o que vai gerar problemas no futuro pois toda vez que tiver atualização vou ter que rever este código se não tiveram outras alterações e inserir novamente meu código toda a vez, o que aumenta o custo do procedimento.  Não vou fazer isso, pois vai gerar problemas com certeza este tipo de coisa.

 

Complementando a minha sugestão do Exception, não poderia criar um flag passada via Nfce.Config.ThrowExceptionTimeOut=true (default  false)  para que ocorra o Exception?  Desta forma não afetaria ninguem que já usa a LIB e já resolveria o problema da detecção do TimeOut.  Pode ser?

 

 

 

 

 

Eu entendi o ponto, mas por mais simples que seja a mudança, nós precisamos validar antes. O time já está trabalhando nisso, trago um retorno para ti quando concluirmos. A solução acima é temporária, caso tu precise urgente.

[Júlio Cavalcanti]

Tu pode contribuir, realizando a alteração e anexar aqui no tópico. Dessa maneira nós validamos a inclusão da contribuição.