cancel
Showing results for 
Search instead for 
Did you mean: 

SCAN não retorna status do serviço

Former Member
0 Kudos

Bom dia,

Desde 14/08/2011 às 08:05:56 o nosso tipo de emissão SCAN não está retornando STATUS de ativo, e também não é realizada a consulta do status do mesmo.

Dei uma olhada no GRC/PI/Java/ECC... e aparentemente está tudo ok

Quando o SCAN parou pela primeira vez, deu o seguinte erro:

PARSE_APPLICATION_DATA Error during XML => ABAP conversion: Response Message; CX_ST_MATCH_ELEMENT in /1SAI/TXS2731B33DE5F5A8813C20 Line 268 Elem.'nfeStatusServicoNFResponse2' esperado

Pesquisando sobre o erro, achamos 2 trheads:

http://forums.sdn.sap.com/click.jspa?searchID=73768752&messageID=10193658

http://forums.sdn.sap.com/click.jspa?searchID=73768752&messageID=10151927

Elas sugerem a aplicação das notas abaixo:

1501345 - Xi runtime: Manifest

1522630 - Xi runtime: Payload ignored due to parsing error

1162160 - CX_ST_MATCH_ELEMENT in XML Inbound processeing

Inclusive um dos usuários comenta que após aplicada a 1522630 o problema foi resolvido... (Mas não sei se isso irá funcionar)

Outro check que realizei foi do erro retornado no status do serviço do SCAN agora, e o GRC retorna o seguinte erro:

MAPPING.JCO_COMMUNICATION_FAILURE "COMMUNICATION FAILURE" during JCo call. Error when opening an RFC connection

Pesquisando sobre o erro, encontrei algumas sugestões:

1) Alguns sugerem a exclusão da conexão RFC AI_RUNTIME_JCOSERVER para TCP/IP (SM59) no GRC e criar novamente... mas não sei se isso iria funcionar...

2) Em outras pesquisas, alguns falam que a Conexão entre ABAP e JAVA foi quebrada... isso é a razão para o erro JCO_COMMUNICATION... e a sugestão é reiniciar o Java...

3) Em outra pesquisa: Quando há muitas mensagens a serem processadas simultaneamente. O número padrão de processos paralelos em VisualAdmin -> JCO Provider RFC -> AI_RUNTIME_) e ver se isso ajuda.

Obs.: À alguns dias, tivemos um problema que ocorreu com a SEFAZ-GO, a mesma colocou nossa faixa de IP's em uma Blacklist (ainda não sabemos porque) e daí ela nos retornava que estava "fora do ar". Será que poderia ser isso? Como posso checar isso?

O nosso S.P. é o:

SLL-NFE 100 0018 SAPK-10018INSLLNFE xNFE 1.0

Alguém poderia nos auxiliar? Pois isso não gera impacto em nossos processos desde que a SEFAZ (GO/PR/SP/MT) não fique inativa, pois caso isso ocorra o nosso processo de emissão de NF-e em SCAN não irá funcionar e a emissão de NF-e irá parar.

Qualquer dúvida estou à disposição.

Edited by: MATEUS PARREIRA GUIMARÃES on Sep 1, 2011 7:12 PM

Edited by: Fernando Ros on Sep 2, 2011 10:24 PM - trocado code por quote para melhor visualizaçã

Accepted Solutions (0)

Answers (3)

Answers (3)

Former Member
0 Kudos

Só para acrescentar uma pergunta:

Mesmo a SEFAZ de origem (GO/MT/PR/SP/etc...) estando ativa no monitor, o STATUS do SCAN também deve aparece no monitor como "ATIVO"?

Obrigado.

henrique_pinto
Active Contributor
0 Kudos

Mateus,

não há problema os 2 aparecerem como ativos - desde que o ERP esteja corretamente numerando com o tpEmis = 1 (i.e. normal).

Vc ainda está com o problema mencionado no início?

Se sim, recomendo abrir chamado no SLL-NFE para análise.

