Erro de SYSFAIL e Queda do Ambiente JAVA (PI)

[former_member312176]

Bom Dia

Estou num projeto de NFe e atualmente esta acontecendo o seguinte cenário de Erros:

Na SMQ2 , quando apresenta um aumento nas filas de Mensagens , aparece SYSFAIL em determinadas Filas , todas as outras travam , aumenta o numero de Filas.

Com essa mensagem de SYSFAIL nas filas , o serve0 (Parte JAVA do PI) cai e após isso estou tendo que efetuar manualmente um STOP/START em todos os canais de comunnicação para que os R/3 voltem a emitir NFe.

Isso esta ocorrendo com mais frequência após inserir uma nova empresa para emissão de NFe.

Alguem poderia me ajudar a entender por que ocorre o SYSFAIL as mensagens travam e derruba o ambiente JAVA ?

Sérgio.

[former_member182503 · Accepted solution]

Bom dia Sergio,

Primeiro: Qual erro que ocorre quando vc entra no para ver o LUW com problema?

Segundo: foi feito algum tipo de tunning no PI para aumento de número de filas e/ou processamento paralelo de BPE? Se sim, foi alterado o número de Working Process Dialog (Parametro rdisp/wp_no_dia)? Foi alterado o número máximo de conexões na instancia (parâmetro rdisp/tm_max_no deve estar como o default, 200, o que é pouco em ambientes de PI produtivo).

Esses dois pontos podem bloquear as filas caso estejam configurados de maneira errada.

Para ver os parâmetros de instancia, ver transação RZ10.

Terceiro (pós edit): Verifique no Log DefaultTrace para ver se voce encontra o erro 666 - Out Of Memory.

Para ver o log, se você tiver acesso ao Visual Admin, entre por lá e vá em Log Viewer. Caso contrário, loge na Transação AL11 e vá navegando por /usr/sap//DVEBMGS00/j2ee/cluster/server0/log/

Pode ser que o ambiente subiu com pouca memória para o Java.

[]'s

Edited by: Jose Nunes on Aug 26, 2010 9:00 AM

[former_member312176 · Accepted solution]

1º) Erro: Commit Fault: com.sap.aii.af.rfc.afcommunication.RfcAFWException:SenderA

2º) Foi alterado o numero de Filas O numero de Filas foi alterado , mas não consigo ver esse parametros na RZ10 , tem 3 entradas : X32_DVEBMGS32_NFISAP ; DEFAULT ; START_DVEBMGS32_NFISAP nessa transação ...onde eu vejo isso

