Erreur lors de l'export des données

Bonjour,

Je rencontre une erreur lors de l’export des données du module immo :

L’erreur dans la console :

Cette action fonctionnait bien cet après midi.

Il y a t il un moyen de savoir d’ou vient le pb svp ?

Merci d’avance.
Abed.

Pouvez vous regarder s’il y a des messages plus complets (stacktrace etc.) dans les logs serveur complètes (accessibles via Operation > System logs ou en download via le SIM)

Voici ce que je trouve dans log système :

2018-02-23 19:14:16,609 ERROR [com.simplicite.util.ObjectDirect] SIMPLICITE|http://demo.simplicite.io:13398||ECORED0001|system|com.simplicite.util.ObjectDirect|invokeAction||Erreur Module com.simplicite.util.exceptions.ActionException at com.simplicite.util.engine.ObjectManager.invokeActionSync(ObjectManager.java:3230) at com.simplicite.util.ObjectDirect.invokeAction(ObjectDirect.java:664) at com.simplicite.util.ObjectDB.invokeAction(ObjectDB.java:1595) at com.simplicite.util.ScriptedObjectDB.invokeAction(ScriptedObjectDB.java:1428) at com.simplicite.webapp.tools.JSONServletTool.action(JSONServletTool.java:1321) at com.simplicite.webapp.ObjectJson.action(ObjectJson.java:662) at com.simplicite.webapp.tools.JSONServletTool.businessObjectService(JSONServletTool.java:520) at com.simplicite.webapp.servlets.AbstractJSONServlet.service(AbstractJSONServlet.java:84) at javax.servlet.http.HttpServlet.service(HttpServlet.java:742) at org.apache.catalina.core.ApplicationFilterChain.internalDoFilter(ApplicationFilterChain.java:231) at org.apache.catalina.core.ApplicationFilterChain.doFilter(ApplicationFilterChain.java:166) at org.apache.tomcat.websocket.server.WsFilter.doFilter(WsFilter.java:52) at org.apache.catalina.core.ApplicationFilterChain.internalDoFilter(ApplicationFilterChain.java:193) at org.apache.catalina.core.ApplicationFilterChain.doFilter(ApplicationFilterChain.java:166) at com.simplicite.webapp.filters.AuthMethodFilter.doFilter(AuthMethodFilter.java:108) at com.simplicite.webapp.filters.AbstractFilter.doFilter(AbstractFilter.java:37) at org.apache.catalina.core.ApplicationFilterChain.internalDoFilter(ApplicationFilterChain.java:193) at org.apache.catalina.core.ApplicationFilterChain.doFilter(ApplicationFilterChain.java:166) at org.apache.catalina.core.StandardWrapperValve.invoke(StandardWrapperValve.java:199) at org.apache.catalina.core.StandardContextValve.invoke(StandardContextValve.java:96) at com.simplicite.tomcat.valves.APISessionValve.invoke(Unknown Source) at org.apache.catalina.core.StandardHostValve.invoke(StandardHostValve.java:140) at org.apache.catalina.valves.ErrorReportValve.invoke(ErrorReportValve.java:81) at org.apache.catalina.valves.AbstractAccessLogValve.invoke(AbstractAccessLogValve.java:650) at org.apache.catalina.core.StandardEngineValve.invoke(StandardEngineValve.java:87) at org.apache.catalina.connector.CoyoteAdapter.service(CoyoteAdapter.java:342) at org.apache.coyote.http11.Http11Processor.service(Http11Processor.java:803) at org.apache.coyote.AbstractProcessorLight.process(AbstractProcessorLight.java:66) at org.apache.coyote.AbstractProtocol$ConnectionHandler.process(AbstractProtocol.java:790) at org.apache.tomcat.util.net.NioEndpoint$SocketProcessor.doRun(NioEndpoint.java:1459) at org.apache.tomcat.util.net.SocketProcessorBase.run(SocketProcessorBase.java:49) at java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1149) at java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:624) at org.apache.tomcat.util.threads.TaskThread$WrappingRunnable.run(TaskThread.java:61) at java.lang.Thread.run(Thread.java:748)

Une information supplémentaire ;
Quand je retire l’objet ImmDocument de l’export, l’export des données du module se passe bien. Quand je l’ajoute, ça plante !
Cet objet contient des pdf, photo, doc…

