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
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:
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, ou view nommé. Pour les objets au niveau table ou 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
Pour plus d’informations sur les rôles, consultez les rôles d’application.
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