Bonjour,
Dans le cadre d’une migration d’application, nous recherchons le chemin absolu de stockage des documents.
Je constate qu’ en V4 Simplicité, les documents de l’appli sont stockés dans un répertoire ‘recyclebin’.
Est-ce normal ?
Merci de votre réponse et meilleurs voeux.
Guillaume
J’oubliais :
[Platform]
Status=OK
Version=4.0.P23
BuiltOn=2019-12-20 18:27 (revision 7f9d1a3c55293dc181b03c412dce366572bd32a1)
Encoding=UTF-8
EndpointIP=192.168.1.20
EndpointURL=https://Rec-sim:10258/agmanif
TimeZone=Europe/Paris
SystemDate=2020-01-06 15:21:25
[Application]
ApplicationVersion=4.0
ContextPath=/agmanif
ContextURL=https://rec.bretagne.bzh/agmanif
ActiveSessions=1
EnabledUsers=197
TotalUsers=198
LastLoginDate=2020-01-06 15:20:04
[Server]
ServerInfo=Apache Tomcat/9.0.30
ServerType=WEB
User=agmanif
[OS]
Name=Linux
Architecture=amd64
Version=3.10.0-1062.1.1.el7.x86_64
SystemEncoding=UTF-8
[Disk]
DiskFree=26095
DiskUsable=24493
DiskTotal=37149
[JavaVM]
Version=1.8.0_222
Vendor=Oracle Corporation
VMName=OpenJDK 64-Bit Server VM
VMVersion=25.222-b10
ScriptEngine=rhino
ScriptEngineVersion=Rhino 1.7.10 2018 04 09
HeapFree=70433
HeapSize=313856
HeapMaxSize=466432
TotalFreeSize=223009
[Cache]
GrantCache=92
GrantCacheMax=0
GrantCacheRatio=0
ObjectCache=112
ObjectCacheMax=10000
ObjectCacheRatio=1
ProcessCache=1
ProcessCacheMax=10000
ProcessCacheRatio=0
[Database]
Vendor=2
ProductName=MySQL
ProductVersion=5.5.5-10.2.9-MariaDB-10.2.9+maria~stretch
DriverName=MySQL Connector/J
DriverVersion=mysql-connector-java-8.0.18 (Revision: fef2894d751d47223192b706977b4a5bc41e6be4)
DBDate=2020-01-06 15:21:25
DBDateOffset=0
DBPatchLevel=P23
UsingBLOBs=true
[Healthcheck]
Date=2020-01-06 15:21:25
ElapsedTime=12
Les document qui sont dans “recyclebin” sont ceux qui sont à la poubelle donc ceux qui ne sont plus associés à des records d’objet métier.
Les documents de votre application qui sont encore liés à des records d’objet métier sont là où le parametre système DOC_DIR définit qu’ils sont.
Si la valeur de ce paramètre est “BLOB” ils sont en BLOB en base de données sinon c’est soit un chemin absolu, soit un chemin relatif vis à vis du chemin dans le paramètre système PROJECT_DIR (en 4.0 si celui-ci vaut “default” cela signifie <chemin de la webapp>/WEB-INF)
Merci, la présence d’un chemin dans le champ dbd_path m’avait emmené sur une fausse piste. Effectivement un blob est présent dans le champ dbd_content.
Bonjour,
Je veux stocker les documents d’une application dans un sous-répertoire de ‘WEB-INF’. Puis-je à votre avis utiliser à cette fin le répertoire ‘doc’, qui est vide par défaut ?
En effet, les fichiers étant volumineux je souhaite éviter le dossier ‘dbdoc’ pour ne pas remplir les sauvegardes.
Merci
Tout dépend ce qu’on entend par “document de l’application” et comment on souhaite les exploiter dans l’application
Ce sont des fichiers uploadés par nos utilisateurs (des fichiers pdf, excel…). Ils seront uploadés et visualisables. C’est un simple champ de type document dans un de nos objets métier.
Si ces documents sont des données (ici un attribut d’un objet métier) ils sont gérés en tant que tel, donc dans le répertoire dbdoc ou en BLOB en base.
Historiquement on pouvait créer (par code ou import XML) des documents avec un path absolu dans m_document et donc les mettre physiquement où on veut. Je pense que c’est toujours possible en 4.0 mais du coup ce ne sont pas des documents uploadables via la UI (car ceux ci vont dans le dboc ou en BLOB)
Par contre je ne sais pas trop ce qui se passe en mode BLOB avec des documents avec ce genre de path absolu.
Je cherche à migrer de V3 en V4, pour cela j’ai :
-remplacé le paramètre système DOC_DIR qui est “BLOB” par défaut en V4 par “dbdoc”
-copié les fichiers du répertoire “D:\serveur\Tomcat7.0.67\data\simplicite\crbsimplicite\dbdoc\MonAppli” de la V3, vers “/home/MonAppli/tomcat/webapps/MonAppli/WEB-INF/dbdoc/” en V4
-migré les données de la table m_document de V3 vers la table m_document de V4
-> Cela fonctionne en utilisant le chemin relatif ‘dbdoc’ : je visualise bien mes documents.
En revanche, en spécifiant un chemin absolu dans DOC_DIR (sans avoir redémarré la plateforme je l’avoue) le comportement de la plateforme était erratique et je n’ai pas insisté, je préfère donc utiliser un chemin relatif car cela fonctionne, mais autre que ‘dbdoc’.
Par construction un chemin relatif dans m_document est relatif par rapport au DOC_DIR (i.e. WEB-INF/dbdoc par défaut).
Si vous voulez mettre les fichiers ailleurs c’est forcément avec des path absolus. Si on est pas en mode BLOB ça devrait marcher (en mode BLOB comme je l’ai dit je sais pas)
Mais fondamentalement je ne comprends pas trop pourquoi vous avez opté pour une approche “couches basses” au lieu de faire des exports/imports ZIP de vos objets avec leurs documents
Nous avons 16 Go de données, je ne pense pas qu’un export ZIP pourra gérer un tel volume.
Pour élargir le sujet, est-il possible d’interfacer simplicité avec un système de GED ou de lecteurs partagés ? La question s’est-elle déjà présentée à vous ?
Merci
Non clairement 16Gb ne sera pas gérable par un export ZIP.
Pour ce qui est de la seconde question, ce sont des choses totalement différentes:
Bonjour,
Je prends bonne note des trois possibilités de paramétrage BLOB / chemin relatif / chemin absolu
En BLOB et chemin relatif par rapport au DOC_DIR, tout fonctionne.
En revanche pour paramétrer un chemin absolu (notre objectif) je rencontre des problèmes :
nous avons un bug global sur l’interface qui m’oblige à redémarrer l’instance pour revenir à la stabilité :
dbdoc) à un chemin absolu (/var/crb/files)après redémarrage de la machine le problème d’interface est également présent :
Dans le dbdoc il y a les fichiers des resources (HTML, CSS, JS) de la disposition responsive, votre symptôme correspond clairement au fait que la plateforme ne trouve pas/plus les resources de cette disposition et bascule sur la UI legacy qui elle aussi ne peut pas fonctionner correctement s’il lui manque des resources.
Avez vous investigué les causes des messages d’erreur (et pris en compte le warning) qui s’affichent. Changer l’emplacement du dbdoc est une opération complexe qui ne se fait pas “toute seule” et sans avoir bien vérifié que tout est bon au niveau physique (typiquement les droits de lecture/écriture sur les répertoire, …)
Pour expliquer les 2 comportements :
Quand on passe de BLOB à un chemin physique, Simplicité tente copier tous les documents sur disque ou réciproquement dans la table m_document. Si un document est inexistant ou problème d’écriture… il signale une erreur, mais ne supprime jamais les fichiers d’origine une fois migré (c’est une autre opération à faire quand on est sur que tout est bien déplacé).
S’il s’agit juste d’un changement de répertoire physique, c’est à vous de faire de cp -R, le mv ou encore le lien symbolique du répertoire existant avec les droits d’écriture nécessaires (ce n’est pas à Simplicité de décider quoi faire dans ce cas, d’où le message)
Toute opération de mise à jour de ce paramètre DOC_DIR (et son cousin DOC_DIR_LOCAL dans le cas DOC_DIR=BLOB pour dire ou se trouve le DBDOC physique d’origine) est à considérer comme une migration à risque (taille disque insuffisante, pb de droits, fichier absent…), donc se faire après sauvegarde du-dit dbdoc (la table m_document ou le file système) afin de de pouvoir restaurer / corriger le pb et recommencer.
Bonjour,
je découvre vos échanges sur le sujet, ce qui m’amène à me poser quelques questions (peut-être redondantes, désolé):
clairement, on ne peut pas embarquer 16Go de docs à chaque fois qu’on sauvegarde la webapp. Si les docs sont stockés dans la webapp, est-il possible de les exclure de la sauvegarde (peut-être est-ce déjà fait?)
si les docs sont stockés dans la webapp, je suppose qu’ils ne sont pas écrasés par la mise à jour de Simplicité (ce serait dommage ;-). Est-ce que le dossier préservé est celui indiqué par DOC_DIR?
on a le choix entre stocker nos docs en BLOB ou en fichiers. Pour des volumes de données conséquents, quels sont les avantages/inconvénients, vos éventuelles préconisations, les points de vigilance s’il y en a?
si l’on stocke nos 16Go de docs sur le système de fichiers local, quelle est la meilleure façon de procéder pour configurer correctement Simplicité ? Préconiseriez-vous un stockage hors de la webapp sur un montage réseau, comme cela me vient naturellement à l’esprit?
Cordialement,
Benjamin.
