Erforderliche Endpunktlogik für alle Service-Broker

Service-Broker müssen eine Standardgruppe von Metadatenwerten bereitstellen, die von den REST-APIs benutzt werden, und IBM Cloud-Broker müssen über Logik für die folgenden REST-API-Endpunkte und -Pfade verfügen:

Katalog (GET)

Gibt die Katalogmetadaten zurück, die in Ihrem Broker enthalten sind.

Ressourceninstanzen (PUT)

Erstellt Ihre Serviceinstanz.

Ressourceninstanzen (DELETE)

Löscht Ihre Serviceinstanz.

Ressourceninstanzen (PATCH)

Aktualisiert Ihre Serviceinstanz.

Hinweis zu 'Katalog (GET)': Dieser Endpunkt definiert den Vertrag zwischen dem Broker und der IBM Cloud-Plattform für die Services und Pläne, die vom Broker unterstützt werden. Dieser Endpunkt gibt die Katalog-Metadaten zurück, die in Ihrem Broker gespeichert sind. Diese Werte definieren den Mindestvertrag zwischen Ihrem Dienst und der Plattform IBM Cloud. Alle zusätzlichen Katalog-Metadaten, die nicht benötigt werden, werden im IBM Cloud Katalog gespeichert. Alle Aktualisierungen von Kataloganzeigewerten wie Links und Symbole müssen in der IBM Cloud-Konsole aktualisiert und nicht in Ihrem Broker enthalten sein. Keine der in Ihrem Broker gespeicherten Metadaten werden in der IBM Cloud-Konsole oder der IBM Cloud-CLI angezeigt. Die Konsole und die Befehlszeile geben zurück, was im Partner Center Sell eingestellt und im Katalog IBM Cloud gespeichert wurde. Der folgende Abschnitt zeigt die minimal erforderlichen Werte, die catalog (GET) zurückgibt:

{
       "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."
               }
               ]
       }]
}

Erforderliche Endpunktlogik für bindefähige Services

Wenn Ihr Dienst an Anwendungen in IBM Cloud gebunden werden kann, muss er API-Endpunkte und Anmeldeinformationen an Ihre Dienstnutzer zurückgeben. Ein bindefähiger Service muss die bindefähigen Operationen in der Open Service Broker-Spezifikation verwenden und die folgenden Endpunkte oder Pfade implementieren:

Bindungen und Berechtigungsnachweise (PUT)

Bindet Ihre Serviceinstanz an eine Anwendung.

Bindungen und Berechtigungsnachweise (DEL)

Hebt die Bindung Ihrer Serviceinstanz an eine Anwendung auf.

Erforderliche IBM Cloud-Erweiterungsendpunkte

Die OSB-Spezifikation unterstützt keinen inaktivierten Instanzstatus. Ein inaktivierter Status enthält eine fehlende Zahlung oder andere Situationen, die zu einer Kontosperrung führen (aber noch nicht storniert wurden) und sich vom Status einer gelöschten Instanz unterscheiden. Damit IBM Cloud Kunden unterstützen kann, deren Status möglicherweise inaktiviert ist, hat IBM Cloud die erweiterten API-Endpunkte definiert, die die Inaktivierung und erneute Aktivierung von Serviceinstanzen ermöglichen. Die folgenden Endpunkterweiterungen sind erforderlich:

Instanzen aktivieren und inaktivieren (GET)

Status - Gibt den Status Ihrer Serviceinstanz zurück.

Instanzen aktivieren und inaktivieren (PUT)

Aktiviert oder inaktiviert eine Serviceinstanz.

Die Inaktivierung des Zugriffs auf die Serviceinstanz bei Aufruf des Inaktivierungsendpunkts und die erneute Aktivierung des Zugriffs bei Aufruf des Aktivierungsendpunkts ist Aufgabe des Service-Providers.

X-Broker-API-Originating-Identity

Der Benutzeridentitäts-Header wird durch einen API-Ursprungsidentitäts-Header bereitgestellt. Dieser Anforderungsheader enthält die IBM Cloud-IAM-Identität des Benutzers. Die IAM-Identität ist base64 codiert. IBM Cloud unterstützt einen einzelnen Authentifizierungsrealm: IBMid Der Realm IBMid verwendet eine eindeutige IBMid-ID (IUI = IBMid Unique ID), um die Identität des Benutzers in IBM Cloud zu ermitteln. Diese IUI stellt für den Service-Provider eine nicht transparente Zeichenfolge dar.

Beispiel:

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

Version des API-Headers

Der API-Versionsheader ist 2.12. Beispiel: X-Broker-Api-Version: 2.12.

Ressourceninstanz (PUT) body.context und Ressourceninstanz (PATCH) body.context

PUT /v2/service_instances/:resource_instance_id und PATCH /v2/service_instances/:resource_instance_id empfangen den folgenden Wert in body.context: { "platform": "ibmcloud", "account_id": "tracys-account-id", "crn": "resource-instance-crn" }.

Empfehlungen zur Verwendung asynchroner anstelle synchroner Operationen

Die OSB-API unterstützt sowohl den synchronen als auch den asynchronen Betriebsmodus. Wenn Ihre Operationen weniger als 10 Sekunden dauern, müssen Sie synchrone Antworten verwenden. Andernfalls müssen Sie den asynchronen Betriebsmodus verwenden. Der asynchrone Modus erfordert den Endpunkt last_operation. Weitere Informationen finden Sie unter Status einer laufenden Bereitstellung für eine Serviceinstanz abrufen.

Empfehlungen für die positionsübergreifende Verwaltung von Brokern

Für Benutzer ist es wichtig, die Gegebenheiten der Position für ihre Cloud-Services in Bezug auf die Latenzzeiten, die Verfügbarkeit und den Datenspeicherort zu kennen.

Wenn Sie Dienstinstanzen auf IBM Cloud erstellen, ist einer der erforderlichen Parameter, den Ihre Benutzer angeben, der Ort, an dem die Dienstinstanz erstellt werden soll. Einige Dienste können die Erstellung an mehreren Standorten unterstützen. So kann ein Datenbankdienst beispielsweise die Erstellung in allen Regionen von IBM Cloud oder nur in einer Teilmenge unterstützen.

Wenn Ihr API-basierter Drittanbieterservice in einer anderen Cloud implementiert wurde und in IBM Cloud zugänglich gemacht wurde, gibt die Position die Position des Service in der anderen Cloud an.

Beim IBM Cloud-Onboarding müssen Sie mindestens einen OSB-Broker implementieren. Sie können je nach Bereitstellungsstrategie und den Standorten, die für Ihren Service unterstützt werden sollen, mit mehreren Brokern arbeiten. Im Partner Center Sell erstellen Sie die Zuordnung zwischen Ihrem Preistarif und dem Broker. In der Regel haben Sie die Wahl zwischen der Definition eines einzigen Brokers, der alle Standorte Ihres Dienstes bedient, und der Definition eines Brokers pro Standort; diese Entscheidung obliegt dem Dienstanbieter.

Eine Liste der verfügbaren Positionen finden Sie unter IBM global catalog locations. Wenn für Ihren Service weitere Standorte definiert werden müssen, wenden Sie sich an das IBM Cloud -Onboarding-Team.