Erro no cenário SIGNN_SignNFe_OB - No implementing class registered

[RafaelVieira]

Bom dia,

Estou vendo erros no envio de NF-e, quando ela passa para o cenário de assinatura digital (SIGNN_SignNFe_OB).

Vejo no monitor GRC que as notas ficam no status 02 - Enviado ao serviço de assinatura digital.

WASSTAT = 02.

No monitor PI, vejo 2 registros para cada tentativa de execução, um com bandeira quadriculada no Sender e o Receiver com bandeira vermelha, ambos mostrando o mesmo erro:

<?xml version="1.0" encoding="UTF-8" standalone="yes" ?> 
- <!--  Call Inbound Proxy 
  --> 
- <SAP:Error xmlns:SAP="http://sap.com/xi/XI/Message/30" xmlns:SOAP="http://schemas.xmlsoap.org/soap/envelope/" SOAP:mustUnderstand="">
  <SAP:Category>XIProxy</SAP:Category> 
  <SAP:Code area="ABAP">INTERFACE_REGISTRATION_ERROR</SAP:Code> 
  <SAP:P1>ifmmessif</SAP:P1> 
  <SAP:P2>SIGNN_SignNFe_OB</SAP:P2> 
  <SAP:P3><a href="http://sap.com/xi/NFE/006" TARGET="test_blank">http://sap.com/xi/NFE/006</a></SAP:P3> 
  <SAP:P4></SAP:P4> 
  <SAP:AdditionalText></SAP:AdditionalText> 
  <SAP:ApplicationFaultMessage namespace=""></SAP:ApplicationFaultMessage> 
  <SAP:Stack>No implementing class registered for the interface (ABAP interface, request message SIGNN_SignNFe_OB, request message, namespace <a href="http://sap.com/xi/NFE/006)" TARGET="test_blank">http://sap.com/xi/NFE/006)</a></SAP:Stack> 
  <SAP:Retry>M</SAP:Retry> 
  </SAP:Error>

Encontrei algumas threads com mensagens de erro semelhante, mas em cenários diferentes.

-> SXMB_ADM

- PI

Role = Integ. Server

Corresp. IS = dest://INTEGRATIONSERVER_SYS

Engine Type = HUB

- GRC

Role = App System

Corresp. IS = dest://INTEGRATIONSERVER_SYS

Engine Type = LOC

Destination INTEGRATIONSERVER_SYS in SM59:

Target Host =

Service No. = 8011

Path Prefix = /sap/xi/engine?type=entry

Alguém sabe onde mais eu posso verificar pra solucionar isso?

Muito obrigado,

Rafael Vieira.

[henrique_pinto]

Se vc entra na SPROXY, no client GRC e PI, vc consegue ver com sucesso as interfaces do Integration Repository?

E a execucao da SLDCHECK, termina com sucesso (também, em ambos os clientes)?

Abs,

Henrique.

[RafaelVieira]

Fala Henrique, valeu pela ajuda.

SLDCHECK roda com sucesso nos 2 clients.

SPROXY no GRC mostra todas as interfaces com luz verde, tudo certinho.

[henrique_pinto]

O XI Content da 006 está presente no Integration Repository?

Ainda, o HTTP Destination do PI que aponta pro GRC está ok? Vc só falou da Destination que aponta pro PI (alias, verifica o client no logon details pra ver se aponta pro PI mesmo).

Abs,

Henrique.

[RafaelVieira · Accepted solution]

O XI Content está ok, importado no ESR.

Caso não tivesse corretamente importado, iria refletir na SPROXY, faltando os Proxies, etc.

Quanto a HTTP destination, acredito que esta é a única HTTP que existe para a comunicação GRC - PI, não?

Só tenho definida está destination tipo H para esta integração.

Criada no GRC, apontando para o PI.

Esta destination, inclusive, é a mesma utilizada na SXMB_ADM do PI e também do GRC (em Corresponding Integ. Server) dest://INTEGRATIONSERVER_SYS.

Apenas tinha feito confusão quanto ao client desta destination, que estava configurada para o client do PI (200), e achei que devería alterar para 205 (GRC). Mas na verdade, esta destination é justamente a que aponta para o PI, e deve ser client 200 mesmo.

Outra coisa, é que o usuário definido na aba Logon & Security é um usuário criado sob o tipo System. Vi num material NF-e que esta HTTP destination é criada com o PIAPPLUSER, que um usuário de serviço. Vou alterar isso, mas não acredito que seja a solução do problema.

Edited by: rvsilvax on Feb 2, 2011 4:29 PM

[henrique_pinto · Accepted solution]

De fato, se nao tivesse importado, vc nao iria ver as interfaces 006 na SPROXY, mas vc nunca havia dito que as tinha visto lá (apenas que as que estavam lá estavam verdes).

Nao é a causa do seu problema, mas no retorno do PI pro GRC, vc tb vai ter uma comunicacao HTTP, através do canal de comunicacao XI Receiver que vc configura no Integration Directory. Esse canal pode conter diretamente os dados de conexao do Integration Engine do GRC, OU vc pode criar uma HTTP Destination no PI que aponta pro GRC e usar essa http destination no comm channel.

Abs,

Henrique.

[RafaelVieira]

Ok Henrique, sobre os proxies, disse que estava tudo certo, ou seja, Service Interfaces do XI Component gerando cada um o seu proxy correspondente na SPROXY do GRC e com luz verde para todos. Então este ponto está ok.

Vou revisar esta questão da destination H e fazer a substituição, pois de fato o canal proxy receiver está errado (está usando a mesma destination que citei acima, e que está apontando para o próprio XI).

Para a criação desta HTTP destination, que deve ser apontada do PI para o GRC, qual seria (ou onde posso obter esta informação) a Path Prefix? No caso da HTTP Destination do GRC para o PI, usamos /sap/xi/engine?type=entry

Nesta nova, qual sería este prefixo?

Como esta rodando em um mesmo servidor, apenas em clients diferentes, Target Host e Service No permanecem iguais, certo?

Muito obrigado,

Rafael.

[henrique_pinto]

Oi Rafael,

é o mesmo path prefix, pois vc está apontando para o Integration Engine do GRC.

O que vai mudar é o client (e, portanto, o usuario), pois no caso apontará para o client GRC e nao para o client PI.

Abs,

Henrique.

[henrique_pinto]

E só pra ter certeza:

a SLDCHECK terminou de fato com sucesso? Digo, nao só foi executada, como todas as funcoes dentro dela terminaram com sucesso (linhas verdes)? Nao basta ter aberto o SLD.

Outra maneira de verificar é ir direto nas RFC Destinations SAPSLDAPI e LCRSAPRFC e ver se ambas estao ok.

Veja também o seguinte checklist:

Check List for Setting Up a Connection to the Service Repository
1. The address of the Enterprise Services Repository must be known in the SAP system 
Check with report SPROX_CHECK_IFR_ADDRESS
The address is taken from the following parameters in the exchange profile ('Connections' section):
com.sap.aii.connect.repository.name: Server (for example,pwdf0436)
com.sap.aii.connect.repository.httpport: Port (for example, 1080)
com.sap.aii.connect.repository.contextroot: Root (for example,rep)
The logon data is also read from the exchange profile ('ApplicationSystem' section):
com.sap.aii.applicationsystem.serviceuser.name: User
com.sap.aii.applicationsystem.serviceuser.pwd: Password
As an alternative to using the exchange profile, you can maintain the RFC destination SAP_PROXY_ESR. If this RFC destination is maintained it will be used by the proxy generation in place of data from the exchange profile to access the Service Repository. In this case, the Exchange Profile will even not be read.
The RFC destination has to be set up using transaction SM59 and should look like this:
RFC Destination: SAP_PROXY_ESR
Connection Type: G (HTTP Connection to External Serv)
Description1: ESR for Proxy Generation
Target Host: esr_host
Service No: 1080
Path Prefix: rep
Logon and Security:
Basic Authentication: active
User: esr_user
Password: esr_password
2. The HTTP Framework of the Web Application Server must function
Check with report SPROX_CHECK_HTTP_COMMUNICATION
If necessary, contact your system administrator. Please be aware of the fact, that the HTTP framework is depending on the application server. Thus the result of the report may differ for different application servers.
3. Proxy generation must interpret the data of the Enterprise Services Repository

Abs,

Henrique.

[RafaelVieira]

Resultados dos testes do checklist:

1 - SPROX_CHECK_IFR_ADDRESS - Status = OK: Address maintained

2 - SPROX_CHECK_HTTP_COMMUNICATION - "HTTP communication functioning"

Criei a HTTP Dest. do PI para o GRC e alterei o CC proxy receiver do GRC utilizando esta destination.

Também revisei os usuários PIAPPLUSER e WF-BATCH, que faltavam associar algumas roles:

/XNFE/PRXYSERV

/XNFE/RFCSERV

/XNFE/TAXNUMBER

/XNFE/USERMENU

SAP_XI_APPL_SERV_USER.

As notas continuam paradas no monitor GRC com status process. 02 = Enviado ao serviço de assinatura digital.

No monitor PI, cada nota gera 2 registros, ambos ficam com bandeira quadriculada.

Na coluna Ack Status fica com o interrogação verde ("Still awaiting acknowledgement").

Na coluna Outbound Status (no primeiro registro) fica uma bandeira verde ("Message Scheduled on outbound side").

Na coluna Technical Outbound Channel, fica o valor PE. Quando clico nele, me mostra a fila XBQO$PE_WS90100005 e Destination WORKFLOW_LOCAL_200.

Duplo click no nome da fila e aparecem mais detalhes desta fila, com o valor SYSFAIL na coluna Status.

Duplo click em SYSFAIL, e um pop up exibe o erro "Password logon no longer possible - too many failed attempts".

Verifiquei o usuário da destination WORKFLOW_LOCAL_200 (WF-BATCH) mas ele não está bloqueado.

Alguém sabe onde mais eu posso verificar para corrigir este erro e fazer as notas serem assinadas e continuar o processo?

Muito obrigado pela força.

[henrique_pinto]

Essa destination WORKFLOW_LOCAL_200 aponta pro proprio client do PI?

Se nao, vc verificou se o WF-BATCH está bloqueado nesse outro client?

Abs,

Henrique.

[RafaelVieira]

Obrigado pela ajuda Henrique!

Esta destination aponta para o próprio PI.

Na aba de Administração da destination, mostra que ela foi criada no próprio PI, e em Logon & Security, aponta para o client 200 (o PI).

Não faço muita idéia do porquê da criação/utilização desta destination que o pessoal de basis criou.

Quanto ao usuário, ele está com status Saved nos 2 clients.

[henrique_pinto]

Em geral se usa isso pq em ambientes de alta disponibilidade, vc poderia jogar o processamento de workflow pra um outro application server dedicado (indicado pela Destination), para nao impactar o processamento dos app server que estao em load balance processando request de interface.

Dá uma olhada na SMQR, se vc tem alguma fila de BPM registrada (XBPE_WS*) e vê se ela usa destination.

Abs,

Henrique.

[henrique_pinto]

Ops, agora q vi q o erro era na fila XBQO* e nao na XBPE*.

Troque XBPE_WS* por XBQO$PE_WS* no que eu falei acima.

Dê uma lida: http://help.sap.com/saphelp_nw70/helpdata/en/45/1a97be109921a0e10000000a1553f6/frameset.htm

Tentou rodar a SWF_XI_CUSTOMIZING?

Abs,

Henrique.

[RafaelVieira]

Henrique,

na SMQR não tem nada em XBQO*. Na coluna Destination with LOGON Data está vazia.

Já na SMQ1 (Outbound) tem aquele registro, conforme comentei ateriormente, que marca o erro de sistema.

Verifiquei a SWF_XI_CUSTOMIZING e já estavam com algumas verificações já feitas:

Maintain Runtime Environment

- Maintain Workflow System Administrator

- Maintain Active Plan Version

- Maintain Time Units

- Schedule Background Job for Event Queue

- Schedule background job for clearing report

- Set Up Workflow Runtime

Maintain Definition Environment

All checked

Ainda assim, mandei processar e retornou Customizing Already Carried Out.

[henrique_pinto]

As filas XBQO nao estao registradas?

Nem XBQ* ?

Cara, tudo indica q é problema no WF-BATCH...

Abra um chamado no componente BC-XI pro pessoal analisar.

Abs,

Henrique.

[RafaelVieira]

Muito obrigado pela ajuda Henrique.

Tentei eliminar o registro de erro na SMQ1 (Password logon no longer possible - too many failed attempts) e enviar novamente uma NF.

Gerou novamente o mesmo erro.

Cl. Queue Name               Destination                      Entries    Status   Date 1     Time 1   NxtDate    NxtTim   Wait for queue

200 XBQO$PE_WS90100005       WORKFLOW_LOCAL_200                       6  SYSFAIL  11.02.2011 13:19:31 11.02.2011 13:42:16

Só não sei exatamente se este erro está apontando problemas com o WF-BATCH ou com algum outro usuário.

Como eu podería garantir isso ?

Na linha de erro exibida na SMQ1 (acima), quando clico 2x na fila que aponta SYSFAIL, são exibidos os seguintes campos/valores:

Cl.  User         Function Module                 Queue Name                Destination                       Date        Time      Status

200  PIAPPLUSER   SWF_XI_MSG_RAISE_EVENT          XBQO$PE_WS90100005        WORKFLOW_LOCAL_200                11.02.2011  13:19:31  Password logon no longer possible - too many faile

-

-

---

E todos os registros subsequentes aparecem como:

200  PIAPPLUSER   SWF_XI_MSG_RAISE_EVENT          XBQO$PE_WS90100005        WORKFLOW_LOCAL_200                11.02.2011  13:21:59  Transaction recorded

Na linha de erro (1a linha), 2x click sobre a destination, me mostra a WORKFLOW_LOCAL_200 (Logon & Security - Client 200(PI) / User WF-BATCH / PW Status saved).

[RafaelVieira]

Desculpe, esqueci de adicionar que, uma vez que o registro foi excluído da fila, e uma nova NF foi enviada, vejo os seguintes 4 registros na SXMB_MONI:

	Sender Service		Sender Interface		Status
1	SIGNN_SignNFeProcess	SIGNN_SignNFe_SYNC		System 	Error(Restart Not Possible)
2	BS_BPD_JAVA		SIGNN_signIn_doc_SYNC_IB	Log Version
3	BS_GRC_205		SIGNN_SignNFe_OB		Success (Still awaiting ack)
4	BS_GRC_205		SIGNN_SignNFe_OB		Success (Still awaiting ack)

Os 2 primeiros terminam com luz vermelha e Log version (a bolinha vazia). Dentro da mensagem, o seguinte erro:

  <SAP:Category>XIAdapterFramework</SAP:Category> 
  <SAP:Code area="MESSAGE">GENERAL</SAP:Code> 
  <SAP:P1></SAP:P1> 
  <SAP:P2></SAP:P2> 
  <SAP:P3></SAP:P3> 
  <SAP:P4></SAP:P4> 
  <SAP:AdditionalText>com.sap.aii.af.ra.ms.api.DeliveryException: invalid content type for SOAP:
   TEXT/HTML; HTTP 401 Unauthorized</SAP:AdditionalText> 
  <SAP:ApplicationFaultMessage namespace=""></SAP:ApplicationFaultMessage> 

Att,

[henrique_pinto]

O PIAPPLUSER está lockado?

Abs,

Henrique.

[RafaelVieira]

PIAPPLUSER está normal.

Tentei a reconfiguração automática de WF pela transação SWF_AUTO e está resultando que RFC User tem um password incorreto e pergunta se desejo sincronizar os passwords.

WF-BATCH de fato está com problemas.

Passei estes detalhes para o basis. Problema é que a comunicação com os basis fica prejudicada por ter uma série de intermédios (equipe na Inglaterra).

Assim que tiver um retorno, posto aqui os resultados.

Muito obrigado pela ajuda so far...

Abraço!

[henrique_pinto]

Note que o fato de o PW estar saved na SM59 nao quer dizer q ele está correto.

Fazendo o teste de logon, funciona?

Abs,

Henrique.

[RafaelVieira]

Exatamente!

Este teste age mais como um ping, mas não evidencia o login com sucesso no sistema.

Vendo junto com a equipe de basis, foi necessário sincronizar os passwords do WF-BATCH, eles fizeram algum processo antes que alterou o password deste usuário.

Isso foi feito através da t-code SWF_Auto.

Agora as notas enviadas estão todas ficando com erro no monitor GRC:

Status 25 Assinatura digital NF-e: erro de aplicativo PI.

No monitor PI, vejo o seguinte erro:

<?xml version="1.0" encoding="UTF-8" standalone="yes" ?> 
- <!--  Response 
  --> 
- <SAP:Error xmlns:SAP="http://sap.com/xi/XI/Message/30" xmlns:SOAP="http://schemas.xmlsoap.org/soap/envelope/" SOAP:mustUnderstand="">
  <SAP:Category>XIAdapter</SAP:Category> 
  <SAP:Code area="BPE_ADAPTER">NEGATIVE_ACKNOWLEDGEMENT</SAP:Code> 
  <SAP:P1></SAP:P1> 
  <SAP:P2></SAP:P2> 
  <SAP:P3></SAP:P3> 
  <SAP:P4></SAP:P4> 
  <SAP:AdditionalText></SAP:AdditionalText> 
  <SAP:ApplicationFaultMessage namespace=""></SAP:ApplicationFaultMessage> 
  <SAP:Stack>Negative acknowledgment triggered by a process</SAP:Stack> 
  <SAP:Retry>M</SAP:Retry> 
  </SAP:Error>

Realizei um teste no webservice de assinatura digital conforme o Wiki https://wiki.sdn.sap.com/wiki/display/BPX/TestingtheNFEDigitalSignature+component.

e obtive sucesso na resposta (Successful XML Signature.).

Alguma sugestão?

Agradeço desde ja.

[henrique_pinto]

Agora aparentemente está executando o BPM, mas o mesmo falha por alguma razao.

Vc vê alguma mensagem a mais do processo SIGNN sendo gerada na SXI_MONITOR, ou só a mensagem de request de SIGNN mesmo?

Ainda, fazendo scroll pra direita, vá até as colunas inbound/outbound, e clique em 'PE', isso deve abrir o detalhe da instancia de BPM executada, e daí vc consegue mais detalhes do erro.

Abs,

Henrique.

[RafaelVieira]

Henrique,

aparentemente o BPM foi executado com sucesso.

Por favor, veja os prints abaixo:

http://img191.imageshack.us/img191/9850/pimonitor01.jpg

http://img191.imageshack.us/img191/9850/pimonitor01.jpg

Detalhes do processamento BPM

http://img529.imageshack.us/img529/5343/pimonitor05.jpg

Este abaixo é a parte do payload onde devería estar assinado:

(SIGNN_SignNFeProcess - Sender Service)

http://img689.imageshack.us/img689/9369/pimonitor04.jpg

[RafaelVieira]

Detalhe:

como da pra perceber, são gerados os 4 registros na SXMB_MONI:

http://img510.imageshack.us/img510/9608/pimonitor06.jpg

Os registros que mostram erro de Ack, tem a seguinte mensagem de erro:

  <?xml version="1.0" encoding="UTF-8" standalone="yes" ?> 
- <!--  Response 
  --> 
- <SAP:Error xmlns:SAP="http://sap.com/xi/XI/Message/30" xmlns:SOAP="http://schemas.xmlsoap.org/soap/envelope/" SOAP:mustUnderstand="">
  <SAP:Category>XIAdapter</SAP:Category> 
  <SAP:Code area="BPE_ADAPTER">NEGATIVE_ACKNOWLEDGEMENT</SAP:Code> 
  <SAP:P1></SAP:P1> 
  <SAP:P2></SAP:P2> 
  <SAP:P3></SAP:P3> 
  <SAP:P4></SAP:P4> 
  <SAP:AdditionalText></SAP:AdditionalText> 
  <SAP:ApplicationFaultMessage namespace=""></SAP:ApplicationFaultMessage> 
  <SAP:Stack>Negative acknowledgment triggered by a process</SAP:Stack> 
  <SAP:Retry>M</SAP:Retry> 
  </SAP:Error>

Já no último registro (que está sem bandeira de sucesso e nem erro), vejo a seguinte mensagem de erro:

  <?xml version="1.0" encoding="UTF-8" standalone="yes" ?> 
- <!--  Inbound Message 
  --> 
- <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:P1> 
  <SAP:P2></SAP:P2> 
  <SAP:P3></SAP:P3> 
  <SAP:P4></SAP:P4> 
  <SAP:AdditionalText>com.sap.aii.af.ra.ms.api.DeliveryException: invalid content type for SOAP: TEXT/HTML; HTTP 401 Unauthorized</SAP:AdditionalText> 
  <SAP:ApplicationFaultMessage namespace=""></SAP:ApplicationFaultMessage> 
  <SAP:Stack></SAP:Stack> 
  <SAP:Retry>M</SAP:Retry> 
  </SAP:Error>

Deve ser alterado o content type em algum momento?

Não precisei fazer isso nas configurações anteriores.

Muito obrigado pelo help!

[former_member182114]

Bom dia,

O usuário que você está usando no communication channel para logar no webservice pode estar travado ou ter direitos insuficientes. Redigite por lá o mesmo usuário e senha que usou no teste direto.

Atenciosamente, Fernando Da Ró

[henrique_pinto]

Nao nao, o content type é só pq em vez de voltar um XML, voltou um HTML com o erro HTTP 401.

Note que o BPM executou a chamada do assinador, e foi essa chamada que falhou.

O negative acknowledgement em si nao é erro, mas apenas um indicativo de que algo falhou lá na frente.

O negative ack é necessário para que vc possa restartar posteriormente o processo pelo próprio monitor do GRC (a mensagem provavelmente parou na aba de erro de assinatura, no monitor de NFe).

Quanto ao erro em si, supondo que vc já olhou o óbvio (i.e. o usuario usado no comm channel = o mesmo usuario testado por você na WSNavigator, que funcionou), provavelmente o HTTP 401 é na integração entre o Integration Engine (IE) ABAP e o Adapter Engine (AE) Java. A comunicacao nesse caso é HTTP, e pode ser aí a falha. Veja se as RFC Destinations AI_DIRECTORY* e AI_RUNTIME* estão OK e mapeadas com o mesmo Program ID das JCO RFC Providers equivalentes (que você vê no servido JCo RFC Providers do Visual Admin).

Se fosse pra chutar, baseado no erro anterior, eu diria que é erro de senha de usuário também...

Possivelmente o Basis mudou o master password sem seguir a nota 936093. Dê uma averiguada, principalmente nos users PIAFUSER, PIDIRUSER, PIREPUSER etc. Ou checa logo a lista completa:

http://help.sap.com/saphelp_nw70/helpdata/en/56/361041ebf0f06fe10000000a1550b0/frameset.htm

Aproveita e vê também o SLDDSUSER e se o SLDCHECK ainda acaba com sucesso (onde sucesso = todas as mensagens de texto indicando que a funcao chamada foi finalizada OK; apenas o fato de a tela web do SLD abrir nao indica sucesso).

Abs,

Henrique.

[RafaelVieira]

Alguns dos usuários do PI estavam, de fato, com passwords errados.

Inclusive o próprio usuário de acesso ao serviço de assinatura digital.

Vou solicitar a revisão dos usuários.

Muito obrigado pela ajuda.

[RafaelVieira]

Problema resolvido.

Além da revisão dos usuários de sistema, o usuário de acesso ao serviço de assinatura digital havia sido criado com um prazo de validade, e que tinha expirado.

Muito obrigado a todos pela ajuda!

Rafael.

[RafaelVieira]

Problema resolvido.

Além da revisão dos usuários de sistema, o usuário de acesso ao serviço de assinatura digital havia sido criado com um prazo de validade, e que tinha expirado.

Muito obrigado a todos pela ajuda!

Rafael.

[RafaelVieira]

Alguém já passou por isso e pode dar alguma ajuda?

Agradeço,

Rafael Vieira.