Schema 1

{
  "type": "record",
  "name": "book",
  "fields": [
    {
      "name": "title",
      "type": "string"
    },
    {
      "name": "author",
      "type": "string"
    }
  ]
}

Schema 2

{
  "type": "record",
  "name": "book",
  "fields": [
    {
      "name": "author",
      "type": "string"
    },
    {
      "name": "title",
      "type": "string"
    }
  ]
}

Schema 3

{
  "type": "record",
  "name": "book",
  "fields": [
    {
      "type": "string"
      "name": "author",
    },
    {
      "type": "string"
      "name": "title",
    }
  ]
}

Schema 1 und Schema 2 sind unterschiedliche Schemata und die Registry speichert sie als separate Schemata. Sie können nicht austauschbar verwendet werden, weil sie die Felder author und title in einer anderen Reihenfolge auflisten. Mit Schema 1 codierte Daten werden nicht korrekt decodiert, wenn der Decodierungsprozess Schema 2 verwendet.

Wenn Sie das SerDes verwenden, um das neue Schema in der Reihenfolge Schema 1, Schema 2 und Schema 3 zu erstellen, erhalten Sie zwei neue Schemas. Schema 1 und Schema 2 unterscheiden sich, aber Schema 3 entspricht Schema 2.

Wenn Sie Schemas mithilfe der REST-API erstellen, werden Schemas nur dann als übereinstimmend betrachtet, wenn sie textgleich sind, einschließlich aller Attributsortierungs-und beschreibenden Felder. Dies gilt für den Fall, dass Schema 3 ein anderes Schema sein soll.

Authentifizierung

Für den Zugriff auf die Schemaregistry benötigen Sie außerdem eine Gruppe von Berechtigungsnachweisen, die für die Authentifizierung bei der Registry verwendet werden können. Es gibt zwei Optionen: Basisauthentifizierung mit einem API-Schlüssel oder Trägertokenauthentifizierung.

Die Beispiele in diesem Dokument zeigen die Verwendung des API-Schlüssels, aber es können beide Optionen verwendet werden.

curl -u token:$APIKEY ...

curl -H "Authorization: Bearer $TOKEN" ...

Fehler

Wenn ein Fehlerzustand auftritt, gibt die Schema-Registrierung einen non-2XX-Bereich HTTP-Statuscode zurück. Der Hauptteil der Antwort enthält ein JSON-Objekt in der folgenden Form:

{
    "error_code":404,
    "message":"No artifact with id 'my-schema' might be found."
}

Die Eigenschaften des JSON-Fehlerobjekts sind folgende:

Schemastatus festlegen

Dieser Endpunkt wird verwendet, um den Status eines Schemas in der Registry auf ENABLED oder DISABLED zu setzen. Der Status eines Schemas kann durch Absetzen einer PUT-Anforderung an den Endpunkt /artifacts/{schema-id}/state festgelegt werden (dabei ist {schema-id} die ID des Schemas). Wenn die Anfrage erfolgreich ist, wird eine leere Antwort und ein Statuscode von 204 (kein Inhalt) zurückgegeben.

Beispiel für curl-Anforderung:

curl -u token:$APIKEY –X PUT $URL/artifacts/my-schema/state -d '{"state": "DISABLED"}'

Das Festlegen eines Schemastatus erfordert Folgendes:

• Zugriff auf die Schema-Ressource, die dem geänderten Schema entspricht, für Manager-Rollen.

Schemaversionsstatus festlegen

Dieser Endpunkt wird verwendet, um den Status einer Schemaversion in der Registry auf ENABLED oder DISABLED zu setzen. Der Status einer Schemaversion kann durch Absetzen einer PUT-Anforderung an den Endpunkt /artifacts/{schema-id}/versions/{version}/state festgelegt werden (dabei ist {schema-id} die ID des Schemas und {version} die Versionsnummer der Schemaversion). Wenn die Anfrage erfolgreich ist, wird eine leere Antwort und ein Statuscode von 204 (kein Inhalt) zurückgegeben.

Beispiel für curl-Anforderung:

curl -u token:$APIKEY –X PUT $URL/artifacts/my-schema/versions/1/state -d '{"state": "DISABLED"}'

Das Festlegen eines Schemaversionsstatus erfordert Folgendes:

• Zugriff auf die Schema-Ressource, die dem zu ändernden Schema entspricht, für Manager-Rollen.

Schema erstellen

