Guía de implementación › Implementación › Scripting de lógica de negocios (experto en la lógica de negocios) › Dentro de la lógica de negocios › Flujo de eventos

Flujo de eventos

Como se ha indicado previamente, las entradas en la lógica de negocios son los eventos de motor y los eventos de datos sin procesar.

Los eventos de datos sin procesar por parte de la lógica de negocios vienen definidos por la función de registro dentro de la cual el código solicita un conjunto específico de eventos de datos sin procesar definidos por su tipo de evento y los identificadores de recurso.

En la lógica de negocios, el proceso de registro también asocia una subrutina definida por el usuario que se ejecuta para gestionar el evento de datos sin procesar una vez que se recibe un evento. (De forma predeterminada, se trata del evento OnXXXEvent, cuyo nombre se deberá cambiar por uno más significativo).

El motor activa los eventos de motor según las definiciones de contrato y las métricas asociadas. Una vez el evento de motor se activa y recibe, el motor ejecuta el controlador de eventos pertinente. Cada evento de motor tiene un controlador de eventos implícito. Estos controladores de eventos son funciones y procedimientos definidos sobre el VBScript. El controlador de eventos que gestiona el proceso de registro y la función "result" son ambos elementos de implementación obligatoria en el código. El resto de los controladores de eventos son opcionales. No obstante, la lógica de negocios no gestiona eventos de motor para los cuales no se han implementado controladores de eventos. Por lo tanto, es recomendable incluirlos todos (aunque no se usen) para permitir realizar futuras mejoras.

Nota: Al escribir el script de lógica de negocios es importante implementar todos los eventos de motor de manera que se cubran todas las posibilidades finales. Por ejemplo, si hubiera habido una definición de ranura de tiempo no aplicable durante la primera etapa de la implementación pero sí aplicable en el futuro, entonces todas las fórmulas requerirán modificación. Por lo tanto, se recomienda hacer esto para que el experto en la lógica de negocios defina por adelantado el comportamiento de períodos "en la ranura de tiempo" y "fuera de ranura de tiempo", aunque en un principio no sea aplicable; así, cuando se introduzca el comportamiento, los cambios del sistema necesarios serán de poca envergadura.

A continuación se incluyen varios eventos de motor y sus controladores de eventos:

• OnLoad (Time): (opcional), se le invoca una vez al iniciar los cálculos cuando el contrato se está activando. Se puede utilizar para inicializar variables globales.
• OnRegistration (Dispatcher): (necesario), procedimiento para solicitar los eventos de datos sin procesar relevantes y asociarlos con los procedimientos definidos por el usuario con los que gestionarlos. Se solicitan los eventos y se asocian con procedimientos mediante los métodos del objeto Dispatcher.
  El motor de cálculo invoca a OnRegistration una vez al iniciar el cálculo de la métrica y otra vez cada vez que entra en vigencia un recurso registrado para la métrica, tras lo cual el motor evalúa que el conjunto de cambios hechos para ese recurso que pueden influir en el conjunto de eventos transmitidos a la fórmula. El motor tiene la definición de la solicitud de evento definida por los identificadores de tipo de evento y de recursos y por si un recurso (o un conjunto de cambios con varios recursos) cambia algo relacionado con este conjunto. Una vez vigente, se activa un controlador de eventos OnRegistration.
• OnPeriodStart (Time): (opcional), se le invoca al iniciarse el período de tiempo del agente (definido según la unidad de tiempo). El primer OnPeriodStart se activa una vez el contrato entra en vigencia, donde el balance de los períodos empieza con horas redondeadas como unidades de tiempo. Este controlador de eventos normalmente se utiliza para inicializar variables periódicamente, como un contador que guarda el número de incidentes abiertos dentro del período de cálculo que se deberán después inicializar en cero al principio de cada período.
• OnPeriodEnd (Time,IsCompleteRecord): (opcional), se le invoca al final del período de tiempo del agente (definido según la unidad de tiempo). Se le invoca siempre al final redondeado de la unidad de tiempo en horas redondeadas (por ejemplo, 24:00). IsCompleteRecord es verdadero cuando el período de la métrica ha terminado (según el tiempo real del servidor de aplicaciones), y es falso al hacer un cálculo intermedio. Este controlador de eventos se utiliza normalmente para hacer los cálculos finales para el período final y preparar todo para el resultado final que proporcionará la función Result.
• OnTimeslotEnter (Time): (opcional), se le invoca al entrar en un período TimeSlot basado en la definición de la métrica asociada. Por ejemplo, si la métrica está asociada a una definición de ranura de tiempo de horario comercial, donde cada día a las 08:00 AM empieza una ranura de tiempo, entonces este controlador de eventos se activará a esta hora cada día.
• OnTimeSlotExit (Time): (opcional), se le invoca al salir de un período TimeSlot basado en la definición de la métrica asociada. Por ejemplo, si la métrica está asociada con una definición de ranura de tiempo de horario comercial, donde cada día termina a las 17:00 PM, entonces este controlador de eventos se activará a esta hora cada día.
• Target(): (opcional), se le invoca cuando se especifica la métrica con un destino dinámico. Le permite determinar el destino del nivel de servicio de una métrica durante el tiempo de ejecución de la lógica de negocios. Estos destinos pueden incluir el consumo de componentes de servicio o cambios de infraestructura. Tiene cuatro valores, como la función Result; uno para cada modo. En una ejecución normal, esta función se ejecuta después de la función Result.
• Forecast(): (opcional), se le invoca una vez al confirmar la versión del contrato haciendo que el motor de cálculo calcule el contrato una vez en modo de previsión. El modo Previsión está realizando un ciclo de motor de cálculo completo en el contrato (de la fecha de inicio a la fecha de finalización de la versión del contrato). La finalidad de este ciclo es calcular solo los valores de previsión. (No se realiza ningún cálculo en la tabla T_RAW_DATA). A esta función se le invoca en lugar de a la función Result en este modo de ejecución.
• Result(): (necesario), la invoca el motor de cálculo para obtener el resultado del cálculo para un período dado. A la función Result se le invoca siempre después del controlador de eventos OnPeriodEnd.

