Guía de implementación › Ejemplos de casos prácticos › Ejemplos de escritura de lógica de negocios vigente

Ejemplos de escritura de lógica de negocios vigente

En los temas siguientes se ofrecen recomendaciones para escribir de forma eficaz lógicas de negocios:

• Métricas en clúster
  • Al evaluar el volumen de sistema, cuente una métrica en clúster como el número de elementos en la métrica y recuerde que todo se multiplica.
  • El recálculo de un elemento de clúster implica el recálculo de todo el clúster. Por tanto, recuerde tenerlo en cuenta cuando planifique el agrupamiento en clúster, la forma en la que se configuran los adaptadores y al cambiar la estructura de recursos.
  • Los mismos eventos de datos sin procesar que van a muchos elementos de clúster tienen un alto coste de rendimiento (conmutación de contexto).
• Variables globales
  • Obtenga valores de atributos y parámetros en cada lugar del código que necesitan. Evite guardarlos en una variable global, especialmente en métricas en clúster (aumenta el tamaño de los "estados").
  • Evite la lógica que procesa grandes asignaciones. En cambio, procese cada evento en el método OnXXEvent
  • Elimine elementos de asignaciones tan pronto como sea posible. Por ejemplo, cuando se cierra un ticket y al final del período.
• Patrones de diseño

  El paquete de contenido predeterminado contiene varios patrones de diseño para escenarios comunes. Utilizar estos patrones de diseño puede mejorar el rendimiento.

• Funcionalidad incorporada

  ACE tiene herramientas y funcionalidad incorporada para diversas finalidades, como las siguientes:

  • Funcionalidad de ranura de tiempo
    • NetTime
    • IsWithinTimeslot
  • Tiempo de eventos
    • TimeOfLastEvent
    • TimeOfLastEventHandler
  • Context Object
    • Contiene muchos métodos sensibles al entorno
    • Utilice estos métodos y evite "ODBC seguro".
• Resultados de lógica de negocios

  Guarde la estructura en T_SLALOM_OUTPUTS. Esto significa que si tiene varias tablas de lógicas en T_SLALOM_OUTPUTS que tengan una estructura similar, es muy útil colocar campos lógicos similares en el mismo campo físico. Esto facilita la indexación fácil para un rendimiento de informes mejorado.

• Reutilización de evento

  Para utilizar cuando:

  • Varias métricas están realizando un cálculo de primera fase, que es necesario para el contrato, y envían eventos a una métrica de resumen que calcula el resultado (p.ej. cálculo financiero, indicador de clave de rendimiento de alto nivel).
  • Una única métrica está realizando una agregación preliminar en datos sin procesar y envía eventos a otras métricas. La métrica envía considerablemente menos eventos que los que obtiene o realiza cálculos significativos que, de otra forma, realizaría muchas veces.

  Para evitar cuando:

  • Aumenta de forma significativa el número de métricas.
  • Se implementan más de tres niveles.
  • La complejidad de la implementación aumenta y el mantenimiento se vuelve más difícil.
• Recálculos
  • Evite recálculos masivos como parte del funcionamiento normal del sistema.
  • Los motivos de los recálculos son:
    • Datos sin procesar con una marca de tiempo anterior.
    • Singularidad del evento que cambia datos sin procesar en el pasado.
    • Correcciones
    • Excepciones
    • Cambios en los módulos de lógica de negocios
    • Cambios en un contrato
    • Eventos de reutilización de eventos con una marca de tiempo anteriormente
    • Cambios en la estructura de recursos
  • Considere usar la funcionalidad de bloqueo de datos calculado
• Módulos de lógica de negocios
  • Los módulos de lógica de negocios se deberían escribir de forma que, una vez que se hayan revisado por completo, no tengan que modificarse.
  • La directriz es: un módulo es igual a una lógica genérica.
  • Los módulos de lógica de negocios que son muy específicos no pueden servir muchas métricas y no promueven la reutilización de código y lógica.
  • Los módulos de lógica de negocios que son demasiado genéricos son difíciles de mantener. Además, si un módulo de lógica de negocios implementa muchas lógicas complejas, una corrección en un flujo (utilizado por parte de la métrica), provoca el recálculo de todas las métricas
• Registro
  • Realice toda la filtración de eventos utilizando el registro. El dejar la filtración al código tiene un gran impacto en el rendimiento.
  • Simplificación
  • Para el código que no es el propio registro, utilice los métodos dispatcher.IsRunTimeMode y OnResourceStructureChange, sobre todo cuando hay muchos cambios de recursos.
  • Evite utilizar el método RegisterByEventType.
  • En los módulos de lógica de negocios, utilice un formulario genérico (por parte contratante, servicio, tipo de recurso), utilice parámetros o deje el registro que hay que realizar mediante la interfaz de usuario (opción preferida para la reutilización de eventos).