Gargalo de B2B de entrada param Batches

[Former Member]

Bom dia pessoal,

Sempre vejo problemas de filas no grc.

Normalmente ocorrem quando há um gargalo no processamento de B2B de entrada (problemas no servidor de emails as vezes causam uma represa de emails no inbox) e esse gargalo ferra com os batches.

Vocês saberiam me explicar pq vai tudo pra mesma fila?

Tem como segregar isso?

Aumentar o paralelismo pela swf_inb_conf de 1 para qualquer outro valor > 1 melhoraria nossa situação?

Temos 12 DIA na SM50...

E todos os processos de bpm na swf_inb_conf estão com 1.

Poderiam me ajudar com esta questão?

Abraços e muitoo obrigada!

Luciana

[former_member182114 · Accepted solution]

Bom dia Luciana,

Sim, tem como melhorar mas só podemos começar a falar em incrementar o paralelismo aumentando seu número de WP DIALOG.

Seu SAP NFE e PI estão na mesma máquina?

O processo de outgoing usa as filas abaixo (sendo S e R no client SAP NFE) e I/WF/O no client PI):

XBTS -> XBTI -> WF -> XBTO -> XBTR

Se me lembro bem o padrão são 10 para essas filas, e como você comentou o WF está com 1.

Como você explicou que o problema acontece quando as filas genéricas estão cheias, aumentar o paralelismo do ccBPM não irá resolver mas agravar a situação.

Perguntinhas:

Você tem também o incoming?

CT-e entrada?

CT-e saída?

Tá tudo bombando?

Quantos usuários tem acessando o sistema?

Atenciosamente, Fernando Da Rós

[Former Member · Accepted solution]

Oi Fernando,

Muito obrigada pela rápida resposta.

Olha só, não temos incoming não. Apenas recebemos os xmls sem automatização dos processos de MM.

Temos CTe de entrada, CTe de saída, tudo bomba aqui.

Pedi para o pessoal levantar exatamente o número de usuários que acessam o ambiente mas pelo que vejo pela sm50, nunca passa de 5 por vez.

Obrigada Fernando

[Former Member · Accepted solution]

GRC e PI estão na mesma máquina...

[former_member182114 · Accepted solution]

Bom dia Luciana,

Primeiro passo é fazer este levantamento em números pra saber exatamente o que bomba.

Configuração de Lote de NF-e como está? agressiva ou conservadora? Cola aqui também a sua configuração.

Pico de trabalho, depois vai somando (quantidades abaixo chute, não estou na transação agora para pegar os defaults):

10 filas XBTS

10 filas XBTR

20 filas XBTI

3 filas XBTO

5 usuários DIA

1 WF de BATCH

1 WF de BATSR

1 WF de NFESC

x para RFC do ERP

x para algum outra interface se tiver...

...

Tem como criar filas específicas isolando os XBTR e tal, anyway seu sizing já deveria ter sido revisto ao entrar CT-e. 12 DIA para máquina compartilhada (PI+NFE) outgoing de NF-e e CT-e e incoming de NF-e + CT-e (mesmo que sem automação) tá pouco.

Atenciosamente, Fernando Da Rós

-----

Complementado:

Comentei que 12 DIA está pouco, porém isso não depende só da soma nominal da capacidade das filas como mencionei.

Tem-se que somar o volume de trabalho.

Quantas NF-es por hora?

Destas NF-es, são da mesma empresa? mesma Sefaz? <-- isto define se as NF-es podem ir juntas ou não para o governo (mais ou menos lotes criados)

Qual o volume também de CT-es e NF-es recebidos dia? Controla de alguma forma o horário ou vazão quando chegam?

Atenciosamente, Fernando Da Rós

Message was edited by: Fernando Ros

[Former Member · Accepted solution]

Oi Fernando,

Estou buscando as respostas e já posto aqui.

Obrigada

[Former Member · Accepted solution]

Olá Fernando,

Chequei a configuração de lote e não está nada conservador.

Existem 27 linas na tabela /XNFE/BATCUS. Uma para cada cnpj, todas com maxtime =5, maxsize= 500.000, maxquant=15, wait=30 e maxretries=15.

Este é o volume médio de notas por mês:

Outubro/2012 - SAFRA

Notas emitidas e ativas: 32016

Notas emitidas e canceladas: 1806

CTRC Emitidos e ativos: 6853

CTRC emitidos e cancelados: 127

Janeiro/2013

Notas emitidas e ativas: 18879

Notas emitidas e canceladas: 941

CT-e Emitidos e ativos: 1382

CT-e emitidos e cancelados: 31

Estou checando mais dados aqui ..

Obrigada

[Former Member · Accepted solution]