Dieser Endpunkt wird zum Speichern eines Schemas in der Registry verwendet. Die Schemadaten werden im Hauptteil der POST-Anforderung gesendet. Eine ID für das Schema kann über den Anforderungsheader ‘X-Registry-ArtifactId' hinzugefügt werden. Wenn dieser Header in der Anfrage nicht vorhanden ist, wird eine ID generiert. Der Inhaltstypheader ('Content-Type') muss auf den Wert “application/json” gesetzt werden.

Beispiel für curl-Anforderung:

curl -u token:$APIKEY -H 'Content-Type: application/json' -H 'X-Registry-ArtifactId: my-schema' $URL/artifacts -d '{"type":"record","name":"Citizen","fields":[{"name": "firstName","type":"string"},{"name":"lastName","type":"string"},{"name":"age","type":"int"},{"name":"phoneNumber","type":"string"}]}'

Beispielantwort:

{"id":"my-schema","type":"AVRO","version":1,"createdBy":"","createdOn":1579267788258,"modifiedBy":"","modifiedOn":1579267788258,"globalId":75}

Für das Erstellen eines Schemas sind mindestens die beiden folgenden Zugriffsrollen erforderlich:

• Rolle eines Leseberechtigten für den Zugriff auf den Ressourcentyp des Event Streams-Clusters
• Zugriff des Writer-Rollen auf die Schema-Ressource, die dem erstellten Schema entspricht.

Es wird ein Activity Tracker-Ereignis generiert, um die Aktion zu melden. Weitere Informationen finden Sie unter Activity Tracker-Ereignisse.

Schemas auflisten

Sie können eine Liste der IDs aller Schemata erstellen, die in der Registrierung gespeichert sind, indem Sie eine GET-Anfrage an den Endpunkt /artifacts senden. Sie können die Antwort mit dem Parameter jsonformat formatieren (nur die Formate string und object werden unterstützt). Das Zeichenfolgeformat ist der Standardwert und gibt ein Array von Artefakt-IDs (Zeichenfolgen) zurück. Wenn diese Optionen festgelegt sind, werden nur aktivierte Artefakte in das Array eingeschlossen. Das Objektformat gibt ein JSON-Objekt zurück, das ein Array enthält, wobei jeder Eintrag im Array einem Artefakt in der Registry entspricht. Sowohl aktivierte als auch inaktivierte Artefakte werden zurückgegeben, wenn diese Option festgelegt ist.

Beispiel für curl-Anforderung:

curl -u token:$APIKEY $URL/artifacts

oder

curl -u token:$APIKEY $URL/artifacts?jsonformat=string

oder

curl -u token:$APIKEY $URL/artifacts?jsonformat=object

Beispielantwort, wenn jsonformat string ist oder nicht angegeben wird (standardmäßig wird string verwendet):

["my-schema-2","my-schema-4"]

Beispielantwort, wenn jsonformat object ist:

{"artifacts":[{"id":"my-schema","state":"DISABLED"},{"id":"my-schema-2","state":"ENABLED"},{"id":"my-schema-3","state":"DISABLED"},{"id":"my-schema-4","state":"ENABLED"}],"count":4}

Zum Auflisten von Schemas ist mindestens die folgende Zugriffsrolle erforderlich:

• Rolle eines Leseberechtigten für den Zugriff auf den Ressourcentyp des Event Streams-Clusters

Status und Löschung von Schemas

Das Löschen eines Schemas ist ein zweistufiger Prozess. In der ersten Phase des Löschvorgangs wird das Schema in der Registry beibehalten, aber vor einigen Operationen ausgeblendet. Die zweite Stufe entfernt das Schema permanent, kann aber nur nach der ersten Stufe angewendet werden. Der zweistufige Löschprozess gilt auf Artefaktebene und auch auf Versionsebene.

Die beiden Phasen des Löschens werden ausgeführt, indem sowohl Artefakten als auch Versionen (erste Stufe) der Status 'Aktiviert' oder 'Inaktiviert' zugeordnet wird und indem APIs für Ressourcen und Versionen (zweite Stufe) gelöscht werden.

Ein Artefakt oder eine Version, die inaktiviert wurde, kann mithilfe einer Eigenschaft 'state' erkannt werden, die von Operationen zurückgegeben wird, die Artefakte oder Versionen auflisten, oder indem die Details eines Artefakts oder einer Version abgerufen werden. Inaktivierte Schemas werden für das Schemakontingent von 1000 Schemas pro Unternehmensinstanz gezählt.

