Dúvida

Quais são as melhores práticas com relação a Consumo de Recursos e Resiliência (Filas de Integração)?

Solução

Importante

Este artigo tem por objetivo compartilhar informações de melhores práticas com relação a Consumo de Recursos e Resiliência.

Considere os seguintes conceitos:

• Consumo de Recursos:
  • Recorrência de execuções;
  • Consumo de Recursos de Infraestrutura;
• Resiliência:
  • Capacidade de se recuperar a paradas.

1. Consumo de Recursos

Quando falamos de Consumo de Recursos, é necessário ter em mente uma balança que precisa ser calibrada regularmente, levando em conta a Recorrência de Execuções e a Quantidade de Execuções.

Abaixo segue um cenário exemplificado de uma prática que NÃO deve ser seguida:

• Uma regra para execução em um processo agendado, para executar a cada 5 minutos;
• O select retorna uma série de linhas de uma tabela intermediária/de usuário;
• A cada linha retornada faz uma chamada de um WebService.

Neste cenário, a chamada do WebService é desnecessária a cada linha, pois ocorrerá um consumo indevido de instância de Middleware, além de haver demora no processamento da regra em si, devido as chamadas frequentes ao WebService.

1.1. Melhores práticas para garantir o balanceamento adequado de consumo de recursos

Para garantir o consumo adequado de recursos pelo sistema (em se tratando de execução de diversos processos de forma automatizada - sejam processos agendados ou chamadas de WebServices para integração, por exemplo), as melhores práticas são:

1.1.1. Definição da execução dos processos dentro de um calendário (calendário diário/semanal/mensal).

O objetivo é encaixar as diversas execuções dos diversos processos dentro desse calendário, garantindo que os processos não concorram entre si e não causem carga excessiva ao ambiente ao mesmo tempo.

Sempre que você possuir dificuldade em encaixar essas diversas execuções, monte um modelo gráfico estilo de uma agenda do Microsoft Outlook.

Inicie com a agenda em branco e vá inserindo nesta agenda os diversos processos executados no sistema. Desta forma, você terá uma visão clara e gráfica destes processos.

1.1.2. Melhores práticas gerais para os processos e integrações

• As horas são fracionadas. Então você pode fracionar a execução de processos dentro de minutos (para não ficar tudo sendo executado na mesma hora - 09:00, 10:00, 11:00). Uma pergunta retórica a ser respondida: todos os processos precisam ser executados exatamente as 00:00? Uma parametrização realizada desta forma já indica uma falha de parametrização, pois não houve estudo prévio para fazer essa parametrização;
  • Leve em consideração que um dia tem 1.440 minutos para fazer execuções. Seu calendário pode espaçar as execuções de diversos processos dentro desse período;
• Avalie se o processo não pode ser executado durante o horário comercial. Pergunta retórica: por que tudo tem que ser executado fora do horário comercial? Obviamente existem processos que podem gerar concorrência de várias tabelas do sistema e precisam ser executados fora do horário comercial. No entanto, outros processos podem ser executados dentro de um horário em que ainda há utilização do sistema, porém com menor volume de dados trafegados.
• A geração de pendências de exportação (acesso a tabela E000CIX) de forma incorreta pode impactar muito todos os processos. Para maiores informações, verifique o artigo ERP - WebServices - Problemas de performance relacionados ao acesso à tabela E000CIX devido as pendências de integração ativados na tabela E000SXT;
• Paralelismo: utilize o conceito de paralelismo sempre que não houver concorrência entre os dados trafegados/manipulados nos diversos processos que precisam ser executados;
  • Faça o entendimento dos artefatos (tabelas/campos) que são envolvidos no processo para determinar a possível concorrência. Neste ponto, você pode utilizar recursos como SQLMon e trace no banco de dados.
