11 Exporting and Importing Content

Oracle Portal provides a set of export and import utilities that enable you to transfer content between portals. This chapter provides a summary of recommendations and best practices for using the export and import utilities. This chapter contains the following main sections:

• Introduction Oracle Portal Export or Import

• Before You Begin

• Examples of Using Export and Import

• Export in Oracle Portal

• Acquire Transport Set Services

• Import in Oracle Portal

• Using the Oracle Portal Export and Import Command-line Scripts

• Behavior of Objects After Migration

• Recommended Best Practices When Exporting and Importing

11.1 Introduction Oracle Portal Export or Import

This section describes the tasks you need to perform and information about how Oracle Portal Export and Import works with other components of Oracle Fusion Middleware. This section contains the following topics:

• How Does Oracle Portal Export and Import Work?

• Additional Information

How Does Oracle Portal Export and Import Work?

The Oracle Portal Export and Import process consists of the following steps:

1. Create transport sets and extract the content of the transport sets to transport tables. Transport sets contain the portal objects that you want to export to your target portal environment. This information is displayed in a manifest. The manifest is a list of objects in a transport set, used to provide a granular level of control over the export. For more information on the export process and using the Transport Sets - Export Services portlet refer to Section 11.4.1.2, "How Do I Manage My Transport Sets?"

2. Move the transport sets from one system (source) to another (target) using the Transport Sets - Acquire Service portlet, or using the Oracle Portal Export and Import command-line scripts if there is an intervening firewall. Moving the transport set from the source to the target system using the Transport Sets - Acquire Service portlet is described in Section 11.5.2, "Moving Data to the Target System". Using the command-line scripts is described in Section 11.7, "Using the Oracle Portal Export and Import Command-line Scripts".

3. Import the objects from the transport tables to the target portal repository using the Import Transport Set portlet. For more information on the import process and using the Import Transport Set portlet refer to Section 11.6.1, "Oracle Portal Import - Recommended Method".

Additional Information

• Refer to the section on moving product-specific metadata for Oracle Portal from a test metadata repository to a production metadata repository in the Oracle Fusion Middleware Administrator's Guide.

• Refer to the section about controlling the exporting and importing of portlet personalizations in the Oracle Fusion Middleware Developer's Guide for Oracle Portal.

11.2 Before You Begin

Before beginning the export and import process, ensure you have the following information:

• System Requirements

• Additional Considerations

• Privileges for Exporting and Importing Content

• Oracle Portal instance information:

  • Portal schema name.

  • Portal schema password.

  • Portal connect string information.

  • Portal user name.

  • Portal user password.

  • Company name (used only for hosted portal installations). In most cases, this should be left blank.

    
    

    Note: The Oracle Portal schema password is a random password created when the application is installed.

    
    

11.2.1 System Requirements

Before exporting and importing content, ensure that your system meets the minimum system requirements, as described in this section.

Notes: Export and import functions only within the same release of Oracle Portal and the same patch release, for example, release 10.1.4 to release 10.1.4 or release 11.1.1 to release 11.1.1. You cannot export and import between two different releases, such as release 10.1.2 to release 10.1.4 or release 10.1.4 to release 11.1.1. For successful migration of objects, the version of the portal repository should be the same in the target and the source. Any difference in the versions of the middle tiers does not impact migration.

• Using Different Releases of the Export Client Utility. Whenever you move data between different releases of Oracle Database, the following rules apply:

  • The Oracle Database imp utility and the database to which data is being imported (the target database) must be either the same release or a later release.

  • The release of the Oracle Database exp utility must be same as the earliest release of the source or target database.

    
    

    Notes: Oracle Database exp and imp are the migration utilities for export and import used to dump and restore data in an Oracle-specific format for backup and transfer of user data. If you have problems with database release mismatches, then contact Oracle Support Services.

    
    

  The choice to use the database Oracle home or the middle-tier Oracle home depends on the release of the database used for the source and target portal installations. By default, the 11.1.1 release of the middle tier uses an 11.1.1 release Oracle home.

  Based on the recommendations given earlier, the following conditions apply when an 11.1.1 release of a portal and 11.1.1 release of a middle tier is involved:

  • Always use the middle-tier Oracle home to export content. Version 10.2.0.3 is the earliest version of the database supported for an 11.1.1 release of a portal installation.

  • Always use the target database Oracle home to import content. The release of the import utility and the target database must be the same.

  For example, to create an export file that will be imported into a later release of a database, use a release of the Oracle Database exp utility that is the same as the source database. To create an export file that will be imported into an earlier release of a database, use a release of the Oracle Database exp utility that is the same as the release of the target database.

  
  

  Note: Oracle recommends you use the same release of the database for the source and target portal installations.

  
  

• Oracle export and import and character sets. The Oracle Database exp utility always exports user data, including Unicode data, in the character sets of the export server. The character sets are specified when the database is created.

  The Oracle Database imp utility automatically converts the data to the character sets of the import server.

  Some 8-bit characters can be lost (that is, converted to 7-bit equivalents) when you import an 8-bit character set export file. This occurs if the client system has a native 7-bit character set or if the NLS_LANG operating system environment variable is set to a 7-bit character set. Most often, you notice that accented characters lose their accent marks.

  Both the Oracle Database exp and imp utilities alert you of any required character set conversion before exporting or importing the data.

  
  

  Note: When the character set width differs between the export client and the export server, the data may be truncated if the conversion causes the data to expand. If truncation occurs, then the export displays a warning message.

  
  

• Understand your source and target portal instances.

  • Do you have command-line access to appropriate directories on the source and target computers? If you are using the Oracle Portal Export and Import command-line scripts to move the transport sets from one system to another, you must have command-line access to run the shell or command utilities generated by the export import process. The command-line utilities, in turn, access the Oracle Database exp and imp utilities, and the Oracle Portal instance.

  • Is your database configured to allow background jobs to run? Each export or import process sets up a background process. Therefore, verify that the job_queue_processes database parameter is set appropriately.

    To check the value of the job_queue_processes parameter, perform the following query from SQL*Plus:

    %select name, value from v$parameter where name='job_queue_processes'
    

    The value for job_queue_processes should be at least 2 to allow the background jobs to run.

    An alternative way of checking the job_queue_processes parameter is to examine the init.ora file in your database's ORACLE_INSTANCE.

• When do you export and import data? Perform the export and import process after regular business hours, and disable access to Oracle Portal during the process. One way to disable access to the portal temporarily is to configure your listener for a different port number for the duration of the export and then revert to the original port when the export process is complete.

  
  

  Note: If the Oracle Database exp and imp utilities finish with errors or warnings, then you should not import that transport set. The errors or warnings that are recorded in the Oracle Database exp and imp log files (typically named <script_file_name>_<long identifier>_exp.log and <script_file_name>_<long identifier>_imp.log) should be corrected first.

  
  

• How much time does the export or import process take? The exact amount of time to export or import content in Oracle Portal cannot be determined. Many dependencies affect the time it takes to export and import content. The following are dependencies that can affect the processing time.

  Dependencies that affect the Export process are as follows:

  • Objects being exported have a number of dependencies spanning across page groups.

  • There are references or dependencies between objects.

  • Extraction process takes a long time to start because of the assigned database job in the queue.

  • There are a large number of documents being extracted, especially BLOB columns.

  • There is insufficient memory in the TEMP tablespace for sort operations.

  • Schema validation takes a long time due to a large number of objects that need to be validated.

  Dependencies that affect the Import process are as follows:

  • Preliminary check for large page groups, which also depends on the number of internal and external dependencies that need to be checked.

  • Import process takes a long time to start because of the assigned database job in the queue.

  • There is insufficient memory in the TEMP tablespace for sort operations.

  • Post-import schema validation takes a long time due to a large number of objects being validated.

  • Difference between the source and target languages is reasonably high.

  
  

  Tip: Before importing large transport sets, you may want to increase the values of relevant database cache parameters based on your requirement. This will reduce the time taken to import large transport sets.

  
  

11.2.2 Additional Considerations

This section provides a list of some additional considerations you must make before you export and import data in Oracle Portal.

• When exporting or importing large data sets, check that there is sufficient space in the TEMP tablespace. This ensures that the export or import process does not fail due to insufficient memory.

• For exporting large page groups from the command line, use the opeasst.csh script. See Section 11.4.1.1.3, "Exporting Large Page Groups from the Command Line" for more information.

• For importing large page groups from the command line, use the import script with the -automatic_merge option. See Section 11.7.3, "Importing the Transport Set Tables to the Target System" for more information.

• If you have installed any Business Intelligence and Forms components and use related portlets in Oracle Portal on the source portal instance, then you must ensure that the same components are installed on the target portal instance before you can export and import data between the portal instances. If the same Business Intelligence and Forms components are not found on the target portal instance, then, during import, the portlets related to those components will be removed from the pages in which they appear.

  
  

  Caution: Do not manually update system tables to resolve any issues you might have in the source or target portal instances. Doing so will cause the export and import process to fail. If you have any problems with source or target instances, then contact Oracle Support Services.

  
  

11.2.3 Privileges for Exporting and Importing Content

This section describes the privileges required to successfully export and import content. The privileges described subsequently apply to the export and import of Oracle Instant Portal content also.

Privileges for Exporting Content

To allow for secured control over the export of shared objects (objects in the Shared page group), there are two privileges defined at the infrastructure level.

• Any Transport Set - Manage enables you to export and import portal objects, including shared objects. This privilege is granted to the DBA group by default during the portal installation process.

• Any Transport Set - Execute enables you to export and import portal objects, excluding shared objects. This privilege is granted to the PORTAL_ADMINISTRATORS group by default during portal installation process.

Table 11-1 provides a description of export user privileges.

Table 11-1 Export User Privileges

User Privileges	Export Objects That Are Not Shared?	Export Objects That Are Shared?
Any Transport Set - Manage	Yes	Yes
Any Transport Set - Execute	Yes	No
Any Transport Set - None	No	No

Privileges for Importing Content

In addition to the Any Transport Set - Manage privilege, you must also have the Manage privilege on objects of a given type to successfully import content.

For example, a page group containing Web providers requires you to have Manage All privileges on All Providers and All Page Groups to import that page group. Table 11-2 provides a description of each object type and the required privilege level.

Note: The FMWADMIN and Oracle Portal users are granted the Manage All privilege on all page groups at the time of installation or upgrade. Members of the DBA group are also granted the Manage All privilege on all page groups by default.

Table 11-2 Import User Privileges

Object Type	Privileges
All Page Groups	Manage All and All Providers Manage are required to import page groups and shared objects.
All Providers	Manage is required to import page groups, Portal DB Providers, Web providers, WSRP producers, and other database providers.
All Portal DB Providers	Manage is required to import Portal DB Provider objects.
All Shared Components	Manage is required to import shared components if the Portal DB Provider objects reference the shared components.

Note: If you import a page based on a style that belongs to the shared objects group and do not have the necessary privileges to import shared objects, then the style of the page is reset to Main Style by default.

11.3 Examples of Using Export and Import

Oracle Portal supports the ability to copy or update page groups and portal content between your source and target destination portal instances. This section gives examples of the most common uses of the Oracle Portal Export and Import processes.

11.3.1 Case1: Exporting and Importing Between Development and Production Instances

This case shows the steps to copy or update portal page groups and portlets between a development instance and a production instance of Oracle Portal.

Note: User personalizations are not exported; therefore, any personalizations of a page or portlet on the source are not exported or imported.

Scenario 1: Exporting pages and content to a target portal system. The first export to your target system must migrate the entire page group. The following steps provide an overview of the process:

1. Develop page groups, applications, and content on the source system.

2. Identify pages, applications, and content to export, then create transport sets accordingly and export to the target system.

3. Import the transport sets on the target system, into your portal repository.

Scenario 2: Updating content on your target instance. Oracle Portal supports updating items and region-level content on your target system only under the following circumstance:

Export and import of all changes from the source to the target instance. All page structure, content, and user preferences on your target system are replaced with the content from your source system. The first export to your target system migrates the entire page group from the source portal to the target portal instance.

See Section 11.9, "Recommended Best Practices When Exporting and Importing" for more information about the recommended practices for exporting and importing content.

11.3.2 Case 2: Deploying Identical Content Across Multiple Portal Instances

