Anpassung von gespeicherten Prozeduren und Handlern

Das Snowflake Native SDK for Connectors stellt die allgemeine Struktur des Konnektors bereit, erlaubt jedoch einige Anpassungen, abhängig vom Quellsystem und den tatsächlichen Bedürfnissen des Entwicklers. Aus diesem Grund haben einige Features leere Basisimplementierungen, und es ist möglich, sie mit kundenspezifischer Logik zu überschreiben. Darüber hinaus können die Komponenten je nach Bedarf aktiviert und deaktiviert werden. Mehr dazu finden Sie im Abschnitt „Auswählen der Komponenten“.

Gespeicherte Prozeduren

Die vom SDK bereitgestellten gespeicherten Prozeduren können in zwei Kategorien unterteilt werden:

  1. High-Level-Einstiegspunkte für die in Java implementierte Logik

  2. Interne Prozeduren mit geringerem Geltungsbereich

Da sie unterschiedliche Aufgaben haben, ist auch der Anpassungsprozess unterschiedlich.

Anpassung von High-Level-Prozeduren

High-Level-Prozeduren werden nur als Einstiegspunkt für die eigentliche, in Java implementierte Logik verwendet. Um die zugrunde liegende Logik zu ändern, müssen Sie also bei der Neuerstellung der gespeicherten Prozedur einen Pfad zu dem neuen Handler angeben. Diese Prozedur muss als benutzerdefinierter Code in das Skript setup.sql eingefügt werden. Dazu muss die neue Java-Implementierung bereitgestellt werden. Dies kann von Anfang an erfolgen oder mithilfe der in builders des SDK bereitgestellten Funktionen, die im Folgenden beschrieben werden:

CREATE OR REPLACE PROCEDURE PUBLIC.CONFIGURE_CONNECTOR(input VARIANT)
    RETURNS VARIANT
    LANGUAGE JAVA
    RUNTIME_VERSION = '11'
    PACKAGES = ('com.snowflake:snowpark:1.11.0')
    IMPORTS = ('/jar_with_custom_code.jar')
    HANDLER = 'com.custom.handler.CustomHandler.configure';
Copy

Anpassung von Prozeduren mit geringerem Geltungsbereich

Einige der vom Snowflake Native SDK for Connectors bereitgestellten Prozeduren haben so wenig Logik, dass sie einfach nur mit SQL geschrieben werden können. Für diese Prozeduren ist es möglich, die Standardimplementierungen nur durch SQL zu ersetzen. So können beispielsweise einige Prozeduren mit den Suffixen _VALIDATE oder _INTERNAL auf diese Weise reimplementiert werden. Alle diese Prozeduren können auch mit einem reinen Java-Ansatz über Builders angepasst werden. Dieser Ansatz wird unten erläutert. Es gibt auch die Möglichkeit, eine Prozedur, die nur SQL verwendet hat, durch Handler zu ersetzen. In diesem Fall ist es dasselbe wie bei den gespeicherten High-Level-Prozeduren, die oben beschrieben wurden.

CREATE OR REPLACE PROCEDURE PUBLIC.CONFIGURE_CONNECTOR_INTERNAL(config VARIANT)
    RETURNS VARIANT
    LANGUAGE SQL
    EXECUTE AS OWNER
    AS
    BEGIN
        -- input some custom logic here
        RETURN OBJECT_CONSTRUCT('response_code', 'OK');
    END;
Copy

Handler

Das Snowflake Native SDK for Connectors definiert Standard-Handler für die gespeicherten Prozeduren. Diese können so verwendet werden, wie sie sind, sie können angepasst oder komplett ersetzt werden. Im letzteren Fall muss die gesamte benutzerdefinierte Implementierung nicht den vom SDK definierten Standards folgen und die benutzerdefinierte Implementierung muss in SQL spezifiziert werden, wie es oben für die Anpassung von High-Level-Prozeduren erwähnt wurde.

Wenn Sie jedoch dem vom SDK definierten Konnektorablauf folgen möchten, gibt es die Möglichkeit, nur einige Teile des Ablaufs anzupassen. Jeder vorhandene Handler verwendet mehrere zugrunde liegende Objekte, in den meisten Fällen sind dies validator-, callback- oder helper-Klassen. Jede von ihnen bietet eine bestimmte Schnittstelle, und es ist möglich, die Standardimplementierungen durch die kundenspezifischen Implementierungen der Schnittstelle zu ersetzen.

Builders

Um den vom SDKdefinierten Konnektorablauf während der Anpassung beizubehalten, werden Hilfsobjekte namens builders bereitgestellt. Jede handler-Klasse hat ihre eigene builder gebündelt. Diese ermöglichen es dem Benutzer, eine kundenspezifische Implementierung der zugrunde liegenden Java-Objekte bereitzustellen. Auf diese Weise muss der Entwickler den internen Konnektorablauf nicht anfassen und kann sich auf das Anpassen der benötigten Teile konzentrieren. Bei der Verwendung von builders gibt es einen kleinen Haken: Bei diesem Ansatz muss der Entwickler auch die neue Einstiegspunkt-Methode angeben, auf die in der gespeicherten Prozedur verwiesen wird.

Ein handler mit einem angepassten validator unter Verwendung des builder sieht zum Beispiel wie folgt aus:

class CustomConnectionConfigurationInputValidator implements ConnectionConfigurationInputValidator {
    @Override
    public ConnectorResponse validate(Variant config) {
        // CUSTOM LOGIC
        return ConnectorResponse.success();
    }
}

class CustomHandler {

    // Path to this method needs to be specified in the PUBLIC.SET_CONNECTION_CONFIGURATION procedure using SQL
    public static Variant configureConnection(Session session, Variant configuration) {
            //Using builder
        var handler = ConnectionConfigurationHandler.builder(session)
            .withInputValidator(new CustomConnectionConfigurationInputValidator())
            .build();
        return handler.connectionConfiguration(configuration).toVariant();
    }
}
Copy

Dann muss die Einstiegspunkt-Methode in SQL wie folgt angegeben werden:

CREATE OR REPLACE PROCEDURE PUBLIC.SET_CONNECTION_CONFIGURATION(input VARIANT)
    RETURNS VARIANT
    LANGUAGE JAVA
    RUNTIME_VERSION = '11'
    PACKAGES = ('com.snowflake:snowpark:1.11.0')
    IMPORTS = ('/jar_with_custom_code.jar')
    HANDLER = 'com.custom.handler.CustomHandler.configureConnection';
Copy
Sprache: Deutsch