Tempo gasto na assinatura

[Former Member]

Boa tarde.

Se o tempo para assinar uma nota esta muito alto (tempo entre "Enviado ao serviço de assinatura digital" e "Assinado"), onde pode estar o problema?

A configuração SIGNN_SignNFeProcess do SWF_INB_CONF só influencia até o status "Enviado ao serviço de assinatura digital", certo? Ou estou enganado?

Agradeço desde já.

At.,

Bernardo Braga

[former_member182114 · Accepted solution]

Bom dia Bernardo,

De que tempo ruim estamos falando? 10s, 1min?

Acontece sempre ou em momento de pico?

Como está a quantidade de NF-es para o SIGNN?

Seu PI é exclusivo para NF-e ou compartilhado com outras aplicações?

Você usa HSM ou o SLL-NFE-JWS (java da SAP)?

Você implementou layout 2.0? Refez a configuração SWF_INB_CONF para o SIGNN do layout 2.0?

O tempo de ida e volta do lote também está alto? Tipo /xnfe/bat_hist entre status 02-03 e 04-05

Atenciosamente, Fernando Da Ró

[Former Member · Accepted solution]

1) 1 minuto em horário comercial, 10 segundos de madrugada.

2) Momentos de fluxo maior, PICO que é entre 15:00 e 17:30 leva 1 minuto e 30 segundos na média

3) PI é compartilhado, GRC esta em mandante separado. E tem uma instância JAVA exclusiva para NF-e.

4) SLL-NFE-JWS

5) Layout 2.0 implementado. 80% das empresas no 2.00 e 20% na 1.10

6) Refiz a configuração SWF_INB_CONF para 2.00 tambem. Tenho 6 queues para SIGNN_SignNFeProcess 2.00 e 6 para SIGNN_SignNFeProcess 1.10

7) Tempo de ida e volta do lote esta com tempo razoavel: Horário de PICO (agora) esta: 45 segundos (02-03) e 55 segundos (04-05)

obs.: Volume de NF-e aqui é bem alto: em torno de 10.000 notas por dia.

At.,

Bernardo Braga

[former_member182114 · Accepted solution]

Bom dia Bernardo,

Dica, pegue esta NF-e que demorou 1 minuto e tanto e veja na mensagem SXI_MONITOR, tem uma informação "Performance Header" com tempos específicos para cada passo dentro do PI... Se for HTTP_SEND então é entre esta máquina e o assinador, se for DB_ENTRY ou DB_QUEING é tempo de espera em fila (mais provável).

O fato do PI ser compartilhado pode estar gerando estar provocando este delay, acompanhe na SMQ2 como estão as filas do PI para os workflows de signature (veja o WS000000 respectivo na SWF_INB_CONF) e monitore, se tiver ficando em fila pode ser necessário aumentar o tempo.

Cada mensagem que o GRC manda pro PI tem um fluxo de filas mais ou menos assim:

fila XBTS no client do GRC

fila XBTI no client do PI

fila workflow XBPE$WSxxxxx no client do PI

fila XBTO no client do PI

fila XBTR no client do GRC

Você tem que observar seu sistema para diminuir a quantidade registros retidos nas filas. A quantidade de filas XBTI/XBTO é controlada pelos parms EO_OUTBOUNT_PARALLEL (default 10) e EO_INBOUND_PARALLEL (default 3).

Outra coisa, não adianta ter várias filas se não tem Work Process suficientes para elas. Monitore a quantidade de WP em uso/disponível (SM50/SM66) e quantidade de recursos RFC (ARFC).

Atenciosamente, Fernando Da Ró

[henrique_pinto · Accepted solution]

Bernardo,

olhando, de maneira geral, eu diria que os tempos poderiam ser bem melhores. 45 e 55 segundos pra BATCH e BATSR nao é de maneira alguma um tempo bom. SIGNN por ser interno apenas deveria estar demorando 3 a 5 segundos tops.

Qual a configuracao da maquina do PI/GRC?

Outra pergunta, nesse horario de pico (15 as 17:30) é pico apenas de faturamento (i.e. + NFes) ou tem pico de execucao de alguma outra interface nao-NFe pelo PI também?

Eu sugeriria a realizacao de um tunning nesse sistema. É possível que algumas parametrizacoes possam estar inadequadas.

