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 avec des consommateurs, telles que des notebooks, 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 (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

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.

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 or 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

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 de tables nommées et une liste de views.

Ce champ comprend un seul champ notebooks :

  • 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

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. Inclure une base de données dans required_databases est similaire au référencement d’une base de données à l’aide du privilège REFERENCE_USAGE dans le partage de données sécurisé 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.

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

  • semantic_views (list, [OneOfRequired]): A list of named semantic views.

  • roles (list, optional): A list of app roles that the objects in the schema can use; 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.

[OneOfRequired] (1,2,3,4,5)

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

champ tables.{named table}

Chaque table nommée (liste, obligatoire) prend en charge la paire nom/valeur suivante :

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.

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

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

manifest_version: 2

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

shared_content:
  databases:
    - SNAF_POPULATION_DB:
        schemas:
          - DATA_SCHEMA:
              roles: [VIEWER, ANALYST]
              tables:
                - COUNTRY_POP_BY_YEAR:
                    roles: [ANALYST]
              views:
                - COUNTRY_POP_BY_YEAR_2000:
                    roles: [VIEWER, ANALYST]

application_content:
  notebooks:
      - intro_notebook:
          roles: [VIEWER, ANALYST]
          main_file: INTRO_NB.ipynb
      - analyst_notebook:
          roles: [ANALYST]
          main_file: ANALYST_NB.ipynb
Copy
Langage: Français