Disparition d'un objet dans le menu et l'importeur CSV après renommage

Bonjour,

J’ai renommé un objet métier sur mon environnement d’intégration en suivant la procédure suivante :

  • Exporter le module en XML
  • Vérifier dans le XML toutes les références au nom de cet objet
  • Renommer les références une à une en finissant par le nom de l’objet lui-même
  • Exporter à nouveau le module pour vérifier qu’il ne reste pas d’occurrences de l’ancien nom dans des objets/codes

Après avoir fait ça, j’ai vérifié que tout fonctionnait bien par rapport à cet objet sur mon environnement d’intégration. J’ai ensuite exporté le module où l’objet métier se site pour l’importer sur mon environnement d’ope. Je n’ai pas eu d’erreurs à l’import mais après que celui-ci se soit terminé et que j’aie vidé le cache, je ne vois plus l’entrée de menu de mon objet métier dans le domaine où il est censé être (alors que l’objet avec son nouveau nom est bien référencé dans le domaine). Je ne le vois pas nom plus lorsque je cherche à importer les données du métier dans l’importeur CSV (tous les autres objets sont autocomplétés sauf celui-là, avec le nouveau comme avec l’ancien nom).

J’ai renommé mon objet de “SitesSiteCategory” (catégorie de site du module Sites) en “SitesCategory” (catégorie de n’importe quel objet de type bien immobilier). La procédure d’import/export que j’ai faite est la suivante :

Export du module en cURL : curl -u designer:<mot de passe designer> -v --form service=moduleexport --form zip=true -o <Nom du module>_0.18.zip --form module=<Nom du module> https://<URL de l'intégration>/io --insecure --form log=true --proxy $HTTP_PROXY
Import du module en cURL : curl -u designer:<mot de passe designer> -v --form service=moduleimport --form file=@<Nom du module>_0.18.zip --form module=<Nom du module> https://<URL de l'ope>/io --insecure --form log=true --form version=0.18 --form zip=true --form diff=true --proxy $HTTP_PROXY

