Spécifications

Workflow (OSWorkflow)

Un Workflow est un concept large. Même si l'on peut être d'accord sur le concept, il peut être décrit de différentes manières, sous différents points de vue (états/transitions, ...) et avec des vocabulaires différents.

Ce paragraphe a donc pour objectif de donner une "vision ORI-OAI" de ce qu'est un workflow. Concrètement, la spécification d'un workflow ORI-OAI correspond au workflow tel qu'il est présenté dans OSWorkflow mais en utilisant en plus des beans spring ORI-OAI comme méthodes à appeler lors des conditions et fonctions du workflow.

Workflow - Diagramme d'état transtions

Un Workflow est défini par son diagramme d'états/transtions. OSWorkflow permet de définir des Workflows par des fichiers XML. Ainsi on définit un Workflow pour la gestion des fiches des ressources pédagogiques, un autre pour la gestion des thèses, etc.

Une fois un Workflow défini, les applications tierces à OSWorkflow peuvent instancier des instances de workflows pour chacune des ressources souhaitées et les manipuler.

Ici est défini un workflow très simple à 2 états : private et publish. On peut passer d'un état à un autre via une transition possible si la condition est respectée. Lors de cette transition, le workflow peut demander à appeler des fonctions.

Dans Ori-Oai-Workflow, un Workflow correspond très concrètement à un fichier de configuration d'un workflow OsWorkflow (implémentant le diagramme ci-dessus par exemple).

Eléments constitutifs d'un Workflow

instance de workflow

Dans Ori-Oai-Workflow, à une entrée XML (~ fiche de Métadonnée XML) correspond une instance de workflow d'un Workflow (diagramme états/transitions) donné. L'instance de workflow permet la gestion du "cycle de vie" de l'entrée XML. L'instance de workflow garde en mémoire les transitions/états passés et présent de l'entrée XML. Elle est consultée pour récupérer des informations comme les transitions disponibles, l'état actuel, les permissions. Elle est aussi appelée pour demander à effectuer les transitions.
Elle correspond très concrètement à "une" entrée dans la base de données.

Rôles

Les utilisateurs ont des rôles sur des ressources. Typiquement, un utilisateur aura le rôle de "owner" sur les ressources qu'il a lui-même créées. Les rôles peuvent intervenir dans les conditions : "à condition que l'utilisateur courant soit owner". Ces rôles sont définis par des chaines de caractères (depuis ori-oai-1.6) qui représentent dans le workflow les identifications des rôles.

Permissions

Des permissions peuvent êtres positionnées en fonction de l'état (voir des états) dans lequel se trouve l'instance de workflow. Ces permissions sont définies par des chaines de caractères (depuis ori-oai-1.6) qui représentent dans le workflow les identifications des permissions.

Etats-Transitions

Le Workflow est défini par un diagramme d'états/transitions. Une instance de workflow est caractérisée par l'état (voir les états dans le cas de split) dans lequel elle se trouve. Depuis un état, il est possible d'effectuer ou non des transitions. Ces transitions ammènent l'instance dans un autre état.
Dans OSWorkflow, on parle de "step" (pour état [étape]) et de "action" (pour transition).

fonctions - conditions

Les fonctions, tout comme les conditions, peuvent être des java beanshell (scripts en java) ou des classes (méthodes de classes) ou encore, et c'est ce que le déployeur/dévelopeur utilisera certainement la plupart du temps, des beans Spring. Ils peuvent admettre des arguments.
Une fonction permet de lancer un script/méthode après ou avant une transition. On peut par exemple y implémenter l'envoi de mail au owner de l'instance du workflow, une demande d'indexation au module Ori-Oai-Indexing ou plus usuellement encore, le positionnement de permissions et/ou de rôles.
Une condition permet de conditionner une transition via un script/méthode. On peut par exemple conditionner une transition sur l'appartenance de l'utilisateur à un rôle donné.

Mise en oeuvre

Comme dit ci-avant, on utilise OSWorkflow comme un sous-module indépendant des autres composants. Aussi, on propose par défaut plusieurs Workflows définis par des fichiers XML. Dans ces Workflows sont spécifiés les permissions, rôles utilisés. Libre aux utilisateurs/déployeurs de ORI de configurer/développer de nouveaux Workflows en prenant comme exemple ceux donnés par défaut.

OSWorkflow est dirigé via Spring et les beans Spring fournis en standard avec OSWorkflow. La persistance de OSWorkflow dans Hibernate est configurée via la configuration des beans Spring OSWorkflow également. Les fonctions/conditions définis dans les workflow peuvent être des beans définis via les fichiers de config spring. Voir ce lien.. Cela nous permet d'intégrer parfaitement OsWorkflow dans l'application principale tout en conservant toute la souplesse d'OsWorkflow. Il est ainsi possible aux utilisateurs de développer et intégrer leurs propres fonctions et conditions dans les workflows OsWorkflow (et des les partager avec la communauté ). C'est donc un excellent point d'entrée pour un développeur désirant étendre les possibilités/fonctionnalités d'Ori-Oai-Workflow.

Configurations

Grâce à Spring mais aussi à OsWorkflow, l'application est souple car paramétrable à différents niveaux. Du même coup, configurer Ori-Oai-Workflow de manière avancée demande d'éditer un certain nombre de fichiers. Les fichiers à configurer/modifier les plus importants (en terme fonctionnel) sont les fichiers de configuration spring, mais aussi les fichiers permettant d'implémenter un workflow OsWorkflow.

De plus, le module quick-install permet de configurer de façon très fine les workflows utilisés et leurs acteurs , sans avoir besoin de modfier un seul fichier.