Blog

I can’t resist the urge to write this, but winter is officially over today and I didn’t have to use the snow blower (not even the snow shovel) a single time this winter season (no, I don’t live in Florida) and at this pace, odds are, in few years I’ll never have to wear any winter clothing; I love global warming. Back to business; so we touched base a short while back on a potential Web Content Management (WCM) tool as a potential replacement for WebCenter Interaction (WCI): Drupal.  We also discussed some of its strong merits (hey its free, tons of contributed modules and odds are you’ll find a “module for that” for whatever you are doing, runs flawlessly in hot climates, etc.) and we left the blog with some ideas on how to extract the WCI content out of its proprietary repository into industry standard format (XML or JSON) for subsequent import into Drupal.  I think that intermediary step (converting WCI content into XML or JSON) is necessary because WCI, by design, stores its content and metadata in proprietary format: property bags, data entry templates, content items, document repositories stored in hierarchical folder structures, etc. and it can be difficult to get these different content types and their metadata straight into Drupal without an intermediary stepping stone to bridge the two technologies.  Hence, the idea to write custom ReST services that leverage the portal APIs and expose its content in industry standard format that can be consumed using Drupal’s APIs.  Now what next?  Well, at this junction let’s pause for a second. So I am working on this WCI/Drupal migration project with some very talented individuals and the first thing the team did prior to writing or running any PHP scripts is to do some planning.  At this juncture, we have JSON or XML feeds ready to be consumed; but prior to doing that we need to strategize the Drupal site, not so much in terms of themes, navigation, and layout, but rather in terms of structure.  Drupal is centered on these concepts called nodes and content types. After a vanilla Drupal install, we get a few content types: page, article, forum, poll, comment, etc. but upon enabling some of its modules, we get an array of additional content types.  So the idea here is to map the content types from the portal world to those in the Drupal world.  However, our feeds from the portal may not necessarily map to any of these core content types.  So, we will need to create these custom content types in advance in Drupal along with their respective metadata.  Perhaps, it is also time to do some clean up and deprecate old portal content types and items that have been lingering since Plumtree 5.4 and were never updated since.  But I guess the point here is that every XML or JSON feed content type worthy of porting over should be mapped to an equivalent one in the Drupal world.  For example, knowledge library docs can map to an equivalent in Drupal encapsulating its potential fields: author, creation date, keywords, URL, and abstract.   So now that we have a one-to-one mapping between an XML or a JSON feed from the portal and a corresponding content item in the Drupal realm, we can start writing some custom PHP script that would consume that feed and create the node in Drupal.  Nevertheless, I wouldn’t be surprised if Drupal had a JSON or an XML feed parser that would create the node for us buried somewhere among the zillion or so modules that the Drupal community contributes; I will look into that but if one doesn’t exist, my next task would be to navigate the Drupal API. Stay tuned … Thanks. Hani