The good, the bad and the ugly - Workflow & State Machine with Drupal 8

Kevin

Kevin


Nov 30th 2018 in code présentation

Je me suis récemment penché sur une problématique souvent évoquée, mais rarement expliquée sur notre blog; les states machines.

Les states machines - ou machines à états en Français - sont des outils de systèmes informatisés. Ils facilitent la visualisation et la résolution de toutes sortes de problèmes.

Ça oscille dans tous les sens, ça fait sérieux !


Cet article va dans un premier temps couvrir une brève introduction au concept de state machine, un chapitre qui se veut accessible à tout un chacun afin d'appréhender d'une manière concrète ce concept si abstrait.
La seconde partie de ce papier sera plus spécifique à Drupal 8. Nous allons y explorer les différents modules permettant la création de State Machine.
Enfin, je termine ce billet par une conclusion plus personnelle sur mon opinion des machines d'états et leurs utilisations dans Drupal.

Happy Reading !

Définitions

Prenons le taureau par les cornes et tentons de comprendre ce qui se cache derrière ce terme si familier et pourtant si étranger.

Une machine à état est un comportement qui spécifie une séquence d'états qu'un objet traverse pendant sa durée de vie, en réponse aux événements et aux réponses qu’un objet donné donne à ces événements.

Bah alors, vous n'avez pas tout compris ?? C'était clair pourtant - Non !?


Sinon pour ceux et celles qui - comme moi - ne se suffisent pas d'une définition alambiquée, une state machine est un outil permettant de garder une trace de l'état de quelque chose. Elle décrit une séquence d'opérations pour fournir certains services.
Il est important de souligner que ledit quelque chose ne peut être que dans un seul état à la fois.

Prenons l'exemple concret d'une porte. Celle-ci peut être ouverte, fermée ou verrouillée. Cependant, vous ne pouvez pas aller directement de verrouillée à ouverte, vous devez d'abord la déverrouiller.
Un schéma valant mille mots, voici sa représentation:

State Machine d'une porte


Dans un contexte Web, c'est un élément fondamental dans l'organisation des structures. Une state machine décrit les séquences d'achat d'un produit dans un e-commerce ou encore le traitement des états de publication des contenus dans un CMS.

Le meilleur exemple dans le domaine du web est le panier d’achats, il a des états bien définis et un ensemble de transitions pour le passage d'un état à l'autre.

Chemin d'achat simplifié d'un e-commerce


Comme détaillé sur l'image ci-dessus, nous pouvons voir un ensemble d'états définis:

  • Vide
  • Rempli
  • Payé
  • Abandonné

Chaque transition est déclenchée par une fonction spécifique, mais il y en a encore plus, certaines transitions peuvent déclencher d'autres événements, voire même avoir des conditions. Voyons à quoi cela ressemble une fois rassemblé:

Okay, that escalated quickly.


Comme vous pouvez le constater, une fois que vous avez inclus des événements (jaune, rouge, vert) et des conditions de garde (bleu), la logique commence à devenir plus complexe, mais vous êtes alors capable de répondre efficacement et élégamment à des besoins simples tout comme des besoins sur mesure et complexes.

Implémentation

Drupal 8 possède pléthores de modules et une Core Initiative qui se targue d'être une solution pour les développeurs pour implémenter des systèmes de state machines dans leurs projets, voyons quels sont-ils et s’ils valent leur pesant d’or:

Vous vous demandez certainement "Quelles sont les différences entre ces quatre modules?”. Minute papillon, comparons déjà ce que chacun d’eux propose.


Workflows & Content Moderation

Né de l'initiative Workflow Initiative créée en 2016, ces deux modules sont complémentaires.
Workflows expose une API, une interface d'administration et une nouvelle entité Workflow tandis que Content Moderation s'occupe d'exposer la brique "Gestion des publications d'un Node" par le biais des API Workfows.

:point_right: Voir la documentation Workflows

:point_right: Voir la documentation Content Moderation


Workflow