Je ne constate pas de pb avec l’export des données du module Demo or l’objet DemoProduct contient aussi des documents et des images.

Le pb est donc ailleurs, peut être dans le code de votre objet (essayez de le mettre en commentaire et retentez l’export).

PS: Ce stacktrace n’est ni très discriminant ni très informatif. On a un peu amélioré la remontée d’exception dans ce cas particulier, il faudra voir demain ce qu’il y a dans le stacktrace si ça aide à mieux cerner votre pb.

L’objet ImmoDocument, qui comporte 106 attributs, n’a pas de code du tout.
Je vais donc réessayer demain et voir si on aura plus de remontés d’exception.

J’ai fait un test d’export data sur un module dont l’un des objets content 466 champs (c’est pas une faute de frappe) pas de pb, je ne pense donc pas que le nombre de champs de votre objet pose problème.

Quelle est la taille des fichiers joints, sous entendu est-ce compatible avec la mémoire allouée à votre instance de démo ou de formation (à savoir 512Ko) ?

Voici la log système de ce matin suite à un export des données :
2018-02-24 12:01:49,735 ERROR [com.simplicite.util.ObjectDirect] SIMPLICITE|http://demo.simplicite.io:13398||ECORED0001|system|com.simplicite.util.ObjectDirect|invokeAction||Erreur Module
com.simplicite.util.exceptions.ActionException
at com.simplicite.util.engine.ObjectManager.invokeActionSync(ObjectManager.java:3230)
at com.simplicite.util.ObjectDirect.invokeAction(ObjectDirect.java:664)
at com.simplicite.util.ObjectDB.invokeAction(ObjectDB.java:1595)
at com.simplicite.util.ScriptedObjectDB.invokeAction(ScriptedObjectDB.java:1428)
at com.simplicite.webapp.tools.JSONServletTool.action(JSONServletTool.java:1321)
at com.simplicite.webapp.ObjectJson.action(ObjectJson.java:662)
at com.simplicite.webapp.tools.JSONServletTool.businessObjectService(JSONServletTool.java:520)
at com.simplicite.webapp.servlets.AbstractJSONServlet.service(AbstractJSONServlet.java:84)
at javax.servlet.http.HttpServlet.service(HttpServlet.java:742)
at org.apache.catalina.core.ApplicationFilterChain.internalDoFilter(ApplicationFilterChain.java:231)
at org.apache.catalina.core.ApplicationFilterChain.doFilter(ApplicationFilterChain.java:166)
at org.apache.tomcat.websocket.server.WsFilter.doFilter(WsFilter.java:52)
at org.apache.catalina.core.ApplicationFilterChain.internalDoFilter(ApplicationFilterChain.java:193)
at org.apache.catalina.core.ApplicationFilterChain.doFilter(ApplicationFilterChain.java:166)
at com.simplicite.webapp.filters.AuthMethodFilter.doFilter(AuthMethodFilter.java:108)
at com.simplicite.webapp.filters.AbstractFilter.doFilter(AbstractFilter.java:37)
at org.apache.catalina.core.ApplicationFilterChain.internalDoFilter(ApplicationFilterChain.java:193)
at org.apache.catalina.core.ApplicationFilterChain.doFilter(ApplicationFilterChain.java:166)
at org.apache.catalina.core.StandardWrapperValve.invoke(StandardWrapperValve.java:199)
at org.apache.catalina.core.StandardContextValve.invoke(StandardContextValve.java:96)
at com.simplicite.tomcat.valves.APISessionValve.invoke(Unknown Source)
at org.apache.catalina.core.StandardHostValve.invoke(StandardHostValve.java:140)
at org.apache.catalina.valves.ErrorReportValve.invoke(ErrorReportValve.java:81)
at org.apache.catalina.valves.AbstractAccessLogValve.invoke(AbstractAccessLogValve.java:650)
at org.apache.catalina.core.StandardEngineValve.invoke(StandardEngineValve.java:87)
at org.apache.catalina.connector.CoyoteAdapter.service(CoyoteAdapter.java:342)
at org.apache.coyote.http11.Http11Processor.service(Http11Processor.java:803)
at org.apache.coyote.AbstractProcessorLight.process(AbstractProcessorLight.java:66)
at org.apache.coyote.AbstractProtocol$ConnectionHandler.process(AbstractProtocol.java:790)
at org.apache.tomcat.util.net.NioEndpoint$SocketProcessor.doRun(NioEndpoint.java:1459)
at org.apache.tomcat.util.net.SocketProcessorBase.run(SocketProcessorBase.java:49)
at java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1149)
at java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:624)
at org.apache.tomcat.util.threads.TaskThread$WrappingRunnable.run(TaskThread.java:61)
at java.lang.Thread.run(Thread.java:748)

