40 Managing Export, Import, Backup, and Recovery of WebCenter Portal

Oracle WebCenter Portal stores data related to its configuration and content for the various feature areas in several locations. To facilitate disaster recovery and the full production lifecycle from development through staging and production, WebCenter Portal provides a set of utilities that enable you to back up this data, move the data between WebCenter Portal applications in staging and production environments. This chapter describes the backup, import, and export capabilities and tools available. It includes the following sections:

Note:

If you want to migrate a test instance to a production instance, refer to "Moving Oracle WebCenter Portal from a Test to Production Environment" in Oracle Fusion Middleware Administrator's Guide which describes an alternative migration approach.

Audience

The content of this chapter is intended for Fusion Middleware administrators (users granted the Admin role through the Oracle WebLogic Server Administration Console). See also, Section 1.8, "Understanding Administrative Operations, Roles, and Tools".

40.1 Exporting and Importing a Spaces Application for Data Migration

Spaces provides a set of export and import utilities that enable you to back up or move content between Spaces applications and stage or production environments. This section describes how to export and import the whole Spaces application, and also individual spaces and space templates. It includes the following subsections:

Migrating an entire Spaces application:

Migrating individual spaces:

Migrating space templates:

Migrating space resources:

Migrating Wiki documents used by spaces and space templates:

40.1.1 Understanding Spaces Export and Import

Using export and import, Fusion Middleware administrators can migrate entire Spaces applications between stage and production environments. This includes every space, space template, user-defined resources, customizations (applied to the application, pages, and task flows), application and service metadata (object definitions), and other data, as outlined in Figure 40-1.

Figure 40-1 Information Exported with a Spaces Application

Information Exported with WebCenter Spaces

This migration can be performed using Fusion Middleware Control or WLST commands. For details, see:

Space and Space Template Export and Import

Spaces administrators can also export and import individual spaces and space templates, and their related objects, through Spaces Administration. Several WLST commands for migrating individual spaces and space templates are available too.

The primary purpose of these export and import features is to enable cloning and migration of data. The export and import combination enables Spaces administrators to:

  • Move spaces and space templates and related objects stored in Content Server between stage and production environments.

  • Move spaces and space templates and related objects stored in Content Server to remote instances.

For more detail, see.

Application Customizations and User Customizations

Some Spaces application customizations are optional on export, as noted in Figure 40-1. If you want to migrate application-level customizations you must set the export option "Include Customizations". For more information, reference Table 40-5, "Spaces Services - Application Customizations" and Table 40-6, "Spaces - Application Customizations" at the end of this chapter.

40.1.2 Prerequisites for Spaces Application Export and Import

The database in which the application metadata or schema is stored must be up and running for the export and import operation to work. If your application contains any Web Service data controls, all the associated Web Services must also be up and accessible for the export and import to succeed.

In addition, Oracle recommends that you migrate all the back-end components before you export or import a Spaces application. For more information, refer to the section, Section 40.1.3, "Migrating Back-end Components for an Entire Spaces Application."

Spaces is temporarily unavailable during import and export operations to prevent data conflicts. Any user who tries to login or access a Spaces page sees an "application unavailable" page.

40.1.3 Migrating Back-end Components for an Entire Spaces Application

Before migrating a Spaces application, you must migrate all the back-end components that are used by the application. This section tells you how to migrate the Identity Store, Credential Store, Policy Store, Discussions Server, Content Server, Oracle WebLogic Communications Server, and portlet producers.

The configured services in the target instance must be a superset of the services that are configured in the source instance. That is, the target must be configured with at least the same set of services that the source is configured with. If this is not the case, the import operation fails.

This section includes the following sub-sections:

**You do not have to move the LDAP policy store manually.

40.1.3.1 Exporting the LDAP Identity Store

To export users, groups, and passwords from an external identity store, use the ldapsearch command. This command creates an ldif file, which the ldapadd command uses during the import operation. The ldapsearch utility is located in the OID/IdM IDM_ORACLE_HOME/bin directory.

Example 40-1 shows the ldapsearch command for exporting an LDAP identity store. Where LDAP_OH/bin is the OID/IdM IDM_ORACLE_HOME/bin directory:

Example 40-1 ldapsearch Command to Export LDAP Identity Store

LDAP_OH/bin/ldapsearch -h ldap_hostname -p ldap_port -D  "cn=ldap_user" -w password -b "cn=users,dc=example,dc=com"
-s subtree "objectclass=*" "*" orclguid -L > my_users.ldif

When exporting users, ensure that the command includes the orclguid attribute, as shown in Example 40-1.

To migrate groups, repeat the command with appropriate group base DN. For example: -b "cn=groups,dc=example,dc=com"

For detailed syntax and examples, see "ldapsearch" and "ldapaddmt" in Oracle Identity Management User Reference.

For information on migrating an external LDAP identity store, refer to "Managing Directory Entries" and "Performing Bulk Operations" in the Oracle Fusion Middleware Administrator's Guide for Oracle Internet Directory.

Note:

To migrate users, groups, and passwords between two embedded LDAP servers, refer to "Exporting and Importing Information in the Embedded LDAP Server" in Oracle Fusion Middleware Securing Oracle WebLogic Server. Ensure that the command includes the orclguid attribute.

The source and target LDAP servers must both be the same type, that is, both embedded LDAP servers or both external LDAP servers. It is not possible, for example, to migrate users, groups, and passwords stored in an embedded LDAP server to an external LDAP server.

40.1.3.2 Importing the LDAP Identity Store

To import users and groups from another external identity store, use the ldapaddmt utility. The ldapaddmt utility is located in the OID/IdM IDM_ORACLE_HOME/bin directory.

Example 40-2 shows how to run the ldapaddmt utility to import the ldif file. Where LDAP_OH/bin is the OID/IdM IDM_ORACLE_HOME/bin directory:

Example 40-2 ldapaddmt Utility to Import the ldif File

LDAP_OH/bin/ldapaddmt -h ldap_hostname -p ldap_port -D "cn=ldap_user" -w password -c -r -f my_users.ldif

For detailed syntax and examples, see "ldapaddmt" in Oracle Identity Management User Reference.

For information on migrating the LDAP identity store, refer to "Managing Directory Entries" and "Performing Bulk Operations" in the Oracle Fusion Middleware Administrator's Guide for Oracle Internet Directory.

Note:

To import users, groups, and passwords from another embedded LDAP server, refer to "Exporting and Importing Information in the Embedded LDAP Server" in Oracle Fusion Middleware Securing Oracle WebLogic Server.

The source and target LDAP servers must both be the same type, that is, both embedded LDAP servers or both external LDAP servers. It is not possible, for example, to migrate users, groups, and passwords stored in an embedded LDAP server to an external LDAP server.

40.1.3.3 Exporting and Importing the LDAP Credential Store

To migrate your credential store to a different target, use the WLST command migrateSecurityStore. Before running this command you must specify details relating to your source credential store in a jps-config.xml file.

  1. Create your own jps-config.xml (namedjps-config-cred.xml in this example) and then specify the domain name, JPS root, and LDAP URL of the source credential store:

    1. Create a copy of your target's jps-config.xml file, located at DOMAIN_HOME/config/fmwconfig/jps-config.xml, and name the copy jps-config-cred.xml as follows:

      cp MW_HOME/user_projects/domains/my_domain/config/fmwconfig/jps-config.xml 
MW_HOME/user_projects/domains/my_domain/config/fmwconfig/jps-config-cred.xml

    2. In the jps-config-cred.xml file, duplicate the following section:

      <serviceInstance provider="ldap.credentialstore.provider" name="credstore.ldap">
  ...
</serviceInstance>

      The next few steps describes how to edit this new section to point to your source credential store. Once complete, jps-config-cred.xml file contains both source and target information for the migration process.

    3. First, change the name of the new element to indicate that it contains source information. For example, change:

      From: name="credstore.ldap."

      To: name="credstore.ldap.s"

    4. Modify the domain name, JPS root, and LDAP URL values as appropriate. For example:

      <serviceInstance provider="ldap.credentialstore.provider" name="credstore.ldap.s">
            <property value="bootstrap" name="bootstrap.security.principal.key"/>
            <property value="cn=my_domain" name="oracle.security.jps.farm.name"/>
            <property value="cn=jpsroot_webcenter_mytest_to_prod" name="oracle.security.jps.ldap.root.name"/>
            <property value="ldap:myhost:myport" name="ldap.url"/>
        </serviceInstance>

    5. You are only concerned with the credential store, therefore, modify the <jpsContext name="default"> element, removing references to the identity store and the policy store. For example:

      <jpsContext name="default">
     <serviceInstanceRef ref="keystore"/>
     <serviceInstanceRef ref="audit"/>
     <serviceInstanceRef ref="credstore.ldap"/>
</jpsContext>

    6. Duplicate the <jpsContext> element, and change the name in the new <jpsContext> element to "source". For example, change:

      From: <jpsContext name="default">

      To: <jpsContext name="source">

    7. Modify the credential store reference to point to the value specified in step c. For example:

      <jpsContext name="source">
     <serviceInstanceRef ref="keystore"/>
     <serviceInstanceRef ref="audit"/>
     <serviceInstanceRef ref="credstore.ldap.s"/>
</jpsContext>

  2. Find the name of the source folder using the ldapsearch utility.

    For example, enter:

    LDAP_OH/bin/ldapsearch -h srcldap_hostname -p ldap_port -D  "cn=ldap_user" -w password -b "" -s sub "cn=<application_name>-*"

    Where <application_name> is the name of the source application.

    The folder name returned is named: <application_name>-xxxx

    For Spaces, <application_name> is always webcenter. If, for example, the source folder is named webcenter-1646, the following information might be returned:

    cn=webcenter-1646,cn=CredentialStore,cn=my_domain, cn=JPSContext,  cn=jpsroot_webcenter_t2ptest
objectclass=top
objectclass=orclContainercn=webcenter-1646

  3. Find the name of the destination folder using the ldapsearch utility.

    For example, enter:

    LDAP_OH/bin/ldapsearch -h dstldap_hostname -p ldap_port -D  "cn=ldap_user" -w password -b "" -s sub "cn=<application_name>-*"

    Where <application_name> is the name of the destination application.

    The folder name returned is named: <application_name>-xxxx

    For Spaces, <application_name> is always webcenter.

  4. To import the credential store, run the WLST command migrateSecurityStore.

    For example (Example 40-3):

    Example 40-3 migrateSecurityStore - Credential Store

    migrateSecurityStore(type="credStore", configFile="/MW_HOME/user_projects/domains/my_domain/config/fmwconfig/jps-config-cred.xml",
src="source", dst="default")

    For detailed syntax and examples, see "migrateSecurityStore" in Oracle Fusion Middleware WebLogic Scripting Tool Command Reference.

40.1.3.4 Exporting and Importing the LDAP Policy Store

You do not need to manually migrate the policy store for a Spaces application because the export/import utilities provided for this application migrate security policy data for you. For details, see Section 40.1.4, "Exporting an Entire Spaces Application."

Oracle does not recommend that you migrate a Spaces policy store manually, but there may be circumstances where this is required. In such cases, use the WLST command migrateSecurityStore to perform the migration as described below.

Note:

For other WebCenter Portal applications, always use the migrateSecurityStore command to migrate security policy data.

Before running the migrateSecurityStore command you must specify details relating to your source policy store in a jps-config.xml file.

  1. Create your own jps-config.xml (namedjps-config-policy.xml in this example) and then specify the domain name, JPS root, and LDAP URL of the source policy store:

    1. Create a copy of your target's jps-config.xml file, located at DOMAIN_HOME/config/fmwconfig/jps-config.xml, and name the copy jps-config-policy.xml as follows:

      cp MW_HOME/user_projects/domains/my_domain/config/fmwconfig/jps-config.xml 
MW_HOME/user_projects/domains/my_domain/config/fmwconfig/jps-config-policy.xml

    2. In the jps-config-policy.xml file, duplicate the following section:

      <serviceInstance provider="ldap.policystore.provider" name="policystore.ldap">
  ...
</serviceInstance>

      The next few steps describes how to edit this new section to point to your source policy store. Once complete, jps-config-policy.xml file contains both source and target information for the migration process.

    3. First, change the name of the new element to indicate that it contains source information. For example, change:

      From: name="policystore.ldap."

      To: name="policystore.ldap.s"

    4. Modify the domain name, JPS root, and LDAP URL values as appropriate. For example:

      <serviceInstance provider="ldap.policytore.provider" name="policystore.ldap.s">
            <property value="bootstrap" name="bootstrap.security.principal.key"/>
            <property value="cn=my_domain" name="oracle.security.jps.farm.name"/>
            <property value="cn=jpsroot_webcenter_mytest_to_prod" name="oracle.security.jps.ldap.root.name"/>
            <property value="ldap:myhost:myport" name="ldap.url"/>
        </serviceInstance>

    5. Duplicate the <jpsContext> element, and change the name in the new <jpsContext> element to "source". For example, change:

      From: <jpsContext name="default">

      To: <jpsContext name="source">

    6. Modify the policy store reference to point to the value specified in step c, removing references to the identity store and the credential store. For example:

      <jpsContext name="source">
    <serviceInstanceRef ref="keystore"/>
    <serviceInstanceRef ref="audit"/>
    <serviceInstanceRef ref="policystore.ldap.s"/>
</jpsContext>

    7. Modify the <jpsContext name="default"> element, removing references to the identity store and the credential store. For example:

      <jpsContext name="default">
     <serviceInstanceRef ref="keystore"/>
     <serviceInstanceRef ref="audit"/>
     <serviceInstanceRef ref="policystore.ldap"/>
</jpsContext>

  2. Find the full name of the source application using the ldapsearch utility.

    For example, enter:

    LDAP_OH/bin/ldapsearch -h srcldap_hostname -p srcldap_port -D  "cn=ldap_user" -w password -b "" -s sub "orclapplicationcommonname=<application_name>*"

    Where <application_name> is the name of the source application.

    The application name returned is: <application_name>xxxx

    For Spaces, <application_name> is always webcenter. If, for example, the full source application name is webcenter#V2.0, the following information might be returned:

    cn=webcenter\#V2.0,cn=my_domain,cn=JPSContext,cn=jpsroot_webcenter_t2ptest
objectclass=top
objectclass=orclJavaApplicationEntity
orclapplicationcommonname=webcenter#V2.0cn=webcenter#V2.0

  3. Find the full name of the destination application using the ldapsearch utility.

    For example, enter:

    LDAP_OH/bin/ldapsearch -h dstldap_hostname -p dstldap_port -D  "cn=ldap_user" -w password -b "" -s sub "orclapplicationcommonname=<application_name>*"

    Where <application_name> is the name of the destination application.

    The application name returned is: <application_name>xxxx

    For Spaces, <application_name> is always webcenter.

  4. To import the policy store, run the WLST command migrateSecurityStore.

    For example (Example 40-4):

    Example 40-4 migrateSecurityStore - Policy Store

    migrateSecurityStore(type="appPolicies", configFile="/MW_HOME/user_projects/domains/my_domain/config/fmwconfig/jps-config-policy.xml",
src="source",dst="default",overWrite="true", srcApp="<full application name>", dstApp="<full application name>")

    For detailed syntax and examples, see "migrateSecurityStore" in Oracle Fusion Middleware WebLogic Scripting Tool Command Reference.

40.1.3.5 Exporting and Importing a File-based Credential Store

To migrate a file-based credential store to a different target, use the WLST command migrateSecurityStore. Before running this command you must specify details relating to your source credential store in the target's jps-config.xml file.

  1. Backup your target's jps-config.xml file located at DOMAIN_HOME/config/fmwconfig/jps-config.xml.

  2. Add source and target information to the target's jps-config.xml:

    1. Add the following section (above the closing </serviceInstances> tag) to point to the source credential store:

      <serviceInstance name="sourcecredstore" provider="credstoressp" location="/MW_HOME/user_projects/domains/base-domain/config/fmwconfig/.">
      <description>File Based Credential Store Service Instance</description>
</serviceInstance>

      Replace /MW_HOME/user_projects/domains/base-domain with the path to the source domain.

    2. Update the credential store reference to point to the value specified in step a. Add the following entries above the closing </jpsContexts> tag:

      <jpsContext name="targetcredstore">
      <serviceInstanceRef ref="credstore"/>
</jpsContext>
<jpsContext name="sourcecredstore">
       <serviceInstanceRef ref="sourcecredstore"/>
</jpsContext>

  3. Import the file-based credential store using the WLST command migrateSecurityStore.

    For example (Example 40-5):

    Example 40-5 migrateSecurityStore - Credential Store

    migrateSecurityStore(type="credStore", configFile="/MW_HOME/user_projects/domains/base-domain/config/fmwconfig/jps-config.xml", src="sourcecredstore", dst="targetcredstore")

    Note that the configFile parameter maps to the jps-config.xml file in the target domain, and that the src and dst parameters map to the newly created jpsContext elements.

    For detailed syntax and examples, see "migrateSecurityStore" in Oracle Fusion Middleware WebLogic Scripting Tool Command Reference.

Output similar to the following displays and includes a WARNING that you can ignore:

{srcFolder=null, preserveAppRoleGuids=null, dst=targetcredstore, type=credStore,
dstFolder=null, resourceTypeFile=null, dstLdifFile=null, srcApp=null,
configFile=/scratch/product/target/user_projects/domains/domain4/config/fmwconfig/jps-config.xml, 
dstApp=null, srcConfigFile=null, src=sourcecredstore, overWrite=null,
migrateIdStoreMapping=null, processPrivRole=null}
Oct 26, 2009 11:23:42 AM oracle.security.jps.internal.tools.utility.destination.apibased.JpsDstCredential setCredential
WARNING: Cannot migrate credential folder/key
webcenter-1111/anonymous#oracle.portlet.client.adapter.adf.ADFPortletContainerExternalConfig.Reason
oracle.security.jps.service.credstore.CredentialAlreadyExistsException:
The credential with map webcenter-1111 and key
anonymous#oracle.portlet.client.adapter.adf.ADFPortletContainerExternalConfig already exists.

40.1.3.6 Exporting and Importing a File-based Policy Store

With Spaces, there is no need for manual policy store migration because the Spaces export/import commands migrate security policy data for you. For details, see Section 40.1.4, "Exporting an Entire Spaces Application."

Oracle does not recommend that you perform policy store migration manually for Spaces but there may be circumstances where this is required. In such cases, use the WLST command migrateSecurityStore to perform the migration as described below.

Note:

For other WebCenter Portal applications, always use the migrateSecurityStore command to migrate security policy data.

Before running the migrateSecurityStore command you must specify details relating to your source policy store in your target's jps-config.xml file.

  1. Backup your target's jps-config.xml file located at DOMAIN_HOME/config/fmwconfig/jps-config.xml.

  2. Add source and target information to the target's jps-config.xml:

    1. Add the following section (above the closing </serviceInstances> tag) to point to the source policy store:

      <serviceInstance name="srcpolicystore.xml"