3º) Esse parametro não tem nessa transação (/usr/sap//DVEBMGS00/j2ee/cluster/server0/log/). em qual desses diretórios abaixo eu encontro esse parametro ?

Existe esses:

DIR_ATRA /usr/sap/X32/DVEBMGS32/data

DIR_BINARY /usr/sap/X32/DVEBMGS32/exe

DIR_CCMS /usr/sap/ccms

DIR_CT_LOGGIN /usr/sap/X32/SYS/global

DIR_CT_RUN /usr/sap/X32/SYS/exe/run

DIR_DATA /usr/sap/X32/DVEBMGS32/data

DIR_DBMS /usr/sap/X32/SYS/SAPDB

DIR_EXECUTABLE /usr/sap/X32/DVEBMGS32/exe

DIR_EXE_ROOT /usr/sap/X32/SYS/exe

DIR_GEN /usr/sap/X32/SYS/gen/dbg

DIR_GEN_ROOT /usr/sap/X32/SYS/gen

DIR_GLOBAL /usr/sap/X32/SYS/global

DIR_GRAPH_EXE /usr/sap/X32/DVEBMGS32/exe

DIR_GRAPH_LIB /usr/sap/X32/DVEBMGS32/exe

DIR_HOME /usr/sap/X32/DVEBMGS32/work

DIR_INSTALL /usr/sap/X32/SYS

DIR_INSTANCE /usr/sap/X32/DVEBMGS32

DIR_LIBRARY /usr/sap/X32/DVEBMGS32/exe

DIR_LOGGING /usr/sap/X32/DVEBMGS32/log

DIR_MEMORY_INSPECTOR /usr/sap/X32/DVEBMGS32/data

DIR_ORAHOME /oracle/X32/102_64

DIR_PAGING /usr/sap/X32/DVEBMGS32/data

DIR_PUT /usr/sap/X32/put

DIR_PERF /usr/sap/tmp

DIR_PROFILE /usr/sap/X32/SYS/profile

DIR_PROTOKOLLS /usr/sap/X32/DVEBMGS32/log

DIR_REORG /usr/sap/X32/DVEBMGS32/data

DIR_ROLL /usr/sap/X32/DVEBMGS32/data

DIR_RSYN /usr/sap/X32/DVEBMGS32/exe

DIR_SAPHOSTAGENT /usr/sap/hostctrl

DIR_SAPUSERS ./

DIR_SETUPS /usr/sap/X32/SYS/profile

DIR_SORTTMP /usr/sap/X32/DVEBMGS32/data

DIR_SOURCE /usr/sap/X32/SYS/src

DIR_TEMP /tmp

DIR_TRANS /usr/sap/trans

DIR_TRFILES /usr/sap/trans

DIR_TRSUB /usr/sap/trans

[former_member182503 · Accepted solution]

Sergio,

Pelo que eu estou entendendo, isso ocorre quando o R/3 envia as notas para o GRC através do Function Module /XNFE/NFE_CREATE, correto? Logo, vc está olhando na SM58 do client do GRC, certo?

Na RZ10, olhe pelo perfil X32_DVEBMGS32_NFISAP, marcando o parametro "Extended maintenance" e selecionando a opção Display. Se não aparecer ali, significa que está no valor default.

Na AL11, clique no DIR_INSTANCE e vá navegando seguindo o caminho que te indiquei. Tente ler o DefaultTrace que seja do horario onde ocorreu o problema no servidor.

PS: Verifique no PI todos os canais de comunicação do tipo RFC. Se eles não estão em uso, tente desabilita-los.

[]'s

[former_member312176 · Accepted solution]

A Solução para NFe nesse projeto é INHOUSE , ou seja , não utiliza GRC.

Na RZ10, o perfil X32_DVEBMGS32_NFISAP selecinando Display, se ele esta com valor default , qual o procedimento para alteração do mesmo.

Na AL11, no DIR_INSTANCE Consegui localizar o Trace e o horário que ocorreu a mensagem, pois não consegui visualizar o erro.

[former_member182503 · Accepted solution]

Sergio,

Como é a arquitetura da sua solução? O R/3 envia os dados para o PI via RFC?

confere se nas chamadas RFC tem um COMMIT WORK.

Se o parametro não aparece na RZ10, você teria que entrar no modo de edição, Novo Parametro, entrar o nome dele e o valor e salvar. Se o parâmetro não for dinamico, é necessário dar um stop/start na instancia.

Bom, deveria ter algum tipo de erro na AL11. Sei lá.

[]'s

[former_member312176 · Accepted solution]

Como é a arquitetura da sua solução?

A Arquiterura de Baseia em Envio, Recebimento , Unitilização e Cancelamento de NFe , Temos um repositório (BW) que armazena os XML's e um portal para visualização desses dados.

O R/3 envia os dados para o PI via RFC?

Sim os dados enviados ao PI são feitos via RFC e nas chamadas das RFC's existe um COMMIT WORK.

Não tenho autorização para editar parametros dessa Transação RZ10

[former_member182503 · Accepted solution]

Sergio,

só pra confirmar, qual o nome da RFC que está sendo chamada do R/3 p/ o PI e como está o SenderAgreement?

PS: Veja a nota 730870

[]'s

[former_member182114 · Accepted solution]

Bom dia Sérgio,

A Arquiterura de Baseia em Envio, Recebimento , Unitilização e Cancelamento de NFe , Temos um repositório (BW) que armazena os XML's e um portal para visualização desses dados.

Independente da solução para o ambiente, que com certeza pode ser ajustado com mais máquina, mais memória, mais processos, vocês utilizam uma nota por lote ?

Isto por si só já pode estar forçando seu sistema, se for 1 pra 1 é muito importante rever o desenho para enviar para Sefaz lotes com várias NF-es dentro.

Atenciosamente, Fernando Da Ró

[former_member312176 · Accepted solution]

Em nossos processos de NFe, não temos NFe por Lote.

Nosso parque de hardware esta sendo consumido apenas 1/3 do total

[henrique_pinto · Accepted solution]

Toda NFe é enviada por lote, a SEFAZ só recebe lote, nao há servico de envio de nota única.

O que faz supor, de sua msg, que vc está forçando o envio de 1 NFe por lote, o que, como o Fernando falou, é extremamente nao desejavel...

Abs,

Henrique.

[former_member312176 · Accepted solution]

Então nesse caso terei que rever meu processo de Envio NFe.

Isso em algum momento estaria afetando os erros recorrentes que estou enfretando.

Esse erros de SYSFAIL , Queda do ambiente JAVA (PI) , será que pode ter alguma relação com o processo que tenho hoje ?

[henrique_pinto · Accepted solution]

Nao dá pra dizer que é a causa raiz, mas com certeza ao ter mais notas por lote, vc terá menos work processes sendo consumidos, menos mensagens trafegadas pelo sistema java etc etc, o que vai dar uma folga maior de operacao pra instancia.

Abs,

Henrique.

[former_member182114 · Accepted solution]

Bom dia Sérgio,

São duas coisas diferentes, o lance de evitar mandar 1 NFe por 1 Batch é para evitar trabalho desnecessário ao servidor. Tipo, o limite é de 50 NF-es por lote ou 500kb, então se o volume para uma Sefaz é bom o suficiente para gerar tipo 10 notas por minuto você poderia mandá-las de uma vez apenas e o "trabalho" para o servidor é o mesmo para enviar/consultar o lote para 1 ou 50 notas.

Quanto aos problemas de java, deve ser falta de tunning para o alto volume. Siga as dicas que o Jose Nunes te passou para que o processamento funcione corretamente já que seu servidor está ocioso como você indicou. Se você ainda tem máquina/memória suficiente então com ajustes você faz com que o processamento caiba nele.

Então são dois pontos:

1 - O desenho atual está provocando excesso de trabalho

2 - A quantidade de processos PI/Java não está sendo suportada pelas configurações.

Dê uma olhada nesta discussão que acho que esclarecer alguns pontos sobre o item 1 e soluções para o item 2:

Atenciosamente, Fernando Da Ró