Dúvida

Quais são as melhores práticas com relação a Integrações e ações para evitar travamentos?

Solução

Neste artigo você verificará as melhores práticas com relação a Integrações e ações para evitar travamentos.

1. Por que ocorrem travamentos?

Em geral, travamentos em rotinas do sistema geralmente são ocasionados por esperas do banco de dados (grande parte delas são locks).

Abaixo seguem exemplos de rotinas personalizadas que podem causar travamento em processos (são práticas que devem ser veementemente evitadas):

• Chamadas de Serviços que executem operações longas. Exemplo:
  • A rotina personalizada chama um WebService A;
  • Esse WebService A chama o WebService B;
  • Esse WebService B chama o WebService C;
  • O WebService C chama uma regra personalizada;
  • A regra personalizada chama um Relatório;
  • E assim sucessivamente...
     
• Chamadas de WebServices de maneira Síncrona ou Assíncrona que possam vir a manipular os mesmos registros que estão sendo manipulados pela sessão atual do sistema (se a sessão atual não é finalizada no mesmo momento em que há a chamada do WebService). Exemplo:
  • Abrir transação dentro do WebService customizado, chamando um WebService nativo que já possui controle de transação (chamando ele de maneira Síncrona) e fechando a transação posteriormente o retorno do WebService nativo;
  • Chamada de WebService customizado de maneira assíncrona, com diversas operações a serem executadas no banco de dados, e apenas depois do processo executado, é efetuado o commit no banco de dados. Esse processo assíncrono pode concorrer com transações abertas em diversas outras sessões do sistema.

• Entrada de Pedidos via WebService Customizado, seguindo a lógica abaixo:
  • WebService customizado para entrada de Pedido era chamado de forma Síncrona;
  • O WebService customizado abre uma transação com banco de dados;
  • O WebService customizado efetua um "SELECT FOR UPDATE" na tabela E078ULT para identificar numeração de código de Cliente;
  • Após essa numeração identificada, dentro da Regra do WebService customizado, efetuada a chamada do WebService Nativo de Cadastramento de Cliente de forma síncrona;
    • Esse WebService nativo também utiliza "SELECT FOR UPDATE" na tabela E078ULT;
  • Após o processo de cadastro do Cliente, seria então chamado o WebService nativo de integração de Pedido;
  • Neste cenário, nunca chegava a chamar o WebService de Pedido, porque no cadastramento de Clientes já ocorria Lock na tabela E078ULT, travamento todo o processo de cadastramento de Clientes da base de dados, devido a concorrência de registros, causada pela má estruturação da customização.

2. Boas práticas de integração

2.1. Conteúdo e Conceitos

• Praticamente em 100% dos modelos de utilização do Gestão Empresarial | ERP atualmente existem integrações com pelo menos um sistema;
• Cada vez mais há necessidade de rapidez, assertividade, resiliência na execução das rotinas;
• Todos devem ser responsáveis pela saúde da integração: tanto quem expõe o dado como quem consome este dado.
  • Quando falamos de integração, falamos de dois (ou mais) sistemas que atuam com uma mesma informação. Esses sistemas são responsáveis por garantir a saúde da integração.
  • Exemplo de prática para garantir a saúde das integrações: cuidado na execução das requisições para não haja solicitações desnecessárias ao sistema Gestão Empresarial | ERP.

2.2. Boas Práticas Gerais para Integrações

Abaixo segue uma lista de boas práticas gerais para integrações:

• Evitar processos de integração longos (Não querer salvar o mundo dentro de um único processamento).
  • Exemplo: Entrada de Pedidos, Geração de Títulos no Contas a Receber; Compensação de Títulos, Geração de Boletos, tudo dentro de um grande processo;
• Separar por especialidade: Um WebService deve fazer o que ele está proposto a fazer, e não fazer diversas coisas dentro dele. Ele pode fazer uma etapa e um segundo WebService fazer outra;
• Orquestrar o envio e processamento: o que vai antes, o que vai depois;
• Definir responsabilidades pelo orquestramento: a responsabilidade do orquestramento precisa estar mapeada e bem definida (Será o Gestão Empresarial | ERP ou será um sistema externo?);
• Quando é preciso que as informações sejam processadas: pode ser que a informação precise ser integrada online (agora), pode ser que a informação possa ser integrada dentro de uma janela, pois ela só é utilizada no outro dia (podendo fazer um fatiamento de processamento de informações);
• Diluir ao longo do tempo: esse tema se aplica diretamente as informações presentes no artigo ERP - Performance/Lentidão/Travamentos - Quais são as melhores práticas com relação a Consumo de Recursos e Resiliência (Filas de Integração);
• O que pode ser separado e como pode ser separado? Essa definição é muito importante para questões de escalabilidade de processos;
• Pensar arquiteturalmente, indo além da solução de cenário único. Não adianta só resolver um pedaço do processo, é necessário pensar no processo como um todo;

