Drupal rides the Enterprise Service Bus

Project Brief -- Drupal Integrated into Microsoft Architecture

The American Productivity and Quality Center (APQC) is a member-based, non-profit organization that provides businesses with resources on process and performance improvement with a focus on knowledge sharing and best practice research. APQC's web site is where members go for documentation, the online library, surveys, and more.

APQC is launching a new site this year, and Drupal is one of several systems playing a role. Drupal will handle content and user management, eCommerce (via Ubercart), and social features.

Achieve's role in the project has been to customize Drupal and ensure that it can scale, perform, and integrate into the overall infrastructure. With launch imminent, we wanted to post about some of the Drupal integration details, and promise to share more information when the site goes live.

SOA Architecture

The project as a whole lent itself to a Service-Oriented Architecture (SOA) approach, which enables platforms to handle discrete functions and play to their strengths. The challenge in such an approach, of course, is securely and efficiently syncing data between systems. APQC mitigates this difficulty by employing Neudesic's Enterprise Service Bus (ESB), a Microsoft-platform middleware package that can take input from the various applications and propogate it throughout the system.

The SOA lays the groundwork for a multi-platform site that offers a rich array of functions for members, appears seamless to users, and automates as many administrative procedures as possible, keeping long-term costs down.

The Achieve Discovery Phase for Drupal Integration

The discovery phase of this project was quite thorough to account for the complications involved and the client's desire to ensure flexibility and performance. Approximately one man-month was devoted to discovery, with Achieve Internet and APQC project managers and technical leads spending much of this time on integration issues.

Data-Mapping for the ESB

The most significant part of the process was data and object-mapping and the clear identification of triggers and communication paths to enable real-time synchronization. The discovery team resolved cases related to:

• >platforms having different names for fields
• >varying object field requirements
• >additional “gotchas” such as date format

The product of the mapping sessions was a specifications documents the team could use for development.

Sharing Resources

Another integration point that had to be settled was user authentication. The survey system, it was determined, would not store user data. As a consequence, Drupal would handle user logins and session management. This required identifying a communication path and methodology.

Meticulousness and Creativity

The emphasis during discovery was on thoroughness and flexibility, with the Achieve team clearly identifying the present requirements and also predicting the enhancements and changes that might be required in the future.

Development

Custom Drupal Modules for Integration

Achieve developers took a test-driven approach to the Drupal/ESB integration. Using the specification documents generated during discovery, we used the Drupal Simple Test module to construct test cases for the desired functionality. Next, we started writing the modules and classes required to pass the tests. This approach allowed us to start with failure, iterate quickly with new code, and work toward success.

The modules we created were designed to handle RESTful communication with the ESB in order to both accept updates made in other systems and pass along changes made in Drupal. We accomplished this by writing a core class that encapsulates as much functionality as possible and then creating a class that extends the core for each specific object. Ultimately, this led to us writing one core module (called “ESB”) and sub-modules called ESBorders, ESBprofiles, and ESBmembers, since order, profile, and member data would need be synchronized with the other systems.

The core module, in addition to containing common functions, also acts as the listener. It accepts XML-formatted data from the ESB, creates a PHP XML object, and then makes the necessary updates to Drupal.

Each sub-module is responsible for sending updates made in Drupal to the ESB. To do this, the Achieve team used existing Drupal hooks to call additional functions when appropriate. If a user updates her profile, for example, the esb_profile function fires, packaging the updated data into XML and sending it to the ESB.

This cluster of object-specific modules will certainly be expanded, and ESBticket is already in the works to handle help desk issues.

Session Authentication

Even with the ESB, a one-to-one integration point was necessary between Drupal and the survey platform. APQC preferred to use Drupal for user management, so each log in for the survey system actually occurs in Drupal. After validating and redirecting users, Drupal also must respond to session authentication requests. In those cases, Drupal determines whether the session id is valid—by comparing the cookie session id with the one stored locally during the login process—and sends a response.

Since this functionality depends primarily on the standardized cookie specification, it can be re-purposed so Drupal can handle authentication for other systems in the future.

Drupal Succeeds in a Strange Land

In the case of APQC, an SOA approach allows Drupal to integrate into a primarily Microsoft environment, with the ESB serving as a universal translator. With ample planning and a test-driven, iterative development approach, the Achieve team found yet again that Drupal's adherence to standards and the flexibility of open source really pay dividends in projects such as these. Additionally, the discovery phase yielded a specification document that governs inter-system communication, making it easier for APQC to add additional platforms when the need arises.