--- sourceDocument: Gestion des opérations IT Australie sourceDocumentLink: https://servicenow-prod.fluidtopics.net/r/fr-FR/it-operations-management Release : - australia ft:locale : - fr-FR ft:publication_title : - Gestion des opérations IT Australie ft:clusterId : - itom bundleId : - itom workflow : - Technology --- # API dans le cloud (CAPI) # API dans le cloud (CAPI) {#ariaid-title1} * Rversion finale: Australia * * Mis à jour 12 mars 2026 * * ![](https://www.servicenow.com/docs/portal-asset/ico-clock) 9 minutes de lecture L'API dans le cloud (CAPI) vous permet d'intégrer Mise en service et gouvernance du cloud des fournisseurs dans le cloud à l'aide d'API REST. ## Composants CAPI {#cloud-management-api__section_phl_yt4_x2b} L'intégration avec les fournisseurs dans le cloud s'effectue par le biais d'appels REST, tels que PUT, GET, POST et DELETE. CAPI fournit le cadre de travail pour vous permettre d'intégrer une API REST de fournisseurs dans le cloud afin que votre instance puisse communiquer avec le fournisseur dans le cloud pour gérer les ressources dans le cloud. Consultez la section [Browse APIs by product](https://www.servicenow.com/docs/access?context=api-product-type&version=australia&pubname=australia-api-reference&ft:locale=en-US) pour en savoir plus. L'CAPI contient les composants suivants : Figure 1. Vue d'ensemble de l'CAPI Fournisseurs : Les fournisseurs dans le cloud sont les clouds auxquels vous pouvez vous connecter. Par défaut, Mise en service et gouvernance du cloud inclut les fournisseurs les plus couramment utilisés, tels qu'AWS, Azure et VMware. Chaque fournisseur propose de nombreux produits, chacun fournissant des types de ressources. Chaque type de ressource est mappé à un seul type de CI. Par exemple, le AWS provider inclut le AWS Elastic Compute Cloud produit, qui inclut le type de AWS::EC2::Instance ressource. Ce type de ressource est l'une des ressources dans le cloud les plus courantes que vous puissiez créer. Elle est directement mappée au type de CI de l'instance d'ordinateur virtuel \[cmdb_ci_vm_instance\], où les ordinateurs virtuels sont enregistrés dans la CMDB. Interfaces : Les interfaces définissent le cadre de travail dont le système a besoin pour structurer les appels REST attendus par les API du fournisseur dans le cloud. Les interfaces définissent les opérations, également appelées méthodes, et les paramètres requis par chaque méthode. Les interfaces sont réutilisables. Si vous étendez CAPI pour inclure de nouveaux produits et API, vous pouvez utiliser des interfaces existantes pour effectuer les mêmes appels REST. API : Les API CAPI sont le composant central de CAPI qui relie un produit et une interface. Les API incluent le code réel que le système exécute. Chaque API CAPI comprend les composants suivants : * Les mappeurs de méthode CAPI fournissent les méthodes mappées aux opérations définies dans l'interface. À partir des mappeurs de méthode CAPI, vous créez des Serveur MID includes de script en JavaScript pour indiquer au fournisseur de cloud exactement ce qu'il doit faire. C'est via les includes de script que la connexion au fournisseur de cloud se produit. Remarque : Si vous créez des API CAPI personnalisées, le système fournit un include de script vide que vous pouvez personnaliser. Vous pouvez également modifier les includes de script existants sur les mappeurs de méthode si nécessaire. Toutefois, la plupart des API par défaut fournies avec l'application n'utilisent pas d'includes Mise en service et gouvernance du cloud de script modifiables. Les connexions sont codées en dur en Java. Vous pouvez toujours utiliser ces API dans les nouveaux blocs de ressources que vous créez, mais vous ne pouvez pas modifier les API. * Les remplacements de configuration d'API contiennent l'identité, telle qu'une clé, et les informations d'identification, telles que la clé secrète, et d'autres paramètres importants requis par le fournisseur dans le cloud. Ces paramètres aident le fournisseur dans le cloud à effectuer les opérations dans la liste connexe Mappeurs de méthode CAPI. Des remplacements de configuration d'API sont nécessaires car, lorsque le système appelle l'API du fournisseur dans le cloud via REST, les données d'identification ne sont pas incluses. Les blocs de ressources utilisent les paramètres et les valeurs que vous définissez dans les remplacements de configuration d'API pour interroger le magasin d'informations d'identification. Lorsque votre API s'exécute, les attributs sont mis à la disposition de tous les appels de méthode dans vos includes de script. Les remplacements ne sont inclus dans le champ d'application que pour cette API. Les remplacements ne remplacent rien dans les autres API. {#cloud-management-api__ul_ynn_zbp_x2b} Étant donné que vous pouvez définir plusieurs versions d'une API CAPI avec de légères variations, vous pouvez étendre (sans remplacer) une API existante tout en conservant les fonctionnalités souhaitées. Cette image illustre les composants de CAPI utilisés lorsque vous mettez en service un ordinateur virtuel Azure à l'aide des paramètres CAPI par défaut fournis avec Mise en service et gouvernance du cloud:Figure 2. CAPI Azure Dans cet exemple, le Microsoft.Compute produit est contenu dans le Azure fournisseur. Azure utilise le produit pour les Microsoft.Compute machines virtuelles. Dans votre instance, le Microsoft.Compute produit est mappé au Microsoft.Compute/virtualMachines type de ressource, qui est associé au Virtual Machine Instance type de CI dans la CMDB. L'interface Compute contient des définitions pour des méthodes telles que CreateNode, qui définit comment créer l'ordinateur virtuel réel. Parmi les nombreux paramètres utilisés CreateNode , Location capture le centre de données où réside l'ordinateur virtuel. Le Azure Compute API rassemble le Microsoft.Compute produit et la structure définie dans l'interface Compute . L'implémentation de la CreateNode méthode appelle l'include de azure-compute-1.0-CreateNode Serveur MID script, qui appelle l'include de script AzureComputeVirtualMachine Serveur MID . Les includes de script effectuent les appels réels à l'API Azure. Pour accéder au compte Azure, les méthodes , ClientID, SecretKeyTenantID, et d'autres sont transmises dans Remplacements de configuration. ## Comment CAPI s'intègre à l'instance {#cloud-management-api__section_oj2_dw4_x2b} CAPI intègre ces composants dans votre instance : Mise en service et gouvernance du cloud Blocs de ressources : Un bloc de ressources représente une ressource cloud unique, telle qu'un serveur virtuel, un serveur de stockage virtuel ou un centre de données. Vous pouvez également le considérer comme un type de CI dans la CMDB. Vous rassemblez de nombreux blocs de ressources dans un plan, qui apparaît sous la forme d'un élément de catalogue (également appelé pile) pour vos utilisateurs dans le catalogue dans le cloud. Dans le système, chaque bloc de ressource est comme un conteneur qui fait référence à CAPI et relie les réponses du fournisseur dans le cloud à un CI spécifique. Utilisation des blocs de ressources : * Étapes opérationnelles qui appellent CAPI pour chaque opération, telle que l'opération de mise en service, et transmettent les valeurs des paramètres nécessaires dont le fournisseur de cloud a besoin pour exécuter l'opération. * Processeurs de réponses qui traitent et analysent la réponse REST du fournisseur et mettent à jour les enregistrements dans la CMDB. {#cloud-management-api__ul_gfn_frq_x2b} La CMDB : Chaque bloc de ressources est basé sur un type de CI de la CMDB. Pour Mise en service et gouvernance du cloud, tous les types de CI liés au cloud sont basés sur la Virtual Machine Object CI classe, qui fournit tous les attributs dont vous avez besoin pour toutes les ressources dans le cloud prises en charge par défaut. Si aucun type de CI pour une ressource dans le cloud n'existe dans le système de base, vous devez créer une nouvelle classe CI et ajouter les attributs nécessaires. Si vous créez une nouvelle classe CI, vous devez également créer : * Une classe CI pour chacune des ressources mises à la disposition de vos utilisateurs. Toutes les classes CI sont basées sur la classe d'objet de l'ordinateur virtuel. * Règle d'identification qui spécifie un ID d'objet. Chaque fois que les composants de Gestion cloud font référence à une ressource cloud spécifique dans la CMDB, ils ont besoin de l'ID d'objet pour trouver la ressource cloud correcte. * Règle de relation qui spécifie la façon dont la classe CI de la ressource est liée à d'autres classes CI. Par exemple, un virtual server CI doit avoir une Hosted on::Hosts relation avec un datacenter CI. Ces règles de relation sont nécessaires à l'unicité d'un CI lorsqu'elles sont traitées par le moteur Identification et rapprochement (IRE). La combinaison du compte de service, de l'ID d'objet de la ressource et du centre de données (ou de l'emplacement) où se trouve la ressource détermine le caractère unique. {#cloud-management-api__ul_vll_zgq_x2b} Serveur MID include de script : Chaque opération dans l'API CAPI a un Serveur MID include de script que vous configurez. L'include de script appelle les classes JavaScript qui se trouvent déjà dans d'autres includes de script du système ou les classes JavaScript que vous créez. Finalement, la classe invoker est appelée pour déclencher l'appel REST. Serveur MID Les includes de script sont configurés sur votre ServiceNow instance, mais s'exécutent sur le Serveur MID. Cette image illustre comment les composants fonctionnent ensemble lorsqu'un utilisateur met en service une ressource à partir de :Portail de l'utilisateur dans le cloud ## Appels REST vers le fournisseur dans le cloud {#cloud-management-api__section_sys_p4j_hfb} Les appels REST vers le fournisseur dans le Serveur MID cloud sont déclenchés à partir des includes de script référencés à partir des mappeurs de méthode CAPI scriptés dans les enregistrements d'API CAPI. Pour créer vos propres API CAPI ou pour créer des includes de script personnalisés Serveur MID (qui font partie des mappeurs de méthode CAPI), vous devez comprendre : * Les classes que vous pouvez appeler dans Serveur MID les includes de script. Consultez [Classes CAPI dans les Serveur MID includes de script](https://servicenow-prod.fluidtopics.net/wq4YS0D_tBOLF8O_mNrFSQ "Mise en service et gouvernance du cloud fournit plusieurs classes JavaScript qui effectuent des appels REST vers les fournisseurs dans le cloud. Ces classes sont appelées à partir d’includes de Serveur MID script (pour Azure par défaut) ou d’appels Java dans le système (pour AWS par défaut). Si vous créez des fournisseurs, des interfaces ou des API CAPI personnalisés (pour n’importe quel fournisseur dans le cloud), vous pouvez utiliser Serveur MID des includes de script pour appeler les classes."). * Comment le fournisseur de cloud implémente REST. Voir : * [Référence de l'API REST Azure](https://docs.microsoft.com/en-us/rest/api/azure/) * [Guides AWS et références d'API](https://docs.aws.amazon.com/index.html#lang/en_us) {#cloud-management-api__ul_ax3_fsj_hfb} {#cloud-management-api__ul_ysk_trj_hfb} Par exemple, pour savoir comment passer un appel REST à Azure pour créer un groupe de ressources, consultez cette rubrique Azure : [groupes de ressources - Créer ou mettre à jour](https://docs.microsoft.com/en-us/rest/api/resources/resourcegroups/createorupdate). Vous pouvez trouver le point de terminaison, les paramètres et le corps de la demande requis par Azure, ainsi que les réponses qu'il fournit. Vous pouvez voir que : * Le point de terminaison est `management.azure.com` * La méthode à appeler avec une opération PUT est `subscriptions/{subscriptionId}/resourcegroups/{resourceGroupName} ?api-version=2018-02-01`, où vous spécifiez l'ID de l'abonnement, le nom du groupe de ressources et la version de l'API. {#cloud-management-api__ul_y12_kwj_hfb} N'oubliez pas que les appels d'API REST ont lieu à l'intérieur des includes de script associés aux mappeurs de méthode d'API Serveur MID CAPI. Appelez les méthodes que CAPI met déjà à votre disposition en utilisant les classes étendues à partir de CloudAPIBase et CloudRESTAPIInvoker. Vous pouvez également créer d'autres includes de script pour étendre ces classes de base et créer vos propres classes. Familiarisez-vous avec ces classes de base et les méthodes disponibles dans celles-ci. ## Commencer ici {#cloud-management-api__section_odh_vlh_n2b} 1. [Examiner les API CAPI fournies avec Mise en service et gouvernance du cloud par défaut](https://servicenow-prod.fluidtopics.net/MuMFqqhBow9Z7Uyh8DaCZg "Plusieurs API CAPI sont fournies par défaut avec l’application Mise en service et gouvernance du cloud ."). 2. [Passez en revue les classes CAPI fournies par défaut](https://servicenow-prod.fluidtopics.net/wq4YS0D_tBOLF8O_mNrFSQ "Mise en service et gouvernance du cloud fournit plusieurs classes JavaScript qui effectuent des appels REST vers les fournisseurs dans le cloud. Ces classes sont appelées à partir d’includes de Serveur MID script (pour Azure par défaut) ou d’appels Java dans le système (pour AWS par défaut). Si vous créez des fournisseurs, des interfaces ou des API CAPI personnalisés (pour n’importe quel fournisseur dans le cloud), vous pouvez utiliser Serveur MID des includes de script pour appeler les classes."). Ces classes peuvent être appelées à partir des includes de script dans vos opérations d'API Serveur MID CAPI. 3. Passez en revue le provisionnement d'un [ordinateur virtuel Azure](https://servicenow-prod.fluidtopics.net/586_3fifpJ5PRTc6fEWEpA "Cet exemple vous guide à travers les composants de cette fonction lors de Mise en service et gouvernance du cloud la mise en service d’un ordinateur virtuel dans un centre de données Azure. Les sujets abordés incluent les plans, les blocs de ressources, l’API dans le cloud (CAPI) et Serveur MID les includes de script.") et d'un [ordinateur virtuel AWS](https://servicenow-prod.fluidtopics.net/XcC8zjH60pwa5VLPFNojbA "Cet exemple vous guide à travers les composants de Mise en service et gouvernance du cloud cette fonction lors de la mise en service d’un ordinateur virtuel dans un centre de données AWS. Les sujets abordés incluent les plans, les blocs de ressources, l’API dans le cloud (CAPI) et Serveur MID les includes de script.") pour voir comment les composants fonctionnent ensemble. La procédure pas à pas Azure utilise un include de Serveur MID script pour vous permettre de voir les différentes classes CAPI utilisées dans l'opération de mise en service. La procédure pas à pas AWS n'utilise pas d'include de Serveur MID script. 4. [Ajouter un produit à un fournisseur existant dans CAPI](https://servicenow-prod.fluidtopics.net/LZ8LxP6TLNA~v6yXoD8sRA "L’API Mise en service et gouvernance du cloud cloud (CAPI) propose de nombreux fournisseurs, tels qu’AWS et Azure, et produits, tels que les instances EC2. Toutefois, vous pouvez ajouter des produits aux fournisseurs existants pour de nouveaux types de ressources cloud."). 5. [Créer une classe CI pour une ressource cloud virtuelle](https://servicenow-prod.fluidtopics.net/L3qOIHf~g0886Jm5jkhqbg "Si le ne fournit pas de type de CI pour les système de base ressources virtuelles basées sur le cloud, vous pouvez créer une classe CI basée sur la classe d’objet de l’ordinateur virtuel."). 6. [Créer ou étendre une interface CAPI](https://servicenow-prod.fluidtopics.net/2UtGBXEvqvKkyerz~ahIjA "Vous pouvez créer une nouvelle interface CAPI ou étendre une interface existante en ajoutant de nouvelles opérations."). 7. [Créer une API CAPI](https://servicenow-prod.fluidtopics.net/iyj7Gmv6x2lTBEbKoTUcjg "Si les API CAPI existantes ne s’intègrent pas à l’interface CAPI d’un fournisseur, vous pouvez créer une API. Les étapes des blocs de ressources peuvent appeler vos méthodes API lorsque les opérations sont exécutées.") et un include de script personnalisé Serveur MID qui effectue les appels REST vers le fournisseur dans le cloud. Un script include vide Serveur MID est toujours généré pour les nouvelles API CAPI. Modifiez-le avec les appels à d'autres classes et méthodes JavaScript, telles que les méthodes de la classe Invocateur. {#cloud-management-api__ol_zdd_yby_2fb}