Home > Engine & Repository

Administration du référentiel

Cette section décrit l'administration des référentiels EBX.Platform, leur installation et leur migration.

• Architecture technique

• Installation d'un nouveau référentiel

• Migration automatique du système de fichiers

• Sauvegarde du référentiel

• Attributs du référentiel

• Configuration d'une source de données

• Répertoire de stockage des archives

• Supervision et purges

Architecture technique

Cette section décrit les contraintes d'installation et de déploiement du référentiel.

Un référentiel unique par Machine Virtuelle Java (JVM)

Une JVM qui exécute EBX.Platform est limitée à un référentiel unique.

Une JVM par référentiel

Un référentiel ne peut pas être partagé par plusieurs JVMs. Si une telle situation se produit, cela peut conduire à des comportements imprévisibles.

Dans cette version, EBX.Platform n'assure pas de verrouillage qui garantirait la contrainte ci-dessus. Ainsi, il est de la responsabilité de l'administrateur de veiller au respect de cette contrainte.

Exception: plusieurs JVMs pourraient partager un référentiel unique si elles n'effectuent pas des mises à jour sur ce référentiel.

Plusieurs référentiels par base de données relationnelle

EBX.Platform supporte plusieurs référentiels sur une même instance de base de données relationnelle. Ceci est possible par spécification de préfixes de tables différents (propriété ebx.persistence.table.prefix ).

Installation d'un nouveau référentiel

Si la connexion spécifiée par EBX.Platform dispose, sur la base de données relationnelle, des droits de création de tables et d'index alors l'installation du référentiel sur la base de données est exécutée automatiquement. Dans le cas contraire, l'administrateur devra exécuter les scripts SQL qui se trouvent dans le fichier ebx.jar aux emplacements suivants : 

• com/onwbp/adaptation/rep/rdb/oracle/ddl.sql pour Oracle.

• com/onwbp/adaptation/rep/rdb/db2/ddl.sql pour DB2. Notons que sur DB2 Z/OS, le type BIGINT n'est supporté qu'à partir de la "version 9.1". Pour les versions inférieures, il est possible d'utiliser le format DECIMAL(19,0) en lieu et place du type BIGINT. Il faut donc remplacer le type BIGINT du fichier "ddl.sql" par le type DECIMAL(19,0), si on travaille avec des versions de Z/OS inférieures à la "version 9.1".

• com/onwbp/adaptation/rep/rdb/h2/ddl.sql pour H2.

• com/onwbp/adaptation/rep/rdb/hsql/ddl.sql pour HSQLDB.

• com/onwbp/adaptation/rep/rdb/sqlserver/ddl.sql pour SQL Server.

• com/onwbp/adaptation/rep/rdb/postgresql/ddl.sql pour PostgreSQL.

Si la propriété ebx.persistence.table.prefix possède une valeur spécifique, l'administrateur devra au préalable préfixer les noms de toutes les tables et index avec cette valeur.

Migration automatique d'un référentiel 3.7

Si la base de données cible est vide et le référentiel source de la version 3.7 est correctement situé, EBX.Platform effectue une migration automatique du référentiel source. Ceci est effectué au démarrage du serveur (plus précisément lorsqu'une première requête sollicite le cache d'initialisation de EBX.Platform).

Le processus est le suivant :

1. Installer un nouvel environnement EBX.Platform. Le fichier ebx.properties doit faire référence à un référentiel spécifique à travers les propriétés ebx.persistence.factory, ebx.persistence.url et optionnellement ebx.persistence.table.prefix .

2. Fournir un référentiel source. Le dossier ebxRepository/Adaptation/ doit contenir un référentiel fileSystem_3.5 comme source de l'installation.

3. Optionnellement, éditer le fichier ebxRepository/Adaptation/.ebx-private .  La valeur de la propriété repositoryId doit être changée afin d'être unique dans l'entreprise (elle doit avoir 12 chiffres hexadécimaux).

4. Démarrer le nouvel environnement EBX.Platform et lancer EBX.Manager.

La migration se terminera seulement si tous les schémas utilisés par l'adaptation, dans le référentiel à migrer, sont corrects (pas d'erreurs de validation).

Ce processus permet d'installer plusieurs référentiels sur une instance de base de données relationnelle unique (par spécification de préfixes distincts sur la propriété ebx.persistence.table.prefix ).

Sauvegarde du référentiel