As well as using the Acquire Transport Set portal to transport data, you can also use the exp and imp migration utilities to deploy identical content across multiple Oracle Portal instances. In this case, the Oracle Portal objects (portlets, page groups, and so on) can be created in one instance, and propagated to multiple instances using the exp and imp migration utilities. For more information, refer to the information on staging a test environment from a production environment, in the Oracle Fusion Middleware Administrator's Guide.

11.3.3 Case 3: Consolidating Content from Multiple Sources

When you use Oracle Portal Export and Import to migrate content from multiple portal instances to a single target portal instance, you must consider the following points:

• Do not create objects with the same names on different source portal instances from where you plan to import. This helps avoid namespace collisions between shared objects. For example, assume that you create a shared template (shared_tempate1) in source instances (source1 and source2) used by page groups (pgrp1 and pgrp2) in source1 and source2 respectively. Now, if you try to consolidate the two page groups from source1 and source2 into one target instance, then this will result in precheck errors as both page groups use different shared templates with the same name (shared_template1).

• Do not create page groups with the same name. For example, do not create a page group (pgrp1) in source instances source1 and source2 if you need to consolidate these two page groups in into a single target instance. This warning is also valid for names of database provider objects, shared components, Web providers, and database providers.

11.4 Export in Oracle Portal

This section describes the methods for the Oracle Portal Export. This section contains the following topics:

• Oracle Portal Export - Recommended Method

• Oracle Portal Export - Alternate Method

11.4.1 Oracle Portal Export - Recommended Method

This section describes the recommended method to export content in Oracle Portal. It contains the following topics:

• How Does Oracle Portal Export Work?

• How Do I Manage My Transport Sets?

11.4.1.1 How Does Oracle Portal Export Work?

This section describes the export process and the steps required to successfully transfer content from the source portal system, including:

• Creating Transport Sets

• Exporting Data

• Exporting Large Page Groups from the Command Line

11.4.1.1.1 Creating Transport Sets

Once the system requirements are verified, your goal is to create a transport set. Figure 11-1 shows the process.

Note: Limit any possible conflict issues by making one person responsible for maintaining a transport set.

Figure 11-1 Export Process

Description of "Figure 11-1 Export Process"

1. From the Navigator or Bulk Actions (enables you to add multiple pages at once to the export transport set), select the page group or root page to be exported. The Transport Set Manager is displayed.

2. Select a name and whether to include access controls and preferences, or external and child objects as part of the transport set. Click Next to generate the transport manifest.

3. When the dependency calculation has finished, click Display Manifest to display the Export Transport Set page to view the results. Check that the Replace on Import options are set appropriately for the explicit and referenced objects as described in Working with Import Modes in this section. Add any external objects that are required on the destination portal to the transport set. The transport set is now ready for export.

4. Click Export Now to initiate the export. The procedure extracts the data and populates the transport tables. Refer to Section 11.4.1.1.2, "Exporting Data" for more information about the export process.

The Export Transport Set Manager ensures that all the object dependencies in the transport set are correctly extracted. Specifically, the Dependency Manager classifies each object as explicitly selected, referenced, external or child, based on how the object is related to the objects being explicitly exported. The information is displayed in the manifest, as shown in Figure 11-2. The following list shows the classification of objects:

• Explicitly Selected Objects. Objects, that were explicitly selected, from the Navigator or Bulk Actions for export.

• Referenced Objects. Objects that are directly or indirectly referenced by the explicitly selected objects, but are always within the same page group as an explicit object. For example, a style used by a page is a referenced object when it belongs to the same page group.

• External Objects. External objects ensure that the explicitly selected objects perform on the target portal. For example, external providers and database schemas could be considered external objects. Generally, shared objects and components are external objects unless explicitly selected.

• Child Objects. Objects that are part of a hierarchy. For example, subpages, subcategories and subperspectives are child objects of a page, category and perspective.

  
  

  Notes: When a referenced object contains child objects, the child objects are imported in Reuse mode. You should therefore explicitly select the referenced object and include it in the transport set. This will enable you to set the import mode to Replace on Import. Before importing the page group in Reuse mode, note the page group properties. After importing the page group manually, update any changes to reflect the old properties. A child object is picked up for migration only for an explicit object. If a parent page, category, or perspective appears in the referenced section, then the child objects are not picked. See Table 11-12, "Import Behavior of Child Objects" for more information. Containers of explicit objects and referenced objects are migrated as external dependencies.

  
  

Working with Import Modes

The manifest provides a granular level of control over the import mode. The manifest is the list of objects in a transport set. There are two modes available during import:

• Replace on Import. If the object exists on the target, then it is replaced. If it does not exist, then it is created. If this mode is not selected and the object exists, then the object on the target portal is retained as is. However, if the object does not exist on the target, then it is created.

• Reuse on Import. If the object does not exist on the target, then it is created. If it already exists, then it remains as is.

Table 11-3 describes the object classification and the default modes.

Table 11-3 Default Modes

Object Classification	Default Import Mode
Explicitly selected objects	Replace on Import
Referenced objects	Reuse
Child objects	Replace on Import
External objects	Reuse

Figure 11-2 is an example of a transport set manifest.

Figure 11-2 Transport Set Manifest

Description of "Figure 11-2 Transport Set Manifest"

Clicking the name of an object, for example an explicitly selected object, displays a detailed view of child, referenced, and external objects. The objects can be displayed in either a tree view or tabular view. Figure 11-3 is an example of the tree view of a detailed manifest screen.

Figure 11-3 Detailed Manifest Screen

Description of "Figure 11-3 Detailed Manifest Screen"

Note: Editable seeded item types are extracted. It is recommended that you do not edit seeded types. If you want to extract them, then create custom types in the Shared Objects page group based on the existing seeded types. The Dependency Manager includes these in the manifest.

11.4.1.1.2 Exporting Data

Review Section 11.8, "Behavior of Objects After Migration" before exporting and importing your portal content from a source to a target instance.

Note: Portlet repository information (security, organization, and so on) related to the portlet is not migrated during the export and import process.

To export objects:

1. Select the objects for export. You can do this from the Navigator, or search results > Bulk Actions for page groups. See Figure 11-4.

   
   

   Note: Be sure to export portlets (Portal Forms, Portal Reports, Charts, Dynamic Pages) before exporting portal pages and page groups that reference them.

   
   

   Figure 11-4 is an example of the Portal Navigator.

   Figure 11-4 Portal Navigator

   
   Description of "Figure 11-4 Portal Navigator"
   
   

2. Click the Export, Export Page Group, or Export Root Page link to display the Transport Set Manager. Make the transport set name as descriptive as possible, and avoid using any special characters at the start of the name. For example, My Company Transport Set 12-NOV-2008.

   Figure 11-5 is an example of the Transport Set Manager.

   Figure 11-5 Transport Set Manager

   
   Description of "Figure 11-5 Transport Set Manager "
   
   

3. Select Access Controls and Preferences if you want to include access control lists (ACLs) associated with the objects in the transport set. If you select this option, the following happens:

   • Users and groups associated with the objects are migrated.

   • Privileges attached to the objects are migrated.

   • Parameters and events associated with the users are migrated.

4. Select Export all external objects to include external object dependencies in the export with explicitly selected objects.

5. Select whether to include hierarchical objects in the export.

   • Choose Include Entire Hierarchy to include all child objects of explicitly selected objects in the export.

   • Choose Include Object Structure Only to include only the structure of the explicitly selected object (i.e., without any of its child objects) in the export. This option applies only for hierarchical objects (i.e., Pages, Perspectives, and Categories)

6. Set the Pagination options for the transport set.

   Manifest View:

   • Select Full transport view (Default) to render all the objects in the dependency manifest at once.

   • Select Paginated View to enable the user option to set the number of viewable objects per section. For example, if the number of viewable objects is set to 100, you can view only 100 objects per section with the pagination controls. This option is useful particularly for large transport sets which could time out the manifest user interface before rendering.

   Tree View:

   • Select Full Dependency View (Default) to render the detailed dependency tree with all the dependencies at once.

   • Select Paginated View to restrict the dependencies to only the immediate references, and use the Drill Down Pagination controls to traverse through the child references. This setting is useful for large dependency trees that may time out the tree view rendering.

7. Click Next to generate the transport manifest. When the dependency calculation has finished (click ReQuery to check the status), click Display Manifest to display the Export/Import Dependency Manager to view the results (see Figure 11-6). Check that the Replace on Import options are set appropriately for the explicit and referenced objects as described in Working with Import Modes in this section. Add any external objects that are required on the destination portal to the transport set.

8. After making changes, click Recalculate to see the updated manifest.

   Figure 11-6 shows the transport set objects.

   Figure 11-6 Transport Set Manager Objects

   
   Description of "Figure 11-6 Transport Set Manager Objects "
   
   

9. To finalize the transport set immediately after a dependency calculation, click Export Now. If you've made changes, or it's possible that other users on the Portal may have made changes since the dependency calculation, click Recalc & Export to recalculate dependencies prior to exporting the transport set. The objects marked for export are copied to the transport tables for migration. When the export process is complete, the Export Log and Download Scripts page is displayed.

   
   

   Note: When you select Export Now the objects are exported

   
   

   Figure 11-7 Export Log and Download Scripts Page

   
   Description of "Figure 11-7 Export Log and Download Scripts Page"
   
   

10. Check the log in your transport set manager for any errors by clicking the View Log Of Actions link.

    Figure 11-8 is an example of the View Log page.

    Figure 11-8 Transport Set Export Log

    
    Description of "Figure 11-8 Transport Set Export Log"
    
    
    
    

    Note: To view a detailed log of the export process, including debug messages, click on the link at the top of the log indicated by "Detailed log information can be viewed here".

    
    

11. If you are moving data across a firewall to the target system, you'll need to use an Oracle Portal Export and Import command-line script rather than the Acquire Transport Set portlet. From the Export Log and Download Scripts page, select an appropriate export script based on your operating system and download it to the source system. Refer to Section 11.7, "Using the Oracle Portal Export and Import Command-line Scripts" for more information on using the command-line scripts.

11.4.1.1.3 Exporting Large Page Groups from the Command Line

You can use the opeasst.csh (Oracle Portal Export Assistant) script to export large page groups with all the dependencies without going through the portal's user interface. The script replicates the behavior of exporting transport sets through the user interface with the Export all External Objects option turned on.

The script does the following in the following order:

• Creates a transport set with a specified name

• Calculates dependencies for the specified page groups and promotes all external objects iteratively until there are no more promotable external objects

• Extracts metadata into the transport tables

• Generates the checklist for the external dependencies (if any) for the transport set

Note: The s

The script can be found in the /portal/admin/plsql/wwu directory. The following is an example of the script:

%opeasst.csh
Usage: opeasst.csh <-s portal_schema> <-p portal_password> <-c connect_string> <-ts transportset_name> <-pgrps pgrp_names> <-log log_name> <[-export_acls]>

Table 11-4 provides a description of the parameters used in this process.

Table 11-4 OPEASST.CSH Parameter Descriptions

Parameters	Description
-s portal_schema	Oracle Database account for the portal.
-p portal_password	Oracle Database password for the portal.
-c connect_string	TNS connection information for the source database.
-ts transportset_name	Name of the transport set to be created.
-pgrps pgrp_names	Comma-delimited list of Page groups for export. Note: Exporting seeded page groups using the script is not allowed.
	Name of the logfile to which to output the export checklist process log.
-export_acls	Export object-level privileges.

Do the export from the command line, and then perform the following tasks:

1. Check the log in your transport set manager for any errors by clicking the Status link. See Section 11.4.1.2, "How Do I Manage My Transport Sets?" for more information about how to edit and browse the transport sets on the system.

2. When the export is complete browse your transport sets and select the appropriate script for your operating system. See Section 11.7, "Using the Oracle Portal Export and Import Command-line Scripts" for details.

3. Run the script using -mode export as the option.

   %MyScript.csh -mode export
   

   This prompts you for information such as the schema name (source), password, dump file names, and so on. It also creates a dump file upon completion.

4. Using FTP, transfer your dump file and the export and import script to the computer where your target Oracle Portal schema resides.

