Beispiele für Fensterberechnungen

Dieser Abschnitt enthält einige weitere Beispiele für Fensterberechnungen mit Erläuterungen zu deren Funktionsprinzip. Zunächst aber sei eine erweiterte Version der Anforderungsaussage und eine entsprechende Vorlagenberechnung mit Platzhaltern gegeben. Sie können sich beim Schreiben von grundlegenden Berechnungen daran orientieren.

Wenn das TRIGGER_FELD auf dem TRIGGER_OBJEKT auf WERT gesetzt wird, möchte ich die PROPERTY (Eigenschaft) von ZIEL in true/false (Wahr/Falsch) ändern.

Die Berechnung, die dieser Anforderungsaussage entspricht, lautet:

Kopieren

1
2
3
4
5
6
import System
static def GetAttributeValue(Incident):
    PropertyState = false
    if TRIGGER_OBJEKT.TRIGGER_FELD != null and TRIGGER_OBJEKT.TRIGGER_FELD._Title == 'WERT':
        PropertyState = true
    return String.Format(":SetPROPERTY(ZIEL, {0});", PropertyState)

Sie erhalten die gewünschte Berechnung, indem Sie die Platzhalter in der Anforderungsaussage in der Berechnung ersetzen und anschließend TRIGGER_FELD zum Bereich Abhängigkeiten im Berechnungseditor hinzufügen. Ferner empfiehlt es sich, alle Verweise auf „PropertyState“ durch einen aussagekräftigeren Name für die Variable zu ersetzen.

Der restliche Teil dieses Abschnitts bietet Beispiele auf der Basis dieser Berechnung und erklärt die Logik. Die Beispiele weiter hinten erweitern die Berechnung zusätzlich.

Die Einrückungen in diesen Berechnungen sind sehr wichtig und definieren den Umfang der Funktionen. Daher müssen Sie beim Kopieren von Beispielen aus diesem Dokument sicherstellen, dass beim Einfügen in den Berechnungseditor die Einrückungen in korrekter Form erhalten bleiben.

Verwendung von IF-Anweisungen zum Zurücksetzen von Werten

Das folgende Beispiel erweitert das unter Fensterberechnungen einrichten gegebene Beispiel dahingehend, dass das Feld Auswirkung als nicht obligatorisch definiert wird und nur dann obligatorisch wird, wenn das Feld Dringlichkeit auf Dringend gesetzt wurde. Wird das Feld gelöscht (auf NULL gesetzt) oder ein anderer Wert festgelegt, dann wird das Feld Auswirkung wieder auf „nicht obligatorisch“ gesetzt.

Die Formulierung unserer Anforderung hierfür lautet:

Wenn die Dringlichkeit auf Dringend gesetzt wird, möchte ich SetMandatory für das Feld Auswirkung in true (wahr) ändern.

Dies bedeutet: das Triggerfeld ist Dringlichkeit, das Zielattribut ist Auswirkung und die Fensterfunktion ist :SetMandatory(,).

Eine gute Struktur für eine Fensterberechnung ergibt sich aus folgender Vorgehensweise:

Definieren Sie zu Beginn eine Variable, die den typischen True- oder False-Wert (Wahr- oder Falsch-Wert) für die Fensterfunktion angibt.
Konstruieren Sie dann eine Anweisung, die eine Änderung der Variablen bewirkt, wenn bestimmte Werte ausgewählt werden.
Geben Sie schließlich die Fensterfunktion unter Verwendung der Variablen zur Angabe des True/False-Parameters zurück.

Beispiel:

Kopieren

1
2
3
4
5
6
import System
static def GetAttributeValue(Incident):
    MandatoryUrgency = false
    if Incident._IncidentUrgency != null and Incident._IncidentUrgency._Title == 'Dringend':
        MandatoryUrgency = true    
    return String.Format(":SetMandatory(_Impact, {0});", MandatoryUrgency)

Die Zeilen 3 und 4 und die letzten Zeilen weisen eine einzige Einrückung auf; Zeile 5 ist dagegen doppelt eingerückt.

Zeile 3 erstellt eine Variable namens MandatoryUrgency und setzt deren Wert auf false (falsch). Dies ist der gängigste, standardmäßige Wert für die Berechnung.

Mit Zeile 4 wird getestet, ob die Dringlichkeit auf Dringend gesetzt wurde (Incident._IncidentUrgency._Title == 'Dringend'). Beachten Sie, dass die Berechnung (bedingt durch die Berechnungssprache) den Wert des Attributs Incident._IncidentUrgency._Title erst testen kann, nachdem durch entsprechende Prüfung sichergestellt wurde, dass das Objekt des Attributs nicht NULL ist (Incident._IncidentUrgency != null).

