Conditions dans les workflows

Omnissa Intelligence propose des Conditions à utiliser dans Freestyle Orchestrator afin de pouvoir définir des séquences d'actions en milieu de workflow sans créer de workflows distincts.

Avantages

Les conditions réduisent la surcharge liée à la maintenance de workflows distincts pour chaque scénario spécifique. Avec des conditions, vous pouvez utiliser une règle de déclencheur commune pour créer d'autres chemins d'exécution pour chaque scénario différent au sein d'un workflow. Par exemple, sans conditions, vous deviez créer des workflows distincts pour chaque action requise pour chaque scénario de conformité. Désormais, vous pouvez ajouter des conditions pour plusieurs scénarios de conformité avec de nombreuses actions dans un workflow unique.

Créer un workflow avec une condition

Recherchez l'élément de menu Condition sous la forme d'une option de glisser-déposer sur le canevas du workflow.

Important : Vérifiez l'Impact potentiel de vos workflows et testez vos workflows sur un petit nombre de cibles en spécifiant des filtres plus restrictifs pour vous assurer que les actions de workflow se comportent comme vous le souhaitez.

1. Dans Intelligence, accédez à Workspace > Freestyle > Ajouter un workflow.
2. Entrez un nom pour votre workflow .
3. Configurez le déclencheur avec la source de données souhaitée.
4. Sélectionnez les Paramètres du déclencheur.
5. Utilisez les résultats de l'Impact potentiel pour les Paramètres de déclencheur Manuel ou Planifié dans la zone Paramètres de workflow.
   • Sélectionnez Évaluer l'impact potentiel.
   • Sélectionnez Afficher les détails pour accéder au panneau Impact potentiel.
   • Utilisez Grouper par pour regrouper les données par attributs de données. Par exemple, vous pouvez regrouper les données par données de terminal ou données d'application.
   • Utilisez la flèche pour fermer le panneau Impact potentiel.
   • Accédez au panneau à tout moment pendant la création du workflow pour vous aider à affiner vos filtres.
6. Configurez la Règle du déclencheur.
7. Ajoutez une condition en faisant glisser et en déposant l'icône Condition des composants à gauche ou à l'aide de l'icône + Ajouter une étape sur le canevas.
   • Vous devez ajouter une action à la branche Then ou à la branche Else.
   • Vous pouvez imbriquer des conditions et vous devez ajouter une action à au moins une condition dans le groupe de conditions imbriqué.
8. Nommez la condition pour une meilleure lisibilité.
9. Définissez les filtres de cette condition dans la fenêtre Condition.
   1. Définissez l'instruction If pour la condition.
   2. Définissez l'instruction Then pour la condition.
      • Si vous imbriquez des conditions, vous devez ajouter une Action à l'une des conditions du groupe imbriqué.
   3. Définissez l'instruction Else pour la condition.
      • Vous pouvez laisser l'instruction Else vide, arrêter le workflow, poursuivre avec d'autres actions ou ajouter d'autres conditions.
10. Enregistrez le Workflow. Vous pouvez activer le workflow à tout moment .

Exemple de condition

Recherchez les terminaux Windows enrôlés, vérifiez l'état du pare-feu du terminal et si l'état n'est pas égal à Transmettre, puis installez un profil de pare-feu Workspace ONE UEM pour mettre à jour le pare-feu.

1. Dans Intelligence, accédez à Workspace > Freestyle > Ajouter un workflow.
2. Entrez un nom pour votre workflow .
   • Pour notre exemple, nous pouvons utiliser Mettre à jour le pare-feu Windows.
3. Configurez le déclencheur avec la source de données souhaitée.
   • Pour notre scénario, utilisez Workspace ONE UEM > Terminaux comme source de données.
4. Sélectionnez les Paramètres du déclencheur.
   • Définissez le déclencheur sur Automatique.
5. Configurez la Règle du déclencheur.
   • La règle de déclencheur pour ce scénario est Terminaux > État d'enrôlement > Est égal à > Enrôlé.
6. Ajoutez une condition en faisant glisser et en déposant l'icône Condition des composants à gauche ou à l'aide de l'icône + Ajouter une étape sur le canevas.
7. Nommez la condition pour une meilleure lisibilité. Dans ce scénario, entrez Vérifier la plate-forme Windows.
8. Définissez l'instruction If pour la condition.
   • Pour le scénario, définissez Terminaux > Plate-forme > Est égal à > Poste de travail Windows.
   • Nous utilisons les mêmes attributs dans la condition que dans la règle de déclencheur.
