Référence du manifeste d’une Declarative Native App

Les fournisseurs créent un fichier manifeste dans le cadre d’un paquet.

Le fichier manifeste est un fichier basé sur un fichier YAML basé sur du texte, avec le nom de fichier : manifest.yml. Il est utilisé pour partager de manière déclarative des données et une logique avec les consommateurs, comme des notebooks, des fonctions définies par l’utilisateur, des procédures stockées, des tables et des vues.

Le fichier manifeste définit également les rôles d’application, que les propriétaires d’applications peuvent utiliser pour partager un sous-ensemble des données et fonctionnalités de l’application avec des équipes dans leurs équipes d’organisation par rôle.

Pour plus d’informations sur le développement d’un paquet d’application, consultez Paquets d’application dans le partage déclaratif du framework des applications natives.

Manifeste de la Declarative Native App

Le format général d’un manifeste de Declarative Native App contient :

manifest_version: # Added automatically. Don't include.
application_content: # Optional, describes associated app logic
roles: # Optional, describes roles associated with shared_content
shared_content: # Required, describes associated data to be shared
Copy

Champs

Les manifestes Declarative Native App comprennent les champs suivants :

champ manifest_version

Ce champ est ajouté automatiquement au fichier manifeste lorsque vous publiez une nouvelle version d’un paquet d’application.

N’incluez pas ce champ lorsque vous créez un fichier manifeste à inclure dans un paquet d’application. La modification manuelle de ce champ n’est pas prise en charge.

Le champ de niveau supérieur manifest_version (entier, obligatoire) spécifie le numéro de version du fichier manifeste.

Pour plus d’informations sur la gestion des versions, consultez Versions de paquets dans le partage déclaratif du framework des applications natives.

champ application_content

Le champ application_content (liste, facultatif) définit le contenu groupé partagé de façon déclarative par l’application.

Ce champ comprend un seul champ notebooks :

  • application_content.notebooks (Liste, obligatoire) : Une liste de notebooks nommés.

champ application_content.notebooks.{named notebook}

Chaque notebook nommé prend en charge les paires nom/valeur suivantes :

  • main_file (chaîne, obligatoire) le nom du fichier notebook interactif Python (.ipynb).

  • comment (chaîne, facultatif) : Un commentaire décrivant le notebook.

  • runtime_environment_version (chaîne, facultatif) : Spécifie une version de l’environnement d’exécution spécifique pour le contexte d’exécution du notebook , le cas échéant dans la plateforme.

  • roles (liste, facultatif) : Une liste des rôles de l’application qui peuvent accorder l’accès au notebook, par exemple, [sales,marketing]. Lorsque ce champ est vide ([]) ou omis, alors uniquement les propriétaires d’application et les rôles avec des IMPORTED PRIVILEGES autorisés reçoivent l’accès. Les rôles inclus doivent être définis dans le champ des rôles de niveau supérieur.

Exemple application_context

Dans cet exemple, un seul notebook, salesbook, est défini à l’aide du fichier notebook NOTEBOOK1.ipynb qui utilise le runtime connu stable et donne accès aux rôles ventes ou marketing.

application_content:
    notebooks:
        - salesbook:
              roles: [sales, marketing]
              main_file: NOTEBOOK1.ipynb
              comment: Notebook1: Sales and marketing notebook
              runtime_environment_version: stable

roles:
  - sales:
  - marketing:
Copy

champ roles

Le champ de niveau supérieur roles (liste, facultatif) définit une liste de rôles d’application. Ces rôles permettent aux propriétaires d’applications de fournir à leur organisation l’accès à des objets partagés dans une application, tels que des schémas, des tables, des vues et des notebooks.

Chaque rôle nommé peut éventuellement contenir un comment, qui apparaît sous forme de description lorsque le propriétaire de l’application répertorie les rôles dans l’application.

Ces rôles sont référencés dans le manifeste par des objets partagés, au niveau``notebook``, schema, table, view, ou semantic_view. Pour les objets au niveau table, view, ou semantic_view, les rôles doivent également être spécifiés au niveau schema.

Note

  • L’ensemble du contenu du manifeste est accessible au propriétaire de l’application, c’est-à-dire ACCOUNTADMIN, et aux rôles qui se voient attribuer les IMPORTED PRIVILEGES sur l’application.

  • Le nom d’objet défini dans ce fichier manifeste est utilisé pour la résolution d’objet d’exécution. Si le fournisseur modifie le nom de l’objet sans mettre à jour le fichier manifeste avec une nouvelle version, les consommateurs perdront l’accès à l’objet.

Exemple roles

roles:
  - sales:
  - marketing:

application_content:
  notebooks:
    - salesbook:
        roles: [sales, marketing]
        main_file: NOTEBOOK1.ipynb
        comment: Sales and marketing notebook

