Actionkit Project

Introduction

The data level integration project looks at ways of integrating Drupal and ActionApps on the database level. The objective is to make ActionApps items available as Drupal nodes.
We began by looking at how data is stored in the two systems. Then we looked at different integration approaches, developed a prototype implementation of one of the approaches and finally looked at ways of improving this.

Structure of Items in the ActionApps Database

Items in the ActionApps database are stored in two tables:

• item: contains the item ID and some general information like the author, the date, etc
• content: contains any additional fields. These are typically the headline, the abstract, the fulltext and any other custom fields. These are identified by the same item ID as is stored in the item table.

ActionApps offers a simple API for retrieving and storing items.

Structure of Nodes in the Drupal Database

"Basic node information, such as a node id, node type, title, created by and when, etc., is saved in the node table. The node body is saved in the node_revisions table." *
According to this, additional node information needs to be stored in custom tables that are created during the installation of a new module (see Creating new node types).

Approaches

• Complete Import

  A complete import would mean migrating all data from AA to Drupal.

  Advantages

  • The data is kept in one location. No need to synchronise or worry about consistency, locking etc.
  • Can use all of Drupal's features like search, views etc

  Disadvantages

  • Loss of AA interface
  • Need to retrain users
  • No possibility of a smooth transition
• Partial Import

  This means keeping data in two separate databases and finding some way of identifiying one with the other. The unique identifier in AA is the long (unpacked) item ID. The idea here is to create Drupal nodes that use this item ID to associate with items in the AA database.

  Disadvantages

  • A major disadvantage of this approach is the use of item IDs. They do not contain any human readable information. To retrieve them from AA the user has to copy and paste them from the AA admin interface or a special view. Using them as title in Drupal makes thinsg even more user unfriendly.
  • There is a theoretical possibility that two users could be editing one and the same item at the same time - one in ActionApps and one in Drupal. Thus, this would require a locking mechanism of some sort.

  Advantages

  • Users can keep using the ActionApps interface while a site developer can migrate an AA site to Drupal to take advantage of advanced Drupal features.
  • Information is not duplicated. Only the idem ID is stored in both databases. So there is no need for synchronisation.
  • It reduces the amount of work necessary for an initial export (from AA) and import (into Drupal).
  • Views in AA could link to Drupal nodes.

• Synchronisation

  Implement a script that synchronises information stored in the AA database with the Drupal database.

  Disadvantages

  • It is not clear what to synchronise with what. In other words, should the AA database be updated with information from Drupal or the other way around.
  • This can be quite heavy in terms of load and processing requirements as there has to be some way of checking for updates of one database and comparing with the other database.

ActionApps Item Module (aaitem)

Implementation of a Drupal module that displays content from an ActionApps database.

The aaitem module uses a partial import. In order to use an AA item in Drupal the user has to enter the long AA item ID. Once this has been entered it cannot be changed anymore (this is a limitation of this implementation, not a principle one). A Drupal node is created representing the AA item. In a more advanced implementation the user could be given a list of AA headlines to choose the item ID from, set up mappings (see below), and customise the way the AA data is displayed.

The code for this module is based on the Drupal tutorial Creating new node types.

The ActionApps abstraction layer developed for Task #2 now allows for retrieving and storing items from the ActionApps database:

  /**
   * Return an ActionApps item object
   * @param item_id AA item ID
   * @return AAItem Object or false if not found
   */
  function getItem($item_id)
  
  /**
   * Store an ActionApps item object
   * @param item_id AA item ID
   * @param content_array content (key=>value)
   * @return item_id or false if failed
   */
  function updateItem($item_id,$content_array)

In Drupal the following hooks are used:

• aaitem_load: Whenever the node information is loaded from the Drupal database we also load information from the ActionApps database
• aaitem_form: The default is to display the title field and prompt the user to input an AA item id (long id/unpacked). Once the user has entered an item id some fields of the AA database are pulled from the AA database and displayed.
• aaitem_submit: Store the information back to the ActionApps database.
• aaitem_view: Uses a table of predefined mappings to replace Drupal content with content from the AA database when a node gets displayed publicly. For instance, the node title (AA Item ID) is replace with the content of the AA headline field.

Todos

• map categories to taxonomy or find some general approach to taxonomy
• develop an interface that allows the administrator to customise the mapping
• display headlines instead of item IDs in the admin interface
• write the Drupal node ID to the AA database so it can be used in views there to link to Drupal pages

Developing Migration Tools

The aaitem module shows that it is possible to use data stored in a different database with Drupal nodes. It even allows for editing the content and saving it back to the original database. Nevertheless, it has shortcomings, e.g. it is limited to a couple of predefined AA fields, there is no support for date fields etc. For real world use it would need a configuration interface for mapping AA fields to Drupal fields and options of how to interpret and display them.

A possible solution for a migration script could be one that iterates through one ActionApps slice and creates an aaitem node for each item ID. This would allow to run both systems in parallel. Thus reducing the need to train users, schedule downtime, or freeze a web site. One question in this scenario is where the data should stay. There is two options: the current aaitem implementation keeps the data in the AA database. But with a few changes to the code it would be possible to store data to Drupal - overwriting the default Drupal node fields. Since Drupal would require any extra information to be stored in a new table this does not seem to be the best approach. Especially, since the partial import approach still allows using the ActionApps Item Manager and Views while a site runs on Drupal.

In this example an item from ActionApps is being used in Drupal using the aaitem module. The item data will stay in the ActionApps database. The only information stored in Drupal is the ActionApps Item ID.

After activating the aaitem module in Drupal and assigning appropriate access permissions the aaitem content type shows up in the Drupal create content section.

Next it is asking for the ActionApps Item ID. Finding this out is more complicated than expected. To find this out it is necessary to change to the ActionApps Admin interface.

In Slice Admin | Item Manager View the default view is changed to display the Item ID (_#ITEM_ID#).

Now the Item IDs show up in the ActionApps Item Manager interface. This is the ID quired by the aaitem Drupal module.

Back in Drupal.

And after pressing submit the content of the ActionApps item is being displayed. Note that as headline of the node in Drupal it uses the ActionApps Item ID - not very user friendly.

It is interesting that the content can be edited in Drupal and will also be updated in ActionApps.

Her the Headline of the article is being changed.

After updating the node in Drupal the changed headline shows up in the ActionApps Item Manager.

Finally, the ActionApps item is diplayed on the Drupal page.

Conclusion

The approach taken for the development of the aaitem module makes integration of ActionApps and Drupal very easy. Though it is only a prototype at the moment, it already shows that keeping data in ActionApps while allowing to view and edit it in Drupal is worthwile for cases where a smooth transition from ActionApps to Drupal is necessary. Furthermore, it even allows for the running of both systems in parallel and friendly co-existence.

Home Actionkit Demo