Les expressions suivantes sont utilisées dans NGL :
should-have
Utilisation : should-have est utilisé pour faire correspondre la condition au type de ressource.
Syntaxe : <app suite> <resource type> should-have <condition>
Exemple :
microsoft365 remotedomain should-have autoforwardenabled = false
Explanation: the NGL rule will filter the Microsoft365 resources that have remotedomain resource type where autoforwardenable property is false.
should-not-have
Utilisation : should-not-have est utilisé pour ne pas faire correspondre la condition au type de ressource.
Syntaxe : <app suite> <resource type> should-not-have <condition>
Exemple :
microsoft365 remotedomain should-not-have autoforwardenabled = false
Explanation: the NGL rule will filter the Microsoft365 resources that have remotedomain resource type but autoforwardenable property is not false.
Scoping conditionnel
where
Utilisation : where est utilisé pour filtrer les ressources à l'aide de leurs propriétés, afin que seul le sous-ensemble pertinent de ressources soit pris en compte lors des évaluations. Plusieurs conditions peuvent être combinées dans l'expression where à l'aide d'opérateurs logiques (et, ou) pour former des filtres complexes. Voir Comment optimiser les requêtes NGL avec le filtrage des ressources ? pour plus de détails sur le moment et la manière d'utiliser le scoping.
Syntaxe : < suite d’applications> <app suite> <resource type> condition de devoir avoir/ne pas avoir <><condition> where <scoped condition>
Exemple :
Workday WorkdayAccount should-have age(nskp_LastPasswordChangeDate, "days") < 180 where textmatch(username, "-external$") = true
Explication : NGL évaluera tous les utilisateurs de Workday dont le nom d'utilisateur se termine par "-external" et vérifiera si le mot de passe a été modifié pour la dernière fois dans les 180 jours. En l'absence de l'expression where, tous les utilisateurs de Workday seront évalués.
should-have/should-not-have expressions impactent l’évaluation de la condition, tandis que les conditions de cadrage filtrent son champ d’application.Erreurs courantes
Cette section décrit les erreurs pouvant survenir avec where.
| Error Scenario | Exemple incorrect de LGN | Exemple de message d'erreur | Marche à suivre pour corriger l'erreur |
|---|---|---|---|
| La ressource secondaire délimitée n'est pas soumise à une condition d'évaluation | servicenow SysProperties devrait avoir 1 = 1 où SystemProperty with-attribute { Nom = « my.prop.name » } | Erreur : la ressource secondaire "SystemProperty" qui a des conditions de portée doit avoir au moins une condition dans la clause "should-have". | Ajoutez une ou plusieurs conditions d'évaluation pour la ressource secondaire délimitée. |