Kommunikation zwischen Apps¶

Kommunikation zwischen Apps: Überblick¶

Die Kommunikation zwischen Apps (IAC) ermöglicht einer Snowflake Native App, zusätzliche Funktionen für andere Snowflake Native Apps im selben Verbraucherkonto bereitzustellen, indem es Zugriff auf Funktionen und Prozeduren gewährt, die andere Apps aufrufen können.

Beispiel: Eine Snowflake Native App, die Kunden-IDs auflöst, kann anderen Snowflake Native Apps dabei helfen, Kundendaten durch Verknüpfen von Datensets verschiedener Anbietenden zu verbessern.

IAC bietet die Infrastruktur für zwei oder mehr unabhängige Apps, um miteinander zu kommunizieren und dabei ihre Anforderungen an Verwaltung und Sicherheit zu berücksichtigen. App-Entwicklerteams aktivieren IAC für ihre Apps, indem sie Folgendes tun:

• Erstellen von Schnittstellen.

• Verwenden von App-Rollen zur Steuerung des Zugriffs auf die Schnittstellen.

• Auswahl der synchronen oder asynchronen Interaktion. Bei der synchronen Interaktion werden gespeicherte Prozeduren oder Funktionen verwendet, die andere Apps direkt aufrufen können, während die asynchrone Interaktion den Zugriff auf Anforderungsergebnisse ermöglicht, die in Tabellen oder Ansichten gespeichert sind, die andere Apps abfragen können, um die Ergebnisse zu prüfen.

Terminologie¶

IAC verwendet die folgenden Begriffe:

Client

Die App, die die Verbindungsanforderung initiiert und die Funktionen und Prozeduren der Server-App aufruft.

Server

Die App, die über App-Rollen Zugriff auf ihre Funktionen und Prozeduren bietet.

Verbraucher

Die benutzende Person, die die Client- und Server-Apps installiert.

Anwendungskonfiguration

Ein SQL-Objekt, das die Client-App verwendet, um den Namen der Server-App anzufordern. IAC verwendet eine Anwendungskonfiguration vom Typ``APPLICATION_NAME``, um den Namen der Server-App zu speichern.

Anwendungsspezifikation

Ein SQL-Objekt, das die Client-App erstellt, um eine Verbindung zur Server-App anzufordern. IAC verwendet eine Anwendungsspezifikation vom Typ CONNECTION. Weitere Informationen zu App-Spezifikationen finden Sie unter Überblick über App-Spezifikationen.

Workflow für die Kommunikation zwischen Apps¶

Das Herstellen und Verwenden einer Verbindung erfordert einen Handshake-Prozess zwischen der Client- und der Server-App.

1. Abrufen der App-Rollennamen vom Anbieter der Server-App: Der Anbieter der Client-App stimmt sich mit dem Anbieter der Server-App außerhalb von Snowflake ab, um zu bestimmen, welche Server-App-Rollen in der Verbindungsspezifikation angefordert werden sollen.

2. Identifizieren der Ziel-App: Die Client-App erstellt ein Konfigurationsdefinitionsobjekt, um den Namen der Server-App anzufordern. Der Verbrauchende erkennt eingehende Anforderungen und stellt der Client-App den Namen der Server-App über das Konfigurationsobjekt zur Verfügung.

3. Anfordern und Genehmigen einer Verbindung: Die Client-App erstellt eine Anwendungsspezifikation, um eine Verbindung zur Server-App anzufordern, und der Verbrauchende genehmigt die Verbindungsanforderung.

4. Kommunizieren mit der Server-App: Die Client-App ruft die Prozeduren oder Funktionen der Server-App auf.

ALTER APPLICATION
  SET CONFIGURATION DEFINITION my_server_app_name_configuration
    TYPE = APPLICATION_NAME
    LABEL = 'Server App'
    DESCRIPTION = 'Request for an app that will provide access to server procedures and functions. The server app version must be greater than or equal to 3.2.'
    APPLICATION_ROLES = (my_server_app_role);

SHOW CONFIGURATIONS IN APPLICATION my_server_app_name;

name                             | created_on              | updated_on              | type               | ...
my_server_app_name_configuration | 2026-02-09 10:00:00.000 | 2026-02-09 10:00:00.000 | APPLICATION_NAME   | ...

