Problemas na execução da interface "BATCH"

[Former Member]

Bom dia!

Estou com um problema quando envio uma nota para a Sefaz. O GRC dispara a interface BATCH que envia o lote mas o retorno com a mensagem de lote recebido com sucesso fica parado na fila de entrada do PI (SMQ2). A fila fica com status RUNNING eternamente.

Alguém já passou por este problema? Vi discussões aqui sobre isso e já verifiquei tudo o que foi sugerido mas não obtive sucesso.

Muito Obrigada pela ajuda!

[Former Member]

Oi Gabriela

Conseguiu resolver? Você fez export e import dos cenários do PI? No teste de conexão você validou também usuário e senha (logon remoto)?

Abraço

Eduardo Chagas

[Former Member]

Olá Eduardo,

Ainda não conseguimos fazer funcionar. Já reconfigurei o cenário inclusive e nada. Ele continua parando na chamada da conexão AI_RUNTIME_JCOSERVER. Já testei todas as conexões possíveis da sm59 e o basis também verificou usuário e permissões da parte dele. Acho muito estranho parar nessa chamada pois essa conexão está funcionando.

Obrigada!

Gabriela

[former_member182503]

Bom dia Gabriela,

Só por curiosidade:

1- Qual a versão do PI que você está usando?

2- A instalação do GRC é separada do PI?

Grato,

JN

[Former Member]

Bom dia!

A versão é 7.31 e a instalação é a mesma.

Obrigada!

Gabriela

[rhviana]

Maria,

Pergunta.

Você já deletou e recriou o cenário de batch ?

Att,

[Former Member]

Oi Viana,

Já sim... fiz isso também porque o campo idLote não está vindo (e sei que vou ter problemas com isso depois) mas também não funcionou para ambos os problemas.

Obrigada!

Gabriela

[rhviana]

Maria,

Já foi na sproxy do GRC e verificou se existe essa tag ?

Já vui o status da sxi_cache ?

Status da SLD - TCode - sldcheck ?

Se tudo estiver 100%, vamos precisar benzer essa máquina ai rsrsrs..

[Former Member]

O pior de tudo Viana é que está tudo verde tanto na SLDCHECK quanto na SXI_CACHE (já limpei várias vezes inclusive). A tag existe sim na sproxy e estou aceitando orações kkkkk

[rhviana]

Tipo,

Quando você tenta enviar uma nota, fica tudo travado na SMQ2 ? É isso ?

[Former Member]

Ele entrega o lote na Sefaz mas quando volta com a mensagem de lote recebido fica preso na SMQ2 do PI. Após testes junto com o Basis demos um jeito aqui e conseguimos debugar a fila, aí verifiquei que o processo fica parado numa chamada que usa a destination AI_RUNTIME_JCOSERVER. A fila não apresenta erro... ela fica como RUNNING eternamente.

Obrigada!

Gabriela

[rhviana]

Ok.

O BASIS já desregistrou e registrou novamente todas as filas ?

Verifique o usuário dessa conexão, veja se ele está bloqueado e veja também:

https://scn.sap.com/thread/57572

Nesse caso NWA ok, 7.31 !!!

Att,

[former_member182503]

Gabriela,

Se o level do SP do PI 7.31 for igual ou superior a 4 (patch level mais alto de pref. se o sp=4), eu recomendaria configurar os cenários AEX ao invés dos cenários comuns, para evitar usar a camada ABAP do PI.

http://service.sap.com/sap/support/notes/1743455

Se o problema ocorre dentro do BPE, se você configurar usando o AEX provavelmente não terá mais o problema dentro do BPE e sim no AEX e talvez seja mais fácil para identificar a causa do erro (ou talvez nem tenha mais o erro -- eu voto nessa opção).

Mas caso você não queira refazer tudo, eu tentaria executar a SWU3 (customizing automatico de workflow) novamente no seu ambiente PI.

[]'s

JN    

[Former Member]

Oi Viana,

Já desregistramos e registramos as filas sim.

A conexão funciona. O usuário não está bloqueado e no teste de conexão ela roda normalmente.

Vou tentar recriar essa conexão para fazer um teste.

[Former Member]

Oi José

Vou fazer esses passos e já posto aqui se deu certo.

Obrigada!

Gabriela

[henrique_pinto]

Veja se o SP do PI Content (dentro do ESR) está no mesmo nível de SP do ABAP Add-On SLL-NFE 900.

Esse mapping que vc mencionou foi alterado em um SP pq ele passou a trazer o numero de lote na mensagem síncrona em vez de utilizar o enviado pela SEFAZ. Verifique se o numero de lote está correto na mensagem de retorno da SEFAZ pro NFE.

Abs,

Henrique.

[rhviana]