provider="policystore.xml.provider"
location="/MW_HOME/user_projects/domains/base_domain/config/fmwconfig/system-jazn-data.xml">
   <description>File Based Policy Store Service Instance</description></serviceInstance>

      Replace /MW_HOME/user_projects/domains/base-domain with the path to the source domain.

    2. Update the policy store reference to point to the value specified in step a. Add the following entries above the closing </jpsContexts> tag:

      <jpsContext name="targetFileStore">
     <serviceInstanceRef ref="policystore.xml"/>
</jpsContext>
<jpsContext name="sourceFileStore">
     <serviceInstanceRef ref="srcpolicystore.xml"/>
</jpsContext>

  3. Import the file-based credential store using the WLST command migrateSecurityStore.

    For example (Example 40-6):

    Example 40-6 migrateSecurityStore - Policy Store

    migrateSecurityStore(type="appPolicies", srcApp="webcenter",
configFile="/MW_HOME/user_projects/domains/base_domain/config/fmwconfig/jps-config.xml",
src="sourceFileStore", dst="targetFileStore", overWrite="true")

    Note that the configFile parameter maps to the jps-config.xml file in the target domain, and that the src and dst parameters map to the newly created jpsContext elements.

    For detailed syntax and examples, see "migrateSecurityStore" in Oracle Fusion Middleware WebLogic Scripting Tool Command Reference.

Output similar to the following displays and includes a WARNING that you can ignore:

{srcFolder=null, dst=targetFileStore, 
type=appPolicies, dstFolder=null, resourceTypeFile=null, 
dstLdifFile=null, srcApp=webcenter, 
configFile=/scratch/product/target/user_projects/domains/base_domain/config/fmwconfig/jps-config.xml, 
dstApp=null, srcConfigFile=null, src=sourceFileStore, overWrite=true, 
migrateIdStoreMapping=null, processPrivRole=null}Oct 26, 2009 4:14:42 AM
oracle.security.jps.internal.tools.utility.destination.apibased.JpsDstPolicy <init>
WARNING: No identity store associate with policy store found.
wls:/offline>

40.1.3.7 Exporting All Discussions Server Data

To export WebCenter Portal's discussions server data, use the appropriate database export utility:

  • For an Oracle database, go to ORACLE_HOME/bin of your database and then run the command described in Example 40-7.

    If you want to use the default dump directory DATA_PUMP_DIR, you can skip the initial 'create directory' step described in Example 40-7.

  • For non-Oracle databases, refer to the manufacturer's documentation.

Notes:

  • The Oracle Data Pump utility does not support LONG columns types that exist in the DISCUSSIONS schema. Therefore, Oracle recommends using Oracle Database Utilities. See also, the Oracle Database Utilities guide.

  • This section describes how to export all discussions server data. If you want to export discussions for a single space, see Section 40.1.7.1, "Exporting Discussions for a Space".

Example 40-7 Export Database Utility

sqlplus "sys/password as sysdba"
create or replace directory directory as 'path';
exit;

DB_ORACLE_HOME/bin/expdp \"sys/password@serviceid as sysdba\" directory=directory dumpfile=discussions.dmp SCHEMAS=srcrcuprefix_DISCUSSIONS EXCLUDE=STATISTICS

where:

  • DB_ORACLE_HOME is the directory in which the database for WebCenter Portal's discussion server schema is installed.

  • password is the password for the system database user.

  • serviceid is the service ID of the database connection.

  • directory is the location on the database machine where the dump file will be created.

  • DUMPFILE contains the exported data.

  • SCHEMAS is the schema to be exported. This is the RCU suffix that was used during installation, _DISCUSSIONS, along with the user supplied prefix. For example, DEV_DISCUSSIONS.

  • EXCLUDE=STATISTICS specifies not to export statistics for the tables.

40.1.3.8 Importing All Discussions Server Data

To import discussions server data, use the appropriate database import utility:

  • For an Oracle database, follow the steps below.

  • For non-Oracle databases, refer to the manufacturer's documentation.

Notes:

  • The Oracle Data Pump utility does not support LONG columns types that exist in the DISCUSSIONS schema. Therefore, Oracle recommends using Oracle Database Utilities. See also, the Oracle Database Utilities guide.

  • This section describes how to import all discussions server data. If you want to import discussions for a single space, see Section 40.1.7.2, "Importing Discussions for a Space".

  1. Shut down the target discussions server.

  2. Go to DB_ORACLE_HOME/bin of the database where WebCenter Portal's discussions server schema is installed, and connect to the database using sqlplus as sysdba:

    DB_ORACLE_HOME/bin/sqlplus "sys/password@serviceid as sysdba"

  3. Drop the target user:

    drop user tgtrcuprefix_DISCUSSIONS cascade;

  4. Create the target user:

    create user tgtrcuprefix_DISCUSSIONS identified by password default tablespace tgtrcuprefix_IAS_DISCUSSIONS temporary tablespace name_IAS_TEMP;

    where:

    • tgtrcuprefix_DISCUSSIONS is the user name. This is the RCU suffix that was used during installation, _DISCUSSIONS, along with a user supplied prefix. For example, DEV_DISCUSSIONS.

    • password is the password for the target user.

    • tgtrcuprefix_IAS_DISCUSSIONS identifies the default tablespace. For example, the RCU suffix that was used during installation, IAS_DISCUSSIONS, along with a user supplied prefix. For example, DEV_IAS_DISCUSSIONS.

    • name_IAS_TEMP identifies the temporary tablespace. For example, DEV_IAS_TEMP.

  5. Grant connect and resource to the user:

    grant connect,resource to tgtrcuprefix_DISCUSSIONS;

  6. Exit sqlplus.

  7. Run the import tool as described in Example 40-8.

    Example 40-8 Database Import Utility

    DB_ORACLE_HOME/bin/impdp \"sys/password@serviceid as sysdba\" directory=directory remap_schema=srcrcuprefix_DISCUSSIONS:tgtrcuprefix_DISCUSSIONS
remap_schema=srcrcuprefix_DISCUSSIONS_CRAWLER:tgtrcuprefix_DISCUSSIONS_CRAWLER remap_tablespace=source_tablespace:target_tablespace  
exclude=user DUMPFILE=discussions.dmp TABLE_EXISTS_ACTION=REPLACE EXCLUDE=STATISTICS

    where:

    • DB_ORACLE_HOME is the directory in which the database for WebCenter Portal's discussions server schema is installed.

    • password is the password for the system database user.

    • serviceid is the service ID of the database connection.

    • REMAP_SCHEMA identifies the source and target schemas. For example, schema names include the RCU suffix that was used during installation, _DISCUSSIONS, along with the user supplied prefix. For example, DEV_DISCUSSIONS.

    • REMAP_TABLESPACE identifies the source and target tablespace. Remaps all objects selected for import with persistent data in the source tablespace to be created in the target tablespace. For example, source_tablespace:target_tablespace.

    • DUMPFILE contains the data to be imported.

    • TABLE_EXISTS_ACTION=REPLACE drops the current table and creates the table as it is in the dump file.

    • EXCLUDE=STATISTICS Do not include this parameter with impdp if you excluded statistics during the expdp. If you do, the error "ORA-39168: Object path STATISTICS was not found" displays.

40.1.3.9 Exporting All Oracle WebCenter Content Server Data

First use Oracle Data Pump to export the Oracle WebCenter Content Server schema, and then export the native (vault) and web-viewable (weblayout) files.

Note:

This section describes how to export all Content Server data. If you want to export content for a single space, see Section 40.1.7.3, "Exporting Documents for a Space".

Note:

For non-Oracle databases, refer to the manufacturer's documentation.

  1. Export Content Server data using the Oracle Data Pump export utility.

    For example, go to ORACLE_HOME/bin of your database and run the command described in Example 40-9.

    If you want to use the default dump directory DATA_PUMP_DIR you can skip the initial 'create directory' step.

    Note:

    The Oracle Data Pump utility does not support LONG columns types that exist in the OCSERVER schema. Therefore, Oracle recommends using Oracle Database Utilities. See also, the Oracle Database Utilities guide.

    Example 40-9 Data Pump Utility (Export)

    sqlplus "sys/password as sysdba"
create or replace directory directory as 'path';
exit;

DB_ORACLE_HOME/bin/expdp \"sys/password@serviceid as sysdba\" directory=directory SCHEMAS=srcrcuprefix_OCSERVER DUMPFILE=webcentercontent.dmp EXCLUDE=STATISTICS

    where:

    • DB_ORACLE_HOME is the directory in which the database for Oracle WebCenter Content Server schema is installed.

    • password is the password for system database user.

    • serviceid is the service ID of the database connection.

    • directory is the location on the database machine, where the dump file will be created.

    • SCHEMAS is the schema to be exported. This is the RCU suffix that was used during installation, _OCSERVER, along with the user supplied prefix. For example, DEV_OCSERVER.

    • DUMPFILE contains the exported data.

    • EXCLUDE=STATISTICS specifies not to export statistics for the tables.

  2. Export the native (vault) and web-viewable (weblayout) files:

    • Vault files - Tar up the <WC_ORACLE_HOME>/ucm/vault folder on the source system. For example:

      tar cvf ucm_vault.tar WC_ORACLE_HOME/ucm/vault

    • Weblayout files - Tar up the <WC_ORACLE_HOME>/ucm/weblayout folder on the source system. For example:

      tar cvf ucm_weblayout.tar WC_ORACLE_HOME/ucm/weblayout

  3. Import the source vault and weblayout folder archives on the target system as follows:

    • Vault files - Restore the vault folder. For example:

      cd WC_ORACLE_HOME/ucm;
tar xvf ucm_vault.tar

    • Weblayout files - Restore the weblayout folder. For example:

      cd WC_ORACLE_HOME/ucm;
tar xvf ucm_weblayout.tar

40.1.3.10 Importing All Oracle WebCenter Content Server Data

First use Oracle Data Pump to import the source Oracle WebCenter Content Server schema, and then import the source vault and weblayout folder archives.

Note:

This section describes how to import all Content Server data. If you want to import content for a single space, see Section 40.1.7.4, "Importing Documents for a Space".

Note:

For non-Oracle databases, refer to the manufacturer's documentation.

  1. Shut down the target Content Server.

  2. Go to DB_ORACLE_HOME/bin of the database where Oracle WebCenter Content Server schema is installed, and connect to the database using sqlplus as sysdba:

    DB_ORACLE_HOME/bin/sqlplus "sys/password@serviceid as sysdba"

  3. Drop the target user:

    drop user tgtrcuprefix_OCSERVER cascade;

  4. Create the target user:

    create user tgtrcuprefix_OCSERVER identified by password default tablespace tgtrcuprefix_OCSERVER temporary tablespace name_IAS_TEMP;

    where:

    • tgtrcuprefix_OCSERVER is the user name. This is the RCU suffix that was used during installation, _OCSERVER, along with a user supplied prefix. For example, DEV_OCSERVER.

    • password is the password for the target user.

    • tgtrcuprefix_IAS_OCSERVER identifies the default tablespace. For example, the RCU suffix that was used during installation, IAS_OCSERVER, along with a user supplied prefix. For example, DEV_IAS_OCSERVER.

    • name_IAS_TEMP identifies the temporary tablespace. For example, DEV_IAS_TEMP.

  5. Grant connect and resource to the user:

    grant connect,resource to tgtrcuprefix_OCSERVER;

  6. Import Content Server data using the Oracle Data Pump import utility.

    For example, in DB_ORACLE_HOME/bin of your database, run the command described in Example 40-10.

    Note:

    The Oracle Data Pump utility does not support LONG columns types that exist in the OCSERVER schema. Therefore, Oracle recommends using Oracle Database Utilities. See also, the Oracle Database Utilities guide.

    Example 40-10 Data Pump Utility (Import)

    DB_ORACLE_HOME/bin/impdp \"sys/password@serviceid as sysdba\" directory=directory remap_schema=srcrcuprefix_OCSERVER:tgtrcuprefix_OCSERVER
remap_tablespace=source_tablespace:target_tablespace DUMPFILE=webcentercontent.dmp
TABLE_EXISTS_ACTION=REPLACE exclude=user

    where:

    • DB_ORACLE_HOME is the directory in which the database for the Oracle WebCenter Content Server schema is installed.

    • password is the password for system database user.

    • serviceid is the service ID of the database connection.

    • REMAP_SCHEMA identifies the source and target schemas. For example, schema names include the RCU suffix that was used during installation, _OCSERVER, along with the user supplied prefix. For example, DEV_OCSERVER.

    • REMAP_TABLESPACE identifies the source and target tablespace. Remaps all objects selected for import with persistent data in the source tablespace to be created in the target tablespace. For example, source_tablespace:target_tablespace.

    • DUMPFILE contains the data to be imported.

    • TABLE_EXISTS_ACTION=REPLACE drops the current table and creates the table as it is in the dump file.

    • exclude=user specifies not to create the user again.

  7. Import the source vault and weblayout folder archives on the target system as follows:

    • Vault files - Restore the vault folder. For example:

      cd WC_ORACLE_HOME/ucm;
tar xvf ucm_vault.tar

    • Weblayout files - Restore the weblayout folder. For example:

      cd WC_ORACLE_HOME/ucm;
tar xvf ucm_weblayout.tar

After importing the Oracle WebCenter Content Server data, log in to the Spaces application and open any imported space. Verify that the Documents service is enabled in that space and that imported folders are available as expected.

40.1.3.11 Exporting Portlet Producers

This step is only require to migrate entire producer metadata and not just the producer metadata associated with your Spaces application. For information on how to export entire producer metadata, see "How to Manage the Persistence Store for JSR 286 Portlets" and "Migrating a PDK-Java Producer Persistence Store" in Oracle Fusion Middleware Developer's Guide for Oracle WebCenter Portal.

40.1.3.12 Importing Portlet Producers

This step is only required to migrate entire producer metadata and not just the producer metadata associated with your Spaces application. For information on how to import entire producer metadata, see "How to Manage the Persistence Store for JSR 286 Portlets" and "Migrating a PDK-Java Producer Persistence Store" in Oracle Fusion Middleware Developer's Guide for Oracle WebCenter Portal.

40.1.3.13 Exporting and Importing Activity Graph and Analytics Data

The Activity Graph service stores metadata definitions for mapping WebCenter Portal service event data from Analytics in MDS. For information how to import and export Activity Graph metadata, see Section 12.6, "Managing Activity Graph Schema Customizations".

40.1.3.14 Exporting and Importing Pagelet Producer Data

The Pagelet Producer stores configuration data and content in MDS. For information how to import and export page producer metadata, see Section 25.10, "Managing Import, Export, Backup and Recovery of Pagelet Producer Components".

40.1.4 Exporting an Entire Spaces Application

This section describes how to export an entire Spaces application using Fusion Middleware Control and WLST commands. The Spaces application is exported into a single export archive (.ear file). The EAR file contains:

  • A metadata archive (.mar) file that captures metadata and data for the entire application:

    • Metadata: Metadata stored in MDS for spaces, pages, resources, global customizations, user customizations, portlets, and so on.

    • Data: Data stored in WebCenter Portal database tables for portal activity, portal events, and so on.

  • An XML file containing security policy information (policy-store.xml):

    • application roles (and permissions assigned to each role)

    • users details and their application role assignments in the Home space

    • individual space members (and their role assignments in each space)

You can save export archives to your local file system or to a remote server file system. For more information about what is exported, read Section 40.1.1, "Understanding Spaces Export and Import".

The Spaces application is temporarily unavailable during import and export operations to prevent data conflicts. Any user who tries to login or access a Spaces page sees an "application unavailable" page.

The export process does not include data associated with external services, that is, Analytics, Activity Graph, Announcements, Discussions, Documents, Instant Messaging and Presence (IMP), Mail, Pagelets, Personal Events, Personalizations, and Worklists. To learn how to move data associated with these services, see Section 40.1.3, "Migrating Back-end Components for an Entire Spaces Application."

The users in both the export and import environment must be identical. If a shared identity store is not used, then these users must also be migrated. Refer to Section 40.1.3.1, "Exporting the LDAP Identity Store" and Section 40.1.3.2, "Importing the LDAP Identity Store."

Note:

Only application artifacts located in the content directory are exported. For example, icons and images, and so on, associated with a page template must be placed in the page template's content directory to be exported. For more information, see "What You Should Know About a Resource's Properties" in the Oracle Fusion Middleware User's Guide for Oracle WebCenter Portal: Spaces.

Out-of-the-box templates and user customizations are never exported.

This section includes the following:

40.1.4.1 Exporting the Spaces Application Using Fusion Middleware Control

Fusion Middleware administrators can export an entire Spaces application using Fusion Middleware Control.

To export the Spaces application:

  1. In Fusion Middleware Control, navigate to the home page for Spaces.

    See Section 6.2, "Navigating to the Home Page for the Spaces Application."

  2. From the WebCenter Portal menu, select Application Export, as shown in Figure 40-2.

    Figure 40-2 WebCenter Portal Menu - Application Export Option

    WebCenter menu - Application Export option
    Description of "Figure 40-2 WebCenter Portal Menu - Application Export Option"

  3. Change the File Name for the export archive or accept the default name.

    To ensure uniqueness, the default .ear filename contains a timestamp: webcenter_wholeapp_ts_timestamp.ear, as shown in Figure 40-3.

    Figure 40-3 Naming the Export Archive

    Select the Archive to be Exported
    Description of "Figure 40-3 Naming the Export Archive"

  4. Set export options as required. For details, see Table 40-1.

    Table 40-1 Spaces Application Export Options

    Field Description

    Include Services Data

    Select to export data stored in the WebCenter Portal repository for the following services: Activity Streams, Events, Feedback, Lists, Links, Message Boards, Connections, and Profiles. Notes data stored in the MDS repository is exported too.

    Always re-export list data if source and target list definitions do not match. Mis-match only occurs when a list definition exists on the target and it is subsequently changed in the source.

    If the application selected for export contains a large amount of data, consider using the database export utilities to export (and import) the WebCenter Portal schema data instead. For example, run the following commands from ORACLE_HOME/bin for the WebCenter Portal database:

    DB_ORACLE_HOME/bin/expdp \"sys/password@serviceid as sysdba\" 
OWNER=srcrcuprefix_WEBCENTER FILE=webcenter.dmp STATISTICS=none

    DB_ORACLE_HOME/bin/impdp \"sys/password@serviceid as sysdba\" directory=directory 
