Verwenden der Entwickler-API zum Hinzufügen verbraucherdefinierter Vorlagen hinzuzufügen

Im traditionellen Ablauf von Snowflake Data Clean Rooms verwendet ein Anbieter die Entwickler-API, um benutzerdefinierte Vorlagen zu erstellen, und fügt sie dann dem Reinraum hinzu, den der Anbieter mit einem Kunden teilt. Der Verbraucher verwendet diese Vorlage dann zur Durchführung von Analysen im Reinraum.

In manchen Fällen möchte der Kunde seine eigene benutzerdefinierte Vorlage erstellen können, um die Art der Analyse zu steuern, die im Reinraum ausgeführt werden kann. In diesem Szenario erstellt der Anbieter weiterhin den Reinraum und gibt ihn frei, aber der Verbraucher definiert eine Vorlage innerhalb dieses Reinraums. Da es sich um ihren Reinraum handelt, muss der Anbieter ausdrücklich erlauben, dass diese verbraucherdefinierte Vorlage dem Reinraum hinzugefügt wird.

Die Möglichkeit, eine vom verbraucherdefinierte Vorlage zum Reinraum eines Anbieters hinzuzufügen, ist häufig eine Anforderung in einem Reinraum mit mehreren Anbietern, in dem der Verbraucher Analysen mit Daten von mehr als einem Anbieter gleichzeitig durchführt. In dieser Umgebung ist der Kunde möglicherweise am besten in der Lage zu wissen, wie er aus den Daten mehrerer Parteien Erkenntnisse gewinnen kann, und er kann mithilfe der Entwickler-API eine benutzerdefinierte Vorlage erstellen, um dies zu tun. Bei verbraucherdefinierten Vorlagen in einer Umgebung mit mehreren Anbietern muss jeder Anbieter die Vorlage genehmigen, bevor sie verwendet werden kann. Ein ausführliches Beispiel für die Verwendung eines Reinraums mit mehreren Anbietern finden Sie unter Snowflake Data Clean Rooms: Multi-Anbieter-Reinräume.

Grundlegender Arbeitsablauf für verbraucherdefinierte Vorlagen

Der Prozess der Verwendung der Entwickler-API zum Hinzufügen von verbraucherdefinierten Vorlagen zum Reinraum eines Anbieters erfordert koordinierte Aktionen sowohl von Seiten des Verbrauchers als auch des Anbieters. Dieser grundlegende Workflow ist:

Verbraucher:

Sendet eine Anfrage an den Anbieter des Reinraums, dass eine benutzerdefinierte Vorlage hinzugefügt werden soll. Diese Anfrage enthält die Definition der Vorlage, die in der Jinja Templating-Sprache geschrieben ist.

Anbieter:
  1. Überprüft neue Anfragen von Verbrauchern, die dem Reinraum Vorlagen hinzufügen möchten.

  2. Nachdem Sie die Vorlagendefinition überprüft haben, genehmigt die Anfrage oder lehnt sie ab.

Verbraucher:

Überprüft, ob ihre Anfrage genehmigt wurde. Der Verbraucher kann unter jederzeit den Status der Anfrage überprüfen.

Anfragen an einen Anbieter senden

Ein Verbraucher führt den Befehl consumer.create_template_request aus, um eine Anfrage an den Anbieter eines Reinraums zu senden. Diese Anfrage enthält den Namen der Vorlage zusammen mit dem Jinja-Code, der die Vorlage definiert.

Nehmen wir zum Beispiel an, der Anbieter gibt den Reinraum dcr_cleanroom für einen Verbraucher frei. Der Kunde möchte dem Reinraum eine Vorlage mit dem Namen my_overlap_analysis hinzufügen. Um eine Anfrage an den Anbieter des Reinraums zu senden, führt der Verbraucher den folgenden Befehl aus:

CALL samooha_by_snowflake_local_db.consumer.create_template_request('dcr_cleanroom',
  'my_analysis',
  $$
  SELECT
      identifier({{ dimensions[0] | column_policy }})
  FROM
      identifier({{ my_table[0] }}) c
    INNER JOIN
      identifier({{ source_table[0] }}) p
        ON
          c.identifier({{ consumer_id  }}) = identifier({{ provider_id | join_policy }})
       {% if where_clause %} where {{ where_clause | sqlsafe | join_and_column_policy }} {% endif %};
  $$);
Copy

Das dritte Argument ist der Jinja-Code, der die Vorlage definiert.

Eine Referenzdokumentation für den Befehl consumer.create_template_request finden Sie im Abschnitt „Verbraucherdefinierte Vorlagen“ unter Snowflake Data Clean Rooms: Verbraucher-API-Referenzhandbuch.

Auf neue Anfragen von Verbrauchern prüfen

Um zu prüfen, ob neue Anfragen von Verbrauchern vorliegen, führt ein Anbieter den Befehl provider.list_template_requests aus und analysiert dann die Ergebnisse, um Anfragen mit dem Status PENDING zu ermitteln. Der Status PENDING zeigt an, dass der Verbraucher eine neue Anfrage gestellt hat, auf die der Anbieter noch nicht reagiert hat. Die Antwort an provider.list_template_requests enthält den Jinja-Code der Vorlage, mit dem der Anbieter entscheiden kann, ob er die Anfrage genehmigen oder ablehnen möchte.

Nehmen wir zum Beispiel an, der Name des Reinraums des Anbieters ist dcr_cleanroom. Um zu prüfen, ob der Verbraucher eine neue Anfrage zum Hinzufügen einer Vorlage gesendet hat, führt der Anbieter die folgenden Befehle aus:

CALL samooha_by_snowflake_local_db.provider.list_template_requests('dcr_cleanroom');

