Utilisation de l’API du développeur pour ajouter des modèles définis par le consommateur¶

Envoyer des requêtes à un fournisseur¶

Un consommateur exécute la commande consumer.create_template_request permettant d’envoyer une requête au fournisseur d’une salle blanche. Cette requête inclut le nom du modèle ainsi que le code Jinja qui définit le modèle.

Par exemple, supposons que le fournisseur partage une salle blanche dcr_cleanroom avec un consommateur. Le consommateur souhaite ajouter un modèle nommé my_overlap_analysis à la salle blanche. Pour envoyer une requête au fournisseur de la salle blanche, le consommateur exécute la commande suivante :

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 %};
  $$);

Le troisième argument est le code Jinja qui définit le modèle.

Pour la documentation de référence de la commande consumer.create_template_request, voir la section Modèles définis par le consommateur dans Snowflake Data Clean Rooms : guide de référence pour l’API de consommateur.

Vérifier les nouvelles requêtes des consommateurs¶

Pour vérifier les nouvelles requêtes des consommateurs, un fournisseur exécute la commande provider.list_template_requests, puis analyse les résultats pour identifier les requêtes avec un statut PENDING. Un statut PENDING indique que le consommateur a envoyé une nouvelle requête à laquelle le fournisseur n’a pas donné suite. La réponse à provider.list_template_requests inclut le code Jinja du modèle, qui permet au fournisseur de décider s’il souhaite approuver ou rejeter la requête.

Par exemple, supposons que le nom de la salle blanche du fournisseur soit dcr_cleanroom. Pour vérifier si le consommateur a envoyé une nouvelle requête d’ajout d’un modèle, le fournisseur exécute les commandes suivantes :

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

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

La réponse à la commande provider.list_template_requests inclut les éléments suivants pour chaque requête de modèle :

• UUID qui identifie de manière unique la requête.

• Compte consommateur qui a envoyé la requête, au format localisateur de compte.

• Nom du modèle, qui a été spécifié par le consommateur lors de l’envoi de la requête.

• Code Jinja qui définit le modèle.

• Statut de la requête, qui peut être PENDING, APPROVED ou REJECTED.

Pour la documentation de référence de la commande provider.list_template_requests, voir la section Modèles définis par le consommateur dans Snowflake Data Clean Rooms : guide de référence pour l’API fournisseurs.

Approuver ou rejeter une requête¶

Après avoir reçu une requête d’ajout d’un modèle défini par le consommateur, le fournisseur décide d’approuver ou de rejeter la requête.

Approuver une requête

Les fournisseurs exécutent la commande provider.approve_template_request pour approuver une requête d’ajout d’un modèle. Le fournisseur spécifie le modèle à approuver en passant l’identificateur de la requête comme argument.

Par exemple, supposons que le nom de la salle blanche du fournisseur soit dcr_cleanroom et que la requête du consommateur d’ajouter un modèle s’est vu attribuer l’identificateur 01b4d41d-0001-b572. Pour approuver la requête et ajouter le modèle à la salle blanche, le fournisseur exécute la commande suivante :

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

Rejeter une requête

Les fournisseurs exécutent la commande provider.reject_template_request pour rejeter une requête d’ajout d’un modèle. Le fournisseur spécifie quel modèle rejeter en passant l’identificateur de la requête comme argument.

Par exemple, supposons que le nom de la salle blanche du fournisseur soit dcr_cleanroom et que la requête du consommateur d’ajouter un modèle s’est vu attribuer l’identificateur 01b4d41d-0001-b572. Après avoir examiné le modèle Jinja, le fournisseur détermine qu’il introduit un risque de sécurité dans la salle blanche, il souhaite donc rejeter la requête avec une raison descriptive. Pour rejeter la requête d’ajout du modèle, le fournisseur exécute la commande suivante :

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

Pour la documentation de référence des commandes provider.approve_template_request et provider.reject_template_request, voir la section Modèles définis par le consommateur dans Snowflake Data Clean Rooms : guide de référence pour l’API fournisseurs.

Vérifier le statut de la requête en tant que consommateur¶

À tout moment, le consommateur peut exécuter la commande consumer.list_template_requests pour vérifier le statut de leur requête d’ajout d’un modèle. La commande renvoie les information suivantes :

• UUID qui identifie de manière unique la requête.

• Compte fournisseur auquel la requête a été envoyée, au format de localisateur de compte.

• Nom du modèle, qui a été spécifié par le consommateur lors de l’envoi de la requête.

• Code Jinja qui définit le modèle.

• Statut de la requête, qui peut être PENDING, APPROVED ou REJECTED.

• Si la requête a été rejetée, la raison de l’action du fournisseur.

Par exemple, supposons que le consommateur ait envoyé une requête pour ajouter un modèle à la salle blanche dcr_cleanroom. Pour vérifier le statut de la requête afin de déterminer si elle a été approuvée, le consommateur exécute la commande suivante :

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

Pour la documentation de référence de la commande consumer.list_template_requests, voir la section Modèles définis par le consommateur dans Snowflake Data Clean Rooms : guide de référence pour l’API de consommateur.