Exemples de calculs de fenêtre

Cette section fournit des exemples supplémentaires de calculs de fenêtre, avec des détails sur leur fonctionnement. Toutefois, vous trouverez d'abord une version détaillée de la phrase décrivant l'objectif du calcul et le modèle de calcul correspondant avec des marques de réservation. Vous pouvez l'utiliser comme aide pour écrire des calculs de base.

Lorsque TRIGGER_FIELD, dans TRIGGER_OBJECT, est configuré sur VALUE, je veux changer la propriété (PROPERTY) de TARGET en true/false (vrai/faux).

Le calcul correspondant à cette phrase de souhaits est :

Copier
import System
static def GetAttributeValue(Incident):
    PropertyState = false
    if TRIGGER_OBJECT.TRIGGER_FIELD != null and TRIGGER_OBJECT.TRIGGER_FIELD._Title == 'VALUE':
        PropertyState = true
    return String.Format(":SetPROPERTY(TARGET, {0});", PropertyState)

En remplaçant les marques de réservation par celles de la phrase de souhaits dans le calcul, puis en ajoutant TRIGGER_FIELD au volet Dépendances de l'éditeur de calcul, vous obtenez le calcul requis. Il est également recommandé de remplacer toutes les références à PropertyState par un nom de variable plus descriptif.

Le reste de cette section fournit des exemples basés sur ce calcul et en explique la logique. Plus vous avancez dans les exemples, plus le calcul est étendu.

Les indentations de ces calculs sont très importantes car elles déterminent l'étendue des fonctions. Ainsi, si vous copiez des exemples dans le présent document, veillez à bien conserver les indentations correctes lorsque vous les copiez dans l'éditeur de calculs.

Utilisation d'instructions if pour réinitialiser des valeurs

L'exemple suivant est une extension de l'exemple fourni à la section Configuration de calculs de fenêtre, dans laquelle le champ Impact est configuré en tant que non obligatoire. Il devient obligatoire uniquement si le champ Urgence est configuré sur Urgent. Si le champ est vide (configuré sur NULL) ou défini sur une autre valeur, le champ Impact devient à nouveau non obligatoire.

Voici la phrase décrivant l'objectif de cette commande :

Quand Urgence est défini sur Urgent, je veux changer la valeur SetMandatory du champ Impact en true (vrai).

Cela indique que le champ de déclencheur est Urgence, que l'attribut cible est Impact et que la fonction de fenêtre utilisée est :SetMandatory(,).

Voici une structure saine pour un calcul de fenêtre :

  • Définissez une variable au départ pour spécifier la valeur vraie ou fausse typique de la fonction de fenêtre.
  • Construisez ensuite une instruction qui change la variable lorsque l'utilisateur sélectionne les valeurs appropriées.
  • Enfin, renvoyez la fonction de fenêtre en utilisant la variable pour définir le paramètre true/false (vrai/faux).

Par exemple :

Copier
import System
static def GetAttributeValue(Incident):
    MandatoryUrgency = false
    if Incident._IncidentUrgency != null and Incident._IncidentUrgency._Title == 'Urgent':
        MandatoryUrgency = true
    return String.Format(":SetMandatory(_Impact, {0});", MandatoryUrgency)

La troisième ligne, la quatrième et la dernière portent une seule indentation, alors que la ligne cinq en porte une double.

La ligne 3 crée la variable MandatoryUrgency et configure sa valeur sur false. Il s'agit de la valeur la plus courante, valeur par défaut du calcul.

La ligne 4 teste Urgence pour voir si ce paramètre est défini sur Urgent (Incident._IncidentUrgency._Title == 'Urgent'). Notez que, pour que le calcul puisse tester la valeur de l'attribut Incident._IncidentUrgency._Title, la syntaxe de calcul exige de vérifier que l'objet d'attribut n'est pas NULL (Incident._IncidentUrgency != null).

Si la ligne 4 est vraie, si Urgence n'est pas NULL et si vous l'avez configuré sur Urgent, alors la ligne 5 s'exécute et définit la valeur de la variable MandatoryUrgency sur true (vrai).

Enfin, la ligne 6 s'exécute et définit la valeur de l'attribut de calcul. Comme la commande fait référence à une variable, la syntaxe de calcul exige la génération de la chaîne renvoyée à l'aide de la fonction String.Format. Elle prend la forme String.Format("function(attribute, {0});", variable), où {0} est remplacé par la variable lors de la génération de la chaîne, ce qui donne :SetMandatory(_Impact,MandatoryUrgency);. Par défaut, MandatoryUrgency a la valeur false (faux), si bien que le champ Impact n'est pas obligatoire. Toutefois, si Urgence est défini sur Urgent, les conditions définies à la ligne 4 sont remplies et la ligne 5 s'exécute. La commande définit ensuite la variable MandatoryUrgency sur true (vrai), si bien que le champ Impact devient obligatoire.

Notez que les lignes 3 et 5 utilisent un seul signe égal (=), alors que la ligne 4 en utilise deux (==).
Un signe égal (=) unique signifie « rendre cela égal à », deux signes égal (==) signifient « cela est-il égal à ? ».