ALTER APPLICATION my_client_app_name
  SET CONFIGURATION my_server_app_name_configuration
  VALUE = MY_SERVER_APP_NAME;

ALTER APPLICATION SET SPECIFICATION my_server_app_name_connection_specification
  TYPE = CONNECTION
  LABEL = 'Server App'
  DESCRIPTION = 'Request for an app that will provide access to server procedures and functions. The server app version must be greater than or equal to 3.2.'
  SERVER_APPLICATION = MY_SERVER_APP_NAME -- server name obtained from Step 1
  SERVER_APPLICATION_ROLES = (my_server_app_role);

ALTER APPLICATION my_server_app_name
  APPROVE SPECIFICATION my_server_app_name_connection_specification
  SEQUENCE_NUMBER = 1;

SHOW APPROVED SPECIFICATIONS ->>
  SELECT PARSE_JSON("definition"):"SERVER_APPLICATION"::STRING
  FROM $1
  WHERE "name" = 'MY_SERVER_APP_NAME_CONNECTION_SPECIFICATION';

session.call("server_app_name.customer_schema.get_customer_data", customer_id);

session.call("server_app_name.customer_schema.request_customer_data_async", customer_id);

session.call("server_app_name.customer_schema.check_customer_data_requests_async", customer_id);

Verwalten von Verbindungen¶

Zum Anzeigen bestehender Verbindungen in |sf-web-interface|gehen Sie wie folgt vor:

1. Melden Sie sich bei Snowsight an.

2. Wählen Sie im Navigationsmenü die Option Catalog » Apps aus.

3. Wählen Sie die App aus. Alle Verbindungen der App werden in einem Abschnitt mit der Bezeichnung Configurations angezeigt. Unterhalb dieses Abschnitts gibt es einen Unterabschnitt mit der Bezeichnung Application connections.

4. Um eine Verbindung zu ändern, klicken Sie auf das Bleistiftsymbol für die Verbindung. Sie können Folgendes ändern:

   • Welche App mit der App verbunden ist

   • Der Genehmigungsstatus der Verbindung

5. Um die verbundene App anzuzeigen, klicken Sie die Schaltfläche View app.

6. Klicken Sie auf das Zahnrad-Symbol, um die Sicherheitseinstellungen für die Verbindung zu ändern.

Sicherheitshinweise¶

Bei der Genehmigung einer Spezifikationsanforderung sollten sich Verbrauchende darüber im Klaren sein, dass die Gewährung des Zugriffs einer Server-App auf eine Client-App die Berechtigungen der Client-App verbessern kann. Wenn beispielsweise eine Server-App über einen externen Zugriff verfügt, könnte die Client-App über die Server-App indirekten Zugriff auf das Internet oder auf andere externe Ressourcen erhalten. Wenn die Server-App eine Client-App einer anderen Server-App ist, kann die Client-App möglicherweise über die erste Server-App auf die Ressourcen der anderen Server-App zugreifen.

Verbrauchende sollten die Möglichkeiten und Berechtigungen der Server-App überprüfen, bevor sie eine Verbindung genehmigen. Verwenden Sie eine Admin-Rolle (z. B. ACCOUNTADMIN), um die Funktionen des Servers zu prüfen. Wenn Sie den Server mit einer Rolle mit niedrigeren Berechtigungen überprüfen, werden nicht alle Funktionen und Berechtigungen des Servers angezeigt. Verbrauchende sollten beachten, dass der Code der Server-App für den Verbrauchenden nicht sichtbar ist und dass die Berechtigungen und Funktionen der Server-App geändert werden können, nachdem der Verbrauchende die Verbindung genehmigt hat.

Beispielhafte SQL-Befehle zur Überprüfung der Fähigkeiten und Berechtigungen der Server-App umfassen unter anderem die folgenden:

• SHOW GRANTS TO APPLICATION: Dieser Befehl listet auf, welche Berechtigungen für die Client-App der Server-App erteilt wurden.

• SHOW PRIVILEGES IN APPLICATION: Dieser Befehl listet auf, welche potenziellen Berechtigungen auf Kontoebene der Client-App erteilt werden könnten.

