Saltar al contenido

Solución de problemas de conectores en Jitterbit Studio

Esta guía cubre errores y comportamientos inesperados específicos de conectores individuales de Jitterbit Studio, organizados por conector. Solo enumera conectores con problemas conocidos específicos del conector que documentar, no todos los conectores disponibles. Para la lista completa de conectores, consulta Conectores. Comienza con los pasos de diagnóstico a continuación, luego encuentra tu conector en la sección relevante.

Para problemas no específicos de un conector, como una operación que no se ejecuta o un problema con una transformación, script o función, consulta Solución de problemas de operaciones. Para problemas de agentes privados, como un agente que está sin conexión, en mal estado o lento (lo que puede detener la ejecución de operaciones), consulta Solución de problemas de agentes privados.

Para una referencia unificada que cubra integración, automatización, gestión de API, EDI y problemas de desarrollo de aplicaciones en un solo lugar, consulta la guía de solución de problemas de Harmony.

Todas las entradas de solución de problemas en esta página

Pasos de diagnóstico

Estos pasos se aplican a la mayoría de los errores relacionados con conectores y son el punto de partida recomendado antes de investigar un error de conector específico.

Prueba la conexión

En la configuración de conexión, haz clic en el botón Test para confirmar que la conexión se realiza correctamente. Al hacer clic en Test también se descarga la versión más reciente del conector al agente, a menos que la política de organización Disable Auto Connector Update esté habilitada.

Actualiza los metadatos de conexión y los esquemas de actividad

Muchos problemas de conector, como objetos faltantes, una lista de campos desactualizada o un esquema que ya no coincide con el punto de conexión, se deben a metadatos en caché. Después de cualquier cambio en el lado del punto de conexión (campos nuevos, cambio de versión de API o cambio de permiso), reabre la actividad afectada y haz clic en el icono de actualización (Refresh) para recargar objetos y esquemas desde el punto de conexión.

Confirmar disponibilidad del conector y mantenerlo actualizado

La columna Disponibilidad del agente en la lista de conectores muestra si un conector requiere un agente privado.

Los conectores se lanzan y actualizan según el calendario de lanzamientos de Jitterbit, independientemente del agente. En agentes privados, probar una conexión descarga la versión más reciente del conector (consulta Probar la conexión arriba), a menos que esté habilitada la política de organización Disable Auto Connector Update. Para actualizar los conectores de un grupo de agentes en cualquier momento, incluso cuando esa política está habilitada, selecciona Acción > Actualizar conectores para el grupo en la página Agentes de la Consola de administración.

Habilitar registro detallado del conector

Cuando lo indique el soporte de Jitterbit, habilita el registro detallado del conector en el agente privado para capturar detalles a nivel de conector, luego reproduce el problema y revisa los registros. El registro detallado utiliza una entrada de registrador específica del conector; la línea exacta que se debe agregar a logback.xml se proporciona en la sección Solución de problemas de la página de documentación del conector, en Conectores.

Configuración de conexión

Propiedades de configuraciones avanzadas: Las variables que contienen JSON sin procesar deben escaparse

  • Síntoma: Muchos conectores incluyen una tabla Propiedades de configuraciones avanzadas para configuraciones de conexión opcionales. Las variables utilizadas en estos campos que contienen JSON sin procesar deben tener el JSON escapado; pasar JSON sin procesar sin escapar a través de una variable causa que el valor del campo sea incorrecto.
  • Causa posible: Los campos en la tabla Propiedades de configuraciones avanzadas no admiten variables que contengan objetos JSON sin escapar.
  • Resolución:
    • Antes de pasar contenido JSON a través de una variable a un campo Propiedades de configuraciones avanzadas, escapa el JSON. Por ejemplo, {"success": "true"} debe escaparse como {\"success\": \"true\"} antes de asignarlo a la variable.
    • Si ingresas el valor JSON directamente en el campo (no a través de una variable), no se requiere escapar.
    • Las variables en campos Propiedades de configuraciones avanzadas se rellenan en tiempo de ejecución solo en la versión del agente 10.75 / 11.13 o posterior. Si un valor de variable no aparece en tiempo de ejecución, confirma que el agente cumple con esta versión mínima.

Conector Amazon Bedrock

Amazon Bedrock: error de modelo "on-demand throughput isn't supported"

  • Síntoma: Una actividad de Amazon Bedrock falla con:

    Invocation of model ID <model-name> with on-demand throughput isn't supported. Retry your request with the ID or ARN of an inference profile that contains this model.

  • Causa posible: Algunos modelos solo están disponibles en regiones específicas y requieren un prefijo de región en el ID del modelo.

  • Resolución:
    1. Agrega el prefijo de región al ID del modelo. Por ejemplo, anthropic.claude-3-5-haiku-20241022-v1:0 se convierte en us-anthropic.claude-3-5-haiku-20241022-v1:0.
    2. Ingresa el ID del modelo con prefijo utilizando la opción Enter model identifier en la configuración de la actividad.

Conector Cloud Datastore

La actividad Delete Items reporta éxito pero no elimina el registro

  • Síntoma: Una actividad Delete Items de Cloud Datastore reporta éxito en el registro de operaciones, pero el registro de destino aún existe cuando se consulta después.
  • Causa posible: Delete Items identifica registros por el valor de Clave (o Clave alternativa) del almacenamiento, proporcionado en el array keys o ids de la solicitud. (Ambos arrays aceptan valores de clave o clave alternativa.) Si se proporciona el ID interno del registro en lugar de su valor de clave, ningún elemento coincide y la actividad reporta éxito sin eliminar nada.
  • Resolución:
    • En la transformación que prepara la solicitud de Delete Items, asigna el valor de Clave (o Clave alternativa) del almacenamiento, no el ID de registro interno.
    • Cuando encadenas desde una actividad Query Items, asigna el valor key de la respuesta de consulta a la solicitud de eliminación.

Conector Coupa

Coupa: La autenticación por clave API devuelve 403 Forbidden

  • Síntoma: Una operación del conector Coupa falla con un error Forbidden (403) al usar autenticación por clave API.
  • Causa posible: A partir de la versión R35 de Coupa (enero de 2023), las claves API de Coupa están deprecadas y ya no se admiten para la autenticación. Las conexiones configuradas para usar autenticación por clave API reciben un error 403.
  • Resolución:
    1. En la configuración de la conexión Coupa, cambia de autenticación por clave API a autenticación OAuth 2.0.
    2. En tu instancia de Coupa, crea una aplicación cliente OAuth 2.0 y obtén las credenciales del cliente.
    3. Actualiza la configuración de la conexión con las credenciales OAuth 2.0, guarda y vuelve a probar.

Conector de base de datos

Base de datos (JDBC): DBLookup o DBExecute falla con un error de decodificación Base64

  • Síntoma: Una función DBLookup o DBExecute dirigida a una base de datos PostgreSQL o SQL Server a través de un controlador JDBC falla en tiempo de ejecución con:

    Base64 decoding failed. Reason: error:00000000:lib(0)::reason(0)

    Esto ocurre siempre que el valor devuelto se parece a datos codificados en Base64, como un JWT u otro token de acceso, aunque la misma consulta se ejecute correctamente directamente contra la base de datos.

  • Causa posible: Las versiones del agente anteriores a la 12.9 pueden intentar incorrectamente decodificar en Base64 un valor de resultado JDBC que coincida con un patrón similar a Base64, independientemente de si el valor es realmente datos codificados en Base64.

  • Resolución:

    • Para agentes privados, actualiza a la versión 12.9 o posterior. Los agentes en la nube reciben la actualización automáticamente.
    • Si no puedes actualizar de inmediato, evita activar la verificación de Base64 convirtiendo el valor afectado a hexadecimal en la consulta SQL y luego decodificándolo en un paso de script usando HexToString. Por ejemplo, en PostgreSQL: SELECT encode(<column>, 'hex'). Usa el equivalente SQL decode(...,'hex') con StringToHex cuando escribas el valor de vuelta en la base de datos.

Base de datos (ODBC): Los caracteres multibyte no se manejan correctamente

  • Síntoma: Al leer o escribir en una base de datos a través del conector de base de datos usando un controlador ODBC, los caracteres multibyte o no ASCII (por ejemplo, caracteres acentuados o no latinos) no se manejan correctamente.
  • Causa posible: La compatibilidad con caracteres multibyte para el conector de base de datos sobre un controlador ODBC no está habilitada de forma predeterminada. La variable Jitterbit jitterbit.scripting.db.multibyte.enable debe establecerse en true. Esta compatibilidad está disponible en la versión del agente 12.6 y posterior, y no es necesaria cuando se usa un controlador JDBC.
  • Resolución:
    1. Confirma que el agente sea versión 12.6 o posterior.

    2. Establece la variable jitterbit.scripting.db.multibyte.enable en true antes de que se ejecute la operación de base de datos. Por ejemplo, en un paso de script:

      $jitterbit.scripting.db.multibyte.enable = true;

Alternativamente, usa un controlador JDBC para la conexión de base de datos, que maneja caracteres multibyte sin esta variable.

Base de datos: Conexión bloqueada por política de seguridad

  • Síntoma: Una prueba de conexión del conector de Base de datos falla con:

    HttpErrorResponse: The database connection could not be established due to a security policy violation.

    con una línea de detalles que nombra una conexión de loopback:

    Details: java.lang.IllegalArgumentException - JDBC connections to loopback addresses are not permitted.

    o un parámetro de cadena de conexión específico:

    Details: java.lang.IllegalArgumentException - JDBC connection parameter 'allowmultiqueries' cannot be enabled.

  • Causa posible: La versión 12.10 del agente y posteriores restringen ciertas conexiones de base de datos y parámetros de cadena de conexión por defecto, por seguridad. Esto incluye conexiones a localhost o 127.0.0.1, y parámetros de cadena de conexión específicos para los controladores MySQL, PostgreSQL, Oracle y SQL Server. Una conexión que funcionaba antes puede fallar después de actualizar un agente privado a la versión 12.10, porque la restricción se aplica por defecto aunque la sección [JdbcSecurity] no se agregue automáticamente a un archivo jitterbit.conf existente.

  • Resolución: En un agente privado, configura la sección [JdbcSecurity] del archivo de configuración del agente (jitterbit.conf) para permitir la conexión o parámetro específico que necesitas, luego reinicia el agente.

Base de datos: DBLookup o DBExecute falla con "No suitable driver found" al probar un script

  • Síntoma: Probar un script (usando Run test) que llama a DBLookup o DBExecute falla con:

    No suitable driver found for [...]

    El mismo script se ejecuta correctamente cuando se implementa y ejecuta en una operación.

  • Causa posible: La conexión de Base de datos utilizada por la función tiene su campo Login, Password o Connection String configurado con una variable global o de proyecto. Una prueba de script ejecuta solo el script probado, por lo que la variable aún no ha recibido su valor en tiempo de ejecución cuando la función resuelve la conexión. A diferencia de una variable referenciada en un campo configurado de la propia actividad, esto no está cubierto por el valor predeterminado de una variable; una función de base de datos no lee el valor predeterminado al resolver una conexión.

  • Resolución: Antes de la llamada a la función, asigna temporalmente a la variable global o de proyecto el mismo valor real directamente dentro del script probado (por ejemplo, $login = "value"; para una variable llamada login), luego elimina la asignación antes de implementar la operación.

Base de datos: Errores de longitud de campo en Insert, Update o Upsert

  • Síntoma: Una actividad Insert, Update o Upsert de Base de datos falla con un estado de operación Error cuando un valor de origen asignado es más largo de lo que permite la columna de destino. El registro de operación contiene uno de:

    One or more values were truncated when inserting and/or updating the field

    Field value too long
FieldName: m_site  Length: 3  Length Allowed: 1

  • Posible causa: Por defecto, si un valor de origen asignado excede la longitud definida de la columna de destino, la actividad rechaza la fila e informa un estado de Error en lugar de truncar el valor.

  • Resolución:
    1. En la configuración de la actividad Insert, Update o Upsert de Base de datos, habilita Allow truncation of character fields to avoid field length errors. Con esta opción habilitada, los valores que exceden la longitud del campo de destino se truncan y la operación informa un estado de Success with Info en lugar de un estado de Error.
    2. Si el truncamiento no es aceptable, recorta o transforma el campo de origen en la asignación de transformación para que los valores nunca excedan la longitud de la columna de destino, o amplía la columna de destino en el lado de la base de datos.
    3. Redeploy y vuelve a ejecutar la operación.

Base de datos: Archivo JAR del controlador JDBC sobrescrito en actualizaciones de agente

  • Síntoma: Los archivos JAR del controlador JDBC personalizado instalados para el conector de Base de datos se eliminan o sobrescriben cuando se actualiza el agente.
  • Posible causa: Solo se conserva el directorio <JITTERBIT_HOME>/tomcat/drivers/lib/ en las actualizaciones del agente. Los archivos JAR del controlador personalizado colocados en otros lugares en los directorios del agente forman parte de la implementación administrada y pueden eliminarse o sobrescribirse durante una actualización.
  • Resolución:
    • Coloca los archivos JAR del controlador JDBC personalizado en <JITTERBIT_HOME>/tomcat/drivers/lib/ en su lugar. Este directorio se conserva durante las actualizaciones del agente.
    • Si los controladores están actualmente en la ubicación incorrecta, muévelos al directorio correcto y reinicia el agente.

Base de datos: Los caracteres especiales en nombres de columnas causan fallos de consulta

  • Síntoma: Las consultas o transformaciones de Base de datos fallan cuando una tabla de origen tiene nombres de columnas que contienen caracteres especiales como @.
  • Posible causa: Los controladores ODBC no pueden manejar ciertos caracteres especiales en los nombres de columnas de la base de datos.
  • Resolución:
    1. Crea una vista de base de datos en la tabla física que exponga la columna afectada bajo un nombre que no contenga caracteres especiales.
    2. Apunta la actividad de Base de datos a la vista en lugar de la tabla original.

Base de datos: La instrucción SQL excede el límite de 2,000 caracteres

  • Síntoma: Una actividad Query de Base de datos falla o se trunca cuando la instrucción SQL configurada es muy larga.
  • Posible causa: El campo de instrucción SQL en una actividad Query de Base de datos acepta un máximo de 2,000 caracteres.
  • Resolución:
    1. Crea una vista de base de datos que encapsule la lógica de consulta compleja.
    2. Referencia el nombre de la vista en la actividad Query en lugar de la instrucción SQL completa.

IBM DB2 en iSeries: Falla de conexión JDBC

  • Síntoma: Una conexión de Base de datos a IBM DB2 en iSeries (AS/400 o IBM i) usando un controlador JDBC no se conecta.
  • Posible causa: Algunas conexiones a DB2 en iSeries usando un controlador JDBC encuentran problemas que no ocurren con un controlador ODBC.
  • Resolución: Cambia la conexión para usar un controlador ODBC en lugar de JDBC. Las conexiones ODBC solo se admiten en agentes privados.

IBM DB2: Configuración del controlador JCC JDBC (archivo JAR y licencia obsoletos)

  • Síntoma: Una conexión de Base de datos que utiliza el controlador IBM DB2 JCC JDBC falla con un error que hace referencia a una licencia faltante, o falla o produce errores de compatibilidad con versiones más recientes de DB2.
  • Posibles causas:
    • El archivo de controlador db2jcc.jar implementa la especificación JDBC 3 obsoleta. El db2jcc4.jar actual implementa JDBC 4, que las versiones más recientes de DB2 requieren.
    • El controlador JCC requiere un archivo JAR de licencia separado. El archivo JAR del controlador por sí solo no es suficiente.
  • Resolución:
    • Utiliza el controlador db2jcc4.jar, no el obsoleto db2jcc.jar. Instálalo en <JITTERBIT_HOME>/tomcat/drivers/lib/ en el agente privado.
    • Obtén el archivo JAR de licencia de IBM (denominado db2jcc_license_cisuz-XX.jar, donde XX es el número de versión) y cópialo a <JITTERBIT_HOME>/tomcat/shared/lib/.
    • Alternativamente, utiliza la biblioteca de código abierto JTOpen (también conocida como controlador AS400), que no requiere el controlador JCC ni un archivo de licencia.

Kerberos: "Could not initialize class KerbAuthentication"

  • Síntoma: Una conexión de Base de datos que utiliza autenticación Kerberos falla con:

    Could not initialize class com.microsoft.sqlserver.jdbc.KerbAuthentication

  • Posible causa: Los archivos de configuración de Kerberos en el host del agente no tienen los permisos de archivo correctos.

  • Resolución:

    1. En el host del agente privado, establece los permisos de archivo en los archivos de configuración de Kerberos (jaas.conf, krb5.conf y el archivo de caché de tickets de Kerberos) en 644:

      chmod 644 jaas.conf krb5.conf krb5cc_agent

    2. Reinicia el agente después de aplicar los cambios de permisos.

Kerberos: Errores JGSS o GSS durante la prueba de conexión

  • Síntoma: Una conexión de Base de datos que utiliza autenticación Kerberos falla con errores que hacen referencia a jgss o gss.
  • Posible causa: La JVM está configurada con -Dsun.security.jgss.native=true, que la dirige a utilizar la biblioteca GSSAPI nativa del sistema operativo. En algunos sistemas, esto entra en conflicto con la configuración de Kerberos.
  • Resolución:
    1. Elimina el parámetro -Dsun.security.jgss.native=true de los argumentos de JVM del agente.
    2. En krb5.conf, añade udp_preference_limit = 1 bajo la sección [libdefaults] para forzar TCP en lugar de UDP para el tráfico de Kerberos.
    3. Reinicia el agente.

Microsoft Excel: "Operation must use an updateable query"

  • Síntoma: Una actividad de Inserción o Actualización de Base de datos dirigida a un archivo de Microsoft Excel (a través de ODBC) falla con:

    [Microsoft][ODBC Excel Driver] Operation must use an updateable query

  • Posible causa: El controlador ODBC de Excel abre el archivo de Excel en modo de solo lectura de forma predeterminada a menos que la cadena de conexión establezca explícitamente el modo de lectura/escritura.

  • Resolución: En el campo Cadena de conexión de la conexión de Base de datos (ingresado en Configuración opcional con Usar cadena de conexión seleccionado), añade ReadOnly=0; al final de la cadena de conexión para abrir el archivo de Excel en modo de lectura/escritura.

MySQL: Acceso denegado a pesar de credenciales correctas

  • Síntoma: La conexión a una base de datos MySQL mediante el conector de base de datos falla con:

    Access denied for user 'root'@'%' to database 'test'

    incluso cuando el nombre de usuario y la contraseña son correctos.

  • Causa posible: MySQL puede otorgar permisos diferentes según la dirección IP del cliente. Una cuenta de usuario puede tener los privilegios requeridos desde direcciones IP específicas, pero no desde la dirección IP del agente privado.

  • Resolución:

    • En MySQL, verifica que la cuenta de usuario tenga los permisos necesarios para conexiones desde la dirección IP del agente privado. La sintaxis exacta de permisos varía según la versión de MySQL (consulta la documentación de MySQL o contacta a tu administrador de MySQL), pero generalmente toma la forma:

      GRANT ALL ON database.* TO 'user'@'agent-ip';

    • Prueba la conectividad usando un cliente MySQL instalado directamente en el host del agente para determinar si el problema es de red o específico de Jitterbit.

MySQL: Habilitar Batch no mejora el rendimiento de Insert o Update

  • Síntoma: Una actividad Insert o Update de base de datos que usa el controlador JDBC de MySQL muestra poco o ningún mejora de rendimiento después de habilitar Enable Batch, incluso con un gran número de registros.
  • Causa posible: Por defecto, el controlador JDBC de MySQL (Connector/J) envía una declaración por fila independientemente de Enable Batch, en lugar de un lote verdadero del lado del servidor.
  • Resolución: En el campo Additional Connection String Parameters de la conexión, agrega rewriteBatchedStatements=true.

MySQL: Controlador ODBC no aparece en el menú desplegable de Studio

  • Síntoma: Al configurar una conexión de base de datos a MySQL usando un controlador ODBC en un agente privado, el controlador instalado no aparece en el menú desplegable Driver en Studio.
  • Causa posible: El administrador ODBC en el host del agente privado no muestra el controlador, generalmente debido a una incompatibilidad entre 32 bits y 64 bits o una instalación incompleta del controlador.
  • Resolución:
    • En el host del agente privado (Windows), abre Data Sources (ODBC) (en Administrative Tools) y confirma que el controlador ODBC de MySQL aparece en la lista. Para opciones de controlador de MySQL, consulta Conectar a MySQL.
    • Confirma que el agente se conecta a la máquina correcta: el controlador ODBC debe estar instalado en el host del agente, no en la máquina del usuario de Studio.

PostgreSQL: Error de incompatibilidad de codificación del cliente

  • Síntoma: Una prueba de conexión del conector de base de datos a PostgreSQL falla con un error de "incompatibilidad de codificación del cliente".
  • Causa posible: La codificación que usa el servidor PostgreSQL difiere de la codificación predeterminada que asume el controlador ODBC de PostgreSQL.
  • Resolución:
    • En la configuración de conexión de base de datos, agrega ConnSettings=SET CLIENT_ENCODING to 'LATIN1' (sustituyendo la codificación real del servidor) al campo Additional Connection String Parameters.
    • En Windows, si el servidor usa una codificación cirílica como WIN1251, también establece la codificación del cliente a WIN1251 en la configuración del controlador ODBC.

PostgreSQL: Usar el controlador proporcionado por Jitterbit en Linux

  • Síntoma: Las operaciones que utilizan el conector de Base de datos para conectarse a PostgreSQL desde un agente privado en Linux fallan o producen errores, incluso cuando parece que hay un controlador instalado.
  • Causa posible: Muchas distribuciones de Linux incluyen un controlador ODBC de PostgreSQL empaquetado con unixODBC que no funciona de manera confiable con Harmony.
  • Resolución: No utilices el controlador PostgreSQL empaquetado por la distribución. En su lugar, utiliza el controlador ODBC de PostgreSQL incluido en la instalación del agente Jitterbit.

SQL Server JDBC: Falla la autenticación integrada de Windows

  • Síntoma: Para agentes privados, una conexión de Base de datos a SQL Server mediante un controlador JDBC y autenticación integrada de Windows falla con:

    This driver is not configured for integrated authentication. ClientConnectionId:...

    Los registros del agente también pueden mostrar:

    java.lang.UnsatisfiedLinkError: no mssql-jdbc_auth-8.2.0.x64 in java.library.path

  • Causas posibles:

    • Falta el archivo DLL mssql-jdbc_auth requerido para la autenticación integrada de Windows en los directorios de JRE que utiliza el agente Jitterbit en tiempo de ejecución. Colocar el archivo DLL en el mismo directorio que el archivo JAR de JDBC no es suficiente.
    • La cadena de conexión no incluye el parámetro integratedSecurity=true.

  • Resolución:

    1. En el host del agente privado, copia mssql-jdbc_auth-x.x.x.x64.dll (de la distribución del controlador JDBC, utilizando la versión que coincida con el archivo JAR de JDBC incluido en tu agente) en <JITTERBIT_HOME>/jre/bin y <JITTERBIT_HOME>/jre/lib. Realiza una copia de seguridad del archivo, ya que puede eliminarse durante actualizaciones principales del agente.
    2. En la configuración de conexión de Base de datos, agrega integratedSecurity=true al campo Parámetros adicionales de cadena de conexión.
    3. Reinicia el servicio del agente Jitterbit.

Autenticación de Windows en SQL Server: Privilegios insuficientes

  • Síntoma: Una conexión de Base de datos que utiliza autenticación de Windows en SQL Server falla incluso cuando las credenciales de dominio parecen correctas.
  • Causa posible: El usuario del dominio de Windows que ejecuta el servicio del agente Jitterbit carece de los privilegios a nivel de sistema operativo requeridos para la Seguridad Integrada de Windows.
  • Resolución:
    1. Otorga al usuario del dominio los privilegios de Windows Iniciar sesión como servicio y Actuar como parte del sistema operativo en el host del agente privado.
    2. Confirma que el usuario del dominio tiene permisos de lectura y escritura en el directorio de instalación del agente Jitterbit.
    3. Reinicia el servicio del agente Jitterbit después de aplicar los cambios de privilegios.

SQL Server: "No se puede insertar un valor explícito para la columna de identidad" al insertar en una columna de identidad

  • Síntoma: Una operación del conector de Base de datos que escribe en una tabla de SQL Server con una columna de identidad falla con:

    Database Error: Cannot insert explicit value for identity column in table '<table>' when IDENTITY_INSERT is set to OFF.

  • Causa posible: La columna de identidad se incluye en la instrucción INSERT que genera el conector de Base de datos para el destino. SQL Server rechaza un INSERT que hace referencia a una columna de identidad en su lista de columnas (con un valor explícito o nulo) mientras IDENTITY_INSERT está establecido en OFF. Asignar el campo a un valor nulo no lo excluye: un campo de destino se omite del INSERT solo cuando se asigna con la función Unmap.

  • Resolución:
    • Para permitir que SQL Server asigne el valor de identidad automáticamente, excluye la columna del INSERT asignando el campo de destino de identidad con la función Unmap. Para excluir la columna solo cuando el origen no proporciona un valor, utiliza una asignación condicional:
If($source.id != "", $source.id, Unmap())

Cuando la condición es falsa, Unmap elimina la columna del INSERT y SQL Server asigna el siguiente valor de identidad. (Si se proporciona un valor explícito en la rama verdadera, aún se requiere que IDENTITY_INSERT esté ON; consulta la siguiente opción.)

  • Si es necesario insertar valores explícitos en la columna de identidad, establece IDENTITY_INSERT en la tabla de destino en los scripts previos y posteriores a SQL dentro de la actividad:

    SET IDENTITY_INSERT <table> ON;

    SET IDENTITY_INSERT <table> OFF;

    Utiliza esta opción solo cuando desees controlar intencionalmente los valores de identidad desde fuera de la base de datos. Permite insertar valores explícitos en la columna de identidad.

SQL Server: La conexión falla con un error de certificado PKIX

  • Síntoma: Una conexión de Base de datos a SQL Server falla con:

    "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.

    Una conexión que funcionaba anteriormente puede comenzar a fallar después de una actualización del agente a la versión 12.8 o posterior.

  • Causa posible: Las versiones actuales del controlador SQL Server MS JDBC solicitan una conexión cifrada de forma predeterminada y validan el certificado que presenta el servidor de base de datos. La conexión falla cuando ese certificado no se puede rastrear hasta una autoridad de certificación (CA) que el agente ya confía, como un certificado autofirmado, un certificado emitido internamente o el certificado de CA de Amazon RDS que presenta una instancia de Amazon RDS para SQL Server. Se trata de un fallo de confianza de certificado y no de cifrado, por lo que una base de datos puede tener el cifrado habilitado y un certificado válido instalado y aún así fallar. La versión 12.8 del agente actualizó el controlador incluido a una versión que solicita cifrado de forma predeterminada, por lo que una conexión configurada antes de esa actualización puede fallar después.

  • Resolución: Ingresa encrypt=false; en el campo Parámetros adicionales de cadena de conexión bajo Configuración opcional de la conexión de Base de datos, o inclúyelo en una cadena de conexión manual. Esto funciona en agentes en la nube y privados. Para obtener más información, consulta Cifrado de conexión y certificados de servidor.

    Precaución

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

Conector EDI for Cloud v2

Las entradas de solución de problemas para el conector EDI for Cloud v2 se documentan en la guía de solución de problemas de EDI, junto con problemas de Jitterbit EDI. Las entradas relevantes incluyen:

Conector de correo electrónico

La prueba de conexión de Gmail falla con error de autenticación

  • Síntoma: Una prueba de conexión a una cuenta de Gmail usando Autenticación Básica falla con un error de autenticación, incluso cuando se ingresa la contraseña correcta de la cuenta de Google.
  • Causa posible: Google requiere una contraseña de aplicación para cuentas con Verificación en 2 pasos habilitada. La contraseña de la cuenta de Google no es aceptada por SMTP o IMAP cuando la Verificación en 2 pasos está activa; solo se aceptan contraseñas de aplicación.
  • Resolución:
    1. En la cuenta de Google, genera una contraseña de aplicación para la aplicación Jitterbit (consulta la página de Google Iniciar sesión con contraseñas de aplicación).
    2. En la configuración de conexión de correo electrónico en Studio, ingresa la contraseña de aplicación en el campo Contraseña SMTP y/o Contraseña IMAP en lugar de la contraseña de la cuenta de Google.

La firma S/MIME falla o es rechazada por proveedores de correo electrónico en la nube

  • Síntoma: Los correos electrónicos configurados con firma S/MIME no se envían, son rechazados por el servidor del destinatario, o llegan sin firmar cuando se usa un proveedor de correo electrónico en la nube como Microsoft 365 o Exchange Online.
  • Causas posibles:
    • Los proveedores en la nube requieren un certificado S/MIME emitido por una autoridad de certificación (CA) de confianza. Los certificados autofirmados no son aceptados por proveedores en la nube como Microsoft 365 (Exchange Online).
    • S/MIME es funcional solo cuando se usan agentes privados. Si la operación se ejecuta en un agente en la nube, la firma S/MIME no se aplica independientemente del tipo de certificado.
  • Resolución:
    1. Obtén un certificado S/MIME de una CA de confianza. Let's Encrypt proporciona certificados gratuitos aceptados por los principales proveedores en la nube.
    2. Reemplaza el certificado autofirmado en la actividad Enviar correo electrónico de correo electrónico con el certificado emitido por la CA (consulta Requisitos previos para cifrado S/MIME).
    3. Para agentes privados, confirma que el certificado se importó correctamente en el almacén de confianza predeterminado del agente. Para agentes en la nube, la firma S/MIME no es compatible.

La conexión de correo electrónico de Microsoft 365 usando autenticación ROPC falla cuando MFA está habilitado

  • Síntoma: Una conexión OAuth 2.0 de Microsoft 365 que usa la concesión de Credenciales de Propietario de Recurso (ROPC) falla en la autenticación, incluso cuando el nombre de usuario, contraseña, ID de cliente, ID de inquilino y secreto de cliente son todos correctos.
  • Causa posible: La autenticación ROPC requiere que la autenticación multifactor (MFA) esté deshabilitada para las credenciales de Microsoft 365 usadas con el conector. La concesión ROPC no puede satisfacer un desafío de MFA, por lo que la solicitud de token falla cuando se aplica una política de MFA a la cuenta.
  • Resolución:
    • Usa una cuenta de Microsoft 365 cuyas credenciales no estén sujetas a una política de MFA. Para mantener la seguridad, crea un inquilino o directorio dedicado de Microsoft Entra ID que no aplique MFA, como se describe en Requisitos previos para Microsoft 365.
    • Si no se puede quitar MFA de la cuenta, usa un método de autenticación compatible diferente para la conexión en lugar de ROPC.

El envío de correo electrónico falla cuando la misma dirección aparece en múltiples campos de destinatarios

  • Síntoma: Una actividad Enviar correo electrónico de Correo electrónico falla en tiempo de ejecución cuando la misma dirección de correo electrónico está presente en más de uno de los campos Para, CC o BCC.
  • Causa posible: El conector de correo electrónico no permite que la misma dirección aparezca en múltiples campos de destinatarios en una única solicitud de envío. Esto se aplica a las direcciones configuradas directamente en la actividad y a las direcciones suministradas dinámicamente a través de una asignación de transformación.
  • Resolución:
    • Revisa los campos Para, CC y BCC en la configuración de la actividad y en cualquier asignación de transformación de la actividad para confirmar que ninguna dirección aparezca en más de un campo.
    • Si las listas de destinatarios se ensamblan dinámicamente usando variables o scripts, agrega una verificación de deduplicación antes de pasar las direcciones a la actividad.

Conectores de Epicor

Epicor Prophet 21: La operación falla en tiempo de ejecución con múltiples condiciones de filtro

  • Síntoma: Una actividad Consulta de Epicor Prophet 21 falla en tiempo de ejecución cuando la Cadena de filtro contiene más de una condición de filtro, aunque la actividad parezca válida en Studio.
  • Causa posible: Una limitación en la API de Middleware de Epicor Prophet 21 impide que se procesen múltiples condiciones de filtro. La operación parece válida en Studio pero falla en tiempo de ejecución cuando hay más de un filtro presente.
  • Resolución:
    • Reduce la Cadena de filtro a una única condición de filtro.
    • Si se necesitan múltiples condiciones de filtro, recupera un conjunto de resultados más amplio usando un único filtro y aplica el filtrado adicional en un paso de transformación o script después de la actividad.

Conectores de archivo

FTP, Recurso compartido de archivos y Almacenamiento local: "Ningún archivo coincide con el filtro de archivo" en pasos de archivo o seguimiento

  • Síntoma: Una actividad de lectura de FTP, Recurso compartido de archivos o Almacenamiento local falla porque el archivo que espera leer ya no está en la ruta de origen:

    Failed to read file from the source "Read". Reason: No files match the file filter "<filter>".

    La actividad que procesó previamente el archivo tuvo éxito; la falla ocurre en un paso posterior (a menudo un paso de archivo o notificación) que intenta leer el mismo archivo con el mismo filtro.

  • Causas posibles:

    • La actividad de procesamiento ya movió o eliminó el archivo de origen como parte de su comportamiento Después del procesamiento, por lo que el paso de archivo no tiene nada que coincida.
    • Se lanza una operación secundaria de forma asincrónica y la operación principal intenta leer el archivo de salida de la secundaria antes de que haya terminado de escribirlo.
    • Una actividad Escribir de FTP con Usar cambio de nombre de FTP habilitado (el valor predeterminado) escribe el archivo con un nombre temporal y lo renombra al nombre final al completarse. Una operación de lectura posterior que se ejecute antes de que se complete el cambio de nombre no encontrará el archivo.
  • Resolución:
    • Confirma si el paso anterior ya manejó el archivo a través de sus opciones integradas Después del procesamiento (mover, renombrar, eliminar). Si es así, un paso de archivo separado es redundante y debe eliminarse.
    • Si se requiere un paso de archivo separado, rediseña la cadena para que el procesamiento y el archivo ocurran contra la misma referencia de archivo en memoria en lugar de releer desde el origen. Por ejemplo, pasa el contenido leído a través del Almacenamiento temporal al paso de archivo en lugar de releer la ruta de origen.
    • Si un paso posterior lee la salida producida por una operación secundaria, ejecuta la secundaria de forma sincrónica para que su salida exista antes de la lectura. Establece el Tipo de ejecución de la herramienta Invocar operación en Sincrónico, o, cuando llames a la operación desde un script, ejecuta RunOperation de forma sincrónica (el valor predeterminado). Insertar un retraso fijo (por ejemplo, con la función Sleep) agrega latencia y no garantiza que el archivo esté listo.
    • Si una actividad Escribir de FTP está escribiendo en la misma ubicación, verifica si Usar cambio de nombre de FTP está habilitado en la actividad Escribir de FTP. Si la lectura posterior se ejecuta antes de que se complete el cambio de nombre, deshabilita Usar cambio de nombre de FTP en la actividad de escritura, o asegúrate de que la operación de lectura no se ejecute hasta que la operación de escritura se haya completado completamente.

FTP, File Share y Local Storage: Carpeta de error no escrita en caso de fallo de conexión

  • Síntoma: Después de que falla una actividad de FTP, File Share o Local Storage, no aparece ningún archivo en la carpeta de error configurada.
  • Causa posible: La carpeta de error está diseñada para archivar una copia del archivo de origen después del procesamiento fallido, por lo que captura archivos solo cuando la actividad se ejecuta y luego falla (por ejemplo, un error de permiso de escritura en el servidor). Si no se puede establecer la conexión con el servidor en absoluto, la operación falla antes de que la actividad lea algún archivo, por lo que no hay archivo para escribir en la carpeta de error.
  • Resolución:
    • Si la carpeta de error está vacía después de un fallo, consulta los registros de operación para ver si hay un error a nivel de conexión (como un fallo de autenticación o un mensaje de host inaccesible).
    • Usa el botón Test en la conexión para confirmar si el problema está a nivel de red o autenticación.

FTP, File Share y Local Storage: Palabras clave de nombre de archivo no resueltas en rutas de carpeta de éxito y error

  • Síntoma: Las operaciones mueven archivos a carpetas de éxito o error después del procesamiento, pero la ruta de destino incluye texto de palabra clave sin expandir en lugar de valores resueltos. La operación puede fallar o escribir archivos en ubicaciones inesperadas.
  • Causas posibles:
    • Los campos de ruta de carpeta de éxito y carpeta de error en actividades de FTP, File Share y Local Storage no admiten sustitución de palabras clave de nombre de archivo. Las variables no se expanden en estos campos.
    • Estos campos hacen referencia a directorios en la máquina del agente privado, no en el servidor remoto. Las rutas relativas se interpretan en relación con el sistema de archivos del host del agente.
  • Resolución:
    • Usa solo rutas literales (sin variables de palabras clave de nombre de archivo) para los campos de carpeta de éxito y error.
    • Si se requieren rutas dinámicas, agrega un paso de script después de la actividad para mover o renombrar el archivo procesado a la ubicación deseada usando funciones de archivo.

FTP, File Share, Local Storage y Temporary Storage: Write Headers no produce un archivo solo con encabezados cuando el origen no devuelve registros

  • Síntoma: Una actividad de escritura basada en archivos con la opción Write Headers habilitada (FTP Write, File Share Write, Local Storage Write o Temporary Storage Write) no escribe encabezados cuando el origen no devuelve registros. Se crea un archivo vacío o no se crea ningún archivo (si también está seleccionado Do not create empty files).
  • Causa: Este es el comportamiento esperado. Los encabezados se escriben como parte de la salida de transformación, y la transformación se ejecuta solo cuando el origen devuelve al menos un registro. Cuando el origen no devuelve registros, se omite la transformación, por lo que no se escribe ninguna salida (incluidos los encabezados), y Studio registra una advertencia de que el origen está vacío. Esto no es específico de un conector de origen particular o un destino de archivo plano.

FTP: La operación falla después de muchos inicios de sesión rápidos en el mismo servidor

  • Síntoma: Una operación que utiliza el conector FTP (sobre el protocolo FTP o SFTP) que se autentica en el mismo servidor muchas veces en rápida sucesión (por ejemplo, leyendo cientos de archivos pequeños dentro de un bucle, u muchas operaciones ejecutándose contra el mismo servidor en una programación) eventualmente falla con una negación de inicio de sesión o error de conexión. La misma operación se ejecuta correctamente bajo una carga más ligera.
  • Posibles causas:
    • El conector FTP abre y autentica una nueva conexión para cada ejecución de actividad y la cierra cuando termina la operación; una sesión no se reutiliza entre actividades, entre ejecuciones de operaciones o entre proyectos. Esto es por diseño. Cuando muchas operaciones se ejecutan contra el mismo servidor, por ejemplo varias operaciones programadas o múltiples proyectos dirigidos al mismo host, cada ejecución se autentica de forma independiente.
    • El servidor remoto está configurado con un número máximo de conexiones, autenticaciones por minuto o sesiones concurrentes por usuario, y la tasa de inicio de sesión combinada de Jitterbit excede ese límite.
  • Resolución:
    • Cuando sea posible, rediseña la operación para realizar menos conexiones. Reemplaza una actividad de Lectura dentro de un bucle con una única actividad de Lectura que utiliza un comodín en el campo Obtener archivos (por ejemplo, *.xml o data_*.csv), luego divide los datos recuperados en registros individuales dentro de una transformación.
    • Si la operación debe procesar archivos uno a la vez, solicita al administrador del servidor FTP que aumente el límite por usuario de conexiones concurrentes o autenticaciones por minuto.

SFTP "Inicio de sesión denegado. Error de autenticación." al utilizar claves SSH

  • Síntoma: Una operación SFTP que utiliza autenticación de clave privada SSH falla con Inicio de sesión denegado. Error de autenticación., aunque las mismas claves se autentican correctamente desde un cliente SFTP interactivo.

    Failed to get ftp directory list for url sftp://example.com:22/. Login denied. Authentication failure.

  • Posibles causas:

    • La clave privada está protegida por una frase de contraseña, pero falta la configuración PrivateKeyPassphrase en la sección [SSH] del jitterbit.conf del agente.
    • Se configura una contraseña en el endpoint FTP junto con la clave privada. La presencia de una contraseña en la configuración del endpoint interfiere con la autenticación basada en claves.

  • Resolución:

    • Para agentes privados, confirma que la sección [SSH] de jitterbit.conf contiene la ruta correcta de PrivateKeyFile y, si la clave está protegida por frase de contraseña, el valor correspondiente de PrivateKeyPassphrase (consulta Conectarse a SFTP con claves SSH).
    • En la configuración del endpoint FTP, borra el campo Contraseña cuando la autenticación es por clave SSH.
    • Confirma que la clave está en un formato que el agente admite (OpenSSH). Convierte la clave con ssh-keygen si está en formato PuTTY (.ppk) u otro formato que no sea OpenSSH.

FTP Write: "Usar cambio de nombre FTP" falla al escribir en un servidor SFTP

  • Síntoma: Una actividad de Escritura en FTP configurada con la opción Usar cambio de nombre FTP falla cuando el destino es un servidor SFTP, con un error similar a:

    Failed to put ... to the url ...
Quote command returned error. Rename command failed: <reason>.

    El <reason> es típicamente No such file or directory, o Permission denied para un archivo cuyo nombre contiene caracteres multibyte.

  • Posibles causas:

    • En agentes anteriores a la versión 11.56, la opción Usar cambio de nombre FTP no respetaba de forma confiable el paso de cambio de nombre al escribir en un servidor SFTP, particularmente en operaciones de patrón de archivo.

  • El nombre de archivo contiene caracteres multibyte y el servidor SFTP no admite renombrar archivos cuyos nombres los contienen. A partir de la versión 12.8 del agente, el conector FTP puede leer y escribir archivos con nombres multibyte (excepto en agentes privados de Windows a partir de la versión 12.10; consulta Codificación de caracteres y soporte multibyte); sin embargo, con Use FTP Rename el agente carga el archivo con un nombre temporal (sufijo -jbupload) y luego lo renombra al nombre final, y si el servidor no puede renombrar el nombre multibyte devuelve un Permission denied engañoso. Los nombres de archivo que utilizan solo caracteres ASCII no se ven afectados. Esta es una limitación del servidor SFTP, no de Jitterbit.

  • Resolución:

    • Asegúrate de que el agente sea versión 11.56 o posterior, donde Use FTP Rename con SFTP funciona como se espera. Los agentes en la nube se actualizan automáticamente; actualiza los agentes privados si es necesario.

    • Desactiva la casilla Use FTP Rename en la configuración de la actividad para que el agente escriba directamente en la ruta de destino en lugar de cargar con un nombre temporal y renombrar. Esto evita el paso de renombrado y resuelve ambas causas.

    • Para el caso multibyte, alternativamente utiliza un servidor SFTP que admita renombrar archivos cuyos nombres contienen caracteres multibyte.

SFTP: No se admite agregar contenido a archivo

  • Síntoma: Una actividad Write de FTP configurada con la opción Append To File no agrega contenido al archivo existente cuando el destino es un servidor SFTP.
  • Posible causa: El protocolo SFTP no admite agregar contenido a archivos existentes. Esta es una limitación a nivel de protocolo, no un problema de configuración de Jitterbit.
  • Resolución:
    • Utiliza FTP o FTPS si se requiere el comportamiento de agregar contenido.
    • Si SFTP es obligatorio, implementa la lógica de agregar contenido manualmente: lee el contenido del archivo existente, combínalo con los datos nuevos y escribe el resultado completo como un archivo completo.

FTP: Los nombres de archivo que contienen # no se manejan correctamente

  • Síntoma: Una actividad del conector FTP (sobre el protocolo FTP o SFTP) falla cuando el nombre de archivo de origen o destino contiene un carácter hash (#). Leer el archivo devuelve un error como No File with that name o Error in SSH Layer, y escribir el archivo produce un nombre de archivo truncado.
  • Posible causa: El conector FTP trata la ruta del archivo como una URL, en la cual el carácter hash es un delimitador de fragmento reservado. El conector analiza la parte de la ruta antes del # y descarta el resto.
  • Resolución:
    • Renombra los archivos para eliminar o reemplazar el carácter # antes de que Jitterbit los lea o escriba.
    • Para que el conector codifique en URL los nombres que contienen caracteres especiales como #, establece jitterbit.source.ftp.encode_url en true en un script de transformación para nombres de archivo o carpeta de origen, y jitterbit.target.ftp.encode_url en true para archivos escritos en el destino.

File Share: Las rutas UNC con nombres de servidor fallan en agentes en la nube

  • Síntoma: Las conexiones de File Share que utilizan rutas UNC (por ejemplo, \\server\share) fallan al conectarse cuando la operación se ejecuta en un agente en la nube.
  • Posible causa: Los agentes en la nube pueden resolver rutas UNC utilizando una dirección IP pública pero no pueden resolver nombres de host de servidor en rutas UNC.
  • Resolución:
    • Reemplaza el nombre del servidor en la ruta UNC con la dirección IP pública del servidor (por ejemplo, \\192.0.2.1\share).
    • Si se requiere la resolución de nombres de servidor en rutas UNC, utiliza un agente privado en su lugar.

File Share: Los archivos más grandes que 2 GB pueden fallar al recuperarse

  • Síntoma: Una actividad Read de File Share puede fallar al recuperar archivos individuales más grandes que 2 GB. Los archivos más pequeños se recuperan sin problema.
  • Causa posible: El conector File Share tiene una limitación conocida con archivos individuales más grandes que 2 GB.
  • Resolución: No existe una opción de configuración que elimine este límite. Como solución alternativa, divide el archivo en segmentos más pequeños en la fuente para que cada archivo sea menor a 2 GB antes de que la actividad Read de File Share lo recupere.

Local Storage: No disponible en agentes en la nube

  • Síntoma: Una operación que utiliza un conector Local Storage falla cuando se ejecuta en un agente en la nube.
  • Causa posible: Local Storage accede al sistema de archivos de la máquina donde está instalado el agente. Los agentes en la nube se ejecutan en un entorno alojado y no exponen un sistema de archivos local para este propósito.
  • Resolución:
    • Utiliza agentes privados para cualquier operación que requiera el conector Local Storage. Local Storage está deshabilitado en agentes privados de forma predeterminada, así que también habilítalo en el archivo de configuración del agente privado (consulta Enable local file location).
    • Para flujos de trabajo de agentes en la nube, reemplaza Local Storage con Temporary Storage o un conector de almacenamiento externo (File Share, FTP o Cloud Datastore).

Temporary Storage: Archivos faltantes cuando los lee una operación posterior

  • Síntoma: Los archivos de Temporary Storage escritos por una operación faltan cuando una operación posterior intenta leerlos.
  • Causas posibles:
    • El servicio de limpieza de Harmony elimina archivos de Temporary Storage después de 24 horas de forma predeterminada.
    • Cada agente en un grupo de agentes tiene su propio Temporary Storage local. Se garantiza que las operaciones en la misma cadena de operaciones se ejecuten en el mismo agente, pero una operación posterior que no esté en la misma cadena puede enviarse a un agente diferente y acceder a una instancia diferente de Temporary Storage, por lo que no encuentra el archivo, independientemente de la ventana de 24 horas. Consulta Important notes.
  • Resolución:
    • Vincula las operaciones que deben compartir archivos de Temporary Storage en la misma cadena de operaciones utilizando acciones de operaciones, donde el comportamiento de Temporary Storage es consistente y confiable.
    • Para agentes privados, la frecuencia de limpieza se puede ajustar en la sección [FileCleanup] de jitterbit.conf. Consulta [FileCleanup].
    • Si los archivos no se pueden consumir dentro de la misma cadena o deben persistir más de 24 horas, utiliza un conector de almacenamiento persistente accesible para todos los agentes (como File Share, FTP o Cloud Datastore) en lugar de Temporary Storage.

Temporary Storage: Caracteres restringidos en rutas de archivo

  • Síntoma: Una actividad Read o Write de Temporary Storage falla cuando la ruta del archivo contiene ciertos caracteres especiales.
  • Causa posible: Los siguientes caracteres no son compatibles en rutas de archivo de Temporary Storage: ~, %, $, ", <, >, :, ?
  • Resolución:
    • Elimina o reemplaza los caracteres no compatibles en la ruta del archivo. Los siguientes caracteres son compatibles: !, @, #, ^, &, *, (, ), [, ], ', ;
    • Tanto / como \ se aceptan como separadores de ruta.

Almacenamiento temporal: límite de tamaño de archivo de 50 GB en agentes en la nube

  • Síntoma: Una actividad de Almacenamiento temporal Escribir falla al escribir archivos grandes a través de un agente en la nube.
  • Causa posible: Los agentes en la nube imponen un tamaño máximo de archivo de 50 GB por archivo para Almacenamiento temporal.
  • Resolución:
    • Utiliza un agente privado para flujos de trabajo que necesiten escribir archivos individuales mayores a 50 GB en Almacenamiento temporal.
    • Si solo hay agentes en la nube disponibles, divide conjuntos de datos grandes en múltiples archivos menores a 50 GB antes de escribir en Almacenamiento temporal.

Conector HTTP

HTTP v2: El encabezado de autorización duplicado causa error 400 Bad Request

  • Síntoma: Las operaciones del conector HTTP v2 fallan con un error 400 cuando se configuran tanto la autenticación a nivel de conexión como un encabezado de solicitud Authorization definido manualmente en la misma conexión o actividad.
  • Causa posible: Cuando se configura la autenticación en una conexión HTTP v2 (por ejemplo, Basic u OAuth), el conector agrega automáticamente un encabezado Authorization a cada solicitud. Agregar un segundo encabezado Authorization manualmente resulta en dos encabezados conflictivos, que la mayoría de los servidores rechaza con un error 400.
  • Resolución:
    • Elimina cualquier encabezado Authorization agregado manualmente de los encabezados de solicitud en la configuración de la actividad o conexión.
    • Utiliza solo la configuración de autenticación integrada en la conexión para manejar la autorización. No agregues un encabezado Authorization manual junto con la autenticación configurada.
    • Si necesitas establecer el encabezado Authorization dinámicamente a nivel de actividad, establece el tipo de autenticación de la conexión en Sin autenticación y configura el encabezado de solicitud Authorization de la actividad según sea necesario.

HTTP v2: El valor JSON en una variable de proyecto de encabezado de solicitud falla al analizar

  • Síntoma: Una actividad de HTTP v2 que lee un valor de encabezado de solicitud de una variable de proyecto que contiene una cadena JSON falla con un error de análisis:

    Expected a ',' or ']' at 139 [character 140 line 1]

    El mismo JSON funciona cuando se pega directamente en la columna Valor de la tabla Encabezados de solicitud.

  • Causa posible: Cuando se lee un valor de encabezado de solicitud de una variable de proyecto, el conector HTTP v2 no escapa las comillas incrustadas de la manera en que lo hace cuando escribes el valor directamente en la tabla Encabezados de solicitud. Las comillas sin escape rompen la cadena de encabezado antes de llegar al destino.

  • Resolución:
    • Al almacenar JSON en una variable de proyecto que se utilizará como valor de encabezado, escapa cada comilla doble con una barra invertida. Por ejemplo, almacena el valor como {\"success\": \"true\"} en lugar de {"success": "true"}.
    • Si el contenido JSON es estático, pégalo directamente en la columna Valor de la tabla Encabezados de solicitud en lugar de usar una variable. El conector aplica el escape necesario en esa ruta.

HTTP y HTTP v2: La URL contiene múltiples caracteres ?

  • Síntoma: Una operación de HTTP o HTTP v2 falla en el sistema de destino. Los registros del agente muestran que la URL de solicitud contiene más de un ? entre segmentos, por ejemplo https://api.example.com/endpoint?param1=A?param2=B.
  • Causa posible: Los parámetros de consulta se declararon en dos lugares: anexados directamente a la ruta de URL y también agregados a la tabla Request Parameters de la actividad. El conector concatena ambos conjuntos, insertando un segundo ? en lugar de un &.
  • Resolución:
    • Elimina cualquier segmento de cadena de consulta de la ruta de URL. La URL base debe contener solo la ruta en sí (por ejemplo, https://api.example.com/endpoint).
    • Define cada parámetro de consulta en la tabla Request Parameters de la actividad. El conector inserta los caracteres ? y & automáticamente al construir la URL final.

HTTP v2: Codificación doble de URL cuando "Encode request URL" está habilitado

  • Síntoma: Las llamadas a la API REST realizadas a través del conector HTTP v2 fallan en el sistema de destino porque los parámetros de URL aparecen con codificación doble en la solicitud saliente (por ejemplo, un espacio %20 se convierte en %2520).
  • Causa posible: Cuando Encode request URL está habilitado en la configuración de conexión de HTTP v2, el conector codifica la URL completa antes de enviarla. Si los parámetros de URL ya contienen caracteres codificados en porcentaje, esos caracteres se codifican una segunda vez.
  • Resolución:
    • Deshabilita Encode request URL en la configuración de conexión de HTTP v2 cuando la URL o los parámetros ya están codificados o se construyen usando la función URLEncode.
    • Si Encode request URL debe permanecer habilitado, asegúrate de que los parámetros pasados a la URL no estén precodificados antes de llegar a la conexión.

HTTP v2: La operación falla cuando Base URL redirige

  • Síntoma: Una operación de HTTP v2 falla inmediatamente cuando la Base URL configurada devuelve una respuesta de redirección (3xx).
  • Causa posible: Follow redirects está deshabilitado en la configuración de conexión de HTTP v2, por lo que las respuestas de redirección se tratan como fallos en lugar de seguirse automáticamente.
  • Resolución: En la configuración de conexión de HTTP v2, habilita Follow redirects para permitir que el conector siga automáticamente las respuestas de redirección a la URL de destino final.

HTTP v2: Las variables en la ruta de la actividad no se resuelven

  • Síntoma: Una actividad de HTTP v2 usa una variable global, de proyecto o de Jitterbit en su campo Path, pero en tiempo de ejecución la variable se envía literalmente (sin resolver) en lugar de reemplazarse con su valor.
  • Causa posible: Se ingresó una URL completa (una que incluye el protocolo y el host, como https://api.example.com/...) en el campo Path. Las variables no se admiten en URLs completas. Solo se resuelven en una ruta parcial que se anexa a la Base URL de la conexión.
  • Resolución:
    1. En la conexión de HTTP v2, establece la Base URL en la porción de protocolo y host del punto de conexión (por ejemplo, https://api.example.com).
    2. En el campo Path de la actividad, ingresa solo la ruta parcial que sigue a la URL base, y coloca la variable dentro de esa ruta parcial (por ejemplo, /records/[recordId]). El conector resuelve la variable y anexa el resultado a la Base URL en tiempo de ejecución.

HTTP v2: El código de estado de respuesta no está disponible en variables de Jitterbit

  • Síntoma: Los scripts que leen variables de origen o destino de Jitterbit para capturar el código de estado de respuesta HTTP después de que se ejecuta una actividad HTTP v2 no reciben ningún valor. El mismo enfoque funciona con el conector HTTP pero no con HTTP v2.
  • Causa posible: El conector HTTP v2 no completa las variables de origen o destino de Jitterbit. Los datos de respuesta, incluido el código de estado HTTP, se devuelven a través del esquema de respuesta de la actividad en su lugar.
  • Resolución:
    • Para capturar el código de estado usando el esquema de respuesta predeterminado, asigna el campo statusCode, que se encuentra bajo el nodo responseItem/error de la respuesta y contiene el código de estado HTTP (por ejemplo, 200, 403). Para obtener detalles sobre la estructura del esquema de respuesta, consulta la documentación de configuración de la actividad para cualquier actividad HTTP v2.
    • Para capturar el código de estado cuando se usa un esquema de respuesta personalizado, habilita Include Additional Properties from HTTP Response in the Schema en la configuración de la actividad. Esto envuelve el esquema con una estructura definida por Jitterbit que incluye __jitterbit_api_statuscode__ (el código de estado) y __jitterbit_api_errorbody__ (el cuerpo de respuesta para solicitudes sin éxito).
    • Para que el código de estado esté disponible cuando la API devuelve una respuesta sin éxito, habilita Ignore operation error in case of non-successful status code en la configuración opcional de la actividad. Sin esta configuración, la operación falla en respuestas sin éxito antes de que los datos de respuesta puedan asignarse.

HTTP v2: Espacios de nombres XML reescritos al usar un esquema de solicitud personalizado

  • Síntoma: Una operación HTTP v2 que envía una carga útil XML a un servicio web SOAP o XML falla con un error del servidor (como 500 Internal Server Error) aunque la misma carga útil se ejecuta correctamente cuando se envía desde Postman o SoapUI. Al inspeccionar el cuerpo de la solicitud recibido por el destino, se observa que las declaraciones de espacios de nombres XML se han consolidado en el elemento raíz y los prefijos de espacio de nombres originales se han reemplazado con genéricos (por ejemplo, soapenv:Envelope se convierte en Envelope xmlns="...", y los prefijos de elementos se renumeran como ns, ns1, ns2).
  • Causa posible: Cuando se usa un esquema de solicitud personalizado en la configuración de la actividad HTTP v2, la transformación normaliza el XML de forma predeterminada, moviendo todas las declaraciones de espacios de nombres al nodo raíz y reasignando sus prefijos. Los servicios SOAP y otros puntos finales XML que validan la coherencia de los prefijos de espacios de nombres rechazan la carga útil modificada.

  • Resolución:

    • En la versión del agente 12.8 o posterior, establece jitterbit.target.xml.preserve.namespace.prefix en true en un paso de script anterior a la transformación para mantener los prefijos de espacios de nombres del XML de origen en lugar de reasignar genéricos:

      $jitterbit.target.xml.preserve.namespace.prefix = true;

    • Si tus agentes privados son anteriores a la versión 12.8, o el destino también rechaza la consolidación de declaraciones de espacios de nombres en el elemento raíz, utiliza el esquema de solicitud predeterminado en lugar de uno personalizado y asigna la carga útil XML completa como una cadena al campo body del esquema. La carga útil se trata entonces como una cadena en lugar de XML analizado, por lo que sus declaraciones de espacios de nombres se conservan. El esquema de respuesta puede seguir siendo un esquema personalizado.

HTTP v2: Los espacios se codifican como + en lugar de %20

  • Síntoma: Las llamadas a la API REST que utilizan el conector HTTP v2 fallan en el sistema de destino porque los espacios en la URL se codifican como + en lugar de %20, lo que causa que el destino devuelva un error de recurso no encontrado.
  • Resolución:
    • En la conexión HTTP v2, habilita la opción Encode request URL. El conector entonces codifica la URL de la solicitud, codificando los espacios como %20.
    • Proporciona la URL de la solicitud completamente sin codificar. No precodifiques caracteres ni apliques la función URLEncode a la URL, porque los caracteres ya codificados se codifican dos veces cuando Encode request URL está habilitado (por ejemplo, example+string%20value se convierte en example%20string%2520value).

HTTP: Envía null como la cadena "null"

  • Síntoma: Una actividad HTTP POST o PUT envía campos asignados con la función Null como la cadena "null" (u los omite) en lugar de emitir un literal JSON null. Esto ocurre cuando el esquema de solicitud se define en la actividad.
  • Posible causa: Cuando el esquema de solicitud se define en la actividad HTTP, el conector no serializa un Null asignado como un JSON null. Cuando el esquema se define en la transformación en su lugar, sin esquema de solicitud proporcionado en la actividad, el conector envía un Null asignado como un JSON null correctamente.
  • Resolución:
    • Migra la actividad al conector HTTP v2, que serializa Null correctamente. Jitterbit recomienda convertir conexiones y actividades HTTP existentes a HTTP v2.
    • Si la actividad debe permanecer en HTTP, define el esquema de solicitud en la transformación en lugar de en la actividad, y deja el esquema de solicitud de la actividad sin establecer. Con el esquema definido en la transformación, el conector serializa un Null asignado a un JSON null correctamente.

Conector LDAP

La eliminación de entrada LDAP falla cuando la entrada de destino tiene entradas secundarias

  • Síntoma: Una actividad LDAP Delete Entry falla con un error del servidor LDAP (por ejemplo, notAllowedOnNonLeaf o un mensaje que indica que la entrada no es un nodo hoja).
  • Posible causa: El protocolo LDAP no permite eliminar una entrada que tiene entradas secundarias (subordinadas). La entrada debe ser un nodo hoja sin hijos para que la eliminación sea exitosa.
  • Resolución:
    • Antes de eliminar la entrada principal, elimina primero todas las entradas secundarias. Recorre la jerarquía desde las entradas más profundas hacia arriba.
    • Si se requiere eliminar un subárbol completo, implementa un script que identifique y elimine entradas desde la parte inferior del árbol hacia arriba, utilizando RunOperation con la actividad LDAP Delete Entry para cada entrada.

Búsqueda de entrada LDAP: La expresión de filtro distingue mayúsculas de minúsculas en algunos servidores

  • Síntoma: Una actividad LDAP Search Entry no devuelve resultados o devuelve un error, aunque las entradas consultadas existan en el directorio.
  • Posible causa: Algunos servidores LDAP requieren que los nombres de atributos en expresiones de filtro coincidan exactamente con el caso utilizado por el esquema de ese servidor. La expresión de filtro rellenada previamente por Studio utiliza mayúsculas de título para la clase estructural (por ejemplo, ObjectClass), pero algunos servidores requieren un caso diferente (por ejemplo, objectClass).
  • Resolución:
    1. En la configuración de la actividad LDAP Search Entry, revisa el campo Filter Expression rellenado previamente.
    2. Ajusta el caso de los nombres de atributos para que coincida con lo que espera el servidor LDAP de destino. Por ejemplo, cambia ObjectClass a objectClass si el servidor requiere minúsculas.
    3. Consulta la documentación o definición de esquema de tu servidor LDAP para conocer las convenciones de nomenclatura de atributos requeridas.

Conectores de Microsoft

Microsoft SharePoint Online: Las conexiones de esquema SOAP fallan después de la jubilación de IDCRL

  • Síntoma: Las operaciones que utilizan un conector de Microsoft SharePoint Server con el tipo de conexión de esquema SOAP han comenzado a fallar o devuelven errores de autenticación al conectarse a SharePoint Online.
  • Causa posible: Microsoft retiró el método IDCRL (Identity Client Runtime Library) utilizado por las conexiones de esquema SOAP a SharePoint Online. Después del 1 de mayo de 2026, se espera que las operaciones que utilizan el esquema SOAP de SharePoint para conexiones de SharePoint Online fallen.
  • Resolución:
    1. En Studio, abre cada conexión de SharePoint afectada y cambia la configuración de Esquema de SOAP a REST.
    2. Reconfigura cualquier actividad que utilizara el esquema SOAP para usar operaciones REST equivalentes.
    3. Prueba e implementa nuevamente las operaciones afectadas.
    4. Para obtener detalles de migración, consulta la documentación del conector Microsoft SharePoint Server.

Microsoft Dynamics 365 Business Central v2: Los nombres de tipo son incompatibles con los metadatos

  • Síntoma: Las operaciones que utilizan el conector de Microsoft Dynamics 365 Business Central v2 fallan con errores que indican que los nombres de tipo en la carga útil son incompatibles con los metadatos de OData.
  • Causa posible: Ciertos puntos finales de la API de OData de Dynamics 365 Business Central requieren anotaciones de tipo OData en la carga útil de la solicitud. De forma predeterminada, el conector no incluye estas anotaciones, lo que causa errores de incompatibilidad de tipo para esos puntos finales.
  • Resolución:
    1. Abre la configuración de la actividad Actualizar de Microsoft Dynamics 365 Business Central v2.
    2. En Configuración opcional, habilita Establecer tipo OData en carga útil.
    3. Guarda la actividad y vuelve a probar las operaciones afectadas.

Microsoft Entra ID: Los atributos de extensión no se pueden seleccionar como condiciones de filtro de consulta

  • Síntoma: Al configurar una actividad de Consulta de Microsoft Entra ID, el campo onPremisesExtensionAttributes y sus campos de atributo de extensión secundarios (por ejemplo, extensionAttribute1 a través de extensionAttribute15) no aparecen en el selector de Campos de objeto en el paso 3 y no se pueden seleccionar como condiciones de filtro de cláusula condicional.
  • Causa posible: onPremisesExtensionAttributes es un objeto de tipo complejo (anidado). El selector de Campos de objeto del paso 3 expone solo campos de tipo de datos primitivos; los campos de tipo complejo se excluyen de la lista de selección.
  • Resolución: Los campos onPremisesExtensionAttributes no necesitan seleccionarse en el paso 3 para devolverse. Aparecen en el esquema de salida de la actividad en el paso 4 y se rellenan en tiempo de ejecución cuando se ejecuta la operación. Para acceder a los valores de atributos de extensión, asigna desde onPremisesExtensionAttributes y sus campos secundarios en la transformación.

Actividad de actualización de Microsoft Entra ID: Los campos DateTime se rechazan con error de tipo Edm.String

  • Síntoma: Una actividad de Actualizar de Microsoft Entra ID falla con:
Se encontró un valor que tiene un nombre de tipo incompatible con los metadatos.
El valor especificó su tipo como 'Edm.String', pero el tipo especificado en los metadatos es 'Edm.DateTimeOffset'.
[HTTP/1.1 400 Bad Request]
  • Posible causa: El conector envía valores de campos DateTime (como employeeHireDate) sin la anotación @odata.type requerida por la API de Microsoft Graph. Sin la anotación, el valor se interpreta como Edm.String en lugar de Edm.DateTimeOffset, lo que causa un error 400.
  • Resolución:
    1. Abre la configuración de la actividad Update de Microsoft Entra ID.
    2. En el paso 1, expande Configuración opcional y habilita Establecer tipo OData en la carga útil.
    3. Guarda la actividad, vuelve a implementar y ejecuta nuevamente la operación.

Consulta de Microsoft Entra ID: "Cláusula de filtro de consulta no compatible o inválida" en propiedades filtradas

  • Síntoma: Una actividad de Consulta de Microsoft Entra ID falla cuando se aplica una condición de filtro en el paso 3:

    (Request_UnsupportedQuery) Unsupported or invalid query filter clause specified for property '<property>' of resource '<object>'. [HTTP/1.1 400 Bad Request]

    La misma consulta se ejecuta correctamente cuando no se aplica ningún filtro.

  • Posible causa: El filtrado en ciertas propiedades de Microsoft Entra ID (como companyName y createdDateTime) utiliza la capacidad de consulta avanzada de la API de Microsoft Graph, que requiere $count=true en la cadena de consulta. Sin ella, la API rechaza el filtro incluso cuando la sintaxis es correcta. El conector incluye automáticamente el encabezado ConsistencyLevel: eventual requerido, pero $count=true debe agregarse por separado.

  • Resolución: Elige una de las siguientes opciones según la pestaña utilizada en el paso 3:
    • Pestaña Básica: Selecciona la casilla Incluir recuento. Esto agrega $count=true a la consulta automáticamente.

    • Pestaña Avanzada: Agrega &$count=true manualmente a la cadena de filtro. Por ejemplo:

      $filter=companyName eq 'Example Corp'&$count=true

Para la lista de propiedades que requieren sintaxis de consulta avanzada, consulta Capacidades de consulta avanzada en objetos de Microsoft Entra ID en la documentación de Microsoft Graph.

Las operaciones de Microsoft Dynamics AX 2012 fallan con "Error de inicio de sesión"

  • Síntoma: Las operaciones que utilizan el conector de Microsoft Dynamics AX contra AX 2012 fallan en tiempo de ejecución, aunque la prueba de conexión se realiza correctamente en Studio. El registro del Servicio REST del Conector de Jitterbit Dynamics AX 2012 contiene:

    The server has rejected the client credentials.

    The logon attempt failed

  • Causa: El campo Nombre de dominio en la conexión de AX 2012 no está configurado con el valor correcto. La autenticación de AX 2012 requiere que el Nombre de dominio sea la extensión del nombre de dominio DNS (por ejemplo, yourcompany.com), no un nombre de dominio corto o NetBIOS. Un valor de dominio incorrecto hace que AX rechace credenciales válidas con un error de inicio de sesión, incluso cuando la prueba de conexión se realiza correctamente.

  • Resolución:
    1. Abre la conexión de Dynamics AX 2012 en Studio.
    2. Establece el campo Nombre de dominio en tu extensión de nombre de dominio DNS (por ejemplo, yourcompany.com), no en un nombre de dominio corto/NetBIOS.
    3. Confirma que el Inicio de sesión sea el nombre de usuario de la cuenta de servicio de AX con los privilegios requeridos y vuelve a ingresar la Contraseña para descartar un valor obsoleto.
    4. Prueba la conexión y luego ejecuta nuevamente la operación.

Conector NetSuite

Nota

NetSuite cuenta con una guía de solución de problemas dedicada que cubre problemas adicionales de conexión, esquema, configuración de actividades y rendimiento. Consulta Solución de problemas de NetSuite.

La creación, actualización o inserción en NetSuite falla con "is not a legal value for Country"

  • Síntoma: Una actividad de Creación, Actualización o Inserción de NetSuite falla cuando el valor de origen de un campo de país no coincide con un valor enum Country de NetSuite:

    FaultString: org.xml.sax.SAXException: <country_value> is not a legal value for {urn:types.common_<version>.platform.webservices.netsuite.com}Country

  • Causa posible: La API SuiteTalk de NetSuite requiere que Country (y otros campos enumerados) sea uno de los valores enum predefinidos del WSDL (por ejemplo, _unitedStates). Se rechaza un nombre de país mostrado, un código de país ISO o cualquier valor que no coincida exactamente con el enum del WSDL.

  • Resolución:
    • En la transformación que se asigna al destino de NetSuite, traduce el valor de país de origen al valor enum de NetSuite correspondiente antes de escribir. Un diccionario de referencia cruzada, una declaración Case o una tabla de búsqueda funcionan para esto.
    • Construye la referencia cruzada a partir del enum Country definido en el WSDL de SuiteTalk de NetSuite que utiliza tu conector. Los valores válidos cambian entre versiones de WSDL, así que siempre verifica contra la versión de WSDL configurada actualmente en la conexión.
    • Aplica el mismo enfoque a cualquier otro campo respaldado por un enum de NetSuite (por ejemplo, State, Currency) donde los valores de origen no coincidan ya con el enum del WSDL.

Conector OData

Los conjuntos de entidades de OData v2 no se cargan con "No entity sets found"

  • Síntoma: Configurar una actividad de Consulta de OData que apunte a un servicio OData v2.0 devuelve un error al obtener la lista de objetos, aunque la prueba de conexión sea exitosa:

    An error occurred while fetching the data:
Error while generating for query activity object list. The Exception is No entity sets found for the address provided.

  • Causa posible: La compatibilidad con servicios OData V2 se agregó al conector OData en la versión 11.59 del agente, a través de la configuración de conexión OData version. En agentes anteriores a la versión 11.59, el conector solo admite OData V4, por lo que una conexión que apunte a un servicio OData V2 no puede rellenar la lista de objetos. La misma falla ocurre en la versión 11.59 o posterior si OData version se deja en V4 para un servicio OData V2.

  • Resolución:
    1. Para agentes privados, actualiza a la versión 11.59 o posterior. Los agentes en la nube reciben la actualización automáticamente.
    2. En la conexión OData, establece OData version en V2 (el valor predeterminado es V4). Guarda y vuelve a probar la conexión.
    3. Reabre la actividad de Consulta de OData. Los conjuntos de entidades deberían cargarse ahora.

OData: Microsoft Dynamics 365 devuelve solo los datos de la empresa predeterminada

  • Síntoma: Una conexión de OData a un punto de conexión de Microsoft Dynamics 365 Finance and Operations devuelve datos solo de la empresa predeterminada del usuario, por lo que faltan registros de otras empresas en los resultados.
  • Causa posible: Por defecto, un punto de conexión OData de Dynamics 365 Finance and Operations devuelve solo los datos que pertenecen a la empresa predeterminada del usuario. Para dar a la conexión un alcance entre empresas (expandido), se debe agregar una cláusula de filtro entre empresas a la URL de metadatos de OData de la conexión (la URL $metadata). En la URL de metadatos, ?cross-company=true por sí solo no aplica el alcance expandido.
  • Resolución: En la conexión OData, agrega una cláusula de filtro dataAreaId a la URL de metadatos de OData, reemplazando usrt con tu identificador de área de datos, luego guarda y vuelve a probar:
?$filter=dataAreaId eq 'usrt'&cross-company=true

Para obtener información sobre cómo Dynamics 365 limita los datos de OData por empresa, consulta la documentación de Microsoft sobre comportamiento entre empresas.

Conectores de Oracle

Oracle EBS: error de conexión "custom provider JAR file is not present"

  • Síntoma: La conexión a una instancia de Oracle E-Business Suite (EBS) falla con:

    Error connecting to Oracle EBS instance. Error is: The custom provider JAR file is not present in the Jitterbit Private Agent or it is not in the right location ($JITTERBIT_HOME/Connectors/Providers)

  • Causa posible: El conector Oracle EBS requiere que el controlador JDBC de Oracle (ojdbc8.jar) se coloque manualmente en el agente privado. Este archivo no se incluye con el agente y debe agregarse antes de que la conexión pueda establecerse.

  • Resolución:
    1. Descarga ojdbc8.jar del sitio web de Oracle (se requiere una cuenta de Oracle).
    2. Coloca ojdbc8.jar en el directorio $JITTERBIT_HOME/Connectors/Providers/ en el host del agente privado.
    3. Reinicia todos los agentes en el grupo de agentes.
    4. Vuelve a probar la conexión de Oracle EBS.

Conectores de Salesforce

Nota

El conector de Salesforce cuenta con una guía de solución de problemas dedicada que cubre autenticación, esquema, configuración de actividades, límites de registros y problemas de actividades masivas. Consulta Solución de problemas del conector de Salesforce.

Salesforce Events: no se pueden habilitar eventos después de reiniciar el agente

  • Síntoma: Después de reiniciar o reinstalar un agente privado, los eventos del conector Salesforce Events no se habilitan, incluso cuando las credenciales de conexión son correctas.
  • Causa posible: Después de un reinicio, es posible que el archivo JAR del conector aún no esté presente en el agente. Habilitar un evento requiere que el conector se descargue primero en el agente.
  • Resolución:
    1. Abre la configuración de conexión de Salesforce Events en Studio.
    2. Haz clic en Test para probar la conexión. Esto fuerza la descarga del JAR del conector al agente.
    3. Después de que la prueba de conexión sea exitosa, intenta habilitar el evento nuevamente.

Salesforce Events: limitaciones de actividades de escucha

Los siguientes comportamientos de las actividades de escucha de Salesforce Events (Subscribe Event y las actividades Subscribe Insert, Update y Delete CDC Event) son esperados y no indican un defecto del conector:

  • No se pueden habilitar eventos porque se alcanzó el número máximo de suscriptores. La instancia de Salesforce limita el número de clientes concurrentes (suscriptores). Cuando se alcanza ese límite, no se pueden habilitar más eventos. Reduce el número de suscriptores activos conectados a la instancia.
  • Faltan símbolos de medida como $ y % en la respuesta. Estos símbolos no se devuelven, por diseño de la API de Salesforce.
  • Los campos sin modificar se devuelven como nulos en las respuestas de Change Data Capture (CDC). Para actividades de CDC, solo se rellenan los campos modificados; los campos sin modificar se devuelven como nulos, por diseño de la API de Salesforce.

Conector SAP

Múltiples actividades SAP en una operación fallan en tiempo de ejecución

  • Síntoma: Una operación que contiene más de una actividad de SAP o que combina una actividad SAP con una actividad de NetSuite, Salesforce, Salesforce Service Cloud, ServiceMax o SOAP se implementa sin errores de validación pero falla al ejecutarse.
  • Causa posible: Las operaciones que mezclan estos tipos de actividades parecen válidas en Studio y se pueden implementar correctamente, pero estas combinaciones no se admiten en tiempo de ejecución. Las reglas de validación de operaciones no marcan este patrón como un error en tiempo de diseño. Se trata de un problema conocido de Studio documentado.
  • Resolución:
    • Diseña cada operación para que contenga solo una actividad SAP, sin otras actividades SAP, NetSuite, Salesforce, Salesforce Service Cloud, ServiceMax o SOAP en la misma operación.
    • Si se necesitan datos de múltiples sistemas en un único flujo de trabajo, divide la lógica en operaciones separadas y encadénalas usando acciones de operación.

SAP RFC: "Sin autorización RFC para el módulo de función BAPI_TRANSACTION_COMMIT"

  • Síntoma: Una actividad de RFC de SAP falla en tiempo de ejecución con:

    JCoException occurred No RFC authorization for function module BAPI_TRANSACTION_COMMIT

  • Causas posibles:

    • La cuenta de usuario SAP en la conexión no tiene autorización S_RFC para BAPI_TRANSACTION_COMMIT o sus grupos de funciones relacionados.
    • El módulo de función BAPI_TRANSACTION_COMMIT no está configurado como habilitado para acceso remoto en el sistema SAP.
    • La transformación de solicitud anterior a la actividad no establece el campo de control de confirmación.

  • Resolución:

    • En el sistema SAP, confirma que el módulo de función BAPI_TRANSACTION_COMMIT está habilitado para acceso remoto.
    • En la transformación de solicitud que precede a la actividad RFC de SAP, establece el campo BAPI_COMMIT en true.
    • Verifica que la cuenta de usuario SAP referenciada en la conexión tenga autorización S_RFC para BAPI_TRANSACTION_COMMIT y todos los grupos de funciones relacionados.
    • Si el problema persiste, contacta a tu administrador SAP BASIS para que revise las asignaciones de objetos de autorización del usuario.

La conexión SAP falla con "Clave de idioma no válida"

  • Síntoma: Una conexión de SAP falla durante la inicialización con un error sobre la clave de idioma:

    Connector Error: AdapterResourceException: Error while creating Destination. 00024Invalid language key when configuring the text environment.

  • Causa posible: El código de Idioma configurado en el extremo SAP no es válido para el sistema SAP de destino: el código no está instalado o no se admite en ese sistema, o está mal escrito o tiene mayúsculas incorrectas (por ejemplo, en en lugar de EN). SAP rechaza la clave no válida al inicializar el entorno de texto del destino.

  • Resolución:
    1. Edita el extremo SAP en Studio y establece el campo Idioma en un código de idioma válido de dos letras (por ejemplo, EN para inglés).
    2. Verifica que el valor coincida con un idioma instalado y activo en el sistema SAP de destino. Si no estás seguro, confirma el idioma predeterminado del usuario de integración en el perfil de usuario SAP y utiliza ese.
    3. Prueba la conexión desde Studio para confirmar que la inicialización se realiza correctamente antes de reimplementar la operación.

Conector de ServiceNow

Las ejecuciones iniciales son lentas después de reiniciar el agente o en agentes en la nube

  • Síntoma: Las operaciones que utilizan el conector de ServiceNow se ejecutan lentamente en dos escenarios:

    • En agentes privados, la primera operación después de reiniciar el agente puede tardar varios minutos; las ejecuciones posteriores son rápidas.
    • En agentes en la nube, las ejecuciones son intermitentemente lentas, tardando minutos cada vez que se actualiza la caché de metadatos del conector.

    Esto puede causar tiempos de espera agotados en las API descendentes.

  • Causa posible: El conector almacena en caché los metadatos de ServiceNow de forma agresiva. Después de reiniciar un agente en un agente privado (o en cada ejecución de un agente en la nube que no conservó la caché), la primera operación debe reconstruir la caché, lo que tarda varios minutos.

  • Resolución:
    • En un agente privado, mitiga la lentitud posterior al reinicio agregando getcolumnsmetadata=onUse a las Opciones avanzadas del punto de conexión de ServiceNow. Esta configuración solo es efectiva en agentes privados.
    • Para un rendimiento consistente en agentes en la nube, llama a la API REST de ServiceNow a través del conector HTTP v2 en lugar de usar el conector de ServiceNow. El conector HTTP v2 no almacena en caché los metadatos y evita el retraso de reconstrucción.

Conector de Shopify

Shopify: Las selecciones de objetos de actividad pueden cambiar después de actualizar la versión de la API

  • Síntoma: Después de cambiar la versión de la API en una conexión de Shopify, una o más actividades de Shopify devuelven errores o se comportan de forma inesperada, y un objeto o subobjeto configurado parece haber cambiado.
  • Causa posible: Shopify lanza nuevas versiones de la API trimestralmente y depreca versiones anteriores después de 12 meses. Cuando cambias a una versión de API diferente, los objetos o subobjetos que no están disponibles en la nueva versión pueden dejar de ser seleccionables, lo que causa que la selección configurada de la actividad cambie cuando se actualiza la configuración.
  • Resolución:
    1. Después de cambiar la versión de la API de Shopify en la conexión, abre cada configuración de actividad de Shopify afectada.
    2. Haz clic en Actualizar para recargar los objetos disponibles para la nueva versión de la API.
    3. Revisa las selecciones de objetos y subobjetos para confirmar que reflejan tu intención en la nueva versión.
    4. Actualiza cualquier selección que haya cambiado a los objetos de reemplazo correctos.
    5. Redeploy y vuelve a probar las operaciones afectadas.
    6. Para obtener información sobre los plazos de deprecación de versiones de la API de Shopify, consulta el registro de cambios de Shopify.

Conector de Snowflake

Snowflake: Las conexiones basadas en contraseña fallan después de la deprecación de autenticación

  • Síntoma: Las operaciones que se conectan a Snowflake utilizando el tipo de autenticación Contraseña (Deprecada) han comenzado a fallar después de funcionar previamente.
  • Causa posible: Snowflake está eliminando gradualmente la autenticación de un solo factor (solo contraseña). Las conexiones basadas en contraseña fallan a menos que la propiedad TYPE de la cuenta de usuario de Snowflake esté configurada en LEGACY_SERVICE.

  • Resolución: Elige una de las siguientes opciones:

    • Solución temporal: En Snowflake, establece la propiedad TYPE de la cuenta de usuario en LEGACY_SERVICE para restaurar la conectividad basada en contraseña:

      ALTER USER <username> SET TYPE = LEGACY_SERVICE;

      Esta solución temporal no es una solución a largo plazo, ya que Snowflake puede eliminar la compatibilidad con LEGACY_SERVICE en una versión futura.

    • Migración recomendada: Actualiza la conexión del conector de Snowflake en Studio para usar autenticación OAuth o Key-Pair, y configura la cuenta de usuario de Snowflake para que coincida.

Snowflake: La instancia de desarrollador está en reposo, las tablas de metadatos no se están poblando

  • Síntoma: Al configurar una actividad de Snowflake, la lista de objetos disponibles no se completa o aparece vacía, aunque la prueba de conexión sea exitosa.
  • Causa posible: Las instancias de desarrollador de Snowflake entran en estado de reposo cuando no se han accedido recientemente. Aunque la prueba de conexión puede ser exitosa contra una instancia en reposo, es posible que la instancia no devuelva metadatos de tablas y objetos.
  • Resolución:
    1. Inicia sesión en la interfaz web de Snowflake para despertar la instancia.
    2. Reabre la conexión de Snowflake en Studio y haz clic en Test para volver a probar las credenciales.
    3. Reabre la configuración de la actividad para actualizar la lista de objetos disponibles.

Snowflake Query: La falta de coincidencia de mayúsculas y minúsculas en el nodo raíz de esquema plano causa error ProcessFlatStream

  • Síntoma: Una actividad de Query de Snowflake que utiliza un esquema plano falla en tiempo de ejecución con:

    StartElement() error, starting element does not match with the root.
qName= "<table_name_lowercase>", root name="<TABLE_NAME_UPPERCASE>"

ProcessFlatStream error

    Este error ocurre cuando la consulta incluye una cláusula WHERE, una cláusula LIMIT o una referencia de variable en una cláusula WHERE.

  • Causa posible: El conector de Snowflake devuelve el nombre de la tabla en minúsculas en la respuesta XML. Cuando Studio genera un esquema plano a partir de la consulta, el nombre del nodo raíz se crea en mayúsculas. La falta de coincidencia entre el nodo raíz del esquema (mayúsculas) y el nodo raíz de la respuesta XML (minúsculas) causa que el procesamiento de flujo plano falle.

  • Resolución: Elige una de las siguientes opciones:
    • En el esquema plano, cambia el nombre del nodo raíz a minúsculas para que coincida con la salida del conector. Por ejemplo, cambia el nombre de SALES_ORDERS a sales_orders.
    • Utiliza el esquema espejo con asignación predeterminada en lugar de un esquema plano construido manualmente. El esquema espejo deriva su estructura directamente de la respuesta del conector y no tiene esta falta de coincidencia de mayúsculas y minúsculas.

Snowflake Merge: stageName y fileContent faltan en el esquema de solicitud para etapas externas

  • Síntoma: Una actividad Merge de Snowflake configurada contra una etapa externa muestra un esquema de solicitud sin los campos stageName y fileContent. La misma actividad configurada contra una etapa interna expone ambos campos.
  • Causa posible: Las etapas externas son referencias de solo lectura a archivos que ya existen en almacenamiento en la nube externo (S3, GCS o Azure Blob). La actividad Merge no puede cargar contenido de archivo en una etapa externa, por lo que el esquema omite los campos que impulsan esa carga.
  • Resolución:
    • Cuando la actividad se dirige a una etapa externa, asegúrate de que los archivos de datos ya estén presentes en la ubicación de almacenamiento en la nube a la que hace referencia la etapa. La actividad Merge lee directamente de esos archivos; no se necesita un campo fileContent.
    • Cuando necesites insertar contenido de archivo desde la operación, configura la actividad Merge para usar una etapa interna. El esquema entonces expone stageName y fileContent.

Snowflake Insert o Merge: Errores de sintaxis SQL de caracteres especiales

  • Síntoma: Una actividad de Insert o Merge de Snowflake falla con un error de compilación SQL como:

    SQL compilation error:
syntax error line 1 at position <n> unexpected '<token>'.

Los valores de columna también pueden aparecer mal asignados, con datos de un campo apareciendo en la columna incorrecta.

  • Posibles causas:

    • Los valores de campo que contienen comillas simples (por ejemplo, un valor como corner's) no se escapan antes de incluirse en la carga útil SQL. La comilla sin escapar termina la cadena prematuramente, lo que causa que el resto del valor se interprete como sintaxis SQL en lugar de datos.
    • Un nombre de columna de destino contiene un carácter especial, como un guión (por ejemplo, Zip-Code). Snowflake requiere que un identificador que contenga un carácter especial esté entrecomillado; sin entrecomillar, produce un error de sintaxis en el guión.

  • Resolución:

    • Para valores que contienen comillas simples: En la conexión de Snowflake, en Configuración opcional, habilita Escapar caracteres especiales. Esto escapa automáticamente las comillas simples en las cargas útiles de actividades Insert e Invoke Stored Procedure. Para actividades Merge, o como alternativa para Insert, usa SQLEscape en la asignación de transformación para escapar las comillas simples en los valores de campo afectados antes de que lleguen a la actividad.
    • Para nombres de columna que contienen caracteres especiales: Confirma que Usar comillas para identificadores de Snowflake esté habilitado en la conexión (habilitado de forma predeterminada).

Snowflake: Error de espacio de pila Java al consultar conjuntos de datos grandes

  • Síntoma: Una actividad Query de Snowflake falla con el siguiente error cuando la consulta devuelve un gran número de filas:

    Error executing query activity. Exception is Java heap space

    El conector reporta el error de esta forma porque envuelve el error Java subyacente, que aparece más adelante en el seguimiento de pila:

    Caused by: java.lang.OutOfMemoryError: Java heap space

    Si este error ocurre en consultas que devuelven pocas filas, o el mismo agente también falla con errores de pila a través de otros conectores, la causa es más probable que sea la asignación general de pila del agente que el tamaño del conjunto de resultados. Consulta Espacio de pila Java: OutOfMemoryError.

  • Posible causa: El conector de Snowflake carga el conjunto de resultados de consulta completo en la memoria de JVM antes de pasarlo a la transformación. Con conjuntos de resultados muy grandes, esto agota la pila de JVM de Tomcat en el agente privado.

  • Resolución: Para grandes volúmenes de consultas, usa el conector de base de datos con un controlador JDBC de Snowflake en lugar del conector de Snowflake. El conector de base de datos no almacena en búfer el conjunto de resultados completo en memoria, por lo que puede manejar volúmenes de consultas mucho más grandes. Instala el controlador JDBC de Snowflake en el agente privado y luego configura una conexión de base de datos que lo use. En el agente 12.x y posterior, esa conexión de base de datos también necesita enableArrowResultFormat=false&jdbc_query_result_format=json en su cadena de conexión; consulta Snowflake: Las operaciones fallan en el agente 12.x.

    Si necesitas permanecer en el conector de Snowflake, cualquiera de las siguientes opciones puede reducir la presión de memoria, aunque ninguna garantiza ser suficiente para conjuntos de datos de millones de filas:

    • Divide la consulta en lotes usando las cláusulas SQL LIMIT y OFFSET, ejecutando la operación repetidamente con desplazamientos incrementales hasta que se procesen todas las filas.
    • Aumenta el tamaño de pila de JVM de Tomcat en el agente privado (consulta Memoria de pila de Tomcat).

Snowflake: Las operaciones fallan en el agente 12.x

  • Síntoma: En un agente privado que ejecuta la versión 12.x, las operaciones que consultan Snowflake a través de un controlador JDBC de Snowflake (una conexión de base de datos o un script DBExecute) fallan en tiempo de ejecución, aunque la prueba de conexión sea exitosa. El error hace referencia a la capa de memoria Arrow del controlador, por ejemplo:
JDBC driver internal error: exception creating result java.lang.ExceptionInInitializerError at net.snowflake.client.jdbc.internal.apache.arrow.memory.unsafe.UnsafeAllocationManager

o:

JDBC driver internal error: exception creating result java.lang.NoClassDefFoundError: Could not initialize class net.snowflake.client.jdbc.internal.apache.arrow.memory.RootAllocator
  • Posible causa: Por defecto, el controlador JDBC de Snowflake devuelve los resultados de las consultas en formato Apache Arrow, que no es compatible con la versión 12.x del agente y posteriores. Consulta el artículo de solución de problemas de Snowflake sobre este error de módulo Java para más detalles. La prueba de conexión no devuelve ningún conjunto de resultados, por lo que sigue siendo exitosa mientras que las consultas fallan. Actualizar la versión del controlador JDBC no lo resuelve.

  • Solución: Establece enableArrowResultFormat en false y jdbc_query_result_format (o JDBC_QUERY_RESULT_FORMAT) en json para que el controlador devuelva los resultados en JSON en lugar de Arrow:

    • Conector de base de datos: Añade enableArrowResultFormat=false&jdbc_query_result_format=json a la cadena de conexión de Snowflake, en el campo Parámetros adicionales de la cadena de conexión (o en el campo Cadena de conexión, si está seleccionado Usar cadena de conexión).
    • Conector de Snowflake: En Configuración opcional > Propiedades personalizadas de conexión, añade enableArrowResultFormat con un valor de false. Una fila JDBC_QUERY_RESULT_FORMAT con un valor de JSON ya está presente allí por defecto.

    Luego guarda, vuelve a probar la conexión y vuelve a ejecutar la operación.

    En un agente privado, puedes aplicar la corrección a nivel de JVM para que no sea necesario repetirla por conexión, añadiendo --add-opens=java.base/java.nio=ALL-UNNAMED a CATALINA_OPTS:

    Añade la siguiente línea a /opt/jitterbit/tomcat/bin/setenv.sh:

    export CATALINA_OPTS="$CATALINA_OPTS --add-opens=java.base/java.nio=ALL-UNNAMED"

    Luego reinicia el agente.

    1. Abre el Editor del Registro y busca la siguiente clave:

      HKEY_LOCAL_MACHINE\SOFTWARE\WOW6432Node\Apache Software Foundation\Procrun 2.0\Jitterbit Tomcat Server\Parameters\Java

    2. Abre la subclave Options.

    3. En el campo Datos del valor, añade --add-opens=java.base/java.nio=ALL-UNNAMED a las opciones de Java existentes.
    4. Haz clic en Aceptar.
    5. Reinicia el agente.

    Utiliza una de las siguientes estrategias para aplicar la configuración:

    1. Actualiza el Dockerfile y reconstruye la imagen de Docker:

      docker build -t my-agent .

    2. Inclúyelo en el comando run de Docker:

      docker run -e CATALINA_OPTS="--add-opens=java.base/java.nio=ALL-UNNAMED" my-agent

    3. Inclúyelo en docker-compose.yml y reinicia el contenedor:

      environment:
  - CATALINA_OPTS=--add-opens=java.base/java.nio=ALL-UNNAMED

Conector SOAP

Error de implementación de SOAP: "No WSDL with locator"

  • Síntoma: La implementación de un proyecto que incluye una conexión SOAP, o una actividad SOAP Request o SOAP Response de API, falla con:

    Failed to deploy - Internal Error: No WSDL with locator

  • Posibles causas:

    • Se eliminó el WSDL, se reimportó o su referencia interna se rompió, por lo que el proyecto hace referencia a un identificador de WSDL que ya no existe.

  • El proyecto fue implementado o transferido a otro entorno antes del lanzamiento de Harmony 12.9, cuando la implementación de un proyecto podía eliminar archivos WSDL que aún estaban en uso. El lanzamiento 12.9 previene la eliminación, pero un WSDL eliminado antes debe volver a cargarse.

  • Resolución:

    1. Vuelve a cargar el WSDL para el componente afectado:

      • Para una conexión SOAP, abre la conexión y selecciona Upload URL o Upload file (no Select existing), vuelve a cargar el WSDL, revisa la configuración de Port y Select methods, luego haz clic en Save Changes.
      • Para una actividad SOAP Request o SOAP Response de API, abre la actividad y vuelve a cargar el WSDL en el paso 1 de su configuración.

    2. Revisa cualquier transformación que herede esquemas del WSDL recargado y regeneralos si es necesario.

    3. Vuelve a implementar el proyecto.

    4. Si el proyecto tiene múltiples WSDLs y no está claro cuál está afectado, consulta Solución de problemas de conexión SOAP para identificarlo desde una exportación JSON.

SOAP WSDL: schemaLocation debe usar referencias relativas

  • Síntoma: Una conexión SOAP que hace referencia a un WSDL con archivos de esquema XSD importados falla al cargar o produce errores de resolución de esquema en tiempo de diseño.
  • Causa posible: El WSDL usa URLs absolutas en sus atributos schemaLocation para archivos XSD importados (por ejemplo, http://example.com/schema.xsd). El agente no puede obtener esquemas de URLs remotas absolutas al cargar un WSDL importado localmente.
  • Resolución:
    1. Edita el WSDL para que todas las referencias schemaLocation usen rutas relativas (por ejemplo, schema.xsd en lugar de http://example.com/schema.xsd).
    2. Coloca todos los archivos XSD referenciados en el mismo directorio que el WSDL e importa nuevamente el WSDL en la conexión SOAP.

El conector SOAP reescribe los prefijos y la estructura del espacio de nombres XML

  • Síntoma: El sobre XML producido por una actividad SOAP no coincide con los prefijos de espacio de nombres literales o la estructura del WSDL de origen (por ejemplo, el conector sustituye xmlns:ns1 por xmlns:glob). Los servicios SOAP estrictos que comparan el texto exacto del prefijo rechazan la solicitud.
  • Causa posible: El motor de transformación procesa los mensajes SOAP como XML estructurado, no como texto literal. Produce una carga útil semánticamente equivalente que puede usar prefijos de espacio de nombres diferentes al WSDL de origen.
  • Resolución: Para servicios SOAP que requieren una estructura XML literal, omite el conector SOAP y construye la carga útil de la solicitud como una cadena:
    1. Crea una conexión HTTP v2 que apunte a la URL del servicio SOAP.
    2. En una transformación, construye el sobre SOAP como una cadena, concatenando literales de cadena y valores asignados con el operador +. Alternativamente, lee una plantilla de un archivo y sustituye valores dinámicos con Replace.
    3. En la actividad POST de HTTP v2, usa el esquema de solicitud predeterminado (no cargues un esquema de solicitud personalizado) y asigna la cadena del sobre SOAP construida al campo body de ese esquema. El conector envía el valor body tal cual, preservando el XML literal.
    4. Establece el encabezado Content-Type en text/xml o application/soap+xml, y establece el encabezado SOAPAction si el servicio lo requiere.
    5. Lee la respuesta del servicio desde el campo responseContent del esquema de respuesta predeterminado de la actividad.

SOAP: Los mensajes MTOM/XOP no son compatibles

Conector VTEX

La prueba de conexión falla con "No tienes permiso para acceder a este recurso"

  • Síntoma: Una prueba de conexión de VTEX falla con un error de permisos en Studio, aunque las mismas credenciales funcionan en herramientas externas como Postman.

    You don't have permission to access this resource

  • Causa posible: El usuario de VTEX o la clave de aplicación asociada con la conexión no tiene uno o más permisos que el conector utiliza para validar la conexión. Estos permisos son más estrictos que los necesarios para el acceso básico a datos.

  • Resolución:
    1. En el portal de administración de VTEX, abre el perfil de acceso asignado al usuario o clave de aplicación que Jitterbit está utilizando.
    2. Confirma que el perfil de acceso incluye la función License Manager con acceso al recurso Get account by identifier.
    3. Guarda el perfil y vuelve a probar la conexión de VTEX en Studio.

Conector Workday

Workday: WSDL v42.0 y v42.1 devuelven errores para servicios específicos

  • Síntoma: Las operaciones que utilizan el conector Workday configurado con la versión WSDL 42.0 o 42.1 fallan al acceder a los servicios web Human_Resources o Resource_Management.
  • Causa posible: Se sabe que WSDL v42.0 devuelve errores para los servicios Human_Resources (v42.0) y Resource_Management (v42.0). Se sabe que WSDL v42.1 devuelve errores para el servicio Human_Resources (v42.1). Estos son problemas conocidos específicos de esas versiones de WSDL.
  • Resolución:
    1. En la configuración de conexión de Workday, cambia la versión de WSDL a 41.x o 43.0 o posterior para operaciones que utilicen los servicios Human_Resources o Resource_Management.
    2. Prueba la conexión y vuelve a ejecutar las operaciones afectadas para confirmar que el problema se ha resuelto.

Workday: La prueba de conexión falla con "La tarea enviada no está autorizada"

  • Síntoma: Una prueba de conexión de Workday falla con:

    Error occurred while opening connection. The Exception is Processing error occurred. The task submitted is not authorized.

    Este error puede ocurrir con ambos tipos de autenticación Basic Auth y JWT Bearer. Ten en cuenta que las operaciones pueden ejecutarse correctamente en tiempo de ejecución incluso cuando la prueba de conexión devuelve este error, porque la prueba llama a un servicio específico de Workday (Get_Message_Template_Translation_Request) que requiere un permiso que el ISU podría no tener, mientras que las operaciones de integración reales llaman a servicios diferentes.

  • Causas posibles:

    • El Usuario del Sistema de Integración (ISU) no ha sido asignado al grupo de seguridad Setup Administrator en Workday. La llamada de prueba de conexión del conector se rechaza si el ISU carece de esta membresía de grupo de seguridad.
    • El campo Workday Host contiene un valor incorrecto. Un host incorrecto causa que la conexión falle antes de que se intente la autenticación.

  • Resolución:

    1. Verifica que el valor de Workday Host en la configuración de conexión sea correcto. El host debe ser la URL base de tu inquilino de Workday (por ejemplo, https://wd5-impl-services1.workday.com/). Puedes confirmar el valor correcto desde la página View API Client de Workday.
    2. En la instancia de Workday, abre la tarea Assign Users to User-based Security Group, selecciona Setup Administrator y confirma que el ISU aparece en System Users. Si no es así, agrega el ISU. Para ver los pasos completos, consulta Requisitos previos.
    3. Confirma que la tarea Configure Web Service Security también se haya completado para el ISU, como se describe en la página Requisitos previos.
    4. Vuelve a probar la conexión.