Plus d'accès à UI simplicité

Bonjour,
suite changement de configuration DOC_DB en mettant valeur remplacée c:/dbdoc je n’ai plus d’accès à l’ui, j’ai l’erreur :
2021-05-17 16:27:34,956 INFO [com.simplicite.util.Grant] SIMPLICITE|http://2f05d3f34fba:8080||ICORED0001|public|com.simplicite.util.Grant|init||Info: public connected, session ID: 3352A87725548C5654C23608DAE7057B, timeout: 5 min , user agent: Mozilla/5.0 (Windows NT 10.0; Win64; x64; rv:78.0) Gecko/20100101 Firefox/78.0
2021-05-17 16:26:35,902 ERROR [com.simplicite.webapp.servlets.ui.ResourceServlet] SIMPLICITE|http://2f05d3f34fba:8080||ERROR|designer|com.simplicite.webapp.servlets.ui.ResourceServlet|doGet||Evénement: Resource not found: missing file in {
“code”: “MAIN”,
“cached”: true,
“id”: “260”,
“type”: “HTML”,
“doc_id”: “2281”
}
com.simplicite.util.exceptions.NotFoundException: missing file in {
“code”: “MAIN”,
“cached”: true,
“id”: “260”,
“type”: “HTML”,
“doc_id”: “2281”
}
at com.simplicite.webapp.WebServicesFactory.streamResource(WebServicesFactory.java:2707)
at com.simplicite.webapp.servlets.ui.ResourceServlet.doGet(ResourceServlet.java:55)
at javax.servlet.http.HttpServlet.service(HttpServlet.java:626)
at javax.servlet.http.HttpServlet.service(HttpServlet.java:733)
at org.apache.catalina.core.ApplicationFilterChain.internalDoFilter(ApplicationFilterChain.java:227)
at org.apache.catalina.core.ApplicationFilterChain.doFilter(ApplicationFilterChain.java:162)
at org.apache.tomcat.websocket.server.WsFilter.doFilter(WsFilter.java:53)
at org.apache.catalina.core.ApplicationFilterChain.internalDoFilter(ApplicationFilterChain.java:189)
at org.apache.catalina.core.ApplicationFilterChain.doFilter(ApplicationFilterChain.java:162)
at com.simplicite.webapp.filters.RewriteFilter.doFilter(RewriteFilter.java:86)
at com.simplicite.webapp.filters.AbstractFilter.doFilter(AbstractFilter.java:37)
at org.apache.catalina.core.ApplicationFilterChain.internalDoFilter(ApplicationFilterChain.java:189)
at org.apache.catalina.core.ApplicationFilterChain.doFilter(ApplicationFilterChain.java:162)
at com.simplicite.webapp.filters.HTTPHeadersFilter.doFilter(HTTPHeadersFilter.java:39)
at com.simplicite.webapp.filters.AbstractFilter.doFilter(AbstractFilter.java:37)
at org.apache.catalina.core.ApplicationFilterChain.internalDoFilter(ApplicationFilterChain.java:189)
at org.apache.catalina.core.ApplicationFilterChain.doFilter(ApplicationFilterChain.java:162)
at org.apache.catalina.core.StandardWrapperValve.invoke(StandardWrapperValve.java:188)
at org.apache.catalina.core.StandardContextValve.invoke(StandardContextValve.java:97)
at org.apache.catalina.authenticator.AuthenticatorBase.invoke(AuthenticatorBase.java:542)
at com.simplicite.tomcat.valves.APISessionValve.invoke(APISessionValve.java:192)
at org.apache.catalina.core.StandardHostValve.invoke(StandardHostValve.java:143)
at org.apache.catalina.valves.ErrorReportValve.invoke(ErrorReportValve.java:92)
at org.apache.catalina.valves.AbstractAccessLogValve.invoke(AbstractAccessLogValve.java:687)
at org.apache.catalina.core.StandardEngineValve.invoke(StandardEngineValve.java:78)
at org.apache.catalina.connector.CoyoteAdapter.service(CoyoteAdapter.java:357)
at org.apache.coyote.http11.Http11Processor.service(Http11Processor.java:374)
at org.apache.coyote.AbstractProcessorLight.process(AbstractProcessorLight.java:65)
at org.apache.coyote.AbstractProtocol$ConnectionHandler.process(AbstractProtocol.java:893)
at org.apache.tomcat.util.net.NioEndpoint$SocketProcessor.doRun(NioEndpoint.java:1707)
at org.apache.tomcat.util.net.SocketProcessorBase.run(SocketProcessorBase.java:49)
at java.base/java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1130)
at java.base/java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:630)
at org.apache.tomcat.util.threads.TaskThread$WrappingRunnable.run(TaskThread.java:61)
at java.base/java.lang.Thread.run(Thread.java:831)
2021-05-17 16:26:35,897 ERROR [com.simplicite.webapp.servlets.ui.ResourceServlet]