• Pensar olhando para os recursos de infra/instancias disponíveis, pois eles são limitados e precisam ser bem aproveitados.

   

Abaixo você poderá visualizar uma imagem que ajuda na interpretação de um cenário de processamento.

Informações para interpretação dessa imagem:

• Considere que você possui um processo X, onde o tempo completo de processamento é de 01:00 (1 minuto);
• Se você utiliza a estratégia de um único processo único (sem fatiar ele em etapas), para executar 5 processos desses completos, você tem 5 minutos de tempo de processamento (observe o lado esquerdo da imagem acima);
• Se você utiliza a estratégia de fatiar esse processo em etapas (no caso da imagem, foi utilizado o exemplo de 5 etapas), para executar 5 processos desses completos, você tem 2 minutos de processamento (considerando 60 segundos dividido por 5, que daria 12 segundos por etapa, mas ainda está se arredondando para 15 segundos cada etapa);
  • Neste cenário de etapas, você perceberá que quando uma etapa termina para um processo, ela já inicia para outro processo, sendo executado sequencialmente;
  • Todos os registros demorarão o mesmo tempo completo de processamento, mas utilizando o conceito de "fatiar" em menores processos, você consegue paralelizar o processamento, onde no final o término de todos as execuções somadas, será muito menor.
• No exemplo acima, no comparativo das estratégias de execução, você poderá ter 5 processos executando em 5 minutos, ou 5 processos executando em 2 minutos.

2.3. Boas práticas para entrada de dados no Gestão Empresarial | ERP

O exemplo abaixo a ser dado é um exemplo prático de entrada de dados no Gestão Empresarial | ERP, para processo de integração de Vendas (Notas Fiscais).

Importante

Lembre-se de que você não deve “resolver tudo numa única requisição”. Esse tipo de abordagem gera mais locks mais longos, o que é insustentável em grandes volumes de processamento.

Problema: Sistema externo não tinha as seguintes informações:

• código de cliente;
• código de série fiscal;
• código de transação;
• código de forma de pagamento;
• código de condição de pagamento;
• Dentre outras informações que são necessárias para chamadas de WebServices nativos do sistema Gestão Empresarial | ERP.

Solução "normal“: Fazer tudo dentro do mesmo serviço customizado. Ou seja;

• Buscar todas as informações;
• cadastrar o que falta;
• Ir chamando os WebService nativos para fazer os processamentos;

Solução Otimizada: 

• Momento/Fase 1: armazenado os dados de entrada em tabelas de usuário e devolvido ao sistema externo indicando ao sistema externo que os dados já estão com o ERP;
• Momento/Fase 2: Processo que ajusta os dados (cliente, série, condição de pagamento, forma de pagamento, e qualquer outra informação necessária);
• Momento/Fase 3: Processo que cadastra os clientes (aqueles casos em que os Clientes ainda não existiam);
• Momento/Fase 4: Processo que processa os documentos (que já estão todos prontos para fazer a integração);
• Momento/Fase 5: Processo que roda de X em X tempo limpando as tabelas intermediárias envolvidas, eliminando os registros já processados (isso diminui o tamanho das tabelas envolvidas e não onera execução de comandos de busca de dados nessas tabelas);
  • Como boa prática ainda, antes de limpar esses registros da tabela principal da integração, pode ser enviado o registro para uma tabela de histórico (tabela essa que não será acessada regularmente).

Resultados obtidos com essa estratégia:

• Possibilidade de tratar ordenação de registros pra evitar deadlocks;
• Possibilidade de paralelizar envios por filial;
• Diminuição expressiva do tamanho das transações com os bancos de dados (diminuindo também a incidência de locks e deadlocks).

2.4. Boas práticas para execução de processos posteriores a autorização de um documento no eDocs

