A few months ago, we posted our ideas for a new workflow module called maestro in the Contributed Modules Ideas group and we had some good community feedback. Since then, we have been making steady progress with the development of the Drupal 7 module and are getting close to releasing a first beta version for the community to play with. This is the first of several blog posts that will offer more explaination on Maestro - it's development progress, roadmap and usage.

 

We had multiple objectives for the development of the module and Randy, Eric and I have been working as a team sharing ideas and the development effort. We are basing the Maestro module on our Nexflow application which is used by our biggest clients for a number of critical business workflows and has been in use for over five years. But this is not a simple port of the Nexflow code and like our other applications we have moved to Drupal as modules, this is a full re-write to take advantage of the native Drupal API , core features and extensive array of modules that extend any single modules capabilities. Additionally, we had design goals to make maestro very extensible and have used a number of Design Patterns in the code design coupled with Drupal's API HOOKS.

 

Maestro has a number of components that include the workflow engine and the visual workflow editor which is used to define the workflow - creating a workflow template. The workflow engine runs in the backgound and executes the workflow tasks, testing the tasks execution results and branch the workflow if required. The workflow engine will run every x seconds and execute all tasks that are in the queue which have not yet completed. Once they execute and return a success status, the engine will archive them and step the workflow forward. Both these components have been developed to support any number of different task types. New task types can be developed and added much like the Drupal CCK module can support new field types. Initially we will have the following task types:

  • Content Type Task: Assign a task to a user to create a new content node - task definition allows you to select from available content types.
  • Interactive Function Task: Assign a task to a user that executes a custom function or one provided with maestro to display an interactive form to the user in the task console. This could be task to review and approve a content node, form submission or an inline form to collect information from a user that effects the workflow - such as asking a question that is later tested to branch the workflow.
  • IF Task: used in the workflow to test for a condition and branch the workflow. The IF task can test for the execution status of the previous task (did it complete successfully, aborted, cancelled or put on hold) or it can branch based on a value of a process variable.
  • Batch Task: executes a php script - executed by the engine in the background.
  • Batch Function Task: executes custom code, drupal function or other module function automatically by the engine. This can be a simple function like drupal_set_message or a custom function that works with optional paramaters defined in the task definition. A batch function can also contain far more complex code with database and remote system API calls. The batch function does not necesarilly need to complete immediately and can return a non-complete status and will execute the task again the next time the engine runs. It may be that this batch function is testing for a remote condition to become true before moving the workflow forward.
  • Fire Trigger Task: this task will lets you setup a trigger task that will execute one of the defined drupal actions - offering lots of extra flexibility.
  • Set Process Variable Task: workflows can take advantage of user defined process variables that are unique to each instance (process) of the workflow. Tasks can be assigned by process variable which allows workflow tasks to be dynamically assigned based on data collected during the workflow such as a determining from the users profile what department they work for and assigning the equipment purchased request to their department manager. A workflow can have any number of process variables can store any value that you want to test for later in the workflow or use in subsequent tasks. This task lets you assign a value to a process variable or do simple math on it. An IF task can test for the value of a process variable and branch the workflow.
  • Manual Web Task: part of this task setup is to provide a URL which can be an internal URL or remote URL for an application. This is an interactive task where it will appear in the assigned users task console. The user will click on the task to execute it and will be redirected to the URL defined in the task definition. It's up to the remote script to trigger the completion of the task and clear the task from the users task console.
  •  AND Task: Allows you to have workflows that have multiple branches and then join up at an AND task which effectively waits for all branches to complete before it executes. You may need to get approval from three different managers and each approval branch of the workflow can execute at the same time. Branches don't need to have similar tasks or even the same number of tasks.

We are also looking at creating a TIMER TaskType as well which would allow you to add a task to the workflow that will pause the execution until a specific date/time or pause for x days, hours or minutes.

 

We recenty put together a 10min video showing Maestro running inside Drupal being used for a content publish  workflow requiring an Editor and Publisher to review and approve the article before proceeding to a batch function task that publishes the article.

 

Another discussion that mentions Maestro:  Drupal Workflow and revision managment

 

 

General Tags