Schema löschen

Schemas werden aus der Registrierung gelöscht, indem eine DELETE-Anfrage an den Endpunkt /artifacts/{schema-id} gesendet wird (wobei {schema-id} die ID des Schemas ist). Bei erfolgreicher Ausführung wird eine leere Antwort und der Statuscode 204 (kein Inhalt) zurückgegeben.

Beispiel für curl-Anforderung:

curl -u token:$APIKEY -X DELETE $URL/artifacts/my-schema

Für das Löschen eines Schemas sind mindestens die beiden folgenden Zugriffsrollen erforderlich:

• Rolle eines Leseberechtigten für den Zugriff auf den Ressourcentyp des Event Streams-Clusters
• Zugriff auf die Schema-Ressource, die dem gelöschten Schema entspricht, für Manager-Rollen.

Es wird ein Activity Tracker-Ereignis generiert, um die Aktion zu melden. Weitere Informationen finden Sie unter Activity Tracker-Ereignisse.

Neue Version eines Schemas erstellen

Um eine neue Version eines Schemas zu erstellen, senden Sie eine POST-Anfrage an den Endpunkt /artifacts/{schema-id}/versions (wobei {schema-id} die ID des Schemas ist). Der Hauptteil der Anforderung muss die neue Version des Schemas enthalten.

Wenn die Anfrage erfolgreich ist, wird das neue Schema als neueste Version des Schemas mit einer entsprechenden Versionsnummer erstellt und eine Antwort mit dem Statuscode 200 (OK) und einer Nutzlast, die Metadaten zur Beschreibung der neuen Version (einschließlich der Versionsnummer) enthält, zurückgegeben.

Beispiel für curl-Anforderung:

curl -u token:$APIKEY -H 'Content-Type: application/json' $URL/artifacts/my-schema/versions -d '{"type":"record","name":"Citizen","fields":[{"name": "firstName","type":"string"},{"name":"lastName","type":"string"},{"name":"age","type":"int"},{"name":"phoneNumber","type":"string"}]}'

Beispielantwort:

{"id":"my-schema","type":"AVRO","version":2,"createdBy":"","createdOn": 1579267978382,"modifiedBy":"","modifiedOn":1579267978382,"globalId":83}

Für das Erstellen einer neuen Version eines Schemas sind mindestens die beiden folgenden Zugriffsrollen erforderlich:

• Rolle eines Leseberechtigten für den Zugriff auf den Ressourcentyp des Event Streams-Clusters
• Zugriff der Rolle "Writer" auf die Schemaressource, die dem Schema entspricht, das eine neue Version erhält.

Es wird ein Activity Tracker-Ereignis generiert, um die Aktion zu melden. Weitere Informationen finden Sie unter Activity Tracker-Ereignisse.

Neueste Version eines Schemas abrufen

Um die neueste Version eines bestimmten Schemas abzurufen, senden Sie eine GET-Anfrage an den Endpunkt /artifacts/{schema-id} (wobei {schema-id} die ID des Schemas ist). Ist die Anforderung erfolgreich, wird die neueste Version des Schemas in den Nutzdaten der Antwort zurückgegeben.

Beispiel für curl-Anforderung:

curl -u token:$APIKEY $URL/artifacts/my-schema

Beispielantwort:

{"type":"record","name":"Citizen","fields":[{"name": "firstName","type":"string"},{"name":"lastName","type":"string"},{"name":"age","type":"int"},{"name":"phoneNumber","type":"string"}]}

Für den Abruf der neuesten Version eines Schemas sind mindestens die beiden folgenden Zugriffsrollen erforderlich:

• Rolle eines Leseberechtigten für den Zugriff auf den Ressourcentyp des Event Streams-Clusters
• Zugriff der Reader-Rolle auf die Schemaressource, die dem abgerufenen Schema entspricht.

Bestimmte Version eines Schemas abrufen

Um eine bestimmte Version eines Schemas abzurufen, senden Sie eine GET-Anfrage an den Endpunkt /artifacts/{schema-id}/versions/{version} (wobei {schema-id} die ID des Schemas und {version} die Versionsnummer der spezifischen Version ist, die Sie abrufen möchten). Ist die Anforderung erfolgreich, wird die angegebene Version des Schemas in den Nutzdaten der Antwort zurückgegeben.