Abs,

Henrique.

former_member182114
Active Contributor
0 Kudos

Bom dia Mateus,

Normalmente informação sobre o problema sempre é bom, mas nesta sua mensagem tá parecendo que vários erros foram pegos, mas não sei se todos estão relacionados ao mesmo problema.

HTTP 403 Forbidden ---> pode ser certificado ou pode ser apenas falha na comunicação abaixo

JCO_SYSTEM_FAILURE ---> O java caiu? Tem mais de um nó, ou load balance?

A falha na deserialização pode ocorrer se chegar um payload não esperado. Ex.: Erro de proxy ou HTTP 403 manda uma mensagem do proxy, que não é a resposta padrão do SOAP.

Mesmo a SEFAZ de origem (GO/MT/PR/SP/etc...) estando ativa no monitor, o STATUS do SCAN também deve aparece no monitor como "ATIVO"?

O funcionamento atual é assim:

- verifica-se a Sefaz Origem sempre

- verifica-se o SCAN quando:

1) se a consulta na Sefaz origem der erro ou diferente de 107 (recebendo normalmente) E TAMBÉM o flag do customizing de configuração de status de serviço para esta Sefaz diz Checar SCAN em caso de erro

2) se o SCAN estava sendo consultado anteriormente, então será consultado SEMPRE enquanto estiver recebendo um 107 ou 113 (se der um erro ou se receber resposta diferente do 107/113 então para de consultar)

Atualmente a forma que se tem para "ativar" a consulta ao SCAN é colocar no communication channel da Sefaz Origem (interface SRVSC) uma URL falsa, para produzir o tal erro de consulta na Sefaz de origem (caso 1)

Se a idéia for apenas um teste, pode rodar a função /XNFE/006_SRV_STATUS_OUT com os parms:

IV_CUF = 35 (35=São Paulo, por exemplo)

IV_TPAMB = 1 (1=Produção, 2=Homologação)

IV_TPEMIS = 3 (1=Normal, 3=SCAN)

IV_VERSION = 2.00

Atenciosamente, Fernando Da Ró

Former Member
0 Kudos

Olá Fernando.

Primeiramente, obrigado pelo retorno, quanto ao ponto destacado por você abaixo:

A falha na deserialização pode ocorrer se chegar um payload não esperado. Ex.: Erro de proxy ou HTTP 403 manda uma mensagem do proxy, que não é a resposta padrão do SOAP

No dia 14/08/11 o SCAN de São Paulo estava ativo e por volta das 17 horas houve o primeiro erro:

PARSE_APPLICATION_DATA Error during XML => ABAP conversion: Response Message; CX_ST_MATCH_ELEMENT in /1SAI/TXS2731B33DE5F5A8813C20 Line 268 Elem.'nfeStatusServicoNFResponse2' esperado

que me parece causado por uma recepção de mensagem fora do padrão esperado, e logo em seguida os erros de JCO_COMMUNICATION_FAILURE começaram para as consultas subsequentes.

Outro ponto que achei interessante na postagem do Pamplona foi:

<SAP:Stack>"SYSTEM FAILURE" during JCo call. Bean SMPP_CALL_JAVA_RUNTIME3 not found on host srvprdgrc, ProgId=AI_RUNTIME_GRP:</SAP:Stack>

isso pode causado por uma falha no JRE do servidor?

o que você sugere que poderíamos fazer para correção? reiniciar o servidor para tentar reestabelecer o ambiente?

Outro ponto que gostaria de lhe falar, é um exemplo do que aconteceu:

Quando consulto na J1BNFE as notas emitidas em SCAN à partir de 14/08/2011, não encontro nenhuma, isso poderia normalmente ocorrer caso nenhuma das SEFAZ (GO/MT/PR/SP) parassem, porém, quando realizo uma consulta no monitor do GRC, o mesmo me informa que a SEFAZ "caiu" várias vezes desta data pra cá... teoricamente o SCAN deveria ter funcionado, porém ele não funcionou e todas as vezes que era consultado o status do serviço, o mesmo retornava que o SCAN estava fora...

