A continuación se presenta una lista de los eventos en los que el sistema obliga al motor a recalcular:
Los datos sin procesar e intermedios se pueden agregar después del tiempo real en que ocurrieron. Un ejemplo sería un caso en el cual algún origen del evento estaba inactivo y no recibía los datos. Cuando los nuevos datos se agregan, el motor recalcula a partir de la marca de tiempo del evento agregado. Por ejemplo, el valor del dólar se introdujo a final del mes. Sin embargo, todos los cálculos del mes entero se basan en el valor del dólar en ese momento. Por lo tanto, el motor vuelve al inicio del mes y recalcula utilizando el nuevo valor.
Los datos se pueden corregir incluso después de que se hayan calculado. Las correcciones sustituyen los datos sin procesar.
Nota: Esta situación no ocurre con datos intermedios, en los que no se pueden agregar correcciones.
Cuando una corrección se agrega, el motor debe encontrar que ocurría un estado anterior al cambio. El motor empieza a recalcular la métrica con los datos corregidos nuevos incluidos en el cálculo a partir de ese momento.
Por ejemplo, si un usuario introdujo por error el número 5 como datos sin procesar la semana pasada. El usuario reemplaza el 5 por 3. El motor debe recalcular desde la fecha en que se introdujo el 5. El número 3 se utiliza en lugar de 5.
NOTA: Una corrección puede ser meramente una supresión de datos incorrectos, sin que haya que reemplazarlos por nuevos datos.
Se reciben eventos basado en el registro para:
Cuando cambia un recurso, el motor recalcula a partir del punto en el que cambió un recurso. Un ejemplo de este recálculo es la asignación o la supresión de un recurso de un grupo de recursos o el cambio del valor de un atributo personalizado de recurso.
En un caso en que una lista de servidores tiene una indicación en curso de su estado, el servidor 3 se retiró para el mantenimiento. Se elimina el servidor 3 sin una notificación de sistema. El usuario le notifica al sistema que el servidor 3 no existía durante el período de mantenimiento. El motor retrocede y recalcular desde la fecha en que se eliminó el servidor 3.
Cuando se realiza un cambio en el atributo personalizado de un recurso, el motor recalcula todas las métricas que se asocian con el recurso. Las métricas se recalculan desde la fecha en la que cambió el atributo personalizado.
Por ejemplo, un escenario en el cual los servidores se encuentran en Nueva York, Chicago y Los Ángeles. El usuario decide incluir los servidores de Chicago en el grupo de Nueva York. A continuación, el gestor decide que los servidores de Chicago forman en realidad parte del grupo de Los Ángeles y cambia el estado de los servidores de Chicago. El motor debe recalcular.
Las excepciones se pueden crear para períodos de tiempo definidos. Por ejemplo, hay un período de tiempo que se define como en horas de trabajo normales, pero hay una excepción debido a una interrupción de potencia. Esta excepción elimina el intervalo de tiempo especificado de las horas de trabajo normales. Los eventos se controlan todavía aunque se consideran fuera de la ranura de tiempo. Una vez que se distingue de la rutina normal, se puede definir el comportamiento fuera de ranura de tiempo en el script de lógica de negocios. Sin embargo, el usuario aún no puede definir cómo se porta el motor durante el período de tiempo de la excepción. El comportamiento no se puede modificar del comportamiento estándar de fuera de la ranura de tiempo. Las excepciones se pueden definir antes del período de tiempo real o después. Cuando se agrega una excepción a un período de tiempo que haya calculado el motor, se recalcula para tener en cuenta la excepción.
Por ejemplo, hay un caso en que se realizó una notificación de interrupción de alimentación hace una semana. El sistema realizó los cálculos hasta el momento actual, sin tener en cuenta la interrupción de alimentación. Se necesita un recálculo en este caso.
La lógica de negocios definida por el usuario se puede crear en cada métrica separada. Además, si la lógica es central y tiene que reutilizarse, se puede colocar dentro de un módulo de lógica de negocios. Esto permite al usuario crear la lógica una vez y utilizarla en múltiples métricas. Sin embargo, cuándo se cambia el módulo para corregir un error en la lógica, se cambian todas las métricas que se vinculan al módulo. Estas métricas se deben recalcular para explicar esta corrección.
Por ejemplo, si el usuario tiene varios clientes y todos ellos desean una métrica de Help Desk. La lógica de Help Desk se puede colocar en un módulo de lógica de negocios.
La reutilización de eventos es una función que permite al usuario crear métricas que utilicen los resultados del cálculo de otras métricas como entrada. Este tipo de datos se llaman datos intermedios. Para crear estos datos se hace que una métrica envíe eventos que sean similares en estructura a los datos sin procesar. La métrica receptora se registra a esta métrica de envío y recibe los eventos que se enviaron de la misma forma en que una métrica recibe eventos de datos sin procesar. Si se recalcula la métrica de envío, debe suprimir los eventos que envió previamente y recalcular el período de tiempo que requiere el recálculo. Esto significa que los datos intermedios que envió anteriormente no están actualizados. Las métricas que se registran para recibir estos datos también deben recalcularse para explicar los nuevos datos.
Al crear una versión del contrato, parte o la totalidad de la métrica contenida se recalcula desde el inicio de la versión del contrato. Este recálculo se realiza solamente para las métricas en que se haya realizado algún cambio desde la versión anterior. No recibe recálculo si crea una versión del contrato y la confirma directamente. No se realiza ningún recálculo, ya que las métricas contienen cambios.
En los siguientes casos, no hay recálculo:
Una nueva versión del contrato se considera un cálculo, no un recálculo, así que no aparece en el historial de recálculos.
Por ejemplo, hay un contrato de tres años con la empresa ABC. Amplía el contrato durante un año adicional. Este cambio crea una nueva versión del contrato. ACE1 recalculará la métrica desde el 1 de enero de 2005.
No se realiza ningún cambio si tiene un contrato con 100 métricas y crea una versión y cambia el parámetro de UNA de las métricas. Las demás métricas no se recalculan.
Nota: Si se realizan cambios en el pasado lejano, se provoca un recálculo largo. Este recálculo tarda mucho tiempo, ya que las métricas afectadas tienen que recalcularse desde el momento del cambio.
|
Copyright © 2013 CA.
Todos los derechos reservados.
|
|