| Oracle® Fusion Middleware Administrator's Guide for Oracle WebCenter Portal 11g Release 1 (11.1.1.6.0) Part Number E12405-16 |
|
|
PDF · Mobi · ePub |
| Oracle® Fusion Middleware Administrator's Guide for Oracle WebCenter Portal 11g Release 1 (11.1.1.6.0) Part Number E12405-16 |
|
|
PDF · Mobi · ePub |
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:
Section 39.1, "Exporting and Importing a Spaces Application for Data Migration"
Section 39.2, "Exporting and Importing Framework Applications for Data Migration"
Section 39.3, "Migrating Wiki Documents from External Applications"
Section 39.4, "Backing Up and Recovering WebCenter Portal Applications"
Section 39.5, "Troubleshooting Import and Export Issues for Spaces"
To best plan the proper usage of these tools, record which WebCenter Portal features your WebCenter Portal applications are using: Spaces, Framework, Discussion server, Oracle WebCenter Content Server, and so on.
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. This section describes an alternative approach to the steps described in this chapter (some of the steps are automated).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".
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:
Section 39.1.6, "Prerequisites for Individual Space Export and Import"
Section 39.1.7, "Migrating Back-end Components for Individual Spaces"
Migrating space templates:
Migrating Spaces resources:
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 39-1.
This migration can be performed using Fusion Middleware Control or WLST commands. For details, see:
Section 39.1.4.1, "Exporting the Spaces Application Using Fusion Middleware Control"
Section 39.1.4.2, "Exporting the Spaces Application Using WLST"
Section 39.1.5.1, "Importing a Spaces Application Using Fusion Middleware Control"
Section 39.1.5.2, "Importing a Spaces Application Using WLST"
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 39-1. If you want to migrate application-level customizations you must set the export option "Include Customizations". For more information, reference Table 39-4, "Spaces Services - Application Customizations" and Table 39-5, "Spaces - Application Customizations" at the end of this chapter.
User-level customizations are not migrated during export and import. For more information on application customization and user customization and the difference between them, see "What You Should Know About Customizing Page Components" in the Oracle Fusion Middleware User's Guide for Oracle WebCenter Portal: Spaces.
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 39.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.
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:
Section 39.1.3.3, "Exporting and Importing the LDAP Credential Store"
Section 39.1.3.4, "Exporting and Importing the LDAP Policy Store"
Section 39.1.3.5, "Exporting and Importing a File-based Credential Store"
Section 39.1.3.6, "Exporting and Importing a File-based Policy Store"
Section 39.1.3.11, "Exporting Oracle WebLogic Communications Server"
Section 39.1.3.12, "Importing Oracle WebLogic Communications Server"
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 39-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 39-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 39-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.
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 39-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 39-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.
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.
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:
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
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.
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"
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>
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>
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">
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>
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
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.
To import the credential store, run the WLST command migrateSecurityStore.
For example (Example 39-3):
Example 39-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", overWrite="true", srcFolder="<source folder>", dstFolder="<destination folder>")
For detailed syntax and examples, see "migrateSecurityStore" in Oracle Fusion Middleware WebLogic Scripting Tool Command Reference.
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 39.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 themigrateSecurityStore 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.
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:
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
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.
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"
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>
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">
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>
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>
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
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.
To import the policy store, run the WLST command migrateSecurityStore.
For example (Example 39-4):
Example 39-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.
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.
Backup your target's jps-config.xml file located at DOMAIN_HOME/config/fmwconfig/jps-config.xml.
Add source and target information to the target's jps-config.xml:
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.
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>
Import the file-based credential store using the WLST command migrateSecurityStore.
For example (Example 39-5):
Example 39-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.
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 39.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 themigrateSecurityStore 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.
Backup your target's jps-config.xml file located at DOMAIN_HOME/config/fmwconfig/jps-config.xml.
Add source and target information to the target's jps-config.xml:
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.
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>
Import the file-based credential store using the WLST command migrateSecurityStore.
For example (Example 39-6):
Example 39-6 migrateSecurityStore - Credential 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>
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 run the command described in Example 39-7.
For non-Oracle databases, refer to the manufacturer's documentation.
Note:
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.Example 39-7 Export Database Utility
DB_ORACLE_HOME/bin/expdp \"sys/password@serviceid as sysdba\" OWNER=srcrcuprefix_DISCUSSIONS DUMPFILE=/tmp/df.dmp STATISTICS=none
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.
OWNER 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.
DUMPFILE contains the exported 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.
Note:
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.Shut down the target discussions server.
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"
Drop the target user:
drop user tgtrcuprefix_DISCUSSIONS cascade;
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.
Grant connect and resource to the user:
grant connect,resource to tgtrcuprefix_DISCUSSIONS;
Exit sqlplus.
Run the import tool as described in Example 39-8.
Example 39-8 Database Import Utility
DB_ORACLE_HOME/bin/impdp \"sys/password@serviceid as sysdba\" remap_schema=srcrcuprefix_DISCUSSIONS:tgtrcuprefix_DISCUSSIONS remap_tablespace=source_tablespace:target_tablespace DUMPFILE=/tmp/df.dmp STATISTICS=none
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.
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:
For non-Oracle databases, refer to the manufacturer's documentation.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 39-9.
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 39-9 Data Pump Utility (Export)
DB_ORACLE_HOME/bin/expdp \"sys/password@serviceid as sysdba\" OWNER=srcrcuprefix_OCSERVER DUMPFILE=/tmp/ucm.dmp STATISTICS=none
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.
OWNER 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.
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
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
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:
For non-Oracle databases, refer to the manufacturer's documentation.Shut down the target Content Server.
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"
Drop the target user:
drop user tgtrcuprefix_OCSERVER cascade;
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.
Grant connect and resource to the user:
grant connect,resource to tgtrcuprefix_OCSERVER;
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 39-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 39-10 Data Pump Utility (Import)
DB_ORACLE_HOME/bin/impdp \"sys/password@serviceid as sysdba\" remap_schema=srcrcuprefix_OCSERVER:tgtrcuprefix_OCSERVER remap_tablespace=source_tablespace:target_tablespace DUMPFILE=/tmp/UCM.dmp STATISTICS=none TRANSFORM=oid:n
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.
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.
For information on exporting Oracle WebLogic Communications Server, see Oracle WebLogic Communication Services Administrator's Guide.
For information on importing Oracle WebLogic Communications Server, see Oracle WebLogic Communication Services Administrator's Guide.
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 the appendix "Portlet Preference Store Migration Utilities" in Oracle Fusion Middleware Developer's Guide for Oracle WebCenter Portal.
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 the appendix "Portlet Preference Store Migration Utilities" in Oracle Fusion Middleware Developer's Guide for Oracle WebCenter Portal.
This section describes how to export an entire Spaces application using Fusion Middleware Control and WLST commands.
A Spaces application is exported into a single export archive (.ear file). The EAR file contains:
a metadata archive (.mar ) file
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 39.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 see an "application unavailable" page.
The export process does not include data associated with external services, that is, Mail, Discussions, Announcements, Worklists, Personal Events, Instant Messaging and Presence (IMP), and Documents. To learn how to move data associated with these services, see Section 39.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 39.1.3, "Migrating Back-end Components for an Entire Spaces Application."
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. For more information on user customizations, see the section What You Should Know About Customizing Page Components" in the Oracle Fusion Middleware User's Guide for Oracle WebCenter Portal: Spaces.
This section includes the following:
Section 39.1.4.1, "Exporting the Spaces Application Using Fusion Middleware Control"
Section 39.1.4.2, "Exporting the Spaces Application Using WLST"
Fusion Middleware administrators can export an entire Spaces application using Fusion Middleware Control.
In Fusion Middleware Control, navigate to the home page for Spaces.
See Section 6.2, "Navigating to the Home Page for the Spaces Application."
From the WebCenter Portal menu, select Application Export, as shown in Figure 39-2.
Figure 39-2 WebCenter Portal Menu - Application Export Option
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 39-3.
Set export options as required. For details, see Table 39-1.
Table 39-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 contain a large amount of data, consider using the database export utilities to export (and import) the WebCenter Portal schema data instead. For example: DB_ORACLE_HOME/bin/expdp \"sys/password@serviceid as sysdba\" OWNER=srcrcuprefix_WEBCENTER DUMPFILE=/tmp/WCS.dmp STATISTICS=none DB_ORACLE_HOME/bin/impdp \"sys/password@serviceid as sysdba\" remap_schema=srcrcuprefix_WEBCENTER:tgtrcuprefix_WEBCENTER remap_tablespace=source_tablespace:target_tablespace DUMPFILE=/tmp/WCS.dmp STATISTICS=none TRANSFORM=oid:n 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 39.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 39-4 and Table 39-5. If you deselect this option, WebCenter Portal: Spaces is exported without these application customizations. Portlet and page customizations are always exported. See also Figure 39-1, "Information Exported with a Spaces Application". |
Click Export.
In the Download dialog, as shown in Figure 39-4, click Export to confirm that you want to go ahead.
Figure 39-4 Downloading an Export Archive
Progress information is displayed during the export process. The application being exported cannot be accessed during export operations.
When the export process is complete, specify a location for the export archive (.ear).
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 39-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.
Click Close to dismiss the Export window.
The export archive (.EAR) is saved to the specified location.
Check the diagnostic log file, WC_Spaces-diagnostics.log, for any warnings or errors reported during the export process. To view the log file, choose the menu option WebCenter > Logs > View Log Messages. For details, see Section 34.3, "Viewing and Configuring Log Information". See also Section 39.5, "Troubleshooting Import and Export Issues for Spaces."
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."
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 39.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 39.4, "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 29.5, "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 Spaces 11.1.1.4.0. If necessary, you must upgrade to 11.1.1.4.0 before you create the export archive. For details, "Patching Oracle WebCenter" in Oracle Fusion Middleware Patching Guide.
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:
Section 39.1.5.1, "Importing a Spaces Application Using Fusion Middleware Control"
Section 39.1.5.2, "Importing a Spaces Application Using WLST"
Fusion Middleware administrators can import an entire WebCenter application using Fusion Middleware Control.
To import a Spaces application using Fusion Middleware Control:
In Fusion Middleware Control, navigate to the home page for Spaces.
See Section 6.2, "Navigating to the Home Page for the Spaces Application."
From the WebCenter Portal menu, select Application Import.
In the Spaces Application Import page (Figure 39-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 39-7 Spaces Application Import Page
Click Import.
In the Spaces Application Import dialog (Figure 39-8), click Import.
Figure 39-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 39.1.5.3, "Verify an Imported Spaces Application".
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 39.1.5.3, "Verify an Imported Spaces Application".After importing an entire Spaces application you must:
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."
Log in to the Spaces application and verify that all spaces and space templates are available as expected.
If not, see Section 39.5.2, "Spaces and Space Templates Not Available After Import".
Initiate the Oracle Secure Enterprise Search crawler to index newly imported data.
See also, Oracle Secure Enterprise Search Administrator's Guide.
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 39.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.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.
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:
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:
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.
Click Spaces.
Select the space you want to export, then choose Edit Space from the Edit menu.
Click Services, then Discussions.
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 39.1.9.1, "Importing Individual Spaces Using the Spaces Application" - Step 11.
Click Forum Administration, and login to the Admin Console.
In the Admin Console, select the System menu and choose XML Export & Import in the sidebar.
Select Data Export.
Set the following options (Figure 39-9):
Export Options - Select Custom Options, and select all the check boxes.
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.
Export location, Export filename, Export file encoding - Keep the default values.
Click Start Export.
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 39.1.9.1, "Importing Individual Spaces Using the Spaces Application."
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 39.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:
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:
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.
Click Spaces.
Select the space for which you want to import data, and then choose Edit Space from the Edit menu.
Click Services, then Discussions.
Click Forum Administration (on the far right), and log into the Admin Console.
In the Admin Console, select the System menu and then choose XML Export & Import in the sidebar.
Select Data Import.
Choose the appropriate space export file from the list available (Figure 39-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 39.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/.
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.
Select the Content menu, and then choose Content Summary in the sidebar.
All the categories and forums in the system are listed here.
Select WebCenter, and then click the Move button for the newly imported forum or category.
Select the root category for the target Spaces application, and click Move Categories.
The Category Summary page shows the new location.
Click Permissions in the sidebar.
Deselect all the permissions for the User Types: Anyone and Registered Users, and click Save Changes (Figure 39-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:
Log into Spaces with administrative privileges.
See "Accessing Spaces Administration Pages" in the Oracle Fusion Middleware User's Guide for Oracle WebCenter Portal: Spaces.
Open Spaces Administration.
Click Spaces.
Select the space for which you want to import data, and then choose Edit Space from the Edit menu.
Click Services, then Discussions.
Click the Search icon besides Category ID or Forum ID, and choose the imported category (or forum) from the list.
Click Apply.
You are not required to export space-related documents before you export a space, because the documents remain in the source content repository. After migrating your space to another Spaces application you can 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 39.1.7.5, "Exporting/Importing Space Documents using the Document Migration Utility."
There are several ways to import documents 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 39.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 the Batch Loader utility, as described in "Batchloading Content" in Oracle WebCenter Content System Administrator's Guide for Content Server.
Use the Batch Loader to migrate space-related documents if you want to preserve document metadata or require document links in Content Presenter task flows to work postimport.
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.
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 Second/Third phases. For information on the First phase (space/space template migration), see Section 39.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.
Table 39-2 describes the properties required to run the Document Migration Utility. For information on how to run the utility, see Section 39.1.7.5.2, "Migrating Content Using the Document Migration Utility."
Table 39-2 Document Migration Properties
| Property | Description | Requirement |
|---|---|---|
|
Usage |
Specifies whether you want to import or export content to a file. Options are: |
Export and Import |
|
MDSConn |
Specifies MDS JDBC connection in the format:
|
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 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: When When |
Export and Import |
|
UCMUser |
Specifies the Content Server user name used to connect through RIDC. |
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 ( |
Export and Import |
To migrate documents for one or more spaces (or space templates), you can use any of the following methods:
Specifying Document Migration Properties in a Properties File
Specifying Document Migration Properties on the Command Line
Specifying Document Migration Properties on the Command Line When Prompted
What You Should Do/Know Before Migrating Content:
Migrate the required spaces/space templates to the target application.
For details, see Section 39.1.9, "Importing Individual Spaces" or Section 39.1.12, "Importing Space Templates".
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
Create a properties file containing all the properties required for your export/import. See Table 39-2 for a description of all the properties.
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=weblogic #UCMPwd=welcome1 # 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=user1_mds #MDSPwd=welcome1 # 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
Save the file. For example, save as myMigrationProperties.properties or similar.
Navigate to the WEBCENTER_ORACLE_HOME/webcenter/archives directory in which the Document Migration Utility, content-migration-tool.jar is located.
Run the Document Migration Utility by specifying the absolute path to your document migration properties file on the command line (Example 39-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 39.1.7.5.3, "Running the Document Migration Utility with Additional Logging."
Example 39-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 = weblogic 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
Navigate to the WEBCENTER_ORACLE_HOME/webcenter/archives directory in which the Document Migration Utility, content-migration-tool.jar is located.
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 39.1.7.5.3, "Running the Document Migration Utility with Additional Logging."
Example 39-12 exports a space called MySalesSpace and a space template called SalesTemplate.
Example 39-12 Specifying Document Migration Properties on the Command Line For an Export
java -jar content-migration-tool.jar export idc://mycontentserver.mycompany.com:9444 weblogic /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 = weblogic 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
Navigate to the WEBCENTER_ORACLE_HOME/webcenter/archives directory in which the Document Migration Utility, content-migration-tool.jar is located.
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 39.1.7.5.3, "Running the Document Migration Utility with Additional Logging."
Example 39-13 exports a space called MySalesSpace and a space template called SalesTemplate.
Example 39-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: weblogic
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: welcome1
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 = weblogic
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
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
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 39.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 39.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. For information on user customizations, see the section "What You Should Know About Customizing Page Components" in the Oracle Fusion Middleware User's Guide for Oracle WebCenter Portal: Spaces.
This section includes the following:
If you want to export an entire Spaces application, see Section 39.1.4, "Exporting an Entire 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.
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."
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 39.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.
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.
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."
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 39.1.7.5, "Exporting/Importing Space Documents using the Document Migration Utility".
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 39.1.10, "Migrating Back-end Components for Space Templates." and Section 39.1.8, "Exporting Individual Spaces."
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.
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."
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 39.1.9, "Importing Individual Spaces"
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.
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."
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 Display 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.
This section includes the following:
Section 39.1.13.1, "Exporting WebCenter Resources Using the Spaces Application"
Section 39.1.13.2, "Exporting WebCenter Resources Using WLST"
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.
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."
Authorized users can import (upload when using WLST) 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 display 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 39.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:
Section 39.1.14.1, "Importing WebCenter Resources Using the Spaces Application"
Section 39.1.14.2, "Importing WebCenter Resources Using WLST"
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.
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."
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:
Section 39.2.1, "Understanding Framework Application Export and Import"
Section 39.2.2, "Prerequisites for Framework Application Export and Import"
Section 39.2.3, "Exporting Portlet Client Metadata (Framework Applications)"
Section 39.2.4, "Importing Portlet Client Metadata (Framework Applications)"
Section 39.2.5, "Exporting WebCenter Portal Resources (Framework Applications)"
Section 39.2.6, "Importing WebCenter Portal Resources (Framework Applications)"
Section 39.2.7, "Exporting WebCenter Portal Service Metadata and Data (Framework Applications)"
Section 39.2.8, "Importing WebCenter Portal Service Metadata and Data (Framework Applications)"
Section 39.2.9, "Migrating Security for WebCenter Portal Applications"
Section 39.2.10, "Migrating Data (WebCenter Portal Applications)"
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 39-12).
Table 39-3 lists available migration tools and their capabilities. All customizations listed in Table 39-3 are migrated with Framework applications.
Table 39-3 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:
|
|
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. |
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.
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.
Note:
Both the portlet producer and individual portlets must include an<allow-export> tag that is set to true. If this tag is not set, the portlet producer (and the portlets) are excluded from the export process. For details, refer to "How to Implement Export/Import of Customizations (WSRP 2.0)" in the Oracle Fusion Middleware Developer's Guide for Oracle WebCenter Portal.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 import portlet client metadata associated with all applications, see "Portlet Preference Store Migration Utilities" in Oracle Fusion Middleware Developer's Guide for Oracle WebCenter Portal.
This section describes how to import portlet client metadata and producer customizations and personalizations, for a Framework application, using the WLST command importPortletClientMetadata.
Prerequisites:
The database in which the application metadata or schema is stored and the portlet producers must be up and running.
Both the portlet producer and individual portlets must include an <allow-import> tag that is set to true. If the tag is not set, the portlet producer (and the portlets) are excluded from the import process. For details, refer to "How to Implement Export/Import of Customizations (WSRP 2.0)" in the Oracle Fusion Middleware Developer's Guide for Oracle WebCenter Portal.
To import portlet client metadata, run the WLST command importPortletClientMetadata:
importPortletClientMetadata(appName, fileName, [server, applicationVersion)]
where:
appName: Name of the Framework application (for example, myWebCenterApp).
fileName: Name of the exported EAR file containing the portlet client metadata (for example, myportletmetadata.ear).
server: Name of the managed server where the Framework application is deployed (for example, WC_CustomPortal).
applicationVersion: Version number of the deployed application, if multiple versions of the application is deployed.
See also, Section 1.13.3.1, "Running Oracle WebLogic Scripting Tool (WLST) Commands."
For detailed syntax and examples, see "importPortletClientMetadata" in Oracle Fusion Middleware WebLogic Scripting Tool Command Reference. See also, "Metadata Services (MDS) Custom WLST Commands".
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 Display 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 36.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.
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 Display 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 36.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."
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.
To export portlet metadata, run the WLST command exportPortletClientMetadata. See also, Section 39.2.3, "Exporting Portlet Client Metadata (Framework Applications)".
To export configuration file updates that are stored in MDS, run the WLST command exportMetadata with "docs='/META-INF/mdssys/cust/adfshare/adfshare/**". See also, Appendix A, "adf-config.xml and connections.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 39-4 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".
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."
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:
To export the WebCenter Portal application data, use the export and import database utilities. This section includes the following sub sections:
Section 39.2.10.1, "Exporting Data (WebCenter Portal Applications)"
Section 39.2.10.2, "Importing 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 39-14.
For non-Oracle databases, refer to the manufacturer's documentation.
Example 39-14 Data Pump Utility (Export)
DB_ORACLE_HOME/bin/expdp \"sys/password@serviceid as sysdba\" OWNER=srcrcuprefix_WEBCENTER FILE=/tmp/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.
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 39-15
For non-Oracle databases, refer to the manufacturer's documentation.
Example 39-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=/tmp/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.
You can migrate wiki content from an external wiki application, such as Confluence, into WebCenter Portal: Spaces using a custom application in combination with the Document Migration Utility. This custom wiki extraction tool would extract the wiki content into an archive of a specific format that could then used by the Document Migration Utility to import the data into the Spaces' Content Server instance.
To write such 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:
Section 39.3.1, "Understanding Document Content in Spaces and Space Templates"
Section 39.3.2, "Understanding Wiki Documents and Wiki Pages"
Section 39.3.3, "Understanding the Document Migration Utility"
Section 39.3.4, "Migrating Data from the Source Wiki Application to Spaces"
When the Documents service is enabled in a space or space template, data is created in Content Server.
This section contains the following subsections:
Section 39.3.1.3, "Understanding Folder and File Limitations for a Folder"
Section 39.3.1.4, "Understanding Export/Import for Spaces and Space Templates"
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.
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.
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:
Log into Content Server.
Go to Administration > Folder Configuration.
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.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 39.3.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 39.1, "Exporting and Importing a Spaces Application for Data Migration."
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:
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.
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.
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 39.1.7.5.2, "Migrating Content Using the Document Migration Utility."
This section contains the following subsections:
Section 39.3.3.1, "Understanding the Document Migration Utility's Export Function"
Section 39.3.3.2, "Understanding the Document Migration Utility's Import 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 39.3.3, "Understanding the Document Migration Utility." For more information about the metadata maintained between the source and target, see Section 39.3.3.2.1, "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.
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 39.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 theCheckExistingContents 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 39.3.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.
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).
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 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 noProducts 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="weblogic" 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="weblogic" 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="weblogic" 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="weblogic" name="dDocCreator" />
<attribute value="weblogic" name="dDocAuthor" />
<attribute value="OWCSVR01USORAC012754" name="dDocName" />
<attribute value="1" name="dRevisionID" />
<attribute value="weblogic" name="dDocLastModifier" />
</attributes>
</document>
</documents>
</folder>
<folder>
<attributes>
<attribute value="TRUE" name="xForceFolderSecurity" />
<attribute value="weblogic" name="dCollectionCreator" />
<attribute value="Presentations" name="dCollectionName" />
<attribute value="0" name="isLink" />
<attribute value="sysadmin" name="dCollectionOwner" />
<attribute value="weblogic" name="dCollectionModifier" />
<attribute value="1" name="dCollectionEnabled" />
</attributes>
<folders>
<folder>
<attributes>
<attribute value="TRUE" name="xForceFolderSecurity" />
<attribute value="weblogic" name="dCollectionCreator" />
<attribute value="Branding" name="dCollectionName" />
<attribute value="0" name="isLink" />
<attribute value="sysadmin" name="dCollectionOwner" />
<attribute value="weblogic" name="dCollectionModifier" />
<attribute value="1" name="dCollectionEnabled" />
</attributes>
<documents>
<document>
<attributes>
<attribute value="TRUE" name="xForceFolderSecurity" />
<attribute value="Document" name="dDocType" />
<attribute value="weblogic" 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="weblogic" name="dDocCreator" />
<attribute value="weblogic" name="dDocAuthor" />
<attribute value="OWCSVR01USORAC012748" name="dDocName" />
<attribute value="1" name="dRevisionID" />
<attribute value="weblogic" 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="weblogic" 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="weblogic" name="dDocCreator" />
<attribute value="weblogic" name="dDocAuthor" />
<attribute value="OWCSVR01USORAC012758" name="dDocName" />
<attribute value="1" name="dRevisionID" />
<attribute value="weblogic" name="dDocLastModifier" />
</attributes>
</document>
<document>
<attributes>
<attribute value="TRUE" name="xForceFolderSecurity" />
<attribute value="Document" name="dDocType" />
<attribute value="weblogic" 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="weblogic" name="dDocCreator" />
<attribute value="weblogic" name="dDocAuthor" />
<attribute value="OWCSVR01USORAC012747" name="dDocName" />
<attribute value="1" name="dRevisionID" />
<attribute value="weblogic" name="dDocLastModifier" />
</attributes>
</document>
</documents>
</folder>
<folder>
<attributes>
<attribute value="TRUE" name="xForceFolderSecurity" />
<attribute value="weblogic" name="dCollectionCreator" />
<attribute value="Products" name="dCollectionName" />
<attribute value="0" name="isLink" />
<attribute value="sysadmin" name="dCollectionOwner" />
<attribute value="weblogic" name="dCollectionModifier" />
<attribute value="1" name="dCollectionEnabled" />
</attributes>
</folder>
<folder>
<attributes>
<attribute value="TRUE" name="xForceFolderSecurity" />
<attribute value="weblogic" 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="weblogic" 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="weblogic" 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="weblogic" name="dDocCreator" />
<attribute value="weblogic" name="dDocAuthor" />
<attribute value="OWCSVR01USORAC012756" name="dDocName" />
<attribute value="1" name="dRevisionID" />
<attribute value="weblogic" name="dDocLastModifier" />
</attributes>
</document>
</documents>
</folder>
</folders>
<documents>
<document>
<attributes>
<attribute value="TRUE" name="xForceFolderSecurity" />
<attribute value="Document" name="dDocType" />
<attribute value="weblogic" 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="weblogic" name="dDocCreator" />
<attribute value="weblogic" name="dDocAuthor" />
<attribute value="OWCSVR01USORAC012746" name="dDocName" />
<attribute value="1" name="dRevisionID" />
<attribute value="weblogic" name="dDocLastModifier" />
</attributes>
</document>
</documents>
</groupspace-folder>
To migrate content from an existing wiki application to WebCenter Portal: Spaces, perform the following steps:
Prepare Spaces for import of the wiki content.
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.
Use the Document Migration Utility to import the archive into Content Server.
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:
Section 39.3.4.1, "Preparing WebCenter Portal: Spaces for Importing Wiki Content"
Section 39.3.4.3, "Using the Document Migration Utility to Import the Archive into the Target Space"
Section 39.3.4.4, "Creating Wiki Pages in Spaces for the Content in Content Server"
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:
Decide if you want to import all the wiki content into a single space or multiple spaces.
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.
Log into Content Server.
Ensure that the user's layout is Top Menus:
Click the user's name to display the user's Profile page.
Under User Personalization Settings check that Layout is set to Top Menu.
For each space in which wiki content is to be imported, determine the folder GUID:
Click Browse Content.
Click on the root folder for the Spaces instance.
This is the same as the Root Folder setting in the Content Server connection.
Click the folder for the space.
The folder name will be the same as the space's internal name.
Click Info on the toolbar to display the folder information.
Add IsSoap=1 to the URL.
Search for the string dCollectionGUID. For example:
<idc:field name="dCollectionGUID">05573322-E895-EDA3-8A83-07CF39CBDE05</idc:field>
Keep a note of the space folder name and its GUID as the GUID is needed when building the archive in the next step.
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 39.3.3, "Understanding the Document Migration Utility."
The custom wiki extraction tool must perform the following steps:
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.
Clean up the source HTML of wiki documents.
For each wiki document, edit the HTML to remove application-specific HTML tags.
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.
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
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:
Section 39.3.4.2.1, "Extracting and Arranging the Wiki Content"
Section 39.3.4.2.2, "Cleaning Up the Source HTML of Wiki Documents"
Section 39.3.4.2.4, "Building the ExportImportData.xml Documents"
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 39.3.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 39.3.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 39.3.1.3, "Understanding Folder and File Limitations for a Folder."
To create extracted wiki content, perform the following tasks:
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.
For wiki documents for which wiki pages will be created in WebCenter Portal: Spaces after import:
Create a wiki folder with the same name as the wiki document.
Place the wiki document in this folder.
Place any other documents in this folder, if required.
If there are related images and/or documents, add them to this wiki folder as well.
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)
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>
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:
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 39.3.4.1, "Preparing WebCenter Portal: Spaces for Importing Wiki Content."
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).
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>
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 39.3.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 39.3.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
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.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 39.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.
To use WebCenter wiki pages to display the imported wikis, perform the steps below. For more information about wiki pages, see Section 39.3.2, "Understanding Wiki Documents and Wiki Pages."
Log into Spaces.
Locate the space where the content has been uploaded.
Click Actions and select Create and Page.
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.
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.
This section contains the following subsections:
Section 39.5.2, "Spaces and Space Templates Not Available After Import"
Section 39.5.3, "Exporting and Importing Spaces in Multibyte Languages"
Section 39.5.4, "Page or Space Not Found Messages After Import"
Section 39.5.5, "Space Import Archive Exceeds Maximum Upload File Size"
Section 39.5.8, "Exporting and Importing Spaces with Services Configured"
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.
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."
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.
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.
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 39.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."
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.
When you migrate a Spaces application you can choose whether certain application customizations are imported using the option "Include Customizations". Table 39-4 highlights those services and task flows that store application customizations, and which are optional on migration. Table 39-5 lists application-level and space-level settings which are optional.
Note:
User customization are never migrated during export and import. For more information on application customizations and user customizations, and the difference between them, see "What You Should Know About Customizing Page Components" in the Oracle Fusion Middleware User's Guide for Oracle WebCenter Portal: Spaces.Table 39-4 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 |
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.
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 |
See also, "Understanding 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:
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 39-5 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 |
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:
Extract the archive.
The archive contains two files: policy-store.xml and transport.mar.
Expand the transport.mar into a directory.
The data.xml file is located in the oracle\webcenter\lifecycle\importexport directory.
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:
In page edit mode, content and display template settings.
<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"/>
Repack the transport.mar file by zipping the top-level directories Oracle and pagedefs into a file named transport.mar.
Repack the export archive by zipping the newly created transport.mar and the policy-store.xml file into an archive.
Import the new archive.
For the example error message above, we would need to remove the following:
|
 Copyright © 2009, 2011, Oracle and/or its affiliates. All rights reserved. Legal Notices |
|