Logique de noeud final requise pour tous les courtiers de services

Les courtiers de services doivent fournir un ensemble standard de valeurs de métadonnées utilisées par les API REST. De plus, les courtiers IBM Cloud doivent inclure la logique pour les noeuds finaux ou les chemins d'API REST suivants :

catalog (GET)

Renvoie vos métadonnées de catalogue incluses dans votre courtier.

resource instances (PUT)

Crée votre instance de service.

resource instances (DELETE)

Supprime votre instance de service.

resource instances (PATCH)

Met à jour votre instance de service.

Remarque concernant catalog (GET) : ce noeud final définit le contrat entre le courtier et la plateforme IBM Cloud pour les services et les plans pris en charge par le courtier. Ce point de terminaison renvoie les métadonnées du catalogue stockées dans votre courtier. Ces valeurs définissent le contrat minimal entre votre service et la plateforme IBM Cloud. Toutes les métadonnées supplémentaires du catalogue qui ne sont pas obligatoires sont stockées dans le catalogue « IBM Cloud ». Toute mise à jour des valeurs d'affichage du catalogue, telles que les liens et les icônes, doit être effectuée dans la IBM Cloud console et non hébergée chez votre courtier. Aucune des métadonnées stockées dans votre courtier ne s'affiche dans la console IBM Cloud ou l'interface de ligne de commande IBM Cloud. La console et l'interface de ligne de commande (CLI) renvoient les paramètres définis dans Partner Center Sell et enregistrés dans le catalogue « IBM Cloud ». La section suivante présente les valeurs minimales requises renvoyées par la requête (GET) « catalog » :

{
       "services": [{
           "id": "0bc9d744-6f8c-4821-9648-2278bf6925bb",
           "name": "ibmcloud-link",
           "description": "An IBM provided service that enables aliasing to service instances in the IBM Cloud.",
           "bindable": true,
           "plan_updateable": false,
           "plans": [
               {
                   "id": "da40662d-2f72-4a19-8c79-8c77cf285e1",
                   "name": "ibmcloud-alias",
                   "free": true,
                   "description": "The IBM Cloud alias plan used for linking."
               }
               ]
       }]
}

Logique des noeuds finaux requis pour les services pouvant être liés

Si votre service peut être associé à des applications dans IBM Cloud, il doit fournir des points de terminaison API et des identifiants à ses utilisateurs. Un service pouvant être lié doit utiliser les opérations pouvant être liées dans la spécification Open Service Broker et implémenter les noeuds finaux ou les chemins suivants :

bindings and credentials (PUT)

Lie votre instance de service à une application.

bindings and credentials (DEL)

Annule la liaison de votre instance de service à une application.

Noeuds finaux d'extension IBM Cloud requis

La spécification OSB ne prend pas en charge un état d'instance désactivé. Un état désactivé inclut un paiement manquant ou d'autres situations qui entraînent une suspension de compte (mais pas encore d'annulation) et est différent d'un état d'instance supprimé. Afin IBM Cloud d'aider les clients susceptibles de rencontrer un état de désactivation, IBM Cloud a défini les points de terminaison API étendus qui permettent de désactiver et de réactiver les instances de service. Les extensions de point de terminaison suivantes sont requises :

enable and disable instances (GET)

Statut - renvoie l'état de votre instance de service.

enable and disable instances (PUT)

Activer ou désactiver une instance de service.

Le fournisseur de services a la charge de désactiver l'accès à l'instance de service lorsque le noeud final de désactivation est démarré puis de réactiver cet accès lorsque le noeud final d'activation est démarré.

X-Broker-API-Originating-Identity

L'en-tête d'identité de l'utilisateur est fourni via un en-tête d'identité provenant de l'API. Cet en-tête de demande inclut l'identité IAM IBM Cloud de l'utilisateur. L'identité IAM est codée au format « base64 ». IBM Cloud prend en charge un seul domaine d'authentification : IBMid. Le domaine IBMid utilise un ID unique (IU) IBMid pour définir l'identité de l'utilisateur dans IBM Cloud. Cet ID unique est une chaîne opaque pour le fournisseur de services.

Exemple :

X-Broker-API-Originating-Identity: ibmcloud eyJpYW1faWQiOiJJQk1pZC01MEdOUjcxN1lFIn0=
Decoded:
{"iam_id":"IBMid-50GNR717YE"}

Version d'en-tête d'API

L' en-tête de version d'API est 2.12. Par exemple : X-Broker-Api-Version: 2.12.

resource instance (PUT) body.context et resource instance (PATCH) body.context

PUT /v2/service_instances/:resource_instance_id and PATCH /v2/service_instances/:resource_instance_id receive the following value within body.context: { "platform": "ibmcloud", "account_id": "tracys-account-id", "crn": "resource-instance-crn" }.

Recommandations en matière d'utilisation d'opérations asynchrones au lieu d'opérations synchrones

L'API OSB prend en charge à la fois les modes de fonctionnement synchrones et asynchrones. Si vos opérations prennent moins de 10 secondes, vous devez utiliser des réponses synchrones. Dans le cas contraire, vous devez utiliser le mode de fonctionnement asynchrone. Le mode asynchrone requiert le noeud final last_operation. Pour plus d'informations, voir Obtention du statut d'une mise à disposition en cours pour une instance de service.

Recommandations pour la gestion des courtiers dans les différents emplacements

Il est important que les utilisateurs connaissent l'emplacement de leurs services Cloud pour le temps d'attente, la disponibilité et l'hébergement des données.

Lorsque vous créez des instances de service sur IBM Cloud, l'un des paramètres obligatoires que vos utilisateurs doivent fournir est l'emplacement où ils souhaitent que cette instance de service soit créée. Certains services permettent de créer des contenus à plusieurs endroits. Par exemple, un service de base de données peut prendre en charge la création dans toutes les régions d' IBM Cloud, ou seulement dans certaines d'entre elles.

Si votre service de tiers reposant sur une API est implémenté dans un autre cloud et exposé dans IBM Cloud, l'emplacement indique l'emplacement du service dans l'autre cloud.

Lors de l'intégration à IBM Cloud, vous devez implémenter au moins un courtier OSB. Vous pouvez avoir plus d'un courtier en fonction de votre stratégie de déploiement et des emplacements à prendre en charge pour votre service. Dans Partner Center Sell, vous établissez le mappage entre votre plan de tarification et le courtier. En général, on a le choix entre définir un seul courtier pour desservir tous les sites de votre service ou définir un courtier par site; ce choix revient au prestataire de services.

Pour obtenir la liste des emplacements disponibles, consultez les emplacements du catalogue globalIBM. Si votre service nécessite la définition d'un plus grand nombre de sites, veuillez contacter l'équipe d'intégration d' IBM Cloud.