Page History

...

• workflow process defined as bpmn 2.0 (Business Process Model and Notation) file
• each process is registered by name at startup and made available to the workflow engine, see /modules/workflow/workflows
• each step in the workflow is a workitem defined in a wid (work item definition, a jBPM specific file), e.g. MgnlDefinitions.wid
• WorkItemHandlerDefinitionRegistry scans the config repo at startup and registers all handlers each work item is mapped to a work item handler. Handlers are under workItemHandlers nodes, eg. /modules/workflow-jbpm/workItemHandlers and maps workitems with their respective handlers
• handlers implement WorkItemHandler, WorkItemHandler is a Java class executed at runtime when the workflow reaches the corresponding work item or step
• workflows are launched via commands, e.g. /modules/workflow/workflows/activate which has a workflow property referring to the name of the workflow to launch

...

• activation workflow is defined as SimpleActivation.bpmn 
• its first workitem is called publishNotification which maps to a NotificationWorkItemHandler class
• when activation workflow is started, publishNotification is executed
• publishNotification populates a map of arbitrary data with
  • the work item id 
  • the process id this work item belongs to
  • who started the process
  • who's been assigned to
  • the path to activate
  • if activation is recursive
  • publication date in case of scheduled activation
  • the message view to handle the item in Pulse
• publishNotification creates a Message with the above data and send sends it to Pulse
• user opens the message in Pulse and decides to approve or reject
  • in either case a CompleteTaskAction is triggered and the decision is passed back to the workflow engine in a results map

...

1. Using jBPM User Tasks
   
   • PRO
     
     • would be the "proper" way to implement manual tasks in jBPM (we currently fake them with a Service Task, that is a task usually performed by an automated system, which sends a message to Pulse) 
     • we'd take advantage of all the properties already available there, such as groupId, actorId, comment, etc., no need to reinvent the wheel
   • CONTRA
     
     • no clear documentation on how to integrate it - one is basically left with the source code only. TODO verify that this claim is actually true
     • what about tasks independent of a workflow engine presence?
     • how to make the workflow engine aware of Magnolia groups and users?
2. Extending the Message class into a generic Task
   
   • PRO
     
     • would handle any type of task, regardless of a workflow engine presence
     • easier to persist and query, most of the job already being done by the MessageStore API
   • CONTRA
     
     • would make our workflow solution still rely on our "fake" UserTask

...