9. Définissez l'instruction Then pour la condition.
   • Pour le scénario, nous allons imbriquer une autre condition afin de pouvoir vérifier l'état du pare-feu.
   • Nommez la deuxième condition État du pare-feu différent de transmettre > Installer le profil de pare-feu.
   • Sélectionnez Terminaux > État du pare-feu > Pas égal à > Transmettre.
10. Définissez l'instruction Then pour la deuxième condition imbriquée.
    • Ajoutez une Action Workspace ONE UEM > Installer le profil.
      • Le moteur de workflow installe le profil de pare-feu UEM pour mettre à jour le pare-feu lorsqu'il identifie que l'état du pare-feu n'est pas Transmettre.
      • Une action est attribuée à l'une de nos conditions dans un groupe imbriqué.
    • Pour l'ID du profil, recherchez et sélectionnez votre Profil de pare-feu UEM.
11. Laissez les instructions Else vides pour les première et deuxième conditions.
12. Enregistrez le Workflow. Vous pouvez activer le workflow à tout moment .

Scénarios de configuration

Vous devez configurer toutes les données nécessaires pour un workflow dans la règle de déclencheur. Si vous utilisez des conditions, vous devez utiliser une configuration spécifique (les mêmes entités ou les relations 1:1) ou vous devez référencer l'entité de condition dans la règle de déclencheur (relation 1:N).

Que sont les entités et les attributs ?

Les règles et conditions de déclencheur sont composées de filtres de déclencheur qui incluent une entité et un attribut. Dans la capture d'écran, Terminaux est l'entité et État de l'antivirus est l'attribut.

Est égal à et Transmettre sont les qualificateurs de la paire entité-attribut Terminaux > État de l'antivirus.

Scénarios

Pour que les conditions fonctionnent sans erreur, configurez vos conditions à l'aide de l'une des méthodes répertoriées dans la liste Scénarios.

Ces scénarios sont des exemples de relation entre l'entité dans la règle de déclencheur et l'entité dans la condition.

Scénario 1 : mêmes entités

• Explication
  • La règle de déclencheur et la condition utilisent la même entité.
• Exemple
  • La source de données et la règle de déclencheur utilisent l'entité Enquête pour référencer une Apps Survey et la condition contient également une entité Enquête à des fins d'évaluation.
  • Le workflow peut avoir plusieurs conditions, mais toutes les conditions doivent utiliser l'entité Enquête.
    

Scénario 2 : Relations un-à-un (1:1)

• Explication
  • La règle du déclencheur utilise une entité et la condition en utilise une autre. Cependant, les entités dans la règle de déclencheur et dans la condition ont une relation un-à-un.
  • Par exemple, le moteur de workflow, lors de l'utilisation d'une entité Terminaux dans la règle de déclencheur, peut identifier une entité unique Utilisateurs dans la condition.
  • Autre exemple : le moteur de workflow, lors de l'utilisation d'une entité Terminaux dans la règle de déclencheur, peut identifier la valeur d'une entité Capteurs particulière comme device_manufacturer_name dans la condition.
• Exemple
  • La source de données et la règle de déclencheur utilisent l'entité Terminaux pour voir si le terminal est enrôlé, et la condition utilise une entité Utilisateurs pour vérifier que l'utilisateur du terminal se trouve dans le groupe d'utilisateurs RH.
  • La règle de déclencheur et la condition utilisent une relation d'entité 1:1, car le moteur de workflow identifie un terminal spécifique enrôlé dans un groupe d'utilisateurs spécifique.
  • Ces workflows peuvent avoir plusieurs conditions tant que chaque entité de condition a une relation 1:1 avec l'entité de règle de déclencheur.
    
    

Scénario 3 : Relations un-à-plusieurs (1:N)

