Foire aux questions

Comment EsupDematEC est reliée à Galaxie ?

Galaxie propose aux gestionnaires un export des voeux des candidatures par un fichier Excel, c'est ce fichier Excel qui, importé dans EsupDematEC, permet de prendre en compte les candidatures et les postes liés.

Le fichier excel de Galaxie est-il reçu automatiquement ? Qui contacter pour faire une telle demande ?

Dans un usage classique, le fichier Excel de Galaxie n'est pas reçu automatiquement par défaut (voir sinon la question Peut-on automatiser la procédure d'import des fichiers Galaxie ?), c'est aux gestionnaires de l'exporter depuis l'interface web de Galaxie, puis de l'importer dans EsupDematEC via l'interface web d'EsupDematEC.

Pour ce faire cette personne doit être "super-manager" dans EsupDematEC.

Le fichier Excel est donc généré à la demande par Galaxie et il contient l'ensemble des voeux des candidatures reçus depuis le début : il est de plus en plus gros.

Ceci est notamment vrai si vous demandez à faire des extractions complètes/totales dans Galaxie, et c'est ce que nous conseillons de faire : Galaxie peut en effet vous fournir des extractions partielles ne proposant que les entrées modifiées/ajoutées depuis l'extraction précédente ... en utilisant de telles extractions, vous devez être très vigilants et bien prendre en compte toutes les extractions que vous effectuez , l'extraction totale/complète depuis Galaxie nous parait donc à privilégier.

EsupDematEC est donc capable de traiter des imports Exel Galaxie présentant à chaque fois des candidatures déjà traitées, aussi il ne génère les comptes et postes que lorsque ceux-ci ne sont pas déjà présents dans l'application. Plus généralement il ne prend donc en compte que les 'nouveautés' d'un nouvel import d'un fichier Excel Galaxie.

EsupDematec signale tout problème éventuel sur l'importation, sur le fichier (mail non renseigné, mail mal formé, etc.) via ses journaux consultables en ligne.

Plus précisément, comment fonctionne l'import des fichiers Excel Galaxie dans EsupDematEC ?

EsupDematEC met en base de données (table galaxie_entry) l'ensemble des éléments provenant des différents Excel importés.
Il lit les fichiers Excels dans l'ordre d'arrivée et de haut en bas, stocke en base chaque ligne comme une candidature et écrase (remplace) en base les éléments d'une candidature qu'il a déjà vu. Une candidature étant identifiée par le numéro de candidat et le numéro d'emploi.

Une fois la table galaxie_entry recalculée après un import d'un Excel, EsupDematEC propose la génération des comptes utilisateurs (bouton généré), postes et candidature si il voit des éléments d'un galaxy_entry ne correspondant pas à un utilisateur, un poste ou/et encore une candidature.

Altaïr, Antee, Fidis ... EsupDematEC est utilisable pour les A.T.E.R. ou les E.C. ?