Quanto à sua pergunta, a configuracao da SWF_INB_CONF influencia o tempo de execucao do BPM que realiza as comunicacoes (assinador, sefaz). Ou seja, ela influenciaria o quão mais rápido vc teria suas NFes em status "Assinado" e não apenas "enviado para assinatura" (esse status na verdade nao depende de BPM, é gerado pelo GRC sincronamente assim que ele dispara o proxy de envio p/ o assinador, i.e. interface SIGNN outbound).

Abs,

Henrique.

[Former Member · Accepted solution]

Obrigado pelas respostas.

Configuração da máquina não sei dizer, vou procurar me informar.

15:00 as 17:30 é horário de PICO para TUDO...rs.

SMQ2 esta tranquilo. Nâo fica nada retido. É raro alguma fila chegar a 10 mensagens. Só quando ocorre alguma carga ou algum processo específico (fora do normal).

Analisando o PerformanceHeader, encontrei o seguinte:

(7 segundos- no RESPONSE - mandante PI)

<SAP:RunTimeItem>

<SAP:Name type="DBQUEUE">DB_ENTRY_QUEUING</SAP:Name>

<SAP:Timestamp type="begin" host="xxxxxxxxxx">20110209191417.126121</SAP:Timestamp>

</SAP:RunTimeItem>

<SAP:RunTimeItem>

<SAP:Name type="DBQUEUE">DB_ENTRY_QUEUING</SAP:Name>

<SAP:Timestamp type="end" host="xxxxxxxxxx">20110209191424.533367</SAP:Timestamp>

</SAP:RunTimeItem>

(10 segundos- no RESPONSE - mandante PI)

<SAP:RunTimeItem>

<SAP:Name type="DBQUEUE">DB_SPLITTER_QUEUING</SAP:Name>

<SAP:Timestamp type="begin" host="xxxxxxxxxx">20110209191424.566969</SAP:Timestamp>

</SAP:RunTimeItem>

<SAP:RunTimeItem>

<SAP:Name type="DBQUEUE">DB_SPLITTER_QUEUING</SAP:Name>

<SAP:Timestamp type="end" host="xxxxxxxxxx">20110209191434.836676</SAP:Timestamp>

</SAP:RunTimeItem>

Quanto ao TUNING vou procurar me informar.

At.,

Bernardo Braga

[former_member182114 · Accepted solution]

Bom dia Bernardo,

Outra coisa, você no ERP utiliza impressão automática?

Se sim, você seguiu umas dicas sobre colocar todo o código da BAdI CALL_RSNAST00 para dentro de uma função e chamar assíncronamente?

Pelo seguinte, isto também tem um impacto enorme na performance, já que todas interfaces assíncronas voltam ao GRC pela fila XBTR independente de ser BATCH, NFesc, signn, signc, sigs, skipr, BATSR... Daí vou te dar um exemplo: Imagina que na XBTR tem duas entradas... a em execução um BATSR com retorno da Sefaz com 50 NF-es e a próxima entrada desta fila XBTR é um retorno de assinatura querendo "voltar" ao GRC...

Agora, para cada NF-e seu ERP demora 2 segundos na parte da impressão automática ou qq coisa que você execute além do standard por lá, 50 x 2 = 100 segundos que o SIGNN ficou esperando na fila.

Verifica isso também.

Atenciosamente, Fernando Da Ró

[henrique_pinto · Accepted solution]

Além de ver a SMQ2, veja na SM50 se seus Dialog WPs ficam sempre cheios ou se vc tem sempre alguns poucos em idle.

Se vc tem 6 filas pra SIGNN e cada fila tem 10 entradas, vc tem 60 notas em paralelo, o que nao é pouco.

Ainda, as filas ficam com varias entradas durante muito tempo? Isso pode ser indicativo de que as filas estao demorando pra ser executadas, ou seja, que vc tem mais filas do que Work processes disponíveis. A analise da SM50 em horário de pico pode ajudar a identificar isso.

Qtas filas vc tem pra BATCH & BATSR 005 & 006?

Note que vc já tem 12 filas p/ SIGNN (6 de 005 & 6 de 006).

O fato de vc ter dobrado o # de filas p/ 006 pode ser indicativo de que o # de WPs nao está sendo suficiente e daí vc fica com fila parada. Nessa situacao (# de filas > # de WPs), qto mais filas, pior. Se sua nota tem sorte de entrar numa fila processada, blz. Se tiver o azar de cair numa fila parada, ferrou. Se tivesse uma fila só, demorava mas processava todas. Ou seja, o ideal nao é crescer indefinidamente o numero de filas, mas apenas enquanto vc tem WPs disponiveis.