remap_schema=srcprefix_WEBCENTER:tgtprefix_WEBCENTER 
remap_tablespace=source_tablespace:target_tablespace 
DUMPFILE=webcenter.dmp TABLE_EXISTS_ACTION=REPLACE exclude=user

    For details, refer to the Oracle Database Utilities guide.

    Deselect this option if you do not want to export any data associated with lists, events, tags, links, connections, profiles, message boards, activity streams, and feedback. For example, when moving an application from a test environment to a stage or production environment the test data may no longer be required.

    Note: The export process does not export data associated with other external services such as Mail, Discussions, Announcements, Worklists, Instant Messaging and Presence (IMP), Personal Events, and Documents. To learn how to move data associated with these services, see documentation for that product. See also, Section 40.1.3, "Migrating Back-end Components for an Entire Spaces Application."

    Include Customizations

    Select to export application customizations. For information about which application customizations are optional on export, see Table 40-5 and Table 40-6.

    If you deselect this option, the Spaces application is exported without these application customizations.

    Portlet and page customizations are always exported. See also Figure 40-1, "Information Exported with a Spaces Application".

  5. Click Export.

  6. In the Download dialog, as shown in Figure 40-4, click Export to confirm that you want to go ahead.

    Figure 40-4 Downloading an Export Archive

    Download
    Description of "Figure 40-4 Downloading an Export Archive"

    Progress information is displayed during the export process. The application being exported cannot be accessed during export operations.

  7. When the export process is complete, specify a location for the export archive (.ear).

    Figure 40-5 Saving an Export Archive

    Download
    Description of "Figure 40-5 Saving an Export Archive"

    Select one of:

    • Download - Saves the export EAR file to your local file system.

      Your Browser downloads and saves the archive locally. The actual download location depends on your Browser set up.

    • Save to Server - Saves the export EAR file to a server location.

      When the Archive Location dialog box displays (Figure 40-6), enter a suitable path for Server Location, for example, /tmp, and then click Save. The name of the EAR is not required here.

      Ensure that the server directory you specify has write permissions.

      Figure 40-6 Archive Location

      Download
      Description of "Figure 40-6 Archive Location"

  8. Click Close to dismiss the Export window.

The export archive (.EAR) is saved to the specified location.

Check the diagnostic log file, WC_Spaces-diagnostic.log, for any warnings or errors reported during the export process. To view the log file, select the menu option WebCenter > Logs > View Log Messages. For details, see Section 34.3, "Viewing and Configuring Log Information". See also Section 40.4, "Troubleshooting Import and Export Issues for Spaces."

40.1.4.2 Exporting the Spaces Application Using WLST

Use the WLST command exportWebCenterApplication to export the Spaces application. For command syntax and examples, see "exportWebCenterApplication" in the Oracle Fusion Middleware WebLogic Scripting Tool Command Reference.

The Spaces application is temporarily unavailable during export operations to prevent data conflicts. Any user who tries to login or access a Spaces page sees an "application unavailable" page.

For information on how to run WLST commands, see Section 1.13.3.1, "Running Oracle WebLogic Scripting Tool (WLST) Commands."

40.1.5 Importing an Entire Spaces Application

This section describes how to import an entire Spaces application using Fusion Middleware Control and WLST commands.

Before importing the Spaces application:

  • Migrate back-end components for the application, such as the LDAP identity store, credential store, policy store, discussions server, content server, Oracle WebLogic Communications Server, portlet producers, and so on. See Section 40.1.3, "Migrating Back-end Components for an Entire Spaces Application."

    Personal pages, that is, pages users create in the Home space, are only migrated if the target and source applications both use the same LDAP identity store; this is because personal page assignments are per user GUID.

  • Oracle also recommends that you backup the database schema, WebCenter Portal repository, MDS, and your policy store. See Section 40.3, "Backing Up and Recovering WebCenter Portal Applications."

  • Check that all users assigned to the Administrator role exist in the target identity store. On import, users listed in the Spaces security policy are checked against the identity store that is configured for the domain. If a user is not found, any policies associated with that user are removed. See also, Section 30.4, "Moving the Administrator Account to an External LDAP Server."

  • Confirm that the Spaces archive (.ear) that you want to import was exported from WebCenter Spaces 11.1.1.4.0 or later. You cannot import archives from earlier versions (such as 11.1.1.2.0 or 11.1.1.3.0) directly into WebCenter Portal: Spaces 11.1.1.7.0. If necessary, you must upgrade your source environment to 11.1.1.4.0 or above (Oracle recommends 11.1.1.7.0) before you create the export archive. For details, "Patching Oracle WebCenter" in Oracle Fusion Middleware Patching Guide.

    You cannot import archives generated from WebCenter Portal: Spaces 11.1.1.7.0 to target environments earlier than 11.1.1.7.0.

The Spaces application is temporarily unavailable during import and export operations to prevent data conflicts. Any user who tries to login or access a Spaces page sees an "application unavailable" page.

This section includes the following:

40.1.5.1 Importing a Spaces Application Using Fusion Middleware Control

Fusion Middleware administrators can import an entire WebCenter application using Fusion Middleware Control.

To import a Spaces application using Fusion Middleware Control:

  1. In Fusion Middleware Control, navigate to the home page for Spaces.

    See Section 6.2, "Navigating to the Home Page for the Spaces Application."

  2. From the WebCenter Portal menu, select Application Import.

  3. In the Spaces Application Import page (Figure 40-7), specify the location of your Spaces application archive (.ear). Select one of the following:

    • Archive Located on Local File System - Enter the Archive Location. Alternatively, click Browse to locate the directory on the local file system where the .ear file is stored.

    • Archive Located on Server File System - Enter the Archive Location. Any shared location accessible from this Spaces application.

    The archive you select must contain an entire Spaces application export—you cannot import individual spaces from here. Refer to "Exporting and Importing Spaces and Space Templates" in the Oracle Fusion Middleware User's Guide for Oracle WebCenter Portal: Spacesfor more information.

    Figure 40-7 Spaces Application Import Page

    WebCenter Spaces Application Import page
    Description of "Figure 40-7 Spaces Application Import Page"

  4. Click Import.

  5. In the Spaces Application Import dialog (Figure 40-8), click Import.

    Figure 40-8 Spaces Application Import dialog

    WebCenter Spaces Application Import dialog
    Description of "Figure 40-8 Spaces Application Import dialog"

    Once the import is complete, a success message displays.

After importing an entire Spaces application, log in and verify the application. For details, see Section 40.1.5.3, "Verify an Imported Spaces Application".

40.1.5.2 Importing a Spaces Application Using WLST

Use the WLST command importWebCenterApplication to import a Spaces application. For command syntax and examples, see "importWebCenterApplication" in the Oracle Fusion Middleware WebLogic Scripting Tool Command Reference.

For information on how to run WLST commands, see Section 1.13.3.1, "Running Oracle WebLogic Scripting Tool (WLST) Commands."

Note:

After importing an entire Spaces application, log in and verify the application. For details, see Section 40.1.5.3, "Verify an Imported Spaces Application".

40.1.5.3 Verify an Imported Spaces Application

After importing an entire Spaces application you must:

  1. Restart the managed server on which the newly imported Spaces application is deployed.

    In a cluster environment, restart each managed server in the cluster. See also, Section 8.2, "Starting and Stopping Managed Servers for WebCenter Portal Application Deployments."

  2. Log in to the Spaces application and verify that all spaces and space templates are available as expected.

    If not, see Section 40.4.2, "Spaces and Space Templates Not Available After Import".

  3. Initiate the Oracle Secure Enterprise Search crawler to index newly imported data.

    See also, Oracle Secure Enterprise Search Administrator's Guide.

40.1.6 Prerequisites for Individual Space Export and Import

To export one or more spaces, the Spaces application that contains the spaces must be up and running, and all the spaces you want to export must be offline to prevent data conflicts. For details, see, "Taking Any Space Offline" in the Oracle Fusion Middleware User's Guide for Oracle WebCenter Portal: Spaces. If a space contains Web Service data controls or portlets, all associated Web Services or producers must also be up and accessible for the export and import to succeed.

Space-related data associated with some back-end components, specifically the discussions server, must be migrated after you export or import spaces. See next section, Section 40.1.7, "Migrating Back-end Components for Individual Spaces."

Note:

The simultaneous export or import of large numbers of spaces is not recommended as, depending on server configuration, it may affect system performance. If a serious deterioration in performance is observed, break-down the export or import into several smaller groups.

40.1.7 Migrating Back-end Components for Individual Spaces

When migrating one or more spaces, you must also migrate the back-end components used by the space. This section tells you how.

This section includes the following sub sections:

You must import the spaces on to the target before importing these back-end components.

40.1.7.1 Exporting Discussions for a Space

Use the Discussions Server Admin Console to export discussions associated with a particular space.

Space discussions are exported to an .xml file, and saved to a .zip file in the DOMAIN_HOME/config/fmwconfig/servers/<target_server_name>/owc_discussions/data/ directory.

Where DOMAIN_HOME is the path to the Oracle WebLogic Server domain. For example, MW_HOME/user_projects/domains/my_domain/config/fmwconfig/servers/WC_Collaboration/owc_discussions/data/.

To export discussions for a space:

  1. Login to the Discussions Server Admin Console.

    You can login directly if you know the console's URL. For example: http://example.com:8890/owc_discussions/admin

    Alternatively, login through Spaces as follows:

    1. Login to Spaces with administrative privileges, and open the Spaces administration pages.

      See "Accessing Spaces Administration Pages" in the Oracle Fusion Middleware User's Guide for Oracle WebCenter Portal: Spaces.

    2. Click Spaces.

    3. Select the space you want to export, then select Edit Space from the Edit menu.

    4. Click Services, then Discussions.

    5. Note down the Forum Name/ID or Category Name/ID associated with this Space.

      WebCenter Portal's discussions server generates discussion category and forum IDs sequentially. If this ID exists on the target system, the imported forum (or category) will be assigned a new, unique ID, and therefore you must reconfigure the imported space, to point to the new ID. For details, see Section 40.1.9.1, "Importing Individual Spaces Using the Spaces Application" - Step 11.

    6. Click Forum Administration, and login to the Admin Console.

  2. In the Admin Console, select the System menu and select XML Export & Import in the sidebar.

  3. Select Data Export.

  4. Set the following options (Figure 40-9):

    1. Export Options - Select Custom Options, and select all the check boxes.

    2. Export Content - Select Export Specific Content, and select the name of the forum or category required.

      Note: Spaces that support multiple forums use a category to store discussions. Other spaces use a single forum.

    3. Export location, Export filename, Export file encoding - Keep the default values.

    Figure 40-9 Exporting Discussions for an Individual Space

    Exporting Discussions for an Individual Space

  5. Click Start Export.

  6. Once complete, copy the .zip file (that contains the export .xml file) from the MW_HOME/user_projects/domains/my_domain/config/fmwconfig/servers/<server_name>/owc_discussions/data directory to same location on the target discussions server.

    For example, MW_HOME/user_projects/domains/my_domain/config/fmwconfig/servers/WC_Collaboration/owc_discussions/data.

Before importing space discussions on the target system, the space you are migrating must exist on the target. See Section 40.1.9.1, "Importing Individual Spaces Using the Spaces Application."

40.1.7.2 Importing Discussions for a Space

Use the Discussions Server Admin Console to import discussions exported from another WebCenter Spaces application.

Ensure that the associated space exists on the target before you import the discussion data. See Section 40.1.9.1, "Importing Individual Spaces Using the Spaces Application."

Note:

WebCenter Portal's Discussions Server generates discussion category and forum IDs sequentially. Therefore, when importing discussion data between two targets (or source to target), there is a chance that the same IDs exist on both systems. When ID clashes occur, the imported forum (or category) is assigned a new, unique ID and therefore you must reconfigure the space to point to the new ID. See Step 11 below for details.

To import discussions for a particular space:

  1. Log into the Discussions Server Admin Console.

    You can login directly if you know the console's URL. For example: http://example.com:8890/owc_discussions/admin

    Alternatively, log in through Spaces as follows:

    1. Log into Spaces with administrative privileges, and open the Spaces administration pages.

      See "Accessing Spaces Administration Pages" in the Oracle Fusion Middleware User's Guide for Oracle WebCenter Portal: Spaces.

    2. Click Spaces.

    3. Select the space for which you want to import data, and then select Edit Space from the Edit menu.

    4. Click Services, then Discussions.

    5. Click Forum Administration (on the far right), and log into the Admin Console.

  2. In the Admin Console, select the System menu, and then select XML Export & Import in the sidebar.

  3. Select Data Import.

  4. Select the appropriate space export file from the list available (Figure 40-10).

    If the file you want is not listed, copy the export .zip file from the source directory DOMAIN_HOME/config/fmwconfig/servers/<target_server_name>/owc_discussions/data/ to same location on this target. See also, Section 40.1.7.1, "Exporting Discussions for a Space."

    Where DOMAIN_HOME is the path to the Oracle WebLogic Server domain. For example, MW_HOME/user_projects/domains/my_domain/config/fmwconfig/servers/WC_Collaboration/owc_discussions/data/.

    Figure 40-10 Importing Discussions for a Space

    Importing Discussions for a Space

  5. Click Start Import.

    On import, the discussions data is copied to the discussions server. In the next step you reassociate the space you migrated earlier with this newly imported data.

  6. Select the Content menu, and then select Content Summary in the sidebar.

    All the categories and forums in the system are listed here.

  7. Select WebCenter, and then click the Move button for the newly imported forum or category.

  8. Select the root category for the target Spaces application, and click Move Categories.

    The Category Summary page shows the new location.

  9. Click Permissions in the sidebar.

  10. Deselect all the permissions for the User Types: Anyone and Registered Users, and click Save Changes (Figure 40-11).

    Figure 40-11 Editing Forum Permissions

    Editing Forum Permissions

  11. In the Spaces application, navigate to the space's Discussions Forum Settings tab, to reassociate the space with the discussion data that you just imported:

    1. Log into Spaces with administrative privileges.

      See "Accessing Spaces Administration Pages" in the Oracle Fusion Middleware User's Guide for Oracle WebCenter Portal: Spaces.

    2. Open Spaces Administration.

    3. Click Spaces.

    4. Select the space for which you want to import data, and then select Edit Space from the Edit menu.

    5. Click Services, then Discussions.

    6. Click the Search icon besides Category ID or Forum ID, and select the imported category (or forum) from the list.

    7. Click Apply.

40.1.7.3 Exporting Documents for a Space

You are not required to export space-related documents (including wikis and blogs) before you export a space because the documents remain in the source content repository. After migrating your space to another Spaces application, use WebCenter Portal's Document Migration Utility to export documents from the source space and import them to the new target space. For detailed steps, see Section 40.1.7.5, "Exporting/Importing Space Documents using the Document Migration Utility."

Note:

Oracle recommends that you use WebCenter Portal's Document Migration Utility rather than WebCenter Content's migration tools to move WebCenter Portal documents from one Content Server instance to another.

40.1.7.4 Importing Documents for a Space

Use any of the following methods to import documents (including wikis and blogs) into a space:

  • In the Spaces application, open the space, and on the Documents page or in a Document Manager, Document Explorer, or Folder Viewer task flow, use the Upload action to import one or more files at a time, as described in "Uploading New Files" in Oracle Fusion Middleware User's Guide for Oracle WebCenter Portal: Spaces.

  • When the content repository is Oracle WebCenter Content Server:

    • Use WebCenter Portal's Document Migration Utility, as described in Section 40.1.7.5, "Exporting/Importing Space Documents using the Document Migration Utility".

      Use this utility to migrate all files/folders stored for one or more spaces on Oracle WebCenter Content Server. When you migrate documents using this utility, most document metadata, including whether the file is a wiki or a blog, is preserved.

    • Use WebDAV, which is installed with Oracle WebCenter Content Server out-of-the-box, to drag and drop content from the folder belonging to the original space in your Content Server repository to the empty folder assigned to the target space. When dragging and dropping content to the target system, do not drag the original space's source folder to the target; drag and drop only the content that is stored under the space's folder.

      If you do not know the WebDAV URL for the Content Server that is used to store documents, contact your Fusion Middleware Administrator. If the base URL for that Content Server is http://host:port/relative_web_root, the WebDAV root URL is http://host:port/relative_web_root/idcplg/webdav.

      Note:

      Depending on the WebDAV client you use, all properties may not be copied over (for example, document descriptions, checkin and checkout status, and versions may not be carried across).

      Specifically, do not use WebDAV if your space contains wikis/blogs. WebDav does not maintain custom metadata, so wikis/blogs are imported as HTML documents and appear broken in the target.

    Oracle recommends that you use WebCenter Portal's Document Migration Utility or WebDAV rather than WebCenter Content's migration tools to move WebCenter Portal documents from one Content Server instance to another.

40.1.7.5 Exporting/Importing Space Documents using the Document Migration Utility

You can migrate all files and folders stored for a specific space (or a set of spaces) using WebCenter Portal's Document Migration Utility. You can use the same utility to migrate documents stored for space templates. There are three distinct phases to document migration:

  • First phase: Space migration to new target
    On import, the Documents service is enabled or disabled in the target to match that of the source. If the Documents service is enabled in the source, a folder is created on the target Oracle WebCenter Content Server for the space (or space template) and appropriate content server permissions are granted to users and groups with access to the space/space template.

  • Second phase: Document export
    When you export document content for a space (or space template), the current version of all the files/folders stored for the space on Oracle WebCenter Content Server are included in the export archive.

  • Third phase: Document import to new target
    On import the exact hierarchical structure of the files/folders is maintained. Metadata for the files/folders is also maintained wherever possible. Specifically, this means that wiki and blogs appear as wiki/blogs on the target.

This section describes the second/third phases. For information on the first phase (space/space template migration), see  Section 40.1, "Exporting and Importing a Spaces Application for Data Migration." The Document Migration Utility exports space/space template documents into an archive which the utility can subsequently use to import the archived documents into the target.

The following information is not included in the export archive:

  • Home space content

  • Version history - Only the current revision is migrated

  • Renditions - Renditions are recreated on import, as per settings on the target

  • Original create dates - Create dates for all documents/folders reset to the date and time the documents are imported

  • Unknown doctypes - Doctypes that do not exist on the target are set to the default doctype for the target

  • Comments on documents - Comments that users enter about documents while working the Spaces application are stored with activity stream data, not as document metadata.

  • Links to documents - Links that users create to documents are stored with link data, not as document metadata.

40.1.7.5.1 Properties Required to Run the Document Migration Utility

Table 40-2 describes the properties required to run the Document Migration Utility. For information on how to run the utility, see Section 40.1.7.5.2, "Migrating Content Using the Document Migration Utility."

Table 40-2 Document Migration Properties

Property Description Requirement

Usage

Specifies whether you want to import or export content to a file. Options are: import and export

Export and Import

MDSConn

Specifies MDS JDBC connection in the format:

jdbc:oracle:thin:@host:port:SID or

jdbc:oracle:thin:@host:port/ServiceName

Export

MDSUser

Specifies the MDS user name used by the Spaces application