5. To import your objects, the contents of the transport set dump file must first be imported to the transport set tables on the target system. See Section 11.6.1.2, "Importing Data" for details.

The following features and limitations currently apply:

• The script supports only exporting page groups

• Multiple page groups can be exported at once using comma-delimited values

• Export checklist logs are available after export. These logs help identify prerequisites prior to import

• Export Access Control Lists feature is supported

• The import mode options (i.e., Replace on Import and Reuse on Import) are not available

• Exporting database providers is not supported

• If the Dependency Manager results in some external objects for the page group being exported, then all the external objects are automatically made explicit by the script without any user intervention. Those objects that can be made explicit are recursively added to become part of the transport set until there are no remaining external objects in the transport set.

• The script name cannot be changed.

  
  

  Notes: Remember to set the infrastructure Oracle home (ORACLE_INSTANCE) when connecting to the database to run the opeasst.csh script. To run shell script tools on the Windows operating system, you need one of the following UNIX emulation utilities: — Cygwin 1.3.2.2-1 or later. Visit http://sources.redhat.com. — MKS Toolkit 6.1. Visit http://www.datafocus.com/. Whenever you use the command line, it will create a new dump based on the timestamp, and will not overwrite an existing dump, it is recommended that you cleanup the unused and the old dump files periodically to save the disk space.

  
  

11.4.1.2 How Do I Manage My Transport Sets?

The Transport Sets -Export Services portlets on the Administer page enables you to export, browse, and edit the transport sets on the system. This section discusses the following:

• Browsing Transport Sets for Export

Note: The status is set to "ACQUIRE_IN_PROGRESS" on both the source and target for the Transport Set being acquired, and is a valid status in the export browse transport set list.

11.4.1.2.1 Browsing Transport Sets for Export

You can view and edit the list of objects selected for an exported transport set. You can view all of the transport sets that are on the system and their current status. You can also view the log of actions, view the referenced objects, and download the export and import scripts.

To display the Transport Sets

1. Navigate to the Export Transport Set portlet. Figure 11-9 shows the Export Transport Set Portal.

   Figure 11-9 Export Transport Set Portlet

   
   Description of "Figure 11-9 Export Transport Set Portlet"
   
   

2. Click Browse Transport Sets for Export. Figure 11-10 shows a sample Browse Transport Sets for Export screen.

Figure 11-10 Browse Transport Sets for Export

Description of "Figure 11-10 Browse Transport Sets for Export"

The Browse Transport Sets for Export screen shows the status of all transport sets on the source system.

• To view the export manifest for a transport set, click Name

• To download scripts for a transport set, click the corresponding Script link.

• To view the log for a transport set, click Status

• To generate a checklist to validate the transport set's readiness for import click Generate Checklist.

• To delete a transport set, select it and click Delete.

When you select transport sets and click Delete, you are prompted for confirmation. Clicking OK does not affect transport sets that are in the Export, Export In Progress, Precheck In Progress, Migration In Progress, Import, or Import In Progress statuses.

To make a previously exported or finalized (Dependency calculation complete) transport set available for reuse, select the transport set and click Reuse.

When you select transport sets and click Reuse, you are prompted for confirmation. Clicking OK does not affect transport sets that are in the Export, Export In Progress, Migration In Progress, Ready For Import, Import, Import In Progress statuses.

Notes: The Reuse option is valid only for transport sets in the source portal with a status of You can import objects with multiple hierarchies in the same transport set.

11.4.2 Oracle Portal Export - Alternate Method

You can export content when both the source and target Oracle Portal instances exist in a customer database installation, and not in a product metadata repository. For details, refer to the information on staging a test environment from a production environment, in the Oracle Fusion Middleware Administrator's Guide.

11.5 Acquire Transport Set Services

You use the Transport Sets - Acquire Services portlet to perform the following task:

• Register a Source Portal

• Moving Data to the Target System

11.5.1 Register a Source Portal

Before moving data from a source portal you must first register the portal. Once registered, the source portal can be selected and used to specify the data source in the Transport Sets - Acquire Services portal as described in Section 11.5.2, "Moving Data to the Target System"

To register a source portal:

1. Create a private database link with embedded credentials (known as a fixed user database link) to the source portal. Refer to Section 11.6.1.1, "Creating a Database Link" for instructions on how to create a database link.

2. In the Transport Sets - Acquire Services portlet, click Register a Source Portal to display the Register a Source Portal screen. Figure 11-11 shows the Register a Source Portal screen.

   Figure 11-11 Register a Source Portal Page

   
   Description of "Figure 11-11 Register a Source Portal Page"
   
   

3. Provide a unique name and database link for the source portal and click Register. You can now select the source portal when you acquire a transport set.

4. Provide a unique name and database link for the source portal and click Register. You can now select the source portal when you acquire a transport set.

11.5.2 Moving Data to the Target System

Before importing your objects, the contents of the transport set must first be moved to the transport set tables on the target system. If there is no intervening firewall, use the Transport Set - Acquire Services portlet to move the data as shown below. If you are moving data across a firewall or there are other local configuration considerations that do not allow you to use the Acquire Transport Set portlet, use the command-line scripts as shown in Section 11.7, "Using the Oracle Portal Export and Import Command-line Scripts".

To move your content using the Acquire Transport Sets portlet:

1. In the Transport Set - Acquire Services portlet, click the Browse Source Portals on the Administer page and check that the source portal you're moving data from is registered on the target instance.

   If the source portal has not previously been registered, from the Acquire Transport Sets portlet, click Register A Source Portal and register it as described in Section 11.5.1, "Register a Source Portal".

2. From the Transport Set - Acquire Services portlet, click Acquire Transport Sets to display the Acquire a Transport Set page.

   Figure 11-12 Acquire a Transport Set

   
   Description of "Figure 11-12 Acquire a Transport Set"
   
   

3. Specify the source portal and the transport set and click Acquire to start transferring the data.

4. When the transfer is complete, click Display Manifest to display the transport set manifest. Click on the explicitly selected object to display the detailed manifest. Click Tree View to see the nested dependencies.

5. Click Close to return to the manifest, and then click Precheck Now to perform a precheck of the transferred data. The system checks that all object dependencies have been resolved.

6. Click Display Manifest when the precheck is complete and check the status column for errors. Refer to Table 11-7 to see the status icons. Resolve any errors before continuing with importing the transport set.

11.6 Import in Oracle Portal

This section describes the methods for importing in Oracle Portal. This section contains the following topics:

• Oracle Portal Import - Recommended Method

• Oracle Portal Import - Alternate Method

11.6.1 Oracle Portal Import - Recommended Method

This section describes the import process and the steps required to successfully transfer content using the Transport Sets - Acquire Services portal to the target portal system, including:

• Creating a Database Link

• Register a Source Portal

• Moving Data to the Target System

• Importing Data

• How Do I Manage My Transport Sets (Import)?

11.6.1.1 Creating a Database Link

The Acquire Transport Sets functionality uses a fixed user database link to pull data from the source database. When an application uses a fixed user database link, the local server always establishes a connection to a fixed remote schema in the remote database. The local server also sends the fixed user's credentials across the network when an application uses the link to access the remote database.

To create the database link:

1. On the Portal Builder page, click the Navigator link.

2. Click the Database Objects tab.

3. In the Name column, scroll down to the schema to which you want to link and click the schema's name.

4. Click Create New...Database Link.

5. Enter the Database Link Name you want to use to identify the database link.

   Example: mydb.mydomain@remotedb

6. Choose the schema that will own the finished database link, and then click Next. Only schemas in which you have Manage schema access privileges display in the list.

   
   

   Note:

   
   

7. Complete the database connection fields as shown in Table 11-5, and then click Next.

   Table 11-5 Database Connection Information

   Field	Description
   Current User	Select to log into the remote database using the same user name and password that you use to log into Oracle Portal.
   Specific User	Select to log into the remote database using a user name and password other than the one you use to log into Oracle Portal.
   User Name	Enter a User Name and Password if you want to log into the database automatically as the Current or Specific user. If you don't enter a User Name and Password, a login dialog box will display when you try to log into a database using the link. The User Name and Password must be for a valid user account in the remote database.
   Password	Enter the password for the database User Name.

   
   

8. Enter either the TNSNAME for the database, or supply the Host Address, Host Service Name, the Host Protocol, and the Host Port, and then click Finish.

After creating the database link, continue by registering it as described in Section 11.5.1, "Register a Source Portal". Once the link is established through the registered source portal, you can select one of the transport sets that are "Export Complete" on the source portal and move it to the target using the Transport Sets - Acquire Services portal as described in Section 11.5.2, "Moving Data to the Target System". The Acquire process pulls the transport set data one by one in batches through the database link and informs you once the process is done.

Creating a Database Link from the Command Line

You can also create the database link from the command line using SQL *Plus using the following syntax:

create database link <link_name> connect to <source-portal> identified by "<source-portal-password>" using '<net-service-name>';

where:

Table 11-6 Database Link Syntax

Parameters	Description
link_name	A user-defined name for the link.
source-portal	Name of the portal schema that you want to register as the source for this portal.
source-portal-password	Database password for the above schema. Note: Passwords for Oracle 11g databases, unlike earlier versions, are case sensitive by default. To preserve the password case you must enclose it within double quotes.
net-service-name	Alias or the full connection descriptor (obtained from $TNS_ADMIN/tnsnames.ora).

Example:

create database link mylink1 connect to portal12 identified by "******"

using

'(DESCRIPTION =

(ADDRESS_LIST =

(ADDRESS = (PROTOCOL = TCP)(HOST = stacu35.us.oracle.com)(PORT = 1521)))

(CONNECT_DATA =

(SERVER=DEDICATED)

(SERVICE_NAME = asinfra.us.oracle.com)))'

Refer to the section on "Creating Database Links" in the Oracle Database Administrator's Guide for more information on creating database links using SQL *Plus.

After creating the database link, continue by registering it as described in Section 11.5.1, "Register a Source Portal", and moving it to the target using the Transport Sets - Acquire Services portal as described in Section 11.5.2, "Moving Data to the Target System".

11.6.1.2 Importing Data

To import an object, the contents of the transport set must first be imported to the target system. When you select a transport set for import, a preliminary check (or precheck) process determines if the objects already exist on the target.

To import your content:

1. Locate the Import Transport Set portlet, installed by default on the Administer tab.

   
   

   Note: When you import a transport set and click the Browse Transport Sets link, you will see the newly imported transport set with the Export Complete status and links to the export scripts. Selecting a transport set on the target for Reuse resets the transport set. This makes the transport unusable because it was not exported from the target instance and therefore no objects exist that match the objects in the transport set.

   
   

2. Select the imported transport set and click Import. The Objects page of the Import Manager is displayed.

   Figure 11-13 shows the Objects page that displays the list of objects included for import.

   Figure 11-13 Transport Set Manager Import Objects

   
   Description of "Figure 11-13 Transport Set Manager Import Objects "
   
   

3. If you select Replace on Import, then the object is replaced if it is found in the target portal.

   
   

   Note: Replace on Import mode is the default mode for explicitly selected objects; Reuse is the default mode for referenced objects. The import modes are not applicable to the external objects until they are made explicitly selected objects.

   
   

4. To view the log output, click the Status icon. Table 11-7 provides a description of each status type.

   Table 11-7 Status Descriptions

   Status	Description
   Description of the illustration cg_expimp_pass.gif	Pass
   Description of the illustration cg_expimp_fail.gif	Fail
   Description of the illustration cg_expimp_warning_1.gif	Pass with warnings

   
   

   Figure 11-14 shows a sample View Log page.

   Figure 11-14 Transport Set Manager Import Log

   
   Description of "Figure 11-14 Transport Set Manager Import Log"
   
   
   
   

   Note: To view a detailed log of the import process, including debug messages, click on the link indicated by "Detailed log information can be viewed here" at the top of the transport set log.

   
   

5. Click Close to return to the Objects page.

6. Click the Main tab.

   Figure 11-15 Import Transport Set Page

   
   Description of "Figure 11-15 Import Transport Set Page"
   
   