Galaxie propose des applications différentes suivant les type de recrutement. Pour les A.T.E.R. (Attaché Temporaire d'Enseignement et de Recherche) c'est Altaïr par exemple.
Aussi les fichiers Excel exportés de Galaxie n'ont pas toujours le même format, cela peut même éventuellement changer d'une campagne sur l'autre. 

Jusqu'en version 1.2.3 EsupDematEC proposait un fichier de configurations src/main/resources/META-INF/spring/applicationContext-galaxie.xml permettant de modifier la correspondance entre les noms des colonnes Excel du fichier Galaxie et les champs attendus par EsupDematEC.
A partir de la version 1.3.0 ce paramétrage se fait directement via l'interface graphique, menu "Mapping Galaxie". 

3 champs sont à renseigner correctement au minimum : id_email, id_numemploi et id_numCandidat.

Les autres champs ne servent "qu'à" l'affichage et n'influent pas sur le bon fonctionnement de l'application.

Ces champs doivent donc impérativement être vérifiés avant le premier import Excel Galaxie d'une campagne !

En 2019/2020, seul Altaïr ne propose pas la dématérialisation des pièces jointes, fonctionnalité pour laquelle EsupDematEC a été développée initialement. 

Aussi en 2019/2020, EsupDematEC n'est plus utilisable qu'avec Altaïr.

Dès 2020/2021, on peut s'attendre à ce que Galaxie propose également pour le recrutement des ATER cette évolution.

EsupDematEC peut supporter plusieurs campagnes en même temps ?

Entre chaque campagne, on pourra simplement purger la quasi-totalité de la base de données. Ce excepté, la table permettant l'adaptation du titre, textes d'aide, textes de mail, logo ... ainsi que les comptes admin et (super-)managers - cf question dans cette FAQ sur la mise à jour applicative.

À quoi correspondent les différents rôles dans EsupDematEC, à quoi servent-ils ?

Les rôles des utilisateurs dans EsupDematEC sont les suivants : 

Admin 

Les utilisateurs avec le rôle "Admin" ont  le maximum de droits - cependant les droits supplémentaires qu'il a par rapport au SuperManager ne sont en fait pas censés servir dans une utilisation normale d'EsupDematec : par exemple, le bouton """Créer un nouveau "Galaxie Entry"""" ne doit pas être utilisé : ces éléments doivent être générés uniquement par l'import de fichiers Excel Galaxie. 

Ce rôle peut éventuellement être donné à un administrateur informatique.

SuperManager

C'est le rôle à utiliser pour gérer l'instance d'EsupDematEC.
Il est donné usuellement au( x ) responsable(s) fonctionnels d'EsupDematEC du service DRH.

Les super-manager peuvent configurer les textes, logos etc. de l'application, créer d'autres utilisateurs manager ou supermanager en leur attribuant un password.

C'est le supermanager qui importe régulièrement les fichiers Excel Galaxie présentant les candidatures.
C'est encore lui qui actionne le formulaire pour lancer les créations de comptes depuis les informations issues de ces fichiers Excel Galaxie.
De même pour les membres de commissions (utilisation d'un fichier Excel spécifique, donné en exemple dans le bloc d'aide du menu concerné).

Il peut également ajouter éventuellement des fichiers de candidatures à la place  des candidats.

Il a de plus tous les droits d'un manager.

Manager

Donné usuellement aux personnels du service DRH (qui ne sont pas déjà supermanager), il permet de consulter l'ensemble des journaux sauvegardés en base de données ainsi que l'ensemble des candidatures (téléchargement des fichiers).

Ils peuvent également noter une candidature comme non recevable. Celle-ci ne sera pas supprimée mais elle ne sera pas listée aux membres de la commission correspondante.

Membre

Créés depuis depuis l'importation d'un fichier Excel présentant un couple "email / numéro de poste", les membres ont le droit de consulter l'ensemble des candidatures des postes sur lesquels ils ont été affectés (et marqués comme recevable), ils ont également le droit de déposer des "rapports du comité de sélection" qui peuvent être consultés par les autres membres (mais pas par les candidats) .

• (à partir de 1.5.0) - membre président : en plus d'être membre un utilisateur président d'un poste a la possibilité d'ajouter et supprimer des fichiers sur la page poste prévu à cet effet. Un membre pouvant télécharger ces mêmes fichiers.
• (à partir de 1.5.0) - un manager ou président peut nommer un membre rapporteur d'une candidature ; un rapporteur n'a pas de droits supplémentaires sur la candidature considérée par rapport aux autres membre, un code  couleur permet simplement aux membres de commissions de distinguer les candidatures pour lesquelles ils ont été nommés rapporteurs.

Candidat

Crées depuis l'importation d'un fichier Excel Galaxie, les candidats peuvent déposer des fichiers dans l'interface web d'EsupDematEC. Ils peuvent les supprimer ou encore les retélécharger (pour s'assurer par exemple de leur bonne transmission). 

A quoi correspond la fonctionnalité de "SU" d'EsupDematEC ?

La fonction de Switch User (SU)  permet à un admin ou super-manager de se connecter au nom d'un autre utilisateur en rentrant simplement le nom d'utilisateur (email) dans un formulaire.

Elle permet ainsi de "voir" précisément l'interface d'un utilisateur spécifique, de voir "ce que voit" l'utilisateur.

Les actions effectuées sur les fichiers seront journalisées dans la base au nom de l'admin ou du super-manager (avec le nom de l'utilisateur cible mentionné également)

Quand importer les candidats dans EsupDematEC ? Et les membres ?

La campagne lancée, Galaxie va permettre via des exports de fichiers Excel (réalisés régulièrement) de mettre à jour dans EsupDematEC les candidatures.

Cette mise à jour, effectuée manuellement par un supermanager, peut se faire quotidiennement ou plus encore : dans les faits, il semble pertinent de réaliser cette extraction/importation 2 fois par jour en début de campagne puis d'accélérer le rythme en fin de campagne (pour laisser un maximum de temps aux candidats tardifs, qui représente une population nombreuse).

Cette extraction/importation provoque la création de comptes candidat et de postes dans l'application. En plus de créer le compte, EsupDematEC envoie un mail d'activation sur le mail du candidat (le candidat doit donc renseigner un mail valide dans Galaxie) afin que celui-ci puisse se connecter sur EsupDematEC et uploader les fichiers demandés.

La période d'enregistrement close sur Galaxie, et suivant la date maximale d'envoi de fichiers positionnée par le super-manager, les candidats ne peuvent plus modifier leur candidature ni même se connecter.
Une fois l'ensemble des candidatures consultées par le service DRH (super-manager et manager), une fois les témoins positionnés éventuellement à non-recevable (le témoin est à recevable par défaut), le super-manager peut importer un ou plusieurs Excel présentant les membres des commissions.

Comme pour les candidats, le mail des membres, renseignés dans les Excel vont permettre l'envoi par l'application de mails d'activation. 

Quand et pourquoi changer l'état d'une candidature dans EsupDematEC ?

EsupDematEC permet aux gestionnaires (manager; super-manager, admin), qui correspondent usuellement aux personnels du service DRH, de changer les candidatures d'"états". 

Plus précisément, une candidature peut être à la fois (champs disjoints):

• recevable ou non recevable
• retenue pour audition ou non retenue pour audition
• Non_vue ou Vue ou Vue_mais_modifie_depuis ou Vue_incomplet ou Vue_incomplet_mais_modifie_depuis

recevable ou non recevable

L'état recevable ou non recevable permet d'afficher ou non les candidatures aux membres de la commission. Cela ne change pas les permissions d'accès du candidat à la candidature. Le candidat n'a d'ailleurs pas connaissance de cet état.

Ainsi, passer l'état d'une candidature de non recevable à recevable de verrouillera pas pour autant la candidature : le candidat pourra encore la modifier, c'est à dire supprimer ou ajouter des fichiers. Le verrouillage des candidatures vis à vis des candidats est uniquement régi par la "date fin de candidat (actif)" - voir question s'y rapportant ci-dessous.

C'est ainsi que l'on conseille de n'importer les commissions qu'une fois la "date fin de candidat actif" passée, et donc une fois que les candidatures sont effectivement stabilisées.

retenue pour audition ou non retenue pour audition

Une candidature qui passe de l'état "non retenue pour audition" à l'état "retenue pour audition" engendre l'envoi d'un mail que le manager peut en partie éditer. Cela provoque aussi le verrouillage de la candidature non plus en fonction de la  "date fin de candidat (actif)" mais de la "Date fin candidat auditionnable" (voit la question s'y rapportant ci-dessous).

Non_vue ou Vue ou Vue_mais_modifie_depuis ou Vue_incomplet ou Vue_incomplet_mais_modifie_depuis

Ces différents tags sont un outil visuel (codes couleurs) donné au gestionnaire pour gérer plus facilement les candidatures.

Il est à noter enfin qu'aucune synchronisation n'est faite entre les états de la candidature dans Galaxie et les états de la candidature dans EsupDematEC : une double saisie est donc à faire par le service DRH.

Le renseignement de l'adresse Email du candidat dans Galaxie est donc obligatoire pour EsupDematEC ?

Oui ! Et comme Galaxie ne le précise pas (le champ mail n'est actuellement pas obligatoire dans celui-ci), les fiches de postes mis à disposition sur Galaxie doivent donc le préciser !

Dans ces fiches, vous (service RH) pourrez ajouter par exemple un encart "Consignes à respecter obligatoirement pour votre dossier de candidature" précisant clairement que le renseignement d'une adresse Email valide est indispensable et qu'aucune candidature papier ne sera recevable ... 

EsupDematEC possède-t-elle un système d’horodatage ?

EsupDematEC garde trâce de toutes les actions upload/download/delete des fichiers (également des authentifications) en base de données (en plus des logs classiques) - ces informations sont ainsi consultables par les "admin" et "super-manager" de l'application.

Qu'est ce qu'un candidat actif  dans EsupDematEC ?

Un candidat actif est un candidat qui a procédé à au moins un envoi de fichier (même si il l'a ensuite supprimé).

À quoi correspondent les dates configurables dans EsupDematEC ?

• Date fin candidat : date à partir de laquelle les candidats (non actifs) n'ont plus accès à l'application.
• Date fin candidat actif : date à partir de laquelle les candidats actifs n'ont plus accès à l'application.
• Date fin membre : date à partir de laquelle les membres n'ont plus accès à l'application.
• Date fin candidat auditionnable (configurable pour chaque poste) :   date à partir de laquelle les candidats retenus pour audition n'ont plus accès à l'application.

Lorsque les candidats n'ont plus accès à l'application suite au dépassement de ces dates, leurs tentatives d'authentification échouent, le message "la date de clôture des dépôts est dépassée" apparaît.

Comment sont donnés les login / password par EsupDematEC ?

Les login correspondent aux mails des individus, ils sont

• soit saisis manuellement dans un formulaire pour les admin, super-manager et manager
• soit renseignés automatiquement via l'import des fichiers Excel Galaxie / de commisions.

Les passwords sont chois par les utilisateurs à l'activation du compte.
Un super-manager peut aussi le renseigner (ou l'écraser) directement dans un formulaire.
Il n'est jamais lisible par contre, car chiffré dans la base de données.

Est-ce qu'EsupDematEC est cassifié ?

Non, nous avons choisi de faire d'EsupDematEC une application indépendante des briques du SI.

Elle utilise donc notamment sa propre gestion de comptes.

Peut-on automatiser la procédure d'import des fichiers Galaxie ?

Côté EsupDematEC, la commande Bash suivante vous permet d'importer en ligne de commande un fichier Excel Galaxie.

mvn clean compile exec:java -Dexec.args="importgalaxie /tmp/EXTETBF.xls" 

Un certain nombre d'établissements ont en effet automatisé l'import des fichiers Excel Galaxie dans EsupDematEC. Pour ce faire, et en lien avec l'équipe technique de Galaxie, un dossier partagé est créé et Galaxie y dépose régulièrement les extractions qu'EsupDematEC importe grâce à la ligne de commande ci-dessus.

En plus de cette ligne de commande, on peut proposer un accès ssh via un serveur ssh léger et spécifique (comme dropbear par exemple) sur un port particulier.
On créé et dédie un utilisateur à Galaxie pour qu'il puisse s'authentifier par clef ssh et réaliser un scp sur un répertoire spécifique dédié (par exemple /opt/galaxie-import/).
Puis ont peut passer par la configuration d'un incron pour prendre en compte tout fichier déposé dans ce répertoire : 

cat /etc/incron.d/galaxie-import 
/opt/galaxie-import IN_CLOSE_WRITE /root/import-galaxie.sh $#

Exemple de bash appelé par la tâche incron :

cat /root/import-galaxie.sh
#!/bin/bash
if [[ "$1" == *zip ]]
then
cd /opt/galaxie-import/ && unzip $1 &>> /var/log/demat-ater-import-galaxie.log
su - tomcat -c "cd /opt/demat-ater/ && flock /tmp/esup-demat-import-galaxie.lock -c 'mvn exec:java -Dexec.args=\"importgalaxie /opt/galaxie-import/${1/.zip/}/${1/.zip/.xls}\"'" &>> /var/log/demat-ater-import-galaxie.log
fi

Les admin, manager et super-manager peuvent se connecter à EsupDematEC depuis l'extérieur de l'université?

EsupDematEC peut tourner sur du MySQL au lieu de PostgreSQL ?

L'application EsupDematEC nécessite une BD SQL supportant les transactions ainsi que le streaming sur les blobs. 
Par défaut mysql (et innodb) ne supporte pas actuellement le streaming sur les blobs. 

A moins d'être un DB Admin très averti sur la question, on peut considérer qu' EsupDematEC requiert purement et simplement l'utilisation de PostgreSQL - ce notamment pour sa gestion très efficace des blobs : EsupDematEC stocke effectivement les fichiers des candidats "en base", c'est à dire sous forme de blobs (qui sont en fait stockés astucieusement sous forme de fichier séparé dans le file system pour postgresql).

A ce propos, on vous recommande donc de bien suivre la documentation technique d'EsupDematEC notamment autour de la mise en place de Postgresql :
https://github.com/EsupPortail/esup-dematec#postgresql

Quid de la volumétrie ? Et les sauvegardes des données d'EsupDematEC ?

Suivant les documents demandés, la volumétrie peut évidemment varier. Si les documents demandés restent des fichiers textes (pdf), les tailles restent "relativement" faibles par rapport aux capacités des serveurs actuels.
Voici un exemple de volumétrie sur une campagne de recrutement (2014) : 

Nombre de postes 22 
Candidats uniques 541 
Candidats actifs 515 
Nombre de candidatures 632 
Nombre de candidatures actives (au moins une modification) 589 
Fichiers déposés 1747 
Volume total 3,9 GB 
Taille Max Fichier 131 MB 

-> taille disque de /var/lib/postgresql : 5.8 Go (à noter : ~ 1.5 fois plus que la taille totale des fichiers). 

-> taille d'un pg_dump en directory (-F d disponible depuis postgres 9) : 3,7 Go 

Que faut-il mettre en place pour sauvegarder l'ensemble des données EsupDematEC dont les fichiers de candidatures ?

L'ensemble des données est stocké dans une base de données PostgreSql. Sauvegarder les données revient à sauvegarder la base de données.

PostgreSql propose différents mécanismes de sauvegarde. Le mécanisme le plus simple est de faire un simple dump de la base de données (pg_dump).

Depuis Postgres 9, la commande pg_dump propose une sortie sous forme de répertoire, où chaque blob (correspondant à chaque fichier déposé dans EsupDematEC) se retrouve sous la forme d'un fichier compressé. L'intérêt est alors que

• ce dossier issu du pg_dump e prête bien bien aux robots de sauvegarde et à leurs possibilités de sauvegarde incrémental
• le pg_dump en directory est plus rapide que les autres pg_dump, notamment sur des bases de données avec des blob volumineux.

Exemple d'une ligne crontab faisant un dump toutes les nuits (1H30) dans l'optique du passage d'un robot de sauvegarde dans le répertoire /var/lib/postgresql/backup/dematater-dump :

30 01 * * * postgres rm -rf /var/lib/postgresql/backup/dematec-dump && pg_dump -b -F d -f /var/lib/postgresql/backup/dematec-dump dematec

A noter que le répertoire cible du dump doit pouvoir supporter la taille du dump (~ équivalent à la taille de l'ensemble des fichiers de candidatures).

 pg_restore -d dematec /var/lib/postgresql/backup/dematec-dump

Nous devons archiver les candidatures pour une période de 5 ans*, que propose EsupDematEC ?

Depuis la version 1.1.0, EsupDematEC propose une commande bash permettant d'exporter les candidatures dans un système de fichiers classique.
Cela permet d'archiver les candidatures et de les stocker sur un espace de stockage quelconque, une clef usb, un disque externe crypté.

Depuis le répertoire source d'EsupDematEC on lance la commande ainsi : 

mvn clean compile exec:java -Dexec.args="archive /opt/archive-demat-ater-2013"

* 5 ans est la période spécifiée dans l'Instruction DPACI/RES/2005/003 du 22 février 2005
http://circulaire.legifrance.gouv.fr/pdf/2009/04/cir_281.pdf - page 31

Comment télécharger EsupDematEC ?

On vous propose de récupérer EsupDematEC par Git pour faciliter les mises à jour.
Dans ce cas là, assurez-vous alors de bien vous positionner sur le dernier tag d'EsupDematEC, et pas sur une version de développement encore instable.
Exemple de commande pour ce faire (on se positionne ici sur le tag  EsupDematEC-1.4.5 en nommant notre branche locale sous le nom de 'recrutement-ater') :

git clone https://github.com/EsupPortail/esup-dematec.git
git checkout -b recrutement-ater EsupDematEC-1.4.5 

Si vous ne souhaitez pas utiliser git, vous pouvez aussi télécharger ces mêmes versions en zip ou tar.gz : 
https://github.com/EsupPortail/esup-dematec/releases 

Comment installer EsupDematEC ?

La procédure d'installation est décrite dans le README : https://github.com/EsupPortail/esup-dematec/blob/master/README.md

Est-il possible de mettre à jour EsupDematEC facilement ?

Les mises à jour des versions mineures d'EsupDematEC (entre 1.0.0 et 1.0.1 par exemple) ne demandent pas de changement au niveau de la strucure de la base de données, elles se font simplement.
Ainsi si vous récupérez le code via GIT (et que vous y gérez de fait vos configurations, on vous y encourage), une commande de type git pull, un redéploiement et redémarrage suffisent.

Pour les mises à jour des versions majeures (entre 1.0.3 et 1.1.0 par exemple), il peut y avoir des opérations de mise à jour à effectuer au niveau de la base de données.
Pour ce faire, une commande batch est disponible, après avoir fait un pull sur la nouvelle version, vous pouvez lancer : 

mvn clean compile exec:java -Dexec.args="dbupgrade"

Pour une nouvelle campagne, vous pouvez aussi repartir d'une base de données vierge ... si vous voulez conserver les configurations (titre, textes mail, logos, ...) ainsi que les comptes admin et (super-)manager cependant, vous pouvez "nettoyer" votre base :

mvn clean compile exec:java -Dexec.args="deletedata"

Cette commande efface donc notamment tous les fichiers de candidatures !

D'un point de vue pratique :

1. Il est conseillé d'éviter de faire des mises à jour de versions majeures en pleine campagne.
2. Une nouvelle campagne requiert de repartir d'une base de données quasi vierge (archivez les candidatures avec la commande adéquate avant, cf question ci-dessus) - puis pour la mise en place de la nouvelle campagne : 
   1. vous pouvez simplement repartir de zéro au niveau de la base (base complètement vierge, configurations à ressaisir)
   2. si vous souhaitez récupérer les configurations (correspond à une tableappli_config et depuis la 1.3.0 également à  appli_config_file_type) et les comptes admin et (super-)manager (correspond à la table des utilisateurs c_user), vous pouvez éventuellement supprimer les données via la commande deletedata, mettre à jour votre code EsupDematEC (on vous conseille de gérer cela via git) puis migrer la base via dbupgrade.
3. Si vous avez pris "trop"  de "retard" entre les différentes versions, repartez d'une base et d'une installation vierge ; reprenez 'manuellement' (ou par script sql) les quelques configurations que vous souhaitez et que vous pouvez reprendre. Les mises à jours de versions majeures éloignées n'ont pas été validées ni testées (de la 1.0.3 à la 1.3.0 par exemple).

EsupDematEC peut fonctionner en load-balancing ?

Actuellement EsupDematEC est prévue pour fonctionner sur une seule instance d'un serveur web Java type Tomcat. Son fonctionnement en load-balancing est donc actuellement déconseillé.

Détails techniques supplémentaires ici : 

Techniquement, le fait que tout soit stocké en base de données pourrait faciliter le support du load-balancing (pas d'accès concurrent à un file system à gérer notamment.
Cependant pour faciliter le développement et optimiser les performances, nous avons choisi de mettre en cache (cache simple en mémoire) les paramétrages de l'application issus des tables  appli_config et galaxie_mapping - ce cache est mis à jour lors de la modification par l'IHM des paramétrages - dans un fonctionnement en load-balancing, il ne serait alors mis à jour que sur une seule instance. 

Quelles sont les 'recommandations' système pour EsupDematEC ?

EsupDematEC est une application web java (servlet/jsp), aussi on recommande d'installer EsupDematEC de la même manière que vous installez vos autres applications CAS, ENT EsupPortail, Idp Shibboleth, etc.

Traditionnellement (au niveau Esup notamment), ces installations correspondent à la mise en place d'un Tomcat intégrant la 'webapp' EsupDematEC et la mise en place d'un Apache en frontal permettant ainsi de gérer à ce niveau certaines fonctionnalités comme le SSL (https), le cache, la compression, ...

CF la documentation suivante par exemple : Apache frontal (esup 4)

Au niveau Apache, outre bien sûr les configurations du SSL  notamment, vous pourrez avoir une configuration contenant celà : 

    ProxyPass / ajp://localhost:8009/ ttl=10 timeout=1200 retry=1

    ExpiresActive On
    ExpiresByType text/css "access plus 3 hours"
    ExpiresByType text/javascript "access plus 3 hours"
    ExpiresByType application/javascript "access plus 3 hours"
    ExpiresByType image/gif "access plus 1 day"
    ExpiresByType image/png "access plus 1 day"
    ExpiresByType image/jpg "access plus 1 day"
    ExpiresByType image/jpeg "access plus 1 day"
    ExpiresByType application/x-shockwave-flash "access plus 1 day"
    ExpiresByType image/x-icon  "access plus 1 day"

    CacheRoot /var/cache/httpd/esup-dematec
    CacheEnable disk /resources/
    CacheDirLevels 2
    CacheDirLength 1

    AddOutputFilterByType DEFLATE text/html text/css text/javascript application/x-javascript application/javascript

L'application EsupDematEC est assez peu gourmande en ressource système. L'usage du streaming au niveau des downloads/uploads de fichiers de la requête jusqu'à la base postgresql permet de limiter l'usage de la RAM.

De même les sessions utilisateurs ne consomment que très peu de RAM.

Ainsi, en tant qu'établissement de 30.000 étudiants par exemple, dans l'hyptohèse que vous utilisiez un seul serveur (VM) pour 4 instances d'EsupDematEC avec donc 4 tomcat, 1 Apache (servant 4 VirtualHost) et 1 PostgreSQL (servant 4 bases), 2 CPUs et 4 GB de RAM conviendront.

Il faudra aussi penser à ajuster les paramètres de mémoire de Java ainsi par exemple : 

-Xms512m -Xmx512m

Le format du fichier que Galaxie envoie pour EsupDematEC n'est pas reconnu.

Suivant les campagnes et les paramétrages effectués, des établissements se voient parfois proposer des fichiers Excel Galaxie non directement interprétables par EsupDematEC.

Ainsi en octobre 2018, nous avons fait évoluer EsupDematEC (version 1.5.5) pour qu'il supporte les fichiers Excel XLSX "Excel 2003 XML" en plus de Excel XLS "Excel 97-2003".

Si vous récupérez un fichier dans un format différent (c'est à dire non compris par votre instance d'EsupDematEC pour une raison donnée), vous pouvez, à défaut d'une solution plus directe, envisager de convertir vos fichiers en ligne de commande avant de l'importer via la commande mvn d'EsupDematEC. 

soffice (libreoffice) en ligne de commande peut parfois dépanner : 

soffice --headless --convert-to xlsx:"Calc MS Excel 2007 XML" fichier-galaxie-format-non-compris-par-esupdematec.xls