ACBR GTIN e Proxy

[AngeloMique]

Boa tarde a todos.

Estou implementando o ACBRGTIN em um projeto. Certificado, Schemas, etc... tudo configurado. Em máquinas sem um proxy, a consulta vai de boa e o WebServices retorna todas as informações corretamente.

Porém, quando configuramos um proxy, o componente retorna como se o Webservice não tivesse sido consultado, ou seja resulta vazio em todas as informações.

A URL do WebService utilizado para a cosnulta (https://dfe-servico.svrs.rs.gov.br/ws/cgConsGTIN/ccgConsGTIN.asmx) abre no browser nas máquinas com proxy normalmente. Mas no componente, retorna nulo. Imagens anexas. Alguém poderia dar uma luz?

Sem proxy:

 

 

 

Com Proxy:

 

 

 

 

 

[AngeloMique]

Corrigindo:

 

A URL acessada pelas máquinas via proxy acima citada é https://dfe-servico.svrs.rs.gov.br/ws/ccgConsGTIN/ccgConsGTIN.asmx

 

Angelo.

[Diego Foliene]

5 horas atrás, AngeloMique disse:

Boa tarde a todos.

Estou implementando o ACBRGTIN em um projeto. Certificado, Schemas, etc... tudo configurado. Em máquinas sem um proxy, a consulta vai de boa e o WebServices retorna todas as informações corretamente.

Porém, quando configuramos um proxy, o componente retorna como se o Webservice não tivesse sido consultado, ou seja resulta vazio em todas as informações.

A URL do WebService utilizado para a cosnulta (https://dfe-servico.svrs.rs.gov.br/ws/cgConsGTIN/ccgConsGTIN.asmx) abre no browser nas máquinas com proxy normalmente. Mas no componente, retorna nulo. Imagens anexas. Alguém poderia dar uma luz?

Sem proxy:

 

 

 

Com Proxy:

 

 

 

 

 

Boa tarde!
Por favor, faça um teste com o programa exemplo marcando a opção "Salvar envelope Soap" na aba WebServices e confira nos arquivos gerados se vem as informações.

[AngeloMique]

Bom dia Diego.

Obrigado pelo retorno.

 

Numa máquina com o Proxy ativo, marquei a opção que você me orientou e retornou os 4 XMLS anexos:

 

7890176052858-cons-gtin.xml7890176052858-gtin-soap.xml7890176052858-gtin.xml7890176052858-cons-gtin-soap.xml

 

Aparentemente o serviço está respondendo OK, só o componente não retorna os dados dos XMLs de consulta quando informado o proxy.

 

Lembrando que em máquinas sem proxy ele retorna e exibe normalmente os dados dos XMLs retornados.

Obrigado desde já,

Angelo.

[Diego Foliene]

1 hora atrás, AngeloMique disse:

Bom dia Diego.

Obrigado pelo retorno.

 

Numa máquina com o Proxy ativo, marquei a opção que você me orientou e retornou os 4 XMLS anexos:

 

7890176052858-cons-gtin.xml 142 B · 0 downloads 7890176052858-gtin-soap.xml 749 B · 2 downloads 7890176052858-gtin.xml 440 B · 1 download 7890176052858-cons-gtin-soap.xml 472 B · 0 downloads

 

Aparentemente o serviço está respondendo OK, só o componente não retorna os dados dos XMLs de consulta quando informado o proxy.

 

Lembrando que em máquinas sem proxy ele retorna e exibe normalmente os dados dos XMLs retornados.

Obrigado desde já,

Angelo.

Apenas para confirmação, você configurou o proxy corretamente no componente certo?

[AngeloMique]

Boa tarde Diego.

 

Estou usando o aplicativo exemplo do ACBR ainda.

 

Existe uma rotina nele chamada ConfiguraComponente,  que é chamada em outra rotina chamada LerConfiguracao, executada no OnCreate do Form Principal, onde há os comandos:

 

 with ACBrGTIN1.Configuracoes.WebServices do
  begin
    UF         := cbUF.Text;
    Ambiente   := StrToTpAmb(Ok, IntToStr(rgTipoAmb.ItemIndex+1));
    Visualizar := cbxVisualizar.Checked;
    Salvar     := cbxSalvarSOAP.Checked;

    TimeOut   := seTimeOut.Value;
    ProxyHost := edtProxyHost.Text;
    ProxyPort := edtProxyPorta.Text;
    ProxyUser := edtProxyUser.Text;
    ProxyPass := edtProxySenha.Text;
  end;
 

Acredito que ele está passando correto, pois se não configuro o endereço e porta do Proxy na aplicação de exemplo, na máquina dá erro de timeout ao tentar consultar o WebService.

 

Alguma outra ideia?

[Renato Rubinho]

6 horas atrás, AngeloMique disse:

Aparentemente o serviço está respondendo OK, só o componente não retorna os dados dos XMLs de consulta quando informado o proxy.

Boa tarde,

Confirmando, esses xmls foram gerados:

* Com o programa de exemplo

* Com os campos de proxy preenchidos

* Foram salvas as configurações antes de consultar 

Confirmando as três condições acima, com base no XML de retorno, o proxy não é o problema pois a comunicação foi feita e os dados foram recebidos.

Aumente o timeout para 30k ou mais, pois a conexão pode estar sendo interrompida antes da finalização do processo e gerando a inconsciência ao alimentar os dados no componente.

Se tiver como debugar no ambiente com proxy, navegue com o F7 dentro dos métodos para ver onde está ocorrendo o erro que faz com que o componente não seja alimentado.

[AngeloMique]

Boa tarde Rubinho.

Obrigado pelo retorno. Todos os testes estão sendo feitos com a aplicação de exemplo e o campo proxy preenchido corretamente.

Aumentei o TimeOut para 30000 e parece que também não lê este parâmetro. É como se simplesmente o WebService não lesse nenhum parâmetro envolvendo o Proxy, inclusive o timeout. Muito esquisito. Além disso, numa máquina com proxy, mesmo retirando os parâmetros de proxy e porta, gravando as alterações, saindo da aplicação e voltando e testando, ele continua aparentemente tentando passar pelo proxy e retornado a tela com dados vazios, como se o webservice continuasse na memória parametrizado ou algo assim. Muito esquisito.

Vou ver se consigo um proxy e tento debugar a aplicação atrás dele.

Muito obrigado desde já.

 

 

 

[Renato Rubinho]

Boa tarde Angelo,

Veja com o suporte do TI, pois o proxy deve ter um log para você analisar o que está passando por ele.

37 minutos atrás, AngeloMique disse:

numa máquina com proxy, mesmo retirando os parâmetros de proxy e porta, gravando as alterações, saindo da aplicação e voltando e testando, ele continua aparentemente tentando passar pelo proxy e retornado a tela com dados vazios

Se a rede tem proxy e você não configura, provavelmente não irá funcionar, a menos que esteja liberada a internet mesmo sem o proxy, confirme isso para não bater cabeça.

23 horas atrás, Renato Rubinho disse:

com base no XML de retorno, o proxy não é o problema pois a comunicação foi feita e os dados foram recebidos.

Lembrando, a comunicação funcionou, pois trouxe o XML com os dados, mas não carregou no componente, isso é o que precisa tentar debugar.

40 minutos atrás, AngeloMique disse:

Aumentei o TimeOut para 30000

Ao chamar o método, retorna em menos de 30 segundos? Se retorna o problema não é timeout, se cai nos 30 segundos tem que aumentar mais.

[AngeloMique]

Bom  dia Rubinho.

Não chega a nem 5 segundos, mesmo aumentando para 1 minuto. Parece que o componente não está lendo vários parâmetros com o proxy habilitado.

 

Aliás, consulteis o log do proxy fornecido e está passando de boa. O problema é que aparentemente no retorno, o componente não está lendo os arquivos de retorno com o proxy habilitado.

[Diego Foliene]

54 minutos atrás, AngeloMique disse:

Bom  dia Rubinho.

Não chega a nem 5 segundos, mesmo aumentando para 1 minuto. Parece que o componente não está lendo vários parâmetros com o proxy habilitado.

 

Aliás, consulteis o log do proxy fornecido e está passando de boa. O problema é que aparentemente no retorno, o componente não está lendo os arquivos de retorno com o proxy habilitado.

Bom dia Angelo.
Conforme o @Renato Rubinho citou anteriormente, você consegue fazer o debug no programa exemplo?
Se sim, por favor faça um teste colocando um ponto de parada na function Executar da unit ACBrDFeWebService e na function TratarResposta da unit ACBrGTINWebServices.
 

[AngeloMique]

Ok Diego. Farei isso.

[Diego Foliene]

27 minutos atrás, AngeloMique disse:

Ok Diego. Farei isso.

Boa tarde!
Por favor, além do Debug, faça também mais um teste.
Tente consultar com a opção "Salvar envelope SOAP" da aba WebService marcada e anexe para nós os SOAPs da consulta com o Proxy e sem o Proxy para compararmos e ver se tem alguma diferença entre eles.
Anexe também o Log, por favor.(O componente tem um evento chamado OnGerarLog, veja no programa exemplo).
Busquei uma orientação com os responsáveis pelo componente e os mesmos me informaram que o GTIN usa a mesma base dos outros componentes de documento fiscal no que diz respeito as configurações de Proxy então deveria funcionar.
De possa de todas essas informações, temos mais base para fazer uma análise bem detalhada.

[AngeloMique]

Bom dia Diego.

 

Desculpe a demora.

 

Desde ontem à tarde, venho recebendo esses erros ao tentar consultar o GTIN, em ambiente sem proxy:

 

 

Pela manhã estava consultando tudo normal.  Por isso não tive condições de gerar o acima.

Será que são problemas na SEFAZ/RS? Hoje de manhã tentei novamente e mesmo erro.

Certificado OK, emitindo NF-e e NFC-e nesta máquina e em outras máquinas de desenvolvimento em ambiente de homologação do PR.

Seguem as telas de configuração da aplicação demo do ACBR:

 

 

[Diego Foliene]

19 minutos atrás, AngeloMique disse:

Bom dia Diego.

 

Desculpe a demora.

 

Desde ontem à tarde, venho recebendo esses erros ao tentar consultar o GTIN, em ambiente sem proxy:

 

 

Pela manhã estava consultando tudo normal.  Por isso não tive condições de gerar o acima.

Será que são problemas na SEFAZ/RS? Hoje de manhã tentei novamente e mesmo erro.

Certificado OK, emitindo NF-e e NFC-e nesta máquina e em outras máquinas de desenvolvimento em ambiente de homologação do PR.

Seguem as telas de configuração da aplicação demo do ACBR:

 

 

Bom dia!
Altere o SSLType na aba WebService para LT_TLSv1_2 e faça novos testes por favor.

[AngeloMique]

Oi Diego.

Deu certo.  Amanhã retomaremos os testes.

 

Obrigado.

 

[AngeloMique]

Boa tarde  Diego.

Esses arquivos foram gerados em uma máquina com proxy:

GTIN_COM_PROXY.zip

Estes arquivos foram gerados numa máquina sem proxy:

GTIN_SEMPROXY.zip

Nosso ambiente de testes:

1 - Compilamos a aplicação demo no Delphi 2010 com todos os patches de atualização e a última versão do ACBR trunk 2, baixado via SVN.

2 - Compilamos também a aplicação demo no Delphi 11 Alexandria com os patches instalados e a última versão do ACBR trunk 2 via SVN.

3 - Os schemas que utilizamos em todos os testes são os que vem junto com o ACBR trunk 2, baixados do SVN.

3 - Levamos 2 PCs de desenvolvimento para o ambiente de um cliente com Proxy.  Instalamos nelas, do zero, o  Windows 10, versão 22H2 64 bits com todas as atualizações; instalamos o certificado digital do cliente e o nosso (todos e-CNPJ A1, 1 da Certisign e outro do Serasa); instalamos todas as cadeias de certificados;

4 - Instalamos em cada uma dessas máquinas físicas 3 VMS para teste: a) 1 Windows 7 32 bits com todas as atualizações e updates possíveis; b) 1 Windows 8.1 64 bits com todas as atualizações e updates possíveis e c) 1 Windows Server 2012R2 64 bits com todas as atualizações e updates possíveis. Instalamos em todas elas também os certificados acima mencionados e as cadeias.