7. Select the Access Controls and Preferences option under Access Controls and Preferences if you want to include the access control lists (ACLs) associated with the objects in the transport set.

   
   

   Note: The Import Access Control Lists option cannot be selected if you did not select it during the export process.

   
   

   If you select this option, the following happens:

   • Group profiles get created only if they do not exist on the target.

   • User and group profiles do not get updated upon subsequent imports. Default groups of users are not imported.

   • If a user exists on the target, then the user's default group is populated from Oracle Internet Directory.

8. Select or Precheck Again if you've made changes to resolve warnings or errors before importing, select Precheck & Import to precheck the transport set prior to importing it, select Import Now to import the transport set without prechecking, or select Save & Close to save any changes and return to the transport set later.

   
   

   Note:

   
   

9. Check the log for errors.

   To ensure that all the content has been imported correctly:

   • In the Navigator, verify that the content in each portal page group that you imported was imported correctly. Specifically, for each portal page, verify that the appropriate portlets appear in each region of your portal page. When these portlets (navigation pages, pages exposed as portlets, database provider components, or Web portlets) occur as external dependencies and they do not exist on the target, then the portlet entry is deleted from the page.

     
     

     Note: During the import, a two-step preliminary check process is performed. Clicking View Log shows both the first stage of the process and the preliminary check as complete. This is done before the import and before populating the portal tables with data. Clicking Refresh Log will show both the second stage of the process and the preliminary check with different timestamps.

     
     

Warnings and Failures During Import

Objects that are being imported can be classified into two types:

• Warning types - Objects that, on failure, cascade warnings to explicitly selected objects.

• Failure types - Objects that, on failure, cascade failures to explicitly selected objects.

A warning type will raise warnings and allow the explicitly selected objects to be imported. A failure type object is not imported.

If an explicitly selected object has two dependencies, a warning type and a failure type, and if both the dependencies fail the preliminary check process, then the failure type will be dominating, and the explicitly selected object will fail.

A warning type affects explicitly selected objects more than any other kind of object. Referenced and external objects raise failures and warnings for the explicitly selected objects based on their type. Table 11-8 describes the warning or failure behavior for each object.

Table 11-8 Warning and Failure Types

Object	Type	Expected Behavior
Attribute	Failure	The explicitly selected object will fail if the dependent attribute fails.
Item type	Failure	The explicitly selected object will fail if the dependent item type fails.
Page type	Failure	The explicitly selected object will fail if the dependent page type fails.
Style	Warning	The style will revert to the main style of the page group to which it belongs.
Category	Warning	The category is set to none.
Perspective	Warning	The perspective associated with an item or page is removed.
Portal Templates for pages	Failure	The explicitly selected object will fail if the dependent template fails.
Portal Templates for items	Warning	The Portal Template for item associated with an item or page is removed.
HTML Template	Warning	The HTML Template associated with an item or page is removed.
Page	Warning	There are three possible outcomes when a page is a dependent of another object: Page exposed as a portlet. The portlet entry is removed from the region that contained the page portlet. Page link pointing to a page. The page link is removed from the region, because the page to which the link is pointing to has failed. Page Parameters and Events dependency. The link that was pointing to the page that failed is reset to point to the same page in which the Page Parameters and Events link is located.
Navigation page	Warning	The navigation page portlet is removed from the page. You can associate the page with another navigation page after the import.
Color, font, JavaScript, application template, image	Warning	Set to the default at run time.
Any other providers (DB provider, Web provider, WSRP provider)	Warning	The portlet instance on the referenced page is removed. Refer to the section on Portlet Cleanup for more information.

When the container objects in the following list appear as external dependencies, because their child objects were selected for export and they do not exist on the target, the explicitly selected objects (child objects of the container objects) will fail.

• Page group

• Portal DB Provider

• Category

• Perspective

• Page

Cascade Warning Behavior

Warnings or failures detected in objects during the preliminary check behave as shown in Table 11-9.

Table 11-9 Cascade Warning Behavior

Object	Warning Status	Failure Status
Contained object	Status is cascaded to the container object.	Status is cascaded to the container object.
Hierarchical object	Status is cascaded to all parent objects. Status is not cascaded to child objects.	Status is cascaded to all child objects. Status is cascaded to all parent objects.
Referred object	Status is not cascaded to all referenced objects.	Status is cascaded to all referenced objects.

Portlet Cleanup

Imported portlets are synchronized with the target portlet repository during the import process. If a portlet instance fails during the resolution phase of the import process, then it is deleted from the source page.

For example, a page can have a portlet, which could be one of the following:

• Navigation page

• Page exposed as a portlet

• Database Portlet (registered or built-in)

• Web/WSRP portlets (registered or built-in)

When these portlets appear as external dependencies in Reuse mode and do not exist on the target page, the portlet instance is deleted from the page. If these dependencies were made explicit and their import failed, then the portlet instances would still be deleted.

To summarize, if the imported portlet does not exist in the portlet repository on the target, then it gets deleted from the source page.

Note: The portlet cleanup operation deletes portlet dependencies such as Page Parameters and Events, URL, text, and so on. The page structure remains unchanged after removing the portlet instance from a source page. If the navigation page (external dependency) does not exist on the target page, then a page using that navigation page passes with warnings, and the navigation page portlet gets deleted from the source page.

11.6.1.3 How Do I Manage My Transport Sets (Import)?

The Transport Sets -Import Services portlets on the Administer tab and enable you to import, browse, and edit the transport sets on the system. This section discusses the following:

• Browsing Transport Sets for Import

Note: The status is set to "ACQUIRE_IN_PROGRESS" on both the source and target for the Transport Set being acquired, and is a valid status in the export browse transport set list.

Browsing Transport Sets for Import

You can view and edit the list of objects selected for an imported transport set. You can view all of the transport sets that are on the system and their current status. You can also view the log of actions, view the referenced objects, and generate a checklist.

To display the Transport Sets:

1. Navigate to the Import Transport Set portlet. Figure 11-16 shows the Import Transport Set Portal.

   Figure 11-16 Import Transport Set Portlet

   
   Description of "Figure 11-16 Import Transport Set Portlet"
   
   

2. Click Browse Transport Sets for Import. Figure 11-17 shows a sample Browse Transport Sets for Import screen.

Figure 11-17 Browse Transport Sets for Import

Description of "Figure 11-17 Browse Transport Sets for Import"

The Browse Transport Sets for Import page shows the status of all transport sets on the source system.

To view the export manifest for a transport set, click Name

To view the log for a transport set, click Status

To delete a transport set, select it and click Delete.

When you select transport sets and click Delete, you are prompted for confirmation. Clicking OK does not affect transport sets that are in the Export, Export In Progress, Precheck In Progress, Migration In Progress, Import, or Import In Progress statuses.

To generate a checklist to validate the transport set's readiness for import, click Generate Checklist.

11.6.2 Oracle Portal Import - Alternate Method

You can export and import content when both the source and target Oracle Portal instances exist in a customer database installation, and not in a product metadata repository. For details, refer to the information on staging a test environment from a production environment, in the Oracle Fusion Middleware Administrator's Guide.

11.7 Using the Oracle Portal Export and Import Command-line Scripts

If there is an intervening firewall between the source and target instances, you must use the Oracle Portal Export and Import command-line scripts to move the transport sets. The process consists of:

• Downloading the Command-line Scripts

• Running Your Script to Create an Export Dum File

• Importing the Transport Set Tables to the Target System

11.7.1 Downloading the Command-line Scripts

Use Download Scripts and View Log page to download the scripts as described below for Internet Explorer:

1. Right-click the selected script, then click Save Target As.

2. Change the name and remember to include the correct file extension, .csh for UNIX or .cmd for NT. For example, MyScript.csh.

3. Save the file to the directory on your file system where you want to run the export script. Usually, this directory is where your export portal resides.

   
   

   Note: This location must have access to the database. On some systems, the downloaded UNIX script requires you to set the Execute permissions correctly before running it. Ensure that you do not edit the export script.

   
   

11.7.2 Running Your Script to Create an Export Dum File

The next step in the export process are to create a transport set dump file using the script you created in the previous section, and then transfer your export data to your target system.

1. Run a script with the parameters shown in the following example. The example assumes that the name of the script is MyScript.csh. The parameters in bold are applicable only for export, and they are mandatory.

   %MyScript.csh
   Usage: MyScript.csh <-mode export_or_import_or_exportdp_or_importdp>
   <-s portal_schema><-p portal_password> <-pu portal_username><-pp portal_userpassword> <-company company_name> <-c connect_string><-d dump_file_names> <-dir directory_object> <-sp source_portal><-automatic_merge>
   

   
   

   Notes: Remember to set the infrastructure Oracle home (ORACLE_INSTANCE) when running the export script. The value for the company_name parameter is the company name you see in the login page when working in a hosted portal. When working in a portal that is not hosted, the value for the parameter should be none. If you are running the script in interactive mode, then do not pass a value. Ensure that you do not edit the export script.

   
   

   Table 11-10 provides a description of the parameters you can use in this process.

   Table 11-10 Parameter Descriptions

   Parameters	Description
   -mode	Mode for invoking the Export Import Command Line Utility EXPORT mode: Exports content to dump files using the Oracle Database exp utility. IMPORT mode: Imports content from dump files using the Oracle Database imp utility. EXPORTDP mode: Exports content to dump files using the Oracle Database expdp (ORACLE DATAPUMP EXPORT) utility. IMPORTDP mode: Imports content from dump files using the Oracle Database impdp (ORACLE DATAPUMP EXPORT) utility.
   -s portal_schema	Oracle Database account for the portal
   -p portal_password	Oracle Database password for the portal
   -pu portal_username	Lightweight user name for logging in to the portal
   -pp portal_userpassword	Lightweight user password for logging in to the portal
   -company company_name	Company name (for example, ORACLE)
   -c connect_string	TNS connection information to the remote database
   -d dump_file_names	Names of files for Oracle Export or Import utilities to write to or read from. If multiple file names are specified, then they must be separated by commas. For example: FILE1.DMP,FILE2.DMP Note: If multiple file names are not specified, then the Export or Import utilities will automatically prompt for another file name during the export and import process, if required.
   -dir directory_object	Directory Object for Oracle expdp/impdp utilities. The directory_object is the name of a database directory object (not the name of an actual directory) created by the database administrator (DBA) using the SQL CREATE DIRECTORY command (applicable modes => EXPORTDP / IMPORTDP)
   -sp source_portal	Oracle Database account for the source portal (applicable mode => IMPORTDP). Datapump import needs this information to map the schema objects from the dump to target).
   -automatic_merge	Automatically imports contents of the dump file (applicable modes => IMPORT / IMPDP)
   -automatic_precheck	Automatically prechecks the contents of the dump file (applicable modes => IMPORT / IMPDP)

   
   
   
   

   Note: The IMPORT utility can read only the dump created using the EXPORT utility. The IMPDP utility can read only the dump created using the EXPDP utility.

   
   

2. Transfer your export data. To do this:

   1. Run the script using -mode export or -mode exportdp as the option. For example, to run the script in EXPORT mode:

      myscript1.csh -mode export -s myportal -p myportal123 -c mydb -d myexport.dmp
      

      Or to run the script in EXPORTDP mode:

      myscript1.csh -mode exportdp -s myportal -p myportal123 -c mydb -d myexport.dmp -dir expimp_dir

      where expimp_dir is the logical directory created using "create directory command from SQL*Plus session", and mapped to any physical directory on the server.

   2. Finally, using FTP, transfer your dump file and the Export and Import script to the computer where your target Oracle Portal schema resides.

11.7.3 Importing the Transport Set Tables to the Target System

The final step is to use the command-line script to import the transport set tables to the target system. This is done by calling the same script (used in the export) with the -mode parameter set to import or importdb. The parameters in bold are applicable only for import and are mandatory. Refer to Table 11-10 for a description of the parameters.

%MyScript.csh
Usage: MyScript.csh <-mode export_or_import_or_exportdp_or_importdp>
<-s portal_schema><-p portal_password> <-pu portal_username><-pp portal_userpassword> <-company company_name> <-c connect_string><-d dump_file_names> <-dir directory_object> <-sp source_portal><-automatic_merge>

Example to run the script in IMPORT mode:
myscript1.csh -mode import -s myportal -p myportal123 -pu expimp_usr -pp expimp_usr123 -company ORACLE -c mydb -d myexport.dmp

