Implementierungshandbuch › Implementierung › Business-Logik-Skripting (Business-Logik-Experte) › Innerhalb der Business-Logik › Eventfluss

Eventfluss

Wie zuvor erwähnt, sind die Eingaben für die Business-Logik die Engine-Events und die Rohdaten-Events.

Von der Business-Logik empfangene Rohdaten-Events werden von der Erfassungsfunktion bestimmt, bei der der Code einen bestimmten Satz an Rohdaten-Events anfordert, die durch ihren Event-Typ und den Ressourcen-Bezeichnern definiert werden.

In der Business-Logik ordnet die Erfassung auch eine benutzerspezifische Subroutine zu, die ausgeführt wird, um das Rohdaten-Event zu verarbeiten, sobald ein Event erfasst wird. (Standardmäßig ist dies das OnXXXEvent, das sinnvoll umbenannt werden sollte.)

Die Engine-Events werden von der Engine entsprechend den zugeordneten Vertrags- und Metrik-Definitionen ausgelöst. Sobald das Engine-Events ausgelöst und empfangen wird, führt die Engine die angemessene Eventroutine aus. Jedes Engine-Event hat eine implizite Eventroutine. Diese Eventroutinen sind Funktionen und Verfahren, die oben im VBScript definiert sind. Die Eventroutine, die die Erfassung ausführt, und die "Ergebnis"-Funktion müssen beide zwingend in den Code implementiert werden. Alle anderen Eventroutinen sind optional. Allerdings befasst sich die Business-Logik nicht mit Engine-Event, für die keine Eventroutinen implementiert wurden. Deswegen ist es eine gute Vorgehensweise, sie an Ort und Stelle zu belassen (auch wenn nicht verwendet werden), um zukünftige Erweiterungen zu ermöglichen.

Hinweis: Beim Schreiben des Business-Logik-Skripts ist es wichtig, alle Engine-Events zu implementieren, um alle endgültigen Möglichkeiten abdecken zu können. Auch wenn zum Beispiel während der ersten Phase der Implementierung keine Zeitfenster-Definition verfügbar war, dies jedoch zukünftig der Fall sein sollte, dann müssen alle Formeln geändert werden. Es wird daher empfohlen, dass der Business-Logik-Experte das Verhalten "in timeslot" und "out of timeslot" weit im Voraus festlegt, auch wenn diese Verhaltensweisen anfänglich nicht verfügbar sind. So sind die erforderlichen Änderungen geringfügig, wenn das Verhalten eingeführt wird.

Nachfolgend finden Sie verschiedene Engine-Events und ihre Eventroutinen:

• OnLoad (Time) - (optional) wird einmal zu Beginn der Berechnungen aufgerufen, wenn der Vertrag aktiviert wird. Kann für die Initialisierung globaler Variablen verwendet werden.
• OnRegistration (Dispatcher) - (erforderlich) Methode, mit dem die relevanten Rohdaten-Events angefordert und mit den benutzerspezifischen Verfahren verknüpft werden, mit denen sie verarbeitet werden. Die Events werden angefordert und mithilfe der Methoden des Dispatcher-Objekts mit den Verfahren verknüpft.
  OnRegistration - wird von der Berechnungs-Engine einmal am Anfang der Metrik-Berechnung und dann jedes Mal, wenn eine für die Metrik registrierte Ressource wirksam wird, aufgerufen. Daraufhin beurteilt die Engine den Satz von Änderungen, die an dieser Ressource vorgenommen wurden und sich auf den Eventsatz auswirken können, der an die Formel weitergeleitet wird. Die Engine umfasst die Definition der Event-Anfrage, die vom Event-Typ und den Ressourcen-Bezeichnern definiert wird, und in den Fällen, in denen sich eine Ressource (oder ein Änderungssatz, der mehrere Ressourcen enthält) ändert, etwas, dass sich auf diesen Satz bezieht. Sobald es in Kraft tritt, wird ein Event Handler OnRegistierung ausgelöst.