5 - Importante: Tais VMS já são utilizadas no nosso ambiente para testes dos nossos softwares, com NF-e, NFC-e e NFS-e. Em todas essas VMS, nossas aplicações  consultam, emitem, cancelam entre outras coisas os documentos fiscais mencionados sem nenhum problema, seja com o proxy habilitado, ou seja sem ele.

Porém, no ACBR GTIN, com o proxy, elas apresentam o erro :

 

6 - Conforme já mencionei, nas VMS acima os arquivos XML de consulta são retornados corretamente na pasta indicada no aplicativo de exemplo, mas com o proxy habilitado, o componente não mostra o retorno. No ambiente sem proxy, sim, mostra todas as informações.

7 - Agora o mais bizarro:

Nas máquinas físicas com o Windows 10 22H2, sem mesmo configurar o proxy nas opções da aplicação demo, ele faz e apresenta todas as consultas normalmente, seja com proxy, seja sem. E mesmo habilitando e informando o parâmetro do proxy no aplicativo demo, no Windows 10 22H2, o aplicativo demo retorna e apresenta normalmente  a consulta.

8 - Não satisfeitos, levamos a aplicação demo a uma máquina do cliente, com o Windows 10, mas a versão 1809, obviamente com o proxy habilitado. Deu o mesmo erro que acima, como nas VMS.

