Quand je regarde le Data Model, je constate qu’il me manque une grande partie de mes Nodes dans les Model Items (principalement les roses). Ici j’en ai 38 alors qu’il doit y en avoir une bonne centaine.
Un ModelItem se crée dès lors qu’un noeud/contenu/link est lié à l’objet métier appartenant à un template de modèle, cette liste est en cache. Donc dès qu’un template de modèle change, il faut vider tous les caches (pour limiter le champ d’application du champ meta-objet du ModelItem).
Ensuite, le save d’un modèle lance une tache asynchrone (donc rend la main à l’utilisateur avant que tous les ModelItem soient créés) qui synchronise les noeuds contenus dans le SVG vs. les noeuds qui existent en base (ajoute ou supprime la relation). Donc pour synchroniser, il suffit de forcer un save sur le Model (sans forcement passer par le modeleur, open/save via la UI/Menu Model ou par code select/save).
Cette tache de synchro SVG/Base ne fonctionne pas sur un import XML (batch instance), car dans ce cas d’import de Model, les ModelItem sont exportés en cascade avec le modèle si on choisit l’option “exporter tout” et pas unqiuemeent l’objet Model :
J’ai ouvert le model, cliqué sur Save et les model items manquent toujours.
Je pense que ça vient du fait que mon objet Flow (les node roses) est node ET link. Je n’ai que 3 model items de type Node sur l’objet Flow, et je ne les trouve pas dans les model items de type Link.
La clé fonctionnelle d’un ModelItem est donnée par le model et le target object (un lien vers un objet de la base). Le type n’est pas en clé, donc un Objet ne peut être listé qu’une fois dans un modèle, et c’est suffisant.
Dans votre paramétrage RciFlow est bien un Node et non un Link.
Le type Link signifierait qu’il est la N,N entre 2 Nodes RciApplication (“Link Object” est vide dans votre cas). Pour le voir en tant que Link, il faut réunir vos 2 Links depuis le Node RciFlow en un seul, en l’utilisant comme N,N dans “Link Object”, il n’y aura plus de node rose afficher, juste une fleche.
Bref l’objectif du ModelItem, est de pourvoir trouver les modèles dans lequel un objet apparait (dans le panel ad hoc). La notion de RciFlow = Link est fonctionnelle dans votre cas, mais du point de vue du modeleur c’est bien un node = un carré avec des fleches qui entrent et qui sortent.
Masquez la colonne Type si c’est troublant pour les utilisateurs.
En tout cas entre les nodes de type RciApplication et de type RciFlow, il devrait y avoir une 100aine de ModelItem créés à la fin de la synchro et non 38.
RciFlow est bien un lien de type N,N dans mon modèle de données, mais dans le modeleur on veut le voir en tant que node car on est intéressés par les Data qui sont affichées comme item du node.
Donc j’insère les nodes dans le modèle par code.
Est-il normal alors que j’ai des RciFlow de type link dans mon modèle ?
Oui j’ai bien compris. Mais vous ne répondez pas à la question de savoir si vous en avez 100 ou 38 créations après synchro.
Un type Link est relatif à l’objet “Link object” optionnel quand on définit un lien dans le modèle (vide dans votre copie d’écran). Vous avez paramétrez 2 liens directs pour afficher votre flux comme un node.
Donc à priori vous de devriez pas avoir de type Link, sauf si vous avez modifié votre défintion de modèle après en avoir créé = il faut resynchroniser vos modèles via un “save” forcé.
Les nodes/link/content du SVG sont parsés au save pour créer des ModelItem
les classes .node ayant les propriétés data-obj et data-id deviennent des types Node.
les classes .link ayant les propriétés data-obj et data-id (de la N,N) deviennent des types Link
les classes .item ayant les propriétés data-obj et data-id deviennent des types Content
les containers ne sont pas traités
Editez votre fichier SVG et regardez ce qu’il continent.
Ah ok, j’avais compris que vous aviez des Node et non des Link. J’ai besoin de savoir si le total est bon et si c’est juste les types qui sont incorrects.
Dans votre cas le RciFlow est égal à l’une des extrémités du Link, Simplicité doit confondre ou traiter 2 fois l’item qui apparait en tant que Node et Link, je vais regarder plus en détail.
Oui le total est bon par rapport au modèle, j’ai 35 types node (correspondant aux nodes applications en jaune) et 55 types link (correspondant aux nodes flux en rose)
La synchro scanne d’abord les nodes, puis les links :
Vos RcIFlow sont créés avec le type Node
Puis ils deviennent des Link quand le parser les scanne en tant que Link
Il faut attendre la fin de la synchro pour avoir des chiffres corrects, je ne vois pas de problème.
Comme expliqué dès le début, le traitement est asynchrone, donc la UI voit les données au fur et à mesure de leur insertion, donc au milieu il en manque forcement… mais tout doit être OK à la fin.
On ne va pas rendre ce traitement synchone ou pire mettre un “sychronized global” car le/les utilisateurs devraient attendre longtemps et en terme UX ce n’est envisageable.
On pourrait plutôt les masquer le temps que la synchro n’est pas terminée, avec un logique on voit “tous les ModelItem ou rien” ou ajouter un champ “scanning / synchronized” visible.
Désolée je pense que je suis partie sur une mauvaise piste et je n’ai pas de problème en soi avec le nombre d’items sur le model.
Mais je pensais que c’est ce qui fait disparaître des nodes à l’export / import, or en regardant de plus près je pense que ce n’est pas la cause.
J’ai fait un export du module Modeler et je l’ai importé dans un nouvel environnement.
Quand je regarde le SVG et le png sur mon nouvel environnement les images sont correctes. Mais quand j’ouvre le modeler j’ai la moitié des nodes qui disparaissent. Pourtant je les vois bien dans les model item.
Il y a effectivement une autre synchro à l’ouverture d’un modèle vis-à-vis des données présentent dans la base.
Si les Nodes sont supprimés lors de l’affichage, c’est qu’ils n’existent pas dans la base ou alors que Simplicité ne peut pas retrouver les row_id (différent de la base source) avec la clé fonctionnelle contenu dans le SVG (le data-keys contient le JSON de la clé fonctionnelle d’un node, link…).
Regardez pour les nodes qui disparaissent si le nom de l’application a changé par exemple.
Il faut à mon avis :
synchroniser les data entre vos bases (même App, Flow…)
ré-enregistrer le modèle pour que les data-keys soient corrects.
exporter/importer vos modèles.
Sinon il faut modifier le SVG pour mettre les bonnes clés.
Merci pour cette piste, effectivement on a des applications qui ont été suffixées “A revoir” et ce sont elles qui disparaissent.
Dans le SVG, même après un save forcé via le modeler, ma clé n’est pas mise à jour sur les nodes (bizarrement elle l’est sur les link, peut-être parce qu’ils ne sont pas générés par mon code).
Ce qui est étrange c’est que les noeuds ne disparaissent pas sur mon environnement source alors que j’ai exactement le même SVG avec le problème de clé que sur le cible.
Est-ce que je dois tout supprimer et regénérer ? Ca m’a pris beaucoup de temps de positionner les modèles :-/
Le save sérialise le modèle avec les données de la base, clés comprises. Vous comparez des bases non comparables.
Je répète :
Il faut synchroniser vos données métier entre base (prod => dev).
Sauvegarder votre modèle en dev
puis exporter dev=>prod
Sinon
Vous n’avez qu’à faire via la UI des imports connexes des App manquantes = CTRL+A / click droit sur un node / import connexe… tant qu’il en manque
Votre processus de génération / delivery n’est pas bon. Il faut générer les modèles là où les données sont créées/modifiées donc en production, pas en dev. Le node contient le row_id qui lui est bien stable sur une base, le clé fontionnelles sert à exporter/importer entre base = donc la clé fonctionnelle doit être stable sinon impossible de matcher les objets.
Vos clés fonctionnelles ne doivent pas être modifiables pour faire comme vous le faites :
avoir 1 code interne en clé (calculé ou libre en création uniquement puis non modifiable, exemple “APP00123”)
et 1 libellé libre non clé “Application X à revoir”
En fait le jeu de données a été configuré en dev puis j’ai créé les nouveaux environnements. J’ai déjà les mêmes données partout. Il n’y a pas encore de prod en utilisation.
J’ai plusieurs gros modèles comme celui ci sur lesquels j’ai passé pas mal de temps à positionner les nodes donc j’aimerais dupliquer ce travail sur les environnements que je suis en train de créer.
Je ne comprends toujours pas pourquoi le fichier SVG ne se met pas à jour, même sur la dev, avec le nouveau nom de mes applications (A revoir), quand je force le save via le modeler.
Ok, dans ce cas il faut plutôt penser dump de la base full si c’est juste pour copier un environnement de travail, passer par la couche logique est plus lourd.
Je vais regarder quand se met à jour les data-keys, il y a peut être un oubli quelque part.
Après vérification, le data-keys n’était pas bien actualisé lorsque le modèle est ouvert et qu’on enregistre une mise à jour d’un champ clé. C’est corrigé.
En revanche, si on modifie la clé sans que le modèle soit ouvert, les anciennes valeurs restent positionnées dans le fichier SVG, il faut nécessairement ré-ouvir le modèle sur la UI pour synchroniser les données à un moment donné avant de l’exporter. Il n’y a pas de traitement automatique pour synchroniser les modèles fermés (les suppressions ou mises à jour sont détectées à l’ouverture du modèle).
Il faudra vous mettre à jour quand ce sera poussé en V4 pour voir si dans votre cas ça corrige le problème.
