Comme dit dans les spécifications les différents modules utilisés dans Ori-Oai-Workflow ainsi que son implémentation via Spring lui confèrent une certaine souplesse. Cette souplesse implique de fait une certaine complexité dans la configuration de l'ensemble de l'application.

Voici le plan de ce chapitre:

Pré-Requis

Quel que soit le workflow que vous configurerez, Ori-Oai-Workflow nécessite en pré-requis que plusieurs services soient disponibles :

• Une base de données SQL supportant les transactions : MySql en Innodb ou une autre BD SQL avec un moteur transactionnel par défaut.

  Dans le cas de MySQL, faites attention à ce que votre base de données pour Ori-Oai-Workflow ait bien le engine storage positionné à innodb !

  Sous linux, dans my.cnf, pour les versions de mysql récente, on pourra vérifier que l'on a :

  default-storage_engine = innodb
  

  Pour une version plus anciennes, l'option est de la forme :

  default-table-type = innodb
  

  Commandes pour vérifier en ligne de commande (client mysql) le storage utilisé sur une table de votre base :

  mysql> use `ori-oai-workflow`;
  Database changed
  mysql> show table status like 'ORI_WORKFLOW_ACL_ROLE';
  +-----------------------+--------+------------+------+----------------+-------------+-----------------+--------------+-----------+----------------+-------------+-------------+------------+----------------+--------------------------------------------------------------------------------------------------------------------------------------+
  | Name                  | Type   | Row_format | Rows | Avg_row_length | Data_length | Max_data_length | Index_length | Data_free | Auto_increment | Create_time | Update_time | Check_time | Create_options | Comment                                                                                                                              |
  +-----------------------+--------+------------+------+----------------+-------------+-----------------+--------------+-----------+----------------+-------------+-------------+------------+----------------+--------------------------------------------------------------------------------------------------------------------------------------+
  | ORI_WORKFLOW_ACL_ROLE | InnoDB | Dynamic    |    5 |           3276 |       16384 |            NULL |        16384 |         0 |              6 | NULL        | NULL        | NULL       |                | InnoDB free: 3072 kB; (`oriAclObjectIdentityId`) REFER `ori-oai-workflow/ORI_WORKFLOW_ACL_OBJECT_IDENTITY`(`oriAclObjectIdentityId`) |
  +-----------------------+--------+------------+------+----------------+-------------+-----------------+--------------+-----------+----------------+-------------+-------------+------------+----------------+--------------------------------------------------------------------------------------------------------------------------------------+
  1 row in set (0.00 sec)
  

• Un annuaire Ldap dans lequel on va pouvoir récupérer les informations des utilisateurs. Si on utilise l'authentification CAS et non Ldap, il faudra s'assurer que le login CAS correspond bien à l'UID dand Ldap (depuis la 1.4.0, on notera que l'annuaire ldap peut maintenant être remplacé par l'utilisation de Shibboleth).
• un serveur smtp afin d'envoyer les emails d'exception à un email donné (en fait, peut être optionnel en modificant le fichier de configuration exceptionHandling.xml).
  Le serveur smtp est utilisé également dans les workflows lors de l'envoi de mails aux modérateurs, etc.

A cela, et suivant votre workflow, vous aurez certainement besoin d'autres services d'activés comme

• le module d'indexation utilisé usuellement lors d'une transition de type "publication".
• ...

Fichiers à configurer par l'utilisateur déployant Ori-Oai-Workflow

build.properties

deploy.home permet de définir le répertoire dans lequel on veut déployer l'application

Enfin il est possible également de définir un zip à importer dans l'application via un script ant.
_

_

conf/properties/main-config.properties

Ce fichier permet de définir les principales configurations d'ordre technique de l'application : authentification ldap/cas, connection ldap, BD SQL, Module d'indexation, serveur smtp, ...

Enfin notez surtout que ce fichier conf/properties/main-config.properties est le fichier principal des configurations et vous renvoie à d'autres fichiers de configuration: les commentaires sont donc à prendre en compte cela vaut pour les autres fichiers de configuration également bien sûr. Il est avant tout destiné à une installation rapide de l'application mais ne permet quasiment pas de personnaliser votre module.

Installation / migration / maintenance via ANT

Une fois les différents fichiers de configuration modifiés pour correspondre à vos besoins, vous pouvez enfin installer/déployer/initialiser votre applciation dans le tomcat cible (cf build.properties). Pour cela un certain nombre de targets ant est à votre disposition :

