cancel
Showing results for 
Search instead for 
Did you mean: 

Configurar SWF_INB_CONF

Former Member
0 Kudos

Boa tarde.

Estou dando uma olhada na configuração na SWF_INB_CONF e estou vendo que cada serviço esta configurado de uma forma:

Sei que cada configuração depende do Hardware do cliente, mas queria tirar algumas dúvidas:

1) Without Buffering não deixa o processamento mais rapido? Nao é melhor colocar para todos?

2) Quanto mais fila melhor? (considerando que a máquina suporte)?

3) A configuração abaixo esta razoavel? Poderia configuração abaixo causar mensagens de cancelamento ficarem algumas vezes paradas na fila processando(RUNNING)?

BATCH_BatchProcess

Delivery Mode: Without Buffering

Queue Assignment: Multiple Queues (Random)

Number of Queues: 5

BATSR_BatchStatusRequestProcess

Delivery Mode: Without Buffering

Queue Assignment: Multiple Queues (Random)

Number of Queues: 5

CANCR_CancellationRequestProcess

Delivery Mode: Buffering Possible

Queue Assignment: One Queue

Number of Queues: 1

NFESC_NFeStatusCheckProcess

Delivery Mode: Without Buffering

Queue Assignment: Multiple Queues (Random)

Number of Queues: 3

SIGNC_SignCancNFeProcess

Delivery Mode: Buffering Possible

Queue Assignment: One Queue

Number of Queues: 1

SIGNN_SignNFeProcess

Delivery Mode: Without Buffering

Queue Assignment: Multiple Queues (Random)

Number of Queues: 3

SIGNS_SignInutNFeProcess

Delivery Mode: Buffering Possible

Queue Assignment: One Queue

Number of Queues: 1

SKIPR_SkippingRequestProcess

Delivery Mode: Buffering Possible

Queue Assignment: One Queue

Number of Queues: 1

Agradeço desde já.

At.,

Bernardo Tavares Braga

Accepted Solutions (1)

Accepted Solutions (1)

former_member182114
Active Contributor
0 Kudos

Bom dia Bernardo,

1) Não tenho certeza, mas seria o contrário With Buffering seria mais rápido, porém vc só pode configurar mais de uma fila se usar o Without Buffering que no final das contas vai mais rápido por executar em paralelo. Quando a colocar em todas, melhor analisar os casos em que vc realmente precisa disso. Veja comentários por processo

2) Sim, porém é um ajuste fino entre quantidade de dialogs disponíveis e recursos RFC. Sugestão: Fazer stress test em DEV e acompanhar... faça simulações e veja o que fica melhor na sua necessidade de negócio/hardware.

3) Aí tem duas questões FILA não quer dizer que fica em running direto, se ficar em running direto para a mesma mensagem o problema é outro. Mantenha o GRC atualizado por SP's, estamos constantemente adicionando tratamentos que reduzem a zero os erros de fila parada. Em resumo quanto mais atualizado menos você precisa caçando coisas no PI...

Quanto às interfaces, tem que se ter em vista o processo normal de NF-e que é EMISSÃO. Cancelamento, inutilização e consulta de status são pontuais e dependendo do seu hardware não faz sentido algum paralelizá-los pois concorrerão com o processo principal que é EMISSÃO.

SIGNN_SignNFeProcess - Esta é a interface que necessita da maior quantidade de processos possíveis, deixe maior que os outros (tente 10)

BATCH_BatchProcess - Ok c/ multiplas filas

BATSR_BatchStatusRequestProcess - Ok c/ multiplas filas

NFESC_NFeStatusCheckProcess - Evite o paralismo aqui. Você estaria comprometendo a principal missão p/ status query de NF-es de fornecedor for grande

Ok para individual: SIGNC, SIGNS, CANCR, SKIPR

Este paralelismo é nas interfaces no PI, e existe uma REGRA DE OURO pro GRC NFE para atingir um super troughput no GRC. Criar o menor número de lotes possíveis. Como ? Assinando rápido (por isso prioridade para o SIGNN) e permitindo o lote com 50 NF-es, e aumentar o tempo de espera até um ponto onde consiga colocar o maior número possível de NF-es sem impactar o negócio. Veja esta thread que explica bem isto:

Instalações com 1 NF-e por lote. Também tem 2 interfaces por NF-e que representam 12 mensagems no PI, duas comunicações com Sefaz..... Gastando disco, rede, internet...

Pra terminar: TUNNING é equilíbrio NÃO EXISTE REGRA QUANTO AOS VALORES, tem que entender e testar, vai depender de negócio x capacidade de processamento. Bom senso e equilíbrio.

Atenciosamente, Fernando Da Ró

henrique_pinto
Active Contributor
0 Kudos

Alguns comentarios:

1) without buffering eh mais rapido sim, teoricamente. Mas nem todo design de BPM pode ser without buffering (por exemplo, se o BPM tem correlacao nao pode). No caso do NFE, todos os BPMs sao simples pontes async/sync, entao pode ser tudo without buffering sim.

Se tiverem curiosidade e quiserem mais detalhes de como funciona o Inbound Processing do BPE e sugestoes de design de BPMs:

http://help.sap.com/saphelp_nw70/helpdata/en/45/1a9702109921a0e10000000a1553f6/frameset.htm

http://www.sdn.sap.com/irj/scn/index?rid=/library/uuid/c00d9465-ea97-2910-deac-f8aa681eef35&override...

2) notem que essas filas nao sao filas de interface (que vc paraleliza atraves de parametros na SXMB_ADM; mais detalhes no PI Tuning Guide). Elas sao filas de execucao dos BPMs (que nada mais sao que qRFCs). Cada entrada na fila é um processo (workflow) esperando pra ser executado.

3) o ideal eh vc usar algo em torno de 80% dos dialog WPs que vc tem com filas de execucao dos processos de emissao (SIGNN, BATCH e BATSR). Os demais WPs servem para usuarios logados, para os demais processos (CANC, SKIP, NFESC) e tambem para os proprios processos do PI (o PI usa WP dialog pra processar filas de interface! entao nao adianta usar todos os WPs com fila de BPM que a performance vai ser é pior). Dentro do numero de WPs que vc usará para os 3 processos de emissao, a distribuicao otima é algo do tipo x:y:y (SIGNN:BATCH:BATSR), onde x/y = numero medio de NFes por lote. Note que esse numero medio é diferente da quantidade maxima de NFes configurada. Vc pode ter 10 NFes/lote na configuracao, mas na média vc pode ter 3 NFes/lote pq tem varios lotes com poucas notas. Entao no caso x/y = 3, x = 3y. O numero total de WPs das filas desses 3 processos seria entao x + y + y = 5y. Suponha por exemplo que vc tinha 32 WPs dialog no total, 80% dah algo em torno de 25. Desses, vc teria que deixar 15 para SIGNN, 5 para BATCH e 5 p/ BATSR. Na pratica, vc pode ir brincando com esses valores (e.g. baixa SIGNN para 13, aumenta os outros para 6, ou vice versa) e verificar o ponto otimo que maximiza o throughput de notas/minimiza o tempo de processamento medio.

Abs,

Henrique.

Answers (1)

Answers (1)

Former Member
0 Kudos

Excelente. Ajudou bastante. Vou dar uma lida nos materiais e fazer os ajustes necessários.

Muito obrigado.