One of the nice features of the WebLogic Portal 8.1 release is a fairly extensive content management system. It does not, nor was it ever intended to, compete with the large content management vendors on the market today, but for many applications it works quite well. There are some problems however with using the content management system. This article will address several of them and provide details of a dev2dev tool that will help get around them.

Problem #1: Migration
When content is created outside of a production system, there is no easy way of moving this content into production. In many cases production systems have very strict rules on changing content and ad hoc changes are not allowed, therefore migration is needed.

Problem #2: Backup/Restore
If the default repository is used, all data in the content management system is stored in a database. There are many ways to backup and restore this data using standard database tools, but a good knowledge of the database schema is needed to allow for a proper restore. Often the entire database is backed up, which only allows for a restore to a particular point in time.

Problem #3: Data Type Changes
Data types defined in the content management system cannot be changed if there is any content associated with that type. Therefore, all data must be deleted before a change can be made. This can be frustrating when a lot of data has been created and a simple property change is needed.

Problem #4: Bulk Changes
Sometimes bulk changes are needed in a content management system. The WebLogic Portal Admin User Interface is nice for maintenance of the content and for small changes, but for large ones it can be difficult to use.

Most of these issues are addressed today by fancy SQL scripts written by very advanced database gurus, or that require a large amount of manual work that leads to high maintenance costs.

After facing this issue while building a complex content management-based portal, I decided to build something to help. I developed a Content Management Import/Export tool. I shared this with several of my colleagues and soon discovered this was something that was needed in the public domain. You can find the tool, including source, on dev2dev: http://cmimportexport.projects.dev2dev.bea.com.

I will cover the operation of this tool and how it can be used to address the aforementioned issues.

Installation
You can find an installation guide to help with this process here: https://cmimportexport.projects.dev2dev.bea.com/ files/documents/261/192/InstallationGuide.doc. For the purposes of this article, it is assumed that the CM Import/Export portal was installed; however, the most common installation will be the portlet within an existing administration portal.

To install the CM Import/Export portal, simply deploy the appropriate EAR file from here: https://cmimportexport.projects.dev2dev.bea.com/ servlets/ProjectDocumentList?folderID=96&expandFolder=96&folderID=96 . Once this is done, the tool can be accessed by going to the following URL: http://host:port/cmPortal/cmImportExport.portal. Simply replace the host and port that is appropriate for your installation.

Use
After logging into the portal, you are presented with four options (see Figure 1). Two options deal with content types and the other two deal with content data. The tool assumes you have some understanding of WLP content management and the fact that data types must be defined before content data can be added. However, the tool does not force you to do things in a particular order. Therefore, it is possible to try to import data with no type definitions. This, of course, would result in errors.

Content Types Export
Let's start with content types. If you have an existing repository with type definitions, you can export them to an XML file using the Content Types Export button. Once this is selected, you are able to select which repository to use for the export. When the View Export Tree button is pressed, you will be presented with a list of content types and checkboxes. All items that are selected will be exported to the XML file.

The XML file will be created in the server's temp directory. The final screen will show you the full path to the file.

Content Type Schema
There is no official schema definition for WLP content management types. So, I created one (cmTypes.xsd). The tool uses this schema to create XML beans for the import and export operations. The schema is a simple flat structure that supports all data types and properties except for the "explicit" flag (see Listing 1). The WLP content management APIs do not expose this property. Consequently, if you have types with the explicit flag set, this information will not be exported and the corresponding content data will not be exported. Since this is a user-defined database table, typically a separate process is used to maintain this information anyway.

Note: A future release of WLP may adopt portions of the JSR-170 standard for content management import/export. If this is the case, I will adopt this standard to make it easier to move content data from one version of WLP to another.

Content Types Import
The import operations allow you to upload a local XML file into an existing content management system. The import will look for differences between the XML file and the existing content management types. If there are any conflicts, they will be displayed BEFORE the import (see Figure 2). This allows you to intelligently select which content types should be imported into the new system. Note that in some cases, changes to data types that have associated content data may cause a failure. The existing data may need to be exported, deleted, and then reimported. If the data type structure changes, then the exported XML file may need to be changed to reflect the new structure. There are many good XML manipulation tools available that can do this.