Errores y reglas de validación del 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. Esta página explica cómo identificar asignaciones no válidas, ver los errores de validación asociados y resolverlos.

Errores de validación

Las Transformaciones se tratan igual que otros componentes del proyecto al identificar la validez de los componentes a escala del proyecto. Es decir, se pueden identificar transformaciones no válidas en el tela de diseño y en el panel del proyecto como se cubre 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 contener errores de transformación. Para ser considerada 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, ciertos campos de destino pueden requerir una asignación o no permitirla. 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 solucionar estos errores, puede identificarlos dentro de la propia transformación y realizar los ajustes necesarios. 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 completa de un campo objetivo no es válida, aparece una línea vertical roja a la izquierda del bloque del campo objetivo. El icono de advertencia se muestra en la esquina superior derecha del campo de destino. Al pasar el cursor sobre él, 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 completa de un campo de destino es potencialmente inválida, aparece una línea vertical naranja a la izquierda del bloque del campo de destino. Al pasar el cursor sobre el campo, se indica el motivo de la posible inválida.

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

También pueden producirse asignaciones no válidas o potencialmente no válidas si se asignan varios objetos (por ejemplo, más de un objeto o variable de origen) 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 secuencia de comandos para agregar lógica de procesamiento. Las asignaciones potencialmente no válidas tienen como objetivo señalar un posible problema, pero pueden dejarse como están si se 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 icono Icono Editar.

Objeto individual mapeado

Cuando un objeto individual mapeado dentro de un campo de destino no es válido, se resalta en rojo con un Icono de advertencia 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 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 desde una actividad de Salesforce o de base de datos, o si solo tienen etiquetas de tipo de datos, como aquellas definidas desde 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 indica necesariamente un problema con la asignación. Por ejemplo, si un campo de origen con un tipo de dato entero se asigna a un campo de destino con un tipo de dato de cadena, el resultado es una cadena que contiene un valor numérico. Los campos de origen con cualquier tipo de dato se pueden asignar a un campo de destino con un tipo de dato 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 dato se asigna a un tipo de dato de destino no coincidente, dichas asignaciones pueden marcarse como potencialmente incompatibles. Los campos asignados con tipos de datos potencialmente incompatibles se muestran con un borde naranja:

Al pasar el cursor, se indica 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 del 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 asignados mediante lógica de script, tras procesar el secuencia de comandos y evaluar la salida resultante, el valor se convierte al tipo de datos del campo de destino al que se asigna. Se espera que el usuario sepa, basándose en la salida convertida al tipo de datos del campo de destino, si esta salida final es la deseada.

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 secuencia de comandos, la salida final de 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 dato. Luego, durante el procesamiento de la transformación, esta salida se convierte en un double Tipo de dato. Dado que la salida comienza con un dígito, cualquier dígito inicial se transferirá 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 dato.title="Transformation Script 2" <trans> "string" + 1 </trans>

El segundo secuencia de comandos, arriba, evalúa a un valor de "string1" con un string tipo de dato. Durante el procesamiento de la asignación de transformación, esta salida se convierte en un double tipo de dato. 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 su lugar, el campo de destino toma el valor predeterminado de un número; es decir, el resultado final de la asignación es un valor de 0 con un double Tipo de dato.

En algunos casos, puede que desee sobrescribir el tipo de dato del campo de destino y transferir la salida con un tipo de dato diferente. Para ello, puede usar el Format o FormatDate Funciones dentro del secuencia de comandos de mapeo del campo de destino. Asegúrese de que la función esté en la última instrucción del secuencia de comandos, ya que el valor devuelto siempre proviene de la última secuencia de comandos.

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 a la transformación como componente desde el tela de diseño o panel del proyecto como se cubre en Validez del componente.

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

La Transformación no está configurada correctamente.

Este mensaje suele aparecer cuando se ha añadido una nueva transformación a una operación y aún no se ha configurado. Para solucionarlo, abra la pantalla de configuración de la transformación y transformación como corresponda. No es necesario que una transformación contenga asignaciones si su esquema de destino consta únicamente 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 contener errores de transformación. Para ser considerada 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, ciertos campos de destino pueden requerir una asignación o no permitirla. 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:

La asignación se refiere a un campo $[ruta] inexistente de origen/destino/variable.

Posible conflicto de tipos de datos en el mapeo.

Campo de destino $[node.name] [debe asignarse / no puede asignarse].

El campo de destino $[node.name] está vinculado a las [joins de base de datos] de su elemento principal. No se puede asignar un valor a este elemento.

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

Las asignaciones de un nodo de bucle de destino dependen de más de un nodo de bucle de origen.

Se debe proporcionar el esquema [Origen / Destino].

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 todos los campos se tengan en cuenta y tengan tipos de datos compatibles. Si tiene referencias a variables inexistentes, verifique que variable existe. Si tiene errores de validación de secuencia de comandos, revise 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, reportados línea por línea. Es decir, después de resolver un error en una línea, podrían reportarse errores de sintaxis adicionales para 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 Mapa de un origen 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 pueden proporcionarse desde dentro de la actividad durante su configuración (consulte la documentación de cada conector), o bien definiendo un esquema desde directamente 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:

La Transformación no es válida.