Operations

Au sein de FlowerDocs, on appelle opération une action sur un composant au sein de FlowerDocs Core. Les OperationHandlers réagissent à l’exécution de ces opérations.


L’exécution d’une opération peut être découpée en 4 phases :

1 . Les OperationHandler enregistrés dans la phase de pré-traitement sont appelés

2 . L’Operation est executée

3 . Les OperationHandler enregistrés dans la phase de post-traitement sont appelés

4 . Les OperationHook asynchrones sont exécutés

Si une erreur intervient lors du pré-traitement comme la levée d’une exception, le déroulement des étapes est bloqué.


Consulter la Javadoc pour plus de précisions sur cette API

Pour réagir à l’exécution d’une opération au sein d’un OperationHandler, il est nécessaire de s’y abonner.

Un abonnement permet de définir sur quelles opérations réagir en permettant de définir :

  • la phase d’exécution : détermine si l’OperationHandler doit être exécuté avant ou après l’opération (BEFORE ou AFTER)
  • l’action : CREATE, UPDATE, SEARCH, ADD_CONTENT ou DELETE_CONTENT
  • le type d’objet : DOCUMENT, FOLDER, TASK ou VIRTUAL_FOLDER
  • le handler à exécuter : le nom complet de la classe de l’OperationHandler ou son URL

En outre, l’abonnement détermine si la réaction à l’exécution d’une opération est synchrone ou asynchrone (exécutée dans un autre thread pour ne pas bloquer l’application).


D’autres paramètres peuvent être définis sur l’abonnement à une opération :

  • enabled : détermine si l’abonnement est actif ou désactivé
  • StopOnException : arrête le déroulé de l’opération si une erreur est déclenchée (seulement valable pour la phase BEFORE)
  • RegistrationOrder : ordonne les abonnements à une même opération

Un OperationHandler permet de réagir à l’exécution d’une opération. Pour y réagir dans son contexte, un OperationContext lui est fourni en entrée.

Un OperationHandler est un fragment de code présent au sein de la JVM [FlowerDocs Core]. Il est donc, soit fourni nativement par FlowerDocs, soit ajouté dans le classpath de l’application (on-premise seulement).


Pour développer votre premier OperationHandler, consultez la documentation.

Un OperationHook est un OperationHandler exposé en tant que web service REST.

Il permet de réagir à l’exécution d’une opération de manière isolée dans sa propre JVM.


Pour développer votre premier OperationHook, consultez la documentation.

Les opérations effectuées par les utilisateurs peuvent être stockées sous la forme de faits. Un fait historise une opération effectuée en conservant les informations de l’opération :

  • un identifiant unique
  • l’identifiant de l’objet concerné
  • l’identifiant de l’utilisateur ayant exécuté l’opération
  • l’action effectuée
  • la date d’exécution (timestamp)


Par défaut, les opérations de création, mise à jour et suppression sont historisées pour tous les composants. Pour les tâches, l’application d’une réponse et l’assignation à un utilisateur sont également historisées par défaut. Les opérations pouvant être historisées sont listées ci-dessous :

Action Clé Catégories de composant Historisée par défaut
Création create Toutes Oui
Lecture read Toutes Non
Mise à jour update Toutes Oui
Suppression delete Toutes Oui
Réponse answer Tâche Non
Assignation assign Tâche Non


Afin de modifier les opérations historisées, le fichier core.properties doit être modifié en s’appuyant sur la configuration par défaut :

fact.registrations.document=create,update,delete
fact.registrations.folder=create,update,delete
fact.registrations.virtual.folder=create,update,delete
fact.registrations.task=create,update,delete,answer,assign