6 Managing Site Replication

Concepts

Tasks

6.1 About Site Replication

To better understand replication, you should be aware of the terminology and processes that are involved. Because Site Studio relies on the content server's Archiver/Replicator tool to replicate the site, you can refer to the content server documentation for more information.

To replicate your site, you must perform several steps to ensure that the site works properly on the server that you are copying it to (the target server). You must prepare that server environment, configure the two servers so that they communicate with one another, set up archives on both servers, and finally, perform the actual replication.

Most of the replication features are on the Manage Site Replication page on the content server, but you can also use the Site Studio Replicator tool to customize the replication even more. Site Studio Replicator is installed with Site Studio Designer, and is a four-part wizard. For more information on the Replicator installed alongside Designer, see the User's Guide for Site Studio Designer.

When you replicate a site, you copy the site hierarchy, page templates, fragments, contributor data files, native documents, site assets, and more. The replication feature in Site Studio uses the existing replication framework in the content server (Archiver/Replicator).

6.2 Replication Process

The replication process in Site Studio includes a source server, a target server, an export archive, an import archive, and the transfer.

Figure 6-1 Replication Process

Description of Figure 6-1 follows
Description of "Figure 6-1 Replication Process"

  • Export: Native files, web-viewable files, content types, and user attributes are copied out of the source content server into an export archive.

  • Import: Files and content server information are copied from an import archive to the target content server.

  • Transfer: Content is transferred from one content server to another. This function can be used to copy content across a firewall or between two servers that do not have access to the same file system. You can also transfer archives between two content servers that have access to the same file system.

  • Replicate: Automates the export, import, and transfer steps. You can use replication to automatically export from one content server, transfer the archive to another computer, and then import to another content server.

When you replicate your site from one content server to another, the Site Studio replication feature exports the contents of your site into an export archive. The contents of this export archive is subsequently copied into an import archive which resides on the target server. The import archive is then extracted to that server so that your site can be viewed and used again on the server.

You create the export archive on the source server and an import archive on the target server. You must create the import archive on the target server first, however, so that you can point the export archive to that location when you set one up.

The replication process consists of several steps:

  1. "Configuring the Target Server for Replication"

  2. "Setting Up an Outgoing Provider on the Source Server"

  3. "Setting Up the Import Archive on the Target Server"

  4. "Setting Up the Export Archive on the Source Server"

  5. "Starting the Site Replication"

6.3 What Gets Replicated

When you use the Site Studio replication feature to replicate your site from one content server to another, the following items are included:

  • Project file (the dDocName of the project file)

  • Web site ID (where the xWebsites field contains the site ID of the site)

  • Web site sections (where the xWebsiteSection field contains the site ID of the site)

  • Fragment libraries (where the xWebsiteObjectType field contains the value "fragment")

It is important that the metadata values for xWebsites, xWebsiteSection, and xWebsiteObjectType be used correctly on your site in order for the contents of the site to be replicated.

6.4 Revisions Included

Revisions with a release date later than the most recent export date are exported. This prevents archives from exporting material that has been exported, which ensures the migration of content only once and prevents the unfettered growth in the size of the archives. Furthermore, all selected revisions of content that match the export query are exported to the archive. This works in tandem with the release date filter to ensure that the required Web site content is replicated.

6.5 Additional Export Settings

The Site Studio replication feature includes several other useful settings to ensure that your site is successfully replicated:

  • Configuration information for the content is included for administrators who plan to synchronize metadata models between two content servers. (Site Studio does not use this information.)

  • The source archive is identified as the transfer owner (the content server that initiates the transfer from the source archive to the target archive).

  • The import archive on the target server is identified as the target archive, which takes responsibility for receiving material exported and transferred from a source server and then imports the material into the target server.

6.6 Configuring the Target Server for Replication

The Site Studio replication feature copies your site from one content server to another. If it does not, however, copy the content server environment from the source server to the target server.

Before you replicate the site, you must make sure the content server environment on the target server is set up the same way as the source server (at least the parts used by your site). If you skip this step, your Web site will experience problems during the replication process.

The steps to reproduce the content server environment vary from one organization to another and from one Web site to another. As such, we offer these general guidelines.

To manually configure the target server environment, perform these steps:

  1. Recreate the metadata model used on the source server. This includes all custom metadata fields and file formats. This metadata is required for your site to operate properly. For example, checking in files generally relies on your metadata settings, and certain features on your site rely on custom metadata fields.

  2. Reinstall all components used by your site on the source server. This includes Dynamic Converter (for native documents) and Check Out and Open (to check native documents out using the contribution icon).

  3. Recreate unmanaged resources. This includes custom ActiveX controls or JSP objects that are used by your site.

  4. Recreate any additional configuration settings that you have introduced to the server. This includes anything that has changed the behavior of the server.

