Skip to end of metadata
Go to start of metadata

You are viewing an old version of this page. View the current version.

Compare with Current View Page History

« Previous Version 14 Current »

Navigation dans les fichiers de configuration

Icon

Avant de procéder à la configuration avancée, il est conseillé de consulter le document "Navigation dans les fichiers" pour mieux comprendre la structure des différents fichiers.

Vous trouverez dans cette partie toutes les possibilités de configuration suivantes:

Si vous utilisez le module quick-install (fortement conseillé) , il ne vous sera pas nécessaire de modifer ces fichiers . Il  sera cependant utile de connaitre leur utilité si vous voulez adapter ou ajouter un workflow.

Configuration générale du module

La configuration générale du module se trouve sous conf/properties. Cette configuration s'applique à tous les workflows.

default-permissions-roles.xml

  • Ce fichier  permet de configurer les permissions et rôles pouvant être utilisés par l'application (IHM)  ou par tous les workflows. Les "recipients" utilisés doivent être déclarés dans groups.xml
  • par défaut, assigne le rôle d'administrateur de chaque workflow aux administrateurs de l'application

groups.xml

  • Permet de configurer le nom et la définition des groupes disponibles dans l'application.
  • par défaut,  définit le groupe des administrateurs de l'application ("admins")

namespaces.xml

  • Définit les espaces de noms utilisés par plusieurs type de métadonnées
  • Par défaut, contient le namespace "dc" utilisé par les formats Dublin Core et TEF (thèses)

metadataslist.xml

  • Ce fichier permet de paramétrer les catégories de fiches qui seront affichées aux utilisateurs applicatifs déclarés dans groups.xml. Cela permet de mettre dans un même ensemble des fiches provenant de différents workflows ayant des états différents, sur lesquelles l'utilisateur a des rôles différents.
  • Par défaut, ce fichier est vide

Authentification / Autorisation avec Shibboleth


Depuis la version 1.4.0 ori-oai-workflow peut utiliser Shibboleth à la fois pour l'authentification et l'autorisation. LDAP et CAS ne sont alors plus nécessaires et il est possible de partager une même instance d'ori-oai-workflow entre plusieurs établissements.

Pour que les mécanismes shibboleth soient pris en compte au niveau de ori-oai-workflow, ce dernier attend de pouvoir interpréter directement les attributs Shibboleth positionnés dans les paramètres HTTP de la requête cliente. On peut pour ce faire utiliser directement le mod_shib d'apache, dans lequel on requerra une authentification Shibboleth sur l'ensemble de l'applicatif.

Voici un exemple d'une telle configuration (le mod_shib et proxy_ajp (ProxyPass) sont ici utilisés et donc chargés par ailleurs :

Reste ensuite à configurer l'interprétation des attributs Shibboleth au niveau ori-oai-workflow : on va pouvoir définir d'une part l'attribut Shibboleth qui va correspondre à l'identifiant d'un individu dans ori-oai-workflow (dans conf/properties/spring/acegi/acegi-authentication-shib.xml ) , puis d'autres part les règles qui vont permettre de définir à quel(s) groupe(s) appartient l'individu connecté; ces règles, à paramétrer par l'exploitant, devront s'appuyer sur les attributs shibboleth disponibles (dans groups.xml, cf plus haut).

conf/properties/spring/acegi/acegi-authentication-shib.xml

groups.xml

Les règles de constitution ("values") doivent correspondent à des expressions Java renvoyant un boolean (true, false). Si l'expression interprétée renvoie true, alors on affecte à l'individu connecté le groupe donné en clé. groupsMap est le nom de la variable définissant une table de hashage regroupant l'ensemble des attributs Shbboleth disponibles : nom/valeur.

Voici un exemple d'école avec le workflow DC "easy" :

Limitations: de par le mode de fonctionnement de shibboleth, il n'est pas possible de retrouver dynamiquement tous les individus d'un groupe donné. On ne pourra donc pas utiliser dans un workflow l'envoi de mails à l'ensemble des individus d'un groupe. On contournera ce problème en définissant directement les individus un à un comme destinataires des mails, ou mieux encore en définissant en amont une mailing-list permettant cet envoi de mails à un ensemble prédéfini d'individus.

Conditions et fonctions OsWorkflow

OsWorkflow


