Referenz zum Declarative Native App-Manifest

Anbieter erstellen eine Manifest-Datei als Teil eines Pakets.

Die Manifest-Datei ist eine textbasierte YAML-Datei mit dem Dateinamen: manifest.yml. Es wird verwendet, um Daten und Logik deklarativ für Verbraucher freizugeben, wie z. B. Notebooks, benutzerdefinierte Funktionen, gespeicherte Prozeduren, Tabellen und Ansichten.

Die Manifest-Datei definiert auch App-Rollen, die App-Eigentümer verwenden können, um eine Teilmenge der Daten und Features der App an Teams in ihren Organisationsteams nach Rollen freizugeben.

Informationen zur Entwicklung eines Anwendungspakets finden Sie unter Anwendungspakete bei deklarativer Freigabe im Native Application Framework.

Declarative Native App-Manifest

Das allgemeine Format eines Declarative Native App-Manifests enthält Folgendes:

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

Felder

Declarative Native App-Manifeste enthalten die folgenden Felder:

Feld manifest_version

Dieses Feld wird automatisch zur Manifest-Datei hinzugefügt, wenn Sie eine neue Version eines Anwendungspakets freigeben.

Fügen Sie dieses Feld nicht ein, wenn Sie eine Manifest-Datei erstellen, die Sie in ein Anwendungspaket aufnehmen möchten. Das manuelle Bearbeiten dieses Feldes wird nicht unterstützt.

Das manifest_version-Feld der obersten Ebene (Ganzzahl, erforderlich) gibt die Versionsnummer der Manifest-Datei an.

Weitere Informationen zur Versionierung finden Sie unter Paketversionen in der deklarativer Freigabe im Native Application Framework.

Feld application_content

Das application_content-Feld (Liste, optional) definiert gebündelte Inhalte, die deklarativ von der App freigegeben werden.

Dieses Feld enthält ein einzelnes notebooks-Feld:

  • application_content.notebooks (Liste, erforderlich): Eine Liste von benannten Notizbüchern.

Feld application_content.notebooks.{named notebook}

Jedes benannte Notizbuch unterstützt die folgenden Name/Wert-Paare:

  • main_file (Zeichenfolge, erforderlich), der Pfad zur Datei des interaktiven Python-Notebooks (.ipynb), relativ zum Stammverzeichnis der Paketversion.

  • comment (Zeichenfolge, optional): Ein Kommentar, der das Notizbuch beschreibt.

  • runtime_environment_version (Zeichenfolge, optional): Gibt eine bestimmte Version der Laufzeitumgebung für den Ausführungskontext des Notizbuchs an, falls innerhalb der Plattform anwendbar.

  • roles (Liste, optional): Eine Liste von App-Rollen, die Zugriff auf das Notebook gewähren können, zum Beispiel [sales,marketing]. Wenn dieses Feld leer ist ([]) oder weggelassen wird, dann erhalten nur App-Eigentümer und Rollen mit erteilten IMPORTED PRIVILEGES Zugriff. Die enthaltenen Rollen müssen im -Feld für Rollen der obersten Ebene definiert sein.

Bemerkung

