Después: la correlación de datos gráfica convertida

Después de haber actualizado la correlación de mensajes, debería revisar y corregir las transformaciones en la correlación de datos gráfica a fin de que se comportara de la misma forma que la correlación de mensajes original.

La imagen siguiente muestra la configuración de la correlación de datos gráfica convertida de la correlación denominada MembersMFPFlow_Mapping.map:

La correlación del caso de ejemplo convertida en una correlación de datos gráfica con todos los comportamientos de transformación verificados.

Las transformaciones se actualizan como parte de la solución, de forma que aunque las transformaciones ahora sean de distinto tipo, se comportan de la misma forma que la correlación de mensajes. Puede probarlo siguiendo los pasos de Verificación de la solución después de seguir los pasos para Implementación de la solución para el escenario de conversión de correlación de mensajes.

Las correlaciones de datos gráficas utilizan todas las funciones 2.0 XPath estándar y permiten funciones escritas por el usuario en Java™ y ESQL. Las correlaciones de mensajes utilizaban XPath básico 1.0, algunas funciones de correlación ESQL incorporadas de propiedad y funciones Java y ESQL escritas por el usuario.

No todas las funciones ESQL se pueden convertir directamente a equivalentes de XPath, pero estas funciones se resuelven en la solución del escenario. En la captura de pantalla puede observar estos cambios en los elementos siguientes:

  • MEMBER_NAME_PART.PERSON_GIVEN_NAMES ahora se establece utilizando expresiones XPath estándar para comprobar si el mensaje de entrada tiene caracteres que no sean de espacio en blanco en PERSON_MIDI_NAME. El editor de correlaciones de datos gráficas proporciona aquí un aviso porque la lógica de la correlación supone que el mensaje de entrada tiene MEMBER_NAME_PARTS presente, que se define como una opción en el modelo de esquema de mensajes con MEMBER_NAME_WHOLE. Para este escenario, el autor de la correlación de mensajes original ha supuesto que los datos de entrada incluirán siempre MEMBER_NAME_PARTS, por lo que según esta suposición se puede ignorar el aviso.

    Para evitar este aviso, y el de la correlación PERSON_SURNAME, puede añadir una comprobación If / Else para MEMBER_NAME_PARTS o MEMBER_NAME_WHOLE.

  • MEMBER_AGE_GROUP se establece utilizando una llamada a la función ESQL escrita por el usuario ageRange(). Esto no ha cambiado.
  • MEMBER_INT_GROUP se establece utilizando una construcción If / Else, que continúa utilizando una expresión XPath estándar para la condición de transformación.
  • MEMBER_COMMENT1 ahora se establece utilizando expresiones XPath estándar que sustituyen a las funciones ESQL de propietario anteriores en el editor de correlaciones de mensajes.
  • MEMBER_COMMENT2 y MEMBER_COMMENT3 se establecen llamando a funciones ESQL escritas por el usuario commentPart2() y commentPart3(). Ha sido necesario añadir una expresión condicional XPath para evitar la invocación del ESQL commentPart3() cuando la longitud de los datos de entrada es menor de 48 caracteres. Esto corrige una diferencia de comportamiento para funciones ESQL de usuario que pueden devolver un valor de ESQL NULL. Para obtener más información sobre los cambios ESQL en la correlación, consulte Conversión de una correlación de mensajes heredada que incluye funciones de correlación ESQL.

Ahora puede volver a crear estos cambios utilizando sus propios archivos o los archivos de escenario que se proporcionan siguiendo los pasos como parte de Implementación de la solución para el escenario de conversión de correlación de mensajes.