WebSphere Message Broker, Versão 8.0.0.5 Sistemas operacionais: AIX, HP-Itanium, Linux, Solaris, Windows, z/OS

Consulte as informações sobre a versão mais recente do produto em IBM Integration Bus, Versão 9.0

Representação dos Tipos de Dados de Data/Hora do ESQL

Quando seu aplicativo envia uma mensagem para um intermediário, a forma como os dados da mensagem são interpretados depende do conteúdo da própria mensagem e da configuração do fluxo de mensagens. Se o seu aplicativo envia uma mensagem a ser interpretada pelo analisador XML genérico ou o analisador MRM, que é ajustado por um formato físico XML, o aplicativo pode incluir dados de data ou hora que são representados por qualquer um dos tipos de dados primitivos de data/hora de Esquema XML.

O tipo de dados do Esquema XML de cada parte dos dados é convertido para um tipo de dados ESQL e o elemento que é criado na árvore de mensagens lógicas é do tipo convertido. Se os dados de datetime em uma mensagem de entrada não corresponderem às regras do tipo de dados do esquema escolhido, os valores que o analisador grava na árvore de mensagens lógicas serão modificados, mesmo que a mensagem esteja no domínio MRM e você tenha configurado o fluxo de mensagens para validar a mensagem de entrada. (A validação não está disponível para mensagens XML genéricas).

Isso tem o seguinte efeito nos subcampos dos dados de data e hora de entrada:

Os seguintes exemplos ilustram esses pontos.

Tipo de dados do Esquema XML de Dados de Entrada Regras do esquema Valor de entrada no fluxo de bits Valor gravado na árvore lógica (tipo de dados ESQL entre colchetes)
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)

Validação com Subcampos Ausentes

Ao considerar o tipo de dados de data/hora do esquema a ser usado, considere que, se a mensagem estiver no domínio MRM e você configurar o fluxo de mensagens para validar as mensagens, os subcampos ausentes poderão causar exceções de validação.

Os tipos de dados do esquema Gday, gMonth, gMonthDay, gYear e gYearMonth são utilizados para registrar períodos de tempo recorrentes específicos. Existe uma confusão potencial quando a validação é ativada, porque os períodos de tempo recorrentes que são utilizados nesses tipos de dados do esquema são armazenados pelo ESQL como pontos específicos no tempo.

Por exemplo, quando o 24º dia do mês, que é um tipo gDay (um dia do mês), é gravado na árvore lógica, os subcampos de mês e ano ausentes são fornecidos a partir da época (janeiro de 1970) para fornecer a data específica 1970-01-24. Se você codificar o ESQL para manipular essa data, por exemplo, incluindo um intervalo de 10 dias e, em seguida, gerar uma mensagem de saída validada, surgirá uma exceção. Isso ocorre porque o resultado do cálculo é 1970-02-03, o que é inválido porque o subcampo de mês da data não corresponde mais à data da época.

Uso em um Domínio do MRM

No MRM é possível definir um elemento que possui o tipo lógico igual a dateTime.

Quando um elemento dateTime é analisado, um campo é criado na árvore de mensagens, possuindo o tipo de dados ESQL igual a CURRENT_TIME ou CURRENT_TIMESTAMP. Entretanto, os tipos de dados CURRENT_TIME e CURRENT_TIMESTAMP não possuem a funcionalidade para armazenar informações de fuso horário e o MRM não ajusta o horário de acordo com o fuso horário de entrada e o fuso horário do broker.

Embora os tipos de dados CURRENT_TIME e CURRENT_TIMESTAMP não possam armazenar informações de fuso horário, o MRM armazena estas informações como parte do campo subjacente. Isto significa que, se o campo for copiado entre árvores de mensagens, as informações de fuso horário serão copiadas com ele, permitindo que estas informações sejam preservadas na saída.

Observe que as informações são preservadas somente se o campo for copiado em um campo do mesmo nome.

Entretanto, se qualquer novo campo for derivado do campo original, o novo campo não terá as informações de fuso horário. Isto significa que, se um campo desse tipo for convertido como um caractere, o novo campo assumirá o fuso horário do broker, mas seu valor não será ajustado para qualquer diferença entre o fuso horário de entrada e o fuso horário do broker.

Por exemplo, um elemento dateTime de entrada contendo 2009-02-20T06:08:07-08:00 poderia ser copiado a partir da árvore de mensagens de entrada na árvore de mensagens de saída e aparecer em uma mensagem de saída exatamente no mesmo formato. Entretanto, se o elemento for convertido como caractere, usando o formato IU, por um broker executando GMT, o resultado seria 2009-02-20T06:08:07.000Z.

Avisos | Marcas Registradas | Downloads | Biblioteca | Suporte | Feedback

Copyright IBM Corporation 1999, 2014Copyright IBM Corporation 1999, 2014.

        
        Última atualização:
        
        Última atualização: 2015-02-28 18:29:51


Tópico de ConceitoTópico de Conceito | Versão 8.0.0.5 | ak01005_