• Pensando no Calendário, faça ou verifique o mapeamento do todo e reserve só a sua parte para execução. Pense no todo, limite as execuções dos processos que você quer executar;
• Você realmente precisa ter realmente a informação em tempo real? Essa pergunta precisa ser realizada para garantir qual o objetivo de ter alguma informação de forma OnLine/Síncrona. Exemplo: você realmente precisa ter o saldo de Duplicatas do Cliente atualizado em tempo real? Se não há justificativa para isso, a atualização Online desse dado pode ser desativada um processo automático posterior pode ser parametrizado para essa atualização;
• Evite picos de processamento que podem impactar a Performance. Um processo precisa ser realmente realizado a cada 15 minutos, não pode ser a cada 52 minutos, por exemplo?
  • Lembre-se de que a ativação de um novo processo (seja ele agendado ou não) pode ativar a necessidade de revisão de outros processos que já estejam em execução;
• Cada sistema integrado deve ter seu escopo definido. Quando é a hora de cada sistema se comunicar ou esperar para enviar a integração? Isso é algo que você precisa avaliar;
• Nem tudo que a área de negócio solicita é o que a área de negócio de fato precisa para executar seu processo. Busque entender a real necessidade para o tráfego de informações no sistema, focando na necessidade e não na solução, pois a solução sistêmica pode estar bem distante do que tenha sido identificado em uma primeira análise.

1.1.3. Melhores práticas para chamadas de WebServices dentro das regras LSP (e que pode ser utilizado para chamadas de WebServices de forma externa também - sistema de terceiros)

Seguem melhores práticas recomendadas:

• Validar previamente todas as informações possíveis: os WebServices do sistema Gestão Empresarial | ERP possuem diversas validações. No entanto, dependendo do processo a ser realizado, haverá um longo caminho de processamento até que bata em uma consistência, e então haverá o rollback do processo. Neste cenário, haverá um custo de processamento do WebService e do banco de dados, para que no final não haja confirmação da integração. Então, é importante que tudo que possa ser validado previamente para evitar esse tipo de cenário, seja validado.

  • Um exemplo bem simples de um cenário que pode ser validado: é enviado ao ERP o processamento de uma Nota Fiscal de Saída para um Cliente Inativo. O sistema poderá validar que o Cliente está inativo. Se ocorre essa validação, então ela poderia ser verificada antes da chamada do WebService da Nota Fiscal, verificando se o Cliente está de fato ativo para somente após isso disparar a chamada do WebService da Nota Fiscal de Saída.

   

• Evitar processamentos pesados, limitando a quantidade de registros: a quantidade de registros processados na mesma chamada do WebService pode impactar diretamente na Performance (quando maior o processamento, maior o risco de algum problema de performance). É necessário tratar processamentos em lotes.

   

• Cuidado ao utilizar WebServices de forma assíncrona: disparar vários WebServices assíncronos pode consumir todas as instâncias do Middleware e causar travamento generalizado. O uso de WebService assíncrono é recomendável para grandes volumetrias, mas precisa ser utilizado com total conhecimento dos impactos e com os controle adequados das filas de processamento, garantindo a utilização adequada dos recursos.

1.1.4. Processos que envolvem os mesmos artefatos sendo executados simultaneamente

É necessário garantir que processos que façam uso dos mesmos artefatos (como por exemplo, mesma tabela da base de dados), sejam configurados de forma a não ocasionar locks/deadlocks e nem interfiram entre si nas operações.

Como exemplo de um cenário que não deve ser seguido, será utilizado como exemplo processos que fazem acesso à tabela E000CIX. Verifique a imagem abaixo:

Nesse exemplo, temos 3 processos distintos sendo disparados todo dia as 00:01 e eles fazem acesso à tabela E000CIX ao mesmo tempo. Além disso, são processos complexos e que podem ter uma demora de execução.

Neste cenário, os seguintes problemas:

• Ocorrência de Locks e Deadlocks indesejados;
• Perda de informações (porque um processo faz a limpeza do registro enquanto que outro faz o registro);
• Dados duplicados (porque o registro era gerado por um processo, limpo por um processo e re-gerado pelo primeiro processo);

Motivos para essa situação ocorrer:

• Mesmo horário e execução;
• Mesma tabela base.

A solução para esse cenário foi configurar os processos automáticos que atuam sobre a mesma informação como sucessores, conforme exemplo abaixo:

Importante