La configuration de workflow(s) OsWorkflow est un élément capital dans le déploiement d'un Ori-Oai-Workflow. C'est le workflow qui dirige le module. Dans Ori-Oai-Workflow, OsWorkflow n'a pas été modifié ou personnalisé, les fichiers de configuration des workflows sont donc des fichiers spécifiques OsWorkflow. Ainsi vous pouvez tout à fait vous référer à la documentation d'OsWorkflow si vous en sentez le besoin de même que pour tous les fichiers de configuration de type Spring, vous pouvez vous référer à la documentation de Spring pour connaitre la syntaxe utilisée.

Dans un premier temps, il est important de comprendre ce qu'est un workflow, revoyez dans la section "Specifications" la partie sur le Workflow si ce n'est pas clair.

Dans un second temps, il vous faut connaître les possibilités en matière de condition et fonctions et arriver à penser vos cas d'utilisations du module en terme de Workflow. Pour ce faire, rien ne vaut la présentation d'un exemple exhaustif que vous devrez mettre en relation avec le document fonctionnel sur les cas d'utilisations (document rédigé par Rosa María Gómez de Regil et Romuald Lorthioir).

On notera que ce graphe représentant le workflow des documents que l'on veut indexer n'a pas grand chose de spécifique à OsWorkflow ou à ORI-OAI. Il faut également se rappeler que les rôles, les permissions (dont les permissions d'utiliser tel ou tel formulaire) sont des éléments configurables comme  on le verre ci-dessous.

Une fois ce graphe conçu, la plus grosse partie du travail est faite : il reste à concevoir le XML implémentant ce diagramme en "langage" OsWorkflow, même si il en résulte un XML qui peut être conséquent, le langage XML d'OsWorkflow n'est pas complexe.

Notes sur les conditions et fonctions disponibles actuellement et en natif dans Ori-Oai-Workflow :

spring/spring-osworkflow-helpers.xml

  • C'est ici que sont déclarés les beans spring utilisés dans les workflows OsWorkflow pour implémenter des conditions et des fonctions OsWorkflow.
  • L'administrateur/développeur voulant rajouter des fonctionnalités dans son Workflkow liées à son contexte de déploiement d'Ori pourra de la même façon qu'ici ajouter ses propres beans spring qu'il utilisera dans la configuration des workflows d'OsWorkflow. Le mieux sera de déclarer ses beans dans un fichier dédié à cela (vide par défaut) : conf/properties/spring/spring-custom.xml


Conditions:
HasPermission

Condition sur le fait que l'utilisateur courant a une permission donnée.

HasRole

Condition sur le fait que l'utilisateur courant a un rôle donné.

VerifyXPathes

Vérifie que la résolution de chaque XPath donné en paramètre correspond à au moins un noeud à chaque fois. Place un message dans le listing d'informations de l'instance/fiche considéré si ce n'est pas le cas.

Exécute le schématron (transformation XSL/XSLT via la XSL résultant de la "compilation XSL" d'un schématron) sur la fiche XML pour vérifier qu'il n'y a pas d'erreurs (règles schématron). Place des messages d'erreurs en conséquence dans le listing d'informations de l'instance/fiche considéré.

Fonctions:
AddPermission

Ajoute une permission à un rôle sur l'instance courante.

AddRole

Ajoute un rôle à un utilisateur ou groupe ou utilisateur courant sur l'instance courante.
Un XPath et une valeur attendue sur le xpath donnée sont des paramètres optionnelles à cette fonction. Ils permettent de conditionner ce positionnement de rôle selon la présence ou non d'une valeur à un xpath donné. Par exemple cela permet de donner le rôle de modérateur au groupe de professeurs de mathématiques si la discipline dans la fiche LOM a été positionnée à Mathématiques.

DeleteIndex

Demande à un ORI-OAI-Indexing de supprimer l'index courant de l'instance courante (si elle a été indexée préalablement).

DeletePermission

Supprime une permission à un rôle sur l'instance courante.

DeleteRole

Supprime un rôle à un utilisateur ou groupe ou utilisateur courant sur l'instance courante.

RevertXml

Restore une version de la fiche d'un ancien état (il faut pour cela que dans cet ancien état, un SaveXmlHistory ait été fait).

SaveOrUpdateIndex

Demande à un ORI-OAI-Indexing d'indexer ou de réindexer la fiche de l'instance courante.

Icon

Depuis la 1.1.* cette fonction n'appelle pas/plus la fonction SaveXmlHistory : les 2 fonctions sont dissociées et indépendantes.
Cette fonction DOIT obligatoirement être configurée comme étant une post-function dans OsWorkflow.

SaveXmlHistory

Sauve le XML actuel comme un historique (archive) de l'état initial à la transition.

Icon

Cette fonction DOIT obligatoirement être configurée comme étant une post-function dans OsWorkflow.

SendEmail

Envoie des emails aux utilisateurs d'un rôle donné sur l'instance et/ou à un mail donné "en dur" dans le workflow.
Cette fonction est donc capable de récupérer tous les emails des utilisateurs qui ont un rôle via un positionnement direct sur l'instance, via un positionnement au travers d'un groupe, etc. ... cela signifie que le nombre d'emails peut suivant les configurations être conséquent. La récolte des emails peut actuellement prendre un certain temps si la liste est longue (multiples requêtes ldap). [l'envoi des emails se fait toutefois dans des threads séparés). Nous recommandans la mesure du possible d'utiliser une liste de diffusion (mail "en dur") pour l'envoi de mails à tout un groupe donné et bien défini ...

SetInstanceIdentity et SetEntryIdentity

Place des identifiants (propre à l'instance/fiche ou à l'entrée/entité considéré) au niveau d'un xpath donné.

xslTransform

Appelle une transformations XSL sur la fiche XML de l'instance. Notez que dans le workflow_easy.xml donné par défaut, xslTransform est utilisé en utilisant par exemple properties/xsl/osfunctions/lomSetLifecycleAuthor.xsl : cette transformation fait appel directement à de la logique métier via une expression du type select="document('#{domainService.getCurrentUserName()}')"

Nouveautés en 1.7.0

Icon
 

createOrUpdateScheduledAction

Crée une tâche programmée qui exécutera une action OsWorkflow donnée soit :

  • à une date donnée
  • à chaque 'passage' du scheduler jusqu'à ce qu'une condition sur l'instance de workflow soit vérifiée

invokeWSOperation

Déclenche l'appel à une méthode d'un service distant (HAL, STAR ou autre) configurée dans le fichier remote-services-configs.xml. Plus d'informations ici.

hasRemoteStatus

Condition sur l'état de la fiche au niveau d'un service distant (HAL, STAR ou autre)

setRemoteStatus

Dans le cas d'un workflow interagissant avec un service distant, l'application ORI-OAI-workflow garde une image locale de l'état de la fiche au niveau de ce service. La fonction setRemoteStatus permet de forcer le positionnement de cet état local à une valeur donnée.

Notez que l'ordre des fonctions dans le fichier de config n'est pas annodin.
Un certain nombre des fonctions présentées ci-dessus vont fonctionner dans un contexte transactionnel .... mais pas toutes ....
Les fonctions qui tournent dans un contexte transactionnel annuleront leurs effets automatiquement si une des fonctions provoquait une erreur innatendue.
Dans ce contexte, et par rapport au listing ci-dessus, il est recommandé de lancer

  • en tout dernier l'envoi d'emails (notez que contrairement aux autres fonctions, si l'envoi d'email échoue, rien n'est annulé pour autant),
  • en avant dernier l'appel à des WebServices et donc à ori-oai-indexing par exemple,

Notez enfin que vous pouvez vous appuyer au mieux sur les workflows livrés (des plus simples default_dc_very_easy aux plus complets default_lom_complex)  qui vous fournissent ainsi des exemples significatifs.

Configuration des workflows

Cette configuration est propre à chaque workflow; elle se trouve sous  conf/properties/workflows/[nom_workflow]

Catégories et types de métadonnées

addonContext.xml

  • Il permet de paramétrer les types de fiches que peut ajouter un utilisateur. Notez toute fois qu'un utilisateur pourra effectivement ajouter une fiche d'un type donné si les conditions d'ajout déclarées dans le workflow correspondant sont vérifiées (conditions sur initial-action). Un type de fiche Ori-Oai-Workflow est ainsi déterminé par un workflow OsWorkflow (identifié par workflowName), un nom de schéma, un xsl (permettant à partir d'un xml de produire un html), un fichier xml de défaut qui sera donné comme fiche vide à la création d'une nouvelle fiche (sauf dans le cas où l'utilisateur utilise des patrons de fiches).
  • C'est ici également que l'on configure les XForms à mettre en relation avec les fiches. On a une liste de XForms par type de contenu. Pour chaque XForms est donné un identifiant (réutilisé dans le positionnement des permissions) et une url correspondant à l'adresse du Serveur Orbeon présentant le XForms voulu (et c'est ici par exemple que vous pourrez ajouer un pointeur sur vos formulaires personnalisés ou vous permettant de supporter d'autres formats de MétaDonnées).
  • Ce fichier permet aussi de paramétrer les catégories de fiches qui seront affichées à l'utilisateur. Cela permet de mettre dans un même ensemble des fiches ayant des états différents, sur lesquelles l'utilisateurs a des rôles différents. Ce fichier est donc à modifier en fonction du workflow (états, permissions et rôles)  et en fonction de ses besoins propres.