Export

MDSPwd

Specifies password for the MDS user. Only include to avoid password prompt.

Export

ExportScopes

Specifies the internal name of each space/space template with content to export. Separate multiple space/template names with a comma. Prefix space template names with spacetemplate/<template_internal_name>. Ensure there are no spaces in the comma separated list.

You can obtain internal names from the About Space and About Space Template dialogs. Do not enter display names here.

Export

UCMConn

Specifies Content Server URL in the format: idc://host:intradocPort

When usage=export, specify the URL of the Content Server instance from which content is to be exported.

When usage=import, specify the URL of the Content Server instance to which the content is to be imported.

Export and Import

UCMUser

Specifies the Content Server user name used to connect through RIDC. This user must have sufficient privileges to perform the export or import; either a user defined in an external identity store or the Content Server administrator sysadmin.

Export and Import

UCMPwd

Specifies password for the Content Server user. Only include to avoid password prompt.

Export and Import

TmpDirPath

Optional. Temporary location for data extraction. If not specified, defaults to the system tmp directory.

Export and Import

ArchivePath

Document archive location.

Export and Import

ArchiveName

Optional. Name for the document archive (.zip). Default is docsexport.zip.

Export and Import

Note:

For the Document Migration Utility to work, the Auto Number Prefix configured for the source Content Server must be different to the prefix in the target. Oracle recommends that you verify both Auto Number Prefix values before running the utility. If there is a clash, content import fails and a message similar to this displays:

oracle.stellent.ridc.protocol.ServiceException: Content item 'VM2_000410' was not successfully checked in. The content item is not currently checked out.
 at 
oracle.stellent.ridc.protocol.ServiceResponse.getResponseAsBinder(ServiceResponse.java:142)
40.1.7.5.2 Migrating Content Using the Document Migration Utility

To migrate documents for one or more spaces (or space templates), you can use any of the following methods:

What You Should Do/Know Before Migrating Content: 

  1. Migrate the required spaces/space templates to the target application.

    For details, see Section 40.1.9, "Importing Individual Spaces" or Section 40.1.12, "Importing Space Templates".

  2. Navigate to: WEBCENTER_ORACLE_HOME/webcenter/archives

    This directory contains the Document Migration Utility, content-migration-tool.jar.

When exporting documents, remember that a document archive (.zip) is created at the location you specify in the archivePath property.

When importing documents, the document content in the export archive (specified as the archivePath property) is uploaded to the target Content Server. To verify this, log in to the Spaces application, navigate to the space (or space template) and verify that the imported content is available as expected.

Specifying Document Migration Properties in a Properties File 

  1. Create a properties file containing all the properties required for your export/import. See Table 40-2 for a description of all the properties.

    1. Copy and paste the following properties file into Notepad or another suitable text editor, then edit according to your environment:

      # Document migration properties for one or more spaces.

# Specify whether you want to export content to a file or 
# import content from an archive to another content repository
# valid values: export | import
Usage=export

# Specify connection details for Oracle WebCenter Content repository:
#   UCMConn - Content Server URL. Format: idc://host:intradocPort
#   UCMUser - Content Server user name used to connect through RIDC
#   UCMPwd  - Password for UCMUser. Only include to avoid password prompt
# Required for: Export and Import

UCMConn=idc://mycontentserver.mycompany.com:9444
UCMUser=<enter Content Server admin user name here>
#UCMPwd=<enter password for UCMUser here>

# Specify a temp directory and name/location for the export archive
#   TmpDirPath  -Optional. Temporary location for data extraction. 
#                If not specified, defaults to the system temporary directory.
#   ArchiveName -Optional. Name for the document archive (.zip). 
#                Default is docsexport.zip.
#   ArchivePath -Document archive location
# Required for: Export and Import

TmpDirPath=/scratch/user1/migrateMySpaceDocs/tmpdir
ArchivePath=/scratch/user1/migrateMySpaceDocs/output
ArchiveName=myspacedocs.zip

# Specify MDS details (export only)
#   MDSConn - MDS JDBC connection. Format:
#                jdbc:oracle:thin:@host:port:SID   or
#                jdbc:oracle:thin:@host:port/ServiceName
#   MDSUser - MDS schema user name used by the Spaces application
#   MDSPwd = Password for MDSUser. Only include to avoid password prompt
# Required for: Export

MDSConn=jdbc:oracle:thin:@mymdshost.mycompany.com:1521:wkcdb01
MDSUser=<enter MDS user name here>
#MDSPwd=<enter password for MDSUser here>

# Specify the internal name of each space/space template with content to export.
# Seperate multiple space/template names with a comma. 
# Use internal names only. Do not enter display names.
# Obtain internal names from "About Space" and "About Space Template" dialogs.
# Prefix space template names with 'spacetemplate/<template_internal_name>'
# as indicated in the example.
# Required for: Export

ExportScopes=MySpace1,MySpace2,spacetemplate/MySpaceTemplate

    2. Save the file. For example, save as myMigrationProperties.properties or similar.

  2. Navigate to the WEBCENTER_ORACLE_HOME/webcenter/archives directory in which the Document Migration Utility, content-migration-tool.jar is located.

  3. Run the Document Migration Utility by specifying the absolute path to your document migration properties file on the command line (Example 40-11):

    java -jar content-migration-tool.jar <absolute_path_to_migrationPropertiesFilename>

    Optionally, specify logging settings using the java.util.logging.config.file parameter as described in Section 40.1.7.5.3, "Running the Document Migration Utility with Additional Logging."

    Example 40-11 Specifying Document Migration Properties in a Properties File

    java -jar content-migration-tool.jar /home/user1/myMigrationProperties.properties

Running the Document Migration Utility with the following settings:
  Usage            = export
  UCM Connection   = idc://mycontentserver.mycompany.com:9444
  UCM User         = sysadmin
  Archive fullname = /scratch/user1/migrateMySpaceDocs/output/myspacedocs.zip
  Scopes to Export = [mySalesSpace,spacetemplate/SalesTemplate]
  MDS Connection   = jdbc:oracle:thin:@mymdshost.mycompany.com:1521:wkcdb01
  MDS User         = user1_mds
Setting up MDS connection
Connection to MDS created successfully

Specifying Document Migration Properties on the Command Line 

  1. Navigate to the WEBCENTER_ORACLE_HOME/webcenter/archives directory in which the Document Migration Utility, content-migration-tool.jar is located.

  2. Run the Document Migration Utility by specifying individual properties on the command line:

    To export content:

    java -jar content-migration.jar Usage UCMConn UCMUser TmpDirPath ArchivePath ArchiveName MDSConn MDSUser ExportScopes [UCMPwd MDSPwd]

    To import content:

    java -jar content-migration.jar Usage UCMConn UCMUser TmpDirPath ArchvePath ArchiveName [UCMPwd]

    Note: You can, optionally, specify the UCMPwd and MDSPwd parameters on the command line. If you do not do so, you are prompted to provide them.

    Optionally, specify logging settings using the java.util.logging.config.file parameter, as described in Section 40.1.7.5.3, "Running the Document Migration Utility with Additional Logging."

    Example 40-12 exports a space called MySalesSpace and a space template called SalesTemplate.

    Example 40-12 Specifying Document Migration Properties on the Command Line For an Export

    java -jar content-migration-tool.jar export idc://mycontentserver.mycompany.com:9444
sysadmin /scratch/user1/migrateMySpaceDocs/tmpdir
/scratch/user1/migrateMySpaceDocs/output/myspacedocs.zip
jdbc:oracle:thin:@mymdshost.mycompany.com:1521:wkcdb01 user1_mds
[mySalesSpace, spacetemplate/SalesTemplate] mypassword mypassword

Running the Document Migration Utility with the following settings:
  Usage            = export
  UCM Connection   = idc://mycontentserver.mycompany.com:9444
  UCM User         = sysadmin
  Archive fullname = /scratch/user1/migrateMySpaceDocs/output/myspacedocs.zip
  Scopes to Export = [mySalesSpace,spacetemplate/SalesTemplate]
  MDS Connection   = jdbc:oracle:thin:@mymdshost.mycompany.com:1521:wkcdb01
  MDS User         = user1_mds
Setting up MDS connection
INFO: Export completed successfully. Export archive located at /scratch/user1/migrateMySpaceDocs/output/myspacedocs.zip

Specifying Document Migration Properties on the Command Line When Prompted 

  1. Navigate to the WEBCENTER_ORACLE_HOME/webcenter/archives directory in which the Document Migration Utility, content-migration-tool.jar is located.

  2. Run the Document Migration Utility by specifying the properties on the command line when prompted:

    java -jar content-migration.jar

    Optionally, specify logging settings using the java.util.logging.config.file parameter, as described in Section 40.1.7.5.3, "Running the Document Migration Utility with Additional Logging."

    Example 40-13 exports a space called MySalesSpace and a space template called SalesTemplate.

    Example 40-13 Specifying Document Migration Properties on the Command Line When Prompted

    java -jar content-migration-tool.jar