• Explication
  • La règle du déclencheur utilise une entité et la condition en utilise une autre. Cependant, les entités dans la règle de déclencheur et dans la condition ont une relation 1:N.
  • Par exemple, plusieurs applications sont attribuées à un seul terminal ou installées sur un seul terminal. Dans ce scénario, la règle de déclencheur dispose d'un attribut de terminal et la condition inclut des attributs d'application.
  • Un exemple similaire est la relation entre les entités Terminaux et les entités Profils, Produits ou Mises à jour de système d'exploitation.
  • Cette relation 1:N peut empêcher le système d'utiliser l'entité de la règle de déclencheur pour identifier de manière unique une instance de l'entité à partir de la condition.
  • Cette configuration peut être compliquée et nécessite des configurations supplémentaires.
• Exemple
  • L'entité Terminaux dans la règle de déclencheur recherche le nom d'un terminal, mais l'entité Applications dans la condition vérifie Applications > État d'installation de l'application et de nombreuses applications sont installées sur ce terminal.
  • Le système ne vous permet pas d'enregistrer ce workflow.
  • Reportez-vous à la section Configurations supplémentaires – relations 1:N pour connaître les actions que vous pouvez effectuer si vous souhaitez utiliser cette relation, mais que vous obtenez cette erreur d'interface utilisateur.
    

Configurations supplémentaires – relations 1:N

Lorsque vous utilisez des relations 1:N entre les règles de déclencheur et les conditions, vous devez ajouter une autre règle de déclencheur qui fait référence à l'entité de condition. Lorsqu'il s'exécute, le workflow cible les enregistrements correspondants dans la règle de déclencheur (l'entité d'origine) et l'entité qui fait référence à la condition.

L'ajout de la règle de déclencheur qui fait référence à l'entité de condition augmente la possibilité que le moteur de workflow s'exécute sur un grand nombre d'itérations, car il trouve des enregistrements qui correspondent. La possibilité d'exécuter des itérations augmente encore lorsqu'un workflow est défini pour s'exécuter selon une planification. Les cibles de votre workflow avec une relation 1:N peuvent être excessives, donc vérifiez l'Impact potentiel.

Actions

• Si vous utilisez une entité différente dans la condition, vous devez inclure une règle de déclencheur qui fait référence à l'entité introduite dans la condition.
  Remarque : Vous n'avez pas à inclure la règle de déclencheur supplémentaire si vous utilisez une relation 1:1.
  • Le système a besoin de cette règle de déclencheur qui fait référence à l'entité de condition, car il doit joindre les données des différentes entités pour rechercher des enregistrements correspondants et afficher les résultats.
  • Si nous revoyons l'exemple de relations 1:N dans la liste des Scénarios, vous pouvez ajouter une règle de déclencheur Nom de l'application > Est égal à > Intelligent Hub.
    
  • Ce filtre fait référence à l'entité Applications qui a été introduite dans la condition (Applications > État d'installation de l'application) et termine la jonction des entités Terminaux et Applications.
  • Les entités de la règle de déclencheur sont plus restrictives et ont de meilleures chances de réduire les paires de terminaux et d'applications correspondantes sur lesquelles le workflow peut itérer (également appelées Impact potentiel).
  • Si vous n'ajoutez pas la règle de déclencheur qui fait référence à l'entité de condition, vous ne pouvez pas enregistrer le workflow et l'interface utilisateur affiche une erreur.
• Vérifiez l'Impact potentiel.
• Testez le workflow sur un petit nombre de cibles pour voir qu'il s'exécute comme souhaité en ajoutant un filtre plus restrictif. Par exemple, les attributs du filtre GUID de terminal > Est égal à > Le GUID de votre terminal de test limitent l'itération à la recherche d'un GUID de terminal spécifique.
• Utilisez le paramètre de déclencheur Automatique le cas échéant.
• Envisagez de créer un workflow distinct.

Configurations supplémentaires – modifications d'état

Les workflows obtiennent les données utilisées pour évaluer les conditions au début de l'exécution du workflow et non au moment de l'évaluation.

Si l'état d'un attribut change (par exemple de true à false) en raison d'une action antérieure à la condition (par exemple, la suppression d'une application ou la mise à jour d'un terminal), le workflow n'aura pas ce changement d'état au début et le système ne signalera pas les modifications d'état dans les résultats.

Actions

• Utilisez des attributs dans vos conditions qui ne changeront pas d'état lors de l'exécution du workflow. Un exemple de modification de l'état de l'attribut est dû à l'action qui supprime une application achetée ; dans ce cas, l'état d'installation de l'application passe de true à false.
• Utilisez un workflow distinct pour effectuer les actions qui se seraient produites après la modification de l'état.