AXOPEN

Fonctionnement des numéros internes (ONB) sous Planisware

Description

Dans une application développée sous Planisware les objets d’environnement (formules nommées, alertes, champs supplémentaires…) et les objets de planification (tâches, affectations…) possèdent tous, à quelques exceptions près, un identifiant interne appelé ONB. Cet ONB permet d’identifier de manière unique chacun des objets de l’application.

Le but de cet article est de préciser le fonctionnement de ces numéros internes et en particulier la manière dont ils sont générés afin d’éviter tout doublon.

Génération automatique des ONB

L’ONB d’un objet est attribué lors de sa création. Pour assurer son unicité, l’ONB d’un nouvel objet est généré automatiquement par Planisware à partir d’un compteur interne. Ainsi à chaque nouvelle création le compteur est incrémenté empêchant ainsi la réutilisation d’un numéro déjà attribué.

Comme tous les compteurs incrémentaux de Planisware le compteur dédié aux ONB est défini dans la table « OPX2_SEQUENCE ». Pour rappel cette table comporte 2 champs :

  • Le nom du compteur
  • La valeur du compteur

Table des compteurs Planisware « OPX2_SEQUENCE »

 

Au passage, on peut constater que ces compteurs peuvent aller jusqu’à 20 chiffres.

Le compteur dédié à la génération des ONB est la séquence nommée « opx2_seq ». Dans l’exemple suivant sa valeur au moment de l’interrogation en BDD était de 1 091 363 420.

 

Compteur « opx2_seq »

 

Note : il n’est pas toujours facile de suivre pas à pas l’évolution du compteur dédié aux ONB car la création d’un seul objet dans Planisware peut déclancher la création automatique d’autres objets (ex. création automatique d’un sous-projet par défaut lors de la création d’un projet P5). Cela n’a pas d’importance, l’essentiel est de retenir que tous les ONB seront générés de manière croissante et que le compteur est mis à jour au fur et à mesure en base de données.

Liens entre les objets

Sous Planisware le choix a été fait de ne pas implémenter en dur dans la BDD les relations et les contraintes du modèle de données. L’ONB est donc un élément essentiel pour les objets Planisware car les liens entre les objets sont assurés par des références à leurs ONB respectifs.

Par exemple, si l’on regarde en BDD la table des affectations (TASK_ALLOC) on pourra constater que le lien entre activité et ressource est défini en indiquant l’ONB de l’activité (colonne WORK_STRUCTURE) et l’ONB de la ressource (colonne OPX2_RESOURCE) en plus des attributs complémentaires définissant l’affectation.

Offset et gestion de l’unicité des ONB entre bases Planisware

Comme précisé précédemment les ONB des objets d’environnement et ceux des objets de planifications sont basés sur le même compteur. Or une application Planisware compte au minimum 2 bases distinctes :

  • une base de production
  • une base de développement (pour développer le paramétrage correctif/évolutif)

Il apparait alors clairement que sans outil complémentaire le fonctionnement natif des ONB ne sera pas satisfaisant car il on va nécessairement générer des ONB doublons entre la base de production et la base de développement dont les compteurs ne sont pas synchronisés.

Pour cette raison la notion d’offset a été introduite afin de rétablir l’unicité des ONB générés lorsqu’une application fonctionne avec plusieurs bases distinctes. Il s’agit simplement de définir un numéro pour chacune des bases. Tous les ONB d’une base donnée termineront alors par ce numéro.

Par exemple, si l’offset de ma base de données de production est « 10 » et celui de ma base de développement est de « 20 », tous les objets créés sur la base de production auront un ONB terminant par « 10 » (ex. 105694610) et ceux de ma base de développement un ONB terminant par « 20 » (ex. 105696020). Ce système va permettre d’assurer l’unicité des numéros internes de chacun des objets de l’application.

Exemple : avec un offset de 20 si l’on crée une tâche dont l’ONB est « 1091365620 » alors le compteur interne « opx2_seq » va être incrémenté à « 1091365720 ».

Remarque importante :

Il est essentiel de respecter la recommandation de l’éditeur qui recommande de définir et mettre en place un offset pour chacune des bases Planisware (développement, production site 1, production site 2…) et ceci dès le début de l’intégration. Sinon des objets en doublon vont nécessairement être générés entre la base de développement et la base de de production. Cela pourra induire de graves problèmes de corruption de données.