shared_content:
  databases:
    - sales:
        schemas:
          - orders:
              roles: [sales, marketing]
              tables:
                - january_2025:        # App owners/assignees only
                - february_2025:
                    roles: [sales]     # Accessible to sales only
                - march_2025:
                    roles: [marketing] # Accessible to marketing only
    - customer_info:
        schemas:
          - customer_contact:
              roles: [customer_support]
              views:
                - customer_address:
                    roles: [customer_support] # Accessible to customer_support
                - customer_details:
                    roles: []                 # App owners/assignees only
Copy

Pour plus d’informations sur les rôles, consultez les rôles d’application.

champ shared_content

Le champ shared_content (liste, obligatoire) définit une liste de bases de données partagées de manière déclarative par l’application. Chaque base de données comprend une liste de schemas nommés. Chaque schéma peut inclure une liste d’entités nommées regroupées par type.

Ce champ comprend un seul champ databases et un champ required_databases facultatif :

  • shared_content.databases (Liste, obligatoire) : Une liste des instances de base de données nommées et des objets sous-jacents à partager. Dans l’exemple ci-dessous, le manifeste ajoute une base de données nommée Ventes.

champ shared_content.databases.{named database}

Chaque base de données nommée prend en charge les paires nom/valeur suivantes :

  • schemas (liste, obligatoire) : Une liste des schémas de la base de données.

champ shared_content.required_databases.{named database}

Le champ required_databases (liste, facultatif) définit une liste de bases de données qui sont des dépendances des bases de données partagées. Ces bases de données sont référencées par des vues dans les bases de données partagées, mais ne sont pas partagées directement. Lorsque votre application partage des données provenant de plusieurs bases de données, vous devez explicitement lister toutes les bases de données supplémentaires qui sont référencées par des objets dans votre contenu partagé dans le champ bases_données_requises. Cela garantit que l’application peut être déployée avec succès dans d’autres régions où ces bases de données peuvent ne pas exister par défaut. Inclure une base de données dans le champ bases_de_donnees_requises est similaire au référencement d’une base de données à l’aide du privilège REFERENCE_USAGE dans Secure Data Sharing traditionnel. Pour plus d’informations sur le privilège REFERENCE_USAGE et la façon dont les bases de données dépendantes sont partagées dans le partage de données traditionnel, voir Partager des données de plusieurs bases de données.

champ schemas.{named schema}

Chaque schéma nommé prend en charge les paires nom/valeur suivantes :

  • tables (liste, [OneOfRequired]): Une liste de tables nommées, qui peut inclure des tables dynamiques et des tables Apache Iceberg.

  • views (liste, [OneOfRequired]): Une liste de vues nommées.

  • semantic_views (liste, [OneOfRequired]): Une liste de vues sémantiques nommées.

  • functions (liste, [OneOfRequired]): Une liste de fonctions nommées définies par l’utilisateur (UDFs).

  • procedures (liste, [OneOfRequired]): Une liste de procédures stockées nommées.

  • roles (liste, facultatif) : Une liste des rôles d’application que les objets du schéma peuvent utiliser, par exemple, [sales,marketing]. Lorsque ce champ est vide ([]) ou omis, alors uniquement les propriétaires d’application et les rôles avec des IMPORTED PRIVILEGES autorisés reçoivent l’accès. Les rôles inclus doivent être définis dans le champ des rôles de niveau supérieur.

[OneOfRequired] (1,2,3,4,5,6,7,8,9,10)

Au moins une des tables, views, semantic_views, functions, ou procedures est obligatoire.

Important

Vous devez forcer la séparation des schémas entre les objets de données (objets partagés par référence : tables, views, et semantic_views) et des objets logiques (objets partagés par copie : functions et procedures). Vous ne pouvez pas mélanger des données et des objets logiques dans le même schéma.

champ tables.{named table}

Chaque table standard nommée, table dynamique, et Table Apache Iceberg (Liste, obligatoire [OneOfRequired] ) prend en charge la paire nom/valeur suivante :

  • roles (liste, facultatif) : Une liste des rôles d’application qui peuvent accéder à la table, par exemple, [sales]. Lorsque ce champ est vide ([]) ou omis, alors uniquement les propriétaires d’application et les rôles avec des IMPORTED PRIVILEGES autorisés reçoivent l’accès. Les rôles inclus doivent être définis dans le champ des rôles de niveau supérieur et inclus dans le champ {schéma nommé}.roles.

Note

Les tables dynamiques et Tables Apache Iceberg partagées répliquées dans les régions distantes sont en lecture seule et ne s’actualisent pas automatiquement. Le niveau d’actualisation des données dépend de la fréquence de réplication à partir de la source, et les objets de la source sous-jacente n’ont pas besoin d’être répliqués. Pour plus de détails, voir Remarques relatives à la réplication.

champ views.{named view}

