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

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

The manifest file is a text-based YAML file, with the filename: manifest.yml. It’s used to declaratively share data and logic with consumers, such as notebooks, user-defined functions, stored procedures, tables, and views.

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 (list, optional): A list of app roles that can grant access to the notebook, for example, [sales,marketing]. When this field is empty ([]) or omitted, then only app owners and roles with granted IMPORTED PRIVILEGES receive access. The included roles must be defined in the top-level roles field.

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

The roles top level field (list, optional) defines a list of app roles. These roles allow app owners to provide access to shared objects in an app — such as schemas, tables, views, and notebooks — to their organization.

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.

These roles are referenced in the manifest by shared objects, at the named notebook, schema, table, view, or semantic_view level. For objects at the table, view, or semantic_view level, roles must also be specified at the schema level.

Note

  • All content in the manifest is accessible to the app owner, the ACCOUNTADMIN, and to roles that are granted IMPORTED PRIVILEGES to the app.

  • 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

The shared_content field (list, required) defines a list of databases declaratively shared by the app. Each database includes a list of named schemas. Each schema can include a list of named entities grouped by type.

This field includes a single databases field and an optional required_databases field:

  • shared_content.databases (List, required): A list of named database instances and the underlying objects to share. In the example below, the manifest adds a database named sales.

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.

shared_content.required_databases.{named database} field

The required_databases field (list, optional) defines a list of databases that are dependencies of the shared databases. These databases are referenced by views in the shared databases, but are not shared directly. When your application shares data from multiple databases, you must explicitly list all additional databases that are referenced by objects in your shared content under the required_databases field. This ensures that the application can be deployed successfully in other regions where these databases may not exist by default. Including a database in the required_databases field is similar to referencing a database using the REFERENCE_USAGE privilege in traditional Secure Data Sharing. For information about the REFERENCE_USAGE privilege and how dependent databases are shared in traditional data sharing, see Share data from multiple databases.

champ schemas.{named schema}

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

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

at least one of tables, views, semantic_views, functions, or procedures is required.

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 :

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 :

semantic_views.{named semantic view} field

Each named semantic view (List, required [OneOfRequired] ): supports the following name value pair:

  • roles (list, optional): A list of app roles that can access the semantic view; for example, [sales]. Note that, when sharing a semantic view, its referenced tables or views must be shared as well. When this field is empty ([]) or omitted, then only app owners and roles with granted IMPORTED PRIVILEGES receive access. The included roles must be defined in the top-level roles field and included in the {named schema}.roles field.

functions.{named function} field

Each named function (List, required [OneOfRequired] ): supports the following name value pair:

procedures.{named procedure} field

Each named stored procedure (List, required [OneOfRequired] ): supports the following name value pair:

Exemple shared_content

In this example, two databases are exposed: sales and customer_info. Within these databases the orders.[january_2025|february_2025] tables are exposed as well as the customer_contact.customer_address view.

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

The following code block is an example of a Declarative Native App manifest file.

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