|
Oracle® Application Server Portal Installation and Upgrade Guide
10g Release 2 (10.1.4) B19135-01 |
|
 Previous |
 Next |
|
Oracle® Application Server Portal Installation and Upgrade Guide
10g Release 2 (10.1.4) B19135-01 |
|
|
Previous |
Next |
This chapter describes the tasks that you must perform after a successful upgrade.
Perform the following actions after the upgrade script has completed successfully and you have made a backup of the upgraded OracleAS Portal release 10.1.4 instance. You must perform a backup because several of the post-upgrade actions can negatively affect the repository if not applied correctly.
Post-upgrade tasks are divided into the following two categories:
To ensure that you can use an upgraded OracleAS Portal instance without problems, you must perform the following post-upgrade tasks:
Section 4.1.1, "Updating to the New URL Format and Correcting Invalid Links"
Section 4.1.2, "Removing Obsolete Substitution Tags in HTML Page Skins"
Section 4.1.3, "Reregistering OracleAS Portal as a Content Source in Oracle Ultra Search"
Section 4.1.4, "Scheduling a Full Recrawl Using Oracle Ultra Search"
Section 4.1.5, "Updating the OracleAS Portal URL in the OracleAS Wireless Service Definition"
Section 4.1.8, "Changing the Category and Perspective Names"
Due to architectural changes, the format of URLs has changed in OracleAS Portal release 10.1.4. If you try to access portal objects in an upgraded OracleAS Portal instance using the old URL format, then you will be presented with a redirection screen that shows the old URL you are accessing, along with a new URL. This screen will automatically redirect you to the new URL format.
|
Note: Update any references and bookmarks that include old URLs. The old format will not be supported in future releases. |
Displaying a URL Redirection Screen
You can choose whether to display a URL redirection screen or not. The URL redirection screen displays both the new and old URLs to assist in correcting bookmarks, and so on.
When you access an old URL, the URL redirection screen is displayed by default. To alter the default behavior, you can use the pobredir.sql script. It is located in the portal/admin/plsql/wws directory in the upgrade CD-ROM. The script takes one parameter. Run this script as the portal schema owner.
The following is an example for running the script to enable seamless redirection to the new URL:
SQL> @pobredir.sql 1
A value of 1 seamlessly redirects the user to the new URL and does not produce the redirection screen.
|
Note: If you choose a value of1, then the seamless redirection will work only for this release. After future upgrades, these URLs may be broken. For this reason, turn off the seamless redirection at some point, and fix any URLs that are causing redirection.
|
A value of 0, which is the default value, produces the redirection page.
To run the pobredir.sql script, you must log in to the OracleAS Metadata Repository database as the portal schema user from SQL*Plus. If OracleAS Portal was installed on a customer database, then log in to the database that hosts the portal schema.
Viewing Portal Schema Password Using Oracle Directory Manager To log in to the OracleAS Metadata Repository database as the portal schema user, you must know the portal schema password. If the portal schema resides in the OracleAS Metadata Repository, then the portal schema password is stored in Oracle Internet Directory. You can get the portal schema password from Oracle Internet Directory using Oracle Directory Manager.
To view the portal schema password, perform the following steps:
Start Oracle Directory Manager:
On UNIX, use the following command:
METADATA_REP_ORACLE_HOME/bin/oidadmin
On Windows, click Start, Programs, Oracle Application Server <ias_instance_name>, Integrated Management Tools, and Oracle Directory Manager.
Log in to Oracle Directory Manager as the orcladmin user.
In the System Objects frame, expand Entry Management, cn=OracleContext, cn=Products, cn=IAS, cn=IAS Infrastructure Databases, and then orclReferenceName=<Infrastructure Database name> for the OracleAS Metadata Repository.
Select the OrclResourceName=PORTAL entry to view the portal schema password.
In the Properties tab, you can view the password in the orclpasswordattribute field.
Durable URLs
A durable URL is formed by using a GUID. The format for a durable URL is as follows:
http://<host>:<port>/portal/page/<portal_DAD>[/lang-<language>][/ver-<version>]/<item_guid>
For example, to access a document, mydocument.htm, which has an ID A47D41ECA23648A9E030007F0100118A, the URL is as follows:
http://mymachine.mycompany.com:5000/portal/page/mydad/lang-en/A47D41ECA23648A9E030007F0100118A
The format of a durable URL to render a page is as follows:
http://<host>:<port>/portal/page/<portal_DAD>/<page_guid>
Because the GUID of an object never changes, the URL will continue to be valid even if the object name changes. Durable URLs are generated by OracleAS Portal for item types such as Page Path, Page Links, List of Objects, and so on.
Updating Direct-Access URLs
Direct-access URLs that were used in earlier releases of OracleAS Portal are now referred to as path-based URLs. A path-based URL is formed by identifying the path taken through the portal to get to a particular object. In earlier releases, a path alias like doc, url, and page was used in the URL to denote the type of portal object being accessed. The format of direct-access URLs has changed in this release and does not contain the path alias any more. Following this release, direct-access URL formats will be obsolete.
For backward compatibility, direct-access URL formats are supported in this release of OracleAS Portal. These URL formats invoke a redirection screen that redirects users to the correct target. Avoid using direct-access URL formats going forward, and consider fixing legacy uses of these formats.The syntax for the obsolete URL format is as follows:
http://<host>:<port>/pls/<portal_DAD>/<path_alias>/PAGE/<page_path>
|
Note: Only the first tab in a path alias of path-based URLs is preserved when redirecting to the new URL format. The other tabbed regions on the page default to the first available tab in the region. |
Table 4-1 describes the format of path-based URLs in OracleAS Portal release 10.1.2.0.2 or 10.1.2.1.0, and release 10.1.4.
Table 4-1 Changes to Path-Based URLs
| Type of URL | Format in OracleAS Portal Release 10.1.2.0.2 or 10.1.2.1.0 | Format in OracleAS Portal Release 10.1.4 |
|---|---|---|
|
Page Path-Based URL |
Sample URL to access a page called
|
Note: The Sample URL to access a page called
|
|
Document Path-Based URL |
Sample URL to access a document called
|
Note: The Sample URL to access a document called
|
|
Note: To avoid broken links in the future, it is recommended that you replace path-based URLs with durable URLs. A durable URL uses the object globally unique identifier (GUID) in the URL, and therefore does not cause the link to be broken even if the object name has changed. Refer to the section titled "Durable URLs" for information about durable URLs. |
To update a direct-access URL and fix a broken link, perform the following steps:
Display a link to the property sheet by adding a Property Sheet Smart Link item to the page. Look at the page property sheet to obtain the path-based URL and update the link. Refer to the Oracle Application Server Portal User's Guide for information about performing these steps.
Find the page to which the link must be attached.
Replace the broken link with the new one.
The redirection screen will not be displayed when you access portal objects using the new URL format.
Updating ID-Based URLs
For backward compatibility, ID-based URLs are supported in the current release of OracleAS Portal. Following this release, ID-based URLs that use the following syntax will be obsolete:
http://<host>:<port>/portal/page?_pageid=<site_id>,<page_id>,<tabstring>&_dad=<portal_DAD>&_schema=<portal_schema>
For the current release, ID-based URL formats invoke a redirection screen that redirects users to the correct target. Avoid using ID-based URL formats in the future, and consider fixing legacy uses of these formats.
Note the newly formed URL that is displayed on the redirection screen and correct the link. After you update URLs to the new format, a redirection screen will not be displayed when you access portal objects.
|
See Also: The Oracle Application Server Portal User's Guide for information about the types of URLs supported in OracleAS Portal release 10.1.4. |
In earlier releases, unstructured user interface (UI) templates governed what was displayed on the page. From release 10.1.4 onward, HTML page skins replace the functions of unstructured UI templates. Some of the substitution tags that were used in these templates are now obsolete. After upgrading to OracleAS Portal release 10.1.4, to ensure that portal pages are rendered without errors, do not use obsolete substitution tags in HTML page skins. To ensure that you are not using obsolete substitution tags, perform the following steps:
Open the HTML page skin template in edit mode.
Check the template for obsolete substitution tags. For a list of obsolete substitution tags, refer to Section 5.1.3, "Obsolete Substitution Tags for HTML Templates".
If you find obsolete substitution tags, then replace them with valid substitution tags, or remove them from the template. For a list of substitution tags that are supported, refer to the Oracle Application Server Portal User's Guide.
Perform this step only if you are using Oracle Ultra Search, and have registered OracleAS Portal as a content source.
As the URL format has changed in OracleAS Portal release 10.1.4, after performing the upgrade, you must reregister OracleAS Portal as an Oracle Ultra Search content source by deleting the existing OracleAS Portal content source and creating a new one. Perform the steps in the following sections to delete the existing OracleAS Portal content source, and register the upgraded portal instance as a new content source:
Section 4.1.3.1, "Deleting the Old OracleAS Portal Content Source"
Section 4.1.3.2, "Registering the Upgraded Portal Instance as an Oracle Ultra Search Content Source"
To delete the portal instance, which was registered as an Oracle Ultra Search content source before performing the upgrade, perform the following steps:
Click Ultra Search Administration in the Services portlet to access the Oracle Ultra Search administration tool.
By default, the Services portlet is on the Portal subtab of the Administer tab on the Portal Builder page.
|
Note: If you started with OracleAS Portal release 9.0.2 or earlier, then you will not be able to log in to the Oracle Ultra Search Administration tool as a portal administrator.To access the Oracle Ultra Search Administration tool, you must perform the following tasks:
|
On the Instances tab, click Apply to set the instance.
If you have more than one instance, then ensure that you select the instance you want to update first.
Click the Sources tab, and then click the Oracle Sources subtab.
Select the old OracleAS Portal content source, and then click Delete.
To register the upgraded portal instance as an Oracle Ultra Search content source by specifying the new URL, refer to the section titled "Registering OracleAS Portal As a Content Source" in the Oracle Application Server Portal Configuration Guide.
Once you have registered OracleAS Portal as an Oracle Ultra Search content source, you can register the Ultra Search provider with OracleAS Portal.
Perform this step if you have created custom file attributes for items and pages, and are displaying these attributes through the Oracle Ultra Search content repository.
In OracleAS Portal release 10.1.4, the format of the URL for custom file attributes has changed. Because of this, the Oracle Ultra Search content repository must be updated. Oracle Ultra Search identifies changes by looking at the date on which the items were updated. In this case, the date has not changed, and therefore the Oracle Ultra Search content repository will not be updated. To update this content repository, you must schedule a full recrawl of OracleAS Portal using Oracle Ultra Search.
For details about scheduling a full recrawl of OracleAS Portal, refer to Section "Schedule-Related APIs" in Chapter 11 in the Oracle Ultra Search Administrator's Guide.
Perform this task only if you are accessing OracleAS Portal using a wireless device.
Wireless devices access OracleAS Portal by using the portal home page URL that is stored in the Oracle Application Server Wireless server service definition. Because the OracleAS Portal URL format has changed in release 10.1.4, this change must be reflected in the OracleAS Wireless server service definition.
To update the OracleAS Portal home page URL in the OracleAS Wireless server service definition, perform the following tasks:
Log in to OracleAS Wireless Tools by using the following URL:
http://<host>:<port>/webtool/login.uix
Log in as an Oracle Application Server administrator, such as orcladmin. (The password is set during installation, but can be changed with the User Manager.)
Click the Contents tab.
In the Content Manager, select the portal service, and click Edit.
Click Input Parameters on the left-hand side of the screen.
In the Input Parameters screen, change the existing URL to the following:
http://<host>:<port>/portal/pls/<portal_DAD>/<portal_schema>.home
For example:
http://myserver.abc.com:7778/portal/pls/portal/portal.home
Click Apply to save the changes.
Log out of the Content Manager.
|
Note: If you do not perform this task, then every time you try to access OracleAS Portal using a wireless device, a redirection screen is displayed with a link to the new URL. |
Perform this task only if you are using the OracleAS Portal Export and Import feature.
If you have two portal instances, one source and one target, where you migrate page groups between these two instances using the OracleAS Portal Export and Import functions, then after an upgrade, if you try to export and import content between the two portal instances, it will fail. This happens because the upgrade process assigns new GUIDs to page groups, pages, categories, and perspectives, which are unique for each upgraded portal instance. As the GUIDs of the objects in the two portal instances no longer match after the upgrade, the precheck for these objects will fail during the import.
In such cases, you must run the guidmasg.sql script located in the portal/admin/plsql/wwu directory in the upgrade CD-ROM. Do this before performing an export and import operation. Running this script synchronizes the GUIDs of objects between the upgraded source and target portal instances, and also ensures that any future export and import of page groups is not affected by GUID mismatch.
To run the guidmasg.sql script, perform the following steps:
Back up the source and target portal instances if you have not already done so.
Change the directory to a location where you have write permissions. The guidmasg.sql script will create a set of log files in this location.
Using SQL*Plus, connect to the target portal instance.
|
Note: If the portal schema resides in the OracleAS Metadata Repository, and if you do not know the portal schema password, then refer to "Viewing Portal Schema Password Using Oracle Directory Manager" in Section 4.1.1 to find out the password. |
Create a database link to the source portal schema, as follows:
create database link <database_link_name> connect to <source_portal_schema> identified by <source_portal_password> using <database_connect_info>;
|
See Also: The Oracle Database Administrator's Guide in the Oracle Database documentation library, for information about creating database links. |
Verify that you are able to connect to the source portal instance using the prior database link, as follows:
select version from wwc_version$@<database_link_name>;
Log in to the OracleAS Metadata Repository database on the target portal instance as the portal schema user from SQL*Plus. If OracleAS Portal was installed on a customer database, then log in to the database that hosts the portal schema.
|
Note: If the portal schema resides in the OracleAS Metadata Repository, and if you do not know the portal schema password, then refer to "Viewing Portal Schema Password Using Oracle Directory Manager" in Section 4.1.1 to find out the password. |
Run the guidmasg.sql script and pass the database link name as the input parameter by using the following command:
@CD_ROOT/portal/admin/plsql/wwu/guidmasg.sql <database_link_name>
Review the guidmasg.log file, generated in the current directory, for any errors. Refer to Section 4.1.6.1, "Reviewing the Log Files" for more information.
You can now export and import the page groups between the source and target portal instances.
|
Note: If you have more then two portal instances between which the Export and Import operations must be performed, then you must perform the preceding steps multiple times until all portal instances are synchronized. For example, if you have development, test, stage, and production portals, named Portal A, Portal B, Portal C, and Portal D respectively, then you must run the script in the following manner:
|
To review the output of the guidmasg.log file and to ensure that there are no errors, perform the following checks:
Ensure that the number of page groups listed in the log file as updated includes all the page groups that were migrated before the upgrade to release 10.1.4.
For each page group, verify that the number of pages, perspectives, and categories on both the source and target instances are correct. If there are a greater number of pages and perspectives and categories on the source, then it indicates that the objects are not yet present in the target, which is expected. If there are a greater number of pages on the target, then the additional target pages may be an issue if pages with the same name are created in the upgraded source instance and an attempt is made to import them to the target instance at a later date.
The errors in the log file are sent to standard output and are also included in a separate section at the end of the log file. Use the line numbers in the section at the end of the log file to search for the errors when they occurred earlier in the file.
Perform this task only if you are already using the performance reporting scripts.
To generate performance reports for OracleAS Portal, you must use a set of SQL scripts. The scripts are located in the following directory:
CD_ROOT/portal/admin/plsql/perf
By running these scripts, OracleAS Portal log files are loaded into a database table and reports can be generated based on the information in the log files.
|
Caution: It is highly recommended that you do not store this data in the same database as the portal repository because this may affect performance. |
If you are already using the performance reporting scripts, then after upgrading the OracleAS Portal repository to release 10.1.4, you must run the new copy of the CD_ROOT/portal/admin/plsql/perf/install/update.sql file. This is to accommodate the new URL format for repository requests and to enable collection of new data. If this is not done, then the scripts will not work.For details about how you can use the scripts to monitor OracleAS Portal performance, refer to the README.html file in the scripts subdirectory:
CD_ROOT/portal/admin/plsql/perf/scripts/README.html
Perform this task only if you started with OracleAS Portal release 3.0.9.
You may find that you are not able to access category and perspective pages by using path-based URLs with their pre-upgrade names. This is because, after upgrade, the page ID and page group ID are appended to the category or perspective name. Therefore, the category or perspective name that you specified in the URL is not valid. For example, if you had a category named GENERAL in release 3.0.9, then on moving to release 10.1.2.0.2 or 10.1.2.1.0, and then to release 10.1.4, the name of this category may be GENERAL_12345_0, where 12345 is the page ID and 0 is the page group ID.
As a workaround to this problem, perform either of the two tasks:
Change the category or perspective name to the pre-upgrade name by removing the ID that is appended to the name.
Specify a new name. If there is an existing category or perspective with the name you specified, then you are prompted for a different name.
|
Note: The title of the category will remain unchanged. |
Perform this task only if the database that contains the portal schema was upgraded to Oracle Database 10g from an earlier release.
Oracle Streams Advanced Queuing time manager processes are controlled by the database initialization parameter, AQ_TM_PROCESSES. This parameter must be set to a nonzero value. This enables time monitoring on queue messages and processes messages with delay and expiration properties specified.
For details about updating a database initialization parameter file, refer to the section, "Managing Initialization Parameters Using a Server Parameter File", in the Oracle Database Administrator's Guide in the Oracle Database 10g documentation library.
The following sections describe post-upgrade steps that are optional:
Section 4.2.1, "Moving the Portlet Repository to the New Format"
Section 4.2.3, "Configuring Oracle Text Indexes to Synchronize on Commit"
By default, the portlet repository is upgraded in-place in the OracleAS Portal schema. The existing pages, templates, items, and so on, in the portlet repository are upgraded, and the new portlets are added into the repository. As the old settings are preserved, the pages look very similar to the way they did before the upgrade was run.
|
Note: If you started with Oracle9iAS Portal release 9.0.2 and you had rendered the Portlet Repository as grouped by Provider names, then after the upgrade, the folders in the repository will be grouped by the category, because the Group by Provider Name option has been deprecated since Oracle Application Server 10g (9.0.4).To create a similar organization, assign the portlet names to categories that represent the Provider names. |
If you want the repository to have the appearance of a newly installed instance, then the prrplc.sql script is available to re-create the upgraded portlet repository. This script removes the existing portlet repository and re-creates it. Use the script only if you do not wish to preserve customizations, settings, styles, banners, and so on in the portlet repository.
To re-create the portlet repository, perform the following steps:
Perform a backup of the database, as the script overwrites the repository and is not reversible.
Follow the steps described in Section 3.4, "Starting All Middle Tiers" to start the middle-tier instances.
Navigate to the following directory on the Oracle Application Server Portal Upgrade CD–ROM, which contains the prrplc.sql script:
CD_ROOT/portal/admin/plsql/upg/frwk
Log in to the OracleAS Metadata Repository database as the portal schema user from SQL*Plus. If OracleAS Portal was installed on a customer database, then log in to the database that hosts the portal schema.
|
Note: If the portal schema resides in the OracleAS Metadata Repository, and if you do not know the portal schema password, then refer to "Viewing Portal Schema Password Using Oracle Directory Manager" in Section 4.1.1 to find out the password. |
Run the prrplc.sql script with no arguments.
From OracleAS Portal release 10.1.4 onward, the Community News portlet is obsolete. But this portlet is still available on portal pages. When you try to edit this portlet, a blank page is displayed. To avoid confusion, you can manually delete the Community News portlet from portal pages. To delete this portlet from a page, perform the following steps:
Log in to OracleAS Portal.
Navigate to the page from which you want to delete the portlet.
Click Edit at the top of the page to switch to Edit mode.
Click Actions next to the Community News portlet.
Click Delete.
On the confirmation page, click Yes to delete the portlet and return to the page.
If you are using Oracle Database 10g or later, Oracle Text indexes can be configured to synchronize immediately after data is committed to your portal. This is a new feature in OracleAS Portal release 10.1.4 but it does not apply to databases earlier than Oracle Database 10g.
On upgrade, Oracle Text indexes are not updated to make use of this new feature. This means that all the Oracle Text indexes are configured to synchronize manually using wwv_context.sync procedure. If you want to take advantage of the on commit feature introduced in Oracle Database 10g, then use the procedure wwv_context.commit_sync to reconfigure Oracle Text indexes. For more information, refer to the section titled "Configuring Oracle Text Indexes to Synchronize On Commit" in the Oracle Application Server Portal Configuration Guide.