Wenn Zeile 4 wahr ist und die Dringlichkeit nicht NULL ist und auf Dringend gesetzt wurde, wird Zeile 5 ausgeführt und der Wert der Variablen MandatoryUrgency auf true (wahr) gesetzt.

Schließlich wird Zeile 6 ausgeführt und der Wert des Berechnungsattributs gesetzt. Da wir Bezug auf eine Variable nehmen, erfordert die Berechnungssprache, dass wir die zurückgegebene Zeichenfolge unter Verwendung einer String.Format-Funktion generieren. Diese weist das Format String.Format("function(attribute, {0});", variable) auf, wobei {0} bei der Generierung der Zeichenfolge durch die Variable ersetzt wird, sodass wir Folgendes erhalten: :SetMandatory(_Impact,MandatoryUrgency);. MandatoryUrgency ist standardmäßig false (falsch). Das Feld Auswirkung (engl. „Impact“) ist demzufolge nicht obligatorisch. Wird jedoch für die Dringlichkeit der Wert Dringend definiert, dann sind die Bedingungen in der Zeile 4 erfüllt und Zeile 5 wird ausgeführt. Damit wird die Variable MandatoryUrgency auf true (wahr) gesetzt, womit das Feld Auswirkung obligatorisch wird.

Beachten Sie, dass die Zeilen 3 und 5 ein einzelnes Gleichheitszeichen = verwenden, wohingegen die Zeile 4 zwei Gleichheitszeichen == verwendet.
= bedeutet "dies gleichsetzen mit", wohingegen == bedeutet "ist dies gleich?"

Aktualisierung von zwei Feldern mit einer Berechnung

Das nächste Beispiel zeigt, wie Sie zwei Felder mit einer einzigen Berechnung aktualisieren können, indem Sie eine ähnliche Berechnung wie im vorherigen Beispiel verwenden. In diesem Beispiel erscheinen die Felder CI und CI-Typ nur, wenn die Kategorie auf Hardware festgelegt wurde.

Die Formulierung unserer Anforderung hierfür lautet:

Wenn die Kategorie auf Hardware gesetzt wird, möchte ich SetHidden für das Feld CI UND für das Feld CI-Typ in false (falsch) ändern.

Dies bedeutet, dass Kategorie das Triggerfeld ist, CI UND CI-Typ die Zielattribute sind und die Fensterfunktion :SetHidden(,) lautet.

Kopieren

1
2
3
4
5
6
import System
static def GetAttributeValue(Incident):
    HideCI = true
    if Incident.Category != null and Incident.Category.FullName == 'Hardware':
        HideCI = false
    return String.Format(":SetHidden(ConfigurationItemType,{0});:SetHidden(ConfigurationItem,{1});", HideCI, HideCI)

Die Zeilen 3, 4 und 6 weisen eine einzige Einrückung auf; Zeile 5 ist dagegen doppelt eingerückt. Die lange 6. Zeile erscheint im Berechnungseditor auf einer einzigen Zeile.

Mit Zeile 3 wird die Variable HideCI auf true (wahr) gesetzt.

Mit Zeile 4 wird geprüft, ob Kategorie nicht NULL und auf Hardware gesetzt ist.

Wenn Zeile 4 wahr ist, wird Zeile 5 ausgeführt und HideCI auf false (falsch) gesetzt.

Schließlich wird Zeile 6 ausgeführt und der Wert des Berechnungsattributs auf String.Format(":SetHidden(CITyp,{0});:SetHidden(CI,{1});", HideCI, HideCI) gesetzt. Standardmäßig ist HideCI auf true (wahr) gesetzt, d. h. die Felder CI-Typ und CI sind verborgen. Wird jedoch die Kategorie auf den Wert Hardware gesetzt, dann sind die Bedingungen in der Zeile 4 erfüllt und Zeile 5 wird ausgeführt. Dabei wird die Variable HideCI auf false (falsch) gesetzt und die Felder CI-Typ und CI werden sichtbar.

Wenn Sie String.Format verwenden, um mehr als eine Funktion zurückzugeben, die Variablen verwendet, beziehen Sie sich in der Funktion mithilfe von Nummern in geschweiften Klammern auf die Variablen und fügen danach die Variablen in der entsprechenden Reihenfolge hinzu. Beispiel:

String.Format("function(attribute, {0});function(attribute, {1});function(attribute, {2});", variable 0, variable1, variable 2)

:SetHidden zeigt und verbirgt auch die mit dem Zielattribut verknüpfte Beschriftung. Sie können :SetHidden jedoch nicht für statische Beschriftungen verwenden, die aus dem Baum Steuerelemente in Window Manager hinzugefügt werden.

Verwendung unterschiedlicher Funktionen mit ein und demselben Trigger