Aguardo retorno.

Novamente agradeço,

Mateus.

Edited by: Fernando Ros on Sep 2, 2011 10:25 PM - trocado code por quote para melhor visualizaçã

former_member182114
Active Contributor
0 Kudos

Bom dia Mateus,

Como disse, a mensagem tá com muita "coisa" junto...

O erro de parsing, aconteceu provavelmente por um erro de comunicação, proxy ou qualquer outra issue no servidor (seu ou da Sefaz) que enviou um texto que não o XML no layout previsto da resposta.

Se o serviço estava funcionando, parou por 1 tempo e voltou a funcionar normalmente, então com certeza também é algo temporário. As notas citadas corrigem uma situação de 100% em erro.

JCO_COMMUNICATION_FAILURE e SMPP_CALL_JAVA_RUNTIME3 podem acontecer "naturalmente" sem representar ERRO em qualquer sistema PI quando, por exemplo, durante um reboot da instância Java as interfaces continuam sendo chamadas.

isso pode causado por uma falha no JRE do servidor?

Não

o que você sugere que poderíamos fazer para correção? reiniciar o servidor para tentar reestabelecer o ambiente?

Às vezes reiniciar pode resolver mas irá acobertar as evidências, melhor continuar investigado. Se o negócio apertar pode ser o caso de abir um chamado à SAP.

Quando consulto na J1BNFE as notas emitidas em SCAN à partir de 14/08/2011, não encontro nenhuma, isso poderia normalmente ocorrer caso nenhuma das SEFAZ (GO/MT/PR/SP) parassem, porém, quando realizo uma consulta no monitor do GRC, o mesmo me informa que a SEFAZ "caiu" várias vezes desta data pra cá... teoricamente o SCAN deveria ter funcionado, porém ele não funcionou e todas as vezes que era consultado o status do serviço, o mesmo retornava que o SCAN estava fora...

Se a Sefaz caiu e o customizing diz para checar o SCAN, então você deveria encontrar informações sim do SCAN. Verificando seu sistema, vi que algumas destas informações foram manualmente deletadas.

Atenciosamente, Fernando Da Ró

Former Member
0 Kudos

OK Fernando,

Obrigado pelo apoio.

Vamos monitorar e verificar se está realmente ok ou se não é um problema com a SEFAZ.

Cordialmente,

Mateus.

Former Member
0 Kudos

Boa tarde!

Pessoal em nosso ambiente as mensagens do SCAN que chamam a atenção:

1 -

<SAP:Error xmlns:SAP="http://sap.com/xi/XI/Message/30" xmlns:SOAP="http://schemas.xmlsoap.org/soap/envelope/" SOAP:mustUnderstand="1">

<SAP:Category>XIAdapterFramework</SAP:Category>

<SAP:Code area="MESSAGE">GENERAL</SAP:Code>

<SAP:P1 />

<SAP:P2 />

<SAP:P3 />

<SAP:P4 />

<SAP:AdditionalText>com.sap.aii.af.ra.ms.api.DeliveryException: SOAP: response message contains an error XIAdapter/HTTP/ADAPTER.HTTP_EXCEPTION - HTTP 403 Forbidden</SAP:AdditionalText>

<SAP:ApplicationFaultMessage namespace="" />

<SAP:Stack />

<SAP:Retry>M</SAP:Retry>

</SAP:Error>

2 -

<SAP:Category>XIServer</SAP:Category>

<SAP:Code area="MAPPING">JCO_SYSTEM_FAILURE</SAP:Code>

<SAP:P1>Bean SMPP_CALL_JAVA_RUNTIME3 not found on host srvprdgrc, ProgId=AI_RUNTIME_GRP:</SAP:P1>

<SAP:P2 />

<SAP:P3 />

<SAP:P4 />

<SAP:AdditionalText />

<SAP:ApplicationFaultMessage namespace="" />

