Cuando la aplicación envía un mensaje a un intermediario, el modo en que se interpretan los datos del mensaje depende del contenido del propio mensaje y de la configuración del flujo de mensajes. Si la aplicación envía un mensaje adaptado mediante un formato físico XML para que lo interprete el analizador XML genérico o el analizador MRM, la aplicación puede incluir datos de fecha o de hora representados por cualquiera de los tipos de datos de fecha y hora primitivos del esquema XML.
El tipo de datos de esquema XML de cada fragmento de datos se convierte en un tipo de datos ESQL y el elemento creado en el árbol lógico de mensajes es del tipo convertido. Si los datos de fecha y hora de un mensaje de entrada no coinciden con las normas del tipo de datos del esquema elegido, los valores que escribe el analizador en el árbol lógico de mensaje se modifican incluso si el mensaje está en el dominio MRM y ha configurado el flujo de mensajes para validar el mensaje de entrada. (No está disponible la validación para mensajes XML genéricos.)
Esto tiene el efecto siguiente en los subcampos de los datos de fecha y hora de entrada:
Los ejemplos siguientes ilustran estos puntos.
Tipo de datos de esquema XML de datos de entrada | Normas del esquema | Valor de entrada en la corriente de bits | Valor escrito en el árbol lógico (tipo de datos ESQL entre paréntesis) |
---|---|---|---|
xsd:dateTime | CCYY-MM-DDThh:mm:ss | 2002-12-31T23:59:59 | 2002-12-31 23:59:59 (TIMESTAMP) |
--24 | 1970-01-24 (DATE) | ||
23:59:59 | 23:59:59 (TIME) | ||
xsd:date | CCYY-MM-DD | 2002-12-31 | 2002-12-31 (DATE) |
2002-12-31T23:59:59 | 2002-12-31 (DATE) | ||
-06-24 | 1970-06-24 (DATE) | ||
xsd:time | hh:mm:ss | 14:15:16 | 14:15:16 (TIME) |
xsd:gDay | ---DD | ---24 | 1970-01-24 (DATE) |
xsd:gMonth | --MM | --12 | 1970-12-01 (DATE) |
xsd:gMonthDay | --MM-DD | --12-31 | 1970-12-31 (DATE) |
xsd:gYear | CCYY | 2002 | 2002-01-01 (DATE) |
xsd:gYearMonth | CCYY-MM | 2002-12 | 2002-12-01 (DATE) |
Cuando estudie cuál es el tipo de datos de fecha y hora del esquema que va a utilizar, tenga en cuenta que si el mensaje está en el dominio MRM y configura el flujo de mensajes para validar mensajes, los subcampos que faltan pueden generar excepciones de validación.
Los tipos de datos del esquema Gday, gMonth, gMonthDay, gYear y gYearMonth se utilizan para registrar los períodos de tiempo recurrentes determinados. Es posible que se cree alguna confusión cuando se activa la validación porque los períodos de tiempo recurrentes que se utilizan en estos tipos de datos del esquema se almacenan mediante ESQL como puntos específicos del tiempo.
Por ejemplo, cuando se escribe en el árbol lógico el día 24 del mes, que es un tipo gDay (un día del mes), los subcampos de mes y año que faltan se proporcionan a partir de la época (Enero 1970) para así ofrecer la fecha específica 1970-01-24. Si codifica ESQL para manipular esta fecha, por ejemplo, añadiendo un intervalo de 10 días y, a continuación, genera un mensaje de salida que se valida, se genera un excepción. Esto es debido a que el resultado del cálculo es 1970-02-03, lo cual no es válido porque el subcampo del mes de la fecha ya no coincide con la fecha de la época.
En MRM, es posible definir un elemento que tenga el tipo lógico dateTime.
Cuando se analiza un elemento dateTime, se crea un campo en el árbol de mensaje que tiene el tipo de datos de ESQL CURRENT_TIME o CURRENT_TIMESTAMP. No obstante, los tipos de datos CURRENT_TIME y CURRENT_TIMESTAMP no tienen la funcionalidad de almacenar información de huso horario y el MRM no ajusta la hora según el huso horario de entrada y el huso horario del intermediario.
Aunque los tipos de datos CURRENT_TIME y CURRENT_TIMESTAMP no pueden almacenar información de huso horario, el MRM almacena esta información como parte del campo subyacente. Esto significa que, si el campo se copia entre árboles de mensajes, la información de huso horario se copia con él, lo que permite que esta información se conserve a la salida.
Tenga en cuenta que la información sólo se conserva si el campo se copia en un campo con el mismo nombre.
No obstante, si hay algún campo nuevo derivado del campo original, el campo nuevo no tendrá la información de huso horario. Esto significa que si dicho campo se convierte a caracteres, el nuevo campo adoptará el huso horario del intermediario, pero su valor no se ajustará para compensar ninguna diferencia entre el huso horario de entrada y el huso horario del intermediario.
Por ejemplo, un elemento dateTime de entrada que contenga 2009-02-20T06:08:07-08:00 se podría copiar del árbol de mensaje de entrada al árbol de mensaje de salida y aparecer en un mensaje de salida exactamente en el mismo formato. No obstante, si un intermediario que ejecute GMT convierte el elemento a caracteres utilizando el formato IU, el resultado será 2009-02-20T06:08:07.000Z.