Dúvida

Quais são as melhores práticas para garantia de Performance na utilização de Regras LSP, Relatórios e WebServices Customizados?

Solução

Abaixo seguem informações relacionadas as melhores práticas para garantia de Performance na utilização de Regras LSP, Relatórios e WebServices Customizados

1. Funções para manipulação de dados

Abaixo seguem informações sobre algumas funções/componentes de comunicação com banco de dados que podem ser utilizados em Regras LSP e artefatos customizados. Atente-se para a verificação das melhores práticas de uso entre elas:

1.1. Definir Cursor versus Funções SQL (SQL_Criar())

Para exemplificar uma melhor prática em substituição da função Definir Cursor pelas funções SQL (SQL_Criar(), abaixo seguem exemplos práticos.

Utilizando a função "Definir Cursor" para ter acesso a dados de duas tabelas conjuntas para utilização na lógica da rotina, é necessário fazer dois acessos separados ao banco de dados (acesso em cascata). Então existe um custo de dois acessos ao banco de dados):

Utilizando as funções SQL é possível fazer um acesso único ao banco de dados, fazendo uso da função padrão do banco de dados LETF JOIN, conforme exemplo abaixo:

1.2. Informações adicionais sobre uso de Funções SQL (SQL_Criar())

As funções SQL (SQL_Criar()) permitem a utilização de comandos bem complexos no banco de dados. Abaixo seguem exemplos de funções de banco de dados que as funções SQL permite (não são somente esses, esses são apenas exemplos)

• INNER JOIN
• LEFT JOIN
• MAX, MIN, COUNT, SUM e HAVING
• UNION e UNION ALL
• CASE

Exemplo de comando complexo utilizando funções SQL:

Importante

Para utilização da função SQL de forma que possa ser executado comando nativo do banco de dados é necessário o uso dos comandos SQL_UsarAbrangencia e SQL_UsarSQLSenior2 como "0" (zero), conforme evidenciado na imagem acima.

2. Controles de transações de forma customizada (IniciarTransação(), DesfazerTrancacao() e FinalizarTransacao())

É necessário ter um cuidado redobrado no uso das funções (IniciarTransação(), DesfazerTrancacao() e FinalizarTransacao()) para:

• Garantir que toda transação com banco de dados aberta seja encerrada (desfeita ou commitada) e de forma que essas transações não fiquem muito tempo abertas no banco de dados;
• A exibição/retorno de mensagens ao usuário/rotina deve ser realizada APENAS após haver o commit da transação (FinalizarTransação()) ou após o rollback (DesfazerTransacao()). Caso não seja utilizada essa melhor prática, uma mensagem em tela retornada pela rotina poderá segurar uma transação no banco de dados e ocasionar paralização total do sistema;
• Evitar ao máximo transações longas no banco de dados, ou seja, muitas operações de INSERT, UPDATE e DELETE no meio da mesma transação com banco de dados;

3. Acionamento de funções e recursos que dependem de um retorno para dar continuidade do processo

Em questão de Regras LSP, deve-se evitar ao máximo a utilização de processos/funções que dependem de um retorno para que a regra continue sua execução, ou seja, utilizar algum tipo de chamada que utilize o conceito de processo síncrono.

Exemplo desse tipo de processo que deve ser evitado:

• Funções de Envio de E-mail;
• Chamada de API de sistema externo.

Motivo que deve-se evitar isso: o processamento da rotina interna do sistema dependerá da velocidade na qual há a comunicação externa ao ERP (Exemplo: resposta do Servidor de E-mail, resposta do sistema externo), e isso pode afetar diretamente a velocidade do processamento da rotina da regra LSP.

Como melhor prática para esses cenários, deve-se executar esses processos de forma separada (de forma assíncrona), sem haver esse tipo de chamada dentro da regra LSP.

Uma possibilidade, para esses casos, é verificar execução de processos agendados posteriores para acionar essas chamadas externas.

