Exporting and importing in Portal

Related topics

 

Oracle9iAS Portal includes export-import tools to migrate page group and database provider objects from one instance to another. Using export-import functionality, users can develop content on a development server, push the content through QA for validation and finally stage the content on production servers.

NoteBy default members of the DBA Group are able to perform export and import tasks in Portal.

The transport set portlet must reside on a page that the user has access to, unless the user already has access to the Administer tab. Without this, the user will be unable to view the transport set portlet and cannot perform export with security or import.

In addition, 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.

The following information is also needed during this process:

For additional security information on DBA groups refer to the Oracle9iAS Portal Security Guide.

Note: Portal supports export and import between Portal instances of the same release only; you can not export and import between two different releases of Portal.

Before you begin

Before exporting or importing, ensure that your system meets the minimum system requirements. Also, plan to perform the export and import process during non-business hours, and to disable access to Portal during the process.

The export and import process sets up a background process. Therefore, verify that the JOB_QUEUE_PROCESS parameter is set to a value greater than 0. To do this, log on to SQL*Plus and select * from v$parameter this will give the value for the 'job_queue_process' parameter.

Pre-Requisites Web and Database Providers

Portal export import only migrates the registration information found in portal – no actual migration of the web or database providers happen. For this reason, it is important that the providers are available on the import portal instance in the same manner in which they are available in the export portal.

In the case of web providers, since this provider is identified by a url this could remain the same. For database providers, an additional step is necessary for successful migration of pages that reference the database provider’s portlets:

  1. Database schema(s) used by Portal DB Providers that are marked for export

  2. Database schema(s) used by Database Providers whose portlets are in the pages marked for export

  3. If there are a handful of web providers that are referenced by the pages in the export portal, you can also register them ahead of time in the import portal with the same name as the export portal.

Exporting and Importing

The export and import process is a multi-step process that involves:

  1. Creation of transport sets and extracting content to transport tables (both done via the User Interface)

  2. Migration of the transport tables from one system (source) to another (target) using Oracle EXP/ IMP utilities (done via command line)

  3. Followed by resolution and merge of objects on target (done via UI).

Export Process

The steps can be summarized as follows:

  1. Mark objects for export (from the Navigator or search results -> bulk actions for page groups).

  2. Select Export this Transport Set Immediately (during the creation phase if security export is not required or during edit phase if security export is required), or select the Export later, more objects have to be added option which allows you to add more objects to the Transport Set and export later.

  3. Check the log for errors and download the script file.

  4. Run the script using -mode export as the option (additional options such as the schema name can also be used).

  5. Note the name of the dump file created.

A transport set can be created by clicking the Export link found under Actions in Navigator (Page Group tab, DB Provider tab). This action can also be accessed from the Bulk Action screen. This action is only visible to those users whose the privilege is mentioned above in the pre-requisites section. Clicking the export link next to a particular object marks that object for export.

The export links are not available for all objects (for example, seeded page groups such as portlet repository, documentation, etc cannot be exported, the same is true for certain providers such as web providers, internal provider, provider group, etc.)

For page group objects, perform a search to select objects for export. Then use the bulk action of export on the results returned. This targets a set of objects for export. Then you can add them to the transport set using bulk actions by clicking the Export link in the bulk actions UI.

Two options are provided at this time, either to create a new transport set for the selected object or to use an existing transport set. The latter is useful when a handful of objects need to be migrated (e.g. a database provider or a page group which contains pages with portlets from the database provider).

The next screen allows the user to input information and perform the export then or save the transport set for later export. Clicking Finish allows the user to save the transport set definition. In addition to information about the transport set, the definition also holds information about objects marked for export. This approach is useful if you need to export security for the selected objects also.

Note: This is the only way to export security associated with the objects marked for export.

When the user selects Export this Transport Set Immediately, the transport set is finalized and the list of objects marked for export are copied to the transport tables for migration. These operations happen in the background.

Further additions of objects can be made by selecting the transport set for reuse. The option is only valid for transport sets with a status of 'Extract Complete' or 'Extract Failed'. Links are presented in the UI that allow the user to view the progress of the actions being performed or download Windows NT or UNIX command scripts that will be used in the migration.