Beispiel für die Curl-Anforderung:

curl -u token:$APIKEY $URL/artifacts/my-schema/versions/3

Beispielantwort:

{"type":"record","name":"Citizen","fields":[{"name": "firstName","type":"string"},{"name":"lastName","type":"string"},{"name":"age","type":"int"},{"name":"phoneNumber","type":"string"}]}

Für den Abruf der neuesten Version eines Schemas sind mindestens die beiden folgenden Zugriffsrollen erforderlich:

• Rolle eines Leseberechtigten für den Zugriff auf den Ressourcentyp des Event Streams-Clusters
• Zugriff der Reader-Rolle auf die Schemaressource, die dem abgerufenen Schema entspricht.

Alle Versionen eines Schemas auflisten

Um alle Versionen eines Schemas aufzulisten, die derzeit in der Registrierung gespeichert sind, senden Sie eine GET-Anfrage an den Endpunkt /artifacts/{schema-id}/versions (wobei {schema-id} die ID des Schemas ist). Ist die Anforderung erfolgreich, wird eine Liste aller aktuellen Versionsnummern für das Schema in den Nutzdaten der Antwort zurückgegeben. Sie können die Antwort mit dem Parameter jsonformat formatieren (nur die Formate number und object werden unterstützt). Wenn Sie 'number' (Standardwert) angeben, ist die Antwort ein Array numerischer Werte, die aktivierten Versionen des Artefakts entsprechen (inaktivierte Versionen werden übergangen). Es hat dasselbe Format wie der momentan generierte Endpunkt. Wenn Sie 'object' angeben, ist die Antwort ein JSON-Objekt, das ein Array von JSON-Objekten enthält, die Versionen des Artefakts darstellen. Sowohl aktivierte als auch inaktivierte Versionen sind im Array enthalten.

Beispiel für curl-Anforderung:

curl -u token:$APIKEY $URL/artifacts/my-schema/versions

oder

curl -u token:$APIKEY $URL/artifacts/my-schema/versions?jsonformat=number

oder

curl -u token:$APIKEY $URL/artifacts/my-schema/versions?jsonformat=object

Beispielantwort, wenn jsonformat number ist oder nicht angegeben wird (standardmäßig wird number verwendet):

[1,3,4,6,7]

Beispielantwort, wenn jsonformat object ist:

{"versions":[{"id":1,"state":"ENABLED"},{"id":2,"state":"DISABLED"},{"id":3,"state":"ENABLED"},{"id":4,"state":"ENABLED"},{"id":5,"state":"DISABLED"},{"id":6,"state":"ENABLED"},{"id":7,"state":"ENABLED"}],"count":7}

Für den Abruf der Liste der verfügbaren Versionen eines Schemas sind mindestens die beiden folgenden Zugriffsrollen erforderlich:

• Rolle eines Leseberechtigten für den Zugriff auf den Ressourcentyp des Event Streams-Clusters
• Zugriff der Reader-Rolle auf die Schemaressource, die dem abgerufenen Schema entspricht.

Version eines Schemas löschen

Schema-Versionen werden aus der Registrierung gelöscht, indem eine DELETE-Anfrage an den Endpunkt /artifacts/{schema-id}/versions/{version} gesendet wird (wobei {schema-id} die ID des Schemas und {version} die Versionsnummer der Schema-Version ist). Bei erfolgreicher Ausführung wird eine leere Antwort und der Statuscode 204 (kein Inhalt) zurückgegeben. Wenn die einzige verbleibende Version eines Schemas gelöscht wird, wird auch das Schema gelöscht.

Beispiel für curl-Anforderung:

curl -u token:$APIKEY -X DELETE $URL/artifacts/my-schema/versions/3

Für das Löschen einer Schemaversion sind mindestens die beiden folgenden Zugriffsrollen erforderlich:

• Rolle eines Leseberechtigten für den Zugriff auf den Ressourcentyp des Event Streams-Clusters
• Zugriff auf die Schema-Ressource, die dem gelöschten Schema entspricht, für Manager-Rollen.

Es wird ein Activity Tracker-Ereignis generiert, um die Aktion zu melden. Weitere Informationen finden Sie unter Activity Tracker-Ereignisse.

Bestimmte globale eindeutige ID einer Schemaversion abrufen

