Les Blueprints XaaS sont des workflows vRealize Orchestrator pouvant provisionner des ressources, modifier les ressources provisionnées ou se comporter comme un service effectuant une tâche dans votre environnement. Les Blueprints et les actions sur les ressources ont différentes nuances que vous devez comprendre lorsque vous concevez des Blueprints pour les utilisateurs de votre catalogue de services.

Les définitions suivantes vous permettent de comprendre les termes utilisés lorsque vous travaillez avec des Blueprints XaaS.

Ressource personnalisée

Type d'objet vRealize Orchestrator exposé en tant que ressource par le biais de l'API d'un plug-in vRealize Orchestrator. Vous créez une ressource personnalisée pour définir le paramètre de sortie d'un Blueprint de provisionnement XaaS et pour définir un paramètre d'entrée d'une action sur la ressource.

Composant de Blueprint XaaS

Blueprint de provisionnement ou de non-provisionnement que vous pouvez utiliser dans le canevas de conception du Blueprint. Ce Blueprint peut également être un Blueprint XaaS autonome.

Blueprint XaaS autonome

Blueprint de provisionnement ou de non-provisionnement qui est publié et autorisé directement dans le catalogue de services.

Blueprint de provisionnement

Blueprint de provisionnement qui exécute un workflow vRealize Orchestrator pour provisionner des ressources sur le point de terminaison cible à l'aide de l'API de plug-in vRealize Orchestrator pour le point de terminaison. Par exemple, ajoutez des cartes réseau virtuelles à un périphérique réseau dans vSphere. Pour créer un Blueprint de provisionnement, vous devez disposer d'une ressource personnalisée qui définit le type de ressource vRealize Orchestrator.

Lorsqu'un utilisateur du catalogue de services demande ce type d'éléments du catalogue, le workflow provisionne l'élément et l'élément déployé est stocké sur l'onglet Éléments. Vous pouvez définir des opérations de post-provisionnement sur ce type de ressources provisionnées. Vous pouvez également rendre les Blueprints évolutifs en ajoutant ou supprimant une instance, le cas échéant.

Blueprint de non-provisionnement

Un Blueprint de non-provisionnement exécute un workflow vRealize Orchestrator pour effectuer une tâche qui ne nécessite pas que l'API apporte des modifications au point de terminaison. Par exemple, le workflow qui s'exécute crée un rapport puis l'envoie par e-mail ou le publie sur le système de communication cible.

Lorsqu'un utilisateur du catalogue de services demande ce type d'élément du catalogue, le workflow s'exécute pour effectuer la tâche du script, mais l'élément n'est pas ajouté sur l'onglet Éléments. Il est impossible d'exécuter des opérations de post-provisionnement sur ce type de Blueprint. Vous pouvez utiliser des Blueprints de non-provisionnement comme workflows de prise en charge dans des Blueprints évolutifs. Par exemple, vous pouvez créer un Blueprint pour mettre à jour un équilibrage de charge à haute disponibilité.

Blueprint composite

Blueprint qui a été créé à l'aide du canevas de conception. Le Blueprint composite utilise un ou plusieurs composants. Par exemple, un composant de machine, un composant logiciel ou un composant XaaS. Lorsque vous l'ajoutez à un service, il est répertorié comme un Déploiement. Lorsque vous l'ajoutez à un droit pour le mettre à la disposition des utilisateurs du catalogue de services, il est répertorié comme un Blueprint composite. Un Blueprint composite peut comporter un composant de Blueprint ou inclure l'intégralité d'une application avec plusieurs machines, logiciels et mises en réseau.

Action sur la ressource

Workflow que vous pouvez exécuter sur un Blueprint de provisionnement déployé. Le Blueprint déployé peut être un Blueprint ou un composant de Blueprint XaaS, ou un type de machine que vous avez mappé à un type de ressource vRealize Orchestrator.