Example to run the script in IMPORTDP mode:
myscript1.csh -mode importdp -s myportal -p myportal123 -pu expimp_usr -pp expimp_usr123 -sp myportal -company ORACLE -c mydb -d myexport.dmp -dir expimp_dir

To perform the entire import from the command line, which initiates a background process, you must include the portal user name and password parameters. This is required to validate your role on the target portal instance.

Notes: Remember to set the infrastructure Oracle home (ORACLE_INSTANCE) when running the import script. Before running the script using the -automatic_merge option, you must ensure that all external objects listed in the manifest exist in the target instance. You can ensure this by running the script using the -automatic_precheck option. External objects include database schema, tables, external applications, and so on. This information can be obtained by checking the external objects in the source instance. The value for the company_name parameter is the company name you see in the login page when working in a hosted portal. When working in a portal that is not hosted, the value for the parameter should be none. If you are running the script in interactive mode, then do not pass a value.

The contents of the dump files are imported, and the transport set is made available from the user interface for merging on the target portal system. Figure 11-18 shows how the import process works.

Figure 11-18 Import Process

Description of "Figure 11-18 Import Process"

The following steps summarize the import process:

1. You import the contents of the transport set dump file to the transport set tables utilizing the same script used in the export.

2. A background job is submitted to initiate the import, and log information is generated.

3. Once the import is complete, you can access the transport set from the user interface.

   The final step is to use the command-line script to import the transport set tables to the target system. This is done by calling the same script (used in the export) with the -mode parameter set to import or importdb. The parameters in bold are applicable only for import and are mandatory. Refer to Table 11-10 for a description of the parameters.

   %MyScript.csh
   Usage: MyScript.csh <-mode export_or_import_or_exportdp_or_importdp>
   <-s portal_schema><-p portal_password> <-pu portal_username><-pp portal_userpassword> <-company company_name> <-c connect_string><-d dump_file_names> <-dir directory_object> <-sp source_portal><-automatic_merge>
   
   Example to run the script in IMPORT mode:
   myscript1.csh -mode import -s myportal -p myportal123 -pu expimp_usr -pp expimp_usr123 -company ORACLE -c mydb -d myexport.dmp
   
   Example to run the script in IMPORTDP mode:
   myscript1.csh -mode importdp -s myportal -p myportal123 -pu expimp_usr -pp expimp_usr123 -sp myportal -company ORACLE -c mydb -d myexport.dmp -dir expimp_dir
   

   To perform the entire import from the command line, which initiates a background process, you must include the portal user name and password parameters. This is required to validate your role on the target portal instance.

   
   

   Notes: Remember to set the infrastructure Oracle home (ORACLE_HOME) when running the import script. Before running the script using the -automatic_merge option, you must ensure that all external objects listed in the manifest exist in the target instance. You can ensure this by running the script using the -automatic_precheck option. External objects include database schema, tables, external applications, and so on. This information can be obtained by checking the external objects in the source instance. The value for the company_name parameter is the company name you see in the login page when working in a hosted portal. When working in a portal that is not hosted, the value for the parameter should be none. If you are running the script in interactive mode, then do not pass a value.

   
   

   The contents of the dump files are imported, and the transport set is made available from the user interface for merging on the target portal system. Figure 11-18 shows how the import process works.

   Figure 11-19 Import Process

   
   Description of "Figure 11-19 Import Process"
   
   

   The following steps summarize the import process:

   1. You import the contents of the transport set dump file to the transport set tables utilizing the same script used in the export.

   2. A background job is submitted to initiate the import, and log information is generated.

   3. Once the import is complete, you can access the transport set from the user interface.

      
      

      Notes: To preserve data integrity, avoid: Importing an object, changing its name, and then reimporting it. Importing an object, moving it to shared objects, and then reimporting it. Importing an object, and then moving it from one hierarchy to another.

      
      

11.8 Behavior of Objects After Migration

The following considerations should be made before migrating portal content from a source instance to a target instance using Oracle Portal Export and Import. This section discusses the behavior of Oracle Portal objects after migration.

Import of Translations

Import of translations in Overwrite mode will not be a strict overwrite, and will act as if the translations are being merged. Any unwanted translations on the target, which do not exist on the source, are not removed when the page group is imported in Overwrite mode. You can remove the unwanted translations after the import. However, new translations brought from the source will be imported. This behavior is true for translations of all relevant objects in the subsequent tables.

This section contains the following subsections:

• Section 11.8.1, "Behavior of Oracle Portal Objects"

• Section 11.8.2, "Import Behavior of Child Objects"

• Section 11.8.3, "Behavior of DB Provider Objects"

• Section 11.8.4, "Behavior of Portal DB Provider Reports Object Types"

• Section 11.8.5, "Behavior of Web Providers"

• Section 11.8.6, "Behavior of Shared Portlet Instances"

11.8.1 Behavior of Oracle Portal Objects

This section discusses the behavior of the following portal objects after migration:

• Page Groups

• Attributes

• Approvals

• Items

• Pages

• Regions

• Portal Templates

• HTML Templates

• Categories

• Perspectives

• Navigation Pages

• Styles

• Item Types

• Page Types

11.8.1.1 Page Groups

On the first export and import, if a page group does not exist, then it is created on your target system. Any settings at the page group level are replicated on the target system. On the second import, depending on the mode selected:

Replace on Import mode. The page group properties from the source replace those on the target. All objects within the page group are created or updated depending on whether or not they existed.

Reuse mode. When page groups already exist on the target, the properties are reused and not updated. New objects within the page group are created; existing objects are reused.

Notes:

• New pages are currently not created when page groups are imported using Reuse mode.

• The order of visible objects (in the Configure tab) may differ between the source and target portal. The result is that the drop-down lists (when selecting an item, category, and so on) will look different in the target portal. You can manually reorder the visible objects in the target.

• All configurable settings of a page group are reused and overwritten appropriately in the Configure tab (found when you click Properties for a page group).

• If a page group is imported with a different name, then a new page group is created on the target.

• Migration of the Shared Objects page group excludes pages that cannot be edited or exported, for example, the A to Z root pages.

11.8.1.2 Attributes

On the first export and import, the attributes are created on the target system. The second import, depending on the mode selected for your target:

Replace on Import mode. The properties of the attribute are updated.

Reuse mode. When the attribute already exists on the target, it is reused and not updated.

Notes:

• Attributes that are marked as external cannot be created on the target, even with Any Transport Set - Manage privilege.

• Attributes on the source and the target can only be considered the same when they have the same name, are the same type and have the same unique internal identifier. If the two attributes have the same unique internal identifier but different names, then they can be only imported in Replace on Import mode. If the name and the type are the same, but the unique internal identifier is different, then the attribute import will fail and cascade to any other related objects.

11.8.1.3 Approvals

To view the approvers, access control lists must be exported and imported along with the page group or page that has an approval defined on it.

Replace on Import mode. The approval process can be established for a page or page group. If a page group or a page is marked for either insert or update, then the approval object will be processed in Replace on Import mode. All the approved information in the target will be deleted and re-created. Note that pending items on the source will not be imported, and any pending items on the target will be deleted altogether.

Reuse mode. No action is performed.

11.8.1.4 Items

Item information comes as a part of page export. They follow the import mode of the page.

Replace on Import mode. When a page is imported in Replace on Import mode, items in page regions from the source are copied to the target. Any items found only on the target are removed, items that exist on both the source and target are updated, and items that exist only on the source are created.

Reuse Mode. No items are imported from the source. The page from the source is only used as a reference, and will determine the import mode of items.

Notes:

• The schema associated with a PL/SQL item, page, or attribute, is extracted only if it is not a Public schema or a Creator schema. Such a schema is marked as an external object. The schema needs to be present on the target database to avoid a preliminary check failure. However, you can proceed with the import. The logs will show appropriate messages indicating that it will result in run time errors that can be corrected by bringing in the schema later and reassociating it.

• The list of object items will show differently between source and target unless you migrate those referenced objects (pages, categories, and perspectives) within the same transport set as the list of objects. Note that the Dependency Manager will not mark the objects referenced in the list of objects for export. For this reason, you need to explicitly mark those referenced objects for export, or ensure that they are already in the transport set.

• If portlet instance items are moved from one region to another between subsequent imports of the same page, then any personalizations made by users on those portlet instances are removed.

• Items for pages based on a template are synchronized, in Overwrite mode.

• All explicitly checked-out items in an active state are made checked-in after import.

11.8.1.5 Pages

Exports the page and the page type, template, and style it references along with content (item and portlets).

Replace on Import mode. The properties of the page are replaced. See Section 11.8.1.6, "Regions" for region import behavior. See Section 11.8.1.4, "Items" for item behavior.

Reuse mode. The original page on the target is reused. Child objects are not created on the target (if they do not already exist).

Refer to Table 11-11, "Import Behavior of Regions in Overwrite Mode", for information on import behavior when a page is imported in Overwrite mode.

Notes:

• The current release does not support locking and unlocking content using WebDAV. Content contributors can lock a file, which in turn will check out the item. On import, no owned locks will be displayed.

• When a page exposed as a portlet appears in the external objects list, make sure to include the page in the transport set.

11.8.1.6 Regions

Region information comes as part of page export. They follow the import mode of the page.

Replace on Import mode. When a page is imported in Replace on Import mode, page regions from the source are copied to the target. Any regions found only on the target are removed, including all content in those regions.

Reuse Mode. No regions or items are imported from the source. The page from the source is only used as a reference, it will determine the import mode of regions.

Note: This release of Oracle Portal implements synchronization of target regions with the source. See Table 11-11, "Import Behavior of Regions in Overwrite Mode" for more information.

Synchronization of Regions

This release of Oracle Portal implements synchronization of target regions with the source. The import behavior when a page is imported in Overwrite mode is described in Table 11-11.

Table 11-11 Import Behavior of Regions in Overwrite Mode

Case	Source	Target	import Behavior
Synchronization of target regions with the source	Region_A Region_B Region_D	Region_A Region_C Region_D Region_E	The attributes of Region_A and Region_D are updated with the properties from the source. Region_B is not found on the target and will be created. Region_C and Region_E, which exist only on the target, are deleted.
Region delete from target	-	-	When a region is deleted from the target, all the items and portlets, including user personalizations, are deleted from the target.
Root region mismatch for a page Note: A page can only have one root region.	Root region – Region_X	Root region – Region_Y	The entire root Region_Y hierarchy is deleted from the target and re-created with the Region_X hierarchy from the source.
Region type mismatch Note: Available region types are item, portlet, tab, and subpage.	Region_X – Type A	Region_X – Type B	When there is a region type mismatch, all the items and portlets under that region (including user personalizations) are removed from the target and re-created with the items from the source region.
Region type match	Region_X – Type A	Region_X – Type A	The target items are synchronized with the source items for that region.
Synchronization of target items with source Note: This happens whenever the source and target region type matches.	Item_A Item_B Item_D	Item_A (base user) Item_A (personalized for User A) Item_C (base user) Item_D (base user) Item_E (personalized for User B)	Item_A (base user) is overwritten. Item_A (User A personalization) is preserved on the target. Item_B is created on the target. Item_C (base user) is deleted from the source. Item_D (base user) is overwritten. Item_E (User B personalization) is preserved on the target. Note: Although Item_E does not exist in the source, it is not deleted from the target because it is a user personalization on the target. Only base user item records are part of the structure of a page, and are shown when a page is edited.

11.8.1.7 Portal Templates

Exports the template, the style it references, and any content on the template. The layout and content of pages that depend upon the template are synchronized with the revised template on the target.

Replace on Import mode. The template properties are replaced on import.

Reuse mode. Template information is reused on the target and is not updated from the settings on the source system.

Notes:

• Do not export or import the Category Pages Template or Perspective Pages Template found in the shared objects or page group. They are present only if a category or perspective is created in that page group.

• A template can force all pages based on the template to use the template's style, or it can allow pages based on it to have their own styles. When importing a template whose style has changed, the changes are only propagated to the pages based on the template, if the template forces the pages to use the template's style.

• Templates that were modified after the last import cannot be reused. If you try to reuse a modified template, then the template will fail the preliminary check stage along with the pages in the transport set that are based on the template. Appropriate messages are logged in the preliminary check logs indicating that you have to mark the template in Overwrite mode to proceed with the import.