SELECT * FROM TABLE(RESULT_SCAN(LAST_QUERY_ID())) WHERE status = 'PENDING';
Copy

Die Antwort auf den Befehl provider.list_template_requests enthält für jede Anfrage zur Vorlage Folgendes:

  • UUID, die die Anfrage eindeutig identifiziert

  • Das Konto des Verbrauchers, von dem die Anfrage stammt, im Format des Konto-Locators.

  • Name der Vorlage, den der Verbraucher beim Senden der Anfrage angegeben hat.

  • Jinja-Code, der die Vorlage definiert.

  • Status der Anfrage, der einer der folgenden sein kann: PENDING, APPROVED oder REJECTED.

Eine Referenzdokumentation für den Befehl provider.list_template_requests finden Sie im Abschnitt „Verbraucherdefinierte Vorlagen“ unter Snowflake Data Clean Rooms: Anbieter-API-Referenzhandbuch.

Eine Anfrage genehmigen oder ablehnen

Nachdem der Anbieter eine Anfrage zum Hinzufügen einer verbraucherdefinierten Vorlage erhalten hat, entscheidet er, ob er die Anfrage genehmigt oder ablehnt.

Eine Anfrage genehmigen

Anbieter führen den Befehl provider.approve_template_request aus, um eine Anfrage zum Hinzufügen einer Vorlage zu genehmigen. Der Anbieter gibt an, welche Vorlage genehmigt werden soll, indem er den Bezeichner der Anfrage als Argument angibt.

Nehmen wir zum Beispiel an, der Name des Reinraums des Anbieters ist dcr_cleanroom und der Anfrage des Verbrauchers, eine Vorlage hinzuzufügen, wurde der Bezeichner 01b4d41d-0001-b572 zugewiesen. Um die Anfrage zu genehmigen und die Vorlage zum Reinraum hinzuzufügen, führt der Anbieter den folgenden Befehl aus:

CALL samooha_by_snowflake_local_db.provider.approve_template_request('dcr_cleanroom',
  '01b4d41d-0001-b572');
Copy

Eine Anfrage ablehnen

Anbieter führen den Befehl provider.reject_template_request aus, um eine Anfrage zum Hinzufügen einer Vorlage abzulehnen. Der Anbieter gibt an, welche Vorlage abgelehnt werden soll, indem er den Bezeichner der Anfrage als Argumentangibt.

Nehmen wir zum Beispiel an, der Name des Reinraums des Anbieters ist dcr_cleanroom und der Anfrage des Verbrauchers, eine Vorlage hinzuzufügen, wurde der Bezeichner 01b4d41d-0001-b572 zugewiesen. Nach Prüfung der Jinja-Vorlage stellt der Anbieter fest, dass diese ein Sicherheitsrisiko für den Reinraum darstellt, weshalb er die Anfrage mit einer entsprechenden Begründung ablehnen möchte. Um die Anfrage zum Hinzufügen der Vorlage abzulehnen, führt der Anbieter den folgenden Befehl aus:

CALL samooha_by_snowflake_local_db.provider.reject_template_request('dcr_cleanroom',
  '01b4d41d-0001-b572',
  'Failed security assessment');
Copy

Eine Referenzdokumentation für die Befehle provider.approve_template_request und provider.reject_template_request finden Sie im „Verbraucherdefinierte Vorlagen“ unter Snowflake Data Clean Rooms: Anbieter-API-Referenzhandbuch.

Status der Anfrage als Verbraucher prüfen

Der Verbraucher kann jederzeit den Befehl consumer.list_template_requests ausführen, um den Status seiner Anfrage zum Hinzufügen einer Vorlage zu überprüfen. Der Befehl gibt die folgenden Informationen zurück:

  • UUID, die die Anfrage eindeutig identifiziert

  • Konto des Anbieters, an den die Anfrage gesendet wurde, im Format des Konto-Locators

  • Name der Vorlage, den der Verbraucher beim Senden der Anfrage angegeben hat.

  • Jinja-Code, der die Vorlage definiert.

  • Status der Anfrage, der einer der folgenden sein kann: PENDING, APPROVED oder REJECTED.

  • Wenn die Anfrage abgelehnt wurde, den Grund für die Maßnahme des Anbieters

Nehmen wir zum Beispiel an, der Verbraucher hat eine Anfrage geschickt, um eine Vorlage zum Reinraum dcr_cleanroom hinzuzufügen. Um den Status der Anfrage zu überprüfen und festzustellen, ob sie genehmigt wurde, führt der Verbraucher den folgenden Befehl aus:

CALL samooha_by_snowflake_local_db.consumer.list_template_requests('dcr_cleanroom');
Copy

Eine Referenzdokumentation für den Befehl consumer.list_template_requests finden Sie im Abschnitt „Verbraucherdefinierte Vorlagen“ unter Snowflake Data Clean Rooms: Verbraucher-API-Referenzhandbuch.

Liste aller Anfragen von Verbrauchern

Ein Anbieter führt den Befehl provider.list_template_requests aus, um alle Anfragen anzuzeigen, einschließlich der Anfragen, die genehmigt oder abgelehnt wurden.

Nehmen wir zum Beispiel an, der Name des Reinraums des Anbieters ist dcr_cleanroom. Um alle Anfragen aufzulisten, die unabhängig vom Ergebnis gestellt wurden, führt der Anbieter den folgenden Befehl aus:

CALL samooha_by_snowflake_local_db.provider.list_template_requests('dcr_cleanroom');
Copy

Eine Referenzdokumentation für den Befehl provider.list_template_requests finden Sie im Abschnitt „Verbraucherdefinierte Vorlagen“ unter Snowflake Data Clean Rooms: Anbieter-API-Referenzhandbuch.