Le module Workflow, créé en 2003, expose les mêmes fonctionnalités que les 2 modules Core Workflows & Content Moderation.
L'approche technique est cependant très différente puisqu'elle se repose sur un nouveau type Field et non une Config Entity.

Il est légitime de se demander si ce module doit encore survivre, suite à l'implémentation d'une même feature dans le Core. Je me permets de vous rediriger sur le thread traitant de ce sujet: https://www.drupal.org/project/workflow/issues/2852293

:point_right: Voir la page du projet


State Machine

Contrairement aux 3 précédents modules que sont Workflow, Workflows & Content Moderation, où tout peut être réalisé en quelques clics grâce à une interface d'administration, State Machine nécessite la création d'un module personnalisé.
L'approche est foncièrement différente et bien plus orientée Developer, contrairement aux solutions précédentes orientées Site Builder.

Le fonctionnement du module est assez simple dans sa conception:

  • Les Workflows doivent être définis dans un module personnalisé à l'aide d'un fichier YAML.
  • Le module fournit un nouveau type de champ: State.
  • Chaque fois qu'un champ State est modifié, un événement est propagé. Nous pouvons ensuite agir en fonction de ces événements et déclencher autant d'actions que nécessaire.

:point_right: Voir la page du projet

Quelle solution choisir entre Workflows/Content Moderation et State Machine ?

Mon coeur penche en la faveur du module State Machine.
Principalement orientée Developer, les fichiers de définitions des Workflows sont directement présents dans le repository et ne nécessitent pas un stockage d'une entité en base de données.
Facilement compréhensible, rien n'est caché derrière une Black Box et, d'expérience, le tout est plus simple à maintenir et à tester au travers de tests unitaires.
De plus, la propagation des événements via le composant EventDispatcher de Symfony permet une souplesse à toute épreuve. Alors que Workflows et Content Moderation se contente d'une intégration en Hook.

De mon point de vue, chaque solution correspond à un besoin particulier: Content Moderation (et le module Workflows) répond très rapidement au besoin d’un — et d’un seul — Workflow de publication standard sur le contenu (uniquement fonctionnel avec les Nodes) d’un site Drupal 8, tandis que State Machine peut répondre tout aussi rapidement à des besoins plus complexes (plusieurs Workflow sur le même contenu, Workflow sur n'importe quelle entité ...).

Pour leur support et leur maintenance prévisible, Content Moderation en tant que module Core de Drupal 8 présente un avantage indéniable. Mais le module de State Machine n'est pas en reste, il s'agit de l'un des principaux composants de Drupal Commerce 2.x. Je peux vous garantir que ces deux solutions vont coexister dans le paysage de l'écosystème Drupal pendant un certain temps.


Quoi qu’il en soit, n’hésitez pas à nous contacter pour vous conseiller sur la meilleure stratégie à adopter en relation avec votre projet.


Sources

Pour les plus curieux d'entre vous, voici quelques sources d'informations complémentaires ayant inspiré la création de cet article.

Patrick Kenny (30 Septembre, 2017). Workflow, Workflows, Workspace, and State Machine - what is the difference?
Voir sur https://drupal.stackexchange.com/questions/247098.../...

Ontologia (01 Janvier 2013). Pourquoi les développeurs n'utilisent pas plus de machines à état ?
Voir sur https://linuxfr.org/news/pourqu.../...

Kim Pepper (29 Novembre, 2017). Workflows: A new tool in the toolbox.
Voir sur https://previousnext.com.au/blog/workflows.../...

Flocon de toile (30 Novembre, 2017). Set up workflows with State machine on Drupal 8.
Voir sur https://flocondetoile.fr/blog/set-workfl../..

Drupal Commerce. State Machine.
Voir sur https://docs.drupalcommerce.org/commerc../...

Symfony. The Workflow Component.
Voir sur https://symfony.com/doc/cu../...

João Moura (29 Mars 2018). State Machine in Elixir with Machinery.
Voir sur https://medium.com/@joao../...