• SHOW REFERENCES IN APPLICATION: Dieser Befehl listet Referenzen auf, die die Client-App möglicherweise ohne Verwendung von Berechtigungen verwenden könnte.

• SHOW SPECIFICATIONS IN APPLICATION: Dieser Befehl listet die Anwendungsspezifikationen auf, die der Verbrauchende genehmigt hat, einschließlich der Integrationen für den externen Zugriff (EAIs), Sicherheitsintegrationen, Freigaben, Freigabeangebote und Verbindungen.

SQL-Referenz¶

Die folgenden SQL-Befehle werden verwendet, um die Kommunikation zwischen Apps zu verwalten.

• ALTER APPLICATION SET SPECIFICATION: Erstellt eine App-Spezifikation, die die Server-App verwendet, um der Client-App Zugriff auf ihre Funktionen und Prozeduren zu gewähren.

• ALTER APPLICATION DROP SPECIFICATION: Löscht eine App-Spezifikation.

• ALTER APPLICATION … { APPROVE | DECLINE} SPECIFICATION: Genehmigt oder lehnt eine Anforderung nach einer App-Spezifikation ab.

• SHOW-SPECIFICATIONS: Listet alle Anwendungsspezifikationen in einer App auf.

• DESCRIBE-SPECIFICATION: Beschreibt die App-Spezifikationen für eine App.

• ALTER APPLICATION SET CONFIGURATION DEFINITION: Erstellt oder aktualisiert eine Anwendungskonfiguration (ein Schlüssel-Wert-Paar), die den Namen einer anderen Anwendung vom Verbrauchenden anfordert.

• ALTER APPLICATION DROP CONFIGURATION DEFINITION: Löscht eine Anwendungskonfiguration.

• ALTER APPLICATION SET CONFIGURATION VALUE: Legt einen Wert in einer Anwendungskonfiguration fest.

• ALTER APPLICATION UNSET CONFIGURATION: Setzt den Wert auf die angegebene Anwendungskonfiguration zurück.

• SHOW-CONFIGURATIONS: Listet alle Anwendungskonfigurationen in einer App auf.

• DESCRIBE-CONFIGURATION: Beschreibt die Details einer Anwendungskonfiguration.

• IS_CONFIGURATION_SET (SYS_CONTEXT-Funktion): Gibt zurück, ob für die Konfiguration ein Wert festgelegt wurde oder nicht.

• GET_CONFIGURATION_VALUE (SYS_CONTEXT-Funktion): Gibt den aktuellen Wert der Konfiguration zurück.

• SHOW GRANTS TO APPLICATION: Listet alle Berechtigungen und Datenbank-/Anwendungsrollen auf, die der angegebenen App erteilt wurden.

• SHOW GRANTS TO APPLICATION ROLE: Listet alle Berechtigungen auf, die die Anwendungsrolle hat.

• SHOW GRANTS OF APPLICATION ROLE: Listet alle Rollen und Anwendungen auf, denen die angegebene Anwendungsrolle zugewiesen ist.

Callbacks¶

Das Snowflake Native App Framework bietet Lebenszyklus-Callbacks, um den Workflow für die Kommunikation zwischen Apps zu verwalten. Mit diesen Callbacks kann eine App auf Änderungen in Konfigurationen, Verbindungen und Spezifikationen reagieren. Um Callbacks zu verwenden, registrieren Sie diese im Abschnitt lifecycle_callbacks der Manifest-Datei der App.

Allgemeine Informationen zu Callbacks finden Sie unter Callbacks.

Beispiele¶

Die folgenden Beispiele zeigen, wie Sie eine App für die Kommunikation zwischen Apps konfigurieren.

• Beispiel: Setup-Skript und Manifest-Dateien

• Beispiel: Asynchrone Kommunikation zwischen Apps

CREATE OR ALTER VERSIONED SCHEMA app_schema;

-- create a callback that creates the connection request before the config value of the server name is saved
CREATE OR REPLACE PROCEDURE app_schema.before_config_change_callback(config_name STRING, config_value STRING)
RETURNS STRING
LANGUAGE SQL
AS
$$
DECLARE
    spec_name VARCHAR;
    existing_target VARCHAR;
