Resolver conflictos y errores de mapeo de transformación en Jitterbit Integration Studio

Introducción

Los mapeos de transformación deben ser válidos para que una transformación sea válida. Esta página describe cómo identificar mapeos inválidos y ver los errores de validación asociados con ellos. También explica cómo resolver errores de validación.

Para prevenir problemas de validación, consulte Probar y validar transformaciones.

Errores de validación

Las transformaciones se tratan de la misma manera que otros componentes del proyecto al identificar la validez de los componentes a nivel de proyecto. Se pueden identificar transformaciones inválidas en el lienzo de diseño y en el panel del proyecto, como se describe en Validez de componentes. Los errores de validación dentro de un mapeo se incluyen en la validación de transformaciones.

Para que una transformación sea válida, no debe tener errores de validación dentro de la propia transformación. Para ser considerada válida, una transformación debe cumplir con estas reglas:

• Un mapeo no puede contener referencias a campos o variables que no existen.
• Un mapeo no puede contener conflictos de tipo de datos.
• Un mapeo debe usar una sintaxis de script válida.
• Un nodo de bucle de destino no puede tener múltiples fuentes.
• Se debe proporcionar un esquema para una actividad de fuente o destino adyacente.

Además, ciertos campos de destino pueden requerir un mapeo, o pueden no permitir un mapeo. Por ejemplo, los campos unidos de una tabla secundaria no pueden ser mapeados. Se proporcionan detalles adicionales en Reglas de validación más adelante en esta página.

Para resolver errores de validación, se pueden identificar errores dentro de la propia transformación y hacer ajustes en consecuencia. Los mapeos inválidos se muestran ya sea para un bloque completo de campo de destino, o para objetos mapeados individuales dentro de un bloque de campo de destino.

Campo de destino completo

Cuando un mapeo de campo de destino completo es inválido, aparece una línea vertical roja a la izquierda del bloque del campo de destino. Un ícono de advertencia se muestra en la parte superior derecha del campo de destino. Al pasar el cursor sobre el ícono de advertencia, se lista la razón por la cual el mapeo es inválido.

Este tipo de mapeo inválido puede resultar del mapeo de campos que no se pueden mapear. Por ejemplo, este error ocurre cuando se intenta mapear a un ID de objeto único en una actividad de inserción de Salesforce utilizada como destino.

Cuando un mapeo de campo de destino completo es potencialmente inválido, aparece una línea vertical naranja a la izquierda del bloque del campo de destino. Al pasar el cursor sobre el campo, se lista la razón por la cual el mapeo puede ser inválido.

Este tipo de mapeo inválido puede resultar de la ausencia de un mapeo que puede ser requerido. Por ejemplo, este error ocurre cuando una clave primaria no está mapeada en una actividad de inserción de base de datos utilizada como destino.

Los mapeos inválidos o potencialmente inválidos también pueden resultar de múltiples objetos (como más de un objeto fuente o variable) que se están mapeando a un campo de destino sin ninguna lógica que especifique cómo procesar esos objetos.

Para resolver mapeos inválidos, se puede eliminar el mapeo o abrir el script del campo para agregar lógica de procesamiento. Los mapeos potencialmente inválidos están destinados a señalar un problema potencial, pero se pueden dejar tal como están si se ha determinado que el mapeo es válido.

Para eliminar un mapeo, pasa el cursor sobre el campo de destino y utiliza el ícono Eliminar mapeo.

Para agregar lógica de procesamiento a un campo con un mapeo inválido, pasa el cursor sobre el campo de destino y haz clic en el ícono Editar.

Objeto mapeado individual

Cuando un objeto mapeado individual dentro de un campo de destino es inválido, el objeto mapeado se resalta en rojo con un ícono de advertencia mostrado a la derecha:

Los mapeos individuales pueden ser inválidos si un objeto fuente mapeado ya no está presente después de editar un esquema, si hay una discrepancia entre lo requerido/opcional con la cardinalidad de un campo de destino, o si los campos fuente y de destino tienen tipos de datos incompatibles.

El mapeo de campos fuente y de destino con tipos de datos potencialmente incompatibles se señala para todos los esquemas, independientemente de si tienen tipos de datos definidos, como aquellos definidos a partir de una actividad de Salesforce o Base de Datos. Esta señalización también ocurre para esquemas que solo tienen etiquetas de tipo de datos, como aquellos definidos a partir de un archivo de muestra o que han sido definidos manualmente. Para estos tipos de esquemas, todos los campos se manejan como cadenas, independientemente de si tienen etiquetas de tipo de datos.

Una discrepancia de tipo de datos no indica necesariamente que haya un problema con el mapeo. Por ejemplo, si un campo fuente con un tipo de dato entero está mapeado a un campo de destino con un tipo de dato cadena, los datos resultantes son una cadena que contiene un valor numérico. Los campos fuente con cualquier tipo de dato pueden ser mapeados a un campo de destino con un tipo de dato cadena, por lo que estos mapeos no se señalan.

Sin embargo, si la situación es la inversa, y un campo fuente con un tipo de dato cadena u otro tipo de dato está mapeado a un tipo de dato de destino incompatible, tales mapeos pueden ser señalados como potencialmente incompatibles. Los campos mapeados con tipos de datos que son potencialmente incompatibles se muestran con un borde naranja:

Cuando pasas el cursor sobre el campo, se lista la razón de la potencial incompatibilidad. Para eliminar el mapeo, haz clic en el ícono Eliminar mapeo.

La indicación de un posible desajuste de tipo de datos aparece solo para mapeos simples de un objeto fuente a un campo de destino, y no se muestra si el campo de destino contiene lógica de scripting.