Los siguientes son los pasos que sigue el mecanismo de cálculo (servicio PslWriter) para procesar una sola fórmula de lógica de negocios:

• PslWriter carga la fórmula en la memoria y ejecuta todas las declaraciones que hay en la sección de declaraciones (la sección de declaraciones es todo el código que está fuera de una función o subrutina). Tenga también en cuenta que todos los módulos y las bibliotecas adjuntos se recopilan e incluyen en este único módulo de código para la ejecución.
• PslWriter invoca al controlador de eventos OnLoad.
• PslWriter invoca a OnRegistration.
• El cálculo del período empieza invocando a OnPeriodStart.
• Para cada evento de datos sin procesar registrado durante OnRegistration e incluido dentro del intervalo de tiempo del período, PslWriter invoca al controlador de eventos definido por el usuario asociado con ese evento.
• Si el inicio o el final de la ranura de tiempo cae dentro del intervalo de tiempo del período, se invocará a OnTimeslotEnter o a OnTimeSlotExit.
• Si se produce un cambio de infraestructura relevante dentro del intervalo de tiempo del período, se invocará a OnRegistration.
• El cálculo del período termina al invocar a OnPeriodEnd.
• Si se ha especificado un destino dinámico, entonces se invocará a esta función.
• PslWriter invoca a la función Result para obtener el resultado final del cálculo del período.

  Nota: Cuando se confirma por primera vez la versión del contrato y se selecciona una previsión, se invoca a la función Forecast en lugar de a la función Result. Esto, sin embargo, sólo se produce una vez para cada versión.

Durante cada ciclo de cálculo, el motor evalúa cuáles son los eventos de motor y los eventos de datos sin procesar relevantes basándose en el período de tiempo de cálculo. Primero los clasificará por tiempo y a continuación los enviará a las fórmulas relevantes para realizar los cálculos pertinentes. El tiempo del evento de datos sin procesar es su marca de tiempo y el tiempo del evento de motor es su momento de activación. Estos dos tipos de eventos se combinan después en una secuencia temporal y se envían para realizar el cálculo correspondiente.

Los tiempos de los eventos se basan en la métrica local asociada, pero el parámetro de tiempo de los controladores de eventos (OnPeriodStart (Time)) y la marca de tiempo del evento de datos sin procesar corresponde a su valor en UTC. El motor los compara con sus valores en UTC para utilizar un punto de referencia constante.

Ejemplo:

Si la diferencia de zona horaria de una métrica con respecto a la hora UTC es de dos horas (GMT+2), y hay un evento de apertura de incidente con marca de tiempo 10:00 AM, entonces la marca de tiempo que el controlador de eventos usará dentro del motor se cambiará en consecuencia y se iniciará en realidad a las 8:00 AM UTC. Suponiendo que el adaptador se ha configurado para usar esta misma zona horaria, entonces la hora de los eventos de datos sin procesar se retrasará 2 horas con respecto a la hora UTC también en la base de datos Cuando se pasan los eventos a la lógica de negocios, el agente de cálculo responsable del cálculo de eventos para el período que se inicia a las 10:00 AM en realidad usará el tiempo UTC para eventos, que será 8:00 AM en adelante. Sin embargo, si utiliza el mensaje out.log en el código para imprimir las marcas de hora, mostrará que la marca de tiempo se ha cambiado a la hora UTC y, por consiguiente, mostrará 08:00 AM a pesar de que el período especificado (según la métrica) era para 10:00 AM.

En el requisito de cálculo siguiente es importante convertir la marca de tiempo del evento antes de utilizarlo:

Si una métrica es calcular el número de incidentes cerrados en el mismo día de apertura, entonces es necesario comparar la hora de apertura y de cierre de cada incidente. Si la hora de apertura y de cierre de un incidente caen en el mismo día (y dentro de una ranura de tiempo definida), el incidente se contará.

Puede suceder que durante el proceso de cambiar el incidente a la hora UTC desde la hora local original, cambie el día (usando otra vez GMT+2). Un incidente abierto a la 1:00 AM se pasará a las 11:00 PM del día anterior en hora UTC. En este caso, no se contará cuando hubiera sido necesario. En esta situación, primero hay que convertir la hora de nuevo a la hora de la métrica local y después compararla. En tal caso, utilice el método GetLocaleTime(utcTime). Este método convierte una hora dada en una zona horaria UTC a la zona horaria de la métrica local.

A continuación se incluye el código del controlador de eventos:
Sub OnIncidentEvent(eventDetails)
   If dateDiff("d",Tools.GetLocaleTime(eventDetails.time),_
     Tools.GetLocaleTime(eventDetails("ClosedAt)))=0 then
          CountIncidents=CountIncidents+1
   End If
End Sub