Acegi Security : roles et permissions


Pour infos, les configurations possibles ici proviennent de l'implémentation spécifique de la politique de sécurité de Ori-Oai-Workflow.

default-permissions-roles.xml

  • Ce fichier  permet de configurer les permissions et rôles par défaut dans le workflow. Les masks utilisés doivent être déclarés dans groups.xml

groups.xml

  • Permet de configurer le nom ("key") et la définition ("value") des groupes disponibles dans le workflow.
  • Les noms des groupes sont utilisés dans les autres fichiers de configuration du workflow
  • Un groupe peut-être défini de trois façons, selon la syntaxe utilisée:
Icon

lire ci-dessous le cas particulier "Authentification / Autorisation avec Shibboleth"

Interactions avec un service distant (HAL, STAR, ...)

Nouveauté en 1.7.0

Icon
 

remote-services-configs.xml

Permet de configurer les méthodes (fonctions) de services distants à appeler dans le workflow. Plus d'informations ici

Le workflow

workflows.xml

  • C'est le point d'entrée du workflow

workflow_[type].xml

  • C'est le workflow en lui_même, c'est à dire la liste des états ("step"),  des actions utilisateur ("action") pouvant être faites sous certaines conditions ("condition" ) : les fonctions OsWorkflow ("function") exécutées alors et l'état résultant  ("result") .