La sauvegarde du référentiel doit être assurée par le SGBDR (Système de Gestion de Base de Données Relationnelles) sous-jacent. L'administrateur de la base de données doit utiliser les procédures standards de sauvegarde de cette base de données.

Attributs du référentiel

Un référentiel a les attributs suivants :

• repositoryId. Il identifit de façon unique un référentiel (au moins au niveau d'une entreprise) : Il est codé sur 48 bits (6 bytes) et il est généralement représenté avec 12 chiffres hexadécimaux. Cette information est utilisée pour générer l'UUID (Universally Unique Identifier) des entités créées dans le référentiel et également des transactions enregistrées par la piste d'audit (cela joue le rôle de la partie « noeud UUID », comme spécifiée par le RFC 4122 ).

• repository label. Il fournit un label pour l'utilisateur afin qu'il sache l'objectif et le contexte du référentiel (par exemple, « environnement de production »).

• store format. Il définit le système de persistence sous-jacent, la version courante et sa structure.

Configuration d'une source de données

La source de données de persistance ou de sauvegarde du référentiel doit être configurée par l'administrateur dans la partie persistance du fichier ebx.properties . Il peut effectuer cette configuration de façon totalement manuelle, ou alors spécifier une JNDI (Java Naming and Directory Interface) sur son serveur J2EE qui va ainsi définir la connexion à cette source de données (à titre d'exemple, voir la configuration d'une source de données Oracle sur le Serveur d'Application WebSphere 6 ou la configuration d'une source de données SQL Server sur le Serveur d'Application WebSphere 6 ).

Répertoire de stockage des archives

Les archives sont stockées dans un sous-répertoire archives de ebx.repository.directory (voir configuration ). Ce répertoire est créé automatiquement lors du premier export.

Il est néanmoins possible de le créer manuellement, auquel cas une attention particulière doit être apportée aux droits d'accès. Le processus qui exécute EBX.Platform doit pouvoir y lire et écrire.

Nota bene : Le transfert entre plusieurs référentiels EBX.Platform doit se faire indépendamment du produit. Pour ce transfert, des outils comme FTP, CFT, ou encore de simples recopies via des partages réseaux remplissent parfaitement ce rôle.

De même, le nettoyage de ce répertoire n'est pas assuré par EBX.Platform et est de la responsabilité de l'administrateur.

Le schéma ci-après décrit cette procédure :

Supervision et purges

Exécution du serveur d'application

La supervision de EBX.Platform s'effectue au travers de la supervision du serveur d'application.

Base de données relationnelle

La supervision du référentiel de la source de données s'effectue au travers de la supervision du système de SGBD qui a été configuré.

Système de fichiers

Afin de garantir un fonctionnement correct du logiciel, l'utilisation et la disponibilité des disques doivent être surveillées pour les répertoires suivants :

• piste d'audit :  ${ ebx.repository.directory }/History/

• archives :  ${ ebx.repository.directory }/archives/

• journaux (logs) : ebx.logs.directory

• répertoire temporaire : ebx.temp.directory

Il est important de noter que :

• Le nettoyage des répertoires sus-mentionnés n'est pas assuré par EBX.Platform. Il est de la responsabilité de l'administrateur . 

• Pour la piste d'audit, si des transactions volumineuses sont exécutées avec le détail activé des mises à jour effectuées (cas par défaut), l'espace disque utilisé peut augmenter rapidement . Pour plus d'informations, consulter la section Piste d'audit .

Voir aussi la section configuration / tuning .

Référentiel EBX.Platform

Certaines entités sont accumulées durant l'exécution de EBX.Platform. Il relève de la responsabilité de l'administrateur de les surveiller et purger périodiquement.

Branches et versions

Afin de conserver une taille raisonnable du cache et du référentiel, il est recommandé de fermer les branches et les versions quand elles ne sont plus utilisées et de périodiquement les purger. Pour plus d'information, consulter la section Branches & versions : purge & réouverture .

Interactions utilisateur

Les interactions utilisateur sont utilisées par le Manager Component comme un moyen fiable pour une application d'initier et d'obtenir le résultat de l'exécution d'un service. Ces interactions sont persistées dans la branche technique "ebx-interactions". Il est recommandé de surveiller et, si besoin, nettoyer la table des interactions.

Workflow history

Les événements du workflow sont persistés dans la table d'historique du workflow, dans la branche technique "ebx-workflow-execution". Cette table est remplie de façon continue. Il est recommandé de supprimer régulièrement les anciens enregistrements.

Home > Engine & Repository