Bom dia Luciana,

Aumentando o número de DIA processes (rdisp/wp_no_dia), você pode aumentar também o EO_INBOUND_PARALLEL, mas isso apenas vai aumentar a quantidade de processos executando em paralelo, as filas continuariam as mesmas.

O que pode ser feito é alterar o protocolo do communication channel para EOIO e especificar a fila onde serão executados os processos. Com isso, por exemplo para um sender mail, você pode registrar uma fila XBTQ_EMAIL para todas as mensagens criadas para o NFB2B. Isso impediria que as entradas na SMQ2 executassem juntas.

- no Sender channel, alterar para EOIO;

- na SMQR, cadastrar a fila criada para o cenário;

- garantir que o modo "Maintain order at runtime" está marcado no Sender agreement.

Abs,

Lucas Santos

[Former Member · Accepted solution]

Oi Lucas,

Muito obrigada pela ajuda.

Vou fazer isso!

Umas dúvidas  em relação a esta atividade:

-->Setando uma fila específica para B2B (pelo channel de sender mail) faz com que os batchs não concorram com este processo?

-->Além de definir uma nova fila exclusiva para B2B de entrada, preciso também garantir que sua prioridade seja menor que as demais, certo?

-->Uma coisa que observei também foi que, o que contribui para a lentidão quando os processos de B2B ficam represados, é que assim que um XML entra, o processo de consulta de nota é iniciado. Tenho a sensação de que é este processo de consulta de nota que causa a lentidão, e não exatamente o número de emails que está entrando. Faz sentido? Se isso faz sentido, o ideal seria criar uma fila para o processo de consulta de nota também?

Muiiito obrigada pela ajuda de todos!!!

Já vejo uma luz no fim da fila...ahaha

Abraços,

Luciana

[Former Member · Accepted solution]

Luciana,

1. Não. Isso vai afetar apenas as mensagens criadas para o communication channel sender que enviou utilizando o EOIO. Nesse caso, um "mail sender" por exemplo.

2. Isso pode ser configurado na SMQR, alguns parâmetros como tempo de execução. Procure por notas do "QIN Scheduler", em BC-MID-RFC para mais informações.

3. Esse é um caso mais complicado. Até é possível configurar EOIO para envios de proxy, mas necessitaria alterações nos programas, e isso não é possível ser feito. Isso realmente pode causar lentidão, porém se houver menos notas de entrada em paralelo (porque estará executando apenas em uma fila), isso reduz o número de NFESC sendo executados ao mesmo tempo, permitindo aos outros cenários executarem mais RFCs nesse tempo.

Para o item 3, a nota 1380855 pode auxiliar melhor, e você pode não aumentar o número de filas para o NFESC, se notar que ele está consumindo recursos em excesso.

Abs,

[former_member182114 · Accepted solution]

Hhuahaua, legal sua esperança. Sim só de mapear e agir, não de chorar 😉

Um processo inicia o outro, então um XML chegando que corresponde a um XBTI -> XBTR, irá disparar um NFESC que equivale a um XBTS -> XBTO -> WF -> XBTI -> XBTR.

Processinho danado né...

Este é seu principal problema sim (pois você nem tem controle sobre quando alguém irá disparar estes XML's pra ti).

Sobre o lote (faça imediatamente):

- elimine todas as entradas específicas por CNPJ e deixe apenas alinha default (usar o CNPJ era a única opção possível na versão anterior, porém FORÇA exclusividade de lote por filial, mesmo que seja para mesma Sefaz)

- a configuração padrão ideal é tempo = 40 segundos, tamanho = 500.000, quantidade = 50, tempo rebusca = 120, quantidade rebusca = 10

- se enfrentar problemas temporários com alguma Sefaz, faça configurações temporárias sendo duas as básicas necessárias:

1) Sefaz com delay no HTTP, segurando a conexão, aumente o tempo de fechamento para evitar "tocar" na Sefaz para uns 120 segundos ou mais

2) Internet ruim / dificuldade de processar lotes grandes. Baixa a quantidade de notas por lote para 5 indo até 1 (Isto causa mais lotes criados, então use só em ultimo caso)

Obs.: Configuração de lotes não é customizing. QAS e PRD devem ser diferentes, e PRD tem que ser dinâmico.

Mas tudo temporário mesmo.

Tem que focar no que a mensageria precisa mais que o usuário deseja (quero minha nota em 1 segundo)... Se existe volume então fará fila.

Atenciosamente, Fernando Da Rós

PS: Tava com saudade de discutir sobre isso, é meu tema preferido

[former_member182114 · Accepted solution]

Bom dia Lucas,