Enter the usage ('export' or 'import'): export
Enter UCM Connection (idc://<host name>:<socket port>):
idc://mycontentserver.mycompany.com:9444
Enter UCM User: sysadmin
Enter UCM Password: mypassword
Enter the full path to the temporary directory:
/scratch/user1/migrateMySpaceDocs/tmpdir
Enter path to the directory where the export archive is to be created:
/scratch/user1/migrateMySpaceDocs/output/
Enter the name of the export archive to create (default = docsexport.zip):
myspacedocs.zip
Enter MDS Spaces Data Source Connection (jdbc:oracle:thin:@<host name>:<jdbc port>:<SID>): jdbc:oracle:thin:@mymdshost.mycompany.com:1521:wkcdb01
Enter MDS Spaces Data Source User: user1_mds
Enter MDS Spaces Data Source Password: mypassword
Enter a comma separated list of scopes to export:
[mySalesSpace, spacetemplate/SalesTemplate]
Running Document Migration Utility with the following settings:
  Usage            = export
  UCM Connection   = idc://mycontentserver.mycompany.com:9444
  UCM User         = sysadmin
  Archive fullname = /scratch/user1/migrateMySpaceDocs/output/myspacedocs.zip
  Scopes to Export = [mySalesSpace,spacetemplate/SalesTemplate]
  MDS Connection   = jdbc:oracle:thin:@mymdshost.mycompany.com:1521:wkcdb01
  MDS User         = user1_mds
Setting up MDS connection
INFO: Export completed successfully. Export archive located at
/scratch/user1/migrateMySpaceDocs/output/myspacedocs.zip
40.1.7.5.3 Running the Document Migration Utility with Additional Logging

You can optionally run the Document Migration Utility with additional logging using the java.util.logging.config.file parameter as follows:

java -Djava.util.logging.config.file=<absolute_path_to_logging_properties_file> -jar content-migration-tool.jar <migrationProperties>

Note: The java.util.logging.config.file parameter must be specified immediately after the java command and before -jar.

Where the logging_properties_file includes settings such as:

handlers=java.util.logging.ConsoleHandler.level=INFO
java.util.logging.ConsoleHandler.level=FINER
java.util.logging.ConsoleHandler.formatter=java.util.logging.SimpleFormatter
oracle.webcenter.doclib.level=INFO

40.1.8 Exporting Individual Spaces

Administrators can export one or more spaces from Spaces Administration pages or using WLST commands.

Space information is exported into a single export archive (.ear file). The EAR file contains a metadata archive (.mar file) and a single XML file containing the security policy information. You can save export space archives to your local file system or to a remote server file system.

For more information about what is exported, see Section 40.1.1, "Understanding Spaces Export and Import."

The export process does not include data associated with external services, such as, Discussions, Announcements, and Documents. To learn how to move data associated with these services, see Section 40.1.7, "Migrating Back-end Components for Individual Spaces."

Individual spaces are locked during an export operation to prevent simultaneous imports/exports of the same space. If someone else is exporting a particular space, all subsequent attempts to export (or import) the same space are blocked. If a space contains Web Service data controls, all the associated Web Services must be up and accessible for the export to succeed.

Note:

Space artifacts must be located in the shared content directory to be exported. For example, icons and images associated with a page template must be placed in the page template's content directory to be exported. For more information, see "What You Should Know About a Resource's Properties" in the Oracle Fusion Middleware User's Guide for Oracle WebCenter Portal: Spaces.

Out-of-the-box templates and user customizations are never exported.

This section includes the following:

If you want to export an entire Spaces application, see Section 40.1.4, "Exporting an Entire Spaces Application."

40.1.8.1 Exporting Individual Spaces Using the Spaces Application

Administrators can export one or more spaces from Spaces Administration pages. For details, see "Exporting Spaces" in Oracle Fusion Middleware User's Guide for Oracle WebCenter Portal: Spaces.

40.1.8.2 Exporting Individual Spaces Using WLST

Use the WLST command exportGroupSpaces to export one or more spaces. For command syntax and examples, see "exportGroupSpaces" in the Oracle Fusion Middleware WebLogic Scripting Tool Command Reference.

For information on how to run WLST commands, see Section 1.13.3.1, "Running Oracle WebLogic Scripting Tool (WLST) Commands."

40.1.9 Importing Individual Spaces

Administrators can import a space archive (.EAR) from the Spaces application or using WLST commands.

On import, all spaces included in the archive are created or re-created on the target application. Existing spaces are deleted then replaced, and new spaces are created.

If you intend to import spaces with names identical to those available on the target application, ensure that those spaces are offline in the target application. It is not possible to overwrite a space, on import, if it is online. For details, see "Taking Any Space Offline" in Oracle Fusion Middleware User's Guide for Oracle WebCenter Portal: Spaces.

Spaces are locked during an import operation to prevent simultaneous imports/exports of the same space. If someone else is importing a particular space, all subsequent attempts to import (or export) the same space are blocked. If a space contains Web Service data controls, all the associated Web Services must be up and accessible for the import to succeed.

All spaces must have a security policy. Therefore, when you import a brand new space you must ensure that import the space's security policy too. Existing spaces have a security policy in place so, in this case, it's up to you whether to overwrite the security information on import or maintain the existing security policy.

When you import a space with security, security policy updates do not apply immediately. Any user logged in to the Spaces application must log out and log back in to adopt the new space security policy.

If data migration is important, documents and discussions can be migrated for individual spaces. For details, see Section 40.1.7, "Migrating Back-end Components for Individual Spaces."

This section includes the following:

After importing one or more spaces, consider initiating an Oracle Secure Enterprise Search crawl to index the newly imported data.

40.1.9.1 Importing Individual Spaces Using the Spaces Application

Administrators can import archives containing one or more spaces (.EAR) into another Spaces application. For details, see, "Importing Spaces" in Oracle Fusion Middleware User's Guide for Oracle WebCenter Portal: Spaces.

40.1.9.2 Importing Individual Spaces Using WLST

Use the WLST command importGroupSpaces to import one or more spaces. For command syntax and examples, see "importGroupSpaces" in the Oracle Fusion Middleware WebLogic Scripting Tool Command Reference.

For information on how to run WLST commands, see Section 1.13.3.1, "Running Oracle WebLogic Scripting Tool (WLST) Commands."

40.1.10 Migrating Back-end Components for Space Templates

Space templates can contain pages, portal resources, documents, discussions, lists, and member details. Most template data is exported along with the template, there is no need to migrate template data separately when exporting and importing space templates.

You must, however, migrate the space template's folder and content (on Oracle WebCenter Content Server) to the target instance as described below. If you do not, the Documents service is not enabled in any space that you create, using this template.

Importing the Back-end Folder and Documents for a Space Template

Use WebCenter Portal's Document Migration Utility to migrate document content for space templates. For details, see Section 40.1.7.5, "Exporting/Importing Space Documents using the Document Migration Utility".

40.1.11 Exporting Space Templates

Administrators can export space templates and import them into other Spaces applications. Out-of-the-box templates cannot be exported.

Space templates can include pages, resources, documents, discussions, lists, service information, and security information such as custom roles and current members.

While export and import utilities are primarily used to move information between Spaces applications, the space template export feature is also useful as a backup service, and for sharing and exchanging templates with others.

Space template information is exported into a single export archive (.EAR file). The EAR file contains a metadata archive (.MAR file) and a single XML file containing space security policy information.

You can save export archives to your local file system or to a remote server file system.

This section includes the following:

See also,Section 40.1.10, "Migrating Back-end Components for Space Templates." and Section 40.1.8, "Exporting Individual Spaces."

40.1.11.1 Exporting Space Templates Using the Spaces Application

Spaces administrators can export one or more space templates from Spaces Administration pages. For details, see "Exporting Space Templates" in Oracle Fusion Middleware User's Guide for Oracle WebCenter Portal: Spaces.

40.1.11.2 Exporting Space Templates Using WLST

Use the WLST command exportGroupSpaceTemplates to export one or more space templates. For command syntax and examples, see "exportGroupSpaceTemplates" in the Oracle Fusion Middleware WebLogic Scripting Tool Command Reference.

For information on how to run WLST commands, see Section 1.13.3.1, "Running Oracle WebLogic Scripting Tool (WLST) Commands."

40.1.12 Importing Space Templates

Administrators can import a space template archive (.EAR) into another Spaces application.

On import, all space templates included in the archive are re-created on the target application. If a space template exists on the target, then it is deleted and replaced. If a space template does not exist, then it is created.

Newly imported space templates are not immediately available for general use. You must publish the imported templates to make them available to everyone. See "Publishing and Hiding Space Templates" in Oracle Fusion Middleware User's Guide for Oracle WebCenter Portal: Spaces.

This section includes the following:

See also, Section 40.1.9, "Importing Individual Spaces"

40.1.12.1 Importing Space Templates Using the Spaces Application

Spaces administrators can import one or more space templates from Spaces administration pages. For details, see "Importing Space Templates" in Oracle Fusion Middleware User's Guide for Oracle WebCenter Portal: Spaces.

40.1.12.2 Importing Space Templates Using WLST

Use the WLST command importGroupSpaces to import one or more space templates. For command syntax and examples, see "importGroupSpaces" in the Oracle Fusion Middleware WebLogic Scripting Tool Command Reference.

For information on how to run WLST commands, see Section 1.13.3.1, "Running Oracle WebLogic Scripting Tool (WLST) Commands."

40.1.13 Exporting Spaces Resources

Authorized users can download Spaces resources, such as skins and page templates, while the application is running, edit and extend them in tools such as Oracle JDeveloper, and then upload them back into their Spaces application. Users who want to share or migrate resources to other Spaces applications can use the download feature too.

You can download the following application-level and space-level resources through the resource management pages in Spaces:

  • Skins

  • Page Styles

  • Page Templates

  • Content Presenter Templates

  • Navigations

  • Resource Catalogs

  • Task Flows

  • Mashup Styles

Alternatively, administrators can perform the same task using WLST commands.

When you download (or export) a WebCenter Portal resource, the resource details are saved to a WebCenter Portal export archive (.EAR). You can save the export archive to your local file system or a remote server file system using a filename of your choice.

Optionally, you can include portal resource content that is stored under the 'shared' content directory (oracle\webcenter\siteresources\scopedMD\shared) in the archive. If resource content directories are excluded from the resource archive, you can manually migrate files for portal resources using exportMetadata/importMetadata WLST commands:

exportMetadata(application='webcenter', server='WC_Spaces', toLocation='/tmp/content', docs='/oracle/webcenter/siteresources/scopedMD/shared/**')

importMetadata(application='webcenter', server='WC_Spaces', fromLocation='/tmp/content', docs='/oracle/webcenter/siteresources/scopedMD/shared/**')

This section includes the following:

40.1.13.1 Exporting WebCenter Resources Using the Spaces Application

Spaces administrators and individual space moderators can export resources from WebCenter Portal resource administration pages. For details, see "Downloading a Resource" in Oracle Fusion Middleware User's Guide for Oracle WebCenter Portal: Spaces.

40.1.13.2 Exporting WebCenter Resources Using WLST

Use the WLST command exportWebCenterResource to export a single WebCenter Portal resource. For command syntax and examples, see "exportWebCenterResource" in the Oracle Fusion Middleware WebLogic Scripting Tool Command Reference.

For information on how to run WLST commands, see Section 1.13.3.1, "Running Oracle WebLogic Scripting Tool (WLST) Commands."

40.1.14 Importing Space Resources

Authorized users can import portal resources, such as skins and page templates, while the application is running. You can import the following application-level and space-level resources through the resource management pages or using WLST commands:

  • Skins

  • Page styles

  • Page templates

  • Content Presenter templates

  • Navigations

  • Resource catalogs

  • Task flows

  • Mashup styles

You can only import a resource previously saved to a WebCenter Portal export archive file (.EAR). For details, see Section 40.1.13, "Exporting Spaces Resources".

On import:

  • Existing portal resources are overwritten, that is, resources with the same internal ID.

  • Space-level portal resources are always imported back into the same space. You cannot import a resource into a different space.

This section includes the following:

40.1.14.1 About Permissions Required to Import Spaces Resources

Table 40-3 describes the roles/permission required to import Spaces resources using the Spaces application.

Note:

If you want to import resources using WLST, you must also have the WebLogic Server Monitor role (or higher).

Table 40-3 Permissions Required to Import Resources Using the Spaces Application

Resource Required Spaces Role or Permission Description

Application-level resource

  • Administrator
 

OR

  

Application-level resource

  • Create, Edit, Delete <resourcetype>

  • This permission enables you to create and manage application-level resources for Spaces.

  • Manage Configuration

  • The application-level Manage Configuration permission gives you access to the Spaces administration page.
     

Space-level resource

  • Moderator
 

OR

  

Space-level resource

  • Create, Edit, Delete Resources (standard)

    OR

    Create, Edit, Delete <resourcetype> (advanced)

  • These permissions enable you to create and manage resources for a particular space. Either standard or advanced permissions will apply, depending on the space.

  • Manage Configuration

  • The space-level Manage Configuration permission gives you access to the resource administration page for a particular space.

40.1.14.2 Importing WebCenter Resources Using the Spaces Application

Spaces administrators and individual space moderators can import resources from WebCenter Portal resource administration pages. For details, see "Uploading a Resource" in Oracle Fusion Middleware User's Guide for Oracle WebCenter Portal: Spaces.

40.1.14.3 Importing WebCenter Resources Using WLST

Use the WLST command importWebCenterResource to import a single WebCenter Portal resource. For command syntax and examples, see "importWebCenterResource" in the Oracle Fusion Middleware WebLogic Scripting Tool Command Reference.

For information on how to run WLST commands, see Section 1.13.3.1, "Running Oracle WebLogic Scripting Tool (WLST) Commands."

40.1.15 Migrating Wiki Documents

You can migrate wiki content from Oracle Content Server or other wiki applications, such as Confluence, into WebCenter Portal: Spaces using a custom wiki extraction tool in combination with the Document Migration Utility. The custom wiki extraction tool extracts the wiki content into an archive format that you can import into a Spaces content repository, using the Document Migration Utility.

To write a custom wiki extraction tool, you'll need a detailed understanding of the content created in Content Server for a space, space template, wiki documents, and wiki pages, along with a detailed understanding of the Document Migration Utility and the format of its archive. This section describes these formats and processes in the following subsections:

40.1.15.1 Understanding Document Content in Spaces and Space Templates

When the Documents service is enabled in a space or space template, data is created in Content Server.

This section contains the following subsections:

40.1.15.1.1 Understanding Spaces

When a space has the Documents service enabled (either on creation or post creation) a folder is created in Content Server under the root folder containing all the space folders. The root folder is specified in the settings on the primary content repository connection. For more information about connection properties, see Section 11.2.3.13.2, "Configuring the Content Server Connection for Spaces."

The GUID of the folder created for the space is derived from the internal identifier of the space in Spaces. For example, if the root folder is WebCenter and the space Marketing is being created, the following data is created in Content Server:

Folder Name = Marketing
Folder Path = /WebCenter/Marketing
Folder GUID = 13828FE1-75D8-4A0B-A53B-A76AE78C1AE6

When document content (files/folders/wikis, etc.) is added to the space, the artifacts are created inside the space folder in Content Server.

40.1.15.1.2 Understanding Space Templates

For space templates, the folder is created in the spacetemplates folder that resides under the root folder. The GUID of the folder created for the space template will match the internal identifier of the space template in Spaces.

For example, if the root folder is WebCenter and the space template Template1 is being created, the following data is created in Content Server:

/WebCenter/spacetemplates/Template1

Document content can only be added to a template when the template is created; it cannot be added after the template has been created. When creating a template from a space, if Documents is checked on the Content tab of the Create Template dialogue, the document contents in the space are copied to the template.

40.1.15.1.3 Understanding Folder and File Limitations for a Folder

Content Server has a limit on the number of folders and the number of files that are permitted to be created inside a folder. When the limit of each setting is reached, additional content of that type cannot be added to that folder.

These settings should be large enough to enable users to be able to create a reasonable amount of content, but not so large that they will impair the user interface when rendering that content. Any changes to these settings will only affect new content being added, if you have an existing folder with content larger than these settings, the will not be affected.

To edit the settings for the number of folders and files:

  1. Log into Content Server.

  2. Go to Administration > Folder Configuration.

  3. In the Virtual Folder Administration Configuration section, adjust the settings for Maximum Folders Per Virtual Folder and Maximum Content Per Virtual Folder as appropriate for your environment.

    For more information about these settings, see Section A.4.1, "Virtual Folder Administration Configuration Screen" in Oracle WebCenter Content Application Administrator's Guide for Content Server.

Note:

The root folder containing all the space folders for a WebCenter Portal: Spaces instance bypasses these settings, enabling more space folders to be created than the limit.

40.1.15.1.4 Understanding Export/Import for Spaces and Space Templates

WebCenter Portal: Spaces provides tools to export and import spaces and space templates. On import, the Documents service is enabled or disabled in the target to match that of the source. If the Documents service is enabled in the source, a folder is created in the target Content Server for the space or space template, and appropriate Content Server permissions are granted to users and groups with access to the space or space template. The GUID of the folder in Content Server for a space or space template will be the same in the source and target Content Server. See Section 40.1.15.1, "Understanding Document Content in Spaces and Space Templates" for more information about the folders created in Spaces for spaces and space templates.

Before document content can be migrated from the source to target instances using the Document Migration Utility, the Spaces migration must have completed successfully so that Content Server has folders created for the spaces and space templates that have Documents enabled. For more information about Spaces migration, see Section 40.1, "Exporting and Importing a Spaces Application for Data Migration."

40.1.15.2 Understanding Wiki Documents and Wiki Pages

This section describes the format and how wiki documents and wiki pages work in Spaces. For more information about wiki documents and wiki pages in Spaces, see "Working with Wiki Documents" in Oracle Fusion Middleware User's Guide for Oracle WebCenter Portal: Spaces.

This section contains the following subsections:

40.1.15.2.1 Understanding Wiki Documents

In WebCenter Portal: Spaces you can create a wiki document using the Documents service. These documents can reside anywhere in the hierarchy of any created folders inside a space. Wiki documents can sit alongside documents of other types, or you could choose to arrange all your wiki documents inside a single folder.

When a wiki document is created in Spaces, an HTML document is created and checked into Content Server. This wiki document contains special metadata values that tell Spaces that the document is a wiki document as opposed to a regular HTML document. These metadata values are:

dDocType = Application
dDocFunction = wiki
dOriginalName (document filename) = <wikiName>.htm

When you open a document in Spaces with the above metadata, Spaces will know to display it as a wiki document.

40.1.15.2.2 Understanding Wiki Pages

In WebCenter Portal: Spaces you can create a wiki page by creating a page based on the Wiki page template. When you navigate to a wiki page you are presented with a wiki document. Depending on the display template of your space, you may see a Wikis menu, which you can click to list all the wiki pages in your space. See "Creating a Wiki Document Using the Wiki Page Style" in Oracle Fusion Middleware User's Guide for Oracle WebCenter Portal: Spaces for details on how to create Wiki pages.

When a wiki page is created in Spaces the following artifacts are created in Content Server:

  • A folder is created in the folder for the space the wiki page is being created in; the name of the wiki folder is the same name as the wiki page name but with special characters removed.

  • A document is created inside the wiki folder with the following metadata:

    • dDocTitle = document title (same name as the wiki page name with an extension of .htm)

    • dOriginalName = the documents filename (same as dDocTitle)

    • dDocFunction = wiki

    • dDocType = Application

    • xWCPageID = the name of the wiki page's JSPX page

This is best illustrated with an example. If the root folder is WebCenter, the space in which a wiki page is being created is Marketing, and the wiki page being created is Wiki1, the following artifacts will be created in Content Server:

  • Folder: /WebCenter/Marketing/Wiki1

  • Document: /WebCenter/Marketing/Wiki1/Wiki1.htm

    • dDocTitle= Wiki1.htm

    • dOriginalName = Wiki1.htm

    • dDocFunction = 'wiki'

    • dDocType = 'Application'

    • xWCPageID = Wiki1.jspx

When you navigate to a wiki page the following occurs:

  • WebCenter Content is queried for the document in the following location:

    /<RootFolder>/<GroupSpaceFolder>/<wikiPageName>/<wikiPageName>.htm

    For example: /WebCenter/Marketing/Wiki1/Wiki1.htm

  • If the document is found, it is displayed as a wiki document.

  • If the document is not found the wiki page will display the contents of the wiki folder.

40.1.15.3 Understanding the Document Migration Utility

This section provides a detailed description of the inner workings of the utility, and the format of the resulting document migration archive, which you'll need to write a custom wiki extraction tool. The Document Migration Utility exports space and space template documents into an archive that the utility can subsequently use to import the archived documents into the target. For more information about how to use the Document Migration Utility, see Section 40.1.7.5.2, "Migrating Content Using the Document Migration Utility."

This section contains the following subsections:

40.1.15.3.1 Understanding the Document Migration Utility's Export Function

On export the document content stored in Content Server for the specified spaces and space templates are extracted into a Document Migration Archive. The Document Migration Archive extracts all the contents of a space or space template into its own top-level folder in the archive. The name of this folder is based on the internal GUID of the space or space template folder in Content Server.

The Document Migration Archive will contain a root folder for each space or space template in the export. That is, if you are exporting content from four spaces, the archive will have four root folders. The names of these root folders is based on the internal GUID of the corresponding space or space template folder in Content Server.

In order to have one archive per space or space template, the Document Migration Utility should be called specifying one space/space template at a time and a unique archive name.

Inside each top level folder in the archive is an XML document (ExportImportData.xml) that fully describes the data in that root folder (that is, it describes the data exported for that space or space template). It contains all the metadata of the folders and files in the source Content Server that are to be maintained on import. For more information about the format of the archive, see Section 40.1.15.3, "Understanding the Document Migration Utility." For more information about the metadata maintained between the source and target, see Section 40.1.15.3.3, "Understanding How the Document Migration Utility Handles Metadata."

Assuming there are spaces or space templates for which contents are to be exported, the following occurs during export:

  • A temporary directory is created.

  • For each space or space template:

    • a directory is created in the temporary directory with its name being the GUID of the corresponding folder in Content Server

    • an ExportImportData.xml document is created inside that new directory

    • Content Server is queried for the contents of the space/space template

    • If there are contents, they are read and information about the folders/documents are written to the ExportImportData.xml document and the files are downloaded into the temporary directory

    • If there are contents, they are read and information about the folders and documents are written to the ExportImportData.xml document. The actual files are downloaded into the directory maintaining the folder hierarchy as in the Content Server. For example, if in the Content Server the document doc1.doc is in folder Folder1 the document will be added to the root folder under Folder1 as shown below.

      /<tmpDir>/<spaceFolder>/Folder1/doc1.doc

  • After all contents have been extracted, the entire contents of the temporary directory are zipped up into the Document Migration Archive.

40.1.15.3.2 Understanding the Document Migration Utility's Import Function

Before the Document Migration Utility is run, the Spaces migration must have completed successfully to ensure the space and/or space templates have been created correctly in the target Content Server. If these folders do not exist in Content Server the import of document content will fail. For more information about migrating Space, see Section 40.1, "Exporting and Importing a Spaces Application for Data Migration."

Note:

You cannot simply create a space or space template in the target with the same name as in the source and expect it to work. If you do this, the folder in Content Server will have the same name as in the source but with a different GUID. It is this folder GUID that is used to tie the space in Spaces with the folder in Content Server as well as what is used to synchronize the data in the export archive with the target folder in the target Content Server.

On import, the Document Migration Archive is read and for each space or space template's data the content is recreated in the corresponding space or space template's folder in the target Content Server. The names of the top level folders in the archive are used to synchronize with the space or space template folder in the target Content Server instance. If the space or space template folders in the target Content Server already contain contents, by default the contents are deleted before the import process begins.

Note:

the default behavior can be overwritten by specifying the CheckExistingContents property (values are true or false) in the properties file when running the Document Migration Utility specifying all the properties in a file. When set to false, the default behavior is overridden such that the target folder is not checked for any existing content and any existing content is not deleted. Care should be taken with having this setting as false; if there is any content in the target with the same Content ID or any content in the same folder with the same filename, the import will fail.

The XML document (ExportImportData.xml) located inside each top level folder is used to drive the import. This document describes the hierarchy of files and folders to recreate in the target Content Server. It also contains the metadata to be used when creating the artifacts and for documents it contains the path to the native file in the archive to use in the upload. For more information about the format of the archive, see Section 40.1.15.3, "Understanding the Document Migration Utility."

On import, the following happens:

  • The Document Migration Archive is unzipped into a temporary directory

  • For each folder at the root of the archive (which represent a space or space template):

    • The corresponding folder is obtained from the target Content Server instance (using the folder name that is the GUID of the folder in Content Server)

    • The ExportImportData.xml document is read

    • For each folder or file described in the ExportImportData.xml the contents are recreated in the target instance

      The attributes in the ExportImportData.xml document for the folders and files are used as metadata for the contents being created and the files are uploaded from the corresponding location in the archive.

  • At the end of a successful import, this temporary directory is deleted. If the import fails before completion, this temporary directory will remain.

40.1.15.3.3 Understanding How the Document Migration Utility Handles Metadata

The Document Migration Utility will maintain as much metadata as possible between the source and target. Most internal metadata (such as IDs), however, are not maintained. The following metadata is not included in the export set:

  • Any date metadata, such as the creation date (for example, dCreateDate, dReleaseDate, dDocLastModifiedDate)

  • For a document:

    • No internal identifiers for the document revisions or renditions (for example, dID, dDoc). Note that the content ID, dDocName, is included

    • The ID of the folder in which the document resides (for example, xCollectionID)

    • No Web-viewable renditions, as these will be recreated when the document is checked into the target

    • No information about the actual file (for example, its file type or mimetype) as these will get set when document is checked into the target

    • No status information, such as checked out, released state as these are irrelevant when creating the document in the target (for example, dIsCheckedOut, dReleaseState)

  • For a folder:

    • No internal identifiers or paths such as the parent folder ID, or its own path (for example, hasCollectionID, dCollectionID, dCollectionGUID, hasCollectionPath, dCollectionPath)

  • Storage rule, as this is dependent on the configuration of the target Content Server

  • Security group or other security permissions, as these will get set when the content is created in the target (for example, dSecurityGroup, dRead, canReadCollection)

Metadata that is maintained:

  • Names of artifacts, such as folder name or document title (for example, dCollectionName, dDocTitle)

  • Username of person who created the content and modified it (for example, dCollectionOwner, dDocOwner)

  • Wiki metadata, such as dDocFunction, dDocType, xWCPageID

  • For a document:

    • The name of the file to upload for the document (dOriginalName)

    • The content ID (dDocName)

      If at the time of import a content item already exists in the target Content Server with the same content ID, import will fail. When rerunning an import with the property CheckExistingContents=false set, ensure that the target folder does not already contain the contents from the archive being imported to avoid a content ID error.

  • Custom metadata (for example, myCustomInteger).

40.1.15.3.4 Document Migration Archive

The Document Migration Utility creates a single archive when exporting content from a source Content Server. The archive is used when running the Document Migration Utility to import the data into the target environment. The Document Migration archive has a specific layout and if an archive does not match this layout, the Document Migration Utility import will fail.

Archive format

The following describes the layout of the Document Migration Archive.

At the top level of the archive is a folder for each space/space template that has had their data exported.

  • If a single space/space template has been exported there will only be one root folder, if multiple spaces/space templates have been exported there will be multiple root folders.

  • The root folder names are the same as the internal GUID of the corresponding folder in Content Server (for example, 13828FE1-75D8-4A0B-A53B-A76AE78C1AE6)

In each top level folder is an ExportImportData.xml document that describes the hierarchy of files and folders to recreate in the target Content Server for that space or space template. This document contains the metadata to be used when creating the artifacts (internal metadata, such as xCollectionID, isreadonly, xStorageRule, will not be included). For documents, it contains the path to the native file in the archive to use in the upload.

In each top-level space and space template folder are the exported documents. The layout of the documents inside the top-level folder mimics the layout in the source space and space template in the source Content Server. For example, if document doc1.doc resides in folder1, the top-level folder in the archive will contain a folder folder1 in which doc1.doc resides. The documents file/folder structure in the top-level folder must match the hierarchy described in the ExportImportData.xml so that the import code can find the native file for the documents described in that document uploading the document into the target. Empty folders in the space or space template folder in the source will not be in the archive. However, these folders are still described in the ExportImportData.xml document in order for them to be recreated in the target.

In a simplified overview, this would look like:

  • Space1 top level folder:

    • ExportImportData.xml

    • <Space1's documents arranged in the same folder hierarchy as in the source>

  • Space2 top level folder:

    • ExportImportData.xml

    • <Space2's documents arranged in the same folder hierarchy as in the source>

Understanding the ExportImportData.xml Document

The XSD for the ExportImportData.xml document is shown below.

XSD for ExportImportData.xml:

<?xml version="1.0" encoding="UTF-8"?>
<xs:schema xmlns:xs="http://www.w3.org/2001/XMLSchema">
 
<xs:element name="groupspace-folder" type="FolderType" />
 
  <!-- 'folders' must contain 1 or more 'folder' child elements -->
  <xs:complexType name="FoldersType">
    <xs:sequence>
      <xs:element name="folder" type="FolderType" 
                  minOccurs="1" maxOccurs="unbounded" />
    </xs:sequence>
  </xs:complexType>
 
  <!-- 'documents' must contain 1 or more 'document' elements -->
  <xs:complexType name="DocumentsType">
    <xs:sequence>
      <xs:element name="document" type="DocumentType" 
                  minOccurs="1" maxOccurs="unbounded" />
    </xs:sequence>
  </xs:complexType>
 
  <!-- 'attributes' must have 1 or more 'attribute' child elements -->
  <xs:complexType name="AttributesType">
    <xs:sequence>
      <xs:element name="attribute" type="AttributeType" 
                  minOccurs="1" maxOccurs="unbounded"/>
    </xs:sequence>
  </xs:complexType>
 
  <!-- 'folder' has to have 1 and only 1 'attributes' child element
       0 or 1 'folders' child element, 0 or 1 'documents' child element -->
  <xs:complexType name="FolderType">
    <xs:sequence>
      <xs:element name="attributes" type="AttributesType" 
                  minOccurs="1" maxOccurs="1" />
      <xs:element name="folders"    type="FoldersType"    
                  minOccurs="0" maxOccurs="1" />
      <xs:element name="documents"  type="DocumentsType"  
                  minOccurs="0" maxOccurs="1" />
    </xs:sequence>
  </xs:complexType>
 
  <!-- 'document' has to have : 1 and only 1 'attributes' child element
       and nothing else -->
  <xs:complexType name="DocumentType">
    <xs:sequence>
      <xs:element name="attributes" type="AttributesType"  
                  minOccurs="1" maxOccurs="1" />
    </xs:sequence>
  </xs:complexType>
 
  <!-- 'attribute' element has to have a 'name' and 'value' attributes -->
  <xs:complexType name="AttributeType">
    <xs:attribute name="name"  type="xs:string" use="required" />
    <xs:attribute name="value" type="xs:string" use="required" />
  </xs:complexType>
 
</xs:schema>

Where:

  • <groupspace-folder> is the root tag that represents the space or space template folder.

    This tag contains the <attributes> tag, which in turn contains a number of attributes about the root folder and export data. These attributes are for information purposes only; they are not used in the import.

  • <attributes> is used to group all the attributes of the document or folder.

    This tag must contain one or more <attribute> tags. No other child tags are permitted.

  • <attribute> contains the metadata for a folder or document.

    This tag has two attributes:

    • name - the Content Server metadata name

    • value - the value of the metadata

    No child tags are permitted.

  • <folders> is used to group all the folders in the current folder

    This tag must contain 1 or more <folder> tags. No other child tags are permitted.

  • <folder> is used to indicate a child folder.

    This tag must have the <attributes> tag. If the folder has child folders, it will have the <folders> tag. If the folder has child documents, it will have the <documents> tag.

  • <documents> is used to group all the documents in the current folder.

    This tag must contain one or more <document> tags. No other child tags are permitted.

  • <document> is used to indicate a document in the current folder.

    This tag must have the <attributes> tag. No other child tags are permitted.

Annotated example:

The following annotated example shows a partially complete ExportImportData.xml document. Note that the example contains blank lines and XML comments that should not exist in a real ExportImportData.xml document.

<?xml version="1.0"encoding="UTF-8"standalone="yes"?>
<groupspace-folder>
 
  <attributes>
    <!-- Contains a set of attributes of the main space folder -->
    <attribute name="export-date" value="2011-07-22 13:02:29"/>
  </attributes>
 
  <folders> <!-- only present if the space contains any child folders -->
    <folder> <!-- a 'folder' tag exists for each child folder --> 
      <attributes>
        <!-- contains the set of folder attributes, examples below -->
        <attribute value="F1" name="dCollectionName"/>
      </attributes>
      <!-- a 'folder' tag will contain the 'folders' tag if this folder
           contains child folders, i.e. if 'F1' has child folders -->
      <folders>
        <folder>
          <!-- attribute tags, child folders, child documents etc -->
        </folder>
      </folders> <!-- closing tag for all the folders in the 
                      current folder à
      <!-- a 'folder' tag will contain the 'documents' tag if this folder
           contains documents, i.e. if 'F1' has documents at its root -->
      <documents>
        <document>
          <!-- attributes tags, see below -->
        </document>
      </documents> <!-- closing tag for all the documents in the 
                        current folder -->
    </folder> <!-- closing tag for folder 'F1' -->
  </folders> <!-- closing tag for all the folders in the space root -->
 
  <documents> <!- only present if the folder contains any documents
                  in the root folder -->
    <document> <!-- a 'document' tag exists for each document in the
                    folder -->
      <attributes>
        <!- contains the set of document attributes, examples below -->
        <attribute name="dDocTitle" value="Doc1"/>
        <attribute name="xForceFolderSecurity" value="TRUE"/>
        <attribute name="xSecurityClearanceLevel" value="public"/>
      </attributes>
    <document> <!-- closing tag for document 'Doc1' -->
  </documents><!-- closing tag for all the documents in the space root -->
 
 </groupspace-folder>

Building the ExportImportData.xml Document

The following shows pseudo code for how the XML document is built:

- query Content Server for the space's folder information
  - create a 'group-space-folder' node
    - create an 'attributes' node
    - for each of the three attributes we want to maintain (folder name, path
      and GUID)
        - create an 'attribute' node with name and value
        - add that 'attribute' node to the 'attributes' node
    - add that 'attributes' node to the 'group-space-folder' node
 
 - query Content Server for the contents of the space root folder
     - * If there are child folders
        - Create a 'folders' node
        - For each child folder
            - create a 'folder' node
            - create an 'attributes' node
            - for each folder metadata we want to maintain
                - create an 'attribute' node with name and value
                - add that 'attribute' node to the 'attributes' node
            - add the 'attributes' node to the 'folder' node
            - query Content Server for the contents of this current folder
                - go to * and repeat traversing folders which reside in this
                   current folder
                - go to # and repeat for documents which reside in this current
                   folder
             - add the 'folder' node to the 'folders' node
        - add the 'folders' node to the parent node (which will either be a
           'folder' node or the 'group-space-folder' node)
 
     - # If there are documents in this current folder
        - create a 'documents' node
        - for each document
            - create a 'document' node
            - create an 'attributes' node
            - for each metadata we want to maintain
                - create an 'attribute' node with name and value
                - add that 'attribute' node to the 'attributes' node
            - add the 'attributes' node to the 'document' node
            - add that 'document' node to the 'documents' node
         - add the 'documents' node to the 'folder' node
 
  - use jaxb to write the whole data to an xml file

Document Migration Archive Example

Below is an example of the archive format for a set of sample data and a sample ExportImportData.xml document for one of the spaces in the example.

WebCenter Data

In the example below, two spaces (Marketing and Sales) have been created in Spaces. In the Marketing space two wiki pages have been created: MarketingWiki and Tradeshows. The Marketing space has also had two folders created (Branding and Presentations), the latter of which contains subfolders with a PowerPoint document and a wiki document. The Sales space has no wiki pages, but does contain three folders with some contents.

  • Marketing
    Marketing space contains the Content Server folder GUID= 29A4E019-7AE7-46A1-823B-AF16A313BBEF

    • MarketingWiki

      • MarketingWiki.htm with the following metadata:

        dOriginalName="MarketingWiki.htm"
        dDocTitle="MarketingWiki.htm"
        dDocFunction="wiki"
        dDocType="Application"
        xWCPageID="Page2.jspx"

    • Presentations

      • Branding

        ProductBranding.pptx

      • Presentation Dates.htm with the following metadata:
        (Note that here the wiki document is created inside a folder in a space, rather than being created when a wiki page is created as for MarketingWiki.htm above)

        dOriginalName=" Presentation Dates.htm"
        dDocTitle="Presentation Dates"
        dDocFunction="wiki"
        dDocType="Application"
        xWCPageID = not set (as the wiki was not created when creating a wiki page)

      • ProjectedDesigns.pptx

    • Products

    • TradeShows

      • TradeShows.htm with the following metadata:

        dOriginalName=" TradeShows.htm"
        dDocTitle=" TradeShows.htm"
        dDocFunction="wiki"
        dDocType="Application"
        xWCPageID="Page4.jspx"

  • Sales

    WebCenter Content folder GUID = 629BFEBD-4E83-4DCA-895A-C72E5192FBFD

    • DecConference

      • GuestSpeakers.doc

    • SalesConference

      • Attendees.doc

      • TalkSchedules.doc

    • BudgetForcasts.doc

Archive Contents

  • 29A4E019-7AE7-46A1-823B-AF16A313BBEF (contains Marketing space contents)

    • MarketingWiki

      • MarketingWiki.htm

    • Presentations

      • Branding (ProductBranding.pptx)

      • ProjectedDesigns.pptx

      • Presentation Dates.htm

    • Tradeshows

      • TradeShows.htm

    • ExportImportData.xml

    • 2001Plans.doc

  • 629BFEBD-4E83-4DCA-895A-C72E5192FBFD (contains Sales space contents)

    • DecConference

      • GuestSpeakers.doc

    • SalesConference

      • Attendees.doc

      • TalkSchedules.doc

    • ExportImportData.xml

    • BudgetForcasts.doc

Note:

There is no Products folder under the Marketing space's root folder as this folder did not contain any documents.

ExportImportData.xml for the Marketing space

<?xml version="1.0" encoding="UTF-8" standalone="yes" ?> 
<groupspace-folder>
  <attributes>
    <attribute value="2011-10-27 15:50:18" name="export-date" /> 
    <attribute value="/WebCenter0711/Marketing/" name="group-space-path" /> 
    <attribute value="Marketing" name="group-space-name" /> 
    <attribute value="29A4E019-7AE7-46A1-823B-AF16A313BBEF" 
               name="group-space-guid" /> 
  </attributes>
  <folders>
    <folder>
      <attributes>
        <attribute value="TRUE" name="xForceFolderSecurity" /> 
        <attribute value="sysadmin" name="dCollectionCreator" /> 
        <attribute value="MarketingWiki" name="dCollectionName" /> 
        <attribute value="0" name="isLink" /> 
        <attribute value="Page2.jspx" name="xWCPageId" /> 
        <attribute value="sysadmin" name="dCollectionOwner" /> 
        <attribute value="sysadmin" name="dCollectionModifier" /> 
        <attribute value="1" name="dCollectionEnabled" /> 
      </attributes>
      <documents>
        <document>
          <attributes>
            <attribute value="TRUE" name="xForceFolderSecurity" /> 
            <attribute value="Page2.jspx" name="xWCPageId" /> 
            <attribute value="wiki" name="dDocFunction" /> 
            <attribute value="Application" name="dDocType" /> 
            <attribute value="0" name="ishidden" /> 
            <attribute value="sysadmin" name="dDocOwner" /> 
            <attribute value="MarketingWiki.htm" name="dOriginalName" /> 
            <attribute value="MarketingWiki.htm" name="dDocTitle" /> 
            <attribute value="FALSE" name="xInhibitUpdate" /> 
            <attribute value="0" name="isreadonly" /> 
            <attribute value="0" name="CustomInteger" /> 
            <attribute value="sysadmin" name="dDocCreator" /> 
            <attribute value="sysadmin" name="dDocAuthor" /> 
            <attribute value="OWCSVR01USORAC012754" name="dDocName" /> 
            <attribute value="1" name="dRevisionID" /> 
            <attribute value="sysadmin" name="dDocLastModifier" /> 
          </attributes>
        </document>
      </documents>
    </folder>
    <folder>
      <attributes>
        <attribute value="TRUE" name="xForceFolderSecurity" /> 
        <attribute value="sysadmin" name="dCollectionCreator" /> 
        <attribute value="Presentations" name="dCollectionName" /> 
        <attribute value="0" name="isLink" /> 
        <attribute value="sysadmin" name="dCollectionOwner" /> 
        <attribute value="sysadmin" name="dCollectionModifier" /> 
        <attribute value="1" name="dCollectionEnabled" /> 
      </attributes>
      <folders>
        <folder>
          <attributes>
            <attribute value="TRUE" name="xForceFolderSecurity" /> 
            <attribute value="sysadmin" name="dCollectionCreator" /> 
            <attribute value="Branding" name="dCollectionName" /> 
            <attribute value="0" name="isLink" /> 
            <attribute value="sysadmin" name="dCollectionOwner" /> 
            <attribute value="sysadmin" name="dCollectionModifier" /> 
            <attribute value="1" name="dCollectionEnabled" /> 
          </attributes>
          <documents>
            <document>
              <attributes>
                <attribute value="TRUE" name="xForceFolderSecurity" /> 
                <attribute value="Document" name="dDocType" /> 
                <attribute value="sysadmin" name="dDocOwner" /> 
                <attribute value="0" name="ishidden" /> 
                <attribute value="ProductBranding.pptx" name="dDocTitle" /> 
                <attribute value="ProductBranding.pptx" 
                           name="dOriginalName" /> 
                <attribute value="FALSE" name="xInhibitUpdate" /> 
                <attribute value="0" name="isreadonly" /> 
                <attribute value="0" name="CustomInteger" /> 
                <attribute value="sysadmin" name="dDocCreator" /> 
                <attribute value="sysadmin" name="dDocAuthor" /> 
                <attribute value="OWCSVR01USORAC012748" name="dDocName" /> 
                <attribute value="1" name="dRevisionID" /> 
                <attribute value="sysadmin" name="dDocLastModifier" /> 
              </attributes>
            </document>
          </documents>
        </folder>
      </folders>
      <documents>
          <document>
            <attributes>
              <attribute value="TRUE" name="xForceFolderSecurity" /> 
              <attribute value="wiki" name="dDocFunction" /> 
              <attribute value="Application" name="dDocType" /> 
              <attribute value="0" name="ishidden" /> 
              <attribute value="sysadmin" name="dDocOwner" /> 
              <attribute value="Presentation Dates" name="dDocTitle" /> 
              <attribute value="Presentation Dates.htm" 
                         name="dOriginalName" /> 
              <attribute value="FALSE" name="xInhibitUpdate" /> 
              <attribute value="0" name="isreadonly" /> 
              <attribute value="0" name="CustomInteger" /> 
              <attribute value="sysadmin" name="dDocCreator" /> 
              <attribute value="sysadmin" name="dDocAuthor" /> 
              <attribute value="OWCSVR01USORAC012758" name="dDocName" /> 
              <attribute value="1" name="dRevisionID" /> 
              <attribute value="sysadmin" name="dDocLastModifier" /> 
            </attributes>
          </document>
          <document>
            <attributes>
              <attribute value="TRUE" name="xForceFolderSecurity" /> 
              <attribute value="Document" name="dDocType" /> 
              <attribute value="sysadmin" name="dDocOwner" /> 
              <attribute value="0" name="ishidden" /> 
              <attribute value="ProjectedDesigns.pptx" name="dDocTitle" /> 
              <attribute value="ProjectedDesigns.pptx" 
                         name="dOriginalName" /> 
              <attribute value="FALSE" name="xInhibitUpdate" /> 
              <attribute value="0" name="isreadonly" /> 
              <attribute value="0" name="CustomInteger" /> 
              <attribute value="sysadmin" name="dDocCreator" /> 
              <attribute value="sysadmin" name="dDocAuthor" /> 
              <attribute value="OWCSVR01USORAC012747" name="dDocName" /> 
              <attribute value="1" name="dRevisionID" /> 
              <attribute value="sysadmin" name="dDocLastModifier" /> 
            </attributes>
          </document>
        </documents>
      </folder>
      <folder>
        <attributes>
          <attribute value="TRUE" name="xForceFolderSecurity" /> 
          <attribute value="sysadmin" name="dCollectionCreator" /> 
          <attribute value="Products" name="dCollectionName" /> 
          <attribute value="0" name="isLink" /> 
          <attribute value="sysadmin" name="dCollectionOwner" /> 
          <attribute value="sysadmin" name="dCollectionModifier" /> 
          <attribute value="1" name="dCollectionEnabled" /> 
        </attributes>
      </folder>
      <folder>
        <attributes>
          <attribute value="TRUE" name="xForceFolderSecurity" /> 
          <attribute value="sysadmin" name="dCollectionCreator" /> 
          <attribute value="TradeShows" name="dCollectionName" /> 
          <attribute value="0" name="isLink" /> 
          <attribute value="Page4.jspx" name="xWCPageId" /> 
          <attribute value="sysadmin" name="dCollectionOwner" /> 
          <attribute value="sysadmin" name="dCollectionModifier" /> 
          <attribute value="1" name="dCollectionEnabled" /> 
        </attributes>
        <documents>
          <document>
            <attributes>
              <attribute value="TRUE" name="xForceFolderSecurity" /> 
              <attribute value="Page4.jspx" name="xWCPageId" /> 
              <attribute value="wiki" name="dDocFunction" /> 
              <attribute value="Application" name="dDocType" /> 
              <attribute value="0" name="ishidden" /> 
              <attribute value="sysadmin" name="dDocOwner" /> 
              <attribute value="TradeShows.htm" name="dOriginalName" /> 
              <attribute value="TradeShows.htm" name="dDocTitle" /> 
              <attribute value="FALSE" name="xInhibitUpdate" /> 
              <attribute value="0" name="isreadonly" /> 
              <attribute value="0" name="CustomInteger" /> 
              <attribute value="sysadmin" name="dDocCreator" /> 
              <attribute value="sysadmin" name="dDocAuthor" /> 
              <attribute value="OWCSVR01USORAC012756" name="dDocName" /> 
              <attribute value="1" name="dRevisionID" /> 
              <attribute value="sysadmin" name="dDocLastModifier" /> 
            </attributes>
          </document>
        </documents>
      </folder>
    </folders>
  <documents>
    <document>
      <attributes>
        <attribute value="TRUE" name="xForceFolderSecurity" /> 
        <attribute value="Document" name="dDocType" /> 
        <attribute value="sysadmin" name="dDocOwner" /> 
        <attribute value="0" name="ishidden" /> 
        <attribute value="2011Plans.doc" name="dDocTitle" /> 
        <attribute value="2011Plans.doc" name="dOriginalName" /> 
        <attribute value="FALSE" name="xInhibitUpdate" /> 
        <attribute value="0" name="isreadonly" /> 
        <attribute value="0" name="CustomInteger" /> 
        <attribute value="sysadmin" name="dDocCreator" /> 
        <attribute value="sysadmin" name="dDocAuthor" /> 
        <attribute value="OWCSVR01USORAC012746" name="dDocName" /> 
        <attribute value="1" name="dRevisionID" /> 
        <attribute value="sysadmin" name="dDocLastModifier" /> 
      </attributes>
    </document>
  </documents>
</groupspace-folder>

40.1.15.4 Migrating Data from the Source Wiki Application to Spaces

To migrate content from an existing wiki application to WebCenter Portal: Spaces, perform the following steps:

  1. Prepare Spaces for import of the wiki content.

  2. Write and run a 'Custom Wiki Extraction Tool' to extract content from the Wiki application into an archive matching the precise format expected for use the Document Migration Utility.

  3. Use the Document Migration Utility to import the archive into Content Server.

  4. Create any wiki pages in Spaces to tie up with the content in Content Server.

These steps are described in more detail in the following sections:

40.1.15.4.1 Preparing WebCenter Portal: Spaces for Importing Wiki Content

On provisioning the Documents service in a space or space template, a folder is created in Content Server for that space or space template. The GUIDs of these folders must be determined in order to construct the archive to be used with the Document Migration Utility. The folder GUIDs can be determined by following steps below:

  1. Decide if you want to import all the wiki content into a single space or multiple spaces.

  2. Log into the Spaces application and create the spaces, taking note of the internal name of the group spaces.

    Ensure you are using a template which has the Documents service, otherwise you will have to provision Documents service and setup the role permissions after space creation.

  3. Log into Content Server.

  4. Ensure that the user's layout is Top Menus:

    1. Click the user's name to display the user's Profile page.

    2. Under User Personalization Settings check that Layout is set to Top Menu.

  5. For each space in which wiki content is to be imported, determine the folder GUID:

    1. Click Browse Content.

    2. Click on the root folder for the Spaces instance.

      This is the same as the Root Folder setting in the Content Server connection.

    3. Click the folder for the space.

      The folder name will be the same as the space's internal name.

    4. Click Info on the toolbar to display the folder information.

    5. Add IsSoap=1 to the URL.

    6. Search for the string dCollectionGUID. For example:

      <idc:field name="dCollectionGUID">05573322-E895-EDA3-8A83-07CF39CBDE05</idc:field>

  6. Keep a note of the space folder name and its GUID as the GUID is needed when building the archive in the next step.

40.1.15.4.2 Writing and Running a Custom Wiki Extraction Tool to Extract Content from the Wiki Application

To extract content from the source wiki application into an archive suitable for use with the Document Migration Utility, you'll need to write a custom application. For information about the format of the archive, see Section 40.1.15.3, "Understanding the Document Migration Utility."

The custom wiki extraction tool must perform the following steps:

  1. Extract and arrange the wiki content.

    Create a temporary directory and extract the wiki content from the source wiki application into it and arrange in the file system as it is to appear in Spaces.

  2. Clean up the source HTML of wiki documents.

    For each wiki document, edit the HTML to remove application-specific HTML tags.

  3. Re-write the URLs.

    For each wiki document, replace the existing URLs to content in the source wiki application to the URLs of the same artifacts that will be imported into Spaces.

  4. Build the ExportImportData.xml documents.

    For each root folder build the ExportImportData.xml document which describes the data in the export set and is used to drive the import

  5. Build the archive file.

    Create an archive of the manipulated wiki content that can be used to import the wiki content into Spaces.

Each of these steps is described more fully in the following sections:

40.1.15.4.3 Extracting and Arranging the Wiki Content

The wiki documents in the source application need to be extracted into a temporary directory on the file system and then arranged such that the file system mimics how the content is to be laid out in the target Spaces instance. If all the wiki documents are to be imported into a single space, all of the content should be laid out under a single root folder named with the GUID of the corresponding space folder in Content Server. If the wiki documents are to be imported into multiple spaces, the content should be laid out under multiple root folders, each named with the GUID of their corresponding folder in Content Server. For more information on determining the GUID of a space folder in Content Server, see Section 40.1.15.4.1, "Preparing WebCenter Portal: Spaces for Importing Wiki Content."

Note that when arranging the wiki content on the file system, you should consider how that content will be used in Spaces. For example:

  • If wiki pages are to be created, then the wiki document for that wiki page must be located under a folder of the same name. For more information about wiki pages, see Section 40.1.15.2, "Understanding Wiki Documents and Wiki Pages."

  • When a folder contains a large number of contents, the rendering of that folder's contents could be impaired.

  • Content Server has two settings that limit the number of folders and the number of files which can reside in a folder. When arranging your wiki content, ensure that a folder does not contain more folders than the folder limit setting or more documents than the document limit setting. For more information about folder and file limitations within a space, see Section 40.1.15.1.3, "Understanding Folder and File Limitations for a Folder."

To create extracted wiki content, perform the following tasks:

  1. Create root folders for each space into which you will be importing the wiki documents, name the folders based on the GUID of the corresponding space folder in Content Server.

  2. For wiki documents for which wiki pages will be created in WebCenter Portal: Spaces after import:

    1. Create a wiki folder with the same name as the wiki document.

    2. Place the wiki document in this folder.

    3. Place any other documents in this folder, if required.

    4. If there are related images and/or documents, add them to this wiki folder as well.

  3. For any other wiki documents, create the folder hierarchy that will contain the documents.

Example:

Space S1's folder in Content Server has a GUID of 21SD15F13B8_141D_421B_AD0e_BC54B6F16893. After import, the MarketingWiki and Tradeshows wiki pages will be created and it is expected these wiki pages will show the MarketingWiki.htm and Tradeshows.htm wiki documents.

The following shows the organized structure of the extracted wiki documents and artifacts:

21SD15F13B8_141D_421B_AD0e_BC54B6F16893 (Root space folder)
    Home.htm (Wiki document)
    MarketingWiki (Folder)
        MarketingWiki.htm (Wiki document)
    Branding (Folder)
        Presentation Dates.htm (Wiki document)
        Presentations (Folder)
    ProductBranding.pptx (File)
        ProjectedDesigns.pptx (File)
    Tradeshows (Folder)
        TradeShows.htm (Wiki document)
    Images (Folder)
        Image.jpg (Image)
40.1.15.4.4 Cleaning Up the Source HTML of Wiki Documents

In WebCenter Portal: Spaces, the wiki editor will remove any HTML tags when the wiki page is being edited. Therefore it is advisable to remove any such HTML tags in the wiki documents prior to importing them into WebCenter Portal: Spaces to avoid any confusion of tags being removed when editing a wiki document after import. The following tags can be safely removed:

<html>, </html>
<head>, </head>
<meta>, </meta>
<title>, </title>
<body>, </body>
<tbody>, </tbody>
<thead>, </thead>
<tfoot>, </tfoot>
<script>, </script>
<link>, </link>
40.1.15.4.5 Rewriting the URLs

Wiki pages in the source wiki application may contain URLs referencing artifacts in within the source wiki application, such as links for embedded images or to other wiki page or documents. These artifacts will be migrated to the target Spaces instance and these links will need to be updated to reference the new artifact locations in the target Spaces instance.

The following types of URLs in the extracted wiki pages need to be changed to reference the URLs of the same artifacts in Spaces:

  • Links to other Wiki pages

  • Links to embedded images

  • Links to documents

Follow the steps below to rewrite the URLs in the wiki documents:

  1. Define attributes for the target Spaces instance that will be used in the URL replacement in step 3.

    • WC_BASE_URL: WebCenter instance base URL

      Example: WC_BASE_URL=https://webcenter.example.com

    • UCM_ID: The name of the connection in Spaces to the Content Server

      Example: UCM_ID=dev_ucm

    • SPACE_GUID: The GUID of the space in Spaces where the content resides

      Example: SPACE_GUID=s21sd15f13b8_141d_421b_ad0e_bc54b6f16893

      For more information about determining the GUID, see Section 40.1.15.4.1, "Preparing WebCenter Portal: Spaces for Importing Wiki Content."

  2. For each content item, define the item attributes that will be used in the URL replacement in step 3.

    • FILE_NAME: File name of the content item

      Example: FILE_NAME=Home.htm

    • FILE_ID: Unique Content Server content ID

      Example: MARKETINGSPACE1001

    Note that the FILE_ID must be unique across the entire Content Server instance. A suggested value is the name of the space which the wiki documents are going to be imported into (with no space in the name) post-fixed with a unique number (in the example above, the space name was Marketing Space).

  3. Rewrite the URLs using the defined attributes as shown below:

    Embedded images

    • New URL format:

      IMG_REPLACE=img alt="FILE_NAME" resourceid="UCM_ID#dDocName:FILE_ID" src="WC_BASE_URL/webcenter/content/conn/UCM_ID/uuid/dDocName%3aFILE_ID"

    • Example:

      • Source URL:

        <img alt="image.jpg" src="images/image.jpg">

      • WebCenter URL:

        <img alt="image.jpg" resourceid="dev-ucm#dDocName:WSIMPORT4" src="http://webcenter.example.com/webcenter/content/conn/dev-ucm/uuid/dDocName%3aWSIMPORT4">

    Wiki pages

    • New URL format:

      URL_REPLACE=WC_BASE_URL/webcenter/faces/owResource.jspx?z=oracle.webcenter.doclib%21SPACE_GUID%21UCM_ID%2523dDocName%253AFILE_ID%21%21FILE_NAME

    • Example:

      • Source URL:

        <a href="Home.htm">Home</a>

      • WebCenter URL:

        <a href="http://webcenter.example.com/webcenter/faces/owResource.jspx?z=oracle.webcenter.doclib%21sd15f13b8_141d_421b_ad0e_bc54b6f16893%21dev-ucm%2523dDocName%253AWSIMPORT25%21%21Home.htm>Home</a>

    Links to documents

    • New URL format:

      DOCUMENT_REPLACE=WC_BASE_URL/webcenter/content/conn/UCM_ID/uuid/dDocName%3aFILE_ID

    • Example:

      • Source URL:

        <a href="MarketingWiki/Presentations/ProductBranding.pptx"> Download Product Branding Presentation</a>

      • WebCenter URL:

        <a href="http://webcenter.example.com/webcenter/content/dev-ucm/uuid/dDocName%3aWSIMPORT7"> Download Product Branding Presentation</a>

40.1.15.4.6 Building the ExportImportData.xml Documents

In each root folder containing the contents to be imported an ExportImportData.xml document needs to be created. The ExportImportData.xml document describes the contents of the root folder and is used to drive the import when importing the content into Spaces using the Document Migration Utility. For more information about the Document Migration Utility and the ExportImportData.xml document, see Section 40.1.15.3, "Understanding the Document Migration Utility."

Any metadata to be created with the document on import must be specified in the ExportImportData.xml document. In Spaces, wiki documents are stored as HTML documents but have extra metadata to identify them as wiki documents rather than normal HTML documents. Ensure the ExportImportData.xml document has this metadata specified for all wiki documents in the extracted contents. For more information about the metadata required for wiki document, see Section 40.1.15.2, "Understanding Wiki Documents and Wiki Pages."

Note:

A content ID (dDocName) is automatically generated by Content Server when a document is checked in without one being specified. If you wish your documents to have fixed content IDs, include the dDocName metadata with the document metadata in the ExportImportData.xml document. The dDocName must be unique across the whole Content Server or document check in will fail. A suggestion is to chose your own prefix for the content ID and append numbers incrementally to the end.

The ExportImportData.xml document can be generated manually for each root folder. Alternatively, you can write a custom script to traverse through the root folder contents and generate the document.

It is imperative for the structure of the contents on the file system is detailed in ExportImportData.xml document correctly. If there is a mismatch between the hierarchy of contents described in the ExportImportData.xml document and the file system, the import into the space folder in the target Content Server will fail.

Example:

In this example a custom script named convert_program traverses through a root folder called 21SD15F13B8_141D_421B_AD0e_BC54B6F16893 and creates an ExportImportData.xml document in the current working directory detailing the contents of the folder.

cd 21SD15F13B8_141D_421B_AD0e_BC54B6F16893
run convert_program
40.1.15.4.7 Building the Archive File

Create an archive of the extracted and manipulated wiki documents by zipping up the root space folders. The zip archive must have the root folders inside the archive rather than just the contents of the root folders. One zip file can contain multiple root folders for different spaces, or you can create one zip file for each root folder.

Example:

In the following example, wiki documents have been extracted and manipulated in a folder called 21SD15F13B8_141D_421B_AD0e_BC54B6F16893 in the folder /scratch/wikiexports and the archive to create is wsimport.zip.

cd /scratch/wikiexports
zip –r wcimport.zip 21SD15F13B8_141D_421B_AD0e_BC54B6F16893/

Note:

Ensure that the archive does not exist prior to zipping up the folder contents as some zip tools will add content to the specified archive if it already exists rather than overwriting the archive.

40.1.15.4.8 Using the Document Migration Utility to Import the Archive into the Target Space

Run the Document Migration Utility specifying generated archive in the previous step to import the content into the target Content Server. For information about using the Document Migration Utility, see Section 40.1.7.5.2, "Migrating Content Using the Document Migration Utility."

Log into the Spaces application and navigate to the spaces to which content was imported and ensure the content exists.

40.1.15.4.9 Creating Wiki Pages in Spaces for the Content in Content Server

To use WebCenter wiki pages to display the imported wikis, perform the steps below. For more information about wiki pages, see Section 40.1.15.2, "Understanding Wiki Documents and Wiki Pages."

  1. Log into Spaces.

  2. Locate the space where the content has been uploaded.

  3. Click Actions and select Create and Page.

  4. Give the wiki page a Name and select the Wiki page layout.

    Note that the name of the wiki page must match the name of the folder in the space folder in Spaces, which contains the wiki page of the same name.

    For example, if in the space folder you have a MarketingWiki folder and a MarketingWiki.htm document, the name of the wiki page must be MarketingWiki.

40.2 Exporting and Importing Framework Applications for Data Migration

This section describes how to export and import metadata and application customizations for portal applications developed using Oracle WebCenter Portal: Framework - referred throughout as Framework applications.

It includes the following sections:

40.2.1 Understanding Framework Application Export and Import

Several migration tools are available to export and import Framework application, their connections and customizations (that is, customizations applied to an application, pages, and portlets) between stage and production environments (Figure 40-12).

Figure 40-12 WebCenter Portal Application Export and Import

WebCenter Portal Application Import and Export

Table 40-4 lists available migration tools and their capabilities. All customizations listed in Table 40-4 are migrated with Framework applications.

Table 40-4 WebCenter Portal: Framework Application Migration Tools

Migration Tools Capabilities

Portlet Client WLST Commands

Enable export and import of portlet client metadata, and producer customizations and personalizations.

WebCenter Portal Resource WLST Commands

Enable export and import of WebCenter Portal resources, such as skins, page templates, and so on.

MDS WLST Commands

Enables export and import of:

  • Framework application metadata including customizations made to pages and WebCenter Portal services

  • Data stored in the connections.xml and adf-config.xml documents

Migration WLST Commands

Enables export and import of security policies, including roles and mapping of users and roles.

Oracle Database Utilities

Enables export and import of Framework application data. For information, see the part "Oracle Data Pump" in the Oracle Database Utilities guide.

Non-Oracle database utilities

Refer to the database manufacturer's documentation for information about their data migration tools.

40.2.2 Prerequisites for Framework Application Export and Import

Before exporting or importing metadata and customizations for a Framework application, ensure the following:

  • The database in which the application metadata and schema is stored is up and running.

  • The target instance is configured with the same set of services as the source instance. Additional services can be configured in the target, if required, but minimally, service configuration in the source and target must match.

  • The jps.policystore.removal parameter is set to OFF in your application's weblogic-application.xml so that policies are migrated on import:

    <application-param>
    <param-name>jps.policystore.removal</param-name>
    <param-value>OFF</param-value>
  </application-param>

    If this option is not set, no policy information is imported. In some instances you may not want to migrate policy data, for example, when migrating from a test environment to a production environment where test data is not required. Note however, that pages created on the source instance at runtime do not display on the target instance because no page grants exist on the target.

40.2.3 Exporting Portlet Client Metadata (Framework Applications)

To export portlet client metadata and producer customizations and personalizations, for a Framework application, use the WLST command exportPortletClientMetadata. This command is run on the entire application, and therefore, it exports metadata of all the producers stored in an application. You cannot opt to export metadata for specific producers.

For detailed syntax and examples, see "exportPortletClientMetadata" in Oracle Fusion Middleware WebLogic Scripting Tool Command Reference.

For information on how to run WLST commands, see Section 1.13.3.1, "Running Oracle WebLogic Scripting Tool (WLST) Commands."

For information on how to export portlet client metadata associated with all applications, see "How to Manage the Persistence Store for JSR 286 Portlets" and "Migrating a PDK-Java Producer Persistence Store" in Oracle Fusion Middleware Developer's Guide for Oracle WebCenter Portal.

40.2.4 Importing Portlet Client Metadata (Framework Applications)

To import portlet client metadata and producer customizations and personalizations, for a Framework application, use the WLST command importPortletClientMetadata.

Prerequisites:

For detailed syntax and examples, see "importPortletClientMetadata" in Oracle Fusion Middleware WebLogic Scripting Tool Command Reference. See also, "Metadata Services (MDS) Custom WLST Commands".

For information on how to run WLST commands, see Section 1.13.3.1, "Running Oracle WebLogic Scripting Tool (WLST) Commands."

40.2.5 Exporting WebCenter Portal Resources (Framework Applications)

Authorized users can download application resources, such as skins and page templates, while a Framework application is running, edit and extend them in tools such as Oracle JDeveloper, and then upload them back to the Framework application. Users who want to share or migrate resources to other Framework applications can use the download feature too.

You can download the following portal resources at runtime through the WebCenter Portal Administration Console:

  • Skins

  • Page Styles

  • Page Templates

  • Content Presenter Templates

  • Navigations

  • Resource Catalogs

  • Task Flows

  • Mashup Styles

When you download (or export) a WebCenter Portal resource, the resource details are saved to a WebCenter Portal export archive (.EAR). You can save the export archive to your local file system or a remote server file system using a filename of your choice.

For details, see Section 37.5.8, "Downloading and Uploading a Resource".

Alternatively, system administrators can perform the same task using the WLST command exportWebCenterResource. For command syntax and examples, see "exportWebCenterResource" in the Oracle Fusion Middleware WebLogic Scripting Tool Command Reference.

40.2.6 Importing WebCenter Portal Resources (Framework Applications)

Authorized users can import application resources, such as skins and page templates, while a Framework application is running. You can import the following resources at runtime through the WebCenter Portal Administration Console:

  • Skins

  • Page Styles

  • Page Templates

  • Content Presenter Templates

  • Navigations

  • Resource Catalogs

  • Task Flows

  • Mashup Styles

You can import resources previously saved to WebCenter Portal export archive files (.ear), on your local or remote server file system. Existing resources, that is, resources with the same internal ID are overwritten on import.

For details, see Section 37.5.8, "Downloading and Uploading a Resource".

Alternatively, administrators can perform the same task using the WLST command importWebCenterResource. For command syntax and examples, see "importWebCenterResource" in the Oracle Fusion Middleware WebLogic Scripting Tool Command Reference.

For information on how to run WLST commands, see Section 1.13.3.1, "Running Oracle WebLogic Scripting Tool (WLST) Commands."

40.2.7 Exporting WebCenter Portal Service Metadata and Data (Framework Applications)

The metadata created by WebCenter Portal services is stored in the Oracle metadata store (MDS). For detailed information about MDS, see the chapter "Managing the Oracle Metadata Repository" in Oracle Fusion Middleware Administrator's Guide.

To export base documents for WebCenter Portal services, together with their customizations, use the WLST command exportMetadata.

For example:

exportMetadata(application='myWebCenterApp', server='WC_CustomPortal', toLocation='/tmp/myrepos', docs='/oracle/webcenter/**')

Where:

  • application: Name of the Framework application for which the metadata is to be exported (for example, myWebCenterApp).

  • server: Server on which the Framework application is deployed (for example, WC_CustomPortal).

  • toLocation: Target directory to which documents selected from the source partition are to be exported. The toLocation parameter can be used as a temporary file system for migrating metadata from one server to another.

  • docs: List of comma separated fully qualified document name(s) and/or document name patterns (* and ** patterns).

    In this example, "docs='/oracle/webcenter/**" exports the required documents for all WebCenter Portal services storing metadata in MDS.

Note:

The "docs='/oracle/webcenter/**" command does not export portlet customizations and personalizations or changes to configuration files such as connections.xml and adf-config.xml.

For detailed syntax and examples, see "exportMetadata" in Oracle Fusion Middleware WebLogic Scripting Tool Command Reference.

For information on how to run WLST commands, see Section 1.13.3.1, "Running Oracle WebLogic Scripting Tool (WLST) Commands."

Customizations listed in Table 40-5 are also exported when Framework applications are migrated between stage and production environments.

Metadata for WebCenter Portal services, which consists of base and customization documents, are stored in the following paths:

  • Analytics:/oracle/webcenter/analytics/**

  • Announcements: /oracle/webcenter/collab/announcement/**

  • Blogs: /oracle/webcenter/blog/**

  • Documents: /oracle/webcenter/doclib/** and /oracle/webcenter/doclib/view/jsf/fragments/**

  • Discussions: /oracle/webcenter/collab/forum/**

  • General Settings: /oracle/webcenter/generalsettings/**

  • Events:/oracle/webcenter/collab/events/**

  • External Applications:/oracle/webcenter/admin/** and oracle/adfinternal/extapp/**

  • Instant Messaging and Presence: /oracle/webcenter/collab/rtc/**

  • Links: /oracle/webcenter/relationship/**

  • Language: /oracle/webcenter/webcenterapp/**

  • Lists: /oracle/webcenter/list/** and /oracle/webcenter/list/view/jsf/regions/**

  • Mail: /oracle/webcenter/collab/mail/**

  • Navigations: /oracle/webcenter/navigationtaskflows/**

  • Notes: /oracle/webcenter/note/**

  • Page: /oracle/webcenter/page/** and /pageDefs/**

  • Polls: /oracle/webcenter/collab/survey/**

  • People Connections (Connections):/oracle/webcenter/peopleconnections/connection/**

  • People Connections (Feedback):/oracle/webcenter/peopleconnections/kudos/**

  • People Connections (Profile Gallery):/oracle/webcenter/peopleconnections/personalweb/**

  • People Connections (Profile):/oracle/webcenter/peopleconnections/profile/**

  • People Connections (Message Board):/oracle/webcenter/peopleconnections/wall/**

  • Polls: /oracle/webcenter/collab/survey/**

  • Recent Activity: /oracle/webcenter/recentactivity/**

  • Resource Action Handler: /oracle/webcenter/framework/service/**

  • RSS News Feed: oracle/webcenter/rssviewer/**

  • Scope: /oracle/webcenter/framework/scope/**

  • Search: /oracle/webcenter/search/**

  • Security: /oracle/webcenter/security/**

  • Smart Tag: /oracle/webcenter/collab/smarttag/**

  • Space Browser: /oracle/webcenter/community/**

  • Space Contacts: /oracle/webcenter/people/**

  • Subscriptions: /oracle/webcenter/notification/**

  • Tags: /oracle/webcenter/tagging/**

  • adf-config.xml, connections.xml: /META-INF/mdssys/cust/adfshare/adfshare/**

    Configuration file updates are not stored under the /oracle/webcenter/ directory alongside WebCenter Portal services. To export customizations associated with these files, run exportMetadata again with "docs='META-INF/mdssys/cust/adfshare/adfshare/**". See also, Appendix A, "adf-config.xml and connections.xml".

40.2.8 Importing WebCenter Portal Service Metadata and Data (Framework Applications)

To import WebCenter Portal service metadata and customizations for a Framework application, use the WLST command importMetadata. For example:

importMetadata(application='myWebCenterApp', server='WC_CustomPortal', fromLocation='/tmp/myrepos', docs='/**')

Where:

  • application: Name of the Framework application for which the metadata is be imported (for example, myWebCenterApp).

  • server: Name of the target server on which the application is deployed (for example, WC_CustomPortal).

  • fromLocation: Source directory from which documents are imported. The fromLocation parameter can be any temporary file system location for migrating metadata from one server to another.

  • docs: List of comma separated fully qualified document name(s) and/or document name patterns (* and ** patterns).

For detailed syntax and examples, see "importMetadata" in Oracle Fusion Middleware WebLogic Scripting Tool Command Reference.

See also, Section 1.13.3.1, "Running Oracle WebLogic Scripting Tool (WLST) Commands."

40.2.9 Migrating Security for WebCenter Portal Applications

Security migration involves moving the identity store, credential store, and policy store, from one WebCenter Portal application to another. The process is the same for all WebCenter Portal applications so you can follow the same instructions provided for the Spaces application:

40.2.10 Migrating Data (WebCenter Portal Applications)

To export the WebCenter Portal application data, use the export and import database utilities. This section includes the following sub sections:

40.2.10.1 Exporting Data (WebCenter Portal Applications)

To export WebCenter Portal application data, use the appropriate database utility:

  • For an Oracle database, go to ORACLE_HOME/bin of your database and run the command described in Example 40-14.

  • For non-Oracle databases, refer to the manufacturer's documentation.

Example 40-14 Data Pump Utility (Export)

DB_ORACLE_HOME/bin/expdp \"sys/password@serviceid as sysdba\" OWNER=srcrcuprefix_WEBCENTER FILE=wc.dmp STATISTICS=none

where:

  • DB_ORACLE_HOME is the directory in which the database for the Oracle WebCenter Portal schema is installed.

  • password is the password for system database user.

  • serviceid is the service ID of the database connection.

  • OWNER is the schema to be exported. This is the RCU suffix that was used during installation along with the suffix _WEBCENTER. For example, DEV_WEBCENTER.

  • FILE contains the exported data.

For more information, see "Oracle Data Pump" in the Oracle Database Utilities guide.

40.2.10.2 Importing Data (WebCenter Portal Applications)

To import WebCenter Portal application data, use the appropriate database utility:

  • For an Oracle database, go to ORACLE_HOME/bin of your database and run the command described in Example 40-15

  • For non-Oracle databases, refer to the manufacturer's documentation.

Example 40-15 Data Pump Utility (Import)

DB_ORACLE_HOME/bin/impdp  \"sys/password@serviceid as sysdba\" remap_schema=srcrcuprefix_WEBCENTER:tgtrcuprefix_WEBCENTER
remap_tablespace=source_tablespace:target_tablespace DUMPFILE=wc.dmp STATISTICS=none TRANSFORM=oid:n

where:

  • DB_ORACLE_HOME is the directory in which the database for the Oracle WebCenter Portal schema is installed.

  • password is the password for system database user.

  • serviceid is the service ID of the database connection.

  • REMAP_SCHEMA identifies the source and target schemas. For example, schema names include the RCU suffix that was used during installation, _WEBCENTER, along with the user supplied prefix. For example, DEV_WEBCENTER.

  • REMAP_TABLESPACE identifies the source and target tablespace. Remaps all objects selected for import with persistent data in the source tablespace to be created in the target tablespace. For example, source_tablespace:target_tablespace.

  • DUMPFILE contains the data to be imported.

For more information, see "Oracle Data Pump" in the Oracle Database Utilities guide.

40.3 Backing Up and Recovering WebCenter Portal Applications

To recover data from disasters, such as the loss of database hardware, inadvertent removal of data from file or database, it is important to back up WebCenter Portal applications on a frequent basis. The frequency of backup depends on how often the underlying information stored by WebCenter Portal changes in a particular customer application, and how much time and amount of information could acceptably be lost. Incremental or partial backups may be applied where the data is critical to the business and must be restored due to a failure.

Backup and recovery of WebCenter Portal components can be managed through database export and import utilities, and various other tools. For more information, see "Part IV Advanced Administration: Backup and Recovery" in Oracle Fusion Middleware Administrator's Guide.

40.4 Troubleshooting Import and Export Issues for Spaces

This section contains the following subsections:

40.4.1 ResourceLimitException Issue

Problem

The ResourceLimitException error displays when you try to export all spaces or an entire Spaces application:

Weblogic.common.resourcepool.ResourceLimitException

Solution

Increase the maximum capacity in the JDBC connection pool. To reconfigure the connection pool, log in to the WLS Administration Console. From Services, select Data Sources, JDBC, and then the Connection Pool tab.

40.4.2 Spaces and Space Templates Not Available After Import

Problem

When you first log in to the Spaces application after the import operation, the spaces and space templates that you migrated are not available as expected. This can sometimes occur if the space/space template cache fails to refresh properly.

Solution

Refresh the space/space template cache manually using the refreshGroupSpaceCache and refreshSpaceTemplateCache WLST commands.

To completely clear the cache (all spaces):

refreshGroupSpaceCache(appName='webcenter', spaceNames='', syncMode=1,updateType='all', cleanCache=1)

To completely clear the cache (all space templates):

refreshSpaceTemplateCache(appName='webcenter', spaceTemplateNames='',syncMode=1, updateType='all', cleanCache=1)

For detailed command syntax and examples, see "refreshGroupSpaceCache" and "refreshSpaceTemplateCache" in the Oracle Fusion Middleware WebLogic Scripting Tool Command Reference.

For information on how to run WLST commands, see Section 1.13.3.1, "Running Oracle WebLogic Scripting Tool (WLST) Commands."

40.4.3 Exporting and Importing Spaces in Multibyte Languages

Problem

On Linux, individual space export or import fails for one or more spaces created in multibyte languages due to naming restrictions. Space names are restricted to alphanumeric and space characters ("a" through "z", "A" through "Z", "0" through "9", and the single-byte space character, which Spaces replaces with "_"(underscore) ). If any other characters are used in the space name, export or import fails.

Solution

Enforce the naming restriction on the server on which Oracle WebCenter Portal is deployed. To do this, set the environment variable LC_ALL set to utf-8.

40.4.4 Page or Space Not Found Messages After Import

Problem

When you first log in to Spaces after an import operation you may see a "Page not found" or "Space not found" message if the page or space you last visited no longer exists. Such messages display because "last accessed" page information is retained during an import operation.

Solution

No action required. You will not see the message the next time you log in.

40.4.5 Space Import Archive Exceeds Maximum Upload File Size

Problem

There is a file size limitation uploading content to Spaces. If your export archive exceeds the maximum upload size then the import operation through Spaces administration fails.

Solution

Import the space archive using WLST. For details, see Section 40.1.9.2, "Importing Individual Spaces Using WLST."

Alternatively, modify the content repository upload parameter in web.xml. The default maximum upload size is 2 GB. See also, "Section A.1.2, "web.xml"" in Appendix A, "WebCenter Portal Configuration."

40.4.6 Lists Not Imported Properly

Problem

Lists are not importing properly due to list definition differences in the source and target systems.

Solution

Consider exporting and importing list data. This ensures that list data is consistent with the list definitions being imported.

If you choose to import without data, the list data in the target system is changed to be consistent with the imported list definitions. If a list column data type is changed, the column values are converted from the target data type to the imported data type, if possible, otherwise the value is deleted. If a list column is removed during import, the column values are deleted.

40.4.7 Importing Spaces Customizations

When you migrate a Spaces application you can choose whether certain application customizations are imported using the option "Include Customizations". Table 40-5 highlights those services and task flows that store application customizations, and which are optional on migration. Table 40-6 lists application-level and space-level settings which are optional.

Note:

User customization are never migrated during export and import.

Table 40-5 Spaces Services - Application Customizations

Services in Spaces Application Customizations Optional/Always

Analytics Service

None

  

Analytics Page and Task Flows

Report preferences in page edit mode (Chart, Data Selection, Filtering, Grouping)

Optional

Announcements Service

None

  

Announcement Tab

None

  

Announcement Task Flow

None

  

Discussions Service

    

Sidebar

None

  

Discussions Tab

None

  

Discussion Forum Manager Task Flow

None

  

Forum Task Flow

None

  

Discussion Task Flows

None

  

Documents Service

    

Documents Tab

None

  

Document Manager Task Flow

  • Document Manager display preferences, such as, Description, Size, Status, Modified by, Last Modified, Links, and so on.

  • Table column settings, such as, visible columns, column sizes, and ordering.

See also, "Understanding the Document Manager Task Flow" in Oracle Fusion Middleware User's Guide for Oracle WebCenter Portal: Spaces.

Optional

Document List Viewer Task Flow

Table column settings, such as, visible columns, column sizes, and ordering.

In page edit mode, default fields that display document search results can be customized and additional fields can be added.

Group Space Documents

See also, "Understanding the Document List Viewer Task Flow" in Oracle Fusion Middleware User's Guide for Oracle WebCenter Portal: Spaces.

Optional

Content Presenter Task Flow

Content presenteIn page edit mode, content and display template settings.

See also, "What You Should Know About the Content Presenter Task Flow" in Oracle Fusion Middleware User's Guide for Oracle WebCenter Portal: Spaces.

Optional

Recent Documents Task Flow

None

  

Events Service

    

Events Tab

None

  

Events Task Flow

Page edit mode:

- Task flow customizations: Display Mode, Grid Start Hour, Second Timezone. - Calendars overlay properties: Name, Order, Color and Visibility.

Optional

Lists Service

    

List Tab

None

  

List Viewer Task Flow

Page edit mode:

  • Banding type and interval, and column filter settings

    Banding type and interval

  • Column settings: Sort column and sort direction (ascending, descending), column sizes, and column order

See also, "Working with the Lists Service" in Oracle Fusion Middleware User's Guide for Oracle WebCenter Portal: Spaces.

Optional

List Manager Task Flow

None

  

Mail Service

    

Sidebar

None

  

Mail Task Flow

None

  

Notes Service

None

  

Pages

Page edit mode: task flow and portlet customizations using Composer, such as, Maximize, Move, Vertical Height

Always
 

Page properties: Page Name, Description, Keywords, Scheme, Scheme Background Color, Page Security, Page Parameters, Page modified date, and so on.

Always
 

Component properties: Title, Background Color, and so on.

Always

People Connection Service

    

Activity Stream Task Flow

Display options for the Activity Stream task flow.

Optional

Portlets

Customizations/edit defaults (if any) stored in the producers.

Always

Recent Activities Service

None

  

Resource Catalog

None

  

RSS News Feed Service

None

  

Search Service

None

  

Saved Search

Shared/Private option for saved searches.

Saved search customizations.

Optional

Tags Service

    

Tags

None

  

Tags Center

None

  

Tag Sidebar

None

  

Worklist Service

None

  

Table 40-6 Spaces - Application Customizations

Spaces Customizations Export

Application Settings

  

Optional

Configuration: General tab

All properties

  

Configuration: General tab

Language

  

Configuration:Services tab

Default settings for Discussions, Mail, and People Connections (Profiles, Message Boards, Feedback, Connections, Activity Streams)

  

Pages: Business Role Pages tab

Settings such as Set Page Defaults and display order

  

Pages: System Pages

Page customizations

  

Space Settings

  

Optional

Spaces Settings: General tab

All properties

  

Spaces Settings: Pages tab

Settings such as, Set Page Defaults, Order, and Show Page

Page and system page customizations

  

Spaces Settings: Resource tab

Application level resources edited for use in a space

  

Spaces Settings: other tabs

All properties

  

40.4.8 Exporting and Importing Spaces with Services Configured

Problem

The following error message displays when you try to export a space with services configured, and try to import the same space from an instance where some or all of those services are not configured.

No handlers could be found for services with IDs: <list of service IDs that are not present in the target instance but prsent in the archive>

For example:

No handlers could be found for services with IDs:  oracle.webcenter.collab.forum oracle.webcenter.collab.rtc

Solution

You can work around this problem by either adding the services to the target, or removing the service-related info from the data.xml file of the archive as described below.

To remove service-related info:

  1. Extract the archive.

    The archive contains two files: policy-store.xml and transport.mar.

  2. Expand the transport.mar into a directory.

    The data.xml file is located in the oracle\webcenter\lifecycle\importexport directory.

  3. Remove the service tags for all the services that are not present in the target as listed in the error message.

    For the example error message above, we would need to remove the following:

          <service id="oracle.webcenter.collab.forum" version="11.1.1.0">
         <metadataUsages>
            <metadataUsage includeBaseDocuments="YES" includeSystemCustomizations="YES">
               <paths>
                  <include path="/oracle/webcenter/collab/forum/scopedMD/s516227ec_dde1_4991_9e18_28d487cb3bce/**"/>
               </paths>
            </metadataUsage>
         </metadataUsages>
      </service>
 
   <service id="oracle.webcenter.collab.rtc" version="11.1.1.0"/>

  4. Repack the transport.mar file by zipping the top-level directories Oracle and pagedefs into a file named transport.mar.

  5. Repack the export archive by zipping the newly created transport.mar and the policy-store.xml file into an archive.

  6. Import the new archive.

For the example error message above, we would need to remove the following:

40.4.9 Unable to Migrate Spaces or Documents If the Source and Target Applications Share the Same Content Server

You cannot migrate spaces or space templates between two different Spaces applications that share the same Content Server.

Similarly, you cannot use the Document Migration Utility to migrate space documents between two different Spaces applications that share the same Content Server.