Para a boa prática que será compartilhada abaixo, leva-se em consideração o conceito de processos pequenos para suportar grandes operações, onde há necessidade de estruturar em etapas/estágios evolutivos (estruturar as rotinas para pensar em N estágios).

Problema: Retorno de autorização de NF-e do eDocs - Uma rotina customizada de compensação de títulos e outra de ressuprimento eram realizadas junto com identificador de regras VEN-140NEIMPBO, dentro da transação de autorização do documento. Isso trazia os seguintes impactos:

• Segurava processamento dos retornos e ocasionava grandes locks na base de dados;
• Gerava fila de retorno do eDocs para o ERP;
• Retornava timeout de processamento para o eDocs, o que fazia o eDocs reenviar os mesmos documentos para o ERP novamente;

Solução Otimizada: 

• Adicionadas "filas" para esse processamento em segundo momento (com utilização de tabelas intermediárias para controle das filas);
• Vazão muito maior de processamento, garantindo processamentos paralelos, em travamentos.
   

2.5. Limpeza de informações que sejam temporárias

Neste ponto, cabe frisar a limpeza de dados temporárias (em tabelas intermediárias de integração, por exemplo), como também Logs de processamento.

A limpeza das estruturas temporárias/customizadas precisam ser verificadas por quem criou as estruturas.

Para maiores informações sobre limpeza de Logs, verifique os artigos específicos sobre este tema citados no artigo  ERP - Performance/Lentidão/Travamentos - Onde é possível encontrar informações diversas sobre questões relacionadas a Performance/Lentidão/Travamentos (índice) .

2.6. Boas práticas para integração de dados em Lotes

Quando falamos de integrações, elas devem ser efetuadas de maneira agrupada sempre que possível, pois esse tipo de abordagem é melhor dentro da arquitetura atual do Gestão Empresarial | ERP. Isso porque para envio de integrações de forma unitária temos:

• Tempo de "pedágio", até ser invocado o ws levantar a instancia, realizar login, trocar empresa e filial;
• Há uma maior concorrência, entre diversas instancias de Middleware, que processam mesmos registros, principalmente quando relacionados ao mesmo contexto de negócio;
• Há um eventual "estouro" do número de instancias disponíveis – (consumo de recursos).

Além disso, é muito importante a priorização para enviar ao ERP conjunto de registros que pertençam ao mesmo contexto pai. Exemplo: Enviar primeiro pedidos da mesma Empresa/Filial, para depois  enviar outro pacote de integração para outra Empresa/Filial (isso diminui a necessidade do sistema efetuar trocas de Empresa/Filial diversas vezes durante o processamento de uma mesma requisição).
 

Para maiores informações sobre o processamento de requisições em lotes, verifique o artigo  ERP - Performance/Lentidão/Travamentos - Quais são as melhores práticas com relação a Consumo de Recursos e Resiliência (Filas de Integração).

2.7. Boas práticas relacionadas a validação de dados enviados para integração sem chamadas adicionais à outros sistemas para buscar dados

No que tange a garantia de performance em processamento, é necessário garantir:

Somente Informações válidas efetivadas no negócio devem ser enviadas para processamento do ERP (não adianta enviar dados incompletos que baterão em validações padrões do sistema);
Integrações sempre devem ocorrem em via única, não devendo "voltar para validar dados". Quando o ERP recebe uma informação no WebService, ela deve ser completa. Não deve haver dependência do ERP fazer chamada ao sistema que enviou os dados nesse mesmo momento para pegar mais informações que estão faltando. Se necessário, fazer uso de WebServices Customizados para receber dados e utilizar o recurso já citado no tópico "2.3. Boas práticas para entrada de dados no Gestão Empresarial | ERP" deste artigo.

2.8. Boas práticas relacionadas a informações inválidas em Filas de Pendência

Necessário tratar filas de integração e forma que haja mecanismo para tentar X vezes e parar o processamento do registro depois de X tentativas, caso tenha dado erro nesse número de vezes.

Esse tipo de abordagem:

• Evita processamento desnecessário;
• Evita que informações que precisem ser integradas, demorem mais por ficarem no fim da fila (e a fila de pendências está ainda processando registros que já causaram diversos erros anteriormente).

Para maiores informações sobre o Fila de Processamentos, verifique o artigo  ERP - Performance/Lentidão/Travamentos - Quais são as melhores práticas com relação a Consumo de Recursos e Resiliência (Filas de Integração).