Lors du curl d’import, j’ai un premier message We are completely uploaded and fine suivi d’une erreur 504 :

	HTTP/2 504
	< server: awselb/2.0
	< date: Mon, 05 Aug 2019 15:56:05 GMT
	< content-type: text/html
	< content-length: 148
	< set-cookie: AWSALB=UqNnr3Jpwr7jK0WXqzwUyQue23hZH0SsR0v+q6BEe2DXZ5UV6u4uSh1s1XWt6/H07aT7wTMHF0TmBqlkPcf4+ZwhoqpGY1AJCdDmKIRvT0TU1brNqB6Yy7LpQ+dH; Expires=Mon, 12 Aug 2019 15:55:05 GMT; Path=/
	<
	{ [148 bytes data]
	100 1013k  100   148  100 1013k      2  17147  0:01:14  0:01:00  0:00:14    37<html>
	<head><title>504 Gateway Time-out</title></head>
	<body bgcolor="white">
	<center><h1>504 Gateway Time-out</h1></center>
	</body>
	</html>

Néanmoins tout de suite après avoir vu cette erreur, j’ai regardé dans l’import supervisor et l’import était en cours (puce orange). J’ai attendu quelques minutes et il s’est terminé après 217.955 secondes (passé en vert) sans erreur dans la log d’import. Après ça, j’ai vidé le cache toutes sessions/serveur.

Après l’import de module, je suis allé sur le module en question pour faire un compare avec un XML exporté de l’intégration et n’y vois plus de différences (à part le timestamp lastupd du module).

Les health de mes environnements sont les suivants :

Intégration (source)


[Platform]
Status=OK
Version=4.0.P23
BuiltOn=2019-08-04 21:03 (revision a6e6f36f828291103152bedde79925a44914733e)
Encoding=UTF-8
EndpointIP=172.17.0.20
EndpointURL=http://8e3eed200241:8080
TimeZone=Europe/Paris
SystemDate=2019-08-06 11:20:13

[Application]
ApplicationVersion=0.16 dev
ContextPath=
ContextURL=https://int.rfs.dev.aws.renault.com
ActiveSessions=1
EnabledUsers=7
TotalUsers=8
LastLoginDate=2019-08-06 11:04:31

[Server]
ServerInfo=Apache Tomcat/9.0.22
ServerType=WEB
User=root

[OS]
Name=Linux
Architecture=amd64
Version=4.14.101-75.76.amzn1.x86_64
SystemEncoding=UTF-8

[Disk]
DiskFree=9166
DiskUsable=8638
DiskTotal=10015

[JavaVM]
Version=12.0.2
Vendor=N/A
VMName=OpenJDK 64-Bit Server VM
VMVersion=12.0.2+9
ScriptEngine=rhino
ScriptEngineVersion=Rhino 1.7.10 2018 04 09
HeapFree=174897
HeapSize=506944
HeapMaxSize=1773888
TotalFreeSize=1441841

[Cache]
GrantCache=75
GrantCacheMax=0
GrantCacheRatio=0
ObjectCache=178
ObjectCacheMax=10000
ObjectCacheRatio=1
ProcessCache=1
ProcessCacheMax=10000
ProcessCacheRatio=0

[Database]
Vendor=3
ProductName=PostgreSQL
ProductVersion=10.6
DriverName=PostgreSQL JDBC Driver
DriverVersion=42.2.6
DBDate=2019-08-06 11:20:13
DBDateOffset=0
DBPatchLevel=P23
UsingBLOBs=true

[Healthcheck]
Date=2019-08-06 11:20:13
ElapsedTime=272

Ope (destination)


[Platform]
Status=OK
Version=4.0.P23
BuiltOn=2019-08-04 21:03 (revision a6e6f36f828291103152bedde79925a44914733e)
Encoding=UTF-8
EndpointIP=172.17.0.14
EndpointURL=http://5b689fd7fce9:8080
TimeZone=Europe/Paris
SystemDate=2019-08-06 11:20:34

[Application]
ApplicationVersion=0.16 dev
ContextPath=
ContextURL=https://ope.rfs.ope.aws.renault.com
ActiveSessions=1
EnabledUsers=8
TotalUsers=9
LastLoginDate=2019-08-06 11:03:39

[Server]
ServerInfo=Apache Tomcat/9.0.22
ServerType=WEB
User=root

[OS]
Name=Linux
Architecture=amd64
Version=4.14.101-75.76.amzn1.x86_64
SystemEncoding=UTF-8

[Disk]
DiskFree=9173
DiskUsable=8645
DiskTotal=10015

[JavaVM]
Version=12.0.2
Vendor=N/A
VMName=OpenJDK 64-Bit Server VM
VMVersion=12.0.2+9
ScriptEngine=rhino
ScriptEngineVersion=Rhino 1.7.10 2018 04 09
HeapFree=307665
HeapSize=506944
HeapMaxSize=1773888
TotalFreeSize=1574609

[Cache]
GrantCache=49
GrantCacheMax=0
GrantCacheRatio=0
ObjectCache=187
ObjectCacheMax=10000
ObjectCacheRatio=1
ProcessCache=1
ProcessCacheMax=10000
ProcessCacheRatio=0

[Database]
Vendor=3
ProductName=PostgreSQL
ProductVersion=10.6
DriverName=PostgreSQL JDBC Driver
DriverVersion=42.2.6
DBDate=2019-08-06 11:20:34
DBDateOffset=0
DBPatchLevel=P23
UsingBLOBs=true

[Healthcheck]
Date=2019-08-06 11:20:34
ElapsedTime=96

Quand on renomme un objet et qu’on importe sur paramétrage résultant sur une instance cible, celle-ci ne peut pas savoir qu’il s’agit d’un renommage, pour elle c’est une création d’un nouvel objet (et une suppression de l’ancien).

2 approches possibles:

  1. après export il faut retoucher le XML exporté en ajoutant oldvalue="<ancien nom>" dans le bloc de creation du nouvel objet à la fois sur le nom logique et sur le nom de table physique du nouvel objet

  2. renommer le nom logique mais ne pas renommer le nom de la table physique, exporter/importer puis modifier ce nom manuellement via la UI dans la cible (et donc aussi dans la source), comme ça le nouvel objet récupère bien la table de l’ancien

Bref il faut aider le socle à s’y retrouver d’une manière ou d’une autre.

Bonjour David,

Merci pour ta réponse. Peux-tu me donner plus de détails ou un exemple sur l’utilisation de oldvalue="<ancien nom> ?

J’ai tenté plusieurs choses mais je ne suis pas sûr de bien savoir où le mettre.

Ex : <obo_dbtable>oldvalue="sites_sitecategory"</obo_dbtable> ou bien <oldvalue>sites_sitecategory</oldvalue> dans la partie suivante de mon XML de module :

		<obo_name>SitesCategory</obo_name>
		<obo_dbtable>sites_category</obo_dbtable>
		<obo_dbtable>oldvalue="sites_sitecategory"</obo_dbtable>
		<obo_class/>
		<obo_script_id><![CDATA[DATA:SitesSiteCategory.java:package com.simplicite.objects.RenaultSites;

import com.simplicite.util.Globals;

/**
 * Site category
 */
public class SitesCategory extends com.simplicite.commons.RenaultSites.SitesCommon {
	private static final long serialVersionUID = 1L;

	/** Hook override */
	@Override
	public void postLoad() {
		super.postLoad();

		if (getGrant().getEndpoint() == Globals.ENDPOINT_API) {
			// Hide UI-only fields on the API endpoint
			//getField("sitesScaDescription").setVisibility(ObjectField.VIS_FORBIDDEN);
			//getField("sitesGenActive").setVisibility(ObjectField.VIS_FORBIDDEN);
		}
	}
}]]></obo_script_id>
		<obo_usets>0</obo_usets>
		<obo_nosearch>1</obo_nosearch>
		<obo_comment><![CDATA[Defines the nature of the site : internal, external, partner, supplier or customer.]]></obo_comment>
		<obo_type>O</obo_type>
		<obo_searchspec/>
		<obo_delspec/>
		<obo_exportorder>5</obo_exportorder>
		<obo_distinct>0</obo_distinct>
		<obo_indexable>1</obo_indexable>
		<obo_groupby>0</obo_groupby>
		<obo_dfltref/>
		<obo_template_id.tpl_name>SitesSiteCategory</obo_template_id.tpl_name>
		<obo_cache>D</obo_cache>
		<obo_copy>1</obo_copy>
		<obo_export>1</obo_export>
		<obo_pagine>1</obo_pagine>
		<obo_srh_predef>1</obo_srh_predef>
		<obo_selrow>1</obo_selrow>
		<obo_updall>1</obo_updall>
		<obo_delall>1</obo_delall>
		<obo_listsearch>1</obo_listsearch>
		<obo_list_edit>N;L;E</obo_list_edit>
		<obo_useform>1</obo_useform>
		<obo_title/>
		<obo_icon>wkfinfo</obo_icon>
		<obo_refcount>0</obo_refcount>
		<obo_tree>0</obo_tree>
		<obo_viewmode>V</obo_viewmode>
		<obo_historic>0</obo_historic>
		<obo_printable>1</obo_printable>
		<obo_followlink>1</obo_followlink>
		<obo_mergeable>0</obo_mergeable>
		<obo_social>1</obo_social>
		<obo_rowid_id.fld_name/>
		<obo_extend_id.obj_name/>
		<row_module_id.mdl_name>RenaultSites</row_module_id.mdl_name>
		<obo_btn_reload>P</obo_btn_reload>
		<obo_btn_prefs>P</obo_btn_prefs>
		<obo_btn_del>P</obo_btn_del>
		<obo_btn_copy>P</obo_btn_copy>
		<obo_btn_export>P</obo_btn_export>
		<obo_btn_listadd>1</obo_btn_listadd>
		<obo_btn_listedit>1</obo_btn_listedit>
		<obo_btn_listupsert/>
		<obo_btn_updall>P</obo_btn_updall>
		<obo_btn_delall>P</obo_btn_delall>
		<obo_btn_merge>P</obo_btn_merge>
		<obo_btn_save>1</obo_btn_save>
		<obo_btn_saveclose>1</obo_btn_saveclose>
		<obo_btn_close>1</obo_btn_close>
		<obo_tray>1</obo_tray>
		<obo_dashboard>1</obo_dashboard>
		<obo_prefix/>
		<obo_search_ts/>
	</data>
<obo_name oldvalue="MyOldName">MyNewName</obo_name>
<obo_dbtable oldvalue="my_old_table">my_new_table</obo_dbtable>

Bonjour David,

J’ai essayé plusieurs choses :

  1. Importer le module en diff=true avec la modification oldvalue dans le XML (ton point 1 dans ton message précédent) :
<obo_name oldvalue="MyOldName">MyNewName</obo_name>
<obo_dbtable oldvalue="my_old_table">my_new_table</obo_dbtable>

==> ça n’a pas réglé les problèmes (Category pas listée dans le menu du domaine lié, catégorie pas sélectionnable dans l’importeur csv)

  1. Supprimer manuellement la table (new_table) et importer le module en diff=true de la manière suivante puis renommer le nom de la table manuellement après (ton point 2)
<obo_name oldvalue="MyOldName">MyNewName</obo_name>
<obo_dbtable>my_old_table</obo_dbtable>

==> la table sites_sitecategory a bien été supprimée et la table sites_category créée mais ça toujours pas réglé les problèmes (Category pas listée dans le menu du domaine lié, catégorie pas sélectionnable dans l’importeur csv)

Je ne sais pas comment procéder autrement. Est-ce qu’il faut que je tente de supprimer le module puis de l’importer entièrement à nouveau ?

Je pense que faisant et refaisant N fois la manip tu est dans un état qui n’est plus très clair.

Simplicité ne supprime jamais une table physique lors de l’import de paramétrage. Au pire il la renomme s’il y a un <obo_dbtable oldvalue="my_old_table">my_new_table</obo_dbtable> explicite.

Par contre l’import créé les tables qui n’existent pas.

Bref tu dois repartir d’un état clair de chaque coté, à savoir:

  1. connaitre les noms logiques et les noms de tables physiques actuels (en vérifiant où sont les bonnes données) de chaque coté
  2. s’assurer qu’il n’y a pas de tables “zombies” issues d’imports ratés précédents

Ensuite en mettant les bons oldvalue dans ce que tu importe il n’y a strictement aucune raison d’avoir des pbs.

Bien entendu un XML avec des oldvalues ne peut être importé qu’une seule fois (car la fois suivante les valeurs auront changées et les oldvalues ne retrouvent plus rien).

Donc il faut procéder avec rigueur et en comprenant parfaitement ce que fait l’import.

PS: Supprimer et réimporter ton module ne changera rien si tu n’est pas au clair au niveau des tables physiques.

Une autre approche quand on renomme une table c’est de faire le renommage de la table manuellement sur la cible juste avant l’import. Comme cela l’import du nouvel objet logique le rattachera à la bonne ancienne table (renommée avec son nouveau nom), la suppression de l’ancien objet n’ayant alors pas d’impact.

Etc.

PS:

Il faut toujours importer un module avec diff=true (c’est ce que fait l’import de module par défaut donc ça ne sert à rien de le mettre explicitement) mais ce qu’il faut savoir c’est que si l’import rencontre une erreur (n’importe laquelle) il n’appliquera pas le diff à la fin (et il le dira explicitement dans les traces).

C’est volontaire pour forcer les designers à résoudre les erreurs d’export et/ou d’import en limitant les dégâts. Ce genre d’erreur est en effet toujours révélatrice de graves problèmes de packaging qui auront de toute façon des conséquences néfastes.

Ignorer les erreurs d’import en se disant “bon c’est pas grave ça à l’air de marcher” est la pire des choses à faire. Toute erreur d’import doit impérativement être comprise et corrigée.

Bref si tu as fait des imports multiples avec des oldvalues un peu hasardeuses et qu’en plus tu as eu des erreurs d’imports qui ont inhibé les diffs finaux alors tu es dans un état forcément pas très clair…

En ce qui concerne mon objet métier “SitesCategory” (anciennement “SitesSiteCategory”), après import sur l’environnement destination, il a bien son nouveau nom logique “SitesCategory” et physique “sites_category” dans la UI. Il n’y a plus de table “sites_sitecategory” dans la base.

Mon problème :

  1. Je ne vois pas “SitesCategory” dans le module (?) d’import CSV de Simplicité, il n’est pas complété (alors que les autres objets Sites* le sont).
  2. Je ne vois pas mon objet Category dans la liste du domaine “Reference data” (Code de domaine “SitesRef”) alors que dans la catégorie “Main menu” de ce domaine, j’ai bien l’object code “SitesCategory”.

Je ne sais pas quelles sont les tables en base pour chacun de ces modules (domaine Simplicité, module d’Import CSV). Peux-tu me les indiquer pour que je puisse vérifier que les références à mon objet SitesCategory dans ces tables ont (ou pas, j’imagine) les bonnes valeurs référencées ?

PS : sur la documentation d’io, le paramètre diff est décrit comme defaults to false

La doc était incorrecte : j’ai vérifié dans le code, sur le endpoint I/O le diff est à true par défaut, j’ai corrigé la doc

Pour le reste je ne suis pas sûr de comprendre ce que tu appelle le “module d’import CSV de Simplicité”, parles-tu de la page d’import CSV" ? Dans Simplicité le terme “module” signifie “unité de packaging du paramétrage” si on l’utilise pour parler d’autre chose c’est confusant…

Bon, si on parle bien de la page d’import CSV, si un objet n’y est pas proposé c’est qu’il n’est pas habilité au user qui accède à cette page.

Donc vérifie les droits.

C’était bien les droits qui s’étaient recréés avec le bon nom dans l’intégration mais pas l’opé. Merci.

Reste donc à comprendre pourquoi des droits se seraient “perdus” dans les manips, la réponse est sans doute dans les fameuses erreurs d’import dont je parle précédement…

Peut-être, à voir la prochaine fois que je fais un renommage en utilisant le tag “oldvalue”.

Ok on verra

En résumé:

  1. la seule chose sur laquelle il faut “aider” la plateforme quand on renomme des choses c’est quand on modifie un nom physique (i.e. un nom de table ou un nom de colonne). Le reste du paramétrage lui n’a pas de pb avec les renommages, au pire il gère ça comme une suppression + ajout via le diff final d’import de module
  2. le diff n’étant appliqué que s’il n’y a aucune erreur d’import il faut comprendre et corriger toutes les éventuelles erreur d’import (car sinon ça laisse les choses qui auraient dues être supprimées par le diff final)