Archive and Migration Strategies

This chapter provides information about several typical archiving and migration strategies for Oracle WebCenter Content Server.

Note: All of the scenarios described in this section can be run manually or automatically (through replication).

This chapter covers the following topics:

• Export

• Import

• Self Export/Import

• One-to-One Archiving

• One-to-Many Archiving

• Many-to-One Archiving

• Archiver Examples

• Configuration Migration Tips

Export

This section provides information about strategies for exporting.

Summary

A simple export is typically used to:

• Store and later remove outdated content on a file system.

• Store content on a file system for later retrieval.

• Retain a snapshot of a Content Server instance at a certain date and time.

Configurations

The following are possible export-only configurations, shown in order from most to least typical:

• Export to a collection on an external file system.

• Export to one of the Content Server instance’s own collections.

Import

This section provides information about importing.

Summary

A simple import is typically used to:

• Retrieve content from storage after an unintended deletion.

• Restore content from an archived ‘snapshot’ of a Content Server instance.

Configurations

The following are possible import-only configurations, shown in order from most to least typical:

• Import from a collection on an external file system.

• Import from one of the Content Server instance’s own collections.

Self Export/Import

This section provides information about self export.

Summary

Self export/import is typically used to change content metadata to new values.

Configurations

The following are possible self export/import configurations, shown in order from most to least typical:

• Export to and import from one of the Content Server instance’s own collections.

• Export to and import from a collection on an external file system.

One-to-One Archiving

This section provides information about one-to-one archiving.

Summary

One-to-one archiving is used to copy or move content from one Content Server instance to another.

Configurations

The following are possible one-to-one archiving configurations, shown in order from most to least typical:

• Export, transfer, and import over sockets.

• Export, transfer, and import on a shared file system.

• Export to and import from a collection on a shared external file system.

• Export to the source Content Server collection and import directly from that collection on a shared file system.

• Export from the source Content Server instance directly to a collection on the target Content Server instance and import from that collection on a shared file system.

One-to-Many Archiving

This section provides information about one-to-many archiving.

Summary

One-to-many archiving is typically used to copy or move content from a contribution server to consumption servers.

Configurations

The following are possible one-to-many archiving configurations, shown in order from most to least typical:

• Export, transfer, and import over sockets.

  When this configuration is automated using replication, a separate export archive is required for each target server because the source files are deleted upon transfer. However, for manual transfer, you could transfer a single archive to multiple targets.

• Export, transfer, and import on a shared file system.

  When this configuration is automated using replication, a separate export archive is required for each target server because the source files are deleted upon transfer. However, for manual transfer, you could transfer a single archive to multiple targets.

• Export to and import from a collection on a shared external file system.

  When this configuration is automated using replication, a separate export archive is required for each target server because the source files are deleted upon import. However, for manual import, you could import a single archive from multiple targets.

• Export to the source Content Server collection and import directly from that collection on a shared file system.

  When this configuration is automated using replication, a separate export archive is required for each target server because the source files are deleted upon import. However, for manual import, you could import a single archive from multiple targets.

• Export from the source Content Server instance directly to collections on the target Content Server instances and import from those collections on a shared file system.

Many-to-One Archiving

This section provides information about many-to-one archiving.

Summary

Many-to-one archiving is typically used to:

• Copy or move content from several contribution servers to one consumption server.

• Move sensitive content from several contribution servers to a more secure contribution server.

Configurations

The following are possible many-to-one archiving configurations, shown in order from most to least typical:

• Export, transfer, and import over sockets.

• Export, transfer, and import on a shared file system.

• Export to and import from a collection on a shared external file system.

• Export to the source Content Server instances’ collections and import directly from those collections on a shared file system.

• Export from the source Content Server instances directly to a collection on the target Content Server instance and import from that collection on a shared file system.

Archiver Examples

This section provides examples that illustrate how to use Archiver to solve common business problems.

• Copying a Content Server Instance to a Laptop

• Transferring by Content Type and Author

• Changing Metadata Fields

• Adding Content ID Prefixes

• Changing Release Dates

Copying a Content Server Instance to a Laptop

In this example, you want to set up a laptop computer with a copy of a Content Server instance for a colleague who will be traveling.

This procedure assumes that the source Content Server instance and the laptop computer have access to the same file system, and that the laptop computer has Content Server software installed.

1. Open Archiver on the source Content Server instance.

2. Create a new archive.

3. Because you want to export all content, you do not need to create an export query.

4. To limit the file size of the archive, choose the Latest Revisions option on the Edit Export Query page.

5. If content types and user attributes need to be copied to the laptop system, select Content Configuration andUser Configuration on the Export Data tab.

6. Set export options from the General tab:

   • To save space on the local system, select Replace Existing Export Files.

   • If your colleague needs web-viewable files, select Copy Web Content.

7. Initiate the export manually.

8. Open Archiver on the laptop Content Server instance.

9. Open the source collection and select the archive to import.

10. If content type and user attributes were exported, select these options on the Import Archive page.

11. Initiate the import manually.

Transferring by Content Type and Author

In this example, you have a contribution Content Server instance where users submit content. You want to automatically archive HR content that is contributed by JChang to a Content Server instance in another building that serves as a Human Resources portal.

This procedure assumes that the two Content Server instances do not have access to a shared file system, and that the Human Resources portal server should contain only the latest revision of each content item.

Setting up an Automated Export