Tem uma configuração que pode ser feita separando as filas XBTR e dando prioridade também. O fato de separar também vai ajudar na vazão do importante. Vou procurar aqui como faz...

Atenciosamente, Fernando Da Rós

[Former Member · Accepted solution]

Que povo participativo!!!

Por isso gosto de vocês!

Estou montando um relatório com todas estas observações e formas de correção e já posto aqui sobre elas!!

Muito obrigada gente.

Nem sei como classificar a Thread pois, seria injusto colocar só uma resposta como sendo a correta!!!

Vocês são demais!!!

Abraços

Luciana

[former_member182114 · Accepted solution]

Quem disse que a thread terminou?    

[Former Member · Accepted solution]

Fernando,

Acho que este doc mostra como priorizar as filas:

http://scn.sap.com/people/community.user/blog/2005/12/12/how-to-prioritize-messages-in-xi

Foi o Pedro Baroni me passou...

[Former Member · Accepted solution]

Pessoal

Outra perguntinha:

O Fernando explicou a sequência de filas para o processo de b2b de entrada.

Vocês sabem qual a fila de Batchs?

Como sei para qual fila cada processo vai?

Obrigada

[Former Member · Accepted solution]

Tem também esta nota:

0000813029 Automatic processing of failed XI messages (https://websmp230.sap-ag.de/sap%28bD1wdCZjPTAwMQ==%29/bc/bsp/spn/sapnotes/index2.htm?numm=813029).

Com ela aplicada, possivelmente mesmo depois dos Sysfail, as filas teriam sido reiniciadas e as respectivas entradas não teriam ficado paradas, certo?

[former_member182114 · Accepted solution]

Opa, esta configuração mesmo estava procurando e fui achar esta priorização em emails de 2011....

Vou guardar esta URL com carinho 😉

Thanks Pedro

[former_member182114 · Accepted solution]

Bom dia Luciana,

Estes automatic reprocessing tem outro objetivo que é "empurrar" o que fica parado em fila ou em erro. Em parte é o que comento como housekeeping jobs

Porém em alguns casos ele joga "CONTRA" a performance do sistema.

Exemplo: O programa RSXMB_RESTART_MESSAGES deve ser configurado para o PI e para o SAP NFE. Quando no SAP NFE em algumas situações ele "conserta", porém nos casos do B2B existem casos onde o aplicativo dá algum erro tipo XLM já foi processado... e não irá processá-lo. Restartar só faz aumento da carga de trabalho.

Sintoma: Você monitorando filas e processos e vê um aumento repentido no volume dos processos/filas. Isto acontece de 5 em 5 minutos aprox.

Constatação: Entrando na SXI_MONITOR você encontra mensagens de B2B com bandeira vermelha (manual restart possible). E um contador, que por default vai até 20.....

Solução: Reschedular o job do client SAP NFE com flag "Errors After Auto. Retry Only"

Quanto às filas dá uma olhada nestes status (outra coisa que demorei horrores para achar, mesmo assim só a versão em Inglês, se alguém encontrar a em português me manda recado):

NF-e Status on SAP Nota Fiscal Electronica Solution (ERP x GRC x PI)

As SIGNN não são mais usadas pois são feitas em ABAP, porém pegue a BATCH por exemplo:

1-XBTS --> SAP NFE enviando ao PI (client SAP NFE)

2-XBTI --> PI recebendo (os leitores de B2B também caem aqui)

3-XBPE_WS --> ccBPM que no nosso caso faz o contato com a Sefaz sincronamente

4-XBTI e/talvex XBTO -->recebendo do ccBPM e preparando para mandar para o SAP NFE (por parâmetro pode usar apenas fila XBTI aqui)

5-XBTR --> SAP NFE recebendo a resposta e processando)

As filas XBTS, I, O e R são genéricas e usadas em todos os processos passeando entre o integration engine e server. O recurso da priorização de filas você consegue separar em outras (XBT1/XBT9/XBTL/XBTA) filas.

Atenciosamente, Fernando Da Rós

[former_member182114 · Accepted solution]

Bom dia Luciana,

Lembrei de outra coisa bem simples de implementar que impacta o SAP NFE quando vários processos estão para serem executados. ACKNOWLEDGMENTS.

A única ligação de fato entre o aplicativo SAP NFE e seu conteúdo no PI é o ACKNOWLEDGMENT. A cada mensagem assíncrona enviada ao PI, o SAP NFE grava na tabela /xnfe/acknowledg o messageID to PI e o ID do processo NFE (chave de acesso, número do lote, GUID de evento...)

O intuito destes registros são para setar o SAP NFE para Erro quando um ACK NEGATIVE chega. Esta é a forma de devolver o controle ao usuário quando aconteceu um erro no PI e a resposta do que foi enviado não chegará.