O exemplo dado acima é um exemplo simplista envolvendo 3 processos. Em uma realidade de ambiente do Cliente, mais processos podem estar envolvidos em uma cadeia de configuração de processos agendados em cascata.

Atenção

Tome cuidado para analisar cada caso especificamente. A utilização de processos sucessores/em cascata é uma solução válida para vários cenários, mas você deve levar em consideração de que é também importante utilização de processos paralelizados sempre que possível, para que haja ganho no tempo de processamento de grandes volumes de dados. O ponto chave está justamente nessa questão: é necessário distinguir os processos que podem ser paralelizados dos processos que devem ser executados como sucessores/em cascata.

Para maiores informações sobre processos sucessores, verifique o artigo ERP - Processos Automáticos - Quais as melhores práticas com relação a definição de Processos Sucessores.

1.2. Processos automáticos e seus usuários (e o que isso pode impactar na Performance e execução das rotinas)

A definição de usuários adequados para execução dos processos agendados pode impactar tanto na Performance da execução das rotinas como também na facilitação de análise de incidentes relacionados a esses processos.

Por este motivo, é de extrema importância que você verifique as informações presentes no artigo ERP - Processos Automáticos - Quais as melhores práticas com relação a definição de usuários de execução de Processos Automáticos.

2. Resiliência

Quando falamos de resiliência, estamos falando da capacidade de uma rotina de se recuperar de eventuais falhas ocorridas.

Ainda assim, levando em conta questões relacionadas a Performance.

1.1. Resiliência em filas de integração

Para exemplificar um cenário de resiliência envolvendo filas de integração, leve em consideração o seguinte cenário hipotético de integração de Pedidos:

• Uma Integração com o Gestão Empresarial | ERP, seja por regra ou chamada de software terceiro, para integração de Pedidos;
• Há necessidade de uma preparação para os casos em que haja falhas, seja por problemas de infraestrutura, comunicação ou alguma inconsistência do Web Service;
• Há necessidade de que o processo não fique em looping de reprocessamentos de pedidos que precisem de ajustes para serem integrados.

Neste cenário, aplica-se um processo de melhor prática que:

• Envie ao WebService do ERP os Pedidos em Lote controlados;
• Criação de filas paralelas para envio e reenvio de pedidos com erro (depois de tratados).
• Faça ordenações e saneamentos nas filas de envio ao WebService;
  • Evitar envio de pedidos que há conhecimento que ocorrerá erro;
  • Ordenar o envio de alguns dados dentro do pedido para garantir maior Performance (exemplo: ordenação por código de Produto)
• Paralelizar o envio de pedidos em Pedidos Ímpares e Pedidos Pares;
• Utilizar uma fila específica para envio dos pedidos que tiveram um erro em um primeiro momento e permitir (via uma interface ao usuário) que o usuário tome ações para correção dos registros:

Estratégias adicionais muito bem vindas para esse cenário:

• Integrar os pedidos no ERP em tabelas intermediárias (de usuário) dentro do ERP (que podem ser populadas através de WebServices customizados);
• Fazer o saneamento e validação dos dados antes de chamada do WebService nativo de Pedidos para fazer a integração, evitando erros na chamada do WebService;
• Nesta tabela poderá existir o conceito do controle sobre as filas de integração (conforme já mencionado acima).

Atenção

As tabelas nativas do sistema Gestão Empresarial | ERP não deve de forma alguma ser utilizada para fazer algum tipo de controle de filas/semáforos para esse tipo de integração (Exemplo: criar um capo de controle na tabela E120PED).

Abaixo segue um fluxo simples que descreve o processo acima, separando em Filas de processamento:

E juntamente com essas filas de integração, é necessário ter um controle dos registros que estão sendo integrados (um semáforo), que permitirá o controle completo do processo, evitando diversos problemas como, por exemplo, integração de registros em duplicidade por processos de integração que rodem paralelamente.

Abaixo seguem informações sobre um cenário onde esse semáforo é uma excelente solução:

E abaixo segue uma visão de fluxo exemplo, tratando o cenário acima, reunindo um conceito e Fila de Integração e Semáforo de Controle:

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).