To edit a transport set (to export security for example), go to the Administer tab. Click the icon next to Edit transport set, select a transport set and click Edit. In the manager, choose either Export later, more objects have to be added or Export this Transport Set Immediately then click OK. These two actions can extract the content immediately or save the changes for later export. Once a transport set has been finalized (i.e., Export Now is clicked), the next step is to migrate the contents of the transport set from source to target portal instance.

The migration step uses the Oracle EXP utility to create transport dump files. From the View Log and Download screen, choose the download script based on the operating system. Save the resulting file to the location from where you want to run the export utility.

Notes: This location must have access to the database. On some systems, the downloaded UNIX script requires setting the execute permissions correctly before running it.

Once the scripts are saved (use a .csh or .cmd extension to identify the scripts), perform the migration step by running the script. Running the script without any parameters gives its usage. The example below assumes that the name of the script is opeiasst.csh.

%opeiasst.csh

Usage: opeiasst.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> <-check_mode>

Parameters

Description

 -mode 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 into portal

-pp portal_userpassword

Lightweight user password for logging into portal

-company company_name

Company name (eg: ORACLE)

 -c connect_string

TNS Connection Information to remote database

 -d dump_file_name(s)

Names(s) of files for Oracle exp or imp utilities to write to or read from. If filename(s) are used, they must be separated by commas and enclosed in double-quotes

  E.g.: "FILE1.DMP,FILE2.DMP"

-automatic_merge

Automatically merge contents of dump file on import

-overwrite_mode

Overwrite existing objects with imported objects

-ignore_warnings

Ignore warnings raised during import

-check_mode

Perform a run of import and display potential errors. Do not save the import.

To run the export, specify -mode export as the option to the script:

%opeiasst.csh -mode export

This prompts the user for information such as schema name (source), password, dump file name(s), etc. It also creates a dump file upon completion. The following parameters are for import mode use only:

Note: The first time an export is performed, the entire page group or db provider needs to be exported and imported. This ensures all the necessary dependents are later available for individual export of page group or db provider objects. Also, while it is possible to import an individual db provider object onto a new db provider (one that is different from the source), the same is not true for page groups. Individual page group objects can only be imported into the same page group as the source.

Import Process

The steps can be summarized as follows:

  1. Run the script using -mode import as the option (additional options such as schema name can also be used).

  2. Select the transport set from the Administer Tab.

  3. Import in transport set manager for the selected transported set.

  4. Check log for errors.

  5. Go to the imported objects (via Navigator for example). Verify the object does not have any errors and behaves the same as the source.

To import an object, the contents of the transport set must be first imported to the target system. This is done by calling the same script (used in export) with -mode set to import. i.e.:

%opeiasst.csh -mode import

This prompts the user for information such as schema name (target), password, etc. After validating the user information, the contents of the dump files are imported and the transport set made available for merging on the target portal system.

Once the import is complete the transport set can be accessed from the UI. To do this, go to the Administer tab (Builder) and click the icon next to import a transport set, select the imported transport set, and click on Import. The import manager is displayed. Select the options for import (such as overwrite or reuse, check only) and click on Import Now. This resolves and merges the exported objects (in background) or tests (if check only option is selected) to make sure there are no conflicts.

It is recommended to use Check Only at the beginning of the import to verify that the actions performed have the desired effect. The next step is to run the import again in non-check mode and merge the content. If overwrite mode is selected, then existing objects in the target get overwritten by the imported objects from source. If the overwrite mode is not selected (i.e., it is in reuse mode), then existing objects in target are retained and the imported objects from source are ignored. If a individual page group object is selected for export and import is attempted, the page group to which the individual object belongs to must be present in the target as well (i.e., a full page group export-import was performed before.)

Clicking OK saves changes to the transport set for later resolution and merge (i.e., none of the actions described above are executed.)

Note: The search portlet (which includes categories, perspectives, basic and advanced searches among others) gets reset during import. Recent objects and favorites portlets that are placed in the exported page display only the recent object and favorites of the target. If the security was not marked for export, then the user that performed the import operations is granted manage privilege on the objects.

Different Modes: import process

The first row indicates the two options in the import transport set manager (overwrite mode, check only) and result when they are manipulated. The next rows show the different combinations of the boxes (for overwrite mode and check only) getting set and unset and the end result.

Import Option: Overwrite Mode