9 - Lembrando que em todos os casos, rodamos as aplicações compiladas no D2010 e no D11. Sempre os mesmos resultados, nos executáveis 2 aplicações demo.

10 - Instalamos  numa VM , do zero, o Windows 10 2H22. Mesmo procedimento de instalação e configuração das máquinas físicas. Nesta máquina, com e sem proxy habilitado, o ACBR GTIN retorna e apresenta corretamente os dados.

11 - Instalamos  numa VM , do zero, o Windows 11 2H22. Mesmo procedimento de instalação e configuração das máquinas físicas. Nesta máquina, com e sem proxy habilitado, o ACBR GTIN também retorna e apresenta corretamente os dados.

11 - Na nossa humilde opinião, parece que o componente, em ambientes mais antigos, tem dificuldade de carregar as informações do XML retornado pelo WebService de consulta da SEFAZ/RS. 

 Mais alguma sugestão? Estamos quase ao ponto de nestes clientes com proxy, ler na unha o XML retornado pelo demo.

Agradeço desde já a atenção e desculpem o texto muito longo.

Angelo.

[Diego Foliene]

1 hora atrás, AngeloMique disse:

Boa tarde  Diego.

Esses arquivos foram gerados em uma máquina com proxy:

GTIN_COM_PROXY.zip 1.72 kB · 0 downloads