<SAP:Stack>&quot;SYSTEM FAILURE&quot; during JCo call. Bean SMPP_CALL_JAVA_RUNTIME3 not found on host srvprdgrc, ProgId=AI_RUNTIME_GRP:</SAP:Stack>

<SAP:Retry>M</SAP:Retry>

</SAP:Error>

Att.

Pamplona

Former Member
0 Kudos

Boa tarde a todos!

Pessoal incluindo mais informações as já enviadas pelo Mateus; quando fazemos um check pela SXI_monitor esta

retornando sempre o mesmo retorno:

Qualquer dica ou nota agradecemos,

Pamplona

CENTRAL

<?xml version="1.0" encoding="UTF-8" standalone="yes" ?>

- <!-- Inbound Message

-->

- <SOAP:Envelope xmlns:SOAP="http://schemas.xmlsoap.org/soap/envelope/" xmlns:SAP="http://sap.com/xi/XI/Message/30">

- <SOAP:Header>

- <SAP:Main xmlns:SAP="http://sap.com/xi/XI/Message/30" xmlns:SOAP="http://schemas.xmlsoap.org/soap/envelope/" xmlns:wsu="http://www.docs.oasis-open.org/wss/2004/01/oasis-200401-wss-wssecurity-utility-1.0.xsd" versionMajor="003" versionMinor="000" SOAP:mustUnderstand="1" wsu:Id="wsuid-main-92ABE13F5C59AB7FE10000000A1551F7">

<SAP:MessageClass>SystemError</SAP:MessageClass>

<SAP:ProcessingMode>synchronous</SAP:ProcessingMode>

<SAP:MessageId>8AB8CC05-D44B-11E0-8D74-000000729692</SAP:MessageId>

<SAP:RefToMessageId>E0D44B74-1BE5-7BF1-975B-0024E8437829</SAP:RefToMessageId>

<SAP:TimeSent>2011-09-01T03:36:13Z</SAP:TimeSent>

- <SAP:Sender>

<SAP:Party agency="http://sap.com/xi/XI" scheme="XIParty">SEFAZ_2_SCAN</SAP:Party>

<SAP:Service>Producao</SAP:Service>

<SAP:Interface namespace="http://sap.com/xi/NFE/006">SRVSC_nfeStatusServicoNFSoapIn_SYNC_IB</SAP:Interface>

</SAP:Sender>

- <SAP:Receiver>

<SAP:Party agency="http://sap.com/xi/XI" scheme="XIParty" />

<SAP:Service>GRPCLNT200</SAP:Service>

<SAP:Interface namespace="http://sap.com/xi/NFE/006">SRVSC_nfeStatusServicoNF_SYNC_OB</SAP:Interface>

</SAP:Receiver>

<SAP:Interface namespace="http://sap.com/xi/NFE/006">SRVSC_nfeStatusServicoNFSoapIn_SYNC_IB</SAP:Interface>

</SAP:Main>

- <SAP:ReliableMessaging xmlns:SAP="http://sap.com/xi/XI/Message/30" xmlns:SOAP="http://schemas.xmlsoap.org/soap/envelope/" SystemErrorAckRequested="true" SOAP:mustUnderstand="1">

<SAP:QualityOfService>BestEffort</SAP:QualityOfService>

</SAP:ReliableMessaging>

- <SAP:Error xmlns:SAP="http://sap.com/xi/XI/Message/30" xmlns:SOAP="http://schemas.xmlsoap.org/soap/envelope/" SOAP:mustUnderstand="1">

<SAP:Category>XIAdapterFramework</SAP:Category>

<SAP:Code area="MESSAGE">GENERAL</SAP:Code>

<SAP:P1 />

<SAP:P2 />

<SAP:P3 />

<SAP:P4 />

<SAP:AdditionalText>com.sap.aii.af.ra.ms.api.DeliveryException: SOAP: response message contains an error XIAdapter/HTTP/ADAPTER.HTTPEXCEPTION - HTTP 403 Forbidden----

-


----

-