on 03-22-2013 12:08 PM
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
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
You must be a registered user to add a comment. If you've already registered, sign in. Otherwise, register and sign in.
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
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
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
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
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
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,
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
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
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...
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?
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
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
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
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
You must be a registered user to add a comment. If you've already registered, sign in. Otherwise, register and sign in.
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.
You must be a registered user to add a comment. If you've already registered, sign in. Otherwise, register and sign in.
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
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
User | Count |
---|---|
16 | |
4 | |
2 | |
1 | |
1 | |
1 | |
1 | |
1 | |
1 | |
1 |
You must be a registered user to add a comment. If you've already registered, sign in. Otherwise, register and sign in.