|
Oracle® Application Server Portal Configuration Guide
10g Release 2 (10.1.4) B19305-03 |
|
 Previous |
 Next |
|
Oracle® Application Server Portal Configuration Guide
10g Release 2 (10.1.4) B19305-03 |
|
|
Previous |
Next |
OracleAS 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:
This section describes the tasks you need to perform and information about how OracleAS Portal Export and Import works with other components of Oracle Application Server. This section contains the following topics:
How Does OracleAS Portal Export and Import Work?
The OracleAS Portal Export and Import process consists of the following steps:
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.
Move the transport sets from one system (source) to another (target) using the OracleAS Portal Export and Import command-line scripts, which create a dump file of the transport set.
Transfer the Export and Import command-line script and the dump file to the target system using FTP or another file transfer utility.
Invoke the Export and Import command-line script to import the dump file to the transport tables on your target system.
Import the objects from the transport tables to the target portal repository using the Transport Set Manager portlet.
Additional Information
Refer to the section on moving product-specific metadata for OracleAS Portal from a test metadata repository to a production metadata repository in the Oracle Application Server Administrator's Guide.
Refer to the section about controlling the exporting and importing of portlet personalizations in the Oracle Application Server Portal Developer's Guide.
This section describes the prerequisites to exporting and importing in OracleAS Portal, use cases, and the OracleAS Portal Export and Import processes. This section contains the following topics:
Before beginning the export and import process, ensure you have the following information:
OracleAS 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, leave it blank.
|
Note: The OracleAS Portal schema password is a random password created when the application is installed. |
Before exporting and importing content, ensure that your system meets the minimum system requirements, as described in this section.
Using Different Releases of Export. 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:
|
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 10.1.2 release of the middle tier uses a 10.1.0.2 release Oracle home.
Based on the recommendations given earlier, the following conditions apply when a 10.1.2 release of a portal and 10.1.2 release of a middle tier is involved:
Always use the middle-tier Oracle home to export content. Version 9.0.1.5 is the earliest version of the database supported for a 10.1.2 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.
|
Note: If you have configured a 9.0.4 release of a portal (9.0.4 or 9.0.4.1) to use a 10.1.2 release of a middle tier, then the rules described in this section must be followed. |
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? 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 OracleAS 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_HOME.
When do you export and import data? Perform the export and import process after regular business hours, and disable access to OracleAS 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 Databaseexp 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 OracleAS 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 number of dependencies spanning across page groups.
References or dependencies between objects.
Extraction is taking a long time to start, which depends on the assigned database job in the queue.
The extraction process is taking a long time due to a large number of documents being extracted, especially BLOB columns.
Insufficient memory in the TEMP tablespace for sort operations.
Schema validation taking 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 taking a long time to start, which depends on the assigned database job in the queue.
Insufficient memory in the TEMP tablespace for sort operations.
Post-import schema validation taking 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 could increase the values of relevant database cache parameters based on your requirement. This will reduce the time taken to import large transport sets reasonably. |
This section provides a list of some additional considerations you must make before you export and import data in OracleAS Portal.
When exporting or importing large data sets, ensure 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, use the opeasst.csh script. See Section 10.2.3.1.3, "Exporting Large Page Groups" for more information.
For importing large page groups, use the import script with the -automatic_merge option. See Section 10.2.3.2.1, "Running Your Script on the Target System" for more information.
If you have installed any Business Intelligence and Forms components and use related portlets in OracleAS 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. |
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 10-1 provides a description of export user privileges.
Table 10-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 10-2 provides a description of each object type and the required privilege level.
|
Note: The ORCLADMIN and OracleAS 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 10-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. |
OracleAS 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 OracleAS Portal Export and Import processes.
This case shows the steps to copy or update portal page groups and portlets between a development instance and a production instance of OracleAS 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:
Develop page groups, applications, and content on the source system.
Identify pages, applications, and content to export, then create transport sets accordingly and export to the target system.
Import the transport sets on the target system, into your portal repository.
Scenario 2: Updating content on your target instance. OracleAS 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 10.4, "Recommended Best Practices When Exporting and Importing" for more information about the recommended practices for exporting and importing content.
|
Note: Editing of imported content is not supported from 10g Release 2 (10.1.2) onwards.For example, if you have a page (named Similarly, if you have a page ( |
Oracle Database exp and imp utilities can be used to deploy identical content across multiple OracleAS Portal instances. In this case, the OracleAS Portal objects (portlets, page groups, and so on) can be created in one instance, and propagated to multiple instances using the Oracle Database exp and imp utilities. For more information, refer to the information on staging a test environment from a production environment, in the Oracle Application Server Administrator's Guide.
When you use OracleAS 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 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.
This section describes the recommended method to export and import content in OracleAS Portal. It contains the following topics:
This section describes the export process and the steps required to successfully transfer content from the source portal system, including:
Once the system requirements are verified, your goal is to create a transport set. Figure 10-1 shows the process.
|
Note: Limit any possible conflict issues by making one person responsible for maintaining a transport set. |
From the Navigator or Bulk Actions (enables you to add multiple pages at once to the export transport set), select the objects to be exported. The Transport Set Manager is automatically displayed.
Select a name and select the export options for the transport set. In the Transport Set Manager, click Export Now to initiate the export.
The procedure extracts the data and populates the transport tables.
Generate a migration script and log information from the Transport Set Manager.
Run the script to generate a dump file.
The Export/Import Dependency 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 10-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:
|
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 10-3 describes the object classification and the default modes.
Table 10-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 10-2 is an example of a transport set manifest.
Clicking the name of an object, for example an explicitly selected object, displays a detailed screen of child, referenced, and external objects. Figure 10-3 is an example of a 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. |
Review Section 10.3, "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 create a transport set for export:
Select the objects for export. You can do this from the Navigator, or search results > Bulk Actions for page groups. See Figure 10-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 10-4 is an example of the Portal Navigator.
Click the Export 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 18-JAN-2003.
Figure 10-5 is an example of the Transport Set Manager.
Select Export Access Control Lists 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.
Select the import modes, delete any explicitly selected objects, and add (make explicit) any external objects. Making an external object explicit enables you to add a new object to a transport set instead of going back to the Portal Navigator and adding it. External objects are not exported or imported by default until they are added as explicitly selected objects. See Figure 10-6.
Select either Export Now if you are finished, or Save for Later if you want to add more objects. See Section 10.2.3.3, "How Do I Manage My Transport Sets?" for more information about how to edit and browse the transport sets on the system.
|
Note: When you select some of the transport set options and select Save for Later, the next time you add an object to the transport set, all of the previously selected options are reset. Therefore, you need to select the options each time you add an object until you finalize the transport set. |
Figure 10-6 shows the transport set objects.
Figure 10-6 Transport Set Manager Objects
To finalize the transport set, click Export Now. The objects marked for export are copied to the transport tables for migration. These operations happen in the background.
Check the log in your transport set manager for any errors by clicking the View Log Of Actions link.
Figure 10-7 is an example of the View Log page.
|
Note: To view a detailed log of the export process, including debug messages, perform the following steps:
|
Select an appropriate export script based on your operating system.
Figure 10-8 is an example of the Download Scripts And View Log page.
For Netscape users:
Click the selected script, then click Save Target As.
Change the name and remember to include the correct file extension, .csh for UNIX or .cmd for NT. For example, MyScript.csh.
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: UNIX users should save the file to a local directory and transfer the script to the middle-tier computer where the Oracle Databaseimp utility resides to create the dump file. Ensure that you do not edit the script.
|
For Internet Explorer users:
Right-click the selected script, then click Save Target As.
Change the name and remember to include the correct file extension, .csh for UNIX or .cmd for NT. For example, MyScript.csh.
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. |
Running Your Script to Create an Export Dump File
The next steps 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.
To create a dump file:
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> <-s portal_schema> <-p portal_password> <-pu portal_username> <-pp portal_userpassword> <-company company_name> <-c connect_string> <-d dump_file_names> <-automatic_merge>
|
Notes:
|
Table 10-4 provides a description of the parameters you can use in this process.
Table 10-4 Parameter Descriptions
| Parameters | Description |
|---|---|
|
|
Mode for invoking the Export Import Command Line Utility EXPORT mode: Exports content to dump files using the Oracle Database IMPORT mode: Imports content from dump files using the Oracle Database |
|
|
Oracle Database account for the portal |
|
|
Oracle Database password for the portal |
|
|
Lightweight user name for logging in to the portal |
|
|
Lightweight user password for logging in to the portal |
|
|
Company name (for example, ORACLE) |
|
|
TNS connection information to the remote database |
|
|
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: 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. |
|
|
Automatically imports contents of the dump file |
Transfer your export data. To do this:
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.
Finally, using FTP, transfer your dump file and the Export and Import script to the computer where your target OracleAS Portal schema resides.
You can use the opeasst.csh (Oracle Portal Export Assistant) script to export large page groups, which can time out in the browser while calculating the page group dependencies. These timeout issues are due to the Dependency Manager and the preliminary check routines that are run as foreground processes. The actual data extraction and the data merge are performed in the background.
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> <[-export_acls]>
Table 10-5 provides a description of the parameters used in this process.
Table 10-5 OPEASST.CSH Parameter Descriptions
| Parameters | Description |
|---|---|
|
|
Oracle Database account for the portal. |
|
|
Oracle Database password for the portal. |
|
|
TNS connection information for the source database. |
|
|
Name of the transport set to be created. |
|
|
Comma-delimited list of Page groups for export. Note: Exporting seeded page groups using the script is not allowed. |
|
|
Export object-level privileges. |
Perform the export from the command line, and then perform the following tasks:
Check the log in your transport set manager for any errors by clicking the Status link. See Section 10.2.3.3, "How Do I Manage My Transport Sets?" for more information about how to edit and browse the transport sets on the system.
When the export is complete browse your transport sets and select the appropriate script for your operating system. See Section 10.2.3.1.2, "Exporting Data" for details.
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.
Using FTP, transfer your dump file and the export and import script to the computer where your target OracleAS Portal schema resides.
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 10.2.3.2.2, "Importing Data" for details.
The following features and limitations currently exist:
The script supports only exporting page groups.
Multiple page groups can be exported at once using comma-delimited values.
Dependency Manager logs are available after export. These logs help identify data inconsistencies in the source, for example missing dependencies.
There is no import mode option available, that is, Replace on Import or Reuse.
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:
|
This section describes the import process and the steps required to successfully transfer content to the target portal system, including:
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. This is done by calling the same script (used in the export) with the -mode parameter set to import. The parameters in bold are applicable only for import and are mandatory.
%MyScript.csh Usage: MyScript.csh <-mode export_or_import> <-s portal_schema> <-p portal_password> <-pu portal_username> <-pp portal_userpassword> <-company company_name> <-c connect_string> <-d dump_file_names> <-automatic_merge>
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:
|
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 10-9 shows how the import process works.
You import the contents of the transport set dump file to the transport set tables utilizing the same script used in the export.
A background job is submitted to initiate the import, and log information is generated.
Once the import is complete, you can access the transport set from the user interface.
|
Notes: To preserve data integrity, avoid:
|
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 process determines if the objects already exist on the target.
To import your content:
Locate the Export/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. |
Select the imported transport set and click Import. The Objects page of the Import Manager is displayed.
Figure 10-10 shows the Objects page that displays the list of objects included for import.
Figure 10-10 Transport Set Manager Import Objects
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. |
To view the log output, click the Status icon. Table 10-6 provides a description of each status type.
Table 10-6 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 10-11 shows a sample View Log page.
Figure 10-11 Transport Set Manager Import Log
|
Note: To view a detailed log of the import process, including debug messages, perform the following steps:
|
Click Close to return to the Objects page.
Click the Main tab.
Select the Import Access Control Lists option under Transport Set Options 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:
User and 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.
Select either Import Now if you are finished, or Save for Later.
When you select Import Now, the exported objects are imported in the background. Clicking Save for Later saves changes to the transport set for later resolution and import.
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 10-7 describes the warning or failure behavior for each object.
Table 10-7 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:
|
|
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. |
|
Database provider component |
Warning |
The portlet entry where the component is placed is deleted from the page. |
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 10-8.
Table 10-8 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 |
|
|
|
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
Portal DB Provider component
Web portlet
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. |
The Export/Import Transport Set portlet is installed by default on the Administer tab and enables you to export, import, edit, and browse the transport sets on the system. This section discusses the following:
Figure 10-13 shows the Export/Import Transport Set portlet.
Figure 10-13 Export/Import Transport Set Portlet
You can view and edit the list of objects selected for a transport set. Once you create a new transport set and select the Save for Later option:
Navigate to the Export/Import Transport Set portlet.
Select the transport set from the export list of values.
Edit the preferences.
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. Additionally, you can delete transport sets from the system, and you can reuse a transport set by selecting the transport set and clicking Reuse.
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.
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:
|
Figure 10-14 shows a sample Browse Transport Sets screen.
You can export and import content when both the source and target OracleAS 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 Application Server Administrator's Guide.
The following considerations should be made before migrating portal content from a source instance to a target instance using OracleAS Portal Export and Import. This section discusses the behavior of OracleAS 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:
This section discusses the behavior of the following portal objects after migration:
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.
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.
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 information in the target will be deleted and re-created.
Reuse mode. No action is performed.
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.
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 10.3.1.6, "Regions" for region import behavior. See Section 10.3.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 10-9, "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.
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 OracleAS Portal implements synchronization of target regions with the source. See Table 10-9, "Import Behavior of Regions in Overwrite Mode" for more information.
Synchronization of Regions
This release of OracleAS Portal implements synchronization of target regions with the source. The import behavior when a page is imported in Overwrite mode is described in Table 10-9.
Table 10-9 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 |
|
|
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) |
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. |
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.
Caution:
Region and Item movements done on a template-based page are lost if the template is imported in Overwrite mode. This is also true for:
Items and portlets that are hidden or deleted on the template-based page.
Tabs that are moved or deleted on template pages.
This is because templates always take precedence over pages based on them. Only changes that are specific to the page are retained.
As a workaround, you can perform the following high-level steps:
Migrate the updated template in Overwrite mode.
Migrate the pages that contain modified template items and portlets, in Overwrite mode. In this case, import the template in Reuse mode for the changes to be preserved.
This workaround is valid only for pages migrated in a transport set, and ensures that the modifications made to the items and portlets in the template-based pages are preserved. This procedure needs to be performed every time the template is imported in Overwrite mode.
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.
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.
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.
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.
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.
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.
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.
This section describes the functioning of child objects after migration. Table 10-10 describes the behavior in detail.
Table 10-10 Import Behavior of Child Objects
| Name of Object | Objects | Import Behavior |
|---|---|---|
|
Contained objects, which contribute to the structure of the object |
|
|
|
Contained objects that do not contribute to the structure of the object, but act as placeholders within a container. |
|
|
|
Child objects |
|
|
This section describes the behavior of the following DB Provider objects after migration:
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.
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:
The |
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.
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.
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.
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.
This section describes the following 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 MID_TIER_ORACLE_HOME\j2ee\OC4J_Portal\applications\portal\portal\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.
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 MID_TIER_ORACLE_HOME/j2ee/OC4J_Portal/applications/portalTools/omniPortlet/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, MID_TIER_ORACLE_HOME/j2ee/OC4J_Portal/applications/portalTools/omniPortlet/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:
Append the SSL URL certificates to the certificate file used by the OmniPortlet provider (default is MID_TIER_ORACLE_HOME/portal/conf/ca-bundle.crt).
Update the <trustedCertificateLocation> tag in OmniPortlet provider.xml file located in ORACLE_HOME/j2ee/OC4J_Portal/applications/portalTools/omniPortlet/WEB-INF/providers/omniPortlet/.
Restart OC4J.
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:
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).
Update the <trustedCertificateLocation> tag in the OmniPortlet provider.xml file located in ORACLE_HOME/j2ee/OC4J_Portal/applications/portalTools/webClipping/WEB-INF/providers/webClipping/.
Restart OC4J.
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.
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 OracleAS Portal Export and Import.
Migrating Content Between Upgraded OracleAS Portal Instances
Importing Data with Oracle Text Index Synchronization Turned Off
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 OracleAS 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.
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 OracleAS 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:
|
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:
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.
Export this content page group to the target system.
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.
On the source system, register the same provider (using the same name as the Federated Portal Adapter provider).
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.
Export the Display Page group to the target system.
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.
On the source system, make changes to the page structure (tabs, new regions, and so on) to the Display Page page group.
Export the latest Display Page page group to the target system.
Verify that the Content Page Group contains the new changes that you made in Step 7, on the target environment.
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 Application Server Portal Developer's Guide 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.
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:
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 OracleAS Portal" in the Oracle Application Server Portal Developer's Guide.
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. |
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.
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).
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 not automatically exported and imported. Therefore, it is possible that a custom search portlet is 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. |
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 10.1.2. Exporting and importing content between these two upgraded 10.1.2 development and production instances is not supported.
During an upgrade from a pre-9.0.2 release of OracleAS 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 OracleAS 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 OracleAS Portal instances to avoid preliminary check failures. To do this, perform the following steps:
Create an empty portal instance that will become the new source development instance.
Export the contents of the target production portal instance.
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. |
OracleAS 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:
Run the command-line utility in import mode.
Log in to a subscription.
Import the contents of the transport set into the subscription.
Example 10-1 shows a scenario where OracleAS Portal Export and Import can be used to import the contents of a transport set into multiple subscriptions.
Example 10-1 Importing Content into Multiple Subscriptions
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.
Export the content and structure to a transport set, which becomes the seed transport set.
Export the contents of the transport set to a dump file.
Create a new subscription with the same structure and content defined earlier, by performing the following steps:
Create the new subscription.
Import the contents of the dump file into the portal instance.
Log in to the new subscription.
From the Transport Set portlet, select the transport set and import it.
Verify that the new subscription now contains the required structure and content.
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 OracleAS Portal. If you created a transport set for export and import, then any other user who logs in to OracleAS Portal will be able to view the contents of the transport set that you created, in all subscriptions in that portal. |
While importing large data sets into a target OracleAS 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:
Before you start the import process, run the following command in the target OracleAS Portal instance as the portal schema owner (PORTAL):
@textjsub.sql STOP
Refer to Section 8.3.5.4, "Scheduling Index Synchronization" for details on scheduling, starting, and stopping text index synchronization.
Ensure that the wwv_context.sync job does not exist on the dba_jobs table.
Import your data set. See Section 10.2.3.2.2, "Importing Data" for more details.
Run the textjsub.sql script as the portal schema owner (PORTAL):
@textjsub.sql START
Optionally, run the command to synchronize Oracle Text indexes. Refer to Section 8.3.5.1, "Synchronizing Oracle Text Indexes" for the procedure to do this.
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 OracleAS 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 Internet Directory Administrator's Guide 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 Internet Directory Administrator's Guide 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=orcladmin –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 6, "Securing OracleAS 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=orcladmin –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: Thessoexp and ssoimp scripts found in the wwu directory are obsolete for Oracle Application Server 9.0.x and not compatible with the 9.0.x login server. These should not be used.
|
