Guia de Implementação › Exemplos de estudo de caso › Criando exemplos de lógica de negócios efetivas

Criando exemplos de lógica de negócios efetivas

As recomendações de melhor prática sobre como criar uma lógica de negócios efetiva são fornecidas nos seguintes tópicos:

• Métricas agrupadas
  • Ao avaliar o volume do sistema, contabilize uma métrica agrupada como o número de itens na métrica e lembre-se de que tudo é multiplicado.
  • Calcular novamente um item de agrupamento significa recalcular todo o agrupamento. Portanto, ao planejar o agrupamento e alterar a estrutura dos recursos, lembre-se de como os conectores serão configurados
  • Os mesmos eventos de dados brutos que vão para vários itens de agrupamento têm alto custo de desempenho (alternância de contexto)
• Variáveis globais
  • Obter os parâmetros e os valores de atributo em cada lugar no código em que são necessários. Evite mantê-los em uma variável global, especialmente em métricas agrupadas (aumenta o tamanho dos estados)
  • Evite a lógica que processa mapas grandes. Em vez disso, processe cada evento no método OnXXEvent
  • Remova os itens dos mapas o quanto antes. Por exemplo, quando um ticket é fechado e não no final do período
• Padrões de design

  O pacote de conteúdo predefinido contém vários padrões de design para cenários comuns. Usar esses padrões de design pode melhorar o desempenho

• Funcionalidade integrada

  ACE possui funcionalidade integrada e ferramentas para vários propósitos conforme segue:

  • Funcionalidade do período de atividade
    • NetTime
    • IsWithinTimeslot
  • Hora do evento
    • TimeOfLastEvent
    • TimeOfLastEventHandler
  • Objeto de contexto
    • Contém vários métodos importantes ao ambiente
    • Use esses métodos e evite a opção Safe ODBC
• Saídas da lógica de negócios

  Manter a estrutura em T_SLALOM_OUTPUTS. Isso significa que, se você possui várias tabelas lógicas em T_SLALOM_OUTPUTS com uma estrutura semelhante, é muito útil colocar campos lógicos similares no mesmo campo físico. Isso facilita a indexação de relatórios de desempenho melhorados

• Capacidade de reutilização de eventos

  Usar quando:

  • Várias métricas estiverem executando o cálculo da primeira fase, o qual, por si só, é necessário para o contrato, e enviam eventos a uma métrica de resumo que calcula o resultado (cálculo financeiro, KPI de alto nível, por exemplo)
  • Uma métrica única que executa uma agregação preliminar de dados brutos e envia eventos a várias outras métricas. Isto é razoável quando a métrica envia consideravelmente menos eventos do que recebe ou executa cálculos significativos que, de outra forma, são executados várias vezes

  Evitar quando:

  • Reduzir o número de métricas de modo significativo
  • Implementar mais de três níveis
  • Aumentar a complexidade da implementação e a manutenção se tornar mais difícil
• Novos cálculos
  • Evite novos cálculos grandes como parte da operação normal do sistema
  • Os motivos para novos cálculos são:
    • Dados brutos com data e hora no passado
    • Singularidade do evento que altera os dados brutos no passado
    • Correções
    • Exceções
    • Alterações nos módulos de lógica de negócios
    • Alterações em um contrato
    • Reutilização do evento com data e hora no passado
    • Alterações na estrutura dos recursos
  • Considere o uso da funcionalidade Bloqueio de dados calculados
• Módulos de lógica de negócios
  • Os módulos de lógica de negócios devem ser criados de uma forma que, após completamente revisados, não precisam ser alterados.
  • A diretriz consiste em: um módulo igual a uma lógica genérica
  • Os módulos de lógica de negócios que são muito específicos não podem atender a muitas métricas e não promovem a reutilização do código e da lógica
  • É difícil manter os módulos de lógica de negócios que são muito genéricos Além disso, se um módulo de lógica de negócios implementa várias lógicas complexas, uma correção em um fluxo (usado por parte das métricas), gera o novo cálculo de todas as métricas
• Registro
  • Execute a filtragem de eventos usando o registro. Permite que a filtragem do código tenha um enorme impacto sobre o desempenho
  • Torne mais simples
  • Para o código que não é o próprio registro, use os métodos dispatcher.IsRunTimeMode e OnResourceStructureChange, principalmente quando houver muitas alterações de recursos
  • Evite usar o método RegisterByEventType
  • Nos módulos de lógica de negócios, use um formulário genérico (por parte contratual, serviço, tipo de recurso), parâmetros ou deixe o registro a ser executado usando a interface do usuário (opção preferencial para a Capacidade de reutilização de eventos)