Customização de procedimentos armazenados e manipuladores

O Snowflake Native SDK for Connectors fornece a estrutura geral do conector, no entanto, permite algumas personalizações, dependendo do sistema de origem e das necessidades reais do desenvolvedor. Por esse motivo, alguns recursos têm implementações básicas vazias e é possível substituí-los por lógica personalizada. Além disso, os componentes podem ser habilitados e desabilitados de acordo com necessidades específicas. Mais sobre isso na seção de escolha de componentes.

Procedimentos armazenados

Procedimentos armazenados fornecidos pelo SDK podem ser divididos em duas categorias:

  1. Pontos de entrada de alto nível para a lógica implementada em Java

  2. Procedimentos internos com escopo menor

Como eles têm responsabilidades diferentes, o processo de personalização também é diferente.

Personalização de procedimentos de alto nível

Procedimentos de alto nível são usados apenas como um ponto de entrada para a lógica real implementada em Java. Portanto, para alterar a lógica subjacente, um caminho para o novo manipulador precisa ser especificado ao recriar o procedimento armazenado. Este procedimento precisa ser adicionado como código personalizado no script setup.sql. Isso requer que a nova implementação Java seja fornecida, o que pode ser feito do zero ou usando o fornecido em SDK builders, que são descritos abaixo:

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

Personalização de procedimentos de escopo menor

Alguns dos procedimentos previstos pelo Snowflake Native SDK for Connectors têm tão pouca lógica que podem ser facilmente escritos usando apenas SQL. Para esses procedimentos é possível substituir as implementações padrão usando SQL apenas. Por exemplo, alguns procedimentos com sufixos _VALIDATE ou _INTERNAL podem ser reimplementados dessa maneira. Todos esses procedimentos também podem ser personalizados usando a abordagem Java apenas por meio de Builders. Essa abordagem é explicada abaixo. Também existe a possibilidade de substituir um procedimento que utilizava apenas SQL para usar manipulador em vez disso. Neste caso, será o mesmo que para os procedimentos armazenados de nível alto acima.

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

Manipuladores

O Snowflake Native SDK for Connectors define manipuladores padrão para os procedimentos armazenados. Eles podem ser usados como estão, personalizados ou completamente substituídos. Para o último caso, toda a implementação personalizada não precisa seguir os padrões definidos pelo SDK e a implementação personalizada precisa ser especificada em SQL como foi mencionado acima para personalizar procedimentos de alto nível.

Entretanto, se você deseja seguir o fluxo do conector definido pelo SDK, há uma maneira de personalizar apenas algumas partes do fluxo. Cada manipulador existente está usando vários objetos subjacentes, na maioria dos casos eles são: classes validator, callback ou helper. Cada uma delas satisfaz alguma interface e é possível substituir implementações padrão por implementações personalizadas da interface.

Construtores

Para reter o fluxo definido por SDK no conector durante a personalização, os objetos auxiliares chamados builders são fornecidos. Cada classe handler tem seu próprio builder no pacote. Elas permitem que o usuário forneça uma implementação personalizada dos objetos Java subjacentes. Dessa forma, o desenvolvedor não precisa mexer no fluxo interno do conector e pode se concentrar em personalizar apenas as partes necessárias. Há um pequeno problema ao usar builders, essa abordagem também exige que o desenvolvedor especifique o novo método de ponto de entrada que será referenciado no procedimento armazenado.

Por exemplo, um handler usando um validator personalizado usando o builder parece com isso:

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

Então o método do ponto de entrada em SQL precisa ser especificado assim:

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
Linguagem: Português