Chez Atol CD, nous avons souvent recours à l’ajout de comportements spécifiques (Policy / Behaviour) lorsque des documents sont créés, mis à jour ou supprimés dans Alfresco. C’est un des types de point d’extension qui est disponible dans la caisse à outils du développeur Alfresco :
 https://docs.alfresco.com/6.0/references/dev-extension-points-behaviors.html Nous l’utilisons notamment lorsqu’il est nécessaire de créer des plans de classement à la volée, car il faut s’assurer que le chemin dans lequel le document doit être déposé existe, et au besoin le créer avant de pouvoir déplacer le document à cet emplacement. Nous en profitons aussi généralement pour enrichir ces dossiers de classement avec des métadonnées, tags ou catégories ainsi que des permissions particulières.Habituellement, nous proposons un plan de classement lorsqu’il faut stocker des documents de référence, notamment lorsqu’il s’agit de documents numérisés qui soient conformes au format papier : https://blog.atolcd.com/atol-motion-labs-14-capture-documentaire/
Et justement dans ce cas là, il ne faut pas que les utilisateurs ni mêmes les administrateurs de sites (qui ont tous les droits sur leur espace documentaire) ne puissent ajouter de nouvelles versions à ces documents (qui viendraient altérer l’original) et de surcroît les supprimer. Ces mécanismes ne devant être déclenchés que respectivement par le numériseur (en cas de problème de lisibilité) et l’archiveur au travers d’un protocole défini conjointement ou exceptionnellement par un administrateur technique. Or les permissions standard Alfresco ne permettent pas de contraindre ce type d’action et nous avons eu recourt à des comportements spécifiques dans Alfresco basés sur des événements prédéfinis, mais nous avons eu des surprises ! C’est dans le cadre de ces travaux et sous certaines conditions que nous sommes tombés sur des bugs de la solution Alfresco. Nous avons alors cherché à en comprendre la cause en inspectant le code source des composants impliqués et en analysant l’origine du dysfonctionnement de façon à d’abord pouvoir le contourner pour respecter les délais de livraison. Puis dans un deuxième temps, nous avons décidé de contribuer en proposant des correctifs. Cette étape n’a pas toujours été simple avec Alfresco mais a été grandement facilitée avec la transition de leur base de code de Subversion vers Git et GitHub : https://community.alfresco.com/community/ecm/blog/2018/01/12/alfresco-share-surf-and-aikau-projects-on-github
Bien sûr, il s’agissait également de réaliser les tests unitaires de ces comportements pour garantir la pérennité de ces cas d’usages et éviter les régressions. Mais venons-en aux faits…

Alfresco possède un mécanisme de désactivation temporaire des policies (via le BehaviourFilter), typiquement dans le cas d’un traitement exceptionnel. Celui-ci permet d’ignorer un traitement dans le contexte d’exécution d’un Thread Java. On utilise le mécanisme de try-catch-finally pour réactiver le traitement par défaut à l’issue. Il est possible de neutraliser un comportement de manière globale ou sur un nœud donné (document ou répertoire) et pour un type ou aspect donné (au sens modélisation Alfresco). Or le modèle de données Alfresco supporte l’héritage et on est en droit d’attendre que la désactivation d’un comportement sur un type de document par exemple inhibe également le traitement sur les sous-types (idem avec les aspects et leurs sous-aspects). C’était bien le cas lors d’une désactivation globale (les tests de MNT-13836 en attestent) mais pas lorsqu’un nœud était spécifié via sa référence. C’est donc l’objet de la correction apportée : https://issues.alfresco.com/jira/browse/ALF-21992
Dès lors, pour empêcher la suppression d’un nœud par défaut, nous nous contentons d’ajouter une policy qui déclenche une exception Java et ainsi annule (i.e. rollback) la transaction courante. Et pour inhiber ce comportement, il suffit de désactiver ce comportement !

De manière assez similaire il n’était pas possible de filtrer (i.e. activer ou désactiver) les comportements spécifiques relatifs à la gestion des versions de documents, au travers des événements de VersionServicePolicies, que de manière globale, sans avoir la possibilité de préciser l’identifiant du document sur lequel la spécificité devait s’appliquer : https://issues.alfresco.com/jira/browse/ALF-22006

Enfin la dernière correction touche le Core d’Alfresco et permet de garantir l’ordre d’exécution des traitements spécifiques au moment du commit de la transaction. En effet, il est possible de déclarer des actions spécifiques qui s’exécuteront une fois le traitement principal terminé et juste avant la validation de la transaction en base de données. Ce mécanisme est classiquement utilisé pour la vérification d’intégrité du modèle Alfresco et historiquement pour permettre l’indexation full-text des documents (ce mécanisme basé sur Lucene permettant la synchronisation des index a été déprécié depuis, remplacé par un traitement récurrent toutes les 15 secondes avec Solr permettant seulement la cohérence à terme, dite – eventual consistency -). Pour les policies, il existe une mesure qui permet de préciser que l’action ne s’exécute pas au moment où l’événement se produit mais seulement une fois que le traitement principal est terminé, ce qui permet de s’assurer que toutes les modifications ont été faites au préalable sur les nœuds. Mais dans le cas de plusieurs policies de ce type, les actions à exécuter ne suivaient pas l’ordre d’occurrence des événements, ce qui pouvait entraîner des bugs aléatoires et qui a été corrigé : https://issues.alfresco.com/jira/browse/ALF-22007

Ces contributions sont déjà disponibles dans la toute dernière version Alfresco Community dénommée 201808 EA https://community.alfresco.com/docs/DOC-8006-alfresco-community-edition-201808-ga-release-notes ; première version packagée de la branche 6.1 et selon le cycle des versions définies par l’éditeur, elles devraient suivre dans les versions Entreprise : https://community.alfresco.com/docs/DOC-7996-alfresco-community-edition-61

Tweetez
Partagez
Partagez
0 Partages