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 e lógica com consumidores, como notebooks, funções definidas pelo usuário, procedimentos armazenados, tabelas e exibições.

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 (lista, opcional): uma lista de funções de app 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:
Copy

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 dos apps forneçam à organização acesso a objetos compartilhados em um app, 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 notebook, schema, table, view ou semantic_view. Para objetos no nível table, view ou semantic_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
Copy

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

Campo shared_content

O campo shared_content (lista, obrigatório) define uma lista de bancos de dados compartilhados declarativamente pelo aplicativo. Cada banco de dados inclui uma lista de schemas com nomes. Cada esquema pode incluir uma lista de entidades nomeadas agrupadas por tipo.

Esse campo inclui um único campo databases e um campo opcional required_databases:

  • shared_content.databases (lista, obrigatório): Uma lista de instâncias de banco de dados com nomes e os objetos subjacentes a serem compartilhados. No exemplo abaixo, o manifesto adiciona um banco de dados chamado 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.

Campo shared_content.required_databases.{named database}

O bancos de dados_necessários O campo (lista, opcional) define uma lista de bancos de dados que são dependências dos bancos de dados compartilhados. Esses bancos de dados são referenciados por exibições nos bancos de dados compartilhados, mas não são compartilhados diretamente. Quando seu aplicativo compartilha dados de vários bancos de dados, você deve listar explicitamente todos os bancos de dados adicionais que são referenciados por objetos em seu conteúdo compartilhado no campo required_databases. Isso garante que o aplicativo seja implantado com sucesso em outras regiões onde esses bancos de dados podem não existir por padrão. A inclusão de um banco de dados no campo required_databases é semelhante a fazer referência a um banco de dados usando o privilégio REFERENCE_USAGE no Secure Data Sharing tradicional. Para obter informações sobre o privilégio REFERENCE_USAGE e como bancos de dados dependentes são compartilhados no compartilhamento de dados tradicional, consulte Compartilhar dados de vários bancos de dados.

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)

Pelo menos uma destas opções é necessária: tables, views, semantic_views, functions ou procedures.

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:

  • roles (lista, opcional): uma lista de funções de app que podem acessar a exibição, como [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 e incluídas no campo {named schema}.roles.

Campo semantic_views.{named semantic view}

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

  • roles (lista, opcional): uma lista de funções de app que podem acessar a exibição semântica, como [sales]. Observe que, ao compartilhar uma exibição semântica, suas tabelas ou exibições referenciadas também devem ser compartilhadas. Quando esse campo está vazio ([]) ou é omitido, somente proprietários e funções de apps com IMPORTED PRIVILEGES recebem acesso. As funções incluídas devem ser definidas no campo de funções de nível superior e incluídas no campo {named schema}.roles.

Campo functions.{named function}

Cada função nomeada (lista, [OneOfRequired] obrigatório): oferece suporte ao seguinte par nome-valor:

Campo procedures.{named procedure}

Cada procedimento armazenado nomeado (lista, [OneOfRequired] obrigatório): oferece suporte ao seguinte par nome-valor:

  • roles (lista, opcional): uma lista de funções de app que podem acessar o procedimento, como [analyst]. 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 e incluídas no campo {named schema}.roles.

Exemplo de shared_content

Neste exemplo, dois bancos de dados são expostos: sales e customer_info. Dentro desses bancos de dados, as tabelas orders.[january_2025|february_2025] são expostas, assim como a exibição customer_contact.customer_address.

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

O bloco de código a seguir é um exemplo de arquivo de manifesto do Declarative Native App.

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