With Drupal 8 emerging on the horizon, we've started to delve in to our core modules, Maestro and Filedepot, beginning the process of porting them from Drupal 7 to 8. For our Drupal 8 version of Maestro, I have some immediate concerns that I would like addressed, but also some "wish list" items which I feel would bring a great deal of flexibility. A condensed road map, of sorts, for Maestro's first release on Drupal 8 would be:
We already have the ability to create a drupal action to launch a maestro workflow and trigger that action from drupal. Maesto also has a trigger type task that can launch drupal actions from workflows but we did not have rules integration. We also needed a way to better track adhoc new instances of maestro processes with drupal entities like node and users.
Maestro has a content type task that automatically will create the relationship between the content node and maestro proceess information but there are cases where the maestro content type task is not used to create the content entities and we did not have an easy way to later link maestro processes with content nodes or other entities.
The regenerate functionality goes back many years in the history of the Maestro engine. I wrote the very first instance of the "Maestro" engine back in 2004/2005 where it was nowhere near as flexible and nowhere near as extensible as it is today as Maestro. That being said, the engine's internals have been updated and upgraded over the years which has culminated in what you see today. The concept of regenerate and regenerate all live tasks comes from the very beginning of the engine's life and lives today in Maestro 1.0's engine.
How do I..... ? is a question we hear quite a bit when it comes to the Maestro API. We have a few very good blog posts on our site and also bundle Maestro with some good example code. However time has come to begin to document how to do a variety of common things with the Maestro API.
In part 1 of our Maestro module overview we explained the different task types that we have available in the module. One of these task types is the Interactive Task and this blog post will provide more detail on this task type and how to create your own custom function for it to use. In an interactive workflow driven process, there are many times you need to present information or request information to a user. Examples of this would include:
- Submit a task to a user to create or update a content type record. This may be a drupal article or something more site specific like a job request setup as a custom content type
- Prompt a user to review a piece of information to approve or reject - possibly an article or that job request
- Ask a user for some information using a form - results of which need to be used in the subsequent workflow
- Ask a user to pick from a list of users who should be assigned a subsequent task in the workflow
- Show a user some information - may not require any action
Basically any task where we want to interact with the user and we want full control over what is displayed. We may need to prompt the user with custom submit actions and execute code depending on what action the user takes.
Please note: this blog post refers to Maestro on Drupal 7.
Maestro was a rewrite/refactor of our Nexflow product. When I wrote the first iteration of the Nexflow engine, I always had an Object Oriented approach in mind. While the original Nexflow engine is object oriented, it lacked a clear and clean way to easily implement new features. Although you could easily write a new task type, it was much more difficult to implement in the engine, requiring editing of core code which would always require extensive engine retesting. Maestro Development Methodology:
Our overriding goal was to create a development environment that was suitable for developers to easily attach their own task types and notification mechanisms in to the system without overwriting or hacking core code. Leveraging the strength of Drupal's core functionality along with some neat OO patterns, we were able to create a base set of modules for Maestro that lets developers add their own task types and/or notification mechanisms via add-on modules.
In order to create a Maestro task module, you need to first understand that there are 2 sides of a Maestro Task. There is the User Interface side and the Engine side.
The UI side is responsible for providing the end-to-end user driven experience in creating a workflow using the visual workflow editor. The user interface provides the hooks for showing a task's general display widget as well as its associated editing panel. Without a UI component, users can't use the task in the workflow designer.
The Engine side is responsible for providing the behind-the-scenes worflow engine capabilities that allow Maestro to carry a process forward through the template created by the UI side. The engine side provides all of the necessary logic to execute and complete a task by the Maestro engine.
Maestro is a Drupal 7 module -- meaning that it will not run on Drupal 6. All development for Maestro in terms of its engine must be done on Drupal 7. This blog post is 100% dedicated to showing you how to create a D7 Maestro task module.
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.