Mise à jour de deux champs avec un seul calcul

L'exemple suivant montre comment mettre à jour deux champs avec un seul calcul, à l'aide d'un calcul semblable à celui de l'exemple précédent. Dans cet exemple, les champs CI et Type de CI s'affichent uniquement si le paramètre Catégorie est configuré sur Matériel.

Voici la phrase décrivant l'objectif de cette commande :

Quand Catégorie est défini sur Matériel, je veux changer la valeur SetHidden du champ CI ET du champ Type de CI en false (faux).

Cela indique que le champ de déclencheur est Catégorie, que les attributs cibles sont CI ET Type de CI, et que la fonction de fenêtre utilisée est :SetHidden(,).

Copier
import System
static def GetAttributeValue(Incident):
    HideCI = true
    if Incident.Category != null and Incident.Category.FullName == 'Matériel':
        HideCI = false
    return String.Format(":SetHidden(ConfigurationItemType,{0});:SetHidden(ConfigurationItem,{1});", HideCI, HideCI)

La troisième ligne, la quatrième et la sixième portent une seule indentation, alors que la ligne cinq en porte une double. La longue ligne six s'affiche sur une seule ligne dans l'éditeur de calculs.

La ligne 3 définit la variable HideCI sur true (vrai).

La ligne 4 vérifie que Catégorie n'est pas NULL et est défini sur Matériel.

Si la ligne 4 est vraie, alors la ligne 5 s'exécute et configure HideCI sur false (faux).

Enfin, la ligne 6 s'exécute et définit la valeur de l'attribut de calcul sur String.Format(":SetHidden(ConfigurationItemType,{0});:SetHidden(ConfigurationItem,{1});", HideCI, HideCI). Par défaut, HideCI est true (vrai), si bien que les champs Type de CI et CI sont masqués. Toutefois, si Catégorie est défini sur Matériel, les conditions définies à la ligne 4 sont remplies et la ligne 5 s'exécute. La commande définit ensuite la variable HideCI sur false (faux), si bien que les champs Type de CI et CI deviennent visibles.

Lorsque vous utilisez String.Format pour renvoyer plusieurs fonctions utilisant des variables, vous faites référence aux variables de ces fonctions sous forme de numéros entre accolades, puis ajoutez ensuite les variables dans l'ordre. Par exemple :

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

:SetHidden affiche et masque également l'étiquette associée à l'attribut cible. Toutefois, vous ne pouvez pas utiliser :SetHidden pour les étiquettes statiques ajoutées depuis l'arborescence Contrôles dans Gestionnaire de fenêtre.

Utilisation de plusieurs fonctions avec un seul déclencheur

Les exemples ci-dessus renvoient toujours une seule fonction de fenêtre : ils changent l'état Obligatoire d'un ou de plusieurs champs, ou bien leur état Masqué. Cet exemple montre comment mettre à jour deux fonctions différentes à l'aide d'un seul calcul. Cet exemple est une extension du précédent, où les champs CI et Type de CI s'affichent si Catégorie est configuré sur Matériel, mais également où Type de CI est rendu obligatoire.

Voici la phrase décrivant l'objectif de cette commande :

Quand Catégorie est défini sur Matériel, je veux changer la valeur SetHidden des champs CI ET Type de CI en false (faux), ET changer la valeur SetMandatory de Type de CI sur true (vrai).

Cela indique que le champ de déclencheur est Catégorie, que les attributs cibles sont CI et Type de CI, et que les fonctions de fenêtre utilisées sont :SetHidden(,) et SetMandatory(,).

Copier
import System
static def GetAttributeValue(Incident):
    HideCI = true
    MandatoryCI = false
    if Incident.Category != null and Incident.Category.FullName == 'Matériel':
        HideCI = false
        MandatoryCI = true
    return String.Format(":SetHidden(ConfigurationItemType,{0});:SetHidden(ConfigurationItem,{1});:SetMandatory(ConfigurationItemType,{2});", HideCI, HideCI, MandatoryCI)

La troisième ligne, la quatrième, la cinquième et la huitième portent une seule indentation, alors que les lignes six et sept en portent une double. La longue ligne huit s'affiche sur une seule ligne dans l'éditeur de calculs.

La ligne 3 définit la variable HideCI sur true (vrai) : par défaut, les champs CI et Type de CI doivent être masqués.

La ligne 4 définit la variable MandatoryCI sur false (faux) : par défaut, le champ Type de CI ne doit pas être obligatoire.

Si la ligne 5 est vraie, alors les deux lignes 6 et 7 s'exécutent et configurent HideCI sur false (faux) et MandatoryCI sur true (vrai). Ces deux lignes s'exécutent parce qu'elles ont la même indentation dans le calcul.

Enfin, la longue ligne 8 s'exécute et transmet la valeur de HideCI aux deux premières fonctions, et la valeur de MandatoryCI à la troisième fonction.

Comme vous envoyez la même variable aux deux premières fonctions, vous pouvez récrire la ligne 8 sous la forme suivante :
return String.Format(":SetHidden(ConfigurationItemType,{0});:SetHidden(ConfigurationItem,{0});:SetMandatory(ConfigurationItemType,{1});", HideCI, MandatoryCI)