• clean: pour supprimer les fichiers compilés et déployés.
• deploy: permet de compiler et déployer l'application dans le tomcat.
• all: appelle clean et deploy successivement
• init: pour initialiser la base de données sql : notez que la base doit être créée sur le serveur sql (ATTENTION: si des tables pré-existent elles sont écrasées !).
• update-acls: permet d'informer la base de données des modifications des permissions/rôles faites dans les fichiers de configuration.
• upgrade: met à jour la base de données entre 2 versions d'ori-oai-workflow-spring (target indispensable à appeller pour effectuer une mise à jour entre 2 versions - pensez à sauvegarder votre base de données au préalable)
• importmetadatas: permet d'importer des métadonnées depuis un zip contenant des fichiers xml de métadonnées (le plus simple est cependant de passer par l'Interface Web pour ce faire)
• local-reindexall: permet de mettre à jour l'index local de l'application ori-oai-workflow. ori-oai-workflow utilise en effet un index local (Compass/Lucène) pour permettre une navigation et une recharche rapide dans les fiches. Cet index est indispensable au bon fonctionnement de l'application. Il est synchronisé avec la base de données. Dans certains cas il peut être utile de le reconstruire complètement (resynchroniser) avec la base de données. C'est le but de cette target. Depuis la 1.4 avant de recréer l'index, local-reindexall supprime de fait au préalable l'index (pour le reconstruire entièrement).
• clear-index: la target clear-index détruit l'index local (n'est plus utile depuis la 1.4, cf la target local-reindexall).
• reindexall: demande au module ori-oai-indexing de réindexer toutes les fiches qui sont censées être indexées, c'est à dire qui sont marquées comme étant indexées. Cela peut être utile lors de la reconstruction complète de l'index du module ori-oai-indexing.

Pour une première installation, vous devrez normalement appeler les targets suivantes dans l'ordre :

• deploy,
• init,
• update-acls.
  Avant cela vous aurez :
• configuré les différents fichiers,
• démarré la base de données sql (en y créant la base de données donnée dans le fichier de conf du module),
• ...
  Après l'appel des targets, vous pourrez démarrer le serveur tomcat.

Pour une mise à jour (attention de ne pas appeler la target init qui initalise votre base de données, vous devrez normalement appeler les targets suivantes dans l'ordre (l'application ori-oai-workflow le tomcat doit alors être stoppé) :

• clean,
• upgrade,
• deploy.
  Au préalable vous aurez
• fait des sauvegardes de la base MySQL,
• fait une sauvegarde de vos sources et configurations du module
• fait un switch subversion pour passer du tag précédent à ce nouveau tag au niveau de vos sources (si vous utilisez subversion pour synchroniser vos sources au niveau de l'intégration/exploitation ORI-OAI),

  Utilisez les possibilités de
  svn switchpour passer d'un tag à un autre si vous être branché via Subversion. Cela vous permet de fusionner vos modifications (fichiers de config et autres) et les modifications apportées dans la nouvelle version astucieusement. Subversion directement en ligne de commandes est le moyen le plus confortable.=> le fichier CHANGELOG est à consulter à chaque mise à jour - il tente de vous apporter un certain nombre d'informations sur les changements opérés et que vous devrez donc prendre en compte.
  Attention, ori-oai-workflow devient en 1.6 plus modulaire au niveau des ajouts de supports de nouveaux types de métadonnées, de workflow différents. Aussi la migration de 1.5 vers 1.6 implique une restructuration complète de vos configurations, le svn switch n'est de fait pas d'une grande utilité au niveau de cette migration spéciale.
  => plus d'infos sur cette migration 1.5 -> 1.6 sur cette page dédiée.
  

• résolu les conflits (en vérifiant rapidement vos configurations/personnalisations propres)
• vérifié que votre base SQL tourne

  Les librairies pluto-1.0.1-rc4.jar et portlet-api-1.0.jar qui servent en fait pour l'utilisation de ori-oai-workflow-spring en mode portlet doivent être ajoutées manuellement à vos librairies Tomcat si vous souhaitez faire tourner le module dans un container de portlet. Il faudra également décommenter les déclarations relatives à la servlet "portlet" dans le web.xml (commentées par défaut).
  Si vous souhaitez utiliser CAS, il faut comme indiqué dans les commentaires de main-config.properties configurer le web.xml sauf si vous passez par la facilité du Quick-Install qui fait alors cela pour vous. Si vous utilisez un certificat non reconnu par la JVM (auto-signé pour des tests par exemple), il faut également ne pas oublier d'ajouter un trustStore et de le spécifier dans les paramètres Tomcat lors du lancement de celui-ci :

  CATALINA_OPTS="-Djavax.net.ssl.trustStore=E:/Java/ac-racine-cru.keystore"
  

  => L'utilisation d'un tel certificat est bien évidemment à déconseiller.

Tests

Vous pouvez maintenant passer à la phase de test.