(Fr) L'intérêt de l'unicité Type-Nom-Révision pour une migration

Posted on January 31, 2011

UnicitéTNRJ’ai eu la chance récemment de travailler sur quelques projets de migration qui me permettent d’interagir avec d’autres outils, d’autres solutions PLM pour lesquelles je peux analyser les parallèles avec la solution Aras Innovator et dans le cas présent enrichir quelques règles de gestion d’Aras Innovator à partir de principes de ces autres solutions. Dans ces migrations nous utilisions principalement l’outil Talend Open Studio dont on a parlé récemment à travers le lancement du projet Open Source “InnovatorETL”. Cet outil de migration est aussi appelé ETL pour Extract, Transform, Load. Il va donc permettre d’aller récupérer les données d’un système à travers des fonctions de requêtes de lecture, transformer les formats des données pour les adapter au nouveau système mis en place et enfin les injecter dans la nouvelle solution.

Assurer le découpage E/T/L

A travers ces expériences il apparaît qu’il est primordial de séparer les 3 séquences principales de la migration. Le découpage E/T/L a du sens et il est important de permettre le déroulement de chacune de ces étapes de manière séparée dans le temps. Pour ce faire il est important d’avoir chaque étape sous forme de boite noire avec des interfaces clairement définies.

T-N-R, Une identification indépendante du système

Dans les solutions sur lesquelles j’ai pu travailler lors de ces migrations, il y a deux moyens d’identifier une instance d’objet: l’id de l’objet ou l’ensemble des attributs Type, Nom, Révision. Les solutions respectaient le principe d’un ID équivalent à un trio Type, Nom, Révision. Il y a eu plusieurs discussions sur les différences de performance qu’il pourrait y avoir entre l’utilisation de chaque option lors du chargement des données (Load). Le problème est que la question de performance ne doit pas avoir d’influence sur cette sélection car il y a une différence notable entre ces possibilités: l’ID est propre à l’instance de la solution PLM tandis que l’association Type, Nom, Révision désigne l’objet indépendamment du logiciel dans lequel il est stocké. En quoi cela a son importance? Un exemple simple vient rapidement à l’esprit dans l’enchaînement Transform puis Load. Si l’option d’utiliser l’ID est prise, il va donc falloir charger des articles (Load) avant d’établir la liste des relations à créer à partir des ID créés (Transform) pour charger ensuite ces relations (Load). Si on passe par le TNR et non par l’ID on évite un aller-retour entre Transform et Load qui permet de respecter le besoin d’une séparation claire de ces étapes majeures de la migration.

Le parallèle avec Aras Innovator

Une fois de plus je ramène le tout à Aras Innovator pour en améliorer la gestion. En effet, le trio T-N-R dont je viens de parler n’existe pas en tant que tel dans Aras Innovator (l’unicité d’instance d’objet n’existe de base qu’à travers l’ID). Cependant, il est tout à fait possible de l’établir en assurant l’unicité de cet ensemble. Le nom du type d’objet est déjà unique, il faut donc s’assurer que le nom de l’objet et que la version soient uniques pour un type donné. En appliquant cette règle de gestion, on permet des migrations correctes depuis et vers Aras Innovator. C’est pour sûr une stratégie qui sera conseillée dans le cadre du projet Open Source codeplex Innovator ETL.

N’hésitez pas à partager vos expériences de migration. Etape souvent mal évaluée lors de l’acquisition d’une solution, et qui peut s’avérer assez douloureuse.

Yoann Maingon

Yoann Maingon

Yoann Maingon is an Entrepreneur and a PLM enthousiast. He is our main blogger at Minerva as he has been publishing articles about General PLM concepts and Aras Innovator for more than three years.

More Posts

Download Aras Innovator