Manuel d'implémentation › Implémentation › Ecriture de scripts de logique applicative (expert en logique applicative) › Détails sur la logique applicative › Flux d'événements

Flux d'événements

Comme nous l'avons mentionné, les entrées de la logique applicative sont les événements de moteur et les événements de données brutes.

Les événements de données brutes reçus par la logique applicative sont déterminés par la fonction d'enregistrement, dans laquelle le code demande une définition spécifique des événements de données brutes définis par leur type d'événement et leur identificateur de ressource.

Dans la logique applicative, l'enregistrement associe également une sous-routine définie par l'utilisateur, qui est exécutée afin de gérer l'événement de données brutes une fois qu'un événement est reçu. (Valeur par défaut, c'est l'événement OnXXXEvent, qui doit être renommé de façon plus explicite.)

Les événements de moteur sont déclenchés par le moteur d'après les définitions des contrats et les métriques associées. Lorsque l'événement de moteur est déclenché et reçu, le moteur exécute le gestionnaire d'événements pertinent. Chaque événement de moteur possède un gestionnaire d'événements implicite. Ces gestionnaires d'événements sont des fonctions et des procédures définies au-dessus de VBScript. Le gestionnaire d'événements qui maîtrise l'enregistrement et la fonction result doivent obligatoirement être implémentés dans le code. Tous les autres gestionnaires d'événements sont facultatifs. Toutefois, la logique applicative ne s'occupe pas des événements de moteur pour lesquels les gestionnaires d'événements ne sont pas implémentés. Par conséquent, il est recommandé de les laisser tous en place (même s'ils ne sont pas utilisés) en prévision d'améliorations futures.

Remarque : Lors de l'écriture du script de logique applicative, il est important d'implémenter tous les événements du moteur afin de couvrir toutes les possibilités finales. Par exemple, même si pendant la première étape de l'implémentation une définition de période d'application n'était pas applicable, mais le sera dans l'avenir, toutes les formules nécessiteront une modification. Il est par conséquent recommandé que l'expert en logique applicative définisse d'avance le comportement durant la période d'application et en dehors de la période d'application, même si initialement ces définitions ne sont pas applicables, afin de réduire les modifications nécessaires lorsque le comportement sera introduit.

Voici divers événements de moteur et leurs gestionnaires d'événements :

• OnLoad (Time) (facultatif) : appelé une fois au démarrage des calculs lorsque le contrat est activé. Vous pouvez l'utiliser pour initialiser des variables globales.
• OnRegistration (Dispatcher) (obligatoire) : procédure permettant de demander les événements de données brutes pertinents et de les associer aux procédures définies par l'utilisateur avec lesquelles elles doivent être gérées. Les événements sont interrogés et associés à des procédures en utilisant les méthodes de l'objet Dispatcher.
  OnRegistration est appelée une première fois par le moteur de calcul au début du calcul de la métrique, et à nouveau chaque fois qu'une ressource enregistrée pour la métrique prend effet, après quoi le moteur évalue l'ensemble des changements effectués pour cette ressource qui peuvent influencer l'ensemble d'événements transmis à la formule. Le moteur fait définir la demande d'événement par le type d'événement et les identificateurs de ressources, et dans le cas où une ressource (ou un ensemble de modifications contenant plusieurs ressources) modifie des éléments relatifs à cet ensemble. Une fois qu'il entre en vigueur, un gestionnaire d'événements OnRegistration est déclenché.
• OnPeriodStart (Time) (facultatif) : appelé au début de la période d'agent (défini selon l'unité de temps). Le premier OnPeriodStart est déclenché une fois que le contrat entre en vigueur, lorsque l'équilibre des périodes commence par des unités de temps Ce gestionnaire d'événements est habituellement utilisé pour initialiser périodiquement des variables comme un compteur qui contient le nombre d'incidents ouvert dans la période de calcul qui devrait ensuite être initialisée à zéro au début de chaque période.
• OnPeriodEnd (Time,IsCompleteRecord) (facultatif) : appelé au début de la période d'agent (défini selon l'unité de temps). Il est toujours appelé à la fin arrondie de l'unité d'heure dans des heures arrondies (par exemple, 24:00). IsCompleteRecord est vrai lorsque la période de la métrique est terminée (en fonction de l'heure réelle du serveur d'applications), et est faux dans le cadre d'un calcul intermédiaire. Ce gestionnaire d'événements est habituellement utilisé pour effectuer les derniers calculs pour la période de fin afin de préparer au résultat final qui sera fourni par la fonction Result.
• OnTimeslotEnter (Time) (facultatif) : appelé lors de l'entrée dans une période d'application basée sur la définition de métrique associée. Par exemple, si la métrique est associée à une définition de période d'application des heures ouvrables où chaque jour à 08:00 heures du matin correspond au début de période d'application, dans ce cas ce gestionnaire d'événements sera déclenché tous les jours à cette heure.
• OnTimeSlotExit (Time) (facultatif) : appelé lors de l'entrée dans une période d'application basée sur la définition de métrique associée. Par exemple, si la métrique est associée à une définition de période d'application des heures ouvrables où chaque jour se termine à 17:00 heures, dans ce cas ce gestionnaire d'événements sera déclenché tous les jours à cette heure.
• Target() (facultatif) : appelé lorsque la métrique est spécifiée comme ayant une cible dynamique. Cela vous permet de déterminer la cible de niveau de service d'une métrique pendant l'exécution de la logique applicative. Ces cibles peuvent inclure la consommation de composants de service ou des changements d'infrastructure. Il contient quatre valeurs, comme la fonction Result, soit une pour chaque mode. Cette fonction est exécutée après la fonction Result au cours de l'exécution normale.
• Forecast() (facultatif) : appelé une fois au cours d'une action de validation de la version de contrat en faisant calculer une fois par le moteur de calcul le contrat en mode de prévision. Le mode de prévision exécute un cycle de calcul complet sur le contrat (de la date de début à la date de fin de la version du contrat). Ce cycle n'a pour seul objet que de calculer les valeurs prévisionnelles. (Aucun calcul n'est effectué sur la table T_RAW_DATA table). Cette fonction est appelée à la place de la fonction Result au cours de ce mode d'exécution.
• Result() (obligatoire) : appelé par le moteur de calcul pour obtenir le résultat du calcul pendant une période donnée. La fonction Result est toujours appelée après le gestionnaire d'événements OnPeriodEnd.

Les éléments suivants sont les étapes suivies par le mécanisme de calcul (service PslWriter) pour traiter une formule de calcul de logique applicative unique :

• PslWriter charge la formule dans la mémoire et exécute toutes les instructions dans la section de déclarations (la section de déclarations comprend tout le code situé à l'extérieur d'une fonction ou d'une sous-routine). Notez également que tous les modules et les bibliothèques joints sont inclus et compilés dans ce module de code unique pour l'exécution.
• PslWriter appelle le gestionnaire d'événements OnLoad.
• PslWriter appelle OnRegistration.
• Le calcul de la période commence par l'appel à OnPeriodStart.
• Pour chaque événement de données brutes enregistré pendant OnRegistration qui correspond à la plage horaire de la période, PslWriter appelle le gestionnaire d'événements défini par l'utilisateur associé à cet événement.
• Si le début ou la fin de la période d'application correspond à la plage horaire de la période, OnTimeslotEnter ou OnTimeSlotExit sera appelé.
• S'il y a un changement d'infrastructure pertinent dans la plage horaire de la période, OnRegistration sera appelé.
• Le calcul de la période commence par l'appel d'OnPeriodEnd.
• Si une cible dynamique a été spécifiée, cette fonction sera appelée.
• PslWriter appelle la fonction Result afin de recevoir le résultat final du calcul de période.

  Remarque : Lorsque la version de contrat est d'abord validée et qu'une prévision a été sélectionnée, la fonction Forecast est appelée au lieu de la fonction de résultat. Cette opération, toutefois, se produit uniquement dans ce cas pour chaque version)

Pendant chaque cycle de calcul, le moteur évalue quels sont les événements de moteur et les événements de données brutes pertinents en fonction de la période de calcul. Il va les trier d'abord par heure, puis les envoyer aux formules pertinentes pour être calculés. L'heure de l'événement de données brutes est son horodatage et le moment de l'événement de moteur est son heure de déclenchement. Ces deux types d'événement sont alors combinés dans une séquence de temps et envoyés pour être calculés.

Les périodes des événements sont basées sur la métrique locale associée, mais le paramètre Time des gestionnaires d'événements (c.-à-d., OnPeriodStart (Time)) et l'horodatage de l'événement de données brutes sont basés sur leur valeur UTC. Le moteur les compare en fonction de leurs valeurs UTC pour utiliser un point fixe de référence.

Exemple :

Si la différence UTC de fuseau horaire d'une métrique est de deux heures (c.-à-d. GMT+2), et que la valeur d'horodatage d'un événement d'ouverture d'incident est 10:00 heures du matin, l'horodatage utilisé par le gestionnaire d'événements dans le moteur sera en fait déplacé en conséquence et démarrera réellement à 8:00 heures du matin UTC. En supposant que l'adaptateur est configuré pour utiliser ce même fuseau horaire, les événements de données brutes seront également reculés de 2 heures UTC dans la base de données. Lorsque les événements sont transmis à la logique applicative, l'agent de calcul chargé du calcul des événements pendant la période démarrant à 10:00 heures du matin utilisera en fait l'heure UTC pour les événements, c-à-d 8:00 heures du matin. Toutefois, si vous utilisez le message out.log dans le code pour imprimer les horodatages, il indiquera que l'horodatage a adopté le temps UTC et affichera donc 08:00 heures du matin, bien que la période spécifiée (selon la métrique) est 10 heures du matin.

Dans la condition de calcul suivante, il est important de convertir l'horodatage de l'événement avant de l'utiliser :

Si une métrique est de calculer le nombre d'incidents qui ont été clôturés le même jour de leur ouverture, il est nécessaire de comparer l'heure d'ouverture et l'heure de fermeture de chaque incident. Si l'ouverture d'un incident et l'heure de fermeture correspondent au même jour (et dans une période d'application définie), l'incident sera pris en compte.

Il est possible que durant le processus d'adoption de l'heure UTC par l'incident à partir de son heure locale d'origine, le jour change. (c.-à-d. utilisation de GMT+2). Un incident ouvert à 1 heure du matin sera reculé à 23 heures UTC du jour précédent). Il ne sera alors pas compté même s'il devait l'être. Il s'agit d'une situation où le temps doit être reconverti en heure métrique locale, puis seulement alors comparé. Dans ce cas, utilisez la méthode GetLocaleTime(utcTime). Cette méthode convertit une heure donnée dans un fuseau horaire UTC en un fuseau horaire de la métrique locale.

Les informations suivantes sont le code de gestionnaire d'événements :
Sub OnIncidentEvent(eventDetails)
   If dateDiff("d",Tools.GetLocaleTime(eventDetails.time),_
     Tools.GetLocaleTime(eventDetails("ClosedAt)))=0 then
          CountIncidents=CountIncidents+1
   End If
End sub