Chaque vue nommée (liste, obligatoire [OneOfRequired] ) : prend en charge la paire nom/valeur suivante :

  • roles (liste, facultatif) : Une liste des rôles d’application qui peuvent accéder à la vue, par exemple, [marketing]. Lorsque ce champ est vide ([]) ou omis, alors uniquement les propriétaires d’application et les rôles avec des IMPORTED PRIVILEGES autorisés reçoivent l’accès. Les rôles inclus doivent être définis dans le champ des rôles de niveau supérieur et inclus dans le champ {schéma nommé}.roles.

champ semantic_views.{named semantic view}

Chaque vue sémantique nommée (liste, obligatoire [OneOfRequired] ) : prend en charge la paire nom/valeur suivante :

  • roles (liste, facultatif) : Une liste des rôles d’application qui peuvent accéder à la vue sémantique, par exemple, [sales]. Notez que, lors du partage d’une vue sémantique, ses tables ou vues référencées doivent également être partagées. Lorsque ce champ est vide ([]) ou omis, alors seuls les propriétaires d’application et les rôles avec les :ref:` IMPORTED PRIVILEGES <label-dsna_share_access_to_all_data>` reçoivent l’accès. Les rôles inclus doivent être définis dans le champ des rôles de premier niveau et inclus dans le champ {named schema}.roles.

champ functions.{named function}

Chaque fonction nommée (liste, obligatoire [OneOfRequired] ): prend en charge la paire nom/valeur suivante :

  • roles (liste, facultatif) : Une liste des rôles d’application qui peuvent accéder à la fonction, par exemple, [analyst]. Lorsque ce champ est vide ([]) ou omis, alors uniquement les propriétaires d’application et les rôles avec des IMPORTED PRIVILEGES autorisés reçoivent l’accès. Les rôles inclus doivent être définis dans le champ des rôles de niveau supérieur et inclus dans le champ {schéma nommé}.roles.

champ procedures.{named procedure}

Chaque procédure stockée nommée (liste, obligatoire [OneOfRequired] ): prend en charge la paire nom/valeur suivante :

  • roles (liste, facultatif) : Une liste des rôles d’application qui peuvent accéder à la procédure, par exemple, [analyst]. Lorsque ce champ est vide ([]) ou omis, alors uniquement les propriétaires d’application et les rôles avec des IMPORTED PRIVILEGES autorisés reçoivent l’accès. Les rôles inclus doivent être définis dans le champ des rôles de niveau supérieur et inclus dans le champ {schéma nommé}.roles.

Exemple shared_content

Dans cet exemple, deux bases de données sont exposées : ventes et info_client. Dans ces bases de données, les tables orders.[january_2025|february_2025] sont exposées ainsi que la vue customer_contact.customer_address.

Deux bases de données requises sont également exposées : sales_projections et customer_analytics. Ces bases de données peuvent être référencées par des vues dans les bases de données partagées, mais elles ne sont pas partagées directement.

roles:
  - sales:
  - marketing:

shared_content:
  required_databases:
    sales_projections
    customer_analytics
  databases:
    - sales:
        schemas:
          - orders:
              roles: [sales, marketing]
              tables:
                - january_2025:        # App owners/assignees only
                - february_2025:
                    roles: [sales]     # Accessible to sales only
                - march_2025:
                    roles: [marketing] # Accessible to marketing only
    - customer_info:
        schemas:
          - customer_contact:
              roles: [customer_support]
              views:
                - customer_address:
                    roles: [customer_support] # Accessible to customer_support
                - customer_details:
                    roles: []                 # App owners/assignees only
Copy

Exemple de fichier manifeste

Le bloc de code suivant constitue un exemple de fichier manifeste d’Declarative Native App :

Notez que les données et les objets de code doivent se trouver dans des schémas différents.

manifest_version: 2

roles:
  - VIEWER:
      comment: "The VIEWER role provides access to only one view."
  - ANALYST:
      comment: "The ANALYST role provides access to views, the table, and logic."

shared_content:
  databases:
    - SNAF_POPULATION_DB:
        schemas:
          - DATA_SCHEMA:
              roles: [VIEWER, ANALYST]
              tables:
                - COUNTRY_POP_BY_YEAR:
                    roles: [ANALYST]
                - POPULATION_DYNAMIC_TABLE:
                    roles: [ANALYST]
                - MANAGED_POPULATION_ICEBERG_TABLE:
                    roles: [ANALYST]
              views:
                - COUNTRY_POP_BY_YEAR_2000:
                    roles: [VIEWER, ANALYST]
          - LOGIC_SCHEMA:
              roles: [ANALYST]
              functions:
                - POPULATION_ANALYSIS_FUNCTION(NUMBER):
                    roles: [ANALYST]
              procedures:
                - POPULATION_ANALYSIS_PROCEDURE():
                    roles: [ANALYST]
application_content:
  notebooks:
      - intro_notebook:
          roles: [VIEWER, ANALYST]
          main_file: INTRO_NB.ipynb
      - analyst_notebook:
          roles: [ANALYST]
          main_file: ANALYST_NB.ipynb
Copy