• When a page or an item that uses Portal Templates for Items is migrated, the Portal Templates for Items are brought in as dependencies in the target.

• If pages based on a portal template are imported where the template is in Overwrite mode, any page customizations (such as move, hide, add, or delete) on page regions, items, or portlets based on the template are brought from source to target including regions and item/portlet movements. The target page should simply look same as the source page.

• If a portal template is imported in Overwrite mode, any page personalizations on the target are preserved as long as the base item, portlet, region, or tab exist in the migrated page.

Caution:

Deletions on a tab as part of personalizations on the target will be lost. The user will not be able to see any items or portlets under the personalized deleted tab after it is imported. This is because the template takes precedence and recreates the tabs on the target based on itself. However, since the personalization data is preserved, the actual items or portlets under the tab will not be recreated.

11.8.1.8 HTML Templates

On the first export and import, the HTML Templates are created on the target system. On the second import, depending on the mode selected for your target:

Replace on Import mode. The properties of the HTML Template are updated.

Reuse mode. If the HTML Template already exists on the target, then it is reused and not updated.

11.8.1.9 Categories

Exports the category and its subcategories.

Reuse mode. The original category on the target is reused. Child objects are not created on the target (if they do not already exist).

Notes:

• The category page (the page that appears when a category is clicked) and the category template are not exported. They are created each time on import. The category is always reused; therefore, you make changes once on the target, and the changes will not be lost during subsequent imports. This applies to the category, the category page, and the category template.

• There is no Replace on Import mode. The Replace on Import option will not apply; the category will always be reused.

11.8.1.10 Perspectives

Exports the perspective and its subperspectives.

Reuse mode. The original perspective on the target is reused. Child objects are not created on the target (if they do not already exist).

Notes:

• There is no Replace on Import mode. The Replace on Import option will not apply; the perspective will always be reused.

• The perspective page (the page that appears when a perspective is clicked) and the perspective template are not exported. They are created each time on import. The perspective is always reused; therefore, you make changes once on the target, and the changes will not be lost during subsequent imports. This applies to the perspective, the perspective page, and the perspective template.

11.8.1.11 Navigation Pages

Exports the navigation page, the style it references, and any links on the navigation page.

Replace on Import mode. The properties of the navigation page are replaced.

Reuse mode. The original navigation page on the target is reused.

11.8.1.12 Styles

Exports the style.

Replace on Import mode. The properties of the style are replaced.

Reuse mode. The style on the target is reused.

Notes:

• Styles on the source and the target are considered the same when they have the same name and the same unique internal identifier. If the two styles have the same unique internal identifier, but different names, then they can be only imported in Replace on Import mode.

• Attributes associated with styles are not imported. A local style is associated with all the local attributes of the page group to which the style belongs, and all the shared attributes. A shared style is associated with all the shared attributes.

11.8.1.13 Item Types

Exports the item type and the attributes it references.

Editable seeded item types present in all portal instances are extracted.

Notes:

• If you have to modify a seeded item type, then Oracle recommends you make a copy of the seeded item type, and then modify the properties of the copy.

• Item types on the source and the target are considered the same when they have the same name, are the same type, and have the same unique internal identifier. If the item types on the source and the target have same unique internal identifier, but different names, then they can only be imported in Replace on Import mode.

• Currently, when the attributes associated with the custom types (item type, page type) are modified or the functions associated with the custom type are modified between imports, the changes are not always correctly migrated. You should delete and re-create the custom type on the target. This results in all the items and pages (based on the custom type) being deleted.

• If an item link in a page points to an item on another page, then during export of the page containing the item link, the page containing the linked object is brought in as a dependent page.

11.8.1.14 Page Types

Exports the page type and the attributes it references.

Notes:

• Page Types on the source and the target can only be considered the same when they have the same name, are the same type and have the same unique internal identifier. If the page types on the source and the target have same unique internal identifier but different names then they can only be imported in Replace on Import mode.

• Currently, when the attributes associated with the custom types (item type, page type) are modified or the functions associated with the custom type are modified between imports, the changes are not always correctly migrated. You should delete and re-create the custom type on the target. This will result in all the items/pages (based on the custom type) being deleted.

11.8.2 Import Behavior of Child Objects

This section describes the functioning of child objects after migration. Table 11-12 describes the behavior in detail.

Table 11-12 Import Behavior of Child Objects

Name of Object	Objects	Import Behavior
Contained objects, which contribute to the structure of the object	Regions Items Tabs and subtabs on a page	Contained objects are created or overwritten when the contained object is created or overwritten. When container objects are reused for the target, none of the contained objects will be created from the transport set, even if they do not exist on the target.
Contained objects that do not contribute to the structure of the object, but act as placeholders within a container.	Attribute, Style, Category, Perspective, Item Type, Page Type, Page, and so on, in a page group. Form, Report, Chart, Dynamic Page, and so on, in a Portal DB Provider.	Contained objects are created when the container object exists on the target, or are created from the transport set. When container objects are reused for the target, only new contained objects will be created from the transport set. All the existing objects will be left untouched on the target.
Child objects	Subpage Subcategory and subperspective	Child objects are created when the parent object exists on the target, or are created from the transport set.

11.8.3 Behavior of DB Provider Objects

This section describes the behavior of the following DB Provider objects after migration:

• Seeded DB Providers

• Portal DB Providers

• Portal DB Provider Components

• Shared Components

• Registered Database Providers

11.8.3.1 Seeded DB Providers

• When a page with Develop-in-Place portlets is imported, the components related to those portlets are automatically created in the database schema of the target portal's Develop-in-Place provider.

  The name of the Develop-in-Place database provider is PTL_TOOLS_APP. The underlying database schema for PTL_TOOLS_APP is <PortalSchema>_APP.

• For other seeded database providers, the relevant components brought in from the source portal are automatically created in the database schema of the target portal's database provider, if the provider already exists on the target portal.

  You have to make the seeded database provider a part of the transport set, if it does not already exist on the target portal. Otherwise, you do not need to move it.

Notes:

• The Develop-in-Place provider cannot be exported or imported on a standalone basis, that is, the Develop-in-Place portlets have to exist on a page.

• The Develop-in-Place provider, unlike other database providers, does not show up as an external object in the UI manifest.

• When migrating any database provider, if the Develop-in-Place components or components from other database providers are getting their data from database objects in a schema other than the underlying schema for the database provider, then that database schema should also be exported and imported into the target portal in advance using the exp and imp utilities.

11.8.3.2 Portal DB Providers

On the first export and import, if a Portal DB Provider does not exist, then it is created on the target system.

• Portal DB Provider properties will be created on the target.

• Provider registration will be done for the newly created Portal DB Provider.

On the second import, depending on the mode selected for the target:

Replace on Import mode. The Portal DB Provider properties from the source replace those on the target. All components within the Portal DB Provider are created or updated depending on whether or not they exist.

Reuse mode. When a Portal DB Provider already exists on the target, the properties are reused and not updated. New components within the Portal DB Provider are created, and existing components are reused.

Note: If you are migrating a Portal DB Provider, then you need to perform the following tasks before importing the Portal DB Provider: Ensure that the schema that is used by the Portal DB Provider being exported, exists in the target database instance and that the CONNECT and RESOURCE roles have been granted to it. Run the provsyns.sql script (located in the MID_TIER_ORACLE_HOME/portal/admin/plsql/wwc directory) on the target. Using SQL*Plus, log in as the Portal schema owner and run the script from the SQL prompt, as follows: SQL> @provsyns.sql <db_provider_schema_name> The provsyns.sql script can be executed multiple times for a Portal DB Provider schema.

11.8.3.3 Portal DB Provider Components

The following are the Portal DB Provider components:

• Menu

• Forms

• Reports

• Charts

• Calendars

• List of Values

• Link

• Hierarchies

• Dynamic Pages

• XML/URL Components

• Data Components

On the first export and import, the components are created on the target system.

• The first version of the component will be created under the nominated Portal DB Provider, and this will be the production version.

• A package will be created with the same name as the component under the schema associated with the Portal DB Provider.

On the second import, depending on the mode selected for the target:

Replace on Import mode. A new version of the component is created on top of any existing versions, and this will be the production version. Existing versions on the target, if any, will be archived. The package will be regenerated with the information obtained from the production version.

Reuse mode. If the component does not exist on the target, then it will be created.

Notes:

• List of Values and Link components do not have versions or a package associated with them. Therefore, these components are deleted and re-created on the target, in Overwrite mode.

• Because the List of Values and Link components cannot render on their own, or they are not in portlet form, there will not be any personalizations attached to these components.

• The List of Values (LOV) appears as an external object, which you can choose to make explicit. If an LOV does not exist on the target, then the import will proceed, and the logs will indicate that the LOV associated with the attribute was reset, and you could bring in the LOV and reassociate it later.

11.8.3.4 Shared Components

The following are the shared components:

• Color

• Font

• Image

• JavaScript

• UI Templates (Structured, Unstructured)

On the first export and import, if a shared component does not exist, then it is created on the target system.

On the second import, depending on the mode selected for the target:

Replace on Import mode. The shared components are deleted and re-created with the source information.

Reuse mode. When a shared component already exists on the target, the properties are reused and not updated. New shared components are created, and existing components are reused.

Note: System colors, fonts, and templates are reused on the target, and they are never exported and imported.

11.8.3.5 Registered Database Providers

The schema associated with a registered database provider is marked as an external object in the manifest. Note that on import:

• If the provider and the schema do not exist on the target, then the schema fails the preliminary check, which causes the provider to fail, in turn causing the explicit object to fail.

• If the provider exists and the schema differs on the source and the target, then the provider is assigned a warning status, and the logs will display that a difference in schemas exists.

Note: You must ensure that all the objects are valid after you migrate the schema from the source to the target, to avoid database registration errors.

11.8.4 Behavior of Portal DB Provider Reports Object Types

The Report Security Access Objects are always exported or imported as part of the Portal DB Provider export and import.

Notes:

• The granular export and import of Report Security Access Components are not supported.

• The Report Security Access Components behave in the same manner as DB Provider components in versioning.

• A package is created or regenerated for the Report Definition File (RDF) access component, similar to DB Provider Components.

11.8.5 Behavior of Web Providers

This section describes the following Web providers:

• OmniPortlet

• Web Clipping Providers, WSRP Producers, and Other Web Providers

Enabling and Disabling Export and Import of Web Providers

To enable or disable the migration of OmniPortlet and Web Clipping providers, edit the following variable in the MW_HOME\user_projects\domains\<DomainName>\servers\WLS_PORTAL\tmp\_WL_user\portalTools_11.1.1.1.0\kjdcke\war\WEB-INF\web.xml file:

<env-entry>
<env-entry-name>oracle/portal/provider/global/transportEnabled</env-entry-name>
   <env-entry-value>true</env-entry-value>
   <env-entry-type>java.lang.String</env-entry-type>
</env-entry>

Set the value to false to disable export and import of OmniPortlet and Web Clipping providers.

11.8.5.1 OmniPortlet

OmniPortlet providers, including their default personalizations and related information, referenced by your transport set will be exported and imported with the pages automatically.

Connection information (for example database, user name, password, URL, HTTP authentication user name and password, and so on) associated with an OmniPortlet instance is migrated automatically by default.

If you want to disable the exporting and importing of connection information because of security reasons, then edit the MW_HOME\user_projects\domains\<DomainName>\servers\WLS_PORTAL\tmp\_WL_user\portalTools_11.1.1.1.0\1pwj8k\war\WEB-INF\providers\omniPortlet\provider.xml file and set the exportConnectionInfo parameter to false. For example:

<provider class="oracle.webdb.reformlet.ReformletProvider">
   <exportConnectionInfo>false</exportConnectionInfo>
   ...
</provider> 

If the connection information is not migrated, then the imported OmniPortlet uses the connection information of the same name on the target, if it exists. You can also enter the connection information of the imported OmniPortlet instance from the Edit Defaults page or the Personalize page.

If the connection information to be imported has the same name as an existing connection information of a provider in the target, then the source provider's connection information will not be imported unless the Overwrite mode is specified. Messages will be written to the transport log if the import of connection information failed.

Reuse mode. OmniPortlet providers are always reused.

