Sort by:[Date]

Maestro, SQL Server and IIS

With the increased level of support by Microsoft for not only PHP on IIS, but also getting SQL Server support for Drupal 7, the barriers to entry for Enterprise level customers for Drupal are diminishing rapidly.
Case and point – we recently deployed a Maestro managed workflow process for an Enterprise level customer who would have never entertained the notion of using Drupal or Maestro if it ran only on MySQL. As sad as that sounds, it’s a stark reality for many large companies who will outright refuse even the best solution due to their perceived increased support costs for “yet another database engine” (MySQL).
With that said, my time on our Drupal 7/SQL Server/Maestro project went smoothly as I could have hoped for. There were a few curveballs here and there that hopefully this posting can help someone else overcome. So here I go:

Microsoft SQL Server and Drupal? More likely than you think!

With the recent release of Drupal 7, its PDO database abstraction layer means that Drupal 7 can technically support a variety of databases (provided they have the proper Drupal 7 database interface).
Of course, what Drupal 7 + PDO means is that yet another barrier to entry for "Microsoft Shops" to use Drupal has faded away.  One of the biggest reasons.... ahem.. excuse to not use Drupal (or just about any other Open Source CMS for that matter) was that the CMS needed to run on _______  (fill in the blank here with whichever database you like that is NOT SQL Server).  Not to mention the poor support that used to plague PHP on IIS.
Thanks to hard work by Commerce Guys, the sqlsrv project was born, giving Drupal 7 the required SQL Server database driver. That being said, you may notice that the sqlsrv project is still in an Alpha release state at the time of writing of this blog article (Update -- January 31st 2011  -- sqlsrv is now in RC status!). The Alpha state of modules generally turns people away from using it. However I strongly urge people to continue to use it and help work out any bugs with sqlsrv to bring it to a stable release.
Regardless of the release state of sqlsrv and some of the outstanding issues in its issue queue, it does run quite well and actually didn’t give me any major issues when working on a Maestro project for a client.  

Maestro 1.0 is Now Available

This release fixes the critical outstanding issues with Maestro. There are still some would-likes that will make it into 1.1, which is planned for release candidate around February 18th.

Among all the fixes the most important is the fix for the content type task, which was stalling after uploading a file. Version 1.0 has been fully tested in both MySQL and MSSQL Servers alike. For more information, check out the Maestro page. You can download Maestro on our project page on

Maestro 1.0 RC1 is Available

In light of the recent Drupal 7.0 release, we have finished testing Maestro with D7.0 and are ready to announce the first Maestro release candidate. We will continue to test for bugs, and if no critical issues arise then version 1.0 will be upon us soon!

In particular, this version of Maestro has a number of fixes for MS Sql Server users. For more information on Maestro, check out the Maestro page. You can download Maestro on our project page on

Tracing the Call Stack in PHP

Here's a neat trick I picked up which will help you debug your PHP application. But before I get into the technique, consider this scenario: You're getting a PHP error deep within a class which you didn't write, but are calling its methods. The PHP error message tells you the line and the error that it was running into, but ultimately the issue lies with a parameter you passed into the method.

Let's say the error you were getting was "A SQL Error Has Occurred. Check error.log for details". So you check the error log and sure enough you see the line of SQL that failed. But your application is big and you have many similar SQL statements. PHP tells you the line it failed on, but thats inside the SQL wrapper class you're using. You want to know what db_query statement you called which caused the SQL error to be thrown within the class. Searching your code for the SQL code you wrote is a good start but again, there are lots of similar queries.

Maestro Overview Part 2 - Interactive Tasks

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.

Maestro Internals - Creating a Maestro Task Module

Recently we posted a blog entry Introducing Maestro and it's task types. As noted in that blog post, 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.

Maestro Overview Part 1 -- Task Types

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:

Timesaver - Timesheet management made easy

Anyone who has ever had to record their time down to the minute for a project or for billing purposes knows how tedious the process can be.  Having to not only do the time recording, but also MAKE time to record your time has always been part of the problem.  Too often people are too busy to pop in their time entries on a daily basis and end up reverse engineering their week to do all of their time entries in one fell swoop on a Friday night! 
I've been around multiple time recording systems during my career -- starting with an archaic text based system that was so riddled with options and "special functions" that it made time entry rediculous.   Nearlly all timesheet systems I used over the next 10 years were overly-complex, time consuming and had UIs that must have been written in the days when 640k of RAM was a luxury.  Couple the archaic interface with "Mr(s). Friday Night Timesheet Entry Person", and you have a recipe for disaster when it comes to accurate time reporting.

A new module developers introduction to Organic Groups

During the initial develop of filedepot module, I explored Organic Groups (OG) and found it's implementation was very different from what I have seen in other CMS/PHP Frameworks. The filedepot module allows you to define access rights per folder and wanted to initially integrate OG for group based security access. I was not able to find any good examples of how to use Organic Groups from a module developers perspective, and it was decided for the initial release, to only support assigning access rights to users and roles. The concept of role in Drupal is sort of similar to how Groups are implemented in other CMS/Portal frameworks in that it's an integrated core component with an API to get a list of roles or test if a user has a particular role.

For Drupal, the roles a user has are available as part of the $user global object as $user->roles. The filedepot module maintains the folder access rights in the filedepot_access table and it was straight forward to cycle through the $users->roles for the active user and execute a query against the filedepot_access table for the needed permission. The module also checks for a permission access record for that users specific user id (uid). The permissioning method for filedepot was created so that it could easily be extended to also support organic groups - once I figured it out. Even with out support for Organic Groups, the modules ability to assign access rights (view, upload, admin) per folder to a combination to users and role provides a lot of flexibility and would be fine for most site deployments.

When we started the filedepot development, we were not as familiar with the Drupal Community or the Open Atrium distribution. Open Atrium is a very nicely developed release of Drupal for an Intranet or Portal and has a rich user interface that is built around Organic Groups. Users of Open Atrium really need a file / document solution like filedepot but it will need to support Organic Groups to be an effective solution.