Conectores, configuración y autenticación

Alcance y criterio de compatibilidad

Una Connection reúne dirección, metadatos, método de autenticación y custodia de credenciales. Un componente de Mapping selecciona esa conexión y define la operación sobre un recurso. El Worker ejecuta la operación con sus capacidades y permisos efectivos. Son tres contratos distintos: crear una conexión no garantiza que un proveedor admita todas las modalidades de lectura, escritura o recuperación.

Use esta matriz para preparar los datos del formulario Connections. Los identificadores entre comillas de código permiten reconocer configuraciones e interpretar errores. Un asterisco indica un campo marcado como obligatorio en el catálogo del formulario; otros campos pueden resultar obligatorios por autenticación, protocolo o validación del proveedor. Los puertos son valores iniciales, no instrucciones para abrir redes indiscriminadamente. El endpoint debe corresponder al entorno autorizado de la organización.

Matriz del catálogo de conexiones

La matriz recoge todas las entradas declaradas por el formulario. La oferta efectiva de la instalación se obtiene del catálogo disponible y puede ser menor. Tampoco afirma que una identidad adjunta funcione fuera de su nube o que un controlador esté instalado en cualquier Worker. PostgreSQL figura en la interfaz; no debe interpretarse la lista del registro genérico de conectores como el único mecanismo de integración de PostgreSQL.

Interpretación de los métodos

El catálogo general de autenticación también define oracle_wallet, oci_resource_principal, web_identity e instance_profile. No están asignados como opciones independientes a las entradas de conexión de esta matriz; su existencia no implica que puedan seleccionarse para cualquier conector. Para Amazon S3, aws_iam contempla la identidad de runtime ya adjunta.

Variantes que cambian la preparación

En BigQuery, Database significa Project ID y Schema significa Dataset. En Oracle, Database se presenta como Service name. Databricks requiere HTTP path y Catalog. Snowflake solicita Database y Warehouse; Role y Schema completan el contexto. No intercambie un nombre de base, una ruta HTTP y un identificador de proyecto aunque todos sean textos.

Salesforce parte de API version v65.0; exige la URL My Domain y la configuración de la aplicación e integración correspondientes. Dynamics 365 solicita Directory (tenant) ID y deriva el scope del entorno. Odoo identifica explícitamente su API JSON-2 de versión 19 o posterior. SharePoint añade Site ID o ruta relativa del sitio. Estas diferencias pertenecen al contrato del conector, no a una opción genérica de SQL.

La entrada FTP / SFTP permite escoger protocolo. SFTP usa inicialmente puerto 22; FTP y FTPS, 21. La clave SSH desaparece como opción para protocolos distintos de SFTP. La casilla TLS se ajusta al protocolo: FTP no equivale a una conexión cifrada. Conserve la política de transporte exigida por su organización.

Custodia y preparación segura

Dova Worker Agent conserva el secreto en el entorno del cliente. Customer vault guarda una referencia al secreto de un almacén externo. Passwordless usa una identidad de ejecución sin almacenar un secreto reutilizable. Dova Vault es una modalidad de excepción con entrada cifrada que no vuelve a mostrar el valor. Managed reference identifica referencias administradas existentes.

Los proveedores de referencias reconocidos por el formulario incluyen AWS Secrets Manager, Azure Key Vault, Google Secret Manager, HashiCorp Vault, CyberArk Conjur y Kubernetes Secret. Cada uno valida su propia forma de referencia. Una URI bien formada no demuestra que el Worker pueda resolverla: revise identidad, red y autorización del almacén. Nunca sustituya una referencia por el valor del secreto en nombres, descripciones o archivos de evidencia.

El selector de autenticación depende de la custodia. Passwordless filtra los métodos marcados sin secreto; la modalidad protegida ofrece los métodos pertinentes. Si una combinación carece de métodos válidos, cambie la custodia o el conector conforme al diseño, sin forzar valores ocultos del formulario.

POC de conectividad y resultados esperados

Prepare un recurso aislado con dos registros sintéticos y una identidad limitada a lectura. Cree la conexión en el tenant de pruebas, complete endpoint y metadatos, seleccione la custodia y guarde. Ejecute la comprobación de conexión desde la interfaz. Registre conector, Worker, hora y resultado; omita material secreto. Después seleccione esa Connection desde el componente fuente correspondiente y lea exclusivamente el recurso de prueba.

El resultado esperado tiene dos niveles: la comprobación confirma las condiciones que el conector verifica; la lectura confirma acceso al objeto y proyección de sus dos registros. No considere aprobada una escritura porque la prueba de conexión haya pasado. Para evaluar un destino, utilice otro recurso descartable, pruebe el modo de escritura elegido y compare claves, cantidad y contenido. Esta secuencia es una práctica reproducible, no un resultado de conectividad ya obtenido en su entorno.

Diagnóstico y límites

Ante rechazo de autenticación, compruebe método, identidad, vigencia y permisos. Ante objeto inexistente, confirme catálogo, base, esquema o ruta. Ante timeout, revise primero el Worker y su acceso de red. Ante una opción de escritura ausente, consulte las capacidades efectivas del conector: el componente genérico no garantiza todos los modos para cada proveedor. No convierta un timeout en evidencia de credenciales incorrectas ni copie respuestas que puedan incluir datos del origen.

Continúe con componentes de Mapping, transformaciones y permisos por acción.