Représentation des horodatages dans WebSphere Business Monitor

Etant donné que WebSphere Business Monitor utilise plusieurs bases de données dans son composant de services de données, il est essentiel de comprendre comment les horodatages sont transformés par le système entre les bases de données lors de la réplication de bases.

Il existe de nombreuses configurations possibles pour les topologies WebSphere Business Monitor. Vous devez savoir comment configurer ces topologies pour obtenir les résultats d'horodatage souhaités. Les serveurs concernés sont le serveur contenant la base de données d'exécution, le serveur contenant la base de données d'historique et le serveur sur lequel WebSphere Portal est installé, qui constitue l'emplacement de DB2 Alphablox. Si les rapports doivent comporter toutes les heures au format GMT (temps moyen de Greenwich), la base de données d'exécution, la base de données d'historique et les postes WebSphere Portal doivent utiliser des horloges système au format GMT. Tous les horodatages et rapports dimensionnels seront ainsi au format GMT.

Si vous voulez que toutes les heures s'affichent au format EST, tous les serveurs doivent être configurés comme il convient. Si vous voulez que les clients utilisent des zones d'heure différentes, il est conseillé de définir l'heure GMT sur tous les serveurs. Si les paramètres client au sein de WebSphere Portal n'utilisent pas l'heure GMT, des écarts peuvent apparaître entre les rapports qui utilisent des horodatages (qui utilisent les paramètres de WebSphere Portal) et les rapports qui effectuent des analyses dimensionnelles. Ces derniers utiliseront l'heure GMT. Des données techniques sont fournies ci-après.

Les colonnes d'horodatage dans la base de données d'état sont stockées sous la forme de longs types de données Java (horodatages Java sérialisés basés sur l'heure GMT). Ces horodatages transitant par les trois bases de données, ils sont convertis de ces types de données longs Java en horodatages DB2 au cours des étapes ETL entre les bases de données d'état et d'exécution. Cette opération est effectuée à l'aide d'UDF basé sur Java qui convertit les types de données longs en horodatages et retourne le type de données d'horodatage à DB2. A ce stade, les horodatages sont convertis, d'après les paramètres d'horloge du serveur qui héberge la base de données d'exécution. Si cette horloge système est configurée pour l'utilisation de l'heure GMT, ces horodatages sont convertis au format GMT ; sinon, ils seront convertis, en fonction des décalages de fuseau horaire et des décalages d'heure d'été de l'horloge système. Ils sont stockés dans DB2 avec ce fuseau horaire et non au format d'heure GMT. DB2 fournit des registres spéciaux pour l'extraction du décalage de fuseau horaire et leur application aux horodatages.

Les horodatages qui sont transférés dans la base de données d'historique ne sont pas convertis, car cette base de données stocke les horodatages dans le même format de fuseau horaire que le système d'exécution. Cela signifie que les serveurs de base de données d'exécution et d'historique doivent utiliser les mêmes paramètres de fuseau horaire. Au cours du processus d'extraction, de transformation et de chargement, ces horodatages sont comparés à la table DIM_TIME. La table DIM_TIME par elle-même ne comporte pas de fuseau horaire, mais lorsqu'elle est associée à un serveur de base de données, elle utilise les paramètres de fuseau horaire du serveur. Par conséquent, toutes les correspondances de la table DIM_TIME sont effectuées en supposant que la table DIM_TIME et l'horodatage recherché sont liés au fuseau horaire du serveur de la base de données d'historique, qui peut ne pas être au format d'heure GMT.

Le serveur qui héberge WebSphere Portal doit également utiliser le même fuseau horaire que les serveurs sur lesquels se trouvent les bases de données d'exécution et d'historique. A présent, lorsque les tableaux de bord interrogent les colonnes d'horodatage directement (sans utilisation de la dimension temporelle), l'architecture en cours suppose que le fuseau horaire des bases de données d'exécution et d'historique est le même que celui du serveur de tableau de bord. Les horodatages sont ensuite reconvertis en horodatages Java, et WebSphere Portal considère que les horodatages du serveur de base de données utilisent le même fuseau horaire que lui ; il reconvertit donc ensuite les horodatages en horodatage GMT, d'après ces paramètres. Un machine client peut utiliser différents paramètres de zone. Cela ne générera aucun incident tant que WebSphere Portal convertit correctement les horodatages GMT. Le seul moment où cette conversion a lieu est lorsque WebSphere Portal et les bases de données d'exécution et d'historique doivent utiliser les mêmes paramètres de fuseau horaire.

Le dernier élément n'est pas si simple en raison de la conception de la DIMENSION TIME dans WebSphere Business Monitor. Au cours de la phase d'extraction, de transformation et de chargement, plusieurs liens sont établis avec la DIMENSION TIME pour l'analyse DIMENSIONNELLE. La personne effectuant l'analyse doit considérer que, quels que soient les paramètres de fuseau horaire du client, les rapports sont basés sur le fuseau horaire des serveurs de base de données d'exécution et d'historique, sur lesquels a lieu la conversion de l'heure GMT vers l'heure locale de ces serveurs. Même si la granularité de la DIMENSION TIME n'est qu'au niveau d'une journée, une différence de fuseau horaire peut changer le JOUR auquel un enregistrement particulier s'est produit.


Copyright IBM Corporation 2005, 2006. All Rights Reserved.