Il y a effectivement des documents qui font plus de 512 Ko (jusqu’à même 25 Mo pour certains).
Faut-il tous les supprimer et retenter l’export ?

Le stacktrace n’apporte pas plus d’information que celui d’hier. On doit donc être dans un cas d’erreur non prévu.

Je me suis trompé hier en disant 512Ko je voulais dire 512Mo => c’est la mémoire max allouée à votre instance de demo (sur un autre serveur on pourrait lui allouer plus de mémoire), c’est un minimum pour faire tourner Simplicité mais ça laisse peu de mémoire disponible pour les traitements “lourds”.

Je ne sais pas trop si votre pb peut venir de là mais encoder des documents de 25Mo ou plus en base 64 dans du XML j’avoue que je ne sais pas si ça se passe bien…

On va regarder pour que l’export data du module utilise plutôt le format ZIP par défaut, en attendant faites le test en retirant les plus gros documents (ceux de qques Mo ou moins ne poseront pas pb, sauf s’ils sont très nombreux)

Je confirme qu’en retirant les 7 documents qui font plus de 2 Mo et en laissant les 33 autres documents dans le module, l’export des données se passe bien.

OK il y a donc sans doute un pb, visiblement pas bien catché, lié à la conversion en base 64 des contenus binaire des docs dans le format XML standard.