IMPACTO: Aumento do tempo da criação / consulta de lotes.

O endless program /xnfe/process_report faz por default 3 funções (verificar ACKs, criar lote, consultar lote).

Se tiver muitos acknowledgments para verificar, a criação dos lotes não irá ocorrer no tempo de sua configuração. Em casos críticos já vi sistema ficar quase 3 horas neste step sem criar nem um lote.

SOLUÇÃO: Reagende o job com a opção de acknowledgments desmarcada. E agenda um novo job de minuto em minuto para o programa /xnfe/get_acknowledgment.

A ligação disto com sua thread é que cada B2B chegando dispara um NFESC e é 1 a mais a verificar...

Atenciosamente, Fernando Da Rós

[Former Member · Accepted solution]

Bom dia pessoal,

Apenas passando para dizer que teremos uma reunião esta semana para avaliar todas estas sugestões dadas por vocês.

Já fiz um relatorio descrevendo os problemas, as causas, consequências e possíveis soluções para discutir.

Assim que fecharmos este assunto eu volto aqui para fechar a thread ok?

Abraços e mais uma vez, muito obrigada

[pedro_baroni3 · Accepted solution]

Boa sorte Lu,

Depois conta pra gente a solução.

Abs.,

Pedro Baroni

[Former Member · Accepted solution]

Boa tarde Lucas, tudo bem?

Espero que sim.

Uma dúvida que me veio agora foi a seguinte: consigo setar uma fila específica somente para sender mail channel?

Pois no meu modelo atual, é o próprio Exchange quem trata os emails que chegam e já joga os anexos em file system.

A interface que lê os anexos é Sender File x Receiver Proxy.

Consigo setar esta parametrização para sender file?

Obrigada mais uma vez,

abraços

Luciana

[henrique_pinto]

Só vi essa thread hoje, acho que nao há muito mais a acrescentar, a nao ser q dela dá pra virar um document padrão. , pq você não compila essas informações num Document aqui no SCN?

Tenho certeza que vai ajudar muitas outras pessoas que enfrentam e enfrentarão esse problema.

Abs,

Henrique.

[Former Member]

Oi Herinque,

Pode deixar. Farei isso ainda esta semana.

Abraços

Luciana

[brunobex]

Olá Luciana,

Segue uma nota também com algumas dicas:

SAP Note 1380855 - SAP PI tuning to increase throughput for NFE interfaces: https://service.sap.com/sap/support/notes/1380855

Att,

Bruno Xavier.

[Former Member]

Muito obrigada Bruno!!!

Abraços

[Former Member]

Pessoal,

Estou passando para contar a experiência..rs

O que foi feito por enquanto:

1 - Paralelismo. Na transação swf_inb_conf, aumentei de 1 para 5 em cada um dos processos, inclusive CTe.

2- Priorização de filas: Na transação sxmb_adm, criei um filtro com baixa prioridade para as filas de B2B (não estou certa de que fiz corretamente, fiz apenas no client do PI. Precisa fazer no client do GRC?) O filtro considera a interface de outbound.. e setei baixa prioridade para as filas XBT9.

3- Limpeza da tabela /XNFE/BATCUS (somente 1 linha).

4- Reschedulei o job /XNFE/PROCESS_REPORTS sem ack

5- Schedulei o job /XNFE/GET_ACKNOWLEDGMENT

Com isso, enviamos 9 batches de nota ao mesmo tempo + 2k de emails ao mesmo tempo também.

Tudo isso foi processado em 10 minutos. As notas foram aprovadas bem antes de as filas no GRC acabarem...

Acho que funcionou.

Imagino que tenha mais coisas a serem feitas.. mas este foi o cenário que tivemos da outra vez em produção. E nossa máquina em dev é pior que a de produção.

Quando tivemos o problema, estes 2 mil emails + algumas notas, levaram algo como 4 horas para serem processados, hoje, o mesmo cenário, em 10 minutos com algumas pequenas mudanças!

Obrigada a todos!!

Abraços

Luciana

[rhviana]

Luciana,

Como você schedulou o /xnfe/process_reports sem ACK ?

O job /XNFE/GET_ACKNOWLEDGMENT só com SP13, certo ?

Att,

Viana.

[Former Member]

Oi Ricardo,

Criei uma variante para o programa sem o ack setado e schedulei o job com esta variante.

Estamos no SP13 em dev, mas acabei de checar o programa  /XNFE/GET_ACKNOWLEDGMENT no SP12 na produção e ele existe também.

Acho que consegue schedular o job sem problemas mesmo no SP12.

Abraços

Luciana