Exemple du workflow simple DC

Vous noterez que les fichiers workflows sont à mettre en relation avec la configuration des rôles et permissions ( default-permissions-roles.xml, groups.xml)

Les paramètres entre crochets ( [WORKFLOW_DC-E_TITLE] , ...) seront renseignés (via le quick-install ou "à la main") avant le déploiement.

Ce workflow permet à toute personne autorisée (droit "DCE_CREATE") d'initier une fiche de référencement ("properties/workflows/default_dc_easy/xml/dc-blank.xml") qui sera ensuite complétée et publiée par un modérateur ("DCE_MODERATOR").

Le workflow "default_dc-easy" est utilisé pour le Dublin Core.Un unique formulaire est configuré pour être utilsiable si l'utilisateur a la permission DCE_CREATE sur la fiche considéree (conf/properties/workflows/default_dc_easy/addonContext.xml)

Voici ce que donne la version XML  proposée par défaut (conf/properties/workflows/default_dc-easy/workflow_easy.xml)

Exemple du workflow complet LOM

Ce workflow permet aux validateurs (pédagogique, technique, juridique) de compléter la fiche auteur avant sa publication par le documentaliste. Les validateurs technique et juridique peuvent compléter la fiche de façon simultanée. Un modérateur peut suppléer les validateurs et le documentaliste tout au long du flux de production de la fiche.

Chaque contributeur utilise un formulaire différent :

  • l'auteur Schemas_WF_RPN_complex.pdf(droit "LOMC_USE_CREATE_FORM") utilise un formulaire allégé ([WORKFLOW_PEDAGO_FORM_AUTHOR])
  • les validateurs utilisent un formulaire adapté 
  • le documentaliste Schemas_WF_RPN_complex.pdf(droit "LOMC_USE_DOC_FORM") utilise le formulaire [WORKFLOW_PEDAGO_FORM_DOC]
  • le modérateur  Schemas_WF_RPN_complex.pdf(droit "LOMC_USE_LOM_FORM") utilise le formulaire complet  [WORKFLOW_PEDAGO_FORM_FULL]

Le fichier conf/properties/workflows/default_dc_easy/addonContext.xml

Voici ce que donne la version XML  proposée par défaut (conf/properties/workflows/default_lom_complex/workflow_complex.xml)

  • No labels