Um eine bestimmte globale eindeutige ID einer Schemaversion abzurufen, senden Sie eine GET-Anfrage an den Endpunkt /artifacts/{artifactId}/versions/{version}/meta (wobei {artifactId} die ID des Artefakts und {version} die Versionsnummer der spezifischen Version ist, die Sie abrufen möchten). Bei erfolgreicher Ausführung wird die spezifische globale eindeutige ID einer Schemaversion in den Nutzdaten der Antwort zurückgegeben.

Beispiel für curl-Anforderung:

curl -u token:$APIKEY $URL/artifacts/9030f450-45fb-4750-bb37-771ad49ee0e8/versions/1/meta

Beispielantwort:

{"id":"9030f450-45fb-4750-bb37-771ad49ee0e8","type":"AVRO","version":1,"createdOn":1682340169202,"modifiedOn":1682340169202,"globalId":1}

Zum Abrufen der globalen eindeutigen ID einer Schemaversion sind mindestens die folgenden Zugriffstypen erforderlich:

• Rolle eines Leseberechtigten für den Zugriff auf den Ressourcentyp des Event Streams-Clusters
• Zugriff der Reader-Rolle auf die Schemaressource, die dem abgerufenen Schema entspricht.

Globale Regel aktualisieren

Globale Kompatibilitätsregeln können aktualisiert werden, indem eine PUT-Anfrage an den Endpunkt /rules/ {rule-type} gesendet wird (wobei {rule-type} den Typ der zu aktualisierenden globalen Regel angibt – derzeit wird nur der Typ COMPATIBILITY unterstützt), wobei die neue Regelkonfiguration im Textkörper der Anfrage enthalten ist. Wenn die Anforderung erfolgreich ist, wird die neu aktualisierte Regelkonfiguration ('config') in den Nutzdaten der Antwort zusammen mit dem Statuscode 200 (OK) zurückgegeben.

Das im Textkörper der Anfrage gesendete JSON-Dokument muss folgende Eigenschaften aufweisen:

Beispiel für curl-Anforderung:

curl -u token:$APIKEY -X PUT $URL/rules/COMPATIBILITY -d '{"type":"COMPATIBILITY","config":"BACKWARD"}'

Beispielantwort:

{"type":"COMPATIBILITY","config":"BACKWARD"}

Für das Aktualisieren einer globalen Regelkonfiguration ist mindestens die folgende Zugriffsrolle erforderlich:

• Rolle eines Managers für den Zugriff auf den Ressourcentyp des Event Streams-Clusters

Es wird ein Activity Tracker-Ereignis generiert, um die Aktion zu melden. Weitere Informationen finden Sie unter Activity Tracker-Ereignisse.

Aktuellen Wert einer globalen Regel abrufen

Der aktuelle Wert einer globalen Regel wird durch eine GET-Anfrage an den Endpunkt /rules/ {rule-type} abgerufen (wobei {rule-type} der Typ der abzurufenden globalen Regel ist – derzeit wird nur der Typ COMPATIBILITY unterstützt). Wenn die Anforderung erfolgreich ist, wird die aktuelle Regelkonfiguration in den Nutzdaten der Antwort zusammen mit dem Statuscode 200 (OK) zurückgegeben.

Beispiel für curl-Anforderung:

curl -u token:$APIKEY $URL/rules/COMPATIBILITY

Beispielantwort:

{"type":"COMPATIBILITY","config":"BACKWARD"}

Für den Abruf der globalen Regelkonfiguration ist mindestens die folgende Zugriffsrolle erforderlich:

• Rolle eines Leseberechtigten für den Zugriff auf den Ressourcentyp des Event Streams-Clusters

Regel für bestimmtes Schema erstellen

Regeln können auf ein bestimmtes Schema angewendet werden und dabei alle festgelegten globalen Regeln überschreiben, indem eine POST-Anfrage an den Endpunkt /artifacts/{schema-id}/rules gesendet wird (wobei {schema-id} die ID des Schemas ist), wobei der Typ und der Wert der neuen Regel im Textkörper der Anfrage enthalten sind (derzeit wird nur der Typ COMPATIBILITY unterstützt). Bei erfolgreicher Ausführung wird eine leere Antwort und der Statuscode 204 (kein Inhalt) zurückgegeben.

Beispiel für curl-Anforderung:

curl -u token:$APIKEY $URL/artifacts/my-schema/rules -d '{"type":"COMPATIBILITY","config":"FORWARD"}'