Putz !! Tinha esquecido disso !!!

Veja os niveis em:

Stack abap - SPAM - SLL-NFE 900

Stack Java - SCV - SAP BO NF-e 10.0

Agora vai Maria !!

[Former Member]

Pessoal,

Vejam...

[rhviana]

Inacreditável !

Como última sugestão, remove toda a configuração do integration scenário BATCH e refaça tudo novamente.

Após refazer faça um full cpa refresh + sxi_cache.

Se não resolver, chamado.

Att,

Ricardo Viana.

[Former Member]

Oi Viana,

Eu abri um chamado a umas 2 semanas quase. Na verdade foi por isso que ainda não configurei os AEX que o José Nunes citou acima (parece que a SAP iria olhar hoje). Eu já refiz as configurações do BATCH por causa do problema do lote e limpei os caches infelizmente não funcionou...

Muito Obrigada pela ajuda!!

[rhviana]

Então mais o cenário AEX, até onde eu sei seria para uma instalação AEX - Single Stack Java apenas.

é possivel realizar a configuração dos cenários AEX utilizando dual stack via AAE ?

Disponha e desculpa não ter ajudado muito ;/

[former_member182503]

Ricardo,

Nada impede de você ter dual-stack e rodar os cenários AEX, que são ICO-based, desde que atenda ao pre-req PI7.31 SP04+

[]'s

[rhviana]

Massa cara,

Não sabia dessa, também última vez de desenvolvi em um AEX foi em 2011 putz.. tempo..

Bom nesse caso seria uma config baseada nos adaptadores AAE, imagino.

Obrigado pela explicação.

valeuras

[henrique_pinto]

Mas cole aqui tb a mensagem de retorno da SEFAZ (a que entra no GRC e falha), para vermos os dados e tentarmos entender o que pode estar falhando.

O campo nRec está vindo em branco?

[Former Member]

Gabriela... você chegou a olhar a nota... 937159 - XI Adapter Engine is stuck ?

[Former Member]

Gabriela..

Você pode por favor colocar imagens da sua configuração da RFC? Qual o tipo de conexão e destino RFC você está usando?

Certifique-se que a configuração está exatamente igual a sua outra conexão que funciona.

Abraço

Eduardo Chagas

[Former Member]

Oi Henrique,

Na verdade não entra no GRC e não há erro. Até onde debuguei o processo trava no transformation do BPM de BATCH que faz o Merge...

Veja abaixo o log na sxi_monitor da última interface que ele executa e mais abaixo a fila na SMQ2 do PI... ela fica com status RUNNING.

[rhviana]

Maria,

Você já fez o paralelismo do ccBPM de "BATCH" ?

Tcode - swf_inb_conf

Coloca para 3 o ccBPM do Batch que deve estar em um apenas.

Você já fez o stop/start e active dessa fila, certo ?

Faz o paralelismo, tenta fazer o disparo se as três filas pararem tem alguma coisa errada com ambiente.

[Former Member]

Quando o erro aconteceu eu fiz a configuração na SWF_INB_CONF mas não surtiu efeito... então reinicializei...

Fiz sim... inclusive para debugar eu tive que fazer o stop dela e depois iniciei e ativei ela denovo...

[henrique_pinto]

Gabi,

só por desencargo de consciencia, mas vc tem o alerta NFE_ALRT_CAT definido?

http://help.sap.com/saphelp_nfe10/helpdata/en/6c/b208d6770843988e47593a99165210/content.htm

Outra coisa: se o processo está parado no BPM, então tente verificar em que step do mesmo o processo parou. Para isso, clique na coluna da SXMN_MONI que tem os dizeres "PE" como outbound component, ele vai abrir o workflow monitor.

+1 questão: alguma mensagem síncrona de BPM já funcionou nesse ambiente? Digo, outro cenário que nao o BATCH já funcionou antes? NFESC, SKIPR, etc.? O SRVSC nao é baseado em BPM então não conta. Pergunto isso pq pode ser que esteja faltando configuração também do adapter do tipo XI que o Configuration do PI usa para apontar de volta pro GRC. Ele tem que ter uma HTTP Destination apontando pro client do GRC (nao é a HTTP destination apontando pro client do PI que vc usa na SXMB_ADM - é outra!!). Verifique isso também.

Abs,

Henrique.

[Former Member]

Oi Henrique,

Acabei de olhar e está criado. Vou deixar o print abaixo.

Eu clico no PE e ele direciona para a fila. Eu consegui ver via debug da fila que ele está parando no transformation do BPM que faz junta o Id do Lote com as outras informações de retorno. Para debugar tive que deixar 1 fila em espera, eliminar os registros de fila, debugar e depois ativar a fila novamente.