4. Declaração de WebService em regra LSP apenas quando ele de fato for utilizado

As regras LSP permite utilização de WebServices (tanto nativos como customizados).

A declaração do WebService na regra LSP ocorre da seguinte forma:

Definir interno.com.senior.g5.co.mcm.est.estoques.MovimentarEstoque SrvEstoque;

O exemplo acima é a declaração de um WebService de Movimentação de Estoque.

Ocorre que nem sempre um WebService é utilizado toda vez que a regra é executada.

Por exemplo: dentro de uma regra o WebService pode ser acionado somente se o a transação da NF Fiscal for igual a "5102".

Neste caso, a melhor prática para declaração do WebService é apenas declará-lo dentro dos trechos da regra onde o WebService de fato será utilizado.

Exemplo (baseado no cenário já explicado acima):

Ao invés de fazer a declaração já no cabeçalho da regra, a declaração ocorreria assim:

Se (VsCodTns = "5102")

Inicio

Definir interno.com.senior.g5.co.mcm.est.estoques.MovimentarEstoque SrvEstoque;

SrvEstoque.DadosGerais.CriarLinha();
SrvEstoque.DadosGerais.CodPro = "1101";
SrvEstoque.DadosGerais.CodDer = " ";
SrvEstoque.DadosGerais.CodDep = "DEP01";
SrvEstoque.DadosGerais.CodTns = "90204";
SrvEstoque.DadosGerais.QtdMov = "1";
SrvEstoque.DadosGerais.VlrMov = "10";
SrvEstoque.DadosGerais.DatMov = "20/06/2018";
SrvEstoque.ModoExecucao = 1;
SrvEstoque.Executar();
VMensagemRetorno = SrvEstoque.MensagemRetorno
Fim;

Abaixo seguem mais exemplos.

O que NÃO é uma melhor prática:

O que é a melhor prática:

Seguindo esse processo, você irá garantir que o sistema carregue para a memória as bibliotecas necessárias para executar o WebService declarado apenas no momento em que ele precise de fato ser executado. Para todas as demais execuções da regra em que não seja necessário executar o WebService, não haverá o carregamentos das bibliotecas relacionadas, garantindo uma melhor performance do processamento da regra.

Importante

Em um cenário onde regras são executadas constantemente e processam alto volume de registros, esse tipo de ajuste que pode parecer muito simplório poderá trazer um ganho substancial de performance.

Desta forma, é importante que você revise todas as regras LSP e WebServices customizados do seu ambiente e adeque-os utilizando o conceito descrito acima. Caso você tenha dificuldades em encontrar os WebService customizados na base do sistema, verifique o artigo ERP - WebServices - Como encontrar os WebServices/Portas customizadas na base de dados.

5. Integração customizadas de registros em um fluxo padronizado de forma paralela

Este tópico tem como objetivo demonstrar como é possível fazer uma integração customizada (baseada em Regras LSP), seguindo um fluxo padronizado de forma paralelizada sem consumir todas as instâncias do Middleware, conseguindo aproveitar da melhor forma o paralelismo (mínimo possível de concorrências e locks).

Para exemplificação desse processo, será utilizado como exemplo um processo de integração de pedidos. No entanto, essa boa prática pode ser adaptada para diversas rotinas e tipos de registros a serem integrados.

Premissas do processo de integração de pedidos que será exemplificado:

• Máximo 20 pedidos em fila para processamento;
• Cada pacote montado ao WebService terá no máximo 5 pedidos;
• 4 pedidos sendo processados simultaneamente.

Abaixo segue um fluxo macro simplificado de como seria executado o processo, de acordo com as premissas indicadas acima:

Observação

Para mais informações sobre o questões relacionadas a Performance/Lentidão/Travamentos do Gestão Empresarial | ERP, consulte o artigo ERP - Performance/Lentidão/Travamentos - Onde é possível encontrar informações diversas sobre questões relacionadas a Performance/Lentidão/Travamentos (índice).