Referência do manifesto Declarative Native App¶
Os provedores criam um arquivo de manifesto como parte de um pacote.
O arquivo do manifesto é um arquivo YAML baseado em texto, com o nome: manifest.yml. Ele é usado para compartilhar declarativamente dados (como notebooks, tabelas e exibições) com consumidores.
O arquivo de manifesto também define funções de aplicativo, que os proprietários de aplicativos podem usar para compartilhar um subconjunto de dados e recursos com as equipes da organização por função.
Para saber como desenvolver um pacote de aplicativo, consulte Pacotes de aplicativo no compartilhamento declarativo do Native Application Framework.
Manifesto Declarative Native App¶
O formato geral de um manifesto Declarative Native App contém:
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
Campos¶
Manifestos Declarative Native App incluem os seguintes campos:
Campo manifest_version¶
Este campo é adicionado automaticamente ao arquivo de manifesto quando você lança uma nova versão de um pacote de aplicativo.
Não inclua este campo ao criar um arquivo de manifesto a ser incluído em um pacote de aplicativo. Não há suporte para a edição manual desse campo.
O campo de nível superior manifest_version (inteiro, obrigatório) especifica o número da versão do arquivo de manifesto.
Para mais informações sobre controle de versão, consulte Versões de pacote no compartilhamento declarativo do Native Application Framework.
Campo application_content¶
O campo application_content (lista, opcional) define o conteúdo agrupado declarativamente compartilhado pelo aplicativo.
Este campo inclui um único campo notebooks:
application_content.notebooks(lista, obrigatório): Uma lista de notebooks com nomes.
Campo application_content.notebooks.{named notebook}¶
Cada notebook nomeado oferece suporte aos seguintes pares de nome e valor:
main_file(cadeia de caracteres, obrigatório) o nome do arquivo interativo do notebook Python (.ipynb).comment(cadeia de caracteres, opcional): Um comentário que descreve o notebook.runtime_environment_version(cadeia de caracteres, opcional): Especifica uma determinada versão do ambiente de execução para o contexto de execução do notebook , se aplicável na plataforma.roles(lista, opcional): Uma lista de funções de aplicativo que podem conceder acesso ao notebook, como[sales,marketing]. Quando este campo está vazio ([]) ou omitido, somente proprietários e funções de aplicativos com IMPORTED PRIVILEGES concedidos recebem acesso. As funções incluídas devem ser definidas no campo de funções de nível superior.
Exemplo de application_context¶
Neste exemplo, um único notebook, salesbook, é definido usando o arquivo de notebook NOTEBOOK1.ipynb, que usa o tempo de execução conhecido estable e fornece acesso a quem recebeu as funções sales 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:
Campo roles¶
O campo de nível superior roles (lista, opcional) define uma lista de funções de aplicativo. Essas funções permitem que os proprietários forneçam à organização acesso a objetos compartilhados em um aplicativo, como esquemas, tabelas, exibições e notebooks.
Cada função nomeada pode, opcionalmente, conter um comment, que aparece como uma descrição quando o proprietário do aplicativo lista as funções.
Essas funções são referenciadas no manifesto por objetos compartilhados, no nível nomeado de notebook, schema, table ou view. Para objetos no nível table ou view, as funções também devem ser especificadas no nível schema.
Nota
Todo o conteúdo do manifesto pode ser acessado pelo proprietário do aplicativo, pelo ACCOUNTADMIN e por quem recebeu as funções IMPORTED PRIVILEGES para o aplicativo.
O nome do objeto definido no arquivo de manifesto é usado para a resolução do objeto no tempo de execução. Se o provedor alterar o nome do objeto sem atualizar o arquivo de manifesto com uma nova versão, os consumidores perderão o acesso ao objeto.
Exemplo de 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
Para mais informações sobre as funções, consulte as funções de aplicativo.
Exemplo do arquivo de manifesto¶
O bloco de código a seguir é um exemplo de arquivo de manifesto 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