E como o Fernando falou, isso é apenas pra execucao do Business Process Engine (BPE).

Pro Integration Engine (IE), vc tem ainda filas de processamento de interfaces inbound & outbound assincronas, acks etc.

Entao vc nao pode ocupar 100% dos seus WPs só com BPMs. Se vc executar o BPM rapido mas a msg demorar 1 minuto pra sair do PI e voltar pro GRC, na pratica nao adiantou nada. Entao, procure ocupar no maximo uns 50% dos seus WPs com as filas de BPM.

Abs,

Henrique.

[former_member182114 · Accepted solution]

Resumindo tunning = observação, ajuste, observação, ajuste, observação, ajuste, observação, ajuste....

[Former Member · Accepted solution]

Boa tarde.

Verifiquei com BASIS e a maquina esta sobrando. As filas nunca acumulam e os Dialog WPs nunca ficam cheios.

Acho que o problema pode mesmo estar na BAdI CALL_RSNAST00.

A um tempo atrás coloquei a chamada CALL FUNCTION 'J_1BNFE_CALL_RSNAST00' dentro de uma função e chamar assíncronamente. Porém gerou outros problemas pois haviam outros processos dentro do método "call_rsnast00" que "dependiam" do final da execução da função "J_1BNFE_CALL_RSNAST00". Tive que voltar a versão.

Estou pensando agora em colocar TODO o código do método if_ex_cl_nfe_print~call_rsnast00 dentro de uma função. Da seguinte forma:

METHOD if_ex_cl_nfe_print~call_rsnast00.

CALL FUNCTION 'Z_RFC_NFERFCIMPRESSAO' IN BACKGROUND TASK.

ENDMETHOD.

Dentro da Z_RFC_NFERFCIMPRESSAO coloco tudo que tinha dentro do método "METHOD if_ex_cl_nfe_print~call_rsnast00".

At.,

Bernardo Braga

At.,

Bernardo Braga

[former_member182114 · Accepted solution]

Bom dia Bernardo,

É isto mesmo, todo o conteúdo da call_rsnast00 deve ir para dentro da função Z:

Observação: No seu exemplo só tá faltando os parametros e também o commit work para disparar o in background task.

Manda ver, vai funcionar bonito.

Atenciosamente, Fernando Da Ró

[Former Member · Accepted solution]

Vai ficar assim então:

METHOD if_ex_cl_nfe_print~call_rsnast00.

CALL FUNCTION 'Z_RFC_ZBMHRI016' IN BACKGROUND TASK

EXPORTING

I_ACTIVE = I_ACTIVE.

COMMIT WORK.

ENDMETHOD.

Quando conseguir transportar para PRD (deve demorar um tempo) posto aqui o resultado.

Obrigado mais uma vez.

At.,

Bernardo Braga

[former_member182114 · Accepted solution]

Bom dia Bernardo,

BTW: Estava no seu sistema hoje vendo uma mensagem e aproveitei para dar uma olhada nisso, vi casos de XBTR com mais de um minuto segurando a fila, então vai isso aí vai ficar SHOW !!!

Mas não é tudo, sua internet ou proxy estão atrapalhando também. Veja no cliente do PI transação SWI_DURA2, filtro TODAY, sub-workflows que os processos externos de NF-e estão bem altos (alguns com 30s de MÉDIA), enquanto o de assinatura que é interno está normal 1s.

Veja com a equipe de infra se eles tem um proxy melhor ou um outro canal de internet para usar.

Atenciosamente, Fernando Da Ró

[Felipe_Silveira]

Olá Bernardo.

Você pode tentar melhorar a performance ao fazer o ajuste de configuração de batch para carregar mais NFEs em menos batches.

Pode ainda testar o resultado de aumentar o tempo para recheck de batch, quando estiver em processamento plea Sefaz, para algo como 60 segundos.

Espero ter colaborado com seu problema.

Atenciosamente,

Felipe Silveira

[Former Member]

Felipe, boa tarde.

Na minha visão o tempo para incluir a nota no lote esta entre "Assinado" e "Incluído no lote". Este tempo é rapido. Não tenho problema.

O problema esta antes, entre "Enviado ao serviço de assinatura digital" e "Assinado".

Neste caso acredito que a formação do lote não deva influenciar.

At.,

Bernardo braga