Magnolia CMS Workflow explained: the Big Picture

Magnolia CMS combines 3 frameworks together to support workflows in its recent version: JBPM, Magnolia Task+Pulse and Magnolia itself (command, actions, dialogs..).
You can find more infos on those topics on the official Magnolia Workflow documentation page.

But in short words, how does it work?

Magnolia CMS editors (kind and polite people, I guarantee..) usually open their browser and produce some content. Once ready, they need to ask for approval to their boss in order to see content going live.

Editors starts the workflow from the “pages” app:

workflow-06

They can add a comment or even schedule the content publication:

workflow-07

Once saved, the workflow is initiated: (usually) other users, so called “publishers”, are notified by The Pulse, the internal communication BUS offered by Magnolia: so, they need to “claim” this Task:

workflow-10

Once they are sure that everything is ok, they approve editor’s intention:

workflow-11

And now the content goes live:

workflow-12

This is the “direct lane”, where there is no bounces between publishers and editors (yes, a publication workflow can last forever). For simplicity, I have omitted other scenarios.
But now, what happen behind the scenes? How the Magnolia CMS modules interacts each other to orchestrate the activation workflow?

This is the Magnolia CMS Workflow Big Picture:

Magnolia CMS Workflow - The Big Picture
Magnolia CMS Workflow – The Big Picture

And here the details:

  1. Editors launch an action. This action, available in “pages” app, extends another action, available inside the workflow module for consistency. Activate actions, in few words, launches the activation command. In Community Edition this command directly activate the content, but in Enterprise Edition is overwritten by workflow module: it calls..another command (acting as delegate), the “workflow-activate” one. This command has 2 main goals:
    1. Version the content, to avoid to activate further content changes
    2. Launch the activation flow against the versioned content (and with user parameters as “storage” of flow data)
  2. The reviewForPublication workflow now runs on JBPM Workflow Engine and stops once a HumanTask is required
  3. Publishers (any!) now claims the Task. Now only he / she can approve / reject the activation.
  4. Finally content is activated according to Personalization way-of-doing: the Personalization module has its rules and once installed, injects itself inside the Workflow module

Some pictures:

Activation action: see how it extends the workflow one
Activation action: see how it extends the workflow one
This is how actions work. A simple delegate command, that call another command.
This is how actions work. A simple delegate command, that call another command.
Activation command: it is a chain, where first node is versioned than launched within the workflow
Activation command: it is a chain, where first node is versioned than launched within the workflow
Here you find the workflow definition (JBPM XML)
Here you find the workflow definition (JBPM XML)
This is the HumanTask, the bridge between JBPM and Magnolia
This is the HumanTask, the bridge between JBPM and Magnolia

Latest articles

Written by:

Be First to Comment

Lascia una risposta

L'indirizzo email non verrĂ  pubblicato. I campi obbligatori sono contrassegnati *


6 × otto =