Für das Erstellen von Regeln für bestimmte Schemas sind mindestens die folgenden Zugriffsrollen erforderlich:

• Rolle eines Leseberechtigten für den Zugriff auf den Ressourcentyp des Event Streams-Clusters
• Zugriff auf die Schema-Ressource, für die die Regel gilt, für die Rolle "Manager".

Es wird ein Activity Tracker-Ereignis generiert, um die Aktion zu melden. Weitere Informationen finden Sie unter Activity Tracker-Ereignisse.

Regel für bestimmtes Schema abrufen

Um den aktuellen Wert eines Regeltyps abzurufen, der auf ein bestimmtes Schema angewendet wird, wird eine GET-Anfrage an den Endpunkt /artifacts/{schema-id}/rules/{rule-type} gesendet (wobei {schema-id} die ID des Schemas und {rule-type} der Typ der abzurufenden globalen Regel ist – derzeit wird nur der Typ COMPATIBILITY unterstützt). Wenn die Anforderung erfolgreich ist, wird der aktuelle Regelwert in den Nutzdaten der Antwort zusammen mit dem Statuscode 200 (OK) zurückgegeben.

Beispiel für curl-Anforderung:

curl -u token:$APIKEY $URL/artifacts/my-schema/rules/COMPATIBILITY

Beispielantwort:

{"type":"COMPATIBILITY","config":"FORWARD"}

Für den Abruf von Regeln für bestimmte Schemas sind mindestens die folgenden Zugriffsrollen erforderlich:

• Rolle eines Leseberechtigten für den Zugriff auf den Ressourcentyp des Event Streams-Clusters
• Rolle eines Leseberechtigten für den Zugriff auf die Schemaressource, auf die die Regel angewendet wird.

Regel für bestimmtes Schema aktualisieren

Die für ein bestimmtes Schema geltenden Regeln werden durch eine PUT-Anfrage an den Endpunkt /artifacts/{schema-id}/rules/{rule-type} geändert (wobei {schema-id} die ID des Schemas und {rule-type} der Typ der abzurufenden globalen Regel ist – derzeit wird nur der Typ COMPATIBILITY unterstützt). Wenn die Anforderung erfolgreich ist, wird die neu aktualisierte Regelkonfiguration ('config') in den Nutzdaten der Antwort zusammen mit dem Statuscode 200 (OK) zurückgegeben.

Beispiel für curl-Anforderung:

curl -u token:$APIKEY -X PUT $URL/artifacts/my-schema/rules/COMPATIBILITY -d '{"type":"COMPATIBILITY","config":"BACKWARD"}'

Beispielantwort:

{"type":"COMPATIBILITY","config":"BACKWARD"}

Für das Aktualisieren einer Regel für ein bestimmtes Schema sind mindestens die folgenden Zugriffsrollen erforderlich:

• Rolle eines Leseberechtigten für den Zugriff auf den Ressourcentyp des Event Streams-Clusters
• Rolle eines Managers für den Zugriff auf die Schemaressource, auf die die Regel angewendet wird.

Es wird ein Activity Tracker-Ereignis generiert, um die Aktion zu melden. Weitere Informationen finden Sie unter Activity Tracker-Ereignisse.

Regel für bestimmtes Schema löschen

Die für ein bestimmtes Schema geltenden Regeln werden gelöscht, indem eine DELETE-Anfrage an den Endpunkt /artifacts/{schema-id}/rules/{rule-type} gesendet wird (wobei {schema-id} die ID des Schemas und {rule-type} der Typ der abzurufenden globalen Regel ist – derzeit wird nur der Typ COMPATIBILITY unterstützt). Wenn die Anforderung erfolgreich ist, wird eine leere Antwort mit dem Statuscode 204 (kein Inhalt) zurückgegeben.

Beispiel für curl-Anforderung:

curl -u token:$APIKEY -X DELETE $URL/artifacts/my-schema/rules/COMPATIBILITY

Für das Löschen einer Regel für ein bestimmtes Schema sind mindestens die folgenden Zugriffsrollen erforderlich:

• Rolle eines Leseberechtigten für den Zugriff auf den Ressourcentyp des Event Streams-Clusters
• Rolle eines Managers für den Zugriff auf die Schemaressource, auf die die Regel angewendet wird.

Es wird ein Activity Tracker-Ereignis generiert, um die Aktion zu melden. Weitere Informationen finden Sie unter Activity Tracker-Ereignisse.