How About Drupal?
It is a soul searching time for many of WebCenter Interaction (WCI) customers as the product’s remaining lifespan is approaching retirement and its residual years are numbered in a single digit. Some customers are contemplating sticking with the WCI stack and perhaps upgrade to 10gR4 making the best out of the product’s lifetime, others are considering other Oracle enterprise solutions: UCM or WebCenter Spaces. Some are jumping ship and switching camps to Microsoft and will implement a SharePoint Portal solution. Yet, the move from WCI doesn’t necessarily have to be towards an enterprise solution costing an arm and a leg for your corporation. So why not go open source?
If you were using WCI as a front-facing website or as a Content Management System (CMS), and many have being using it as such, then Drupal can be a cost effective substitute. I had a conversation with my alter ego debating that thought:
[AE] Yeah, but why Drupal?
[ME] Well, for one thing because it is free and you’ll spare yourself countless green between software procurement, maintenance and support. Actually, with just 0.01% of the annual maintenance cost of an enterprise solution you can pay for Drupal + PHP training for your Portal IT folks.
[AE] Are you kidding me, implement an open source CMS as an enterprise WCM for a government site?
[ME]: Precisely, and if security is your concern, then Drupal has a good track record in that field it has a security team that addresses security issues, and has an organized process for investigating, verifying, and publishing possible security problems. Moreover, the maturing and increased security of using open source was cited as one reason Whitehouse.gov used Drupal.
[AE] Well, I am not a democrat and just because whitehouse.gov is running on Drupal doesn’t mean it is a compelling reason for me to switch to Drupal! Who else is running on Drupal?
[ME] You don’t have to be a Democrat to run Drupal. Many Republicans have also embraced it: notably Mitt Romney, Republican Senator Scott Brown, and even good old Newt Gingrich. Likewise, over the past few years, the popularity of Drupal has amplified and some pretty big names have taken notice. Media companies such as MTV UK, Lifetime, and Sony BMG Records are using Drupal as a means of building loyal communities around their products. Print publishers such as Popular Science magazine, and Fast Company magazine use Drupal to provide interactive online content to their readers. Amnesty International, the United Nations, and the Electronic Frontier Foundation use Drupal to coordinate activism on important issues. Ubuntu Linux, Eclipse, Firefox, and jQuery are open source projects that employ Drupal to nurture their contributor communities.
[AE] Ok, fine, but how do I know if Drupal is right for my organization? What is its use case?
[AE] Now we are talking. Below are some considerations from Drupal.org where Drupal can be a viable decision:
- You need a site that is flexible enough to evolve in any direction. For example, you might start with a blog but want the option of adding other features like a wiki, forums, WCM, etc.
- You need a site that can easily be configured to interact with other sites or with other technologies.
- You need a site that can easily handle complex forms and workflows.
- You need the ability to create your own content types. For example, you need to add a custom field to a page.
- You need the ability to quickly organize and display lists of information.
- One or more of the many contributed Drupal modules addresses your needs.
- You need to quickly develop custom functionality.
- You need to create web applications and mashups using third party API's.
[AE] But I am heavily vested in WCI and have heaps of content in Publisher and bags of documents in the Portal Knowledge Library; if I decide to move to Drupal, is there an easy path to migrate my content off WCI to Drupal?
[ME] No free lunch here but it is a challenge you will have to face sooner or later when and if you move to another CMS; but it isn’t impossible and I think the process can be multi steps:
1. Drupal is written in PHP and we can’t call the Portal APIs through PHP, so perhaps we can use ReST calls (something like this http://example.com/kd/99999 for Knowledge Directory (KD) cards and http://example/content/55555 for Publisher content items) that return the content in text-based open standard format (JSON or XML – my preference is JSON.) The structure would capture all the Publisher content along with the content item’s attributes. Same thing for the KD cards and we need to include in the returned JSON the URL for the card as a property. We can also include the Portal security groups as a JSON array for each content item and KD card as well as the folders where the card is stored in. For each REsT call we would be passing the KD card ID (99999 in the example above) and the Publisher content ID (55555 in the example above) while iterating through the ptCards and pcsContentItem tables respectively. An example of a KD card JSON can be something like that:
"name": "Memoirs of my altered ego",
"created": "2008-04-07 10:49:54.0",
"description": "This document contains my memoirs",
"name": "Memoirs of my altered ego",
"\\Document Directory\\Folder 1\\Folder 1_1",
"\\Document Directory\\Folder 2\\Folder 2_1",
"\\Document Directory\\Folder 2\\Folder 2_1\\Folder 2_1_2",
"\\Document Directory\\Folder 2\\Folder 2_1\\Folder 2_1_2\\Folder 2_1_2_1",
"\\Document Directory\\Folder 3\\Folder 3_1"
"Author": “Hani Atalla”,
"modified": "2010-07-29 01:57:12.0",
“property 1: “Property 1 Value”,
“property 2: “Property 2 Value”,
“property 3: “Property 3 Value”,
“property 4: “Property 4 Value”
“property 5: “Property 5 Value”
"Portal Group 1",
"Portal Group 2",
"Portal Group 3",
"Portal Group 4”
2. That export utility is not tied to a Drupal migration as it can be handy when moving to any CMS and can be consumed from anywhere. But now, we need to do some careful planning as we will need to map the WCI content to Drupal objects. The core of the Drupal CMS is nodes as these are Drupal’s building block (more on nodes here.) An important part of planning any Drupal site is deciding what specific kinds of content (referred to by Drupal as “content types”) you’ll be working with. In almost every case, each one will be a different kind of node. All nodes, regardless of the type of content node store, they share a handful of basic properties: an author, a creation date, a title, and body content. So we need to map Portal objects to nodes of specific type and Portal objects’ properties to Drupal custom fields.
3. Just as WCI has its native APIs so does Drupal. I am still reading on these but I imagine we will leverage the Node module to create nodes and set basic node fields when writing a PHP import script.
4. The next step is to skin the Drupal site with a theme.
5. Another step is security and assign Drupal roles to the nodes that were created.
Again, a considerable amount of planning needs to be applied to the process but the intent here is to evaluate whether Drupal is right for you. I think I might have made a dent in my alter ego convincing him to at least consider Drupal and explore it. But meanwhile, I need to do my homework and explore the product further and blog about it as I dive in its core. So stay tuned. Meanwhile here is a cool Drupal intro.