In den vorherigen Beispielen wurde immer nur eine Fensterfunktion zurückgegeben: entweder wurde der Status „Obligatorisch“ für ein oder mehrere Felder geändert oder aber der Status „Ausgeblendet“. Dieses Beispiel zeigt, wie Sie zwei verschiedene Funktionen mit einer einzigen Berechnung aktualisieren können. Dieses Beispiel erweitert das vorherige Beispiel dahingehend, dass die Felder CI und CI-Typ erscheinen, wenn die Kategorie auf Hardware gesetzt wird. Zusätzlich wird aber auch der CI-Typ obligatorisch gemacht.

Die Formulierung unserer Anforderung hierfür lautet:

Wenn Kategorie auf Hardware gesetzt wird, möchte ich SetHidden für CI UND CI-Typ auf false (falsch) setzten UND SetMandatory für CI-Typ in true (wahr) ändern.

Dies bedeutet, dass Kategorie das Triggerfeld ist, CI und CI-Typ die Zielattribute sind und die verwendeten Fensterfunktionen :SetHidden(,) und SetMandatory(,) lauten.

Kopieren

1
2
3
4
5
6
7
8
import System
static def GetAttributeValue(Incident):
    HideCI = true
    MandatoryCI = false
    if Incident.Category != null and Incident.Category.FullName == 'Hardware':
        HideCI = false
        MandatoryCI = true
    return String.Format(":SetHidden(ConfigurationItemType,{0});:SetHidden(ConfigurationItem,{1});:SetMandatory(ConfigurationItemType,{2});", HideCI, HideCI, MandatoryCI)

Die Zeilen 3, 4, 5 und 8 weisen eine einzige Einrückung auf; die Zeilen 6 und 7 sind dagegen doppelt eingerückt. Die lange 8. Zeile erscheint im Berechnungseditor auf einer einzigen Zeile.

Mit Zeile 3 wird die Variable HideCI auf true (wahr) gesetzt, d. h. die Felder CI und CI-Typ sollen standardmäßig verborgen werden.

Mit Zeile 4 wird die Variable MandatoryCI auf false (falsch) gesetzt, d. h. das Feld CI-Typ soll standardmäßig nicht obligatorisch sein.

Wenn Zeile 5 wahr ist, werden sowohl Zeile 6 als auch Zeile 7 ausgeführt. Ferner wird HideCI auf false (falsch) und MandatoryCI auf true (wahr) gesetzt. Diese Zeilen werden beide ausgeführt, da sie in der Berechnung in gleicher Weise eingerückt sind.

Schließlich wird die lange 8. Zeile ausgeführt und übergibt den Wert von HideCI an die ersten beiden Funktionen und den Wert von MandatoryCI an die dritte Funktion.

Da Sie dieselbe Variable an die ersten beiden Funktionen senden, könnten Sie Zeile 8 wie folgt umschreiben:
return String.Format(":SetHidden(ConfigurationItemType,{0});:SetHidden(ConfigurationItem,{0});:SetMandatory(ConfigurationItemType,{1});", HideCI, MandatoryCI)

Verwendung unterschiedlicher Funktionen in Abhängigkeit von den Werten eines Triggers

Dieses Beispiel zeigt, wie Sie je nach dem Wert, der im Triggerattribut ausgewählt wird, unterschiedliche Funktionen verwenden können. Wird für die Priorität der Wert Hoch angegeben, wird das Feld Grund obligatorisch und bearbeitbar gemacht. Wenn die Priorität auf Niedrig gesetzt wird, dann wird das Feld Grund nicht obligatorisch und zudem schreibgeschützt gemacht; ansonsten wird das Feld Grund im standardmäßigen Zustand belassen.

Für diese Berechnung muss zum Incident-Objekt ein Attribut hinzugefügt werden, bei dem als Name _reason definiert wurde.

Die Formulierung unserer Anforderung hierfür lautet:

Wenn die Priorität auf Hoch gesetzt wird, möchte ich SetMandatory für Grund in true (wahr) ändern UND SetReadOnly für Grund in false (falsch). Wird die Priorität auf Niedrig gesetzt, möchte ich SetReadOnly für Grund in true (wahr) ändern UND SetMandatory für Grund soll false (falsch) sein.

Dies bedeutet: das Triggerfeld ist Priorität, das Zielattribut ist Grund und die Fensterfunktionen lauten SetMandatory(,) und SetReadOnly(,). Wir könnten demnach auch Folgendes schreiben:

In allen anderen Fällen soll sowohl SetMandatory als auch SetReadOnly für Grund false (falsch) sein.

Dies bedeutet, dass der Standardwert sowohl bei SetMandatory als auch bei SetReadOnly für Grund false (falsch) ist.

Kopieren

