Configurar una fuente de base de datos Microsoft SQL en Jitterbit Design Studio
Esta página describe cómo configurar Microsoft SQL Server como fuente o destino en Jitterbit Studio usando autenticación de Windows o SQL Server. Consulta Base de datos para obtener información sobre los tipos de autenticación compatibles con varios sistemas.
Nota
Para la configuración de autenticación Kerberos, consulta Autenticación Kerberos de SQL Server.
Autenticación de Windows
La autenticación de Windows se admite usando ODBC y JDBC solo en agentes privados, y se puede usar con una sola cuenta de dominio. Para usar autenticación de Windows, configura estas propiedades en Windows:
- Abre la herramienta Servicios Administrativos (Inicio > Herramientas administrativas > Servicios).
- Si usas ODBC, haz clic derecho en el servicio Jitterbit Apache Server y selecciona Propiedades. Si usas JDBC, haz clic derecho en el servicio Jitterbit Tomcat Server y selecciona Propiedades.
- Ve a la pestaña Iniciar sesión. Selecciona Esta cuenta e ingresa el nombre y las credenciales de la cuenta que deseas usar para la autenticación. Luego haz clic en Aplicar.
- Repite el paso anterior para el servicio Jitterbit Process Engine.
- Establece
TempDiren el archivo de configuración del agente (jitterbit.conf) enC:\Windows\Temp\jitterbit. - Reinicia los servicios de Jitterbit.
Precaución
Asegúrate de haber otorgado al usuario del dominio el privilegio de Iniciar sesión como servicio y Actuar como parte del sistema operativo. También asegúrate de que el usuario del dominio tenga derechos de lectura y escritura en el directorio de instalación de Jitterbit.
Nota
Una alternativa a los pasos 1 a 4 anteriores es otorgar a la cuenta que se usa en la máquina del agente privado permisos en SQL Server. Esto puede hacerlo el administrador de SQL Server configurando la cuenta de la máquina del agente privado en Windows Active Directory (por ejemplo, <domainName>\<machineName>$).
Una vez completados los pasos anteriores, ve a Jitterbit Studio y configura tu fuente o destino de forma normal. En la pantalla de definición de fuente/destino de base de datos, en Parámetros de conexión, especifica lo siguiente:
-
Tipo de controlador: Selecciona ODBC o JDBC según corresponda.
Importante
La autenticación de Windows se admite con los siguientes controladores JDBC:
- SQL Server jTDS [JDBC]
- SQL Server MS JDBC [JDBC]
- Versiones más recientes del Controlador JDBC de Microsoft para SQL Server
Para usar autenticación de Windows con los controladores JDBC de Microsoft, copia el archivo
mssql-jdbc_auth-x.x.x.x64.dlldel paquete de descarga del controlador a la carpetaC:\Program Files\Jitterbit Agent\jre\binen el agente. La versión del DLL debe coincidir con la versión del archivo JAR de JDBC incluido en el agente. Haz una copia de seguridad del archivo ya que puede eliminarse durante actualizaciones principales del agente. -
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 tengas que especificar el nombre de la instancia de SQL Server (NombreDeHost\NombreDeInstancia).
- Nombre de la base de datos: Ingresa el nombre de la base de datos en el servidor con 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 de cadena de conexión adicionales, ingresa lo siguiente según tu controlador:
- SQL Server [ODBC]: Si usas el controlador "SQL Server [ODBC]" ingresa
integratedSecurity=true. Si esto no funciona, ingresaTrusted_Connection=yes. - ODBC Driver 11 for SQL Server [ODBC], SQL Server Native Client 10.0 [ODBC], SQL Server Native Client 11.0 [ODBC]: Si usas otro controlador de SQL Server, ingresa
Trusted_Connection=yes. - SQL Server jTDS [JDBC], SQL Server MS JDBC [JDBC]: Si usas un controlador JDBC de SQL Server ingresa
integratedSecurity=true.
- SQL Server [ODBC]: Si usas el controlador "SQL Server [ODBC]" ingresa
El driver ahora se autenticará como el usuario de dominio de Windows especificado arriba.
Autenticación de SQL Server
Ve a Jitterbit Studio y configura tu origen o destino de la manera normal. En la pantalla de definición de origen/destino bajo Parámetros de conexión, especifica lo siguiente:
-
Driver: El driver de SQL Server puede ser un driver ODBC o JDBC.
Nota
Al seleccionar un driver JDBC, recomendamos usar "SQL Server MS JDBC [JDBC]," el driver 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 tengas que especificar el nombre de la instancia de SQL Server (NombreDelHost\NombreDeLaInstancia).
-
Nombre de la base de datos: Ingresa el nombre de la base de datos en el servidor con la que Jitterbit necesita integrarse.
-
Usuario: 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 driver ahora se autenticará usando las credenciales de autenticación de SQL Server especificadas.
Cifrado de conexión y certificados de servidor
Las versiones actuales del driver SQL Server MS JDBC solicitan una conexión cifrada por defecto (encrypt=true) y validan el certificado que presenta el servidor de base de datos. Si el driver no puede validar el certificado del servidor contra el almacén de claves 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 rastrearse 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 esta validación, porque la falla es de confianza en lugar de cifrado.
La versión 12.8 del agente actualizó el driver JDBC de Microsoft SQL Server incluido. Microsoft cambió el valor predeterminado de encrypt de false a true en la versión 10.2 del driver 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 origen que funcionaba en un agente anterior a 12.8 puede comenzar a fallar después de la actualización.
Para resolver esto, expande Opciones e ingresa encrypt=false; en el campo Parámetros adicionales de cadena de conexión, o inclúyelo en la cadena de conexión si seleccionaste 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. Usa esta opción solo donde sea aceptable para los datos y la ruta de red involucrada.
Tu configuración de SQL Server puede requerir otras propiedades de conexión también. Para las propiedades que el driver admite, consulta Establecer las propiedades de conexión en la documentación de Microsoft.