Import Option: Check Only Mode

Results

Checked

Checked

Overwrite Mode - Check Only.

No actual import. Will report potential conflicts if any existing objects will be overwritten

Checked

Unchecked

Overwrite Mode. Existing objects overwritten with imported objects.

Unchecked

Checked

Reuse Mode - Check Only. No actual import. Will report existing objects that will be reused.

Unchecked

Unchecked

Reuse mode. Existing objects reused and not imported.

Additional Notes:

Single Sign On (SSO) Server

SSO Server export is handled using scripts located in the wwu directory under the directory in which the Portal is installed. SSO Server export/import does not provide support for external and partner applications, and password stores.

Any object from these placed on a page will not work correctly when the page is migrated from one portal to another.

See example below for the usage of SSO Server export and import scripts:

Examples:

UNIX:

From the command line on UNIX, enter the following command to run the SSO Server export data script:

ssoexp.csh [-e <export name>] [-s <sso_schema>] [-p <sso_password>] [-d <dump_file_name>] [-c <connect_string>]

From the command line on UNIX, enter the following command to run the SSO Server import data script:

ssoimp.csh [-e <export name>] [-s <sso_schema>] [-p <sso_password>] [-m reuse] [-d <dump_file_name>] [-c <connect_string>]

DOS:

From the command line on DOS, enter the following command to run the SSO Server export data script:

ssoexp.cmd [-e <export name>] [-s <sso_schema>] [-p <sso_password>] [-d <dump_file_name>] [-c <connect_string>]

From the command line on DOS, enter the following command to run the SSO Server import data script:

ssoimp.cmd [-e <export name>] [-s <sso_schema>] [-p <sso_password>] [-m reuse] [-d <dump_file_name>] [-c <connect_string>]

Exporting/Importing Pages Containing Custom Item Types

Portal Export/Import of pages overwrites all attribute values of items based on custom item types with custom attributes in the target portal. For this reason, you should create items (based on custom item types) on the source portal only, and migrate them to the target through the export-import process for that page.

Exporting/Importing Page URLs Correctly

By default, generated page URLs contain installation specific ID numbers that change when the object is exported. This causes broken links when pages are imported into a different site. 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=portalr2

The same page has this direct access URL:

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

This direct access URL still works on an imported page, providing the name of the page (e.g. HRBENEFITS) and the names of its parent pages (e.g. HRHOME, HRPAGEGROUP) do not change. 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. Therefore, to ensure that links do not 'break' when pages are imported into a different site, always use Page Link item types or direct access URLs when creating links to pages.

For more information, refer to 'Direct Access URLs' and 'Page Links' in the Oracle9iAS Portal online help.

The following object types can be exported from Portal:

Page Groups:

DB Providers:

Web and Other Providers:

Only the registration information stored about the portlet providers (web and database) in Portal is exported. These providers (seen in Navigator) cannot be marked for export; their registration information is implicitly exported whenever pages containing portlets from these providers are exported. For this reason, it is important that the web providers and (more importantly) database provider are available to the portal system where the import will occur.

For web providers, make sure that the import portal can utilize the information in the registration record to successfully register the web provider – if the export portal sits in an internal network and the import sits in an external network and proxies are required for the proper registration and access of the web provider then create the web provider manually on the target server with the same name as the export server.

Under certain circumstances (see the examples below) it would beneficial if the web providers were registered and tested independently (i.e., can the provider's portlets be seen, does registering a portlet from the provider in a test page fail, etc.) before performing any migration work.

Example Conditions

Note: That while the providers could point to different URL's, the providers themselves must be the same - they must have the same "internal" name, and they must have the same portlets (i.e., the id of the portlet is the same).

Example, if SAMPLE_WEB_PROVIDER is the name on the export portal, use the same name when manually registering the provider on the import portal.

For database providers, make sure the schema referenced in the registration information (in the export portal) is exported and imported first – if the same schema name cannot be used for the database provider in the import portal, create the schema with all the objects required for it to be a database provider, manually register a database provider with the same name as the export portal pointing to this schema before using portal export import.

If for some reason a web or database provider is down, then the import will fail for the portlets belonging to the provider.

NoteThe provider metadata information for Page Group and DB Providers are exported along with the page group and db provider objects automatically.

Related topics

Back to top