1
2
3
4
5
6
7
8
9
import System
static def GetAttributeValue(Incident):
    MandatoryReason = false
    ReadOnlyReason = false
    if Incident.Priority != null and Incident.Priority.Title == 'Hoch':
        MandatoryReason = true
    elif Incident.Priority != null and Incident.Priority.Title == 'Niedrig':
        ReadOnlyReason = true
    return String.Format(":SetMandatory(_reason, {0});:SetReadOnly(_reason, {1});", MandatoryReason, ReadOnlyReason)

Die Zeilen 3, 4, 5, 7, und 9 weisen eine einfache Einrückung auf, wohingegen die Zeilen 6 und 8 doppelt eingerückt sind. Die lange 9. Zeile erscheint im Berechnungseditor auf einer einzigen Zeile.

Mit Zeile 3 wird die Variable MandatoryReason auf false (falsch) gesetzt, d. h. das Feld Grund soll standardmäßig nicht obligatorisch sein.

Mit Zeile 4 wird die Variable ReadOnlyReason auf false (falsch) gesetzt, d. h. das Feld Grund soll standardmäßig schreibgeschützt sein.

Wenn Zeile 5 wahr ist und das Feld Priorität auf Hoch gesetzt wurde, dann wird Zeile 6 ausgeführt und MandatoryReason auf true (wahr) gesetzt.

Ist Zeile 5 NICHT wahr, wird Zeile 7 ausgeführt.elif („else if“)-Zeilen werden nur ausgeführt, wenn die vorhergehende Zeile falsch ist.Wenn diese Zeile wahr ist und das Feld Priorität auf Niedrig gesetzt ist, wird Zeile 8 ausgeführt und ReadOnlyReason auf true (wahr) gesetzt.

Schließlich wird Zeile 9 unter Verwendung der vorgegebenen Werte von MandatoryReason and ReadOnlyReason ausgeführt.

Dies bedeutet, dass MandatoryReason und ReadOnlyReason standardmäßig false (falsch) sind, d. h. das Feld Grund ist weder obligatorisch noch schreibgeschützt. Wird jedoch die Priorität auf Hoch gesetzt, dann ist MandatoryReason zwar true (Zeilen 5 und 6), aber ReadOnlyReason immer noch false, daher ist Grund obligatorisch, aber nicht schreibgeschützt. Wird die Priorität auf Niedrig gesetzt, dann ist ReadOnlyReason zwar true (Zeilen 7 und 8), aber MandatoryReason ist false, daher ist das Feld Grund schreibgeschützt, aber nicht obligatorisch.

Verwendung von Datumsangaben in Berechnungen

In diesem Beispiel wird das Feld Grund obligatorisch, wenn das im Feld Benötigt am auf ein Datum eingestellt wird, das innerhalb von sieben Tagen ab dem aktuellen Datum liegt.

Bei dieser Berechnung müssen zum Incident-Objekt Attribute hinzugefügt werden, bei denen als Name _reason und _daterequired definiert wurden. Denken Sie daran, dasselbe Feld nicht mit unterschiedlichen Berechnungen zu aktualisieren.

Die Formulierung unserer Anforderung hierfür lautet:

Wenn Benötigt am auf ein Datum eingestellt ist, das innerhalb von sieben Tagen ab dem aktuellen Datum liegt, soll SetMandatory für Grund auf true (wahr) gesetzt werden.

Dies bedeutet, dass Benötigt am das Triggerfeld ist, Grund, das Zielattribut ist und die verwendete Fensterfunktion SetMandatory(,) lautet.

Kopieren

1
2
3
4
5
6
7

import System
static def GetAttributeValue(Incident):
    MandatoryReason = false
    if Incident._daterequired != null and Incident._daterequired < DateTime.Today.AddDays(7):
        MandatoryReason = true
    return String.Format(":SetMandatory(_reason,{0});", MandatoryReason)

Die Zeilen 3 und 4 und die letzten Zeilen weisen eine einzige Einrückung auf; Zeile 5 ist dagegen doppelt eingerückt.

Mit Zeile 3 wird eine Variable mit der Bezeichnung MandatoryReason erstellt und standardmäßig auf false (falsch) gesetzt, d. h. das Feld Grund soll standardmäßig nicht obligatorisch sein.

Zeile 4 macht von einer .Net-Methode namens .AddDays Gebrauch, um zu bestimmen, ob Benötigt am kleiner ist als das heutige Datum plus 7.Wenn diese Zeile wahr ist, wird die Zeile 5 ausgeführt und HideCI wird auf false (falsch) gesetzt.

Zeile 6 generiert dann die entsprechende SetMandatory-Funktion.

Nähere Informationen zur Verwendung von .Net-Methoden in Berechnungen finden Sie auf der Website der Ivanti Community.