If you use Oracle Content Server version 7.5.2 or later (including 10gR3), you may be able to use Oracle Content Server's Configuration Migration Utility to replicate the content server environment. The next step is to set up an outgoing provider (see "Setting Up an Outgoing Provider on the Source Server").

6.7 Setting Up an Outgoing Provider on the Source Server

In Oracle Content Server, a provider is an API (Application Programming Interface) that establishes a connection between two or more content servers. To replicate a Web site, you must create an outgoing provider on the source server that establishes a connection between it and the target server.

After you configure the target server (see "Configuring the Target Server for Replication"), you are ready to set up an outgoing provider on the source server.

To set up an outgoing provider on the source server, perform these steps:

  1. Log in to the content server as an administrator.

  2. Click Providers.

    The Providers page is displayed.

  3. Under Create a New Provider, click Add beside the "outgoing" provider type.

    The Add Outgoing Provider page is displayed

  4. Enter the following information:

    • Provider Name: A name to identify the provider. The name appears in the providers list on this page (after you add one), and it becomes a subdirectory in the [CS-Dir]/data/providers on the source server.

    • Provider Description: A friendly description for the provider.

    • Provider Class: Enter intradoc.provider.SocketOutgoingProvider (the name of the Java class for outgoing providers).

    • Connection Class: Enter intradoc.provider.SocketOutgoingConnection (the name of the Java class that implements provider connections).

    • Configuration Class: May be left empty (this identifies a Java class for additional configuration settings, useful for database providers).

    • Server Host Name: The name (typically, the system name or IP address) of the target server. A socket connection is made to this host.

    • HTTP Server Address: May be left empty (this is the http address of the target server, which is not necessary for this type of connection).

    • Server Port: The port (typically, 4444) used to communicate with the target server. You can determine the port by viewing the server output when starting the content server.

    • Instance Name: The name (IDC_Name) of the target content server.

    • Relative Web Root: The relative web root for the target content server (for example, /root/) You can skip the remaining options as they are not required for this type of connection.

  5. Click Add to save the provider information and return to the Providers page. (You see your outgoing provider in the providers list.)

  6. Restart the content server.

To test the provider and make sure it was properly set up, return to the Providers page and click Test beside the outgoing provider.

In addition to setting up the outgoing provider, you may still must configure the server IP address filter on the target system so that the source server is allowed to communicate with the target server (for more information, see the Content Server documentation).

If there is a firewall in place, you must allow connections from the source server to the target server on the port defined in step 4.

The next step is to create an import archive (see "Setting Up the Import Archive on the Target Server").

6.8 Setting Up the Import Archive on the Target Server

An import archive resides on the target content server. During replication, content from an export archive (residing on a source server) is copied into the import archive. The import archive then copies the content to the target content server, thus completing the replication process.

After you set up a provider connection (see "Setting Up an Outgoing Provider on the Source Server"), you are ready to create an import archive. You create (or edit) an import archive on the Manage Site Replication page on the target server.

To set up an import archive, perform these steps:

  1. Log in to the content server as an administrator.

  2. In the Administration section, select Site Studio Administration.

    The Site Studio Administration page is displayed (see "Site Studio Administration"). If you run Oracle Content Server in the Top Menus layout, you do not see this page. Instead, all administration options are then items in the Site Studio Administration menu.

  3. Click Manage Site Replication.

    The Manage Site Replication page is displayed (see "Manage Site Replication Page").

  1. Click Add Import Archive....

    The Add Import Archive page is displayed (see "Add Import Archive Page").

    Or, if you are updating an existing import archive, select it in the list of archives and click Change Settings....

  2. Enter a name for the archive in the Archive Name field. This name appears in the list of available archives on the Manage Site Replication page. The archive name should not contain any spaces or special characters.

  3. Enter a description of the archive in the Archive Description field.

  4. To retain content that contributors assign to each region on the target site, select the Retain switched region content on target server during import check box.

    These are the areas where a contributor has switched the contributor data file or native document originally assigned to a region.

    You would typically choose to retain switched region content if you are replicating from a development server (source) to a contribution server (target), because in that scenario you want to preserve the changes made by a contributor.

    You would likely disable this option if you are replicating from a contribution server (source) to a consumption server (target), because in that scenario you want to overwrite anything that has changed on the consumption server.

  5. To retain content that contributors edit in each region on the target site, select the Retain region content on target server during import check box.

    This prevents any contributor data files and native documents from being copied from the source server to the target server, which would potentially overwrite files edited by contributors.

    You would typically choose to retain region content if you are replicating from a development server (source) to a contribution server (target), because in that scenario you want to preserve the changes made by a contributor.

    You would likely disable this option if you are replicating from a contribution server (source) to a consumption server (target), because in that scenario you want to overwrite anything that has changed on the consumption server.

  6. Click Add Archive.

    Or, if you are updating an existing import archive, click Update.