BEGIN
    IF (config_value IS NOT NULL AND config_name = 'MY_SERVER_APP_NAME_CONFIGURATION') THEN
        SHOW SPECIFICATIONS;
        SELECT PARSE_JSON("definition"):SERVER_APPLICATION::STRING
            INTO existing_target
            FROM TABLE(RESULT_SCAN(LAST_QUERY_ID()));

        IF(existing_target IS NOT NULL AND UPPER(existing_target) != UPPER(config_value)) THEN
            EXECUTE IMMEDIATE 'ALTER APPLICATION DROP SPECIFICATION CONNECTION_' || UPPER(existing_target);
        END IF;

        spec_name := 'CONNECTION_' || UPPER(config_value);
        EXECUTE IMMEDIATE
        'ALTER APPLICATION SET SPECIFICATION ' || spec_name || '
            TYPE = CONNECTION
            LABEL = ''Server App''
            DESCRIPTION = ''Request for an app that will provide access to server procedures and functions. The server app version must be greater than or equal to 3.2.''
            SERVER_APPLICATION = ' || config_value || '
            SERVER_APPLICATION_ROLES = (my_server_app_role)';
    END IF;
RETURN 'success';
END;
$$;

CREATE APPLICATION ROLE IF NOT EXISTS client_app_user;
GRANT USAGE ON SCHEMA app_schema TO APPLICATION ROLE client_app_user;
ALTER APPLICATION SET CONFIGURATION DEFINITION my_server_app_name_configuration
    TYPE = APPLICATION_NAME
    LABEL = 'Server App'
    DESCRIPTION = 'Request for an application that will provide access to server procedures and functions. The server app version must be greater than or equal to 3.2'
    APPLICATION_ROLES = (client_app_user);

manifest_version: 2

artifacts:
  setup_script: setup.sql

lifecycle_callbacks:
    before_configuration_change: app_schema.before_config_change_callback

CREATE TABLE IF NOT EXISTS app_schema.processing_queue (
  request_id NUMBER AUTOINCREMENT,
  operation STRING,
  input STRING,
  status STRING DEFAULT 'PENDING',
  response STRING DEFAULT ''
);

CREATE OR REPLACE PROCEDURE app_schema.submit_request(operation STRING, input STRING)
RETURNS STRING
LANGUAGE SQL
EXECUTE AS OWNER
AS
$$
BEGIN
    INSERT INTO app_schema.processing_queue (operation, input) VALUES (:operation, :input);
    RETURN 'Request submitted successfully';
END;
$$;

CREATE OR REPLACE PROCEDURE app_schema.process_requests()
RETURNS STRING
LANGUAGE SQL
EXECUTE AS OWNER
AS
$$
DECLARE
    -- Cursor to find all PENDING requests
    c1 CURSOR FOR SELECT * FROM app_schema.processing_queue WHERE status = 'PENDING';
    result STRING;
BEGIN
    FOR request IN c1 DO

        IF (request.operation = 'OPERATION_X') THEN
            -- assuming there is a UDF func_x(input) to perform operation_x
            result := (SELECT func_x(:request.input));
        END IF;

        -- update the processing queue with the result
        LET stmt STRING :=
            'UPDATE app_schema.processing_queue SET status = 'DONE', response = ' ||
            result ||
            ' WHERE request_id = ' ||
            request.request_id;
        EXECUTE IMMEDIATE (:stmt);

    END FOR;

    RETURN 'Processed pending requests.';
END;
$$;

CREATE OR REPLACE PROCEDURE app_schema.fetch_response(operation STRING, input STRING)
RETURNS STRING
LANGUAGE SQL
EXECUTE AS OWNER
AS
$$
BEGIN
    LET res STRING := (SELECT response FROM app_schema.processing_queue WHERE operation = :operation AND input = :input);
    RETURN res;
END;
$$;

CREATE APPLICATION ROLE IF NOT EXISTS my_server_app_role;
GRANT USAGE ON SCHEMA app_schema TO APPLICATION ROLE my_server_app_role;
GRANT USAGE ON PROCEDURE app_schema.submit_request(string, string) TO APPLICATION ROLE my_server_app_role;
GRANT USAGE ON PROCEDURE app_schema.process_requests() TO APPLICATION ROLE my_server_app_role;
GRANT USAGE ON PROCEDURE app_schema.fetch_response(string, string) TO APPLICATION ROLE my_server_app_role;