To set up an automated export on the Contribution Content Server instance:

1. Create an archive.

2. Set these export queries for the archive:

   Field	Operator	Value
   Content Type	Is	HR
   Author	Is	JChang

3. In the Edit Export Query page:

   • Select Export Revisions with Release Date later than most recent Export Date.

   • Select the Latest Revisionsoption.

4. Set export options from the General tab:

   • To save space on the local system, select Replace Existing Export Files.

   • To include web-viewable files in the archive, select Copy Web Content.

5. Export the archive manually.

6. In the Replication tab, register the archive as an automated exporter.

Setting up an Automated Import

To set up an automated import on the HR Portal Content Server instance:

1. Create a target archive.

2. Select the target archive and ensure that the Update Override Action is set on the General tab.

3. Import the target archive manually.

4. In the Replication tab, register the archive as an automated importer.

Setting up an Automated Pull Transfer

To set up an automated pull transfer from the Contribution server to the HR Portal server:

1. In the Contribution Content Server instance, create an outgoing provider to the HR portal Content Server instance.

2. Open Archiver on the HR portal Content Server instance.

3. Open the target collection and make the target archive ‘targetable.’

4. Open the source collection and select the source archive.

5. In the Transfer To tab, select the target archive as the target destination.

6. Run a manual transfer.

7. Set the transfer to be automated.

Changing Metadata Fields

In this example, you have a custom metadata field, ApprovedBy, which was used in one Content Server instance, but the field name must be changed to Sponsor for consistency with other Content Server instances.

1. Create the new Sponsor metadata field.

2. Create an archive.

3. Manually export all content to the archive. (You do not need to create an export query.)

4. Set up the following import field map for the archive:

   Export Field	Target Field
   xApprovedBy	Sponsor

5. From the General tab, select Update as the Override Action.

6. Initiate the import manually.

7. Delete the ApprovedBy field from the Content Server instance.

Adding Content ID Prefixes

In this example, you have two Content Server instances that are used as contribution servers, but you want to have all content available for consumption from both servers. You can set up an automatic transfer in both directions. However, both Content Server instances use automatic Content ID generation with similar numbering schemes, which could result in errors or overwritten revisions if you import files with Content IDs that already exist on the target Content Server instance.

• One way to avoid conflicts is to add a unique prefix in the Auto Number Prefix system property on both Content Server instances.

• Another way to accomplish this is to add a unique prefix during the import process:

To add content ID prefixes:

1. Set up the following value map on the first Content Server instance’s import archive:

   Input Value	Field	Output Value
   All check box	Content ID	server2_<$dDocName$>

2. Set up the following value map on the second Content Server instance’s import archive:

   Input Value	Field	Output Value
   All check box	Content ID	server1_<$dDocName$>

Changing Release Dates

In this example, you are copying archives to other Content Server instances using replication or transfer, but you want the release date on the target Content Server instance to be the date the content item was copied.

1. Set up an export and import for replication or transfer.

2. Select the archive to import in the target Content Server instance.

3. Set up the following import value map for the archive:

   Input Value	Field	Output Value
   All check box	Release Date	<$dateCurrent()$>

The release dates will reflect the local date and time of the target Content Server instance.

Configuration Migration Tips

There are several points to keep in mind when using the Configuration Migration utility.

• If you use directory locations on the target system that differ from the standard Content Server installation directories, you cannot use Configuration Migration but must do a manual copy of the pertinent directories.

  For example, if you use partitioned file systems and want to split Content Server storage on the partitions, you must add configuration variables to the DomainHome/ucm/cs/bin/intradoc.cfg file to point to the correct locations for the directories that are stored elsewhere.

• If you are using different web servers for the source and the target systems, make sure to exclude the web server information when using Configuration Migration to prepare an export.

• Not all components can be exported using the Configuration Migration utility. For example, components that require an interactive installation cannot be exported. They must be installed separately on the target system.

• Dynamic Converter rules are not transferred with the Configuration Migration utility. They must be manually added to the target system by copying the /data/conversion/cvtemplates.hda file from the source system to the target system. In addition, you should create an archive for dynamic converter templates and transfer them to the target system before transferring other content. Otherwise an error occurs when a document that is eligible for dynamic conversion is imported.

• The Configuration Migration utility is particularly useful for propagating a part of an instance to another. For example, some customization, such as workflows or content profiles, may best be designed and tested on a development instance. After they are tested they can be migrated to your production system. Other development work, such as component development, is probably best done using the Component Wizard and Component Manager for testing and deployment.

• Problems can occur when importing archives if required fields and validated option lists are not considered. If metadata fields have been changed to be required or if option lists have been altered between one migration and another, it will be difficult to import content into another system with those same metadata field definitions. To avoid this problem, temporarily change required fields to be non-required and change option lists to be non-validated before importing data on a target system.

• You can use the Configuration Migration utility with the archiver to create a regular ‘snapshot’ of your instance. You should also make sure to make appropriate backups of your databases at the same time, to ensure that the entire system stays synchronized.

• You should create a configuration migration package before creating an archive package to ensure that the appropriate metadata information is available on the importing Content Server instance.

• Remember that migration is an additive process. The exporting configuration bundle of metadata information is added to the metadata that currently exists in the importing Content Server instance. If metadata information currently exists that matches the metadata being imported, and if the Force Overwrite rule has been selected during import, then the metadata on the importing Content Server instance is overwritten by the metadata from the exported bundle.