Nenhum cenário fora esse e o SRVSC foi testado ainda. Vou verificar essa destination.

Muito Obrigada!

Gabi

[henrique_pinto]

Tente testar o operation mapping no ESR com os inputs que o BPM usa (mensagem de entrada no BPM, i.e. que o GRC enviou pro PI, e a mensagem de retorno da SEFAZ) e veja se ele funciona lá.

Veja também o objeto integration process do configuration, se ele está referenciando o BPM/operation mapping mais atual.

[Former Member]

Maria,

uma pergunta, qual o Operation Mapping está configurado no seu interface determination?

[Former Member]

Maria, boa noite.

Verificar se as notas abaixo se aplicam no ambiente PI:

1849533 XI runtime: synchronous acknowledgments II

1857701 XI runtime: Synchronous acknowledgements III

Att.,

André Canalles

[Former Member]

Sim Andre... estão aplicadas.

[Former Member]

Olá Felipe!

Comparei com um ambiente que funciona todos os interfaces determination que possuem operation mapping e estão iguais... o operation mapping que citei acima é usado no transformation entre o retorno da Sefaz e a chamada do GRC no BPM do processo BATCH.

Obrigada!

Gabriela

[Former Member]

Maria,

Voce ja executou a transação

GRC

sxmb_admin ->Manage Queues

At

Felipe

[Former Member]

Já sim Felipe... o Basis e eu já eliminamos, criamos, ativamos as filas várias vezes.

[Former Member]

Pessoal,

Depois de algumas tentativas conseguimos dar um jeito de debugar o processo que a fila executa. Ela fica parada na chamada da conexão AI_RUNTIME_JCOSERVER. Já testei essa conexão na sm59 e ela está funcionando. Debugando alguns passos vi que esse processo executa o operation mapping BATCH_nfeRecepcaoLote2_Merge_nfeRecepcaoLoteResponse2_TO_nfeRecepcaoLoteResponse2 que é o que está informado no transformation dentro do BPM antes do send para o GRC desse processo.

Alguém já viu algum erro nessa conexão?

[Former Member]

Maria Gabriela, passei pelo mesmo problema com uma nota aqui, mas resolvi, vou te mandar passo a passo para ver se te ajuda a resolver o seu.

No monitor do GRC

NO ECC

Na SEfaz  a nota já ta autorizada

Arrumei da seguinte forma:

Fui no monitor do GRC

Peguei o lote

A situação dele tava a seguinte dentro do monitor do GRC

Fui na Aba de envio de lotes incorretos

Marquei a linha e pedir para Reiniciar, com isso atualizou tudo.

Veja agora a nota liberada

E no ECC aprovada também igual estava na sefaz

Espero ter ajudado.

att.

Sonia Braga

[Former Member]

Maria Gabriela,

como esta a nota no monitor?

por lá as vezes esta numa aba e vc consegue atualizar e a nota é liberada.

Printe para mim se ta em albuma aba destas por favor.

[Former Member]

Maria Gabriela, bom dia,

só para eu tentar entender o que ta falando.

No ECC a nota esta como aguardando resposta( na engrenagem)

no GRC está como?

E na Sefaz a nota chegou lá?

voce chegou entrar no monitor web do GRC, como a nota esta lá?

att.

Sonia Braga

[Former Member]

Oi Sonia,

No ECC está na engrenagem sim. No GRC fica com status 04. A nota vai para a sefaz, entrega o lote o PI recebe o retorno com a mensagem de lote recebido mas a mensagem para na fila de entrada do PI.

Obrigada!

[Former Member]

Olá Senhores!

Na verdade já fiz vários testes junto com o Basis. Já verifiquei o usuário WF-BATCH, já verifiquei as filas, já verifiquei as configurações do GRC e também já vi o operation mapping na configuração da interface como sugere o outro post.

Não tenho como testar em mais de uma SEFAZ pois aqui só se emite nota para SP. A interface de consulta de status (SRVSC) funciona normalmente.

Até agora nada.

Obrigada!

[Former Member]

Gabriela, boa noite.

O problema persiste para mais de uma secretária ? Pode ser um problema com a Sefaz, que está prendendo a conexão sync com o ccBPM.

Att.,

André Canalles

[rhviana]

Maria Gabriela ?

Conseguiu algo ?

Precisa de ajuda ?

Abraço,

Ricardo Viana.

[Former Member]

Oi Maria Gabriela.

Resolveu com as sugestões do Viana?

Abraço

Eduardo Chagas

[rhviana]

Olá Maria bom dia,

Verifique na SM12 se o usuário WF-BATCH está em LOCK, se estiver remova ele dessa situação.

Outro procedimento, na SMQ2, faça um stop/start da fila e veja se sai desse status.

Atenciosamente,

Ricardo Viana.