Estes arquivos foram gerados numa máquina sem proxy:

GTIN_SEMPROXY.zip 1.72 kB · 0 downloads

Nosso ambiente de testes:

1 - Compilamos a aplicação demo no Delphi 2010 com todos os patches de atualização e a última versão do ACBR trunk 2, baixado via SVN.

2 - Compilamos também a aplicação demo no Delphi 11 Alexandria com os patches instalados e a última versão do ACBR trunk 2 via SVN.

3 - Os schemas que utilizamos em todos os testes são os que vem junto com o ACBR trunk 2, baixados do SVN.

3 - Levamos 2 PCs de desenvolvimento para o ambiente de um cliente com Proxy.  Instalamos nelas, do zero, o  Windows 10, versão 22H2 64 bits com todas as atualizações; instalamos o certificado digital do cliente e o nosso (todos e-CNPJ A1, 1 da Certisign e outro do Serasa); instalamos todas as cadeias de certificados;

4 - Instalamos em cada uma dessas máquinas físicas 3 VMS para teste: a) 1 Windows 7 32 bits com todas as atualizações e updates possíveis; b) 1 Windows 8.1 64 bits com todas as atualizações e updates possíveis e c) 1 Windows Server 2012R2 64 bits com todas as atualizações e updates possíveis. Instalamos em todas elas também os certificados acima mencionados e as cadeias.

5 - Importante: Tais VMS já são utilizadas no nosso ambiente para testes dos nossos softwares, com NF-e, NFC-e e NFS-e. Em todas essas VMS, nossas aplicações  consultam, emitem, cancelam entre outras coisas os documentos fiscais mencionados sem nenhum problema, seja com o proxy habilitado, ou seja sem ele.

Porém, no ACBR GTIN, com o proxy, elas apresentam o erro :

 

6 - Conforme já mencionei, nas VMS acima os arquivos XML de consulta são retornados corretamente na pasta indicada no aplicativo de exemplo, mas com o proxy habilitado, o componente não mostra o retorno. No ambiente sem proxy, sim, mostra todas as informações.

7 - Agora o mais bizarro:

Nas máquinas físicas com o Windows 10 22H2, sem mesmo configurar o proxy nas opções da aplicação demo, ele faz e apresenta todas as consultas normalmente, seja com proxy, seja sem. E mesmo habilitando e informando o parâmetro do proxy no aplicativo demo, no Windows 10 22H2, o aplicativo demo retorna e apresenta normalmente  a consulta.

8 - Não satisfeitos, levamos a aplicação demo a uma máquina do cliente, com o Windows 10, mas a versão 1809, obviamente com o proxy habilitado. Deu o mesmo erro que acima, como nas VMS.

9 - Lembrando que em todos os casos, rodamos as aplicações compiladas no D2010 e no D11. Sempre os mesmos resultados, nos executáveis 2 aplicações demo.

10 - Instalamos  numa VM , do zero, o Windows 10 2H22. Mesmo procedimento de instalação e configuração das máquinas físicas. Nesta máquina, com e sem proxy habilitado, o ACBR GTIN retorna e apresenta corretamente os dados.