Pouvez m’indiquer ce que je dois faire et d’ou vient l’erreur ?
Thierry

Je ne connais pas de paramètre DOC_DB mais DOC_DIR = dbdoc ou BLOB par défaut.

DOC_DIR peut pointer vers un autre répertoire racine des documents auquel ca vous devez arrêter tomcat et déplacer le répertoire initial (le dbdoc dans la webapp) vers celui spécifié.

Simplicité le fait automatiquement quand on passe de /dbdoc à BLOB (fichiers en base), mais pour les autres répertoires, il faut obligatoirement le faire manuellement, car c’est une migration potentiellement dangereuse (disk full, droits…) et non plus une simple mise à jour en base. Il faut s’assurer que tout est bien déplacé et redémarrer tomcat / vider les caches.

Si la UI ne fonctionne plus, il faudra mettre à jour ce paramètre DOC_DIR via SQL de la table m_system avec le nouveau chemin qui contient les documents. Bref migrer le dbdoc n’est pas une opération légère, c’est à voir comme une migration avec sauvegarde, et retour arrière en cas d’échec.

Bonjour,
effectivement il s’agit de DOC_DIR.
Est ce qu’il y a un accès SQL via un endpoint Simplicité ?

Sur /io vous pouvez utiliser le service sqlscript (cf. Simplicité® documentation/02-integration/io-commandline)

C’est une commande curl et je ne sais pas quelle commande executer sans voir la table.

Vous pouvez voir la définition de l’objet SystemParam depuis une autre instance.
La table m_system contient un sys_code, une valeur sys_value et optionnellement une valeur surchargée sys_value2 (quand on modifie un paramètre socle) :

select sys_value, sys_value2 from m_system where sys_code='DOC_DIR'
update m_system set sys_value2='/mypath/dbdoc' where sys_code='DOC_DIR'

NB: Si vous êtes avec une base HSQLDB (embedded), seul le process qui l’exécute (en l’occurence Tomcat) peut avoir accès à la base. D’où ma suggestion de passer par /io (vu que dans votre cas la page UI DBAccess n’est plus accessible).

Si on parle d’une autre base vous y avez accès depuis le container via les clients ad hoc (mysql, psql, … ) qui s’y trouvent (ou depuis le host si vous avez rendu le port de la base accessible)

C’est une base mariadb, local. Je voulais éviter d’installer un client maria et j’esperais avoir accès via un endpoint.
La commande io avec la mise à null de sys_value2 à régler mon pb.
A la base j’ai juste mis une valeur remplacée sur un dossier qui n’existait pas.

curl -u designer:simplicite --form service=sqlscript --form file=@update_null_doc_dir.sql --form log=true http://localhost:81/io
Merci

PS:

S’il s’agissait uniquement de changer la valeur surchargée d’un param système un import XML (service xmlimport) sur /io aurait sans doute aussi fonctionné.

Genre:

<object>
	<name>SystemParam</name>
	<action>update</action>
	<data>
		<sys_code>MY_PARAM</sys_code>
		<sys_value2>My value</sys_value2>
	</data>
</object>

Suivi d’un appel au service clearcache toujours sur /io

Sinon, pour la mise à jour d’un param système des appels aux APIs REST auraient aussi sans doute marché :

  1. GET sur /api/rest/SystemParam?sys_code=MY_PARAM pour récupérer le row ID (ex: 123)
  2. PUT (ou PATCH) sur /api/rest/SystemParam/123 avec { "sys_value2": "My value" }

Genre:

Suivi d’un stop+start (ou d’un clear cache sur /io)

Bref les accès en base c’est à réserver aux cas où il n’y a pas d’autre solution et/ou que c’est simple et sans risques à faire en SQL (ex: la mise à jour d’une valeur de param système)

Oui le SQL c’est quand tomcat ou la webapp ne démarre pas.
Passer par des couches HTTP c’est du luxe, dans tous les cas il faut savoir ce qu’on fait.

Pour en revenir à la mise à jour du DOC_DIR, il y a un warning qui s’affiche sur la UI si on change d’emplacement ce paramètre en dehors de Simplicité (dbdoc interne à la webapp ou BLOB) :

You must move the doc folder … to … and restart the platform.

On peut ajouter un controle bloquant si on n’y trouve pas certaines ressources vitales pour la UI si ce message ne semble pas assez clair = la mise à jour ne se fera que si le docdir a été copié ailleurs avant (on ne peut pas le déplacer si la UI fonctionne dessus, c’est à faire à froid). C’est plus lourd qu’un simple move + restart.

This topic was automatically closed 60 minutes after the last reply. New replies are no longer allowed.

PS:

cf. Database access with Docker / Docker compose

Dans les prochaines images Docker il y aura un script pour se connecter facilement à la base de données via les clients natifs présents dans le container Simplicité.

Attention: l’usage dans le cas HSQLDB (embedded) est légèrement différent de l’usage dans les cas des bases de données externes : MySQL, PostgreSQL, Oracle et SQLServer