Configuração do conector

A configuração do conector é a primeira etapa necessária da fase do assistente. Ele garante que o conector tenha a configuração dos objetos comuns entre todos os tipos de conectores, independentemente do sistema de origem e do domínio reais. O procedimento chamado PUBLIC.CONFIGURE_CONNECTOR(config VARIANT) é o ponto de entrada da UI ou planilha para fazer isso. Ao substituir com lógica personalizada, tenha em mente que esse procedimento precisa ser substituído, pois aponta para o método ConfigureConnectorHandler.configureConnector estático em Java como um manipulador.

Chamar este procedimento requer que o usuário tenha a função do aplicativo ADMIN atribuída.

A etapa de configuração do conector consiste internamente em várias fases. Alguns deles são totalmente personalizáveis e, por padrão, não fazem nada. As fases são as seguintes:

  1. Validação de status

  2. Validação de campos

  3. Validação de entrada

  4. Atualização de configuração

  5. Retorno de chamada interno

  6. Atualização de status

Requisitos

A configuração do conector requer pelo menos os seguintes arquivos SQL a serem executados durante a instalação do aplicativo nativo:

  • core.sql

  • configuration/app_config.sql

  • configuration/connector_configuration.sql

Validação de status

Para executar a configuração do conector, o status interno do conector precisa ser CONFIGURING. Esta validação não pode ser substituída usando ConfigureConnectorHandlerBuilder nem sobrescrevendo um procedimento armazenado. No entanto, é possível implementar um manipulador personalizado, que não terá esse tipo de validação.

Validação de campos

A configuração do conector precisa conter um conjunto de campos específicos. Todos eles são opcionais, mas qualquer outro campo faz com que uma exceção seja lançada. As chaves permitidas são:

  • warehouse

  • destination_database

  • destination_schema

  • operational_warehouse

  • global_schedule

  • data_owner_role

  • agent_username

  • agent_role

Warehouse

O warehouse é usado pelo conector para executar o agendador, executar tarefas e executar consultas.

Destination_database

O banco de dados de destino é usado para armazenar os dados ingeridos pelo conector. Este banco de dados deve estar fora do conector. Pode ser um banco de dados existente, porém o conector precisa ter privilégios de gravação nele. Também pode ser um banco de dados recém-criado, no entanto, isso não acontecerá automaticamente e precisa ser implementado como parte do retorno de chamada interno durante a configuração do conector ou a finalização da configuração.

Destination_schema

O esquema de destino será o esquema usado no destination_database acima.

Operational_warehouse

Ocasionalmente, o conector precisa separar os processos de ingestão reais que exigem um warehouse dos processos relacionados às operações internas do conector. Especificando este segundo armazém para dividir a carga entre eles.

Global_schedule

Esta propriedade define o cronograma de execução para a tarefa do agendador. Atualmente, o agendador processará apenas recursos com seus próprios scheduleType=GLOBAL. O valor desta propriedade deve ser semelhante ao abaixo:

"global_schedule": {
    "scheduleType": "CRON",
    "scheduleDefinition": "*/10 * * * *"
}
Copy

Data_owner_role

Função que pode ser usada para atribuir propriedade ao banco de dados de sincronização para reter os dados após a desinstalação do conector.

Agent_username

Nome de usuário usado pelo agente do conector baseado em push ao se conectar ao Snowflake.

Agent_role

Função usada pelo agente do conector baseado em push ao conectar-se com o Snowflake.

Validação de entrada

A entrada precisa ser válida Variant, Além disso, o SDK fornece um procedimento armazenado interno chamado: PUBLIC.CONFIGURE_CONNECTOR_VALIDATE(config VARIANT). Por padrão, este procedimento apenas retorna 'response_code': 'OK', no entanto, ele pode ser alterado substituindo este procedimento armazenado. Alternativamente, pode ser personalizado usando ConfigureConnectorHandlerBuilder e fornecer uma implementação personalizada da interface ConfigureConnectorValidator.

Atualização de configuração

Depois que as validações forem aprovadas com sucesso, a configuração será salva na tabela APP_CONFIG interna. O serviço responsável por isso salva a Variant fornecida sob a chave connector_configuration.

Retorno de chamada interno

O retorno de chamada interno é outra etapa personalizável. Por padrão, ele invoca PUBLIC.CONFIGURE_CONNECTOR_INTERNAL(config VARIANT), que retorna 'response_code': 'OK'. Pode ser sobrescrito através do script SQL ou usando um ConfigureConnectorHandlerBuilder para fornecer implementação personalizada da interface ConfigureConnectorCallback.

Atualização de status

Quando todas as fases acima forem concluídas com sucesso, o status interno do conector será atualizado para:

{
    "status": "CONFIGURING",
    "configurationStatus": "CONFIGURED"
}
Copy

Para um diagrama de transições de estado, veja Fluxo do conector.

Resposta

Resposta bem-sucedida

Se o procedimento for concluído com sucesso, ele retornará uma resposta no seguinte formato:

{
  "response_code": "OK",
}
Copy

Resposta de erro

Em caso de erro, a resposta seguirá o formato abaixo:

{
  "response_code": "<ERROR_CODE>",
  "message": "<error message>"
}
Copy

Possíveis códigos de erro incluem:

  • INVALID_CONNECTOR_STATUS - O procedimento foi chamado no conector já configurado

  • CONNECTOR_CONFIGURATION_PARSING_ERROR - A configuração fornecida não é um JSON válido

  • CONNECTOR_STATUS_NOT_FOUND - O registro de status do conector não existe no banco de dados

  • CONNECTOR_STATUS_PARSING_ERROR - Valor armazenado na tabela APP_STATE com a chave connector_status tem formato incorreto e não pode ser analisado pelo aplicativo

Linguagem: Português