11 - Instalamos  numa VM , do zero, o Windows 11 2H22. Mesmo procedimento de instalação e configuração das máquinas físicas. Nesta máquina, com e sem proxy habilitado, o ACBR GTIN também retorna e apresenta corretamente os dados.

11 - Na nossa humilde opinião, parece que o componente, em ambientes mais antigos, tem dificuldade de carregar as informações do XML retornado pelo WebService de consulta da SEFAZ/RS. 

 Mais alguma sugestão? Estamos quase ao ponto de nestes clientes com proxy, ler na unha o XML retornado pelo demo.

Agradeço desde já a atenção e desculpem o texto muito longo.

Angelo.

Boa tarde!
Muito obrigado pelo empenho e colaboração para buscar a causa do problema.
Criei a #TK-3195 para que o consultor responsável pelo componente possa analisar essa situação e dar um parecer.

[Victor H. Gonzales - Panda]

4 horas atrás, Diego Foliene disse:

Boa tarde!
Muito obrigado pelo empenho e colaboração para buscar a causa do problema.
Criei a #TK-3195 para que o consultor responsável pelo componente possa analisar essa situação e dar um parecer.

Boa tarde,

em debug ele levanta alguma exception em algum ponto?
pois o SOAP é o mesmo, não teria motivo para não leitura, não vejo um motivo explicito para não leitura visto que o xml foi retornado e o SOAP são identicos.

 

Rodaram em debug onde tem o problema apresentado, onde a exceção ocorre especificamente?

[AngeloMique]

Boa tarde Diego.

Obrigado pelo retorno.

O problema é que nosso ambiente de desenvolvimento está todo em Windows 10 2H22. Mas debugamos mesmo assim e não levanta nenhum AV e nenhuma Exception, tanto sem quanto com proxy. Tudo roda normal no D2010 e no D11.

 

Pelo visto vamos ter de debugar com o D2010 num Windows 7... Aiiii... 

 

Angelo.

 

 

[Victor H. Gonzales - Panda]

21 minutos atrás, AngeloMique disse:

Boa tarde Diego.

Obrigado pelo retorno.

O problema é que nosso ambiente de desenvolvimento está todo em Windows 10 2H22. Mas debugamos mesmo assim e não levanta nenhum AV e nenhuma Exception, tanto sem quanto com proxy. Tudo roda normal no D2010 e no D11.

 

Pelo visto vamos ter de debugar com o D2010 num Windows 7... Aiiii... 

 

Angelo.

 

 

Boa tarde,

Conforme as evidências abaixo, não foi detectado nenhuma inconformidade, usando ou não servidores de proxy, sugiro subir um PAServer e efetuar um remote debug, pode ser algo na aplicação. se conseguir detectar algo, nos avise por favor.

 

[AngeloMique]

Bom dia Victor.

Obrigado pelo retorno.

Percebi que vc debugou em uma versão 10 ou superior do Delphi. Em qual Windows vc efetuou a depuração?

Conforme apontamos, o problema parece acontecer nos Windows inferiores ao 10 22H2. O problema ocorre com as versões do Windows inferiores ao 10 22H2, com proxy habilitado. Toda essa depuração que vc fez nós fizemos, só que no Windows 10 22H2, tanto com o D2010 qto com o D11. Também não detectamos qualquer problema em cima dessa versão do Windows, com ou sem proxy habilitado. Já usamos também um PAServer. Sem sucesso. Testamos  atrás de um servidor proxy Linux do cliente conforme acima já mencionado. Sem sucesso. No Windows 10 22H2, o componente se comporta perfeitamente, com proxy ou sem, nestes ambientes.

A situação acima relatada acontece desde o Windows 7 32 até o Windows 10 versão 1809, com proxy habilitado. Sem proxy, vai de boa. Não temos Delphi instalado em versões inferiores ao Windows 10 22H2, por isso não tivemos condições de debugar nestes ambientes.

Lembrando que a aplicação que testamos é o demo que vem nos fontes do ACBR, sem mudar uma única linha de código.

Angelo.

[AngeloMique]

Bom dia.

Como não conseguimos achar a possível falha, não tomaremos mais o tempo de ninguém aqui.

Como o componente retorna o XML correto, muito embora não o exiba nas situações acima, vamos utilizá-lo mesmo assim lendo o XML que ele retorna correto manualmente, nos ambientes com proxy.

Senhor moderador, favor encerrar o tópico. Agradeço a todos pela ajuda, pela atenção e pelo esforço.

 

Angelo.

[Juliomar Marchetti]

vai mais uma sugestão use um ferramenta que loga o trafego http e https desses windows com proxy.

assim também pode ser possível identificar