|
Oracle® Application Server Portal Configuration Guide
10g Release 2 (10.1.2) Part No. B14037-01 |
|
 Previous |
 Next |
|
Oracle® Application Server Portal Configuration Guide
10g Release 2 (10.1.2) Part No. B14037-01 |
|
|
Previous |
Next |
OracleAS Portal provides a set of export/import utilities that enable you to move content between portal installations. This chapter provides a summary of recommendations and best practices developed for export/import functionality as provided in OracleAS Portal 10g Release 2 (10.1.2). This chapter contains the following main sections:
This section outlines some of the tasks you need to perform, and information about how OracleAS Portal Export/Import works with other components of Oracle Application Server, before you start using OracleAS Portal Export/Import. This section contains the following topics:
The export and import process consists of the following steps:
Create transport sets and extract the content to transport tables. Transport sets contain the portal objects that you are planning to export to your target portal environment. This information is displayed in a manifest. The manifest is simply the 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 Portal export/import command-line scripts to generate a transport set dump file.
Transfer the script and dump file to the target system using FTP or other file transfer utilities.
Invoke the 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.
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 on controlling the export/import of portlet customizations in the Oracle Application Server Portal Developer's Guide.
This section contains the following topics:
Before proceeding with the export/import process, make sure you have the following information:
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) - leave blank in most cases.
|
Note: The Portal schema password is a randomized password created on install. You may want to update the password to something more meaningful. |
Before exporting and importing, ensure that your system meets the minimum system requirements, as described in this section.
Using Different Releases and Versions of Export. Whenever you are moving data between different releases of the Oracle Database server, the following rules apply:
The Oracle IMP utility and the database to which data is being imported (the target database) must be the same version, or a higher version.
The version of the Oracle EXP utility must be equal to the lowest version of the source or target database.
|
Notes:
|
The choice of whether to use the database Oracle home or the middle-tier Oracle home depends on the version of the database used for the source and target portal installations. By default, the 10.1.2 middle-tier uses a 10.1.0.2 Oracle home.
Based on the recommendations given earlier, the following conditions apply when a 10.1.2 portal and 10.1.2 middle-tier is involved:
Always use the middle-tier Oracle home for export. 9.0.1.5 is the lowest version of the database supported for a 10.1.2 portal installation.
Always use the target database Oracle home for import. The version of the import utility and the target database must be the same.
|
Note: If you have configured a 9.0.4 portal (9.0.4 or 9.0.4.1) to use a 10.1.2 middle-tier, then the rules described in Using Different Releases and Versions of Export must be followed properly. |
For example, to create an export file for an import into a higher release database, use a version of the Oracle EXP utility that is equal to the source database. To create an export file for an import into a lower release database, use a version of the Oracle EXP utility that is equal to the version of the target database.
|
Note: It is strongly recommended that you use the same database version for the source and target portal installations. |
Oracle export/import and Character Sets. The Oracle EXP utility always exports user data, including Unicode data, in the character sets of the export server. The character sets are specified at database creation.
The Oracle 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 mark.
Both the EXP and IMP utilities provide indications 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, truncation of data can occur if conversion causes expansion of data. If truncation occurs, 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 machines? 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 EXP and IMP utilities, as well as the Portal instance.
Is your database configured to allow the execution of background jobs? 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 execution of background jobs.
An alternative way of checking the job_queue_processes parameter is to examine the init.ora file in your database's ORACLE_HOME.
When to perform export and import? Plan to perform the export and import process during non-business hours and to disable access to OracleAS Portal during the process. One way to disable access to the portal temporarily for all other users, is to configure your listener for a different port number during the duration of the export and revert it back to the original port when your export is complete.
|
Note: If the Oracle EXP/IMP utilities finish with errors or warnings, you should not proceed with the import of that transport set. The errors or warnings that are recorded in the Oracle EXP and IMP log files (typically named<script_file_name>_<long identifier>_exp.log and <script_file_name>_<long identifier>_imp.log) should be addressed first.
|
How much time does export or import take? The exact time taken to export or import content in OracleAS Portal cannot determined. Many dependencies affect the time taken for export and import. The dependencies are listed subsequently.
Dependencies that affect the time taken for Export
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 time taken for Import
Pre-check for large page groups, which also depends on the number of internal and external dependencies that need to be pre-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.
Additional considerations.
When exporting or importing large datasets, ensure that there is sufficient space in the TEMP tablespace. This will ensure that export or import does not fail due to insufficient memory.
For exporting large page groups, use the opeasst.csh (Oracle Portal Export Assistant) script. See Section 10.2.3.1.3, "Exporting Large Page Groups" for more details.
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 Your Target System" for more details.
|
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/import process to fail. If you have any problems with source or target instances, contact Oracle Support. |
This section describes the privileges required to successfully export and import your content.
To allow for secured control over the export of shared objects (objects in the Shared page group), there are now two privileges defined at the infrastructure level.
Any Transport Set - Manage enables you to perform export/import of portal objects, including 'shared' objects. This privilege is granted to the DBA group by default during the portal installation process.
A user with the Any Transport Set - Execute privilege can export/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.
In addition to the Any Transport Set - Manage privilege, you must also have Manage privilege on objects of a given type to successfully import your content.
For example, a page group containing Web providers require 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 Portal users are granted Manage All on all page groups at the time of install or upgrade. Members of the DBA group are also granted Manage All on all page groups by default. |
Table 10-2 Import User Privileges
| Object Type | Privileges |
|---|---|
| All Page Groups | Manage All: This privilege is required, along with the All Providers Manage privilege to import page groups and shared objects. |
| All Providers | Manage: This privilege is required for the import of Page Groups, Portal DB providers, Web providers, and other database providers. |
| All Portal DB Providers | Manage: This privilege is required for the import of Portal DB Provider objects. |
| All Shared Components | Manage: This privilege is required for the import of shared components if the Portal DB Provider objects reference the shared components. |
|
Note: If you import a page which is based on a style belonging 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 introduces some of the most common uses.
This case illustrates the steps involved in copying or updating portal page groups and portlets between a development instance and a production instance of OracleAS Portal.
|
Note: User customizations are not exported, therefore any customizations on a page or portlet on the source are not exported or imported. |
Scenario 1. Exporting your pages and content to a target portal system. The first export to your target system must migrate the entire page group. The subsequent 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 the updating of item, region-level content on your target system ONLY under the following circumstance:
Export/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 should migrate the entire page group from the source portal to the target portal instance.
Refer to Section 10.3.2, "What Are the Recommended Best Practices?", for a detailed overview of the recommended practices.
|
Note: The current release does not support editing of imported content.For example, if you have a page (named Page1) within a page group (named PG1) on the source, which you have migrated to the target, you must not edit Page1 on the target. Similarly, if you have a page (Page1) within page group (PG1) on the source, you must not create a page with the name Page1 within page group (PG1) on the target. |
This case illustrates the process of deploying the same set of OracleAS Portal objects across multiple portal instances. Oracle Database EXP and IMP utilities can be useful when deploying 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. See section "Migrating Your Portal Across Databases" for details.
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 move content from the source portal system, including:
Once the system requirements are verified, your goal is to create a transport set. The subsequent diagram illustrates the process.
|
Note: Limit any possible conflict issues by making one person responsible for maintaining a transport set. |
You select the objects to be exported from the Navigator or Bulk Actions (enables you to add multiple pages at once to the export transport set). The Transport Set Manager is automatically displayed.
You choose a name and select the export options for the Transport Set, click Export Now from the Transport Set Manager to initiate the export.
The procedure extracts the data and populates the transport tables.
You generate a migration script and log information from the Transport Set Manager.
You execute the script to generate a dump file.
The Export/Import Dependency Manager ensures that all the dependencies of objects 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, see Figure 10-2. The classification of objects is listed here:
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, sub-pages, sub categories and sub-perspectives 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 simply 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, it is replaced. If it doesn't exist, then it is created. When this mode is not selected and if the object exists, the object on the target portal is retained as is. However, if the object doesn't exist on the target, then it is created.
Reuse on Import. If the object does not exist on the target, it is created. If it already exists, it remains as is.
The following table 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 |
Clicking the name of an object, for example, an explicitly selected object, displays a detailed read-only screen of child, referenced and external objects, as shown in Figure 10-3.
|
Note: Editable seeded itemtypes are extracted. It is recommended that you do not edit the seeded types. If you want to extract them, 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.1, "How Do Objects Behave After Migration?" before migrating 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/import process. |
To create a transport set for export:
Select the objects for export (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. |
Click the Export link to display the Transport Set Manager, as shown in Figure 10-5. 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.
Check the appropriate boxes under the Transport Set Options:
Export Access Control Lists. Includes Access Control Lists associated with the objects in the transport set.
Validate System Tables. Enables you to choose if you want to validate system tables before export.
For container objects (page group and Portal DB Provider), system tables are always validated before export, and any data inconsistencies are fixed. For a more detailed explanation of how the validation is performed, log on to Oracle Metalink, at http://metalink.oracle.com and read the article SCHEMA VALIDATION UTILITY. This article has DocId 286619.1.
Choose the import modes, delete any explicitly selected objects and promote (make explicit) any external objects. Making an external object explicit enables you to add a new object to a transport set 'in-place' instead of going back to the portal Navigator and adding it. External objects are not exported or imported by default until they are promoted 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 details on how to edit and browse the transport sets currently on the system.
|
Note: When you select some of the transport set options and choose Save for Later, the next time you add an object to the transport set all of the previously selected options are reset. Therefore, you should select the options each time until you finalize the transport set. |
Click Export Now to finalize the transport set. 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.
|
Note: To view a detailed log of the export process, including debug messages:
|
Choose an appropriate export script based on your operating system. See Figure 10-8.
For Netscape users:
Click the selected script, then click Save Target As.
Change the name and remember to include the correct filename extension, .csh for UNIX or .cmd for NT, for example, MyScript.csh.
Save the file to the directory on your file system where you will want to run the export script (generally this directory should be where your export portal resides).
|
Note: UNIX users should save the file to a local directory and move the script to the middle-tier machine where the IMP utilities reside 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 filename extension, .csh for UNIX or .cmd for NT, for example, MyScript.csh.
Save the file to the directory on your file system where you will want to run the export script (generally this directory should be 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 just created in the last 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 subsequent example. The example assumes that the name of the script is MyScript.csh. The parameters in bold are only applicable for export 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_name(s)> <-automatic_merge>
|
Notes:
|
The following table provides a description of the parameters you can use in this process.
Table 10-4 Parameter Descriptions
| Parameters | Description |
|---|---|
| -mode | Mode for invoking the Export Import Command Line Utility
EXPORT mode: Exports content to dump files using Oracle EXP utility IMPORT mode: Imports content from dump files using Oracle IMP utility |
| -s portal_schema | Oracle Database account for portal |
| -p portal_password | Oracle Database password for portal |
| -pu portal_username | Lightweight username for logging in to portal |
| -pp portal_userpassword | Lightweight user password for logging in to portal |
| -company company_name | Company name (for example, ORACLE) |
| -c connect_string | TNS Connection Information to remote database |
| -d dump_file_name(s) | Name(s) of files for Oracle export or import utilities to write to or read from. If multiple filenames are specified, they must be separated by commas.
For example: FILE1.DMP,FILE2.DMP Note: If multiple file names are not specified, export or import utilities will automatically prompt for another file name during the export/import process, if required. |
| -automatic_merge | Automatically import contents of 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 schema name (source), password, dump file name(s), and so on. It also creates a dump file upon completion.
Finally, using FTP, transfer your dump file and export/import script to the machine where your target OracleAS Portal schema resides.
You can use the opeasst.csh (Oracle Portal Export Assistant) script to export large page groups, which time out in the browser while calculating the page group dependencies. These timeout issues are due to the Dependency Manager and the pre-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. An example of the script follows:
%opeasst.csh Usage: opeasst.csh <-s portal_schema> <-p portal_password> <-c connect_string> <-ts transportset_name> <-pgrps pgrp_names> <[-export_acls]>
The following table provides a description of the parameters used in this process.
Table 10-5 OPEASST.CSH Parameter Descriptions
| Parameters | Description |
|---|---|
-s portal_schema
|
Oracle Database account for portal. |
-p portal_password
|
Oracle Database password for portal. |
-c connect_string
|
TNS Connection Information for the source database. |
-ts transportset_name
|
Name of the transport set to be created. |
-pgrps pgrp_names
|
Comma-delimited list of Page groups for export.
Note: Export of seeded page groups using the script is not allowed. |
-export_acls
|
Export object level privileges. |
Perform the export from the command line, then:
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 details on how to edit and browse the transport sets currently 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 Your Data" for details.
Run the script using -mode export as the option.
%MyScript.csh -mode export
This prompts you for information such as schema name (source), password, dump file name(s), and so on. It also creates a dump file upon completion.
Finally, using FTP, transfer your dump file and export/import script to the machine 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 Your Data".
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.
Export Access Control Lists feature is supported.
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, all the external objects are automatically promoted by the script without any user intervention. Those objects that are promotable are recursively promoted to become part of the transport set until there are no remaining external objects in the transport set.
The script name cannot be changed.
|
Note:
|
This section describes the import process and the steps required to successfully move 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 -mode set to import. The parameters in bold are only applicable 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_name(s)> <-automatic_merge>
To perform the entire import from the command line, which initiates a background process, you must include the portal username 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 UI for merging on the target portal system. Figure 10-9 illustrates 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 pre-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 a status of 'Export Complete' 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; click Import. The Objects page of the Import Manager is displayed, as shown in Figure 10-10. The Objects page shows the list of objects included for import.
Figure 10-10 Transport Set Manager Import Objects
If you select Replace on Import, 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 "promoted" to explicitly selected objects. |
To view the log output, click the Status icon. The following table 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. |
|
Note: To view a detailed log of the import process, including debug messages:
|
Click Close to return to the Objects page.
Select the Main tab.
Check the Import Access Control Lists option under Transport Set Options.
|
Note: The Import Access Control Lists option cannot be selected if you chose not to select it during the export process. |
The Import Access Control Lists option includes the Access Control Lists associated with the objects in the transport set.
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, 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 everything has been imported correctly:
In the Navigator, verify that the content in each portal page group that you have imported has been imported correctly. Specifically, for each portal page, verify that the appropriate portlets all appear in each region of your portal page. When these portlets (navigation pages, pages exposed as portlets, DB 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 import, a two-step pre-check process is performed. Clicking View Log shows both the first stage of the process and the pre-check as complete. This is done prior to the actual import and prior to data populating the portal tables.Clicking Refresh Log will show both the second stage of the process and the pre-check with a different timestamp. |
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 the explicitly selected objects will be imported. A failure type object will not be imported.
If an explicitly selected object has two dependencies, a warning type and a failure type and if both the dependencies fail the pre-check process, then the failure type will dominate and the explicitly selected object will also fail.
A warning type impacts explicitly selected objects more than any other kind of object. Referenced and external objects raise failure/warnings for the explicitly selected object based on their type. Table 10-7 describes the expected warning or failure behavior for each object.
Table 10-7 Warning/Failure Types
| Object | Type | Expected Behavior |
|---|---|---|
| Attribute | Failure | The explicitly selected object will fail when the dependent attribute fails. |
| Itemtype | Failure | The explicitly selected object will fail when the dependent itemtype fails. |
| Pagetype | Failure | The explicitly selected object will fail when the dependent pagetype fails. |
| Style | Warning | The style will default to the main style of the page group that it belongs to. |
| Category | Warning | The category is set to 'none'. |
| Perspective | Warning | The perspective associated with an item/page is removed. |
| Page Template | Failure | The explicitly selected object will fail when the dependent template fails. |
| Page | Warning | There can be 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 import. |
| Color, Font, JavaScript, Application Template, Image | Warning | Set to default at runtime. |
| DB Provider Component | Warning | The portlet entry where the component is placed is deleted from the page. |
When the container objects listed subsequently appear as an external dependency, because their child objects have been selected for export and they do not exist on the target, then the explicitly selected object (child object of the container object) will always fail.
Page group
Portal DB Provider
Category
Perspective
Page
Cascade Warning Behavior
Warnings or failures detected in objects during the pre-check will 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, 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 promoted and their import failed, the portlet instances would still be deleted.
To summarize, if the imported portlet does not exist in the portlet repository on the target, it gets deleted from the source page.
|
Note: The portlet clean up operation deletes portlet dependencies like Page Parameters and Events, URL, text, and so on. The page structure remains unchanged after the removal of 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, shown in Figure 10-13, is installed by default on the Administer tab and enables you to export, import, edit and browse the transport sets currently on the system. This section discusses the following:
Figure 10-13 Export/Import Transport Set Portlet
You can view and edit the list of objects selected for a transport set. Once you have created a new transport set and selected 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, referenced objects and download export/import scripts. Additionally, you can delete transport sets from the system or to reuse a transport set, select the transport set and click Reuse.
|
Notes:
|
This section discusses an alternate method to Export/Import content in OracleAS Portal. This method of exporting and importing content will work only if both source and target OracleAS Portal instances exist in a customer database installation, and not in a product metadata repository.
For the recommended method, see Section 10.2.3, "OracleAS Portal Export/Import - Method 1".
Migrating Your Portal Across Databases
Oracle Database EXP and IMP utilities can be useful when deploying identical content across multiple OracleAS Portal instances.
|
Note: In the following steps, theORACLE_HOME is meant to reference the database Oracle home and not the Oracle Application Server Oracle home. It is important that when running database scripts that the correct version is used from the proper Oracle home corresponding to the actual database instance in which portal is being imported.
|
The migration is a multi-step process that involves:
Migrating users and groups from Oracle Internet Directory. Before you start the migration process, you have to migrate the users and groups from Oracle Internet Directory. This step is required if the target portal will not share the same Oracle Internet Directory server.
|
See Also:
|
Listing the schemas to be exported. It is necessary to identify all of the schemas that need to be exported, including the portal schema, the portal "Public" schema, and any schemas used for Database Providers or Portlet Builder components. To list all the schemas run the following query from SQL*Plus as the Portal schema owner:
SELECT USERNAME, DEFAULT_TABLESPACE, TEMPORARY_TABLESPACE FROM DBA_USERS WHERE USERNAME IN (user, user||'_PUBLIC', user||'_DEMO', user||'_APP') OR USERNAME IN (SELECT DISTINCT OWNER FROM WWAPP_APPLICATION$ WHERE NAME != 'WWV_SYSTEM');
|
Note: This will only list schemas that are directly related to Database Providers or Portlet Builder components registered in portal. If any of these schemas additionally reference objects in other schemas, then they should be added to the list of schemas to be exported. |
Listing the tablespaces in the source database. To list the tablespaces used in the source database run the following query from SQL*Plus as the SYS user:
SELECT DISTINCT TABLESPACE_NAME FROM DBA_SEGMENTS WHERE OWNER IN (<list of schemas>) UNION SELECT DISTINCT DEFAULT_TABLESPACE FROM DBA_USERS WHERE USERNAME IN (<list of schemas>) UNION SELECT DISTINCT TEMPORARY_TABLESPACE FROM DBA_USERS WHERE USERNAME IN (<list of schemas>)
Running the Oracle EXP utility.
EXP \'sys/<password of sys user>@<Connect String> as sysdba\' FILE=portal.dmp OWNER=<List of Schemas> LOG=portal.log
The export should terminate without any errors. If there are any ORA- 00942 errors reported in this step, run the following script from SQL*Plus as the SYS user:
ORACLE_HOME/rdbms/admin/catexp.sql
|
Note: The difference in syntax between Unix and NT platforms, you should omit the '\'. For example,'sys/<password of sys user>@<Connect String> as sysdba.
|
Creating a backup of the target database. Backup the target database before proceeding to the next step.
Preparing the target database for import. Before importing the portal schemas into the target database, it is necessary to ensure that the necessary pre-requisite packages have been installed.
|
Note: The target database must meet the same minimum requirements necessary as a database for an Oracle Application Server Metadata Repository. |
PTLASST must be run in SYSOBJECTS mode.
Run ORACLE_HOME/rdbms/admin/catldap.sql.
Recompile all invalid objects by running ORACLE_HOME/rdbms/admin/utlrp.sql
Initialize the portal login trigger for import. Run as SYS
ORACLE_HOME/portal/admin/plsql/wwhost/insttrig.sql SYS
Creating or altering tablespaces in the target database. Check that the required tablespaces exist in the target database. The tablespaces in the target database must be the same as the source tablespaces.
Check that the list of tablespaces identified in Step 2 exists in the target database. To list all the tablespaces on the target, run the following script from SQL*Plus as the SYS user:
SELECT TABLESPACE_NAME FROM DBA_TABLESPACES;
To create a new tablespace, use the CREATE TABLESPACE or CREATE TEMPORARY TABLESPACE commands. For example:
CREATE TABLESPACE <tablespace_name> DATAFILE '<datafile_location>' SIZE 20M DEFAULT STORAGE (INITIAL 1M NEXT 2M MINEXTENTS 2) AUTOEXTEND ON;
<datafile_location> is the file location for the dbf file. On UNIX, for example, the location may be: /u02/oracle/data/tbsa01.dbf.
For any tablespaces that already exist in the target database, it is recommended that they be set to autoextend or they must be sized large enough to hold the imported portal schemas. The following script can be used to enable autoextend on all datafiles:
SET DEFI OFF SPOOL DATAFILES.SQL SELECT 'ALTER DATABASE DATAFILE '''||FILE_NAME||''' AUTOEXTEND ON;' FROM DBA_DATA_FILES ; SPOOL OFF @DATAFILES.SQL
Creating the portal schema. Change directories to ORACLE_HOME/portal/admin/plsql/wwv and run the following script from SQL*Plus as the SYS user.
@wdbisys.sql <Portal Schema> <Portal Default Tablespace> <Portal Temporary Tablespace> WDBISYS.LOG
This creates the portal schema and grants all of the necessary privileges. Use the results of the query from Step 1 to find the names of the default and temporary tablespaces for the portal schema.
Creating the portal_public schema. Change directories to ORACLE_HOME/portal/admin/plsql/wws run the following script as the SYS user.
@cruser.sql <Portal Schema> <Portal Default Tablespace> <Portal Temporary Tablespace>
This creates the PORTAL_PUBLIC schema.
Creating placeholders for the schemas. Check that the list of schemas that will be imported from Step 1. If the schemas already exist in the target database, then it is recommended that they be dropped. Before dropping any schemas, ensure that those schemas are not in use by other applications. To create a new users, use the following syntax:
GRANT CONNECT, RESOURCE TO <user> IDENTIFIED BY <password>;
A user must be created for each user in the list from Step 1. Use the ALTER USER command to adjust any user properties as necessary. For instance, the default and temporary tablespaces should be set to the ones specified by the results from the query in Step 1.
Running the Oracle IMP utility.
IMP \'sys/<password of sys user>@<Connect String> as sysdba\' FROMUSER=<LIST OF SCHEMAS> TOUSER=<LIST OF SCHEMAS> FILE=PORTAL.DMP LOG=PORTAL_IMP.LOG
The following Import error can be ignored as it is expected:
IMP-00041: Warning: object created with compilation warnings.
Compiling all the invalid objects. Compile all the invalid objects in all the imported schemas. Run the ORACLE_HOME/rdbms/admin/utlrp.sql as the SYS user.
Dropping the temporary login trigger. Change directories to ORACLE_HOME/portal/plsql/admin/wwhost and run the following script from SQL*Plus as the SYS user.
@droptrig.sql.
Granting connect through portal. Perform the following commands from SQL*Plus as the portal user:
SET HEAD OFF SET LINES 4000 SPOOL DBUSERS.SQL SELECT DISTINCT 'ALTER USER '||DB_USER ||' GRANT CONNECT THROUGH '|| WWCTX_API.GET_PRODUCT_SCHEMA||';' FROM WWSEC_PERSON$; SPOOL OFF
Run DBUSERS.SQL in the target portal instance to grant connect through privilege to database users associated with portal users.
Middle-tier association. The middle-tier reassociation needs to be made to connect the imported Portal schema to the target metadata repository and Identity Management.
This section contains the following topics:
The following considerations should be made before migrating portal content from a source to a target instance using OracleAS Portal export/import. This section discusses the behavior of portal objects after migration.
Import of Translations
Import of translations in Overwrite mode will not be a strict overwrite, and will behave like 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 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.
Table 10-9 Behavior of Objects
| Object Type | Behavior |
|---|---|
| Page Groups | On the first export/import, if a page group doesn't exist, it is created on your target system. Any settings at 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/updated depending on whether they existed or not. 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:
|
| Attributes | On the first export/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:
|
| Approvals | To view the approvers, Access Control Lists must be exported and imported along with the page group or page that has an approval defined on them.
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. |
| Items | Item information comes as a part of page export. They follow the import mode of the page.
Replace on Import mode. When a page is imported in Replace on Import mode, items in page regions from the source are copied to the target. Any items found only on the target are removed, items that exist on both the source and target are updated, and items that exist only on the source are created. Reuse Mode. No items are imported from the source. The page from the source is only used as a reference, and will determine the import mode of items. Notes:
|
| Pages | Exports the page and the page type, template, and style it references along with content (item and portlets).
Replace on Import mode. The properties of the page are replaced. For region import behavior see, 'Regions'. For item behavior see, 'Items'. Reuse mode. The original page on the target is reused. Child objects do not get created on the target (if they do not already exist). Notes:
|
| Regions | Region information comes as part of page export. They follow the import mode of the page.
Replace on Import mode. When a page is imported in Replace on Import mode, page regions from the source are copied to the target. Any regions found only on the target are removed, including all content in those regions. Reuse Mode. No regions or items are imported from the source. The page from the source is only used as a reference, it will determine the import mode of regions. Note: This release of OracleAS Portal implements synchronization of target regions with the source. See Table 10-14, "Import Behavior of Regions in Overwrite Mode" for more details. |
| Templates | Exports the template and 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:
Caution: Region and Item movements done on a template-based page are lost if the template is imported in Overwrite mode. This is because templates always take precedence over pages based on them. Only changes that are specific to the page are retained. |
| Categories | Exports the category and its sub-categories.
Reuse mode. The original category on the target is reused. Child objects do not get created on the target (if they do not already exist). Notes:
|
| Perspectives | Exports the perspective and its sub-perspectives.
Reuse mode. The original perspective on the target is reused. Child objects do not get created on the target (if they do not already exist). Notes:
|
| Navigation pages | Exports the navigation page and 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. |
| Styles | Exports the style.
Replace on Import mode. The properties of the style are replaced. Reuse mode. The style on the target is reused. Notes:
|
| Item Types | Exports the item type and the attributes it references.
Editable seeded itemtypes present in all portal instances are extracted. Notes:
|
| Page Types | Exports the page type and the attributes it references.
Notes:
|
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, which do not contribute to the structure of the object, but merely act as placeholders within a container. |
|
Contained objects will be created only when:
or
When container objects are reused for the target, only new contained objects will be created from the transport set. (All the existing objects will be left untouched on the target.) |
| Child objects |
|
Child objects will be created only when:
or
|
Table 10-11 Behavior of DB Provider Objects
| Object Type | Behavior |
|---|---|
| Seeded DB Provider |
Notes:
|
| Portal DB Provider | On the first export/import, if a Portal DB Provider doesn't exist, it is created on the target system.
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 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. |
Portal DB Provider Components
|
On the first export/import, the components are created on the target system.
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 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, it will be created. Notes:
|
Shared Components
|
On the first export/import, if a shared component does not exist, 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 always 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/templates are always reused on the target, and are never exported and imported. |
| Registered Database Providers | The schema associated with a registered database provider is marked as an external object in the manifest. Note that on import:
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. |
Table 10-12 Behavior of Portal DB Provider Reports Object Types
| Object Type | Behavior |
|---|---|
| Report Security Access Components | The Report Security Access Objects are always exported or imported as part of the Portal DB Provider export/import.
Notes:
|
Table 10-13 Behavior of Web Providers
Synchronization of Regions
This release of OracleAS Portal implements synchronization of target regions with the source. When a page is imported in Overwrite mode, the import behavior is as follows:
Table 10-14 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/portlets, including user customizations, 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 sub-page. |
Region_X – Type A | Region_X – Type B | When there is a region type mismatch, all the items/portlets under that region (including user customizations) 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 (customized for User A) Item_C (base user) Item_D (base user) Item_E (customized 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 customization on the target. Also, only base user item records are part of the structure of a page, and are shown when a page is edited. |
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/import:
Earlier, the replicated tabs on the target had a different name from that on the source, when 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 avoid duplication of tabs. As 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/import utilities described in this document. In addition to page groups as a whole, individual components within page groups such as sub-pages, 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.
|
Note: The current release does not support the use of circular references. If you import a page group which contains a circular reference then this will produce anORA-00001: unique constraint error, however the import should still finish successfully.
|
Some considerations and best practices to keep in mind are the following:
The first export to your target system should migrate 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 pre-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 chose to promote the page group if you do not know if the page group exists on the target and therefore avoid any potential pre-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 being re-imported 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 sub-pages.
After an initial import operation to your target system, if you change the name of the page group on the target system, subsequent import attempts to that page group will fail.
Categories, itemtypes, perspectives and pagetypes 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 direct access 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.
Here is an example of a URL generated for a page. If the page is imported on another site, this PAGEID 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, we recommend instead the use of Direct Access URLs or Page Link item types.
The same page has this direct access URL:
http://my.portal.com/pls/portal/url/PAGE/HRPAGEGROUP/HRHOME/HRBENEFITS
To find the direct access 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 runtime.
Page Portlets: When you replace a page, the content as well as the structure is replaced on the target.
|
Notes:
|
To preserve content in a page (items, portlets) on the target, but import a style, layout or rendering changes from the source then expose your content through the Federated Portal Adapter portlet. The key here 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 Pages". In this page group, construct 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, 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 Customizations 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: Customizations for Web portlets are not currently preserved. Migration of Edit Defaults is supported out-of-the-box for OmniPortlet and Web Clipping providers. If other providers implement this feature, their Edit Defaults will also be migrated. See Oracle Application Server Portal Developer's Guide for details on 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 will ensure that all customizations 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 Customizations 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 Customizations will be preserved, subject to the user customizations being valid.
|
Note: You can customize, add, hide/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, then 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 (customizations) 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 target (customizations).
Reuse Mode. The customizations 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/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 has been 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, refer to the section Creating a Schema in Portal AS in the document titled Using the Portlet Builder on Oracle Technology Network, http://www.oracle.com/technology/.
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, make sure 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 import. |
There a number of options for adding search components to your pages. You can add a simple 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 re customized and the customizations saved the missing reference is removed.
On export, all the custom search portlets that have been selected for export are checked and any missing references are removed. The customizations are then included in the transport set.
On import, a pre-check will determine 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 ID's 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/import is not supported between two portals that are upgraded from versions earlier than 9.0.2. For example, assume that you have a source development Portal instance and a target production Portal instance, both of version 3.0.9. You then upgrade both the instances independently to version 9.0.4, and then to version 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 version 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, the pre-check for these objects will fail. If, for example, you have a source development instance and a target production instance, you must re-synchronize the OracleAS Portal instances to avoid pre-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 Corporate Pages, 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, you must re-create these after the new development Portal instance is created. |
OracleAS Portal Export/Import supports the creation of taxonomic 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 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/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 taxonomic 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 have created a transport set for import/export, any another user who logs in to Portal will be able to view the contents of the transport set that you have created, in all subscriptions in that Portal. |
