Referência do manifesto Declarative Native App

Os provedores criam um arquivo de manifesto como parte de um pacote.

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.

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
Copy

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 (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.

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:
Copy

Campo 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.

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.

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.

Nota

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

  • 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
Copy

Para mais informações sobre as funções, consulte as funções de aplicativo.

Campo 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.

Campo shared_content.databases.{named database}

Cada banco de dados com nome oferece suporte aos seguintes pares de nome e valor:

  • schemas (lista, obrigatório): Uma lista de esquemas no banco de dados.

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.

Campo schemas.{named schema}

Cada esquema nomeado oferece suporte aos seguintes pares de nome e valor:

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

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

Importante

Você deve aplicar a separação de esquema entre objetos de dados (objetos compartilhados por referência: tables, views e semantic_views) e objetos lógicos (objetos compartilhados por cópia: functions e procedures). Você não pode misturar objetos lógicos e de dados no mesmo esquema.

Campo tables.{named table}

Cada tabela padrão nomeada, tabela dinâmica e tabela Apache Iceberg (lista, [OneOfRequired] obrigatório) oferece suporte ao seguinte par de nome e valor:

Nota

As tabelas dinâmicas compartilhadas e as tabelas Apache Iceberg replicadas para regiões remotas são somente leitura e não são atualizadas automaticamente. A atualização dos dados depende da frequência de replicação da fonte, e os objetos de origem subjacentes não precisam ser replicados. Para obter mais detalhes, consulte Considerações sobre a replicação.

Campo views.{named view}

Cada exibição com nome (lista, obrigatório [OneOfRequired] ): oferece suporte ao seguinte par de nome e valor:

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:

Exemplo de 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.

Dois bancos de dados necessários também são expostos: sales_projections e customer_analytics. Esses bancos de dados podem ser referenciados por exibições nos bancos de dados compartilhados, mas não são compartilhados diretamente.

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

Exemplo do arquivo de manifesto

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

Observe que os objetos de dados e de código devem estar em esquemas diferentes.

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