2.9. Boas práticas para visibilidade de problemas e acompanhamento de integrações

Eventuais problemas de integração precisam ser expostos para que os usuários tratem os registros e retirem os erros dos processamentos dos registros. Esse tipo de visibilidade pode ser dado através de notificações a usuários quando algum problema ocorre ou até mesmo com painéis de acompanhamento de integração, conforme exemplo abaixo:

2.10. Boas práticas para ordenação de informações

É necessário haver uma tratativa relacionada a ordenação dos registros integrados em lote para que cheguem ordenados no processamento do sistema para evitar deadlock

Uma das ordenações que mais causa impacto positivo no processamento do ERP é a ordenação da entrada de pedidos/notas fiscais pelo Código do Produto/Serviço e Derivação.

Esse tipo de ordenação "segue" todo o caminho dentro do ERP (sendo replicado para todas as operações posteriores). Em um cenário real, esse tipo de ordenação já trouxe os seguintes benefícios:

• De 40% de deadlocks para integração de pedidos para 0 deadlocks;
• De 10 pedidos por minuto para 30 pedidos por minuto.

2.10. Boas práticas relacionadas a exportação de dados

No que tange o processo de exportação de dados e integrações, é necessário faz uso das melhores práticas indicadas abaixo:

• Somente ativar integrações que realmente serão utilizadas (Tanto no ERP XT quanto no Senior X):
  • Pergunta para ser respondida: Alguém irá consumir dados referentes a essa integração? Caso a resposta seja "Não", então não deve haver a ativação da integração.
  • Para maiores informações sobre pendências desnecessárias de integração com Senior X, verifique o artigo TECNOLOGIA - Integração Senior X - Pendências de integração na tabela RTC_PENDENCIES afetando a performance do sistema;
• Para Integrações via WebServices:
  • Processo de limpeza de pendencias exportadas deve estar ativado (processo agendado de Rotina 160). Para maiores informações, verifique o artigo ERP - WebServices - Como efetuar a limpeza da tabela de controle de registros integrados (E000CIX);
• Processo de Re-pendenciamento deve estar ativado e configurado adequadamente de acordo com o fluxo do Cliente. Neste processo de re-rependenciamento é necessário validar:
  • Tempo de recorrência do processo agendado;
  • Separação do processo de re-pendenciamento por assunto/integração, garantindo que o processo seja executado apenas para sistemas/registros que faça sentidno haver o rependenciamento.
  • Para maiores informações sobre o processo de Re-pendenciamento, verifique o artigo ERP - WebServices - Como garantir que um registro não integrado no sistema integrado seja reexportado pelo Gestão Empresarial | ERP;
• Uso da integração para seu fim específico:
  • Não usar mecanismo de pendencias para realizar uma carga completa todo dia (ou seja, todo dia efetuar uma chamada de exportação de todos os dados, com Tipo de Integração como "T - Todos").
    • O processo de exportação "A - Somente Alterados" deve ser utilizado para dados incrementais;
    • Quando há necessidade de uma Carga Completa diária de dados, é orientado a criação de forma customizada de exportar esses dados, sem uso dos artefatos nativos do sistema (porque eles não foram criados para essa finalidade de Carga Inicial diária).
• Impor responsabilidade ao Consumidor dos dados (sistema integrado):
  • Quem está consumindo o WebService do ERP Senior deve ter responsabilidade ao consumir os WebServices.
  • Como exemplo de responsabilidade de Consumo de dados, no tópico anterior foi citado a questão de utilização da exportação de registros com o tipo de integração "T - Todos" com Carga Inicial Diária, onde o ERP permite esse tipo de chamada, no entanto, o WebService não foi criado para isso. Então, cabe ao sistema integrado ter a responsabilidade da chamada adequada do WebService, levando em conta o conceito ao qual se aplica o ERP. Não é porque é possível fazer a chamada desta forma que diariamente de que está correto efetuar essa chamada.

2.11. Outras boas práticas que devem ser consideradas

Verifique no artigo ERP - Performance/Lentidão/Travamentos - Onde é possível encontrar informações diversas sobre questões relacionadas a Performance/Lentidão/Travamentos (índice) outros artigos que compartilham boas/melhores práticas para diversos outros processos do sistema.

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