The next step is to create an export archive (see "Setting Up the Export Archive on the Source Server").

6.9 Setting Up the Export Archive on the Source Server

An export archive resides on the source content server, where it collects information from the Web site. During replication, the export archive is copied to an import archive residing on the target server. (That import archive must be created first so that you can point to it when you create the export archive.)

After you create an import archive (see "Setting Up the Import Archive on the Target Server"), you are ready to create an export archive. You create (or edit) an export archive using the Manage Site Replication page on the source server.

To set up an export archive, perform these steps:

  1. Log in to the content server as an administrator.

  2. In the Administration section, select Site Studio Administration.

    The Site Studio Administration page is displayed (see "Site Studio Administration"). If you run Oracle Content Server in the Top Menus layout, you do not see this page. Instead, all administration options are then items in the Site Studio Administration menu.

  3. Click Manage Site Replication.

    The Manage Site Replication page is displayed (see "Manage Site Replication Page").

  4. Click Add Export Archive.

    The Add Export Archive page is displayed (see "Add Export Archive Page").

    Or, if you are updating an existing export archive, select it in the list of archives and click Change Settings.

  5. Enter a name for the archive in the Archive Name field. This name appears in the list of available archives on the Manage Site Replication page. The archive name should not contain any spaces or special characters.

  6. Enter a description of the archive in the Archive Description field.

  7. Choose the Web site to replicate in the Web Site menu.

  8. Select the Include project file in export archive check box to replicate your entire site hierarchy.

    If you do not want to replicate the entire site hierarchy and instead want to replicate individual sections, then clear this check box, continue with the steps below, and then use the Site Studio Replicator tool (see the User's Guide for Site Studio Designer).

  9. For Transfer to Collection, select the collection on the target content server where this archive is copied to.

    Click Open Collection... to browse to the collection on the target server and select it.

  10. For Transfer to Archive, select the archive on the target server where this export archive is copied to (see "Setting Up the Import Archive on the Target Server").

  11. Select the Automatically export new and changed content check box if you want the replication process to be automatic whenever content on the source server changes. (If you do not enable this option, you must manually trigger the replication.)

  12. Click Add Archive.

    Or, if you are updating an existing export archive, click Update.

When you select a Web site for the export archive, Site Studio archives and replicates everything related to your site (see "What Gets Replicated"). To customize what gets archived or to add more items to the archive, you can refine the archive query directly using the Archiver applet on the content server.

The next step is to start the replication (see "Starting the Site Replication").

If you plan to use Site Studio Replicator to replicate individual sections of your site, then the next step is launch the Site Studio Replicator tool (see the User's Guide for Site Studio Designer).

6.10 Starting the Site Replication

Once you have set up an export archive (see "Setting Up the Export Archive on the Source Server"), you are ready to initiate the replication process on the source server using the Manage Site Replication page.

To replicate your Web site, perform these steps:

  1. Log in to the content server as an administrator.

  2. In the Administration section, select Site Studio Administration.

    The Site Studio Administration page is displayed (see "Site Studio Administration").

  3. Click Manage Site Replication.

    The Manage Site Replication page is displayed (see "Manage Site Replication Page").

  4. Select the desired export archive.

  5. Click Export.

If you chose to automatically export new and changed content (see "Setting Up the Export Archive on the Source Server"), then the replication process is automatic after you export the archive.

Depending on the size and complexity of your site, you should allow plenty of time for the target content server to re-index your site after the replication is complete.

6.11 Setting Up "Ready to Replicate"

Site Studio allows the contributor to change the contributor data file, or even replace it with a new file. However, the manager can step in to make sure the new contributor file is ready for replication before the page is replicated.

When Ready to Replicate is a field in the section properties for each section and home page of a Web site. The designer enables the section property in Designer. For more information on enabling Ready to Replicate in Designer, see the User's Guide for Site Studio Designer.

Once Ready to Replicate is enabled, it allows the manager to determine which sections, or even the primary or secondary pages in a section, can be replicated, and which will not. More importantly, whenever the content file for a placeholder is switched, the status of the section will change from Replicate (Figure 6-2) to Don't Replicate (Figure 6-3).

Figure 6-2 Page Marked For Replication

Contribution bar showing the page will be replicated.

Figure 6-3 Pages Marked For No Replication

Surrounding text describes Figure 6-3 .

Since contributors can switch the contributor data files, or even create a new, blank file in each case, the manager has control over the replication to ensure that some pages don't end up with blank information from the creation of a new file. Whenever someone changes the contributor data file, the page is marked as Don't Replicate, regardless of the security level of the person who made the change.

The designer can also mark a section for replication, or to prevent replication, by setting the appropriate Ready to Replicate section properties field value in Designer. However, it is expected that the manager will handle all tasks related to replication, and thus would handle the review of pages marked as Don't Replicate.