Page 2 of 2   « previous page

Content Data Export
Content data presents more complexity. The structure can be hierarchical, can contain many combinations of different data types, and can have multiple values. Therefore, the JavaScript tree presented during the export can be very extensive. The interface allows you to select and deselect entire branches or individual items. Only the selected branches will be included in the exported XML file, so you could modify the root node in the XML file to reposition the entire set of content to another location in the tree. This would be one way to move or copy an entire branch of a content management system.

Content Data Schema
Once again, there is no official schema definition for the content data, and so I had to create one (cmContent.xsd). There are two types of nodes within WLP content management, content and hierarchy. You may notice that the schema only differentiates between these two based on using a node attribute (see Listing 2). This is because these two types are actually identical. That's right, you can have content on a hierarchy node. Most users of WLP content management don't realize this feature exists. In the WLP Portal Admin tool, you can create a hierarchy node and then define a data type and content for that node.

Content Data Import
The content data import is the most interesting. There are many situations to consider when importing data into an existing content management system. When there are data conflicts, it is important to identify them and allow the operator to make a logical choice between importing and ignoring certain content. When using the import tool, items that are in conflict are shown with an exclamation point (see Figure 3) and details can be displayed showing what properties are different (see Figure 4). The user can then decide whether or not to import this particular node. It is important to note that the tool uses content hierarchy and name for matching, not ID numbers. If a node is renamed, no conflict will be seen. IDs were not used because it is very possible that ID numbers will be different from one system to another, but the hierarchy and names would be the same.

Solving the Initial Problems
The overall purpose of this article is to show how this tool can be used to solve the initial problems.

Problem #1: Migration
This was the main purpose for developing this tool. Content types and data can be migrated from one system to another through XML files. It is important to note that the two systems do not need to be accessed at the same time. The exported XML file can be created and imported at a later date (deployment).

Problem #2: Backup/Restore
Migration of data is not the only use for such a tool. You can easily take snapshots of a production system for backup and recovery purposes. The graphical tool or automated script can be used to perform the backup. The XML file name contains the date to make it easy to do periodic backups. Recovery is very easy because the latest backup files can be used and specific data can be included or excluded from the recovery process.

Problem #3: Datatype Changes
Solving this problem is a bit more difficult. Data can be exported to an XML file and then it can be deleted from the repository, which allows the data type to be modified. However, it may be necessary to modify the XML file to reflect the datatype changes. There are many good XML editing tools available to do this, or a simple Perl script can be written. The import tool is very forgiving of datatype changes and so it may not be necessary to change the XML file at all. The import will always attempt to add as much data as possible. For example, if a particular property is deleted from the content management system, then the import will simply ignore this data in the XML file and add the rest of the properties. If a property is added, the import will leave this new property blank.

Problem #4: Bulk Changes
WebLogic Portal provides a mechanism for doing bulk loading, however, it is sometimes more convenient to do this by creating an XML file. For example, for testing purposes, I created a content management type that reflected properties of a file: name, size, permissions. I then wrote a simple Perl script that scanned my filesystem and created a matching XML hierarchy with the file properties. After I imported this into my content management system, I had a full representation of every file on my computer.

Conclusion
The content management system in 8.1 is very powerful and usable, but lacks the important content management migration tools. In WebLogic Portal 9.0, many of these features will be added, but until then, this tool can help make building enterprise-quality applications on top of WebLogic Portal 8.1's content management systems much easier to manage.

Page 2 of 2   « previous page