Saltar al contenido

Configurar un objetivo de base de datos Microsoft SQL en Jitterbit Design Studio

Esta página describe cómo configurar Microsoft SQL Server como fuente o destino dentro de Jitterbit Studio utilizando autenticación de Windows o autenticación de SQL Server. Consulte Base de datos para obtener información sobre los tipos de autenticación admitidos para varios sistemas.

Nota

Para la configuración de autenticación Kerberos, consulte Autenticación Kerberos de SQL Server.

Autenticación de Windows

La autenticación de Windows es compatible utilizando ODBC y JDBC solo en agentes privados, y se puede usar con solo una cuenta de dominio. Para usar la autenticación de Windows, configure estas propiedades en Windows:

  1. Abra la herramienta Servicios Administrativa (Inicio > Herramientas administrativas > Servicios).
  2. Si utiliza ODBC, haga clic derecho en el servicio Jitterbit Apache Server y seleccione Propiedades. Si utiliza JDBC, haga clic derecho en el servicio Jitterbit Tomcat Server y seleccione Propiedades.
  3. Vaya a la pestaña Iniciar sesión. Seleccione Esta cuenta e ingrese el nombre y las credenciales de la cuenta que desea usar para la autenticación. Luego haga clic en Aplicar.
  4. Repita para el servicio Jitterbit Process Engine.
  5. Establezca TempDir en el archivo de configuración del agente (jitterbit.conf) a C:\Windows\Temp\jitterbit.
  6. Reinicie los servicios de Jitterbit.

Precaución

Asegúrese de haber otorgado al usuario de dominio el privilegio de Iniciar sesión como un servicio y Actuar como parte del sistema operativo. También asegúrese de que el usuario de dominio tenga derechos de lectura y escritura en el directorio de instalación de Jitterbit.

Nota

Una alternativa a los pasos anteriores del 1 al 4 es otorgar a la cuenta que se utiliza en la máquina del agente privado permisos en SQL Server. Esto puede ser realizado por el administrador de SQL Server configurando la cuenta de la máquina del agente privado en Active Directory de Windows (por ejemplo, <domainName>\<machineName>$).

Una vez que se completen los pasos anteriores, ve a Jitterbit Studio y configura tu origen o destino como de costumbre. En la pantalla de definición de origen/destino de base de datos, bajo Parámetros de Conexión, especifica lo siguiente:

  • Tipo de Controlador: Selecciona ODBC o JDBC según corresponda.

    Importante

    La autenticación de Windows es compatible con los siguientes controladores JDBC:

    Para usar la autenticación de Windows con los controladores JDBC de Microsoft, copia el archivo mssql-jdbc_auth-x.x.x.x64.dll del paquete de descarga del controlador a la carpeta C:\Program Files\Jitterbit Agent\jre\bin en el agente. La versión del DLL debe coincidir con la versión del archivo JAR JDBC incluido con el agente. Haz una copia de seguridad del archivo, ya que puede ser eliminado durante las actualizaciones importantes del agente.

  • Nombre del Servidor: Ingresa el nombre o la dirección IP del servidor que ejecuta el SQL Server al que Jitterbit necesita conectarse. Es posible que debas especificar el nombre de la instancia de SQL Server (HostName\InstanceName).

  • Nombre de la Base de Datos: Ingresa el nombre de la base de datos en el servidor a la que Jitterbit necesita integrarse.
  • Inicio de Sesión: Deja este campo en blanco.
  • Contraseña: Deja este campo en blanco.

  • Opciones: Haz clic para expandir configuraciones adicionales. En el campo Parámetros Adicionales de Cadena de Conexión, ingresa lo siguiente dependiendo de tu controlador:

    • SQL Server [ODBC]: Si estás utilizando el controlador "SQL Server [ODBC]", ingresa integratedSecurity=true. Si esto no funciona, ingresa Trusted_Connection=yes.
    • ODBC Driver 11 para SQL Server [ODBC], SQL Server Native Client 10.0 [ODBC], SQL Server Native Client 11.0 [ODBC]: Si estás utilizando otro controlador de SQL Server, ingresa Trusted_Connection=yes.
    • SQL Server jTDS [JDBC], SQL Server MS JDBC [JDBC]: Si estás utilizando un controlador JDBC de SQL Server, ingresa integratedSecurity=true.

El controlador ahora se autentificará como el usuario de dominio de Windows especificado anteriormente.

Autenticación de SQL Server

Ve a Jitterbit Studio y configura tu origen o destino como de costumbre. En la pantalla de definición de origen/destino, bajo Parámetros de Conexión, especifica lo siguiente:

  • Controlador: El controlador de SQL Server puede ser un controlador ODBC o JDBC.

    Nota

    Al seleccionar un controlador JDBC, recomendamos usar "SQL Server MS JDBC [JDBC]", el controlador JDBC de Microsoft para SQL Server, que se incluye con los agentes de Jitterbit a partir de la versión 9.3.

  • Nombre del Servidor: Ingresa el nombre o la dirección IP del servidor que ejecuta SQL Server al que Jitterbit necesita conectarse. Es posible que debas especificar el nombre de la instancia de SQL Server (HostName\InstanceName).

  • Nombre de la Base de Datos: Ingresa el nombre de la base de datos en el servidor a la que Jitterbit necesita integrarse.

  • Inicio de Sesión: Ingresa el nombre de usuario para la autenticación de SQL Server.

  • Contraseña: Ingresa la contraseña para la autenticación de SQL Server.

El controlador ahora se autentificará utilizando las credenciales de autenticación de SQL Server según lo especificado.

Cifrado de conexión y certificados de servidor

Las versiones actuales del controlador SQL Server MS JDBC solicitan una conexión cifrada por defecto (encrypt=true) y validan el certificado que presenta el servidor de la base de datos. Si el controlador no puede validar el certificado del servidor contra el almacén de claves de Java del agente, la conexión falla con un error similar a este:

"encrypt" property is set to "true" and "trustServerCertificate" property is set to "false" but the driver could not establish a secure connection to SQL Server by using Secure Sockets Layer (SSL) encryption: Error: (certificate_unknown) PKIX path building failed: sun.security.provider.certpath.SunCertPathBuilderException: unable to find valid certification path to requested target.

Esto afecta a cualquier SQL Server cuyo certificado no pueda ser rastreado hasta una autoridad de certificación (CA) que el agente ya confíe, incluyendo un certificado autofirmado o emitido internamente. Amazon RDS para SQL Server es un ejemplo: una instancia de RDS presenta un certificado emitido por una CA de Amazon RDS que no está en el almacén de claves predeterminado del agente. Una base de datos puede tener el cifrado habilitado y un certificado válido instalado y aún así fallar en esta validación, porque la falla es de confianza más que de cifrado.

La versión 12.8 del agente actualizó el controlador JDBC de Microsoft SQL Server incluido a la versión 13.4.0. Microsoft cambió el valor predeterminado de encrypt de false a true en la versión 10.2 del controlador y documenta ese cambio como uno que rompe la compatibilidad, descrito bajo encrypt en Establecer las propiedades de conexión en la documentación de Microsoft. Por lo tanto, un destino que funcionaba en un agente anterior a la versión 12.8 puede comenzar a fallar después de la actualización.

Para resolver esto, expanda Opciones e ingrese encrypt=false; en el campo Parámetros adicionales de la cadena de conexión, o inclúyalo en la cadena de conexión si seleccionó Construir cadena de conexión manualmente. Esto funciona en agentes en la nube y privados.

Precaución

Con encrypt=false, los datos viajan entre el agente y la base de datos sin cifrar. Use esta opción solo donde sea aceptable para los datos y la ruta de red involucrada.

Su configuración de SQL Server puede requerir otras propiedades de conexión también. Para las propiedades que el controlador admite, consulte Establecer las propiedades de conexión en la documentación de Microsoft.