Notes:

• If the provider registration generates an error due to insufficient privileges, then the provider object fails the preliminary check stage. This is then cascaded to the explicitly selected objects. A provider failing always fails the explicitly selected objects.

• Edit Default customizations are migrated. User personalizations are preserved on target, if present.

Important:

• If localePersonalizationLevel is different between the source OmniPortlet provider and target OmniPortlet provider, then some imported personalizations may become inaccessible in the imported pages. For example, if the current locale is Japanese, and if localePersonalizationLevel is set to locale on the source OmniPortlet provider and to none on the target OmniPortlet provider, then the Japanese personalizations will become inaccessible after importing.

  You can set localePersonalizationLevel in the provider.xml file located in the directory, MW_HOME\user_projects\domains\<DomainName>\servers\WLS_PORTAL\tmp\_WL_user\portalTools_11.1.1.1.0\1pwj8k\war\WEB-INF\providers\omniPortlet.

  For detailed information about localePersonalizationLevel, see the release note at MID_TIER_ORACLE_HOME/portal/pdkjava/v2/pdkjava.v2.release.notes.html.

• If OmniPortlet portlets are configured to use an SSL URL for fetching data, then you must copy these files manually, as SSL URL certificates are not exported and imported by default. Perform the following steps to manually copy the certificate files to the target instance:

  1. Append the SSL URL certificates to the certificate file used by the OmniPortlet provider (default is ORACLE_HOME\portal\conf/ca-bundle.crt).

  2. Update the <trustedCertificateLocation> tag in OmniPortlet provider.xml file located in MW_HOME\user_projects\domains\<DomainName>\servers\WLS_PORTAL\tmp\_WL_user\portalTools_11.1.1.1.0\1pwj8k\war\WEB-INF\providers\omniPortlet.

  3. Restart WLS_PORTAL.

11.8.5.2 Web Clipping Providers, WSRP Producers, and Other Web Providers

Web Clipping providers, WSRP producers, and other Web providers referenced by your transport set must either exist already on your target system or be able to be registered successfully during the import on your target system.

Reuse mode. Web Clipping providers, WSRP producers, and other Web providers are always reused.

Important: If Web Clipping portlets are configured to use SSL URLs for fetching data, then you must copy these files manually, as SSL URL certificates are not exported and imported by default. Perform the following steps to manually copy the certificate files to the target instance:

1. Append the SSL URL certificates to the certificate file used by the Web Clipping provider (default is MID_TIER_ORACLE_HOME/portal/conf/ca-bundle.crt).

2. Update the <trustedCertificateLocation> tag in the OmniPortlet provider.xml file located in MW_HOME\user_projects\domains\<DomainName>\servers\WLS_PORTAL\tmp\_WL_user\portalTools_11.1.1.1.0\1pwj8k\war\WEB-INF\providers\omniPortlet.

3. Restart WLS_PORTAL.

Notes:

• If the provider registration generates an error due to insufficient privileges, then the provider object fails the preliminary check stage. This is then cascaded to the explicitly selected objects. A provider failing always fails the explicitly selected objects.

• When WSRP portlets are imported, the portlet personalizations are not imported.

11.8.6 Behavior of Shared Portlet Instances

The scenarios in Figure 11-19 summarize the behavior of shared portlet instances during migration.

Table 11-13 Behavior of Shared Portlet Instances During Migration

Source	Target
Export the shared portlet user page (without the portlet repository information).	Import the shared portlet for the first time. Register it under the portlet repository with the display name of the shared portlet instance.
Note that t
Rename the shared portlet instance. Note that these changes are not reflected on the portlet repository item which will still contain the original name/display-name) Export the user page.	Import the renamed shared portlet instance after it is already exists on the target. Since the portlet instance is reused on the target, the display-name changes from the source are not migrated.

11.9 Recommended Best Practices When Exporting and Importing

The following is a summary of important recommendations and best practices developed for migrating portal content from a development or test environment to a production instance using Oracle Portal Export and Import.

• Naming Convention for Replicated Tabs

• Migrating Page Groups and Components

• Migrating Portal DB Providers and Components

• Migrating Search Components

• Migrating Content Between Upgraded Oracle Portal Instances

• Exporting and Importing in a Hosted Environment

• Importing Data with Oracle Text Index Synchronization Turned Off

• Migrating Users and Groups

11.9.1 Naming Convention for Replicated Tabs

In earlier releases, the replicated tabs on the target had a different name from that on the source when the tabs were replicated on the pages based on the template. As a result, when you brought in the page at a later time, the tabs on the source did not match the ones on the target, and extra tabs were created on the target.

In this release of Oracle Portal, having a predictable naming convention for replicated template tabs helps to avoid duplication of tabs. Because a page name has to be unique only in a hierarchy, the replicated tabs assume the same name as the template tab. However, you must ensure that you do not rename the replicated tab.

11.9.2 Migrating Page Groups and Components

Page groups and their associated components may be moved from development to production using the Export and Import utilities described in this document. In addition to page groups as a whole, individual components within page groups such as subpages, categories, perspectives, and page styles can be moved individually to the target system, only if the entire page group has been imported to the target system earlier.

• Considerations and best practices to keep in mind:

  • The first export to your target system migrates the entire page group from the source portal to the target portal instance. Subsequent transport sets can then export an individual page or other page group component on the target portal installation.

    
    

    Note: The preliminary check process will fail for an object if the page group does not exist on the target. Whenever a page group object is exported, the page group that owns the object is included as an external dependency. You can choose to make the page group explicit if you do not know if the page group exists on the target, and therefore avoid any potential preliminary check failures. The same applies to other objects included in a hierarchy. Categories, perspectives, and pages when exported display the parent category, perspective, or page as an external dependency in addition to the page group to which they belong. All database provider components display the provider as an external dependent when they are exported by themselves. The default settings of a page group, for example, the default template, style, navigation page, and so on are also extracted by the Dependency Manager and classified as either reference or external (that is, local or shared).

    
    

  • All new or existing content on a page is replaced when a page with the same name is reimported to the target.

  • You can only move objects within a page group to the same page group of the same name on the target portal.

  • A page is migrated along with any subpages.

  • After an initial import operation to your target system, if you change the name of the page group on the target system, then subsequent import attempts to that page group will fail.

  • Categories, item types, perspectives, and page types that are configured in the source are not automatically configured in the target. You must explicitly configure these objects unless you are doing a page group export.

• Page URL behavior: Always use page link item types or path-based URLs when creating links to portal pages. Do not use raw portal page URLs.

  By default, portal page URLs generated by Oracle Portal contain installation-specific ID numbers that change when the object is exported. This causes broken links when pages are imported into a different site.

  The following is an example of a URL generated for a page. If the page is imported on another site, then this page ID will change.

  http://my.portal.com/servlet/page?_pageid=47,49&_dad=portalr2&_schema=portal
  

  If you are using such URLs as manually entered links, then Oracle recommends you use path-based URLs or Page Link item types.

  The same page has the following path-based URL:

  http://my.portal.com/portal/pls/portal/url/PAGE/HRPAGEGROUP/HRHOME/HRBENEFITS
  

  To find the path-based URL for a page, look at the page property sheet. A link to the property sheet can be displayed by adding a Property Sheet Smart Link item to the page.

  You can also use a Page Link item type to create a link to a page. The Page Link item type dynamically generates the correct link at run time.

• Page portlets: When you replace a page, the content and the structure are replaced on the target.

  
  

  Note: This release does not support importing and exporting the Oracle Portal Survey components or the Favorites portlet. Any new Favorites or Groups added in the source will not show up in the transport set, nor will they be migrated to the target. This release supports exporting and importing generic page portlets. A generic page portlet can now be configured to point to any page. The page that the page portlet points to is marked by the Dependency Manager as referenced/external depending on whether or not it belongs to the same page group. On import, this information is resolved and stored in the preference store. On import, if the page does not exist on the target, then the portlet is reset. This release supports exporting and importing Web providers and their default personalizations. See the section on controlling the export and import of portlet personalizations in the Oracle Fusion Middleware Developer's Guide for Oracle Portal.

  
  

  To preserve the content in a page (items, portlets) on the target, but import a style layout, or for rendering changes from the source, you must expose your content through the Federated Portal Adapter portlet. The key is to separate your content from your page structure into two separate page groups. One for content only, exposed through the Federated Portal Adapter, and the other is your display page group. Users can use this to access, view, and customize their portal. Follow these steps:

  1. On the source system, create a page group that only contains pages that have one region that you will later expose to other pages. This region is to be populated with either portlets or items. Name this page group Content Page Group.

  2. Export this content page group to the target system.

  3. On the target system, register the content page group through the Federated Portal Adapter. Expose these pages as portlets through the Federated Portal Adapter provider on the target system.

  4. On the source system, register the same provider (using the same name as the Federated Portal Adapter provider).

  5. On the source system, create another page group called Display Page. In this page group, create pages with regions that expose the portlets from the Federated Portal Adapter provider. You can also include tabs and other portlet regions in this page group if required.

  6. Export the Display Page group to the target system.

  7. From the target system, update, delete, modify, and add new items to the regions and pages in the content page group exposed through the Federated Portal Adapter provider.

  8. On the source system, make changes to the page structure (tabs, new regions, and so on) to the Display Page page group.

  9. Export the latest Display Page page group to the target system.

  10. Verify that the Content Page Group contains the new changes that you made in Step 7, on the target environment.

  11. Verify that the target system contains the latest changes to the pages in the Display Page page group that you recently changed.

      
      

      Note: When a page containing a portlet from an adapter rendered provider (the loop-back case) is imported and the provider is automatically registered on the new portal, it will have the old URL, referencing the old portal. When a loop-back provider is required in the new portal, you will have to create one or update the default provider.

      
      

• Page and Portlet Personalizations and Edit Defaults Migration. You can preserve the user customizations on a page or portlet on the target system while replacing or reusing the edit properties of that page or portlet.

  
  

  Note: Personalizations for Web portlets are not currently preserved. Migration of Edit Defaults is supported for OmniPortlet and Web Clipping providers. If other providers implement this feature, their Edit Defaults will also be migrated. See the Oracle Fusion Middleware Developer's Guide for Oracle Portal for information about how to implement this support.

  
  

  Base objects that no longer exist on the page in the source portal will be removed from the target page after subsequent imports. This ensures that all personalizations for base portlet regions are also removed. Base objects are regions, portlets, items, and tabs that are imported as part of the core definition of the page, defining its structure and content.

  Portlets that already exist on a page behave in the following way when the page is imported in Replace on Import mode:

  • Edit Defaults will be migrated.

  • User Personalizations will be preserved.

  Properties of the page behave in the following way when the page is imported in Replace on Import mode:

  • Edit Properties will be replaced.

  • User Personalizations will be preserved, subject to the user customizations being valid.

    
    

    Note: You can personalize, add, hide or show, delete, and move portlets and tabs. The page must have at least one portlet region and one tab (tab related customizations) in that region. The customized objects inherit the properties of the page. When a region is deleted, for example, a second import removes the region or tab from the page, then customized objects will also be deleted.

    
    

  When you import the page with an increase in the number of portlets on a page, the source takes precedence even if you have customized the page in the target and deleted a portlet. The next time you import the same page, the deleted portlet is considered to be a new portlet to be added to the structure on the target. This also applies to tabs.

  The order of appearance of these portlets (personalizations) and the portlets that form the content of the page are determined by the source and mode of import.

  • Replace on Import mode. The portlets from the source are arranged in the order found in the source followed by the portlets in the target (personalizations).

  • Reuse Mode. The personalizations are preserved, and there will be no changes to the target page.

11.9.3 Migrating Portal DB Providers and Components

Portal DB Providers and their associated components can be moved from a development environment to a production environment using the Export and Import utilities described in this chapter. In addition to Portal DB Providers as a whole, individual components within Portal DB Provider such as forms, reports, charts, and calendars can be moved individually to a target system. This is possible only if the entire Portal DB Provider was imported to the target system earlier.

Some considerations and best practices for migrating Portal DB Provider components are:

• Do not rearrange Portal DB Provider portlet IDs directly in the provider.xml file as this is likely to cause problems after migration.