Utilisation de différentes fonctions sur la base des valeurs d'un seul déclencheur

Cet exemple montre comment utiliser une fonction différente selon la valeur sélectionnée dans l'attribut déclencheur. Si Priorité est défini sur Élevée, alors le champ Raison est rendu obligatoire et modifiable. Si vous définissez Priorité sur Faible, alors le champ Raison est rendu non obligatoire et mis en lecture seule ; sinon, le champ Raison reste à son état par défaut.

Ce calcul nécessite que vous ajoutiez un attribut, dont la valeur Nom est définie sur _reason, à l'objet Incident.

Voici la phrase décrivant l'objectif de cette commande :

Quand Priorité est défini sur Élevée, je veux changer la valeur SetMandatory de Raison en true (vrai) ET la valeur SetReadOnly de Raison en false (faux). Quand Priorité est défini sur Faible, je veux changer la valeur SetReadOnly de Raison en true (vrai) ET la valeur SetMandatory de Raison en false (faux).

Cela indique que le champ de déclencheur est Priorité, que l'attribut cible est Raison, et que les fonctions de fenêtre utilisées sont SetMandatory(,) et SetReadOnly(,). Nous pouvons aussi écrire :

Tout le reste du temps, je veux que les deux valeurs SetMandatory et SetReadOnly de Raison soient définies sur false (faux).

Cela indique que la valeur par défaut pour les deux valeurs SetMandatory et SetReadOnly de Raison est false (faux).

Copier
import System
static def GetAttributeValue(Incident):
    MandatoryReason = false
    ReadOnlyReason = false
    if Incident.Priority != null and Incident.Priority.Title == 'Élevée':
        MandatoryReason = true
    elif Incident.Priority != null and Incident.Priority.Title == 'Faible':
        ReadOnlyReason = true
    return String.Format(":SetMandatory(_reason, {0});:SetReadOnly(_reason, {1});", MandatoryReason, ReadOnlyReason)

La troisième ligne, la quatrième, la cinquième, la septième et la neuvième portent une seule indentation, alors que les lignes six et huit en portent une double. La longue ligne neuf s'affiche sur une seule ligne dans l'éditeur de calculs.

La ligne 3 définit la variable MandatoryReason sur false (faux) : par défaut, le champ Raison ne doit pas être obligatoire.

La ligne 4 définit la variable ReadOnlyReason sur false (faux) : par défaut, le champ Raison doit être en lecture seule.

Si la ligne 5 est vraie et si le champ Priorité est configuré sur Élevée, alors la ligne 6 s'exécute et définit la valeur MandatoryReason sur true (vrai).

Si la ligne 5 n'est PAS vraie, la ligne 7 s'exécute. La ligne elif (« else if ») s'exécute uniquement si la ligne qui la précède est fausse. Si cette ligne est vraie et si le champ Priorité est configuré sur Faible, alors la ligne 8 s'exécute et définit la valeur ReadOnlyReason sur true (vrai).

Enfin, la ligne 9 s'exécute en utilisant les valeurs définies pour MandatoryReason et ReadOnlyReason.

Cela signifie que, par défaut, MandatoryReason et ReadOnlyReason sont définis sur false (faux), si bien que le champ Raison n'est ni obligatoire, ni en lecture seule. Toutefois, si Priorité est configuré sur Élevée, alors MandatoryReason est true (lignes 5 et 6), mais ReadOnlyReason est toujours false, si bien que Raison est obligatoire mais pas en lecture seule. Si Priorité est défini sur Faible, ReadOnlyReason est true (lignes 7 et 8), mais MandatoryReason est false, si bien que Raison est en lecture seule mais pas obligatoire.

Utilisation de dates dans les calculs

Cet exemple rend le champ Raison obligatoire si la date sélectionnée dans le champ Date limite est à 7 jours de la date actuelle.

Ce calcul nécessite l'ajout d'attributs dont la valeur Nom est définie sur _reason et sur _daterequired à l'objet Incident. Attention, veillez à ne pas mettre à jour le même champ avec différents calculs.

Voici la phrase décrivant l'objectif de cette commande :

Quand Date limite est défini sur une date à 7 jours d'aujourd'hui, je veux changer la valeur SetMandatory du champ Raison en true (vrai).

Cela indique que le champ de déclencheur est Date limite, que l'attribut cible est Raison et que la fonction de fenêtre utilisée est SetMandatory(,).

Copier

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)

La troisième ligne, la quatrième et la dernière portent une seule indentation, alors que la ligne cinq en porte une double.

La ligne 3 crée la variable MandatoryReason et la configure sur false (faux) : par défaut, le champ Raison ne doit pas être obligatoire.

La ligne 4 utilise la méthode .Net .AddDays pour déterminer si Date limite est à moins de 7 jours de la date du jour. Si tel est le cas, la ligne 5 s'exécute et configure MandatoryReason sur true (vrai).

La ligne 6 génère ensuite la fonction SetMandatory appropriée.

Pour en savoir plus sur l'utilisation de méthodes .Net dans vos calculs, consultez le site Web de la communauté Ivanti.