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.

...

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.

  Info

  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 : Code Block default-storage_engine = innodb Pour une version plus anciennes, l'option est de la forme : Code Block default-table-type = innodb Commandes pour vérifier en ligne de commande (client mysql) le storage utilisé sur une table de votre base : Code Block 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

...

_

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, ...

...

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,
• 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 \\ {span:class=command}svn switch {span}pour passer

  de
  

  Note
  Wiki Markup

  Span
  class command
  svn switch

  pour 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

  |Migration 1

  .

  5 vers 1.6]. \\

  
  

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

  Note

  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 : Code Block 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.