Errores y reglas de validación de mapeo de Transformación en Jitterbit Integration Studio

Introducción

Las asignaciones de Transformación deben ser válidas para que una transformación sea válida. En esta página se explica cómo identificar asignaciones no válidas y ver los errores de validación asociados a ellas, así como también cómo resolver errores de validación.

Errores de validación

Las Transformaciones se tratan de la misma manera que otros componentes del proyecto cuando se identifica la validez de los componentes a escala del proyecto. Es decir, puede identificar las transformaciones no válidas en el tela de diseño y en el panel del proyecto como se describe en Validez del componente. Los errores de validación dentro de un mapeo se incluyen en la validación de las transformaciones.

Para que una transformación sea válida, no debe tener ningún error de validación dentro de la propia transformación. Para que se considere válida, una transformación debe cumplir estas reglas:

• Un mapeo no puede contener referencias a campos o variables inexistentes.
• Una asignación no puede contener conflictos de tipos de datos.
• Una asignación debe utilizar una sintaxis de secuencia de comandos válida.
• Un nodo de bucle de destino no puede tener múltiples fuentes.
• Se debe proporcionar un esquema para una actividad de origen o destino adyacente.

Además, es posible que ciertos campos de destino requieran una asignación o no la permitan. Por ejemplo, no es posible asignar los campos unidos de una tabla secundaria. Se proporcionan detalles adicionales en Reglas de validación más adelante en esta página.

Para resolver esos errores, puede identificar errores dentro de la propia transformación y realizar los ajustes correspondientes. Las asignaciones no válidas se muestran para un bloque de campo de destino completo o para objetos asignados individualmente dentro de un bloque de campo de destino.

Todo el campo objetivo

Cuando la asignación de un campo de destino completo no es válida, aparece una línea vertical roja a lo largo del lado izquierdo del bloque del campo de destino, una El icono de advertencia se muestra en la parte superior derecha del campo de destino. Al pasar el cursor sobre el icono de advertencia, se indica el motivo por el cual la asignación no es válida.

Este tipo de asignación no válida puede resultar de la asignación de campos que no se pueden asignar, por ejemplo, al intentar asignar a un ID de objeto único en una actividad de inserción de Salesforce utilizado como objetivo.

Cuando la asignación de un campo de destino completo es potencialmente inválida, aparece una línea vertical naranja a lo largo del lado izquierdo del bloque del campo de destino. Al pasar el cursor sobre el campo, se muestra el motivo por el cual la asignación es potencialmente inválida.

Este tipo de asignación inválida puede ser resultado de la ausencia de una asignación que puede ser necesaria, por ejemplo, de una clave principal que no está asignada en una actividad de inserción de base de datos utilizado como objetivo.

Las asignaciones no válidas o potencialmente no válidas también pueden resultar de múltiples objetos (como más de un objeto o variable de origen) que se asignan a un campo de destino sin ninguna lógica que especifique cómo procesar esos objetos.

Para resolver asignaciones no válidas, elimine la asignación o abra el campo en modo de secuencia de comandos para agregar lógica de procesamiento. Las asignaciones potencialmente no válidas tienen como objetivo señalar un problema potencial, pero se pueden dejar "tal como están" si ha determinado que la asignación es válida.

Para eliminar una asignación, pase el cursor sobre el campo de destino y utilice el Icono quitar mapeo.

Para abrir un campo con una asignación no válida en el modo de secuencia de comandos para agregar lógica de procesamiento, pase el cursor sobre los campos de destino y haga clic en el botón Editar icono.

Objeto individual mapeado

Cuando un objeto individual mapeado dentro de un campo de destino no es válido, el objeto mapeado se resalta en rojo con un icono de advertencia que se muestra a la derecha:

Las asignaciones individuales pueden no ser válidas si un objeto de origen asignado ya no está presente después de editar un esquema, si hay una discrepancia obligatoria/opcional con la cardinalidad de un campo de destino o si los campos de origen y de destino tienen tipos de datos incompatibles.

La asignación de campos de origen y destino con tipos de datos potencialmente incompatibles está marcada para todos los esquemas, independientemente de si tienen tipos de datos definidos, como aquellos definidos a partir de una actividad de Salesforce o de base de datos, o si solo tienen etiquetas de tipo de datos, como aquellas definidas a partir de un archivo de muestra o que se han definido manualmente (para estos tipos de esquemas, todos los campos se manejan como cadenas independientemente de si tienen etiquetas de tipo de datos).

Una discrepancia en el tipo de datos no necesariamente indica que haya un problema con la asignación. Por ejemplo, si un campo de origen con un tipo de datos entero se asigna a un campo de destino con un tipo de datos de cadena, los datos resultantes son una cadena que contiene un valor numérico. Los campos de origen con cualquier tipo de datos se pueden asignar a un campo de destino con un tipo de datos de cadena, por lo que estas asignaciones no se marcan de ninguna manera.

Sin embargo, si ocurre lo contrario y un campo de origen con una cadena u otro tipo de datos se asigna a un tipo de datos de destino no coincidente, dichas asignaciones pueden marcarse como potencialmente incompatibles. Los campos asignados con tipos de datos que son potencialmente incompatibles se muestran con un borde naranja:

Al pasar el cursor sobre el elemento, se muestra el motivo de la posible incompatibilidad. Para eliminar la asignación, haga clic en el icono Icono quitar mapeo.

Tenga en cuenta que la indicación de una posible falta de coincidencia de tipo de datos aparece solo para asignaciones simples de un objeto de origen a un campo de destino, y no se muestra si el campo de destino contiene lógica de script.

En el caso de los campos de destino que se asignan mediante lógica de scripts, después de que se procesa el secuencia de comandos y se evalúa el resultado, el valor se convierte al tipo de datos del campo de destino al que se está asignando. Se espera que el usuario sepa, en función del resultado que se convierte al tipo de datos del campo de destino, si este resultado final es el deseado.

A modo de ejemplo, supongamos que el campo de destino es un double tipo de datos. Independientemente del tipo de datos en el secuencia de comandos, después de que se procesa el secuencia de comandos, la salida final para la asignación se convierte en un double Esto se ilustra con los ejemplos de secuencia de comandos de transformación que aparecen a continuación.

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

El secuencia de comandos anterior evalúa un valor de "1string" con un string tipo de datos. Luego, durante el procesamiento de la asignación de transformación, esta salida se convierte en un double tipo de datos. Debido a que la salida comienza con un dígito, cualquier dígito inicial se trasladará a la salida de mapeo final, ya que los números son válidos para un double El resultado final del mapeo es un valor de 1 con un double tipo de datos.

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

El segundo secuencia de comandos, arriba, evalúa un valor de "string1" con un string tipo de datos. Durante el procesamiento de la asignación de transformación, esta salida se convierte en un double tipo de datos. En este caso, debido a que un valor que no es un dígito, que no es válido para un double, está al principio del valor devuelto, no se transfiere ningún valor. En cambio, el campo de destino toma el valor predeterminado para un número; es decir, la salida final para la asignación es un valor de 0 con un double Tipo de datos.

En algunos casos, es posible que desee anular el tipo de datos del campo de destino y transferir la salida utilizando un tipo de datos diferente. Para estos casos, puede utilizar el Format o FormatDate Funciones dentro del secuencia de comandos de mapeo de campos de destino. Asegúrese de que la función esté en la última declaración del secuencia de comandos, ya que el valor devuelto del secuencia de comandos siempre proviene de la línea final.

Reglas de validación

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

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

Transformation is not configured properly.

Este mensaje aparece con mayor frecuencia cuando ha agregado una nueva transformación a una operación y aún no se ha configurado. Para resolverlo, abra la pantalla de configuración de la transformación y luego configure la transformación según corresponda. No es necesario que una transformación contenga asignaciones si su esquema de destino consta solo de nodos sin campos. Si el esquema de destino contiene campos, debe estar presente al menos una asignación para que la transformación se configure correctamente.

Además, para que una transformación sea válida, no debe tener ningún error de validación dentro de la propia transformación. Para que se considere válida, una transformación debe cumplir estas reglas:

• Un mapeo no puede contener referencias a campos o variables inexistentes.
• Una asignación no puede contener conflictos de tipos de datos.
• Una asignación debe utilizar una sintaxis de secuencia de comandos válida.
• Un nodo de bucle de destino no puede tener múltiples fuentes.
• Se debe proporcionar un esquema para una actividad de origen o destino adyacente.

Además, es posible que ciertos campos de destino requieran una asignación o no la permitan. Por ejemplo, no es posible asignar los campos unidos de una tabla secundaria. Las asignaciones no válidas se indican visualmente en la pantalla de configuración de la transformación, como se explica 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:

Mapping refers to a non-existent [source / target / variable] field $[path].

Potential data type conflict in mapping.

Target field $[node.name] [must be mapped / cannot be mapped].

Target field $[node.name] is linked to [database joins] of its parent. You cannot map a value to this element.

records: Error on line [#]: [Script validation syntax error].

Mappings of a target loop node depend on more than one source loop node.

[Source / Target] schema must be provided.

Para resolverlo, pruebe estos consejos de solución de problemas:

• Si tiene referencias a campos inexistentes, conflictos de tipos de datos u otras asignaciones no válidas, busque la asignación no válida y desasignela o verifique el esquema para asegurarse de que se tengan en cuenta todos los campos y de que tengan tipos de datos compatibles. Si tiene referencias a variables inexistentes, verifique que la variable variable existe.
• Si tiene errores de validación de secuencia de comandos, verifique la asignación y realice ajustes dentro del secuencia de comandos. Los mensajes de validación también se muestran debajo de cada secuencia de comandos, informados línea por línea. Es decir, después de resolver un error en una línea, es posible que se informen errores de sintaxis adicionales para resolver en las líneas posteriores. Continúe realizando cambios hasta que el mensaje indique que el secuencia de comandos es válido.
• Si tiene un nodo de bucle de destino que depende de más de un nodo de bucle de origen, siga las instrucciones proporcionadas en Mapeo desde una fuente de múltiples instancias a un destino de instancia única en Estructuras de datos.
• Si tiene actividades de origen o destino adyacentes a la transformación, asegúrese de proporcionar un esquema para cada una. Los esquemas se pueden proporcionar desde dentro de la actividad durante su configuración (consulte la documentación de cada conector), o bien definiendo un esquema directamente desde dentro de la transformación.

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

Transformation is invalid.