Vous pouvez appliquer certaines approches lorsque vous implémentez votre plug-in ; par exemple, en mettant des objets en cache, en plaçant des objets en arrière-plan, en clonant des objets, etc. Ces approches sont susceptibles d'améliorer les performances de vos plug-ins, d'éviter les problèmes de concurrence et d'améliorer la réactivité du client Orchestrator.

Mettre des objets en cache

Votre plug-in peut interagir avec un service distant, et cette interaction est rendue possible par les objets locaux qui représentent les objets distants du côté du service. Pour optimiser les performances du plug-in et la réactivité de l'IU Orchestrator, vous pouvez mettre les objets locaux en cache au lieu de les récupérer à chaque fois auprès du service distant. Vous pouvez tenir compte de la portée du cache : par exemple, un cache pour l'ensemble des plug-ins clients, un cache par utilisateur du plug-in et un cache par utilisateur du service tiers. Une fois implémenté, votre mécanisme de mise en cache est intégré à l'interface du plug-in pour rechercher et invalider des objets.

Placer des objets en arrière-plan

Si vous devez faire apparaître des listes importantes d'objets dans l'inventaire du plug-in et que vous ne disposez d'aucune manière pour récupérer ces objets rapidement, vous pouvez les placer en arrière-plan. Vous pouvez placer les objets en arrière-plan avec, par exemple, des objets dans deux états : fake et loaded. Supposons que les objets fake soient extrêmement faciles à créer et fournissent un minimum d'informations à faire apparaître dans l'inventaire, comme le nom et l'ID. Il serait donc possible de toujours renvoyer les objets fake et, lorsque toutes les informations (l'objet réel) sont demandées, l'entité utilisatrice ou le plug-in pourrait appeler automatiquement une méthode load pour obtenir l'objet réel. Vous pouvez même configurer le processus de chargement des objets de manière qu'il démarre automatiquement après le renvoi des objets factices afin d'anticiper les actions de l'entité utilisatrice.

Cloner des objets afin d'éviter les problèmes de concurrence

Si vous utilisez un cache pour votre plug-in, vous devez cloner des objets. L’utilisation d’un cache qui renvoie toujours la même instance d'un objet à chaque entité qui le demande peut provoquer des effets indésirables. Par exemple, l'entité A demande l'objet O et l'entité consulte l'objet dans l'inventaire avec l'ensemble de ses attributs. Au même moment, l'entité B demande également l'objet O, mais l'entité A exécute un workflow qui commence à modifier les attributs de l'objet O. À la fin de cette exécution, le workflow appelle la méthode update de l'objet pour mettre ce dernier à jour du côté du serveur. Si l'entité A et l'entité B obtiennent la même instance de l'objet O, l'entité A peut voir dans l'inventaire toutes les modifications que l'entité B réalise, avant même que les modifications soient envoyées du côté du serveur. Cela ne pose aucun problème si l'exécution se déroule normalement. Par contre, si l'exécution échoue, les attributs de l'objet O pour l'entité A ne sont pas rétablis. Dans ce cas, si le cache (les opérations find du plug-in) renvoie un clone de l'objet au lieu de la même instance à chaque fois, les entités utilisatrices consultent et modifient leur propre copie et les problèmes de concurrence sont évités, au moins dans Orchestrator.

Notifier les modifications aux autres intervenants

Des problèmes peuvent survenir lorsque vous utilisez simultanément un objet en cache et un objet cloné. Le problème le plus important est que l'objet qui apparaît à l'entité risque de ne pas s'afficher dans sa dernière version disponible. Par exemple, si une entité affiche l'inventaire, les objets sont chargés une seule fois au même moment. Donc si une autre entité modifie certains objets, la première entité ne voit pas ces modifications. Pour éviter ce problème, vous pouvez utiliser les méthodes PluginWatcher et IPluginPublisher de l'API du plug-in Orchestrator afin de notifier les modifications apportées et que ces dernières apparaissent dans les autres instances des clients Orchestrator. Cette solution s'applique également à une instance unique du client Orchestrator lorsque les modifications d'un objet de l'inventaire affectent les autres objets. Ces modifications doivent également être notifiées. Les opérations sujettes aux notifications sont l'ajout, la mise à jour et la suppression d'objets lorsque ces objets ou certaines de leurs propriétés apparaissent dans l'inventaire.

Activer la recherche d'un objet à tout moment

Vous devez implémenter la méthode find de l'interface IPluginFactory pour rechercher des objets uniquement par type et par ID. La méthode find peut être appelée directement après le redémarrage d'Orchestrator et la reprise d'un workflow.

Simuler un service de requête si vous n'en possédez pas

Dans certains cas, le client Orchestrator peut demander l'utilisation de requêtes pour certains objets, ou leur affichage en liste ou en tableau plutôt qu'en arborescence, par exemple. Cela signifie que votre plug-in doit être en mesure d'envoyer des requêtes à tout moment pour certains ensembles d'objets. Si la technologie tierce propose un service de requête, vous devez adapter et utiliser ce service. Si ce n'est pas le cas, vous devez pouvoir simuler un service de requête malgré la complexité accrue et les performances réduites de la solution.

Les méthodes de recherche ne doivent pas renvoyer d'exceptions d'exécution

Les méthodes de l'interface IPluginFactory qui implémentent les recherches dans le plug-in ne doivent pas générer d'exceptions d'exécution contrôlées ou non contrôlées. Cela risque de causer des échecs de type erreur de validation étonnants au cours de l'exécution d'un workflow. Par exemple, entre les deux nœuds d'un workflow , la méthode find est appelée si une sortie du premier nœud est une entrée du deuxième nœud. À ce moment, si l'objet est introuvable à cause d'une exception d'exécution, vous risquez d'obtenir uniquement une erreur de validation sans information complémentaire dans le client Orchestrator. La quantité d'informations apparaissant dans les fichiers journaux dépend de la façon dont le plug-in enregistre les exceptions.