Clairement un export de données contenant des gros documents ext à faire plutôt en format ZIP standard et plutôt via l’interface I/O (cf. https://www.simplicite.io/resources/documentation/02-integration/io-commandline.md)

Le format de l’export des données du module est aujourd’hui uniquement XML, on va voir si c’est possible de changer ça en format ZIP mais, en l’état, l’export des données du module n’a pas été conçu pour être un mécanisme d’export de données autres que de simples données de référence et/ou d’un simple jeu de données de dev/test en complément du paramétrage.

Pourriez-vous me dire svp où est ce qu’il faut stocker (physiquement) le fichier ZIP pour pouvoir l’importer avec curl dans un environnement cible ?

Si je le mets sur mon pc (exemple : D:\ZIP\toto.zip), est ce que c’est ce chemin qu’il faut mettre dans la commande :
form file=@<D:\ZIP\toto.zip>
Merci d’avance.
Abed.

Vous pouvez metre vos fichiers ZIP/XML où vous voulez…

Dans tous les exemples de la doc la syntaxe <...> et [...] c’est juste les notations classiques BNF-like (cf. https://en.wikipedia.org/wiki/Extended_Backus–Naur_form) il ne faut pas les mettre dans les commandes

Merci @david, j’ai réussi à charger les documents dans l’objet immoDocument en passant par curl.

OK tant mieux, pour l’automatisation de tout ça on vous conseille d’utiliser une approche scriptée.

Par exemple on met à dispo un template de projet basé sur Apache Ant ici: https://github.com/simplicitesoftware/project-template, dans des cas simples c’est pas forcément utile d’avoir ce genre de “chapeau” mais sur des projets plus complexes (multi-instances, multi modules, données métier, doc, …) c’est un bon cadre pour travailler.

Bonjour,
J’essaie de faire un « Exporter les données » du module immorecette et j’obtiens l’erreur : java.lang.OutOfMemoryError: Java heap space
Même après avoir fait un un « Purge » de l’instance dans SIM et un vide cache complet.
Je pense qu’en terme de volumétrie, on doit être à moins de 0,5 Go.
Merci pour votre aide.
Abed.

Comme déjà dit plusieurs fois la fonction d’export des données du module n’est pas fait pour autre chose qu’exporter d’un coup en XML un jeu de dev/test restreint et/ou des données de référence. S’il y a un out of memory c’st forcément que le volume de données en question n’est pas adapté.

Si vous devez exporter des “vraies” données faites le de préférence objet par objet via le endpoint I/O (en le scriptant en Apache Ant ou autre) en choisissant le format adapté à vos volumétries (donc plutôt ZIP si vous avez des fichiers/images). Cf. https://www.simplicite.io/resources/documentation/02-integration/io-commandline.md

Un pattern de package “projet” avec son script Ant (qui utilise des appels curl sur I/O) est disponible sur GitHub : https://github.com/simplicitesoftware/project-template

Sauf que le Out of memory arrive lors de de l’export de 82 Mo (taille de Immo_data.xml) alors que la taille de la mémoire est censée être 1 Go !
En plus c’est un besoin ponctuel, donc si j’y arrive avec un simple coup de « Exporter les données », sans avoir à automatiser le tout, je suis preneur, surtout que je ne connais pas Apache Ant 😉.

Le débat n’est pas sur le volume des données mais sur le fait que cette fonction d’ export des données du module n’a pas été conçue pour être autre chose que ce que j’ai expliqué et qui ne correspond en aucun cas à l’usage que vous en faites.

Pour exporter les données d’un objet en format ZIP (celui qui ne posera normalement pas de pb de mémoire) les bonnes manière de faire sont:

Scripter les appels sur le endpoint I/O (via un .bat, un script Ant, etc.) n’est nécessaire que si vous voulez ne pas avoir à refaire les actions ci-dessus manuellement à chaque fois, ce n’est en aucun cas obligatoire.

Bonjour,
J’essaie de faire un export/import de l’objet immoDocument(~320 Mo) avec curl comme préconsié.

J’ai fait un export depuis la recette avec la commande suivante :

curl -u designer:MotDePasseDesigner -b cookies.txt -c cookies.txt --form service=zipexport -o D:\immoDocument.zip --form object=immoDocument https://immorecette.e3m.simplicite.io/io

Ensuite, j’ai essayé de l’importer dans l’instance immodevabed avec la commande suivante :

curl -u designer:MotDePasseDesigner -b cookies.txt -c cookies.txt --form service=zipimport --form file=@D:\immoDocument.zip https://immodevabed.e3m.simplicite.io/io

J’ai obtenu sous dos l’erreur suivante : WARN: Empty data

En regardant dans la log système :

2018-06-03 15:57:43,404 WARN [com.simplicite.webapp.servlets.IOServlet] SIMPLICITE|http://e3m.simplicite.io:10028||WARN|designer|com.simplicite.webapp.servlets.IOServlet|doPost||Evénement: Empty data
2018-06-03 15:57:43,403 INFO [com.simplicite.webapp.servlets.IOServlet] SIMPLICITE|http://e3m.simplicite.io:10028||INFO|designer|com.simplicite.webapp.servlets.IOServlet|doPost||Evénement: I/O service IMPORTZIP path=immoDocument.zip...
2018-06-03 15:57:43,403 INFO [com.simplicite.webapp.servlets.IOServlet] SIMPLICITE|http://e3m.simplicite.io:10028||INFO|designer|com.simplicite.webapp.servlets.IOServlet|doPost||Evénement: Using I/O grant
2018-06-03 15:57:43,400 INFO [Logon] SIMPLICITE|http://e3m.simplicite.io:10028||SESSION|designer|Logon|login (direct)||Session user=designer/IO_SESSION_designer temps=0
2018-06-03 15:57:43,395 INFO [Logon] SIMPLICITE|http://e3m.simplicite.io:10028||SESSION|designer|Logon|login (direct)||Session user=designer/IO_SESSION_designer temps=0
2018-06-03 15:57:43,320 WARN [com.simplicite.webapp.tools.ServletParameters] SIMPLICITE|http://e3m.simplicite.io:10028||WARN|system|com.simplicite.webapp.tools.ServletParameters|loadParameters||Evénement: ERR_MAX_UPLOAD_SIZE:100Mo

Donc j’ai augmenté le paramètre MAX_UPLOAD_SIZE à 1000 Mo (au lieu de 100 Mo initiallement).

Maintenant, quand je lance la commende d’import, je n’ai plus de message d’erreur sous dos ou dans la log, mais le traitement ne se termine pas, je dois l’arrêter avec Ctrl-C et rien n’est chargé dans l’objet immoDocument cible.

Auriez-vous une idée svp de ce qui ne va pas dans ce que je fais ?

Merci d’avance.
Abed.