• OnPeriodStart (Time)-(optional), am Anfang des Agentenzeit-Zeitraums aufgerufen (wird gemäß der Zeiteinheit festgelegt). Der erste OnPeriodStart wird ausgelöst, sobald der Vertrag in Kraft tritt, wobei die Bilanz der Zeiträume in ganzen Stundenzeiteinheiten anfängt. Dieser Event Handler wird üblicherweise verwendet, um in regelmäßigen Abständen Variablen zu initialisieren, wie beispielsweise einen Zähler, der die Anzahl an Vorfällen, die während des Berechnungszeitraums geöffneten wurden, feststellt, die dann zu Beginn eines jeden Zeitraums auf Null initialisiert werden sollten.
• OnPeriodEnd (Time,IsCompleteRecord) -(optional), wird am Ende des Agentenzeit-Zeitraums aufgerufen (gemäß der Zeiteinheit festgelegt). Es wird immer am gerundeten Ende der Zeiteinheit in runden Stunden aufgerufen (zum Beispiel 24:00). "IsCompleteRecord" ist "Wahr", wenn der Zeitraum der Metrik beendet ist (gemäß der Realitätszeit des Anwendungsservers), und "Falsch", wenn eine Zwischenberechnung durchgeführt wird. Dieser Event-Handler wird üblicherweise verwendet, um letzte Berechnungen für den Endzeitraum durchzuführen, und so die Grundlage für das von der Ergebnisfunktion gelieferte Endergebnis zu schaffen.
• OnTimeslotEnter (Time)-(optional), wird aufgerufen, wenn ein TimeSlot-Zeitraum gemäß der zugewiesenen metrischen Definition eingegeben wird. Beispiel: Wenn die Metrik mit einer Zeitfensterdefinition von Geschäftszeiten verbunden ist, wo jeden Tag um 08:00 ein Zeitfenster beginnt, wird der Event-Handler an jedem Tag um diese Uhrzeit ausgelöst.
• OnTimeSlotExit (Time)-(optional), wird aufgerufen, wenn ein TimeSlot-Zeitraum gemäß der zugewiesenen metrischen Definition eingegeben wird. Beispiel: Wenn die Metrik einer Zeitfensterdefinition von Geschäftszeiten zugewiesen ist, wo jeder Tag um 17:00 Uhr das Ende einer Zeitspanne ist, dann wird dieser Event Handler an jedem Tag um diese Uhrzeit ausgelöst.
• Target()-(optional), wird aufgerufen, wenn für die Metrik ein dynamisches Ziel festgelegt ist. Dadurch können Sie das Service Level-Ziel einer Metrik während der Business-Logik-Laufzeit bestimmen. Zu diesen Zielen können der Verbrauch von Servicekomponenten oder Infrastrukturänderungen zählen. Sie besteht aus vier Werten, wie bei der Ergebnisfunktion; einen für jeden Modus. Diese Funktion wird nach der Ergebnisfunktion im Rahmen der normalen Ausführung ausgeführt.
• Forecast()-(optional), wird ein Mal aufgerufen, wenn eine Übernahme der Vertragsversion durchgeführt wird, bei der die Berechnungs-Engine den Vertrag ein Mal in einem Prognosemodus kalkuliert. Der Prognosemodus führt einen vollen Berechnungs-Engine-Zyklus des Vertrags durch (vom Anfangs- bis zum Enddatum der Vertragsversion). In diesem Zyklus werden nur die Prognosewerte berechnet. (Es sind keine Berechnungen in der Tabelle T_RAW_DATA vorhanden). Diese Funktion wird statt der Ergebnisfunktion in diesem Ausführungsmodus, aufgerufen.
• Result()-(erforderlich), wird von der Berechnungs-Engine aufgerufen, um das Berechnungsergebnis für einen bestimmten Zeitraum zu erhalten. Die Ergebnisfunktion wird stets nach dem Event Handler OnPeriodEnd aufgerufen.

Nachfolgend sind die Schritte aufgeführt, denen der Berechnungsmechanismus (PslWriter-Service) zur Verarbeitung einer einzelnen Business-Logik-Formel folgt:

• PslWriter lädt die Formel in den Arbeitsspeicher und führt jede Erklärung aus, die im Abschnitt "Erklärungen" vorhanden ist (dieser Abschnitt "Erklärungen" umfasst jeglichen Code, der sich außerhalb einer Funktion oder Subroutine befindet). Beachten Sie zudem, dass alle angehängten Module und Bibliotheken eingeschlossen sind und zur Durchführung in dieses einzelne Codemodul kompiliert werden.
• PslWriter ruft den Event Handler OnLoad auf.
• PslWriter den Parameter OnRegistration auf.
• Bei der Berechnung des Zeitraums wird mit dem Aufrufen von OnPeriodStart begonnen.
• Für jedes während der OnRegistration protokollierte Rohdatenereignis, das in den Zeitbereich des Zeitraums fällt, ruft PslWriter den diesem Event zugewiesenen, benutzerspezifischen Event Handler auf.
• Wenn der Anfang oder das Ende des Zeitfensters in den Zeitbereich dieses Zeitraums fällt, wird OnTimeslotEnter oder OnTimeSlotExit aufgerufen.
• Wenn es eine relevante Infrastrukturänderung innerhalb des Zeitraums gibt, wird OnRegistration aufgerufen.
• Die Berechnung des Zeitraums endet mit dem Aufruf von OnPeriodEnd.
• Wenn ein dynamisches Ziel festgelegt wurde, wird diese Funktion aufgerufen.
• PslWriter ruft die Ergebnisfunktion auf, um das Endergebnis der Zeitraumberechnung zu erhalten.

  Hinweis: Wenn die Vertragsversion zuerst übernommen wird, und eine Prognose ausgewählt wurde, wird die Prognosefunktion statt der Ergebnisfunktion aufgerufen. Dies trifft allerdings nur dieses eine Mal für jede Version zu.

Während jedes Berechnungszyklus bewertet die Engine, auf worauf die entsprechenden Engine-Events und Rohdatenereignisse im Berechnungszeitraum basieren. Sie sortiert sie zunächst nach der Zeit und sendet dann die relevanten Formeln zur Berechnung. Die Zeit des Rohdatenereignisses ist sein Zeitstempel; die Zeit des Engine-Events ist seine Aktivierungszeit. Beide Eventtypen werden dann in einer Zeitsequenz zusammengeführt und zur Berechnung gesendet.

Das Timing der Events entspricht der zugewiesenen lokalen Metrik, Parameter "Time" der Event-Handler (d. h. OnPeriodStart (Time)) und der Zeitstempel des Rohdatenereignisses entsprechen ihrem UTC-Wert. Die Engine vergleicht sie gemäß ihren UTC-Werten, um so einen konstanten Bezugspunkt zu verwenden.

Beispiel:

Wenn der Zeitzonenunterschied einer UTC-Metrik zwei Stunden (d. h. GMT+2) beträgt, und ein Vorfallöffnungs-Event einen Zeitstempel von 10.00 Uhr hat, wird er Zeitstempel, den der Event Handler nutzt, in der Engine entsprechend verschoben und beginnt tatsächlich um 8.00 Uhr UTC. Ausgehend von der Annahme, dass der Adapter auf die Nutzung derselben Zeitzone konfiguriert ist, werden die Rohdatenereignisse auch in der Datenbank um 2 Stunden zurück auf UTC-Zeit zurückgesetzt. Wenn die Events zur Business-Logik weitergeleitet werden, nutzt der Berechnungsagent, der für die Berechnung der Events für den Zeitraum ab 10.00 Uhr zuständig ist, eigentlich die UTC-Zeit aller Events ab 8.00 Uhr. Wenn Sie die Meldung out.log im Code zum Ausdrucken der Zeitstempel verwenden, wird trotz des festgelegten Zeitraums von (gemäß der Metrik) 10.00 Uhr der auf UTC verschobene Zeitstempel - also 8.00 Uhr - angezeigt.

In der folgenden Berechnungsanforderung muss der Zeitstempel des Events konvertiert werden, bevor sie angewendet wird:

Wenn eine Metrik in der Berechnung der Häufigkeit von Vorfällen besteht, die an demselben Tag geschlossen wurden, an dem sie eröffnet wurden, muss die Öffnungs- und Schließungszeit eines jeden Vorfalls verglichen werden. Wenn die Öffnungs- und Schließungszeit des Vorfalls auf denselben Zeit fällt (und in dasselbe definierte Zeitfenster), wird der Vorfall gezählt.

Es kann passieren, dass sich der Tag bei der Verschiebung des Vorfalls von der ursprünglichen Lokalzeit zur UTC-Zeit ändert (d. h. dass wieder GMT+2 verwendet wird). (Ein Vorfall, der um 1.00 Uhr geöffnet wird, wird in UTC zurück auf 23.00 Uhr am Vortag verschoben). Er wird dann nicht gezählt, selbst wenn er eigentlich hätte gezählt werden müssen. Dies ist eine Situation, in der die Zeit zunächst zurück in die lokale Metrik-Zeit konvertiert werden muss, und erst dann verglichen werden kann. Verwenden Sie in einem solchen Fall die Methode GetLocaleTime(utcTime). Bei dieser Methode wird eine Zeit in einer UTC-Zeitzone in die entsprechende Zeitzone der lokalen Metrik konvertiert.

Nachfolgend finden Sie den Event Handler-Code:
Sub OnIncidentEvent(eventDetails)
   If dateDiff("d",Tools.GetLocaleTime(eventDetails.time),_
     Tools.GetLocaleTime(eventDetails("ClosedAt)))=0 then
          CountIncidents=CountIncidents+1
   End If
End Sub