• Avoid using the portal schema for storing Portal DB Provider components, or the database objects that the components reference.

  • In the source environment, create a separate schema (referred to as the portlets schema) for the Portal DB Provider components. This is the schema that is referenced in the registration information when the Portal DB Provider is created.

    
    

    For more information, see the section "Creating a Schema in Oracle Portal" in the Oracle Fusion Middleware Developer's Guide for Oracle Portal.

  • In the source environment, create a separate schema (referred to as the database objects schema) for the database objects that the components reference. If the database objects already exist in a particular schema, then ensure that this schema is not referenced when creating the Portal DB Provider. This is the schema that holds database objects such as Tables, Views, or Procedures that are used in the creation of Portlet DB Provider components. For example, when you build a form based on a table, view, or a procedure, the table, view, or procedure is stored in the database objects schema.

  • Before importing the Portal DB Provider and its components, ensure that the database objects schema referenced by the components is available in the target environment. The database objects schema must have the same name as in the source environment. Ensure that the database objects and database objects schema have the same grants and privileges as in the source environment. Also ensure that the status of all database objects is valid. The database objects schema can be exported or imported using the database's export or import utilities.

  • Before importing the Portal DB Provider and its components, create an empty portlets schema in the target environment with the same name as in the source environment.

• Ensure that the Portal DB Provider does not have any components that are in Edit or Archive mode. All components being exported should have only one valid production version to ensure that the target environment contains valid components after an import.

• If a page group contains portlets from a Portal DB Provider, then the provider has to be explicitly included in the transport set you are exporting. As an alternative, you can also export or import the provider earlier.

• The schema associated with registered Portal DB Providers is extracted as external object on the manifest.

Note: While importing a database objects schema, you must ensure that the ACLs (roles and privileges) associated with the schema already exist on the target system. This ensures that the generation of components, or the registration of database providers, does not fail during the import.

11.9.4 Migrating Search Components

There a number of options for adding search components to your pages. You can add a Basic Search to match search criteria entered into the Search field, an Advanced Search, and a Custom Search to create an automatically executed search.

11.9.4.1 Basic and Advanced Search Portlets

Basic Search portlets and Advanced Search portlets can be exported and imported. After import, the portlets should appear as they did in the source portal including the user preferences (if the user preferences were being imported).

11.9.4.2 Custom Search Portlets

Custom Search portlets can have many customizations which refer to other objects in the portal, such as page groups to search, attributes to search on, image on submission form, style for results, page for the results, attributes for the results, default values for category, perspective and item type attributes. These can be referred to as dependencies. When a custom search portlet is exported and imported, its dependencies are calculated and shown as external dependencies in the manifest. It is up to the user to include it in the transport set, so that it is exported and imported as well.

If not included, it is possible that a custom search portlet can be customized in the source but the dependencies do not exist in the target. Also, a custom search portlet in the source may have been customized and then the dependency is removed from the portal and the custom search portlet's customizations are not updated. In this case, when the custom search portlet is used for a search, the missing reference is ignored. When the custom search portlet is customized again and the customizations saved the missing reference is removed.

On export, all the custom search portlets that were selected for export are checked and any missing references are removed. The customizations are then included in the transport set.

On import, a preliminary check determines if any dependencies are missing in the target after import. Messages are written to the log. For each custom search portlet that has missing dependencies, the log will show the reference path of the custom search portlet and the missing dependencies and what will happen on import.

The page on which the custom search portlet resides will be flagged with a warning. On the actual import, the custom search portlet customizations are modified to have the correct IDs of all the same dependencies in the target, and the customizations are copied into the target.

Note: Search results saved using the Saved Searches portlet are not imported or exported. You should submit the same search in the new target and save the latest set of search results.

11.9.5 Migrating Content Between Upgraded Oracle Portal Instances

Export and import is not supported between two portals that are upgraded from releases earlier than 9.0.2. For example, assume that you have a source development portal instance and a target production portal instance, both of release 3.0.9. You then upgrade both the instances independently to release 9.0.4, and then to release 11.1.1. Exporting and importing content between these two upgraded 11.1.1 development and production instances is not supported.

During an upgrade from a pre-9.0.2 release of Oracle Portal, objects (styles, attributes, item types, and page types) are given a new Global Unique Identifier (GUID). If the GUIDs do not match between objects in two Oracle Portal instances, then the preliminary check for these objects will fail. If, for example, you have a source development instance and a target production instance, then you must resynchronize the Oracle Portal instances to avoid preliminary check failures. To do this, perform the following steps:

1. Create an empty portal instance that will become the new source development instance.

2. Export the contents of the target production portal instance.

3. Import the contents into the new source development portal instance.

You have now exported and imported the contents from your target production portal instance to the new source development portal instance.

References to seeded page group objects, such as Top Level Pages and Design-Time Pages, will not resolve to the correct GUIDs across two instances. Remove these references from the objects you are exporting. Alternatively, you can create new objects that copy the functionality of the seeded page group objects.

Caution: Any new components in the development instance are lost during the re-creation of the development portal instance. Migrate all the new components from the development instance to the production instance before you upgrade the production instance. If you have partially developed components, then you must re-create these after the new development portal instance is created.

See Also: Section 11.4.2, "Oracle Portal Export - Alternate Method" and Section 11.6.2, "Oracle Portal Import - Alternate Method"

11.9.6 Exporting and Importing in a Hosted Environment

Oracle Portal Export and Import supports the creation of classified content that can be used for replicating content and structure for new subscriptions. It does this by letting the portal instance set the subscription information during the import of the transport set contents into system tables. This means that in a hosted environment, you can export from any subscription, and you can import into any other subscription. This import is not limited to just one subscription; you can import the contents of the same transport set into multiple subscriptions, as follows:

1. Run the command-line utility in import mode.

2. Log in to a subscription.

3. Import the contents of the transport set into the subscription.

Example 11-1 shows a scenario where Oracle Portal Export and Import can be used to import the contents of a transport set into multiple subscriptions.

Example 11-1 Importing Content into Multiple Subscriptions

1. Create a default seed subscription where the objects will be created and managed.

   In this subscription, you create a classified content and structure, which could consist of page groups, pages, other page group objects, Portal DB Providers and their components (exposed as portlets in the pages), portlets from Web providers, and so on.

2. Export the content and structure to a transport set, which becomes the seed transport set.

3. Export the contents of the transport set to a dump file.

4. Create a new subscription with the same structure and content defined earlier, by performing the following steps:

   1. Create the new subscription.

   2. Import the contents of the dump file into the portal instance.

   3. Log in to the new subscription.

   4. From the Transport Set portlet, select the transport set and import it.

   5. Verify that the new subscription now contains the required structure and content.

5. Repeat the previous step for each new subscription that you want to be based on the structure and content created in step 1.

This procedure can be used to create multiple taxonomic categories by creating transport sets for each category, and following the preceding procedure to populate new subscriptions.

Note: In a hosted environment with multiple subscribers, you cannot secure transport sets to a specific subscription in Oracle Portal. If you created a transport set for export and import, then any other user who logs in to Oracle Portal will be able to view the contents of the transport set that you created, in all subscriptions in that portal.

11.9.7 Importing Data with Oracle Text Index Synchronization Turned Off

While importing large data sets into a target Oracle Portal instance, it is sometimes observed that the import process takes a longer time than normal, if synchronization of Oracle Text indexes is enabled. The import process is faster if you disable the synchronization of text indexes for the period of the import. To disable the synchronization of Oracle Text indexes, perform the following steps:

1. Before you start the import process, run the following command in the target Oracle Portal instance as the portal schema owner (PORTAL):

   @textjsub.sql STOP
   

   Refer to Section 9.3.5.4, "Scheduling Index Synchronization" for details on scheduling, starting, and stopping text index synchronization.

2. Ensure that the wwv_context.sync job does not exist on the dba_jobs table.

3. Import your data set. See Section 11.6.1.2, "Importing Data" for more details.

4. Run the textjsub.sql script as the portal schema owner (PORTAL):

   @textjsub.sql START
   

5. Optionally, run the command to synchronize Oracle Text indexes. Refer to Section 9.3.5.1, "Synchronizing Oracle Text Indexes" for the procedure to do this.

11.9.8 Migrating Users and Groups

Oracle recommends the following procedure for exporting and importing:

• Develop your portal objects (page groups, content, portlets, and so on) on your source development system.

• To simplify the task of exporting and importing, assign users, groups, and privileges only on your production system.

• Use Export and Import to migrate your portal objects to your target production system.

• Apply users and privileges to imported portal objects as needed.

Users and groups are defined in Oracle Internet Directory. When you choose to include access control lists and User and Group preferences during Oracle Portal Export, the user and group profiles held in the portal schema are included in the transport set. However, this does not migrate the user and group definitions that are held in Oracle Internet Directory.

For the user and group profiles to be properly imported on the target portal, the user and groups that they refer to must exist in the target portal's associated Oracle Internet Directory.

If you are building your portal content on a test or development server, with the intention to then move that content to a production server, you have the option of assigning your security privileges on the test server and then migrating them, along with the content, to your production server.

In this scenario, assign the privileges to groups, so there is no need to ensure the consistency of the user population between the test and production infrastructures.

If you want to precisely model your user population on both the production and test servers, the best approach is to use Oracle Directory Integration and Provisioning capabilities to synchronize the data from the production directory server to the test server. Synchronizing the data from production to test also provides you the option of adding test users and groups to the test Oracle Internet Directory server without affecting the production server.

Note: See the Oracle Fusion Middleware Administrator's Guide for Oracle Internet Directory for more information on setting up directory synchronization. Note that it is advisable to automatically synchronize the data from production to test, but not the other way around. The Oracle Fusion Middleware Administrator's Guide for Oracle Internet Directory can also be referred for additional information on migrating users and groups.

With the production groups also present on the test server, you can model and test all your access privileges on the test server and then safely migrate the portal access control lists with your exported objects onto the production system.

If you are introducing new groups and access privileges for those groups on the test system, then before you move the portal content and access control lists to production, make sure you migrate the group definitions to production first. You can actually create the groups on production first, and let the synchronization process reflect the new group on the test system before applying the test access control entries, if you need to actually create the group on the test instance first, you can create the group on production with the same means you used to generate the group on test. If this was done manually, and you want to avoid repeating the manual step on production, you can issue an LDAP query on the test instance to generate an LDIF file, which you can then load onto the production instance. For example:

%ldapsearch –h testoid.domain.com –p 389 –D cn=fmwadmin –w password123 -b 'cn=portal.iasdb.domain.com,cn=groups,dc=domain,dc=com' –s sub –L 'cn=groupname' > newgroup.ldif

Note: Before loading the LDIF file containing the group information into the production Oracle Internet Directory instance, you may need to edit the file to correct the portal instance name to match the name for that portal instance on the production Oracle Internet Directory instance. This name will typically be different between the test and the production instances and the name is part of the group DN, so it will have to be modified before loading the file.

In this example, cn=portal.iasdb.dbserver.domain.dcom, cn=groups, dc=us, dc=oracle, dc=com is the location under which the portal groups are located. Refer to Chapter 7, "Securing Oracle Portal" for more information on the organization of the entries in the Directory Information Tree in Oracle Internet Directory. This creates a file called newgroup.ldif containing the group definition. You can then load the file on the production Oracle Internet Directory instance by using ldapadd:

%ldapadd –h prodoid.domain.com –p 389 –D cn=fmwadmin –w password123 –v -f newgroup.ldif

You may only want to deploy default privileges granted to some of the seeded portal groups, or no privileges at all. If no privileges are deployed, then the user performing the import will own the objects. The user can then further grant privileges on the target system as necessary for the specific deployment.

There is no need to synchronize seeded groups or users, assuming that, if privileges are granted to seeded groups in Portal, and those seeded groups are still present on the target system, then the privileges will be correctly associated with those seeded groups.

When migrating group profiles from the source to the target, the import will remap the DNs of the groups to the local group base on the target system if the exported profile was one for a local group on the source. A local group is one that is under the portal group container (the group install base). For groups that were not under the group install base, the DN will remain unchanged.

Note: The ssoexp and ssoimp scripts found in the wwu directory are obsolete for Oracle Fusion Middleware 9.0.x and not compatible with the 9.0.x login server. These should not be used.