Der main_file-Pfad ist immer relativ zum Stamm der Paketversion (das snow://package/<DECL_SHARE_APP_PKG>/versions/<version>-Präfix). Wenn der vollständige Pfad zur Notebook-Datei beispielsweise snow://package/<DECL_SHARE_APP_PKG>/versions/LIVE/NOTEBOOK.ipynb lautet, geben Sie main_file nur als NOTEBOOK.ipynb an.

application_context-Beispiel

In diesem Beispiel wird ein einzelnes Notizbuch, Verkaufsbuch, mithilfe der Notizbuchdatei NOTEBOOK1.ipynb definiert, die die bekannte Laufzeitumgebung stabil verwendet und den Zugriff denjenigen erlaubt, denen entweder die Rolle Verkauf oder Marketing zugewiesen wurde.

application_content:
    notebooks:
        - salesbook:
              roles: [sales, marketing]
              main_file: NOTEBOOK1.ipynb
              comment: Notebook1: Sales and marketing notebook
              runtime_environment_version: stable

roles:
  - sales:
  - marketing:

Feld roles

Das roles-Feld der obersten Ebene (Liste, optional) definiert eine Liste von App-Rollen. Diese Rollen ermöglichen es App-Eigentümern, ihrer Organisation Zugriff auf freigegebene Objekte in einer App zu gewähren, wie z. B. Schemas, Tabellen, Ansichten und Notebooks.

Jede benannte Rolle kann optional einen comment enthalten, der als Beschreibung angezeigt wird, wenn der Besitzende der App die Rollen in der Anwendung auflistet.

Diese Rollen werden im Manifest durch freigegebene Objekte auf der benannten Ebene notebook, schema, table, view oder semantic_view referenziert. Für Objekte auf der Ebene table, view oder semantic_view müssen Rollen auch auf der Ebene schema angegeben werden.

Bemerkung

  • Alle Inhalte im Manifest sind für den Besitzenden der App, den ACCOUNTADMINund die Rollen zugänglich, denen IMPORTED PRIVILEGES in der App zugewiesen wurden.

  • Der in dieser Manifest-Datei definierte Objektname wird für die Auflösung des Laufzeitobjekts verwendet. Wenn der Anbietende den Objektnamen ändert, ohne die Manifest-Datei mit einer neuen Version zu aktualisieren, verlieren die Verbrauchenden den Zugriff auf das Objekt.

roles-Beispiel

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

Weitere Informationen zu Rollen finden Sie unter App-Rollen

Feld shared_content

Das shared_content-Feld (Liste, erforderlich) definiert eine Liste von Datenbanken, die deklarativ von der App freigegeben werden. Jede Datenbank enthält eine Liste von benannten schemas. Jedes Schema kann eine Liste von benannten Entitäten enthalten, die nach Typ gruppiert sind.

Dieses Feld enthält ein einzelnes databases-Feld und ein optionales required_databases-Feld:

  • shared_content.databases (Liste, erforderlich): Eine Liste der benannten Datenbankinstanzen und der zugrunde liegenden Objekte, die freigegeben werden sollen. Im folgenden Beispiel fügt das Manifest eine Datenbank mit dem Namen -sales hinzu.

Feld shared_content.databases.{named database}

Jede benannte Datenbank unterstützt die folgenden Name/Wert-Paare:

  • schemas (Liste, erforderlich): Eine Liste der Schemas innerhalb der Datenbank.

Feld shared_content.required_databases.{named database}

Das required_databases-Feld (Liste, optional) definiert eine Liste von Datenbanken, die von den freigegebenen Datenbanken abhängig sind. Diese Datenbanken werden über Ansichten in den freigegebenen Datenbanken referenziert, werden aber nicht direkt freigegeben. Weitere Informationen zum Verwalten von datenbankübergreifenden Abhängigkeiten finden Sie unter Abhängigkeitsdatenbanken: Verwalten von datenbankübergreifenden Referenzen.

Wenn Ihre Anwendung Daten aus mehreren Datenbanken freigibt, müssen Sie alle zusätzlichen Datenbanken, die von Objekten in Ihrem freigegebenen Inhalt referenziert werden, im Feld required_databases explizit aufführen. Dadurch wird sichergestellt, dass die Anwendung erfolgreich in anderen Regionen bereitgestellt werden kann, in denen diese Datenbanken standardmäßig nicht vorhanden sind.

Das Einfügen einer Datenbank in das Feld required_databases ist vergleichbar mit dem Verweisen auf eine Datenbank mithilfe der REFERENCE_USAGE-Berechtigung bei der herkömmlichen sicheren Datenfreigabe (Secure Data Sharing). Weitere Informationen zur REFERENCE_USAGE-Berechtigung und wie abhängige Datenbanken beim herkömmlichen Data Sharing freigegeben werden, finden Sie unter Freigeben von Daten aus mehreren Datenbanken.

Feld schemas.{named schema}

Jedes benannte Schema unterstützt die folgenden Name/Wert-Paare:

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

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

Wichtig

You must enforce schema separation between data objects (objects shared by reference: tables, views, and semantic_views) and logic objects (objects shared by copy: functions, procedures, and :cortex_agents). You can’t mix data and logic objects in the same schema.

Feld tables.{named table}

Jede benannte Standardtabelle (dynamische Tabelle (Liste, erforderlich [OneOfRequired] )) unterstützt das folgende Name-Wert-Paar:

Bemerkung

Freigegebene dynamische Tabellen und Apache Iceberg-Tabellen, die in Remoteregionen repliziert werden, sind schreibgeschützt und werden nicht automatisch aktualisiert. Die Aktualität der Daten hängt von der Replikationshäufigkeit der Quelle ab, und die zugrunde liegenden Quellobjekte müssen nicht repliziert werden. Weitere Details dazu finden Sie unter Hinweise zur Replikation.

Bemerkung

Um Verbrauchern die Möglichkeit zu geben, Streams auf diesem freigegebenen Objekt zu erstellen (zur Erfassung von Änderungsdaten oder zum inkrementellen Laden), müssen Sie CHANGE_TRACKING = TRUE für die Quelltabelle in Ihrem Anbieterkonto mit Standard-SQL-Befehlen aktivieren (z. B. ALTER TABLE ... SET CHANGE_TRACKING = TRUE). Diese Einstellung kann vom Verbraucher für das freigegebene Objekt nicht geändert werden. Sie muss in der Quelle festgelegt werden.

Feld views.{named view}

Jede benannte Ansicht (Liste, erforderlich [OneOfRequired] ): unterstützt das folgende Name/Wert-Paar:

Bemerkung

Um Verbrauchern die Möglichkeit zu geben, Streams auf diesem freigegebenen Objekt zu erstellen (zur Erfassung von Änderungsdaten oder zum inkrementellen Laden), müssen Sie CHANGE_TRACKING = TRUE für die Quelltabelle in Ihrem Anbieterkonto mit Standard-SQL-Befehlen aktivieren (z. B. ALTER TABLE ... SET CHANGE_TRACKING = TRUE). Diese Einstellung kann vom Verbraucher für das freigegebene Objekt nicht geändert werden. Sie muss in der Quelle festgelegt werden.

Feld semantic_views.{named semantic view}

Jede benannte semantische Ansicht (Liste, erforderlich [OneOfRequired] ): unterstützt das folgende Name-Wert-Paar:

  • roles (Liste, optional): Eine Liste von App-Rollen, die auf die semantische Ansicht zugreifen können, z. B. [sales]. Beachten Sie, dass bei der Freigabe einer semantischen Ansicht die referenzierten Tabellen oder Ansichten ebenfalls freigegeben werden müssen. Wenn dieses Feld leer ist ([]) oder weggelassen wird, dann erhalten nur App-Eigentümer und Rollen mit erteilten IMPORTED PRIVILEGES Zugriff. Die enthaltenen Rollen müssen im -Feld für Rollen der obersten Ebene definiert sein und im Feld {benanntes Schema}.roles enthalten sein.

Feld functions.{named function}

Jede benannte Funktion (Liste, erforderlich [OneOfRequired] ): unterstützt das folgende Name/Wert-Paar:

Feld procedures.{named procedure}

Jede benannte gespeicherte Prozedur (Liste, erforderlich [OneOfRequired] ): unterstützt das folgende Name/Wert-Paar:

cortex_agents.{named cortex agent} field

Each named Cortex Agent (List, required [OneOfRequired] ): supports the following name value pair:

shared_content-Beispiel

In diesem Beispiel werden zwei Datenbanken bereitgestellt: sales und customer_info. Innerhalb dieser Datenbanken sind die Tabellen orders.[january_2025|february_2025] sowie die Ansicht customer_contact.customer_address verfügbar.

Zwei erforderliche Datenbanken sind ebenfalls verfügbar: sales_projections und customer_analytics. Diese Datenbanken können über Ansichten in den freigegebenen Datenbanken referenziert werden, werden aber nicht direkt freigegeben.

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

Beispiel einer Manifest-Datei

Der folgende Codeblock ist ein Beispiel für eine Declarative Native App-Manifest-Datei:

Beachten Sie, dass sich Daten- und Codeobjekte in unterschiedlichen Schemas befinden müssen.

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."
  - APP_USER:
      comment: "The APP_USER role provides access to the Cortex Agent and the underlying data."

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]
          - AGENT_SCHEMA:
              roles: [APP_USER]
              cortex_agents:
                - PRODUCT_AGENT:
                    roles: [APP_USER]
application_content:
  notebooks:
      - intro_notebook:
          roles: [VIEWER, ANALYST]
          main_file: INTRO_NB.ipynb
      - analyst_notebook:
          roles: [ANALYST]
          main_file: ANALYST_NB.ipynb
Morty Proxy This is a proxified and sanitized view of the page, visit original site.