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

Agenten

Jede Metrik verfügt über eine Definition eines Kontrollzeitraums. Der Kontrollzeitraum ist der Zeitraum, in dem die Metrik ein Service Level-Ergebnis ausgeben muss. Diese Ergebnis sollte dann mit dem definierten Ziel verglichen werden. Bei dem für den Kontrollzeitraum erzeugten Ergebnis handelt es sich um das Geschäftsergebnis, mit anderen Worten, es ist das Vertragsergebnis, für das sich der Anbieter zur Bereitstellung eines bestimmten Ziel-Service Levels verpflichtet hat. Jede Instanz der Business-Logik für jeden Zeitraum wird als Agent bezeichnet. Dieser bezieht sich direkt auf die der jeweiligen Metrik zugewiesenen Granularität.

Beispiel: Wenn die Metrik mit einem Kontrollzeitraum von einem Monat definiert ist, wird die Metrik ausgeführt, um ein monatliches Ergebnis zu liefern.

Zur Bereitstellung einer Verfeinerungsoption, mit der der Benutzer das monatliche Ergebnis so verfeinern kann, dass das tägliche Ergebnis eingesehen werden kann, muss die Metrik über eine Definition weiterer Zeiteinheiten verfügen, innerhalb der sie berechnet werden sollte. Die Zeiteinheiten werden im Detailabschnitt "Allgemein" der Metrik auf der Registerkarte "Granularität" definiert.

Für jede der auf der Registerkarte "Granularität" der Metrik und für den Kontrollzeitraum definierten Zeiteinheiten wird von der Engine eine separate Business-Logikinstanz ausgeführt. Jede dieser Instanzen führt denselben Business-Logikcode aus, OnPeriodStart und OnPeriodEnd werden jedoch für jede dieser Instanzen anders aktiviert. Für die tägliche Instanz wird er am Anfang und am Ende eines Tages aktiviert. Für jede Zeiteinheit wird er gemäß den Start- und Endpunkten der Zeiteinheit aktiviert.

Jede der Business-Logik-Instanzen wird ausgeführt, um das entsprechende Zeiteinheitsergebnis zu generieren. Darüber hinaus muss jeder Zeitraum über ein Ergebnis verfügen, bei dem alle Ausnahmen berücksichtigt werden. Jeder Zeitraum, der diese Kriterien nicht erfüllt (wenn Ausnahmen definiert sind), muss seinem Benutzer die Möglichkeit zur Wahl geben, ob das Service Level-Ergebnis mit oder ohne die berücksichtigten Ausnahmen angezeigt werden soll. Aufgrund dieser Anforderung verfügt jede Metrik potenziell über 14 Agenten (Instanzen), die von der Engine ausgeführt werden, zwei Agenten für die Geschäftsergebnisse und 12 für die sechs zusätzlichen Betriebszeiträume.

Folglich hat die Granularitätsdefinition große Auswirkungen auf die Leistung der Berechnungs-Engines, da jeder Zeitraum für einen anderen Agenten berechnet wird. Daher wird in Fällen, in denen die Verfeinerungsoption entweder nicht oder nur partiell erforderlich ist, empfohlen, einige der Agenten zu deaktivieren. Dies wirkt sich besonders nachhaltig bei geringeren Granularitäten, wie stündlichen Ergebnissen, aus. Es wirkt sich auch maßgeblich auf die geclusterte Metrik aus, da die Engine jede der oben aufgeführten Berechnungen für jedes erkannte ClusterItem vornimmt. Tatsächlich wird jedes ClusterItem wie eine neue Metrik behandelt. Beispiel: Bei der Berechnung einer Metrik übergreifend über eine Ressourcengruppe aus 50 Elementen hat die Engine im Vergleich zu derselben, nicht-geclusterten Metrik das 49-fache an Arbeit.

Beispiel: Wenn die Metrik auf die Berechnung der Problemlösungszeit in der Anzahl an Tagen festgelegt ist, ist ein stündliches Ergebnis sinnlos, und die Auswahl des entsprechenden Kontrollkästchens sollte auf der Registerkarte "Granularitäten" aufgehoben werden, damit die Engine keine unnötigen Berechnungen durchführt.

Das Attribut TimeUnit des Kontextobjekts (d. h. context.TimeUnit in der Business-Logik) gibt die Zeiteinheit des derzeit ausführenden Agenten aus, wobei die folgenden Ausgabewerte möglich sind: STUNDE, TAG, WOCHE, MONAT, QUARTAL, JAHR.

So gibt beispielsweise die Kontext.TimeUnit für den täglichen Agenten "Tag" aus.

Das Attribut IsTrackingPeriod des Kontextobjekts gibt "True" für den Agenten aus, der die Zeiteinheit für den Kontrollzeitraum berechnet. Es muss ferner berücksichtigt werden, dass die auf der Registerkarte "Granularität" der Metrik angezeigten Agenten zusätzlich zum Agenten des Kontrollzeitraums der Metrik vorhanden sind. Somit können Sie sogar für eine Metrik mit einem monatlichen Kontrollzeitraum den monatlichen Agenten deaktivieren, und er berechnet dennoch weiterhin den monatlichen Service Level, jedoch nur als "Geschäftsergebnisse" (nicht-operative Ergebnisse).

Wie oben erwähnt, führen die verschiedenen Agenten üblicherweise denselben Business-Logikcode aus, es gibt jedoch Fälle, in denen es notwendig ist, eine geringfügig andere Logik anzuwenden.

Im monatlichen Fall sollte das Ergebnis beispielsweise die Häufigkeit der Ausfallzeiten für jeden Monat separat ausweisen, wie nachfolgend dargestellt:

Für die tägliche Verfeinerung ist es möglicherweise notwendig, die kumulativen Ausfallzeiten einzusehen, wobei jeder Tag eine Summe aller Tage ab Monatsanfang ist. Diese Methode sollte auf alle Zeiteinheiten angewendet werden, die - wie unten dargestellt - kleiner sind als ein einzelner Monat:

Der Unterschied zwischen den zwei Zeiteinheiten ist, dass der Ausfallzeitzähler für den Agenten, der den Kontrollzeitraum berechnet, auf 0 initialisiert wird, für den täglichen Agenten wird der Zähler jedoch nur initialisiert, wenn es sich bei dem Tag um den ersten Tag des Monats handelt.

Nachfolgend sehen Sie den Event Handler OnPeriodStart:
Sub OnPeriodStart(time)
     If InStr("MONTH,QUARTER,YEAR", Kontext.TimeUnit) > 0 _
 Oder (Kontext.TimeUnit = "TAG" und Day(time) = 1) _
 Or (Kontext.TimeUnit = "HOUR" And Day(time) = 1 And Hour(time) = 0) Then
          DownTimeCounter = 0
     End If
End Sub

Was ist unter Neuberechnung zu verstehen?

^Die Neuberechnung wird durchgeführt, wenn die Korrelations-Engine feststellt, dass ein periodisches Endergebnis einer Metrik nicht mehr gültig ist, und die Ergebnisse somit neu berechnet werden müssen.

Eine Neuberechnung kann durch Folgendes verursacht werden:

• Den Empfang neuer Events, die eigentlich in der Vergangenheit stattfanden. (früher als bis zu dem Zeitpunkt, bis zu dem die Engine die Berechnung für diese Metrik derzeit durchgeführt hat)
• Eine Ressource, die für die Metrik registriert ist, wird verändert (neues Versionsdatum und an der Ressource vorgenommene Änderungen).
• Übernehmen einer neuen Vertragsversion, die die zuvor berechnete Zeit mit Änderungen an einigen Metriken überlagert (nur veränderte Metriken werden neu berechnet)

Die effizienteste Methode für eine Registrierung ist über Vertragspartei und Service. Durch die Anordnung der Ressourcen unter Vertragspartei und Service lässt sich die logische Beziehung zwischen der Datenebene und der Geschäftsebene im System ausdrücken. Bei einer Registrierung von Ressourcen durch diese Entitäten sind keine Änderungen an den Formeln erforderlich, wenn sie in unterschiedlichen Verträgen oder für unterschiedliche Services verwendet werden. Der aktuelle Kontext der Metrik, der im Vertrag und im Service identifiziert ist, und der die relevante Vertragspartei und den zugehörigen Service festlegt. Die in diesem Typ von Registrierung definierten Business-Logik-Formeln sind leicht wiederverwendbar, weil sie keinerlei Änderungen in der Registrierung benötigen.