Para los campos de destino que se mapean utilizando lógica de scripting, después de que se procesa el script y se evalúa la salida resultante, el valor se convierte al tipo de dato del campo de destino al que se está mapeando. Se espera que sepas, basándote en la salida que se convierte al tipo de dato del campo de destino, si esta salida final es el resultado deseado.

Como ejemplo, considera un campo de destino con un tipo de dato double. Independientemente del tipo de dato en el script, después de que se procesa el script, la salida final para el mapeo se convierte a un double. Esto se ilustra con los ejemplos de scripts de transformación a continuación.

<trans>
1 + "string"
</trans>

El script anterior evalúa a un valor de "1string" con un tipo de dato string. Luego, durante el procesamiento del mapeo de transformación, esta salida se convierte a un tipo de dato double. Debido a que la salida comienza con un dígito, cualquier dígito(s) inicial(es) se trasladan a la salida final del mapeo, ya que los números son válidos para un double. La salida final para el mapeo es un valor de 1 con un tipo de dato double.

<trans>
"string" + 1
</trans>

El segundo script, anterior, evalúa a un valor de "string1" con un tipo de dato string. Durante el procesamiento del mapeo de transformación, esta salida se convierte a un tipo de dato double. En este caso, debido a que un valor no numérico, que no es válido para un double, está al principio del valor devuelto, no se traslada ningún valor. En su lugar, el campo de destino toma el valor predeterminado para un número. La salida final para el mapeo es un valor de 0 con un tipo de dato double.

En algunos casos, es posible que desees anular el tipo de dato del campo de destino y realmente trasladar la salida utilizando un tipo de dato diferente. Para estas situaciones, puedes usar las funciones Format o FormatDate dentro del script de mapeo del campo de destino. Asegúrate de que la función esté en la última declaración del script, ya que el valor devuelto del script siempre proviene de la última línea.

Reglas de validación

Para que una transformación sea válida, debe estar configurada correctamente. Los mensajes de error descritos a continuación se muestran al ver los errores de validación asociados con la transformación como un componente desde el lienzo de diseño o el panel del proyecto, como se describe en Validez del componente.

Si una transformación no ha sido configurada o está mal configurada, se devuelve el siguiente mensaje de error de validación:

La transformación no está configurada correctamente.

Este mensaje aparece con mayor frecuencia cuando se ha agregado una nueva transformación a una operación y aún no ha sido configurada. Para resolver este error, abre la pantalla de configuración de la transformación y configura la transformación en consecuencia. No es necesario que una transformación contenga mapeos si su esquema de destino consiste únicamente en nodos sin campos. Si el esquema de destino contiene campos, debe haber al menos un mapeo presente para que la transformación esté configurada correctamente.

Además, para que una transformación sea válida, no debe tener errores de validación dentro de la propia transformación. Para ser considerada válida, una transformación debe cumplir con estas reglas:

• Un mapeo no puede contener referencias a campos o variables que no existen.
• Un mapeo no puede contener conflictos de tipo de datos.
• Un mapeo debe utilizar una sintaxis de script válida.
• Un nodo de bucle de destino no puede tener múltiples fuentes.
• Se debe proporcionar un esquema para una actividad de fuente o destino adyacente.

Además, ciertos campos de destino pueden requerir un mapeo o pueden no permitir un mapeo. Por ejemplo, los campos unidos de una tabla hija no pueden ser mapeados. Los mapeos inválidos se indican visualmente dentro de la pantalla de configuración de la transformación, como se describe en Errores de validación anteriormente en esta página.

Dependiendo del error, se devuelve la variación apropiada de estos posibles mensajes de error si no se cumple esta regla:

El mapeo se refiere a un campo [fuente / destino / variable] que no existe $[ruta].

Conflicto potencial de tipo de dato en el mapeo.

El campo de destino $[node.name] [debe ser mapeado / no puede ser mapeado].

El campo de destino $[node.name] está vinculado a [uniones de base de datos] de su padre. No se puede mapear un valor a este elemento.

registros: Error en la línea [#]: [Error de sintaxis de validación de script].

Los mapeos de un nodo de bucle de destino dependen de más de un nodo de bucle de fuente.

Se debe proporcionar un esquema [Fuente / Destino].

Para resolver estos errores, intente estos consejos de solución de problemas:

• Si tiene referencias a campos que no existen, conflictos de tipo de dato u otros mapeos inválidos, encuentre el mapeo inválido y desmapee o verifique el esquema para asegurarse de que todos los campos estén contabilizados y tengan tipos de datos compatibles. Si tiene referencias a variables que no existen, verifique que la variable exista.
• Si tiene errores de validación de script, revise el mapeo y haga ajustes dentro del script. Los mensajes de validación también se muestran debajo de cada script reportado línea por línea. Después de resolver un error en una línea, pueden informarse errores de sintaxis adicionales para las líneas siguientes. Continúe haciendo cambios hasta que el mensaje indique que el script es válido.
• Si tiene actividades de fuente o destino adyacentes a la transformación, asegúrese de proporcionar un esquema para cada una. Puede proporcionar esquemas desde dentro de la actividad misma durante su configuración (consulte la documentación para cada conector), o definiendo un esquema directamente dentro de la transformación.

Además, si una transformación es inválida por alguna otra razón que no se puede determinar fácilmente, se devuelve el siguiente mensaje de error:

La transformación es inválida.

Para obtener más información sobre prevención y solución de problemas, consulte los siguientes recursos:

• Probar y validar transformaciones para detectar problemas temprano.
• Estructuras de datos en Conceptos clave para una estructura adecuada.
• Procesamiento de esquemas para reglas de conversión de datos.