5 Basic Configuration and Administration

This chapter assumes that Oracle Portal has been installed along with the Oracle Fusion Middleware components and addresses the basic tasks that the portal administrator can perform after installation is complete.

This chapter contains the following sections:

5.1 Getting Started with Oracle Portal Administration

Basic Oracle Portal configuration can be performed on the Administer tab available from Oracle Portal. Additionally, there are other administrative tools available to configure Oracle Portal and its related components.

This section will introduce you to the various different administrative tools:

5.1.1 Using the Oracle Portal Administer Tab

The Oracle Portal framework provides administrative services, such as access to monitoring and configuration tools, single sign-on, directory integration, caching, and security. A lot of the features needed to manage users and groups, to set up security and search features, and to administer the portal and database are incorporated into a series of dialog boxes accessed through portlets on a portal page.

After you have installed Oracle Portal, you need to log in as an administrator (The default username is orcladmin), to perform various administrative functions. After you have logged in to Oracle Portal, the Portal Builder page is displayed.

Click the Administer tab to view all the subtabs and portlets that help you administer the portal. The Administer tab is shown in Figure 5-1.

Figure 5-1 The Administer Tab on the Portal Builder Page

Description of Figure 5-1 follows
Description of "Figure 5-1 The Administer Tab on the Portal Builder Page"

You will see the following subtabs in the Administer tab screen:

  • Portal - This subtab enables you to create users and groups, administer the OracleAS Single Sign-On (SSO) server, and administer other services including Oracle Internet Directory, Secure Enterprise Search, Web Cache, proxy settings, and so on.

  • Portlets - This subtab enables you to view the Portlet Repository and its refresh log, and register remote providers and provider groups.

  • Database - This subtab enables you to create and edit database schemas, create and edit database roles, and monitor database information like database parameters, memory consumption, and database storage details.

Portal

This subtab under the Administer tab in the Portal Builder page contains the portlets shown in Table 5-1. This subtab is displayed by default when you click the Administer tab.

Table 5-1 Portlets in the Portal Subtab

Portlet Name Enables You to

Services

  • Specify default home page, default style, and so on.

  • Administer users and groups in the Oracle Internet Directory or configure the directory settings.

  • Administer log registry.

  • Set up basic and advanced search features.

  • Specify Proxy Server settings.

  • Administer and monitor the performance of Oracle Portal and its dependent components such as the Oracle HTTP Server, Portal Services, Oracle Metadata Repository, Secure Enterprise Search, and providers using the Oracle Enterprise Manager 11g Fusion Middleware Control.

  • Manage Oracle BPEL process definition, and configuring BPEL callback.

See Chapter 8, "Monitoring and Administering Oracle Portal" for more information on administering the log registry and monitoring Oracle Portal performance.

Transport Set -Export Services

Transport Set -Acquire Services

  • Register a database link as source portal.

  • Browse or delete source portal registration.

  • Acquire a transport set from the source portal to your portal.

  • See Chapter 11, "Acquire Transport Set Services" for more information.

Transport Set -Import Services

Oracle Reports Security

  • Define access to Oracle Reports objects.

  • Report definition file.

SSO Server Administration

  • Edit OracleAS Single Sign-On (SSO) Server configuration.

  • Create or edit configuration information for partner applications.

  • Create or edit configuration information for external applications.

See Chapter 7, "Securing Oracle Portal" for more information.

Note: You will need to log in as an Oracle Fusion Middleware administrator to change SSO settings.

Oracle Reports Security

  • Define access to Oracle Reports objects.

  • Report definition file.

User

  • Create new users and specify account information.

  • Edit or delete users.

Portal User Profile

  • Establish the user's preferences and global privilege information in the portal.

Group

  • Create groups, assign users to them, and designate group administrators.

  • Edit or delete groups.

Portal Group Profile

  • Establish the group's preferences and privilege information in the portal.

Portlets

This subtab under the Administer tab in the Portal Builder page contains the portlets shown in Table 5-2.

Table 5-2 Portlets in the Portlets Subtab

Portlet Name Enables You To

Portlet Repository

  • View all local and remote portlets.

  • Refresh information about all the portlets in the repository.

  • View Portlet Repository refresh log.

Remote Providers

  • Add a provider to the portlet repository.

  • Change configuration and access information about a provider.

Remote Provider Group

  • Register multiple providers with a single URL.

  • Edit a Provider Group registration.

Database

This subtab under the Administer tab in the Portal Builder page contains the portlets shown in Table 5-3.

Table 5-3 Portlets in the Database Subtab

Portlet Name Enables You To

Schemas

  • Create new database schemas, or edit existing schemas.

Roles

  • Create new database roles, or edit existing roles.

Database Information

  • Monitor and view various database related information and parameters.

Database Memory Consumption, Transactions and Locks

  • Monitor database jobs.

  • View reports and charts of memory consumption and transactions.

  • Monitor session and locks.

  • Terminate undesirable user sessions.

Database Storage

  • Monitor and view various database storage related information.

5.1.2 Using Additional Administrative Tools

For some administrative tasks that cannot be performed through the Oracle Portal Administer tab, you may need to use one of the following tools:

5.1.2.1 Oracle Enterprise Manager 11g Fusion Middleware Control

Oracle Enterprise Manager 11g Fusion Middleware Control is included when you install Oracle Fusion Middleware. From Oracle Portal's perspective, consider this to be the administration tool for the Oracle Fusion Middleware. Oracle Fusion Middleware Control enables you to perform the following administration and configuration operations:

  • Administer clusters

  • Start and stop services

  • View logs and ports

  • Perform real-time monitoring

  • Modify the OracleAS Infrastructure services used by an Oracle Fusion Middleware middle tier.

Refer to Chapter 8, "Monitoring and Administering Oracle Portal" for a detailed description of these Oracle Fusion Middleware Control functions.

Most configuration changes for an Oracle Portal instance are made from the Portal home page or one of the component pages accessed from the Portal home page. To open Portal home page from the Oracle Fusion Middleware Control home page, use the navigation sidebar to open the instance, expand Portal folder, and then select the Oracle Portal instance to configure. Refer to "Accessing Oracle Enterprise Manager 11g Fusion Middleware Control" for instructions on how to access Fusion Middleware Control.

5.1.2.2 WebLogic ScriptingTool (WLST) Command-line Utility

The WebLogic Scripting Tool (WLST) is a command-line scripting interface, that helps you to perform administrative tasks and initiate WebLogic Server configuration changes to WebLogic Server instances and domains. For more information, see the WebLogic Scripting Tool Command Reference guide. You can use Portal-specific WLST commands to complete the following administrative and configuration tasks:

See Also:

5.1.2.3 Portal Installation and Configuration Scripts

There are also various scripts, copied to your ORACLE_INSTANCE during the installation of Oracle Portal. These scripts may be needed to perform administrative actions. Refer to Appendix B, "Using Oracle Portal Installation and Configuration Scripts" for a description of these scripts.

5.2 Finding Out Information About Oracle Portal

This section covers the following topics:

5.2.1 Accessing Oracle Portal in Your Browser

After Oracle Portal is installed, access it by entering the following URL in your browser:

http://<host>:<port>/portal/pls/<dad>

See Table 3-2, "Portal URL Descriptions" for an explanation of the URL components.

For backward compatibility, the old URL syntax is supported in this release. For example, http://<host>:<port>/pls/<dad>.

See Also:

Section 3.1, "Installation Overview"

5.2.2 Finding Your Oracle Portal Version Number

To find your portal version number:

  1. Log in as a portal administrator.

  2. In the Portal Builder, click the Administer tab.

    By default, the Services portlet is on the Portal subtab of the Administer tab on the Portal Builder page.

  3. Click the Portal tab.

  4. In the Services portlet, click the Global Settings link.

    The version number for your Oracle Portal is shown at the bottom of the page.

5.3 Performing Basic Page Administration

This section covers the following topics:

5.3.1 Setting a Default Home Page

The home page is the first page that is displayed to a user after logging in to Oracle Portal. Here's how the logic works:

  • If the user has specified a personal home page, that page is displayed when the user logs on.

  • If the user has not selected a personal home page, but the portal administrator has set one for him or her, the default home page specified for that user is displayed.

  • If the user has not selected a personal home page, but belongs to a default group, the default home page specified for that group is displayed.

  • If there is no default home page for the user's default group, or if the user has no default group, then the system default home page is displayed.

Note:

You must be a portal administrator to define a default home page for the system, a group, or a user.

5.3.1.1 Setting the System Default Home Page

If there is no default home page for the user's default group, the system default home page is displayed.

To set the system default home page:

  1. In the Services portlet, click Global Settings.

    By default, the Services portlet is on the Portal subtab of the Administer tab on the Portal Builder page.

  2. Next to the Default Home Page field, click the Browse Pages icon to see a list of pages from which to choose.

    Note:

    You cannot enter a value in this field; you must select one from the list.

  3. Click Return Object next to the page you want to make the system default home page.

  4. Click OK to return to the Portal Builder.

    Note:

    To check that you set the system default home page correctly, log out of the portal and log back in again. When you log back in, you should be taken the page that you specified as the system default home page.

5.3.1.2 Setting a Group's Default Home Page

If the user has not selected a personal home page, but belongs to a default group, the default home page specified for that group is displayed.

To set a group's default home page:

  1. In the Portal Group Profile portlet, in the Name field, enter the name of the group for which you want to assign a default home page.

    By default, the Portal Group Profile portlet is on the Portal subtab of the Administer tab on the Portal Builder page.

    Note:

    If you are not sure of the group name, click the Browse Groups icon and select from the list provided.

  2. Click Edit.

  3. Next to the Default Home Page field, click the Browse Pages icon to see a list of pages from which to choose.

    Note:

    You cannot enter a value in this field; you must select one from the list.

  4. Click Return Object next to the page you want to make the default home page for this group.

  5. Click OK.

    Note:

    Click Reset to remove the group's default home page.

5.3.1.3 Setting a User's Default Home Page

If the user has not selected a personal home page, but you have set one for him or her, the default home page specified for that user is displayed.

To set a user's default home page:

  1. In the Portal User Profile portlet, in the Name field, enter the user name of the user for whom you want to assign a default home page.

    By default, the Portal User Profile portlet is on the Administer tab of the Portal Builder page.

    Note:

    If you are not sure of the user name, click the Browse Users icon and select from the list provided.

  2. Click Edit.

  3. Next to the Default Home Page field, click the Browse Pages icon to see a list of pages from which to choose.

    Note:

    You cannot enter a value in this field; you must select one from the list.

  4. Click Return Object next to the page you want to make the default home page for this user.

  5. Click OK.

    Note:

    Click Reset to reset the user's default home page to the system default home page.

5.3.2 Setting the System Default Style

If you are the portal administrator, you are responsible for selecting a style to serve as the system default.

When a style is deleted, all pages and item regions that used the style revert to the page group default style. If the page group default style is <None>, all pages and regions revert to the system default style.

Note:

To set the system default style, you must be the portal administrator.

To set the system default style:

  1. In the Portal Builder, click the Administer tab.

  2. Click the Portal subtab.

  3. In the Services portlet, click the Global Settings link.

    By default, the Services portlet is on the Portal subtab of the Administer tab on the Portal Builder page.

  4. In the Default Style section, choose a style from the Display Name list.

    Note:

    The list includes all public styles in the Shared Objects page group.

  5. Click OK to return to the Portal Builder.

5.3.3 Creating Personal Pages

A personal page provides an area within Oracle Portal where authorized users can store and share their own content. Personal pages are located under the Shared Objects page group, and are organized alphabetically by user name.

Note:

To create personal pages for users, you must be the portal administrator.

This section covers the following topics:

5.3.3.1 Automatically Creating a Personal Page for New Users

To configure Oracle Portal to automatically create a personal page for new users:

  1. In the Services portlet, click Global Settings.

    By default, the Services portlet is on the Portal subtab of the Administer tab on the Portal Builder page.

  2. Ensure that you are on the Main tab.

  3. Select Create Personal Pages for New Users.

  4. Click OK.

Whenever a new user logs on for the first time, a personal page is automatically created for that user.

Note:

Personal pages are automatically created when new users log on for the first time (that is, when the user record is created for the user), not for users that already exist.

5.3.3.2 Creating a Personal Page for an Existing User

To configure Oracle Portal to create a personal page for an existing user:

  1. In the Portal User Profile portlet:

    1. In the Name field, enter the name of the user for whom you want to create a personal page.

      Note:

      If you are not sure of the name of the user, click the Browse Users icon and select from the list provided.

    2. Click Edit.

    By default, the Portal User Profile portlet is on the Administer tab of the Portal Builder page.

  2. Ensure that you are on the Preferences tab.

  3. Select Create Personal Page.

    Note:

    If you do not see this check box, the user already has a personal page.

  4. Click OK.

    Notes:

    • Personal pages are accessible from the Navigator in the Shared Objects page group. Any authorized user can drill down into the Personal Pages area of the Shared Objects page group, but they can only view their own personal page, or those personal pages to which they have been granted access.

    • Personal pages for users with user names that do not begin with an alphabetic character are located under the Others area of Personal Pages.

    • Personal pages cannot be deleted.

5.3.4 Setting the Total Space Allocated for Uploaded Files

You can limit the amount of space provided in your database to store documents uploaded to page groups. See Section 5.3.6, "Changing the Page Group Quota" if you want to limit the amount of space provided for a single page group.

You can also limit the size of individual files that content contributors can upload to page groups. See Section 5.3.5, "Setting the Maximum File Size for Uploaded Files" for more information.

When a user uploads a file to the portal, the upload is monitored in the middle tier to detect whether the total space or maximum file size is exceeded. If either of these limits is exceeded, the upload is terminated and an error message is displayed.

Note:

To set the total space allocated for uploaded files, you must be the portal administrator.

To set the total space allocated for uploaded files:

  1. In the Services portlet, click Global Settings.

    By default, the Services portlet is on the Portal subtab of the Administer tab on the Portal Builder page.

  2. Make sure you are on the Main tab.

  3. In the Total Space Allocated radio group, select Limit To to limit the amount of space provided to store files uploaded to the page groups in this portal.

  4. In the field, enter the maximum amount of megabytes provided for uploaded files across the whole portal. When this limit is reached, users will no longer be able to upload files to page groups in the portal.

    Notes:

    • Select No Limit if you do not want to impose a limit for uploaded files.

    • The Used Space field displays the amount of space currently used by documents uploaded to page groups in this portal provided that a limit has been set. If no limit has been set you can still find out how much space is being used by clicking Calculate. Note that the calculation may take some time.

  5. Click OK.

5.3.5 Setting the Maximum File Size for Uploaded Files

You can limit the size of individual files that users can upload to the page groups in your portal.

You can also limit the total amount of space provided in your database to store documents uploaded to page groups. See Section 5.3.4, "Setting the Total Space Allocated for Uploaded Files" for more information.

When a user uploads a file to the portal, the upload is monitored in the middle tier to detect if the maximum file size or portal file quota is exceeded. If either of these limits is exceeded, the upload is terminated and an error message is displayed.

Note:

To set the maximum file size for uploaded files, you must be the portal administrator.

To set the maximum file size for uploaded files:

  1. In the Services portlet, click Global Settings.

    By default, the Services portlet is on the Portal subtab of the Administer tab on the Portal Builder page.

  2. Make sure you are on the Main tab.

  3. In the Maximum File Size radio group, select Limit To to specify the maximum size allowed for individual files uploaded to the portal.

  4. In the field, enter the maximum size (in MB) for each individual file uploaded to the portal. If a content contributor attempts to upload a file larger than this size, an error is displayed.

    Note:

    Select No Limit if you do not want to impose a maximum file size.

  5. Click OK.

5.3.6 Changing the Page Group Quota

You can limit the amount of space provided in your page group to store uploaded documents.

Note:

To change the page group quota, you must have at least one of the following privileges:

  • Portal administrator

  • Manage all privileges on the page group

  • Manage all global privileges on all page groups

To change the page group quota:

  1. In the Portal Navigator page, click the Page Groups tab.

  2. Click Properties next to the page group with which you want to work.

  3. In the Page Group Quota section, select Limit to to limit the amount of space provided to store uploaded documents.

  4. In the field provided, enter the size limit (in MB) for uploaded documents in the page group. When this limit is reached, users will no longer be able to upload documents to the page group.

    Note:

    Select No limit if you do not want to impose a limit for uploaded documents.

  5. Click OK.

5.3.7 Specifying E-mail (SMTP) Host

Enter the Host Name and Port of your e-mail server so that self-registered users can be informed by e-mail when their accounts are accepted or rejected. The default port for SMTP is usually 25. If you enable self-registered users to log on immediately, this information is not needed.

5.3.8 Specifying an Error Message Page

Oracle Portal enables you to choose the error message page that you want to display to users. You can choose the default system error page, or you can specify your own customized error page.

Oracle Portal includes an error message page (called Sample Error Page) that you can edit to match the look and feel of the other pages in your portal. The Sample Error Page is available under the Portal Design-Time page group and includes a portlet that displays all the diagnostic information. Alternatively, you can create your own error message page in any of your page groups. To do this, you must include the Error Message Portlet on the page and turn caching off.

Note:

By default, the Error Message Portlet is located under the Administration Portlets page of the Portlet Repository.

To specify an error message page:

  1. In the Services portlet, click Global Settings.

    By default, the Services portlet is on the Portal subtab of the Administer tab on the Portal Builder page.

  2. In the Error Page section, select one of the following:

    • System Error Page to use the system error page to display full-page error messages to users. The system error page automatically includes all the diagnostic information.

    • Error Page to use your own page to display full-page error messages to users. Click the Browse Pages icon to select the error message page that you want to use.

  3. Click OK.

5.3.9 Specifying an Error Reporting Style

Oracle Portal enables you to choose the error reporting style that you want to display to users. If you enable Secure Error Reporting, it prints only the toplevel error message. This option could be selected to avoid exposing error codes, cause and actions to the end users.

5.3.10 Setting the Default Page for Non-Authenticated Users

You can specify the default page that is displayed to users after they have logged out, or when they initially access the portal site, by setting the default home page for the PUBLIC (that is, non-authenticated) user.

Note:

You must be a portal administrator to define a default home page.

To set the default page users see when they log out, or when they initially access the site, perform the following steps:

  1. In the Portal User Profile portlet, in the Name field, enter PUBLIC.

    By default, the Portal User Profile portlet is on the Administer tab of the Portal Builder page.

  2. Click Edit.

  3. Next to the Default Home Page field, click the Browse Pages icon to see a list of pages from which to choose.

    Note:

    You cannot enter a value in this field; you must select one from the list.

  4. Click Return Object next to the page you want to be displayed when users log out.

  5. Click OK.

    Note:

    Click Reset to remove this setting.

5.3.11 Specifying the Default DOCTYPE for Pages

You can specify a global default doctype that identifies which version of HTML or XHTML it is using for all pages within your portal. Specifying the global doctype setting lets your browser display pages faster.

You identify the version of HTML or XHTML by including a doctype declaration in the code at the begining of the page, such as:

<!DOCTYPE HTML PUBLIC "-//W3C//DTD HTML 4.01 Transitional//EN" "http://www.w3.org/TR/html4/loose.dtd">

Some examples of doctypes include:

  • HTML 4.01 Compatibility mode

  • HTML 4.01 Transitional

  • HTML 4.01 Strict

  • XHTML 1.0 Transitional

  • XHTML 1.0 Strict

Note:

Specifying the doctype does not affect the generated HTML, only the DOCTYPE declaration at the beginning of the HTML.

If you select a strict doctype (for example HTML Strict) some portlet refresh features will be affected due to HTML that is prohibited when using a Strict doctype. Specifically:

  • The page assembly timeout option is not shown when editing pages.

  • Portlet refresh does not use partial page refresh, instead the whole page is refreshed.

In addition, if you choose the middle image alignment option, your HTML will not validate as Strict. This is because an align attribute has to be used in this case, rather than a CSS attribute and the align attribute does not conform to Strict guidelines.

To specify the doctype for pages in a page group:

  1. In the Services portlet, click Global Settings.

    By default, the Services portlet is on the Portal subtab of the Administer tab on the Portal Builder page.

  2. In the Page DOCTYPE section, select the DOCTYPE to be used as a default for all page groups.

  3. Check Allow Page Groups to use a different DOCTYPE to let users override this setting at the page group level, specifying a different doctype for the pages within a specific page group.

  4. Click OK.

5.3.12 Removing the Context-Sensitive Help Link

If you have access to SQL*Plus, you can suppress the Context-sensitive Help link that appears in the banner in Oracle Portal wizards, dialog boxes, alerts, and so on. Note that you cannot suppress the "?" icon that appears in the blue bar of wizards, dialog boxes, and alerts.

You cannot perform this task through the user interface; it must be done programmatically through SQL*Plus.

Note:

You must make the following API calls in both the portal schema and in the portal SSO schema.

To remove the context-sensitive help link:

  1. Access SQL*Plus.

  2. Enter:

    exec wwui_api_body.set_display_help (wwui_api_body.DISPLAY_HELP_OFF);
commit;

To reinstate the context-sensitive help link:

  1. Access SQL*Plus.

  2. Enter:

    exec wwui_api_body.set_display_help (wwui_api_body.DISPLAY_HELP_ON);
commit;

5.4 Configuring Self-Registration

To enable users to create their own portal user accounts, you must configure the self-registration feature. After completing this process, the self-registration link is exposed in the Login portlet.

You can set up an approval process for self-registered users so that they cannot log in until their accounts have been approved. When the account has been approved or rejected, the user is notified by e-mail.

If you do not require approval for self-registered users, the user will be able to log in to the portal immediately after registering.

Note:

To set up self-registration, you must be the portal administrator.

To set up self-registration:

  1. In the Services portlet, click Global Settings.

    By default, the Services portlet is on the Portal subtab of the Administer tab on the Portal Builder page.

  2. In the Self-Registration Options section, select Enable Self-Registration.

  3. Select No Approval Required if self-registered users can log on to the portal immediately after registering.

  4. Select Approval Required if self-registered users need to be approved before they can log on to the portal.

    1. Click Configure to set up the approval process.

    2. In the Approvers field, enter the names of the users or groups that must approve self-registered users.

      Note:

      Use a semicolon (;) as the separator between multiple users or groups. Each step of the approval routing can include both users and groups.

    3. For Routing Method for Approvers, choose:

      • One at a time, all must approve if you want each user or group to be notified in turn and every user or group must approve self-registered users before they can log on.

      • All at the same time, all must approve if you want all the users and groups to be notified at the same time and every user or group must approve self-register users before they can log on.

      • All at the same time, only one must approve if you want all the users and groups to be notified at the same time, but only one user or group member must approve self-registered users before they can log on.

    4. Click Add Step.

    5. Repeat steps a to d to add more steps to the approval process.

      Notes:

      • You do not need to change any other settings on this tab, or any of the settings on the other tabs in this screen.

      • The final approver in the approval chain must be privileged to approve the registration requests of users. To do this, grant the Allow account management privilege to the final approver. These privileges can be assigned on the default DAS Edit User page.

      • Each approver in the approval chain must have the My Notifications portlet on their page to see and act upon new user accounts that are waiting for approval. The My Notifications portlet can be found under Portal Content Tools in the portlet repository.

    6. Click OK to return to the Global Settings screen.

  5. Click OK.

  6. Go to the home page of your portal.

  7. Switch to Edit mode.

  8. If the home page of your portal does not already contain a Login portlet, add the Login portlet to the page.

    By default, the Login portlet can be found in the SSO/OID page under the Administration page in the Portlet Repository.

  9. Next to the Login portlet, click the Edit Defaults icon.

  10. Select Enable Self-Registration.

  11. In the Self-Registration Link Text field, enter the text that you want users to click to register with the portal.

  12. Leave the Self-Registration URL field blank to use Oracle Portal's own self-registration screen.

    If you have created your own self-registration screen, enter the URL in this field.

  13. Click OK.

5.5 Setting Up Oracle BPEL Process Definitions for Approvals

Oracle Portal includes functionality to manage and control the publishing of content on your portal through the use of approvals. However, if your organization finds that the built-in approvals functionality is somewhat restrictive, you can use Oracle BPEL workflow processes for approvals instead.

5.5.1 Synchronizing BPEL Workflow with Portal Workflow

Oracle BPEL workflow can work alongside Portal's default workflow. However, the workflow status as it changes at the BPEL end must be reflected back to the Portal workflow tables. To achieve this, a WebService is called back from BPEL which updates the Portal tables. The credentials needed to establish the connection to the Portal approval schema must be defined in datasource.xml.

5.5.1.1 Deploying the Call Back WebService

To deploy the callback webservices from BPEL:

  1. Add a new JNDI entry in the datasources.xml file located in the WLS_PORTAL. Specify the JNDI name as PortalApprovalDS.

    To add a datasource entry:

    1. Log on to the Oracle WebLogic Administration console.

    2. If you have not already done so, in the Change Center of the Administration Console, click Lock & Edit.

    3. In the Domain Structure tree, expand Services > JDBC, then select Data Sources.

    4. On the Summary of Data Source Page, click New.

    5. On the JDBC Data Source Properties page, enter jdbc/PortalApprovalDS as the name for the JDBC data source,

    6. Select Oracle as the Database Type and Oracle's Driver (Thin) Version XXXXXX as the Database Driver.

    7. Click Next to continue.

    8. On the Transactions Option page, select global transaction options and accept the default setting, then click Next.

    9. On the Connection Properties page, enter the Database Name, Host Name, Port, Database user Name (approval schema name and password, for example: <<PORTAL_SCHEMA_NAME>>_APPROVAL) and click Next.

    10. On the Test Database Connection page, review the connection parameters and click Test Configuration.

    11. On the Select Target Page, select WLS_PORTAL as the sever to deploy the data source.

      If you are using a cluster portal, you need to specify the Portal machine name to the cluster address by login to your WebLogic Administration console and selecting your Domain Name > Environment > Clusters > Cluster Address. After entering the required information you have to restart the managed server (WLS_PORTAL).

    12. Click Finish to save the JDBC data source configuration and deploy the data source to the selected targets.

  2. Deploy the WSPortalApproval.ear file, located at ORACLE_HOME\archives\applications to the managed server WLS_PORTAL using Oracle WebLogic Server Administration console.

    To deploy the application:

    1. Log on to the Oracle WebLogic Administration console.

    2. If you have not already done so, in the Change Center of the Administration Console, click Lock & Edit.

    3. In the left pane of the Console, select Deployments.

    4. In the right pane, click Install.

    5. Using the Install Application Assistant, locate the WSPortalApproval.ear file and click Next.

    6. Select the server (from the list of available servers) under which this needs to be installed ( The default server is WLS_PORTAL).

    7. Accept the default values in the next screen and click Finish. The deployment will be in Prepared state, select Start to make it Active.

  3. Navigate to DOMAIN_HOME\servers\WLS_PORTAL\tmp\_WL_user and verify that the WSPortalApproval folder is created.

  4. After the deployment ensure that the deployed web service is accessible in the following way:

    http_protocol://wls_hostname:wls_port/bpel/WSPortalApproval.

5.5.1.2 Configuring Portal for BPEL

Once the Callback Webservices is sucessfully deployed, perform the following step to enable BPEL for portal:

  1. Login to your Oracle Portal.

  2. Click the Administer tab, and then select the Portal subtab.

  3. Under Services, select Configure BPEL Callback.

    The Configure BPEL callback page is displayed.

  4. In the Callback Endpoint field, enter the callback service URL which is obtained in Step 1. For example, http_protocol://wls_hostname:wls_port/bpel/WSPortalApproval.

  5. Click OK.

5.5.2 Securing your Portal for BPEL Business Process

Oracle Portal uses secure socket layer (SSL) to secure communication with the BPEL business process which is the human workflow composite deployed on the SOA Server. Perform the following task to secure the end to end Portal BPEL communication:

For more information on Portal security, see Chapter 7, "Securing Oracle Portal".

5.5.2.1 Configuring Outbond SSL to BPEL Server

To secure communication from Portal Repository to BPEL server, perform the following steps:

5.5.2.1.1 Configuring the BPEL Business Process to use SSL

Before you start, ensure that your BPEL business process is deployed on a SOA managed server. To configure SSL perform the following task:

Enabling SOA Managed Server for SSL

To enable the SOA managed server, perform the following tasks:

  1. Login to the Oracle WebLogic Administration Console.

  2. If you have not already done so, in the Change Center of the Administration Console, click Lock & Edit.

  3. In the left pane of the Console, expand Environment and select Servers.

  4. In the Servers table, click the SOA Managed Server instance.

  5. Select SSL Listen Port Enabled, and enter the SSL Listen Port number.

Obtaining Keys and Certificates,

After you have enabled the SSL for the SOA managed server, do the following:

  1. Obtain digital certificates, private keys, and trusted CA certificates for a SOA WebLogic Managed Server using the CertGen utility, Sun Microsystem's keytool utility. Digital certificates, private keys, and trusted CA certificates can be obtained from a reputable vendor such as Entrust or Verisign by sending the certificate request created using the utilities mentioned. For testing purpose you can also use the digital certificates, private keys, and trusted CA certificates provided by the WebLogic Server kit.

  2. Store the private keys, digital certificates, and trusted CA certificates. Private keys and trusted CA certificates in a keystore assigned for SSL.

    Note:

    The preferred keystore format is JKS (Java KeyStore). Oracle WebLogic Server supports private keys and trusted CA certificates stored in files or in the WebLogic Keystore provider for the purpose of backward compatibility only.

Configuring the Identity and Trust Keystore

For configuring the identity and trust key store for the WebLogic Managed Server, you need to use the WebLogic Administration Console and perform the following steps:

  1. Login to the Oracle WebLogic Server Administration Console.

  2. If you have not already done so, in the Change Center of the Administration Console, click Lock & Edit.

  3. In the left pane of the Console, expand Environment and select Servers.

  4. Select your SOA WebLogic Managed server.

  5. Select Configuration > Keystores.

  6. In the Keystores field, select Custom Identity and Custom Trust.

  7. In the Identity section, define attributes for the identity keystore:

    1. Custom Identity Keystore: The fully qualified path to the identity keystore.

    2. Custom Identity Keystore Type: The type of the keystore.

    3. Custom Identity Keystore Passphrase: The password you will enter when reading or writing to the keystore. This attribute is optional or required depending on the type of keystore. All keystores require the passphrase in order to write to the keystore. However, some keystores do not require the passphrase to read from the keystore. WebLogic Server only reads from the keystore so whether or not you define this property depends on the requirements of the keystore.

  8. Click Save.

  9. To activate these changes, in the Change Center of the Administration Console, click Activate Changes.

After you have configured the Keystore, you need to configure it for SSL, see Servers: Configuration: SSL and Configure two-way SSL in the Oracle Fusion Middleware Oracle WebLogic Server Administration Console Help.

5.5.2.1.2 Import BPEL Server Certificates into Portal Database Wallet

After the BPEL business process is configured to use SSL, you need to make the Portal Repository communicate to the SOA server with https. To enable this communication, Portal Database wallet must store BPEL business process managed server CA trusted certificate into its truststore. Secure communication is required when the BPEL process URL is used inside Portal Repository during you registration of WSDL and Endpoint URLs for the process deployed in the BPEL server and SOAP Request to BPEL server when the item ( participating in the bpel workflow ) gets uploaded on the page.

Creating an Empty Wallet (HTTPS)

Create an empty wallet to establish the trust points for SSL access to the OracleAS Single Sign-On. To do this, perform the following steps:

  1. Open the Oracle Wallet Manager on the ORACLE_HOME. Note that you can run Oracle Wallet Manager from any location, as long as the generated wallet is accessible from the portal schema in the Oracle Metadata Repository. You can also save the wallet (the directory containing the wallet files) anywhere and move it to another location that is accessible from the portal schema in the Oracle Metadata Repository.

  2. Choose Wallet > New.

    On UNIX, the wallet is stored in the following location by default:

    /etc/ORACLE/WALLETS/<Account Name creating the Wallet>

    On Windows, the wallet is stored in the following location by default:

    \Documents And Settings\<Account Name creating the Wallet>\ORACLE\WALLETS

  3. Create a password for the wallet.

  4. Enter the same password in the Confirm Password field.

  5. Select Standard for Wallet Type.

  6. Click OK.

  7. Click Yes to accept the option to create a Certificate Request.

  8. Fill out the Certificate Request dialog with details that uniquely identify your server, and click OK. A dialog will inform you that the certificate request was created successfully. The Certificate node in the Wallet Navigator will change to Requested.

  9. Send the CR to the chosen Certificate Authority (CA).

  10. You must add the Trusted Root Certificate to the Wallet, as shown in "Adding the Trusted Root Certificate to the Wallet (HTTPS)".

  11. Save the wallet in a convenient directory, for example:

    INFRA_ORACLE_HOME\wallets

  12. Choose Wallet > Save.

Adding the Trusted Root Certificate to the Wallet (HTTPS)

Perform the steps in this section only if you do not have the trusted root certificate of the OracleAS Single Sign-On server's issuing certificate authority listed in the Trusted Certificates list. In this case, you must add the Trusted Root Certificate to the Wallet as shown in the following steps, which are based on the Internet Explorer browser:

  1. Using the browser, go to the OracleAS Single Sign-On home page, https://infra.domain.com/pls/orasso. Ensure that this is on an HTTPS URL.

    1. If the certificate on the server is not automatically trusted by your browser, the Security Alert dialog box is shown.

    2. Click View Certificate.

    3. Click the Certification Path tab.

    4. Select the Certificate Authority Root, which is the first certificate in the list.

    5. Click View Certificate.

    6. Click Install Certificate.

      This brings up the Certificate Import Wizard. This will import the certificate into the browser's list of trusted certificate authorities.

    7. Click Next.

    8. Select Automatically select a certificate store based on the type of certificate.

    9. Click Next.

    10. Click Finish.

      The trusted root certificate is installed in your browser.

  2. Click the lock icon in the status bar to bring up the Certificate dialog box.

  3. Click the Certification Path tab.

  4. Select the Certificate Authority Root, which is the first certificate in the list.

  5. Click View Certificate.

  6. Click the Details tab.

  7. Click Copy to File....

    This brings up the Certificate Export Wizard.

  8. Click Next.

  9. Under Select the format you want to use, select Base-64 encoded X.509 (.CER).

  10. Click Next and specify a file name for the certificate. You can provide any filename for the certificate with a .cer extension.

  11. Click Next and then Finish.

At this point, a .cer certificate file is created, which contains the trusted certificate authority's root certificate. This certificate must be added to the Wallet's list of Trusted Certificates. To accomplish this, assuming that the wallet manager is already running and the empty wallet has been opened, perform the following steps:

  1. Right-click the Trusted Certificates node.

  2. Select Import Trusted Certificate....

  3. Select Paste the certificate, and click OK.

  4. Copy the contents of the certificate file you created earlier into the text area for the BASE64 format certificate, and then click OK.

  5. Verify that the Certificate Authority Root has been added to the list of trusted certificates.

  6. Save the wallet.

  7. You can also set the auto login feature, check Wallet > AutoLogin, if it is not already checked. This feature enables PKI-based access to services without a password, is required for most wallets. It is required for database server and client wallets. It is only optional for products that take the wallet password at the time of startup.

Note:

If the BPEL workflow app is configured to use two-way SSL, then you have to import the DB wallet CA's (certificate authority) trusted certificate, into the truststore of soa-server).

5.5.2.2 BPEL Server Callback to Portal

The Portal Callback URL used by clients, has to be secured in the following scenarios:

  • BPEL enabling Portal (Registration of Portal Callback URL with Portal Repository)

  • Status query of Callback URL on the Global Settings Page (Portal Repository)

  • Once the approval done by the user on the BPEL server, it tries to intimate Portal Repository through the call back URL.

To secure the Portal Callback Webservice communication perform the following:

5.5.2.2.1 Configuring Portal Callback Webservices for 2-Way SSL

To configure Portal Webservices

  1. If you have not deployed WSPortalApproval.ear, you need to deploy it to your WLS_PORTAL managed server as explained in Section 5.5.1.1, "Deploying the Call Back WebService".

  2. Enable SSL for WSPortalApproval.ear in your managed server (WLS_PORTAL), do the following:

    • Login to the Oracle WebLogic Administration Console.

    • If you have not already done so, in the Change Center of the Administration Console, click Lock & Edit.

    • In the left pane of the Console, expand Environment and select Servers.

    • In the Servers table, click the WLS_Portal Managed Server instance.

    • Select SSL Listen Port Enabled, and enter the SSL Listen Port number.

  3. Obtain the identity and trust Keystore for the Portal manged server (WLS_Portal) (See, Configuring the Identity and Trust Keystore).

  4. Configure the Keystore for SSL, see Servers: Configuration: SSL and Configure two-way SSL in the Oracle Fusion Middleware Oracle WebLogic Server Administration Console Help.

5.5.2.2.2 Configuring the Oracle BPEL Process for Identity and Trust Keystore

For configuring the identity and trust keystore, do the following:

  1. Deploy the Oracle BPEL processes on your SOA managed server (soa_server).

  2. Obtain the identity and trust Keystore for the SOA manged server (See, Configuring the Identity and Trust Keystore).

5.5.2.2.3 Configuring Portal Database for Identity and Trust Keystore

You need to create a Wallet, to store your identity and trust keystore, see Creating an Empty Wallet (HTTPS) and Adding the Trusted Root Certificate to the Wallet (HTTPS)

5.5.2.2.4 Enabling BPEL Business Process for Authentication with Portal Callback Webservice

The BPEL Business Process requires to present its identity for authentication with the Portal managed server ( configured for two-way SSL). For this use your Keytool's export and import commands to perform the following:

  • Export the SOA managed server's CA trusted certificate to a text file in BASE 64 encoded format (soa_server_trusted.cer).

  • Export the Portal managed server CA's trusted certificate to a text file in BASE 64 encoded format (portal_server_trusted.cer>.

  • Import the SOA managed CA's (certificate authority) trusted certificate (soa_server_trusted.cer), into the truststore of Portal Managed Server.

  • Import the Portal wallet CA's (certificate authority) trusted certificate (portal_server_trusted.cer), into the truststore of Portal Managed Server.

5.5.2.2.5 Enabling Portal Repository Client for Authentication with Portal Callback Webservice

The Portal managed server which is configured as two-way SSL, it needs the wallet to present its identity for authentication, for this do the following:

  • Export the wallet CA's trusted certificate to a text file in BASE 64 encoded format. (for exporting from the wallet, you can use Oracle Wallet Manager or orapki utility)

  • Import the Portal wallet CA's (certificate authority) trusted certificate (exported into a file in the previous step), into the truststore of Portal Managed Server.

  • Import the Portal wallet CA's (certificate authority) trusted certificate (portal_server_trusted.cer), into the truststore of Portal DB Wallet.

5.5.2.2.6 Registering the Database Wallet to the Portal Preference Store

If your Portal Repository is not registered to use a database wallet, then you need to register it by running secwc.sqlscript, located at ORACLE_HOME\portal\admin\plsql\wwc)

Example 5-1 Registering the Wallet

cd $ORACLE_HOME/portal/admin/plsql/wwc sqlplus <portal_schema/<portal_pwd>@connectstring sql> @secwc.sql <wallet_location>, <wallet_pwd>sql> @secwc.sql 'file:/u01/app/oracle/product/1021_prodee/dbwallet', 'welcome1'

5.5.3 Creating a New BPEL Process Definition

Before page group administrators and page owners can use Oracle BPEL workflow processes for approvals, you first need to create a process definition that points to those workflow processes.

Note:

This assumes that the Oracle BPEL processes have already been created and deployed.

  1. In the Services portlet, click BPEL Process Definition Settings.

    By default, the Services portlet is on the Portal subtab of the Administer tab on the Portal Builder page.

  2. Click Create New BPEL Process Definition.

  3. In the Process Name field, enter the name of the Oracle BPEL process.

    Page group administrators and page designers use this name to identify the process when selecting which process to use for their page group or page. The name should be the same as the name used to identify the process in Oracle BPEL and should not contain any spaces or special characters.

  4. In the Description field, enter a description of the behavior of the Oracle BPEL process.

    While this field is optional, providing a description will greatly aid page group administrators and page designers when they are selecting a process to use for their page group or page. The description can contain up to 4000 characters and can include spaces but not special characters.

  5. In the Process Deployment Location field, enter the URL where the Oracle BPEL process is deployed. This is also known as the endpoint. You can obtain this endpoint from the process deployed in the SOA server.

    If this URL is not accessible directly from Oracle Portal, make sure you have set up the global proxy definition. See Section 6.5, "Configuring Oracle Portal to Use a Proxy Server."

  6. In the Process WSDL Location field, enter the URL to the Oracle BPEL process's description document, or .wsdl file. Oracle Portal must have read permissions on this .wsdl file.

    If this URL is not accessible directly from Oracle Portal, make sure you have set up the global proxy definition. See Section 6.5, "Configuring Oracle Portal to Use a Proxy Server."

  7. In the Process Operation field, enter the name of the operation that Oracle Portal should trigger when this Oracle BPEL process definition is called. The WSDL document should describe this operation.

  8. Click OK to create the Oracle BPEL Process Definition.

  9. A confirmation screen lets you know whether the definition was created successfully. If the definition was not created successfully, check the settings and try again.

    If your BPEL process definition was created successfully, click Close.

5.5.4 Editing an Existing BPEL Process Definition

You can edit an existing BPEL process definition if there are no items involved in the workflow. The business process will be locked if there any items in it.

  1. In the Services portlet, click BPEL Process Definition Settings.

    By default, the Services portlet is on the Portal subtab of the Administer tab on the Portal Builder page.

  2. Click the name of the BPEL process definition that you want to edit.

  3. Edit the fields as required. For information about these fields, see Section 5.5.3, "Creating a New BPEL Process Definition."

    Note:

    You cannot edit the Process Name field.

  4. Click OK to save your changes.

  5. A confirmation screen lets you know whether the changes you made were successful. If the changes were not successful, check the settings and try again.

    If your changes were successful, click Close.

5.5.5 Deleting an Existing BPEL Process Definition

You can delete an existing BPEL process definition if required.

  1. In the Services portlet, click BPEL Process Definition Settings.

    By default, the Services portlet is on the Portal subtab of the Administer tab on the Portal Builder page.

  2. In the table, click the delete icon next to the BPEL process definition that you want to delete.

  3. Check the details to make sure that this is the BPEL process definition that you want to delete.

  4. Click Delete to continue with the operation, or Cancel if you have changed your mind.

  5. Click Close.

5.5.6 Oracle Portal Message Schema

Oracle Portal initiates any Oracle BPEL workflow process through a SOAP message over HTTP. It also sends payload information including the URL of the item so that approvers can view it.

Example 5-2 shows a sample Oracle Portal message schema to illustrate the kind of information included in the message payload. The designer of the Oracle BPEL workflow process should use this information when creating the process (.XSD) file.

Example 5-2 Sample Oracle Portal Message Schema

<complexType>
          <sequence>
              <element name="title" type="string"/>
              <element name="payload">
                <complexType>
                  <sequence>
                   <element name="itemType" type="string"/>
                   <element name="url" type="string"/>
                   <element name="status" type="string"/>
                   <element name="date" type="string"/>
                   <element name="Originator" type="string"/>
                   <element name="description" type="string"/>
                   <element name="pageName" type="string"/>
                   <element name="pageDisplayName" type="string"/>
                   <element name="pageGroupName" type="string"/>
                   <element name="subject" type="string"/>                       
                   <element name="itemVersion" type="string"/>
                   <element name="itemExpiry" type="string"/>
                   <element name="itemDisplayOption" type="string"/>                                                          
                   <element name="author" type="string"/>
                   <element name="defaultLanguage" type="string"/>
                  </sequence>
                </complexType>
              </element>
              <element name="itemId" type="integer"/>
              <element name="pageId" type="integer"/>
              <element name="siteId" type="integer"/>
              <element name="submitter" type="string"/>
              <element name="approvalId" type="integer"/>
              <element name="instanceId" type="integer"/>
              <element name="portalWSUrl" type="string"/>
              <element name="content_manager">
               <complexType>
                <sequence>
                 <element name="userCount" type="integer"/>
                 <element name="users" type="string" minOccurs="0" maxOccurs="10"/>
                </sequence>
               </complexType>
              </element>
              <element name="page_manager">
               <complexType>
                <sequence>
                 <element name="userCount" type="integer"/>
                 <element name="users" type="string" minOccurs="0" maxOccurs="10"/>
                </sequence>
               </complexType>
              </element>     
              <element name="page_group_manager">
               <complexType>
                <sequence>
                 <element name="userCount" type="integer"/>
                 <element name="users" type="string"/>
                 <element name="groupCount" type="integer"/>
                 <element name="groups" type="string"/>
                </sequence>
               </complexType>
              </element>           
          </sequence>
        </complexType>

Table 5-4 describes the different elements in the message payload.

Table 5-4 Message Payload Details

Element Description

title

The display name of the item

itemType

The item type of the item, for example, text, file, url

url

The URL that points to the item

status

The status of the item

date

The date when the item was submitted

Originator

The creator of the item.

description

The description of the item.

pageName

The internal name of the page containing the item

pageDisplayName

The title of the page containing the item

pageGroupName

The name of the page group that owns the page containing the item.

subject

Information sent by Oracle Portal to Oracle BPEL to explain why the message is being sent

itemVersion

The version number of the item

itemExpiry

The expiry date of the item

itemDisplayOption

The display option for the item

author

The name of the author as specified by the user who submitted the item

defaultLanguage

The default language of the portal

itemId

Internally generated ID for the item

pageId

Internally generated ID for the page

siteId

Internally generated ID for the page group

submitter

The user who submitted the item

approvalId

  

instanceId

The instance ID through which the item was added

content_manager

List of users with Manage Content privileges on the page containing the item. Use this to extract the specific user names of users with these privileges to use them as approvers in the Oracle BPEL workflow process.

page_manager

List of users with Manage privileges on the page containing the item. Use this to extract the specific user names of users with these privileges to use them as approvers in the Oracle BPEL workflow process.

page_group_manager

List of users with Manage All privileges on the page group that owns the page containing the item. Use this to extract the specific user names of users with these privileges to use them as approvers in the Oracle BPEL workflow process.

5.5.7 BPEL Callback Webservice Proxy

Oracle Portal requires any Oracle BPEL workflow process to add a callback service before you deploy the business process.

Example 5-3 and Example 5-4, shows a sample callback proxy service to illustrate a Reject or Approval step. The designer of the Oracle BPEL workflow process can use this information when creating the process.

Example 5-3 Reject Callback Webservice

try                 
{                 
    portalwsproxy.proxy.WSPortalApprovalSoapHttpPortClient client =                    
    new portalwsproxy.proxy.WSPortalApprovalSoapHttpPortClient();       
                  
    oracle.xml.parser.v2.XMLElement elm ;       
    elm = (oracle.xml.parser.v2.XMLElement)getVariableData("inputVariable","payload","/client:process/client:portalWSUrl");
    org.w3c.dom.Node node = (org.w3c.dom.Node) elm.getFirstChild();       
    String portalWSUrl = node.getNodeValue();       
    System.out.println("portalWSUrl = " + portalWSUrl);       
    client.setEndpoint(portalWSUrl);       
 
    elm = (oracle.xml.parser.v2.XMLElement)getVariableData("inputVariable","payload","/client:process/client:itemId");       
    node = (org.w3c.dom.Node) elm.getFirstChild();       
       
    System.out.println("Itemid = " + node.getNodeValue());       
    java.math.BigDecimal itemId = new java.math.BigDecimal(node.getNodeValue());       
       
    elm = (oracle.xml.parser.v2.XMLElement)getVariableData("inputVariable","payload","/client:process/client:pageId");       
    node = (org.w3c.dom.Node) elm.getFirstChild();       
       
    System.out.println("Pageid = " + node.getNodeValue());       
    java.math.BigDecimal pageId = new java.math.BigDecimal(node.getNodeValue());       
       
    elm = (oracle.xml.parser.v2.XMLElement)getVariableData("inputVariable","payload","/client:process/client:siteId");       
    node = (org.w3c.dom.Node) elm.getFirstChild();       
       
    System.out.println("Siteid = " + node.getNodeValue());       
    java.math.BigDecimal siteId = new java.math.BigDecimal(node.getNodeValue());       
       
    elm = (oracle.xml.parser.v2.XMLElement)getVariableData("inputVariable","payload","/client:process/client:approvalId");       
    node = (org.w3c.dom.Node) elm.getFirstChild();       
       
    System.out.println("approvalId = " + node.getNodeValue());       
    java.math.BigDecimal approvalId = new java.math.BigDecimal(node.getNodeValue());       
       
    elm = (oracle.xml.parser.v2.XMLElement)getVariableData("inputVariable","payload","/client:process/client:instanceId");       
    node = (org.w3c.dom.Node) elm.getFirstChild();       
       
    System.out.println("instanceId = " + node.getNodeValue());       
    java.math.BigDecimal instanceId = new java.math.BigDecimal(node.getNodeValue());       
       
    client.reject(itemId,pageId,siteId,instanceId,approvalId);     
}       
catch(java.rmi.RemoteException remoteException)            
{            
    System.out.println("REJECT  "+remoteException); 
    System.out.println("An exception occured while trying " +                  
        " connect to portal");                 
    remoteException.printStackTrace();            
}            
catch(Exception exception)                 
{                 
    System.out.println("REJECT_OTHERS "+ exception);       
    exception.printStackTrace();           
}

Example 5-4 Approve Callback Webservice

try                 
{                 
    portalwsproxy.proxy.WSPortalApprovalSoapHttpPortClient client =                    
    new portalwsproxy.proxy.WSPortalApprovalSoapHttpPortClient();                      
                   
    System.out.println("INSIDE THE APPROVE section");  
    oracle.xml.parser.v2.XMLElement elm ;       
      
    elm = (oracle.xml.parser.v2.XMLElement)getVariableData("inputVariable","payload","/client:process/client:portalWSUrl");       
    org.w3c.dom.Node node = (org.w3c.dom.Node) elm.getFirstChild();       
    String portalWSUrl = node.getNodeValue();       
    System.out.println("portalWSUrl = " + portalWSUrl);       
    client.setEndpoint(portalWSUrl);       
      
    elm = (oracle.xml.parser.v2.XMLElement)getVariableData("inputVariable","payload","/client:process/client:submitter");       
    node = (org.w3c.dom.Node) elm.getFirstChild();       
    System.out.println("submitter = " + node.getNodeValue());       
    String submitter = new String(node.getNodeValue());       
      
    elm = (oracle.xml.parser.v2.XMLElement)getVariableData("inputVariable","payload","/client:process/client:itemId");       
    node = (org.w3c.dom.Node) elm.getFirstChild();       
 
    System.out.println("Itemid = " + node.getNodeValue());       
    java.math.BigDecimal itemId = new java.math.BigDecimal(node.getNodeValue());       
       
    elm = (oracle.xml.parser.v2.XMLElement)getVariableData("inputVariable","payload","/client:process/client:pageId");       
    node = (org.w3c.dom.Node) elm.getFirstChild();       
    System.out.println("pageid = " + node.getNodeValue());       
    java.math.BigDecimal pageId = new java.math.BigDecimal(node.getNodeValue());       
       
    elm = (oracle.xml.parser.v2.XMLElement)getVariableData("inputVariable","payload","/client:process/client:siteId");       
    node = (org.w3c.dom.Node) elm.getFirstChild();       
    System.out.println("Siteid = " + node.getNodeValue());       
    java.math.BigDecimal siteId = new java.math.BigDecimal(node.getNodeValue());       
       
    elm = (oracle.xml.parser.v2.XMLElement)getVariableData("inputVariable","payload","/client:process/client:approvalId");       
    node = (org.w3c.dom.Node) elm.getFirstChild();       
    System.out.println("approvalid = " + node.getNodeValue());       
    java.math.BigDecimal approvalId = new java.math.BigDecimal(node.getNodeValue());       
       
    elm = (oracle.xml.parser.v2.XMLElement)getVariableData("inputVariable","payload","/client:process/client:instanceId");       
    node = (org.w3c.dom.Node) elm.getFirstChild();       
    System.out.println("instanceid = " + node.getNodeValue());       
    java.math.BigDecimal instanceId = new java.math.BigDecimal(node.getNodeValue());       
       
    client.approve(itemId,pageId,siteId,submitter,instanceId,approvalId);       
}       
catch(java.rmi.RemoteException remoteException)            
{            
    System.out.println("INSIDE APPROVE  " + remoteException);         
    System.out.println("An exception occured while trying " +                  
        " connect to portal");                 
    remoteException.printStackTrace();            
}            
        catch(Exception exception)                 
{                 
    System.out.println("INSIDE APPROVE WHEN_OTHERS " + exception);         
    exception.printStackTrace();           
}

5.6 Performing Basic Portal Administration

This section covers the following topics:

5.6.1 Simplifying the Full URL of an Oracle Portal Instance

You can simplify the full URL created by the Oracle Portal installation to a more memorable or meaningful URL using the Redirect directive. In this way, end users can access Oracle Portal by entering a simple URL.

By default, the URL for a new Oracle Portal installation requires you to enter:

http://<host>:<port>/portal/pls/<dad>

You can simplify this URL to:

http://<host>/<redirectpath>

Note:

Do not simplify the Oracle Portal URL to http://<host>:<port>/portal. This is because Oracle Portal is already mounted on /portal.

  1. Open the Oracle HTTP Server configuration file, httpd.conf, which is located in the following directory:

    ORACLE_INSTANCE\config\OHS\ohs1

  2. Enter the redirect path as follows:

    Redirect /<redirectpath> http://<host>:<port>/portal/pls/<dad>

    For example:

    Redirect /portalhome http://mysite.oracle.com/portal/pls/portal

    In this example, end users can enter:

    http://mysite.oracle.com/portalhome

    to access the full URL, which is:

    http://mysite.oracle.com/portal/pls/portal

    Notes:

    • The example http://mysite.oracle.com/portalhome assumes that the default port is being used. If the default port is not being used, then the user would have to enter the URL with the port number, http://mysite.oracle.com:<port>/portalhome.

    • You can also edit the httpd.conf file using the Oracle Enterprise Manager 11g Fusion Middleware Control. After you edit the httpd.conf file you can restart the Oracle HTTP Server using the Oracle Enterprise Manager 11g Fusion Middleware Control.

  3. Restart the HTTP server by executing the following command from ORACLE_INSTANCE\bin\opmnctl:

    opmnctl restartproc type=ohs

    You can also restart HTTP server by using the Oracle Enterprise Manager 11g Fusion Middleware Control.

5.6.2 Configuring Oracle HTTP Server to Use the Oracle Portal Home Page

To set the Oracle Portal home page as the Oracle HTTP Server's default home page:

  1. In the directory ORACLE_INSTANCE\config\OHS\ohs1\htdocs, make a backup copy of the files welcome-index.html and welcome-index.html.<lang>, where <lang> is the language code. For example, welcome-index.html.en is the index HTML file for English.

  2. Edit welcome-index.html.<lang> by replacing the entire contents of the file with the following HTML redirection code:

    <HTML>
<SCRIPT LANGUAGE=JavaScript>
document.location="http://<host>.<domain>:<port>/portal/pls/<dad>"
</SCRIPT>
</HTML>

    Notes:

    • Do not specify a port number if you are running Oracle Portal on port 80 or 443.You will need to specify a port number if you are running Oracle Portal on port 8090.

    • If you plan to support other languages, you need to have the language-specific index HTML files with the redirection code, for these languages.

5.6.3 Stopping and Starting Portal Components Using Fusion Middleware Control

Portal components typically need to be restarted following a configuration change.

Follow the steps below to stop, start, or restart a component using Fusion Middleware Control:

  1. Navigate to the Fusion Middleware Control instance for the appropriate farm.

    See "Accessing Oracle Enterprise Manager 11g Fusion Middleware Control" for more information.

  2. Navigate to the home page for your Oracle Portal instance.

    See Section 8.2, "Using Fusion Middleware Control to Monitor and Administer Oracle Portal" for more information.

  3. Locate the Related Components portlet.

  4. In the Name column of the Related Components portlet, click on the component to start or stop.

  5. From the component menu, select Control.

  6. Do one of the following:

    • Click Stop to stop the component.

    • Click Start to start the component.

5.6.4 Configuring a Portal DAD Using Fusion Middleware Control

A Database Access Descriptor (DAD) is a set of values that specify how an application connects to an Oracle Database to fulfill an HTTP request. The information in the DAD includes the user name (which also specifies the schema and the privileges), password, connect-string, and Globalization Support language of the database.

There are two types of DADs: general DADs and portal DADs. An Oracle Portal middle tier uses a portal DAD to access the Oracle Metadata Repository, and this section describes how you can create, edit, or delete a Portal DAD. For information on general DADs, refer to the Oracle Fusion Middleware Administrator's Guide for Oracle HTTP Server.

Creating a Portal DAD

A Portal DAD is automatically created when Oracle Portal is installed. However, should it be necessary, you can create a DAD manually using Fusion Middleware Control.

Note:

Oracle Portal provides support for only one Portal DAD per Portal instance; you cannot create a new DAD if there is a pre-existing DAD for the instance.

Follow the steps below to create a new Portal DAD :

  1. Navigate to the Fusion Middleware Control instance for the appropriate farm.

    See Section 8.1, "Using Oracle Enterprise Manager 11g Fusion Middleware Control" for more information.

  2. Navigate to the home page for your Oracle Portal instance.

    See Section 8.2, "Using Fusion Middleware Control to Monitor and Administer Oracle Portal" for more information.

  3. From the Portal menu, select Settings > Database Access Descriptor.

  4. Click Add and complete the parameters for the new Portal DAD. Refer to Table 8-1, "DAD Settings" for a description of all the options on this page.

  5. Click OK.

  6. Restart the Oracle HTTP Server and the managed server (WLS_PORTAL).

    Refer to Section 5.6.3, "Stopping and Starting Portal Components Using Fusion Middleware Control" for information on restarting the Oracle HTTP Server and WLS_Portal components.

Editing a Portal DAD

Follow the steps below to edit a Portal DAD using Fusion Middleware Control:

  1. Navigate to the Fusion Middleware Control instance for the appropriate farm.

    See Section 8.1, "Using Oracle Enterprise Manager 11g Fusion Middleware Control" for more information.

  2. Navigate to the home page for your Oracle Portal instance.

    See Section 8.2, "Using Fusion Middleware Control to Monitor and Administer Oracle Portal" for more information.

  3. From the Portal menu, select Settings > Database Access Descriptor.

  4. Select the DAD and click Edit. Edit the DAD parameters for this Oracle Portal instance as required. Refer to Table 8-1, "DAD Settings" for a description of all the options on this page.

  5. Click OK.

  6. Restart the Oracle HTTP Server and the managed server (WLS_PORTAL).

    Refer to Section 5.6.3, "Stopping and Starting Portal Components Using Fusion Middleware Control" for information on restarting the Oracle HTTP Server and WLS_Portal components.

Deleting a Portal DAD

Follow the steps below to delete a Portal DAD using Fusion Middleware Control:

Note:

Do not delete the default Portal DAD. If the default Portal DAD is deleted, then Oracle Portal stops working.

  1. Navigate to the Fusion Middleware Control instance for the appropriate farm.

    See Section 8.1, "Using Oracle Enterprise Manager 11g Fusion Middleware Control" for more information.

  2. Navigate to the home page for your Oracle Portal instance.

    See Section 8.2, "Using Fusion Middleware Control to Monitor and Administer Oracle Portal" for more information.

  3. From the Portal menu, select Settings > Database Access Descriptor.

  4. Select the DAD and click Delete.

  5. Click OK.

  6. Restart the Oracle HTTP Server and the managed server (WLS_PORTAL).

    Refer to Section 5.6.3, "Stopping and Starting Portal Components Using Fusion Middleware Control" for information on restarting the Oracle HTTP Server and WLS_Portal components.

5.6.5 Configuring a Portal DAD Using WLST

Follow the instructions below to create, list, update, or delete a Portal DAD from the WLST command-line scripting interface. Refer to Section 5.1.2.2, "WebLogic ScriptingTool (WLST) Command-line Utility" for more information about using the WLST.

Use the Database Access Descriptor commands listed in Table 5-5 to create, list, update, or delete a Portal DAD from the WLST command-line scripting interface. Based on your actions, the portal_dads.conf file located at DOMAIN_HOME\config\fmwconfig\servers\WLS_PORTAL\applications\portal\configuration is updated.

Table 5-5 Database Access Descriptor Commands for Portal WLST Configuration

Use this command... To... Use with WLST...

Creating a Portal DAD

Create a Portal Database Access Descriptor.

Online
     

Updating Portal Dad

Update the attributes of a Portal Database Access Descriptor.

Online

Deleting Portal DAD

Delete a Portal Database Access Descriptor.

Online

listing a DAD

List the parameters used by the Database Access Descriptors for configuration.

Online

5.6.5.1 Creating a Portal DAD

A Portal DAD is automatically created when Oracle Portal is installed. To create a Portal DAD manually, use the following WLST(online) command:

createPortalDad (name, schema, password, [connect_string], nls_language)
Argument Definition 
name
Name of the Database Access Descriptor. 
schema
The Portal database account user name. 
password
The Portal database account password. 
connect_string
Optional. The connection string used to connect to a remote database.

Connect string may be host name: port number: connect string. The connect string format may be ServiceNameFormat (host:port:database_service_name), SIDFormat (host:port:database_sid), or TNSFormat (TNS alias or the whole TNS entry).

 
nls_language
The globalization support language of the Portal database that is represented by this DAD. This setting overrides the NLS_LANG environment variable for a database session and defines some important globalization support properties of the response, including the response character set.

Make sure that this language setting matches the NLS_LANG of the back-end database.

Example 5-5 Creating a Portal DAD

createPortalDad(name='portal1',schema='schema',password='welcome1',connect_string='foo.oracle.com:1521:orcl',nls_language='AMERICAN_AMERICA.AL32UTF8')

Note:

Oracle Portal provides support for only one Portal DAD per Portal instance; you cannot create a new DAD if there is a pre-existing DAD for the instance.

5.6.5.2 Updating Portal Dad

To update the attributes of the Portal DAD use the following WLST(online) command:

updatePortalDad (name, [schema], [password], [connect_string], [nls_language])
Argument Definition 
name
Name of the Database Access Descriptor. This name cannot be changed during update. 
schema
Optional. The Portal database account user name. 
password
Optional. The Portal database account password. 
connect_string
Optional. The connection string used to connect to a remote database.

Connect string may be host name: port number: connect string. The connect string format may be ServiceNameFormat (host:port:database_service_name), SIDFormat (host:port:database_sid), or TNSFormat (TNS alias or the whole TNS entry).

 
nls_language
Optional. The globalization support language of the Portal database that is represented by this DAD. This setting overrides the NLS_LANG environment variable for a database session and defines some important Globalization Support properties of the response, including the response character set. Make sure that this language setting matches the NLS_LANG of the back-end database.

Example 5-6 Updating the Portal DAD Attributes

updatePortalDad(name='portal1',schema='user1',password='welcome2',connect_string='foo.oracle.com:1521:orcl',nls_language='AMERICAN_AMERICA.AL32UTF8')

5.6.5.3 Deleting Portal DAD

To delete the Portal DAD use the following WLST(online) command:

deletePortalDad(name)
Argument Definition 
name
Name of the Portal Database Access Descriptor.

Example 5-7 Deleting the Portal DAD Entry from the Portal_dads.conf File

deletePortalDad(name='portal1')

5.6.5.4 listing a DAD

To list the parameters specified in all the DAD (both general DADs and Portal DADs), use the following WLST(online):

listDads ()

Example 5-8 Listing the Various DADs in the domain

listDads()
------------
/pls/portal1
Schema: h1user
Connect String: foo.oracle.com:1521:orcl
NLS Language: "AMERICAN_AMERICA.AL32UTF8"

5.6.6 Configuring the Portal Cache Using Fusion Middleware Control

Portal cache is a file system-based cache for Oracle Portal pages and portlets. See Section 1.3.2, "Understanding Portal Cache" for more information.

Follow the steps below to configure the Portal cache using Fusion Middleware Control:

  1. Navigate to the Fusion Middleware Control instance for the appropriate farm.

    See Section 8.1, "Using Oracle Enterprise Manager 11g Fusion Middleware Control" for more information.

  2. Navigate to the home page for your Oracle Portal instance.

    See Section 8.2, "Using Fusion Middleware Control to Monitor and Administer Oracle Portal" for more information.

  3. From the Portal menu, select Settings > Portal Cache.

  4. Ensure that the Caching option is set to On.

  5. Edit the cache settings for the Oracle Portal instance as required. Table 8-2, "Portal Cache Settings" has a description of all the options on this page.

  6. Click Apply.

  7. Restart the managed server (WLS_PORTAL).

    Refer to Section 5.6.3, "Stopping and Starting Portal Components Using Fusion Middleware Control" for information on restarting the WLS_Portal components.

5.6.7 Configuring the Portal Cache Using WLST

The WLST(online) command update the attributes of the Portal cache.

TheSE configuration details are maintained in the DOMAIN_HOME\config\fmwconfig\servers\WLS_PORTAL\applications\portal\configuration\portal_cache.conf file.

To update the attributes of the Portal Cache, use:

configurePortalCache(enable, directory, total_size, max_size, cleanup_time, max_age)
Argument Definition 
enable
Enables (On) or disables (Off) portal content and session caching. 
directory
The directory where cached content is stored.

Make sure that this directory exists and has read-write access.

 
total_size
The total amount of disk space (in megabytes) that the Portal cache may use. The maximum value allowed is 4 GB. 
max_size
The maximum size (in bytes) for all cached files. The maximum value allowed is 4 GB.Any dynamically generated content that exceeds this limit is not cached. 
cleanup_time
The time at which to start the cleanup of the cache storage. Use the [Sunday-Saturday, Everyday, Everymonth][hh:mm] format to define the exact day and time in which cleanup should occur. 
max_age
Maximum age of a single cached document. This setting ensures the cache system does not contain any old content. Old cache files are removed to make space for new cache files. The default is 30 days.

Example 5-9 Configuring the Portal Cache

configurePortalCache(enable=true,directory='/scratch/user/installs/Inst_1/cache/PortalComponent/portal',total_size=10101010,max_size=12300033,cleanup_time='Everyday 11:00',max_age=20)

5.6.8 Clearing the Portal Cache

Sometimes you must clear the entire portal cache (the Oracle Portal file system-based cache). For example, when you change the character set of the Oracle Metadata Repository, you will need to clear the entire portal cache as the existing content will use the older character set.

To clear the portal cache:

  1. Navigate to the portal cache directory. The default path is ORACLE_INSTANCE\portal\cache.

  2. Perform a recursive delete of all the files under this directory. For example, on UNIX platforms, issue the following command:

    rm -rf *

    Notes:

    WARNING:

    Ensure that you are in the correct directory before issuing this command. Do not delete the cache directory.

5.6.9 Configuring the Portal Parallel Page Engine

The Oracle Portal architecture is designed around a three-tier architecture that allows any browser to connect to it. This flexible architecture allows each component (browser, Oracle HTTP Server listener, Oracle Database 11g, and Oracle Portal) to be upgraded individually as required.

A part of the Oracle Portal middle tier, the Parallel Page Engine (PPE) is a servlet that runs under Oracle WebLogic Server and services page requests. The PPE reads page metadata, calls providers for portlet content, accepts provider responses, and assembles the requested page in the specified page layout.

5.6.9.1 Setting PPE Configuration Parameters

All servlets are installed under WLS_PORTAL, based upon the application deployment. The configuration parameters for PPE are entered in the appConfig.xml file, that is, in the </portal-midtier> and the configuration parameter under it. In the default installation, this file can be found at the following location:

DOMAIN_HOME\config\fmwconfig\servers\WLS_PORTAL\applications\portal\configuration

The providerHeaders parameter (see Table 5-7) for PPE is entered in the web.xml file, this file can be found at the following location:

DOMAIN_HOME\servers\WLS_PORTAL\tmp\_WL_user\portal\uh04o6\war\WEB-INF

PPE Parameters

Table 5-6 describes each of the different configuration parameters available for use with the PPE. Each parameter affects the operation of the PPE in a different manner. Some are simply for logging, while others can affect the performance of the engine or Oracle Portal itself. In most cases, the default values should be sufficient; however, there may be configurations where this is not the case. Each parameter is described with its syntax, description, and default.

Table 5-6 Parallel Page Engine (PPE) Parameters

PPE Setting Syntax Description Default Value

x509certfile

 
<x509certfile>c:\certificates\trustedcerts.txt</x509certfile>

Specifies a file containing a list of certificates to be implicitly trusted by HTTPClient. These certificates are added as trust points to all connections made by HTTPClient using SSL. Once this setting is in use, all SSL connections must be trusted. Otherwise, HTTPClient will throw an exception in the PPE.

Note that SSL connections are made from the PPE for two reasons, and this configuration affects both:

  • loopback requests to the portal, for example, for PMD.

  • show calls to Providers.

Note that the file specified here can be obtained from a wallet by exporting all trusted certificates, but the comments in the resultant file must be removed. Alternatively, it can be created manually.

trust points not used

versionOnSplashScreen

 
<versionOnSplashScreen>false</versionOnSplashScreen>

Indicates whether the PPE must display version information on the splash screen.

false

useScheme

 
<useScheme>http</useScheme>

Overrides the scheme (http or https) used when the PPE makes requests to the portal. The default, if not specified, is to always use the page request scheme. Note that if you set the useScheme parameter then you must set the usePort parameters.

You need to specify these in scenarios where public access is through https on port A, and you want to set PPE requests to use a faster http connection on port B.

Use page request scheme

usePort

 
<usePort>8888</usePort>

Overrides the port used when the PPE makes requests to the portal. The default, if not specified, is to always use the page request port.

You need to specify these in scenarios where public access is through https on port A, and you want to set PPE requests to use a faster http connection on port B.

Use page request port

useDeviceNameCacheKeys

 
<useDeviceNameCacheKeys>false</useDeviceNameCacheKeys>

This key is used to specify whether the mobile device name or device class must be used while building cache keys. The default is for the device class to be used.

If set to true, then the device name is used to build cache keys.

false

urlDebugUsers

 
<urlDebugUsers>fred,bill,ben</urlDebugUsers>

This is specified to indicate the list of users allowed to use the _debug URL parameter, subject to the value restriction in the urlDebugMode parameter. If this is not specified, all users can use it subject to the value restriction.

The format is a comma-delimited list of portal user names, with leading and trailing spaces being ignored.

none required

urlDebugMode

 
<urlDebugMode>1</urlDebugMode>

Specifies the highest value of the _debug URL parameter that the PPE should honor. Possible values for _debug are:

none, 0, 1, 2, 3, 4, and 5

If a value higher than that allowed is received by the PPE, it is reduced to the highest value permitted, or ignored if no value is allowed.

The values build incrementally. For example, at debug value 2, values for debug level 1 and 0 are also recorded.

1

stall

 
<stall>65</stall>

If the response headers are returned, but the data itself lags behind, then a stall comes into affect. This value keeps the PPE from holding on to connections forever. Once the response headers are received, the PPE makes every effort to wait as long as is feasible to retrieve all of the data. Set this value appropriately if the portlets being requested are large, or running over a slow network.

Note that the upper limit of this parameter should be set to a response time acceptable by a Web user (typically a few seconds).

65 sec

showPageDebug

 
<showPageDebug>false</showPageDebug>

If you set showPageDebug to true, the Page timing information is shown on every request.

Refer to Section B.6, "Timing and Caching Statistics" for a description of the timing and caching statistics.

false

showError

 
<showError>true</showError>

When a portlet times out, or something within the PPE goes wrong with a particular portlet request, an error is displayed to the user. The messages tend to be generic, but do give the user some information and an indication that the page did not display as expected. If you set this to false, no messages are displayed to the user.

true

resourceUrlKey

 
<resourceUrlKey>KEY</resourceUrlKey>

This key is used by the PPE to calculate checksums for URLs that are requested by WSRP and JPDK resource proxying.

If you are using JPDK proxying, a JNDI environment variable, also called resourceUrlKey, must be set for the provider.

none

requestTime

 
<requestTime>30</requestTime>

This is the default time out assigned to portlet requests that do not have their own time out value specified. It is applied as the amount of time (in seconds) allowed before response headers are returned by the server. Time outs are weighted by where they originate. If the portlet sets its own time out value, then that is the time out that is used. If no portlet time out is available, then the provider registration time out is used. If neither of these is present, then the requestTime is used.

Note that the upper limit of this parameter should be set to a response time acceptable by a Web user (typically a few seconds).

30 sec

queueTimeout

 
<queueTimeout>10</queueTimeout>

The amount of time a request should stay in the queue before being timed out. This parameter can be used if requests for portlets are timing out, but the requests are never being sent. Although this points to other performance problems that could be solved by alternative configurations, this option is available to allow requests to stay in the queue for longer or shorter periods of time.

10 sec

proxyHost

proxyPort

 
<proxyHost>ph.comp.com</proxyHost>
<proxyPort>8888</proxyPort>

This is the host name and port number of a proxy server that may be required to request data from the Oracle Fusion Middleware. These parameters are only required if a proxy server is in use between PPE and the Oracle Fusion Middleware listener.

n/a

poolSize

 
<poolSize>25</poolSize>

This represents the number of connections that the PPE is capable of making at any one time. This value can be raised or lowered based upon performance needs. Setting the number higher makes more threads and connections available for use; however, this uses more resources.

25

offlinePath

offlinePathMxml

 
<offlinePath>/path/offline.html</offlinePath>
<offlinePathMxml>/path/offline.xml</offlinePathMxml>

By setting either of these, the PPE is set to display the desired off-line message. There are two available messages: one for an HTML browser and one for a mobile enabled device.

null

minTimeout

 
<minTimeout>5</minTimeout>

This is the minimum request timeout allowed to be used by a Portlet. Thus, if the minTimeout is set to 5, and a portlet sends a timeout of 2, the minTimeout value of 5 would be applied to that portlet.

5 sec

maxParallelPortlets

 
<maxParallelPortlets>20</maxParallelPortlets>

Used to specify the maximum number of portlet requests for a given page, that should be allowed, to execute at the same time. Allowed values are:

0 - Indicates no restriction (beyond the number of fetchers available).

Any positive integer - Indicates a restriction on simultaneous requests.

20

maxParallelPagePortlets

 
<maxParallelPagePortlets>10</maxParallelPagePortlets>

Used to limit the number of page portlet requests that are allowed to execute at the same time in the PPE. Allowed values are as follows:

0 - Indicates no restriction (beyond the number of fetchers available).

Any positive integer - Indicates a restriction on simultaneous requests.

10

jspSrcAlias

 
<jspSrcAlias>/internal_jsp/</jspSrcAlias>

The alias for the JSP engine, like /portal/jsp or some other path.

/jsp/

jspRoot

 
<jspRoot>internal_jsp</jspRoot>

The relative path where JSP files for JSP Pages can be found.

jsp

httpsPorts

 
<httpsPorts>433:444</httpsPorts>

This is a colon (':') separated list of ports on which Oracle Portal is configured to use SSL.

null

enableWebCacheStaticRules

 
<enableWebCacheStaticRules>false</enableWebCacheStaticRules>

This key is not used if you are running 11g Release 1 (11.1.1) of the portal repository, and is provided only for backward compatibility when you use a 11g Release 1 (11.1.1) middle tier with an earlier release of the portal repository.

If you are using an earlier release of the portal repository, then consider the following:

If set to false, PPE includes the no-store directive in the surrogate control response header of an assembled page. This overrides any static cacheability rule defined in Oracle Web Cache, and ensures that the assembled page is not cached in the Web Cache.

If set to true, PPE does not include the no-store directive in the surrogate control response header of an assembled page. This allows the use of static cacheability rules for caching the assembled page in Oracle Web Cache.

Note: It is recommended to use the default value, false, as setting it to true makes cached content accessible using the URL only and this affects security. Portal data that is cached in Oracle Web Cache is secured by the presence of secure Oracle Portal HTTP headers in the request. A setting of true means that fully assembled pages may be requested by URL alone and will be returned from the cache.

false

dmsLogging

 
<dmsLogging>false</dmsLogging>

If you set dmsLogging to true, the PPE outputs data for DMS Logging.

true

cacheEncryptionKey

 
<cacheEncryptionKey>KEY</cacheEncryptionKey>

This key is used to obscure the headers used for caching using Oracle Web Cache. This allows for a more secure cache key, and makes retrieving a cached object more difficult for unwanted requests.

This key is not used if you are running 11g Release 1 (11.1.1) of the portal repository, and is provided only for backward compatibility when you use an 11.1.1 middle tier with an earlier release of the portal repository.

Server Context information

fileUploadLimit

 
<fileUploadLimit>65536</fileUploadLimit>

This is used to define the maximum size of the file (in bytes) that can be uploaded.

65536

disableUploadRequestChunking

 
<disableUploadRequestChunking>false</disableUploadRequestChunking>

If set to true, then chunked encoding of data transfer for file upload will be disabled.

false

wsrpFullPageDecoration

 
<wsrpFullPageDecoration>false</wsrpFullPageDecoration>

If set to false, turns off decoration when a portlet is rendered for the full page modes of WSRP portlets.

true

wsrpCouldNotGetMarkupMsg

 
<wsrpCouldNotGetMarkupMsg>This is my personalized error message</wsrpCouldNotGetMarkupMsg>

Replaces the default 'Could not get markup' message (issued when a WSRP portlet request fails) with a custom string.

none - default message displays

5.6.9.1.1 Passing Page Headers to Providers

Arbitrary HTTP headers received by the PPE on page requests can be forwarded to providers. To do this the Portal Administrator specifies headers to be forwarded on a per provider basis. Providers are identified by the URL at which they are running and an optional service ID.

Passing page headers to providers uses the providerHeaders and headersFor: initialization parameters which must be specifed in web.xml. For example, including the following in the web.xml file:

     ...
     <init-param>
       <param-name>providerHeaders</param-name>
       <param-value>true</param-value>
     </init-param>
     <init-param>
       <param-name>headersFor: http://my.provider.com/jpdk/providers</param-name>
       <param-value>Date:Pragma:X-Oracle-Header</param-value>
     </init-param>
     <init-param>
       <param-name>headersFor: http://some.provider.com/jpdk/providers urn:charts</param-name>
       <param-value>Via:X-Custom-Header</param-value>
     </init-param>
     <init-param>
       <param-name>headersFor: http://other.provider.com/jpdk/clipping</param-name>
<param-value>Cookie/ORA_UCM_INFO;sandiaCookie:Via:X-Custom-Header</param-value>
     </init-param>
     ...

would result in requests made to the provider running at http://my.provider.com/jpdk/providers receiving the Date, Pragma and X-Oracle-Header from the page request, and the provider running at http://some.provider.com/jpdk/providers with a service ID of urn:charts receiving the Via and X-Custom-Header page request headers.

The provider running at http://other.provider.com/jpdk/clipping would receive Via and X-Custom-Header page request headers in addition to the ORA_UCM_INFO and sandiaCookie page request cookies. Any other cookies in the page request would not be forwarded.

Table 5-7 describes the providerHeaders and headersFor parameters:

Table 5-7 ProviderHeaders Parameter

PPE Setting Syntax Description Default Value

providerHeaders

<init-param>

<param-name>providerHeaders</param-name>

<param-value>true</param-value>

</init-param>

Enables page header forwarding to providers. Allowed values are:

true - the headers specified in the headersFor: <URL>[<sid>] will be forwarded to the providers.

false - standard provider header handling.

Defaulting the providerHeaders parameter to false prevents processing overhead associated with this feature during PPE startup and page processing where no provider headers are being passed.

false

headersFor: <url> [<sid>]

<init-param>

<param-name>headersFor: <url> [<sid>]</param-name>

<param-value> header name</param-value>

</init-param>

Specifies a colon separated list of HTTP header names that will be forwarded to the provider with service ID <sid> (if specified), running at URL <url>.

This parameter can also be used to specify named cookies to be forwarded. These are defined using a semi-colon delimited list of cookie names preceded by the literal text 'Cookie/'.

n/a

5.6.9.2 Configuring the Parallel Page Engine Using WLST

The WLST (online) command is used to update some of the PPE configuration parameters in the appConfig.xml file, the configuration file that is used by the Portal midtier repository servlet. The WLST command is used to update the following parameters in the appConfig.xml file:

configurePortalPageEngine(encrypt_key, resource_url_key, use_port, use_scheme, x509certfile)
Argument Definition 
encrypt_key
Specifies the HMAC key to obscure the headers used for caching using Web Cache. This allows for a more secure cache key, and makes retrieving a cached object by unwanted requests more difficult. 
resource_url_key
This key is used calculates checksums for URLs that are requested by WSRP and JPDK resource proxying. For WSRP resource proxying to work, the key must be set to an alpha-numeric value of 10 characters or more. In addition, for JPDK proxying, a JNDI environment variable, also called resourceUrlKey, must be set for the provider. 
use_port
Overrides the port used when the PPE makes requests to the portal. The default, if not specified, is to always use the page request port. Note that if you set use_scheme, you must also set the use_port argument.

This may be used for other reasons, but mostly it is used when SSL is running between the browser and the PPE but not between the PPE and Portal. In this case, the non-SSL port for loop back requests will be different from the SSL port used by the browser.

 
use_scheme
Overrides the scheme (HTTP or HTTPS) used when the PPE makes requests to the Portal. The default, if not specified, is to always use the page request scheme. Note that if you set use_scheme, you must also set the use_port argument. 
x509certfile
Specifies a file containing a list of certificates to be implicitly trusted by HTTP Client. These certificates are added as trust points to all connections made by HTTP Client using SSL.

Note:

For more information, refer Table 5-6, "Parallel Page Engine (PPE) Parameters".

Example 5-10 Updating the Parallel Page Engine

configurePortalPageEngine(encrypt_key='encryption key',resource_url_key='foo.oracle.com',use_port=9999,use_scheme='http',x509certfile='file')

5.6.10 Retrieving the Portal Schema Password

The Oracle Portal schema password is required for some operations where you need to log in to the Portal schema. This section describes how to retrieve the Oracle Portal schema password. For information about changing schema passwords for both default and nondefault Oracle Portals, refer to Section 6.12, "Changing the Oracle Portal Schema Password". To retrieve the Portal schema password, you can use one the following:

Using the Oracle Enterprise Manager 11g Fusion Middleware Control

To retrieve the Oracle Portal schema password, using the Oracle Enterprise Manager 11g Fusion Middleware Control, do the following:

  1. Login to the Enterprise Manager.

  2. Expand WebLogic Domain, and then select ClasssicDomain.

  3. Right click ClasssicDomain, select Security, and then Credentials.

    The Credentials page is displayed.

  4. Under Credential, expand oracle.portal.dads, to see the mapname and keyname. The default mapname is oracle.portal.dads and the keyname is /pls/portal.

Using the WLST Command

The Oracle Portal schema password is stored in the configured credential store, and can be retrieved by an administrator using the WLST listCred command. This command returns the list of attribute values of a credential in the domain credential store with given map name and key name and lists the data encapsulated in credentials of type password only. To retrieve the Portal schema password, perform the following:

  1. Run wlst, located at ORACLE_HOME\common\bin in windows (For Unix it is wlst.sh).

  2. Enter connect()" -> wls:\offline>connect().

  3. Enter your username, password, and server URL.

  4. Run listCred(map="mapName", key="keyName"). For example, wls:/ClassicDomain/serverConfig> listCred(map="oracle.portal.dads", key="/pls/portal")

  5. The output will be as shown in the following example:

     {map=oracle.portal.dads, key=/pls/portal} 
 Location changed to domainRuntime tree. This is a read-only tree with DomainMBean as the root. 
 For more help, use help(domainRuntime) 
 
 [Name : DEV_PORTAL, Description : null, expiry Date : null] 
 PASSWORD:manager1

5.6.11 Using a Custom Image Directory

To avoid losing custom images stored in the Oracle Portal images directory (which is ORACLE_HOME\portal\images by default) during a future upgrade, it is recommended that you create your own images directory and set up an appropriate Oracle HTTP Server alias for this directory.

For example, add an entry, similar to the one shown next, to the file ORACLE_HOME\portal\conf\portal.conf. It is recommended that you use the local Oracle Enterprise Manager 11g Fusion Middleware Control instance to make this change. For more information, refer to the Oracle Fusion Middleware Administrator's Guide for Oracle HTTP Server or the Oracle Fusion Middleware Administrator's Guide for Oracle Web Cache.

Alias /myimages/ "/opt/app/myportal/images/"
<Directory "/opt/app/myportal/images/">
     AllowOverride None
     Order allow,deny
     Allow from all
     ExpiresActive on
     ExpiresDefault A2592000
  <Files *>
     Header set Surrogate-Control 'max-age=2592000'
  </Files>
</Directory>

You do not need to perform any specific Oracle Web Cache configuration as Oracle Web Cache is already configured to globally cache .bmp, .gif, .png, .jpg, and .jpeg files.

5.7 Configuring Mobile Support in Oracle Portal

This section discusses how Oracle Portal and Oracle Application Server Wireless are configured to operate together. Oracle Portal pages can be viewed from a wide variety of devices including desktop browsers, mobile phones, and PDAs. Oracle Portal uses OracleAS Wireless to provide wireless functionality to receive requests from wireless devices, and transform content provided by the portal into an appropriate format.

This section describes the following:

5.7.1 Installing Oracle Application Server Wireless

OracleAS Wireless is no longer installed by default, and OracleAS Wireless 10g must now be installed separately.

To install wireless:

  1. Download the Oracle Application Server 10g Release 2 distribution available from OTN:

    http://www.oracle.com/technetwork/middleware/ias/downloads/101202-095224.html

  2. Follow the onscreen instructions to install the OracleAS Wireless 10g distribution.

    After completing the OracleAS Wireless 10g installation on a separate server, continue by configuring Oracle Portal and OracleAS Wireless as shown in Section 5.7.4, "Configuring Mobile Access".

    Note:

    Oracle Portal 11g Release 1(11.1.1.4) uses OracleAS Wireless 10g for mobile support.

  3. You need to install the following OracleAS Wireless 10g patch to the Wireless instance:

    This patch is required to fix an issue on cookie handling for mobile devices.

Note:

Integrating Oracle Application Server Wireless 10g with Oracle Portal 11g Release 1 (11.1.1) requires you to complete a set of manual steps, as described in the My Oracle Support note 837837.1 (Oracle Portal 11g Release 1 (11.1.1) with Oracle Application Server Wireless). In addition, see the following My Oracle Support notes for information about deprecated features in 10g:

5.7.2 Patching OracleAS Single Sign-On for Oracle Portal Mobile Access

To fix issues on the mobile login form, you must download and install the patch ID 8564509 from https://support.oracle.com/.

5.7.3 Configuring Mobile Settings in Oracle Portal

To configure mobile settings in Oracle Portal:

  1. In the Services portlet, click Global Settings.

    By default, the Services portlet is on the Portal subtab of the Administer tab on the Portal Builder page.

  2. Click the Mobile tab.

Most mobile-related settings for Oracle Portal are found here. For more detail, see:

Note:

In a hosted environment, you can control each subscriber individually. The exception to this is the OracleAS Wireless Service URL setting. When Oracle Portal is operating in hosted mode (with multiple subscribers), any change to the OracleAS Wireless Service URL must be made by the hosting administrator, using a command line script, as it affects all subscribers.

5.7.3.1 Enabling Mobile Access

The Enable Mobile Access option enables you to control how Oracle Portal responds when a mobile client requests portal pages through OracleAS Wireless. If you want Oracle Portal to return pages and portlets in response to mobile requests, you must select the Enable Mobile Access option.

If you do not select this option, Oracle Portal responds to mobile requests with a message stating that it is not mobile enabled.

To enable mobile access:

  1. In the Services portlet, click Global Settings.

  2. Click the Mobile tab.

  3. Select the Enable Mobile Access option.

  4. Click OK.

5.7.3.2 Configuring Mobile Home Pages

Your mobile home page is the first page you see when you access Oracle Portal from a mobile device. If mobile access is enabled, you may choose whether users may select a home page specifically for mobile devices and you can also determine whether all mobile home pages display a Login Link by default:

5.7.3.2.1 Enabling Users to Select Mobile Home Pages

The Enable Mobile Home Page Selection option enables you to control whether portal users may select separate home pages for mobile access. If you do not select this option, the home pages displayed on mobile devices is the same home page that is used for standard desktop access.

To allow mobile home pages:

  1. In the Services portlet, click Global Settings.

  2. Click the Mobile tab.

  3. Select the Enable Mobile Home Page Selection option.

  4. Click OK.

When you select this option, the Default Mobile Home Page field become available to users on the Account Info page. For more information, see the Oracle Fusion Middleware User's Guide for Oracle Portal.

5.7.3.2.2 Excluding Login Links from Mobile Home Pages

The Exclude Login Link from Mobile Home Page option enables you to control whether a Login Link is displayed on mobile home pages. If mobile home pages are allowed, a Login Link is displayed on the mobile home page by default. Select this option if you do not want the default Login Link to be displayed.

To exclude Login Links from mobile home pages:

  1. In the Services portlet, click Global Settings.

  2. Click the Mobile tab.

  3. Select the Exclude Login Link from Mobile Home Page option.

  4. Click OK.

5.7.3.3 Displaying Page Titles in Mobile Banner Links

The Use Page Titles in Mobile Banner Links option enables you to choose what text is displayed in the navigation links that appear in the mobile banner. Select this option to use the titles of pages in navigation link text. To see an example, refer to Figure 5-2. If you do not select this option, the default text (Home and Back) is displayed instead.

To use page titles in navigation link text:

  1. In the Services portlet, click Global Settings.

  2. Click the Mobile tab.

  3. Select the Use Page Titles in Mobile Banner Links option.

  4. Click OK.

5.7.3.4 Displaying Enhanced Page Layouts on PDAs

The Enhance Display for PDAs option allows enhanced page layouts to be displayed on PDAs (Personal Digital Assistants). PDAs have better display capabilities than other, more simple mobile devices; therefore it is possible to enhance portal page display for PDAs.

If you select this option, default font and color settings on the PDA are used for the text, link text, the page list background, the banner background, and so on. By setting additional PDA Display Options you can override the default PDA display settings and include an image in the PDA page banner if you wish. See Figure 5-2, "Sample PDA Page Layout".

Figure 5-2 Sample PDA Page Layout

Description of Figure 5-2 follows
Description of "Figure 5-2 Sample PDA Page Layout"

If you do not select this option, the same page layout is used for all mobile devices.

To display enhanced page layouts on PDAs and (optionally) customize PDA display options:

  1. In the Services portlet, click Global Settings.

  2. Click the Mobile tab.

  3. Select the Enhance Display for PDAs option.

  4. Click Apply.

    When you click Apply, a new section called PDA Display Options is displayed at the bottom of the page.

  5. (Optional) Set PDA Display Options to control how portal pages are displayed on PDAs. Ensure that you use valid markup when specifying your font and color preferences.

    For more detail, see Table 5-8, "PDA Display Options".

  6. Click OK.

Table 5-8 PDA Display Options

Option Description

General Options

Override the default font and color for:

  • Background Color - Specify a background color for portal pages; for example, enter #FF0000 or red.

  • Font Name - Specify the font used to display text on portal pages; for example, enter arial.

  • Font Size - Specify the font size used to display text on portal pages; for example, enter -1.

  • Font Color - Specify the font color used to display text on portal pages; for example, enter #0000FF or blue.

To use the default font or color selected by the PDA, leave the appropriate field blank.

Basic Link Options

Override the default colors:

  • Unvisited Link Color - Specify a color for unvisited links on portal pages; for example, enter #00FFFF or lightblue.

  • Selected Link Color - Specify a color for selected links on portal pages; for example, enter #FFFFFF or white.

  • Visited Link Color - Specify a color for visited links on portal pages; for example, enter #FF00FF or magenta.

To use the default link color selected by the PDA, leave the appropriate field blank.

Banner Image Options

Use these options to specify an image (.GIF) for the PDA banner:

  • Banner Image (File name or URL) - If the image is located in the portal's default image directory, enter the name of the .GIF file only; for example, enter mylogo. Alternatively, enter the full URL to the image; for example, enter http://www.mycompany/images/mylogo.

  • In Default Image Directory? - Select this check box if the banner image you want to use is located in the portal's default image directory. Clear this check box if the image is accBanner Background Color - Specify a background banner color for portal pages; for example, enter #00FFFF or lightblue. Leave the field blank to use the default color selected by the PDA.essible from a URL.

  • Banner Background Color - Specify a background banner color for portal pages; for example, enter #00FFFF or lightblue. Leave the field blank to use the default color selected by the PDA.

Page List (Breadcrumbs) Options

Override the default colors:

  • Foreground Color - Specify a foreground color for portal page breadcrumbs; for example, enter #00FFFF or lightblue.

  • Background Color - Specify a background color for portal page breadcrumbs; for example, enter #0000FF or blue.

  • Link Color - Specify a color for link text in portal page breadcrumbs; for example, enter #000000 or black.

To use the default color selected by the PDA, leave the appropriate field blank.

Login / Logout Link

Specify a color for the Login/Logout link displayed on portal pages; for example, enter #000000 or black.

5.7.3.5 Logging Mobile Responses

The Log Mobile Responses option enables you to control whether portlet responses to mobile requests are logged. This feature is useful during development for portlet debugging purposes. When you select this option, the portal logs the content that mobile portlets generate when displayed on a page in response to a mobile device request.

For mobile devices, portal content is rendered in an Oracle specific markup language called MobileXML. This markup is transformed by OracleAS Wireless to the appropriate device markup that generated the request.

Portlet responses are logged when all the following conditions are met:

  • The Log Mobile Responses option is selected.

  • The user making the request is logged on.

  • The request is either from a mobile device, or it is for a mobile page.

Notes:

  • This option is intended for development purposes only. We do not recommend that you set this option in a production portal as mobile response logging will impact your portal performance.

  • Whenever you enable or disable the Log Mobile Responses option, all currently cached page data is invalidated. Therefore, we recommended that you do not change this option frequently after your Oracle Portal has been deployed for general access.

To log portlet responses to mobile requests:

  1. In the Services portlet, click Global Settings.

  2. Click the Mobile tab.

  3. Select the Log Mobile Responses option.

  4. Click OK.

Oracle Portal comes with two built-in portlets for viewing the content that is logged:

  • Most recent mobile log entry - Shows only the most recent record for a particular user, irrespective of the portlet from which the data was recorded.

  • Mobile log portlet - Shows a list of all the portlets for which a user has content recorded, the user can select which portlet's content they wish to review.

You will find additional information in the article Provider Debugging Techniques: Using the Mobile Log Viewers, on the Oracle Technology Network (OTN), http://www.oracle.com/technology/products/ias/portal/html/mobile_11g_debugging.with.logs.html.

5.7.4 Configuring Mobile Access

After the initial mobile access configuration, or any subsequent Oracle Application Server reconfiguration that results in a change to the Oracle Application Server Wireless service URL or Oracle Portal home page URL, you must manually configure OracleAS Wireless and Oracle Portal to reflect their respective URLs. For more information, see:

5.7.4.1 Configuring the Oracle Portal Home Page URL References

The Oracle Portal home page URL is the address that the OracleAS Wireless service definition refers to. When initially configuring wireless access, or if the home page URL changes, you need to configure or update the following references to it:

5.7.4.1.1 Oracle Application Server Wireless Service Definition

To configure the Oracle Portal home page URL in the OracleAS Wireless server service definition:

  1. Log in to OracleAS Wireless Tools by using the following URL:

    http://<host>:<port>/webtool/login.uix

  2. Enter the user name and password for the wireless administrator.

  3. Click the Contents tab.

  4. In the Content Manager, select the portal service, and click Edit.

    If no Portal service is listed in the Content Manager, create a new service using the Wireless Administration tool as shown in Creating a New Portal Service.

  5. Click Input Parameters on the left side of the screen.

  6. In the Input Parameters screen, change the URL as required.

  7. Click Apply to save the changes.

  8. Log out of the OracleAS Wireless Content Manager.

See Also:

Oracle Application Server Wireless Administrator's Guide

Creating a New Portal Service

If a Portal service does not already exist in the Content Manager, create one using the Wireless Administration tool as shown below:

  1. Open the Wireless Administration tool and select the Services tab.

  2. Select HttpMasterService and click Create Application.

  3. Select Multi-Channel Application and click Create.

  4. Enter portalservice as the application name, and the full URL to the Portal home page as the URL.

    The Portal home page URL appears on the Mobile tab on the Global Settings of the AS11 Portal, and is of the form:

    http://<AS11portal-host>/portal/pls/portal/portal.home

  5. Click Next, and then click Finish.

  6. Select portalservice, and then click Quick Publish and name it portalservice.

  7. Click Finish.

  8. Select the Contents tab and click Add Application Link.

  9. Open the master link, select portalservice, and click Next.

  10. Name the application link portalservice, click Next, and then click Finish.

  11. Click Access Control Content, select Guest, and click Assign Application.

  12. Select portalservice, click Add to Group, and then click Finish.

  13. Select the Users tab, and then the Users subtab.

  14. Select Guest, and click View Application Links, and check that portalservice appears in the list.

  15. Note the object ID in the table for the portalservice service (for example, 7066) to specify the URL in the Portal Global Settings Mobile tab.

5.7.4.1.2 Oracle Portal's Internal Reference to Itself

To configure Oracle Portal's own reference to its home page URL, use the script cfgiasw.pl to set the value. The script files are located here:

ORACLE_HOME/assistants/opca/

To run the script, use the following command:

perl cfgiasw.pl -s portal -c portal_db -h "http://my_portal_server.com/portal/pls/portal/portal.home"

The preceding example is specific to a UNIX machine. See Section B.7, "Using the cfgiasw Script to Configure Mobile Settings" for more information on the cfgiasw script.

5.7.4.2 Configuring the OracleAS Wireless Portal Service URL Reference

Oracle Application Server Wireless is used by Oracle Portal as an intermediary in providing access to mobile devices. To provide this access, Oracle Portal must know the URL to the OracleAS Wireless service on which the portal is registered. If the OracleAS Wireless service URL changes, its reference within Oracle Portal must be updated. This reference can be configured in either of the following ways:

5.7.4.2.1 Using the Global Settings Page to Configure the OracleAS Wireless Portal Service URL

To update the OracleAS Wireless Portal Service URL using the Global Settings page:

  1. In the Services portlet, click Global Settings.

    By default, the Services portlet is on the Portal subtab of the Administer tab on the Portal Builder page.

  2. Click the Mobile tab.

  3. Enter the URL in the OracleAS Wireless Portal Service URL field.

  4. Enter portalservice as the application name, and the full URL to the Portal home page as the URL in the form:

    http://<wireless-host>/ptg/rm?PAoid=<objectid>

    where <objectid> is the portal service Object ID from the Content tab of the Wireless Administration screen.

  5. Click OK.

You can set the OracleAS Wireless Portal Service URL definition only when Oracle Portal is not operating with multiple subscribers. If Oracle Portal is operating with multiple subscribers, only the hosting administrator should change the value of OracleAS Wireless Portal Service URL (using the cfgiasw script).

5.7.4.2.2 Using the cfgiasw Script to Configure the OracleAS Wireless Service URL Reference

To change or configure Oracle Portal's reference to the URL of Oracle Application Server Wireless Portal service, use the script cfgiasw.pl to set the value. The script files are located here:

ORACLE_HOME\assistants\opca\

To run the script, use the following command:

perl cfgiasw.pl -s portal -c portal_db -w "http://my_iasw_server.com/ptg/rm?PAoid=12345"

The preceding example is specific to a UNIX machine. See Section B.7, "Using the cfgiasw Script to Configure Mobile Settings" for more information on the cfgiasw script.

5.7.5 Changing the Mobile Device Component of the Cache Key

OracleAS Wireless is integrated with Oracle Web Cache to improve page rendering performance and scalability. The cache is used as a repository for post-transformed content; the wireless runtime determines what content needs to be inserted into the cache and when to expire content in the cache. The cache key used by Oracle Portal is composed of numerous components. One of these components is based on the OracleAS Wireless header, X-Oracle-Device.Class. This component allows portlet content to be cached based on the class of the mobile device used.

You can enable portlet content to be cached based on the name of a specific device rather than the device class. Refer to Section B.8, "Using the cfgxodnc.pl Script to Change the Mobile Device Component of the Cache Key" for more information.

5.8 Managing Users, Groups, and Passwords

Refer to Chapter 7, "Securing Oracle Portal" for more information on managing users, groups, and passwords.

5.9 Configuring Browser Settings

Refer to Browser Recommendations in the Preface of the Oracle Fusion Middleware User's Guide for Oracle Portal.

5.10 Configuring Language Support

Oracle Portal allows application development and deployment in different languages. This allows developers to work in their own language when they build portals. In addition, the self-service content management supports multiple languages so that end users can provide documents and other content in different languages.

During the middle-tier installation, Oracle Portal is configured, by default, to support en_US. To configure additional languages (listed in Table 5-9) after installation, use the ptllang tool. For more information, see Section 5.10.1, "Installing Languages After Installing Oracle Portal.".

Table 5-9 Oracle Portal Languages and Language Abbreviations

Language Language Abbreviation

Arabic

ar

Brazilian-Portuguese

ptb

Canadian French

frc

Czech

cs

Danish

dk

Dutch

nl

English

us

Finnish

sf

French

f

German

d

Greek

el

Hebrew

iw

Hungarian

hu

Italian

i

Japanese

ja

Korean

ko

Latin American Spanish

esa

Norwegian

n

Polish

pl

Portuguese

pt

Romanian

ro

Russian

ru

Simplified Chinese

zhs

Slovak

sk

Spanish

e

Swedish

s

Thai

th

Traditional Chinese

zht

Turkish

tr

Note:

Oracle Portal is not supported on the ZHT32EUC database character set. If your environment supports Traditional Chinese, then use the AL32UTF8, ZHT16MSWIN950, or ZHT16BIG5 character set.

The languages that are configured are shown in the Set Language portlet. You can use Oracle Portal in the language that corresponds to the language setting in the browser, or to the language you have selected in the Set Language portlet. However, the language setting in the browser must correspond to an installed language in Oracle Portal. The Set Language portlet is not displayed by default, but you can add the portlet to the Portal Builder page or any other page that you create in Oracle Portal.

See Also:

The section Working with the Set Language Portlet in the Oracle Fusion Middleware User's Guide for Oracle Portal.

This section contains the following topics:

5.10.1 Installing Languages After Installing Oracle Portal

To install languages after you have installed Oracle Portal, run ptllang. You must run ptllang for each language that you want Oracle Portal to support.

Caution:

During login operations, information is sent to Oracle Application Server Single Sign-On. The language used in the authentication request is sent back to Oracle Portal. OracleAS Single Sign-On must have all languages installed that exist on the Oracle Portal, so that the selected language is recognized. If OracleAS Single Sign-On does not have the selected language installed, it will default to US English. This is the language that would be asserted to any Oracle Portal that requested authentication in a language that is not available on OracleAS Single Sign-On.

The Set Language portlet in Oracle Portal sets a language and a Persistent Language cookie on OracleAS Single Sign-On and Oracle Portal.

If there are multiple portals configured to use the same OracleAS Single Sign-On, and the portals have different languages installed, all the combined languages must exist on the OracleAS Single Sign-On to accommodate a Set Language request from any of the portals.

Environment

The ptllang tool is available in the ORACLE_HOME/assistants/opca directory. Set the ORACLE_HOME environment variable to the Oracle home that contains the binaries for Oracle Portal, Forms, Reports and Discoverer.

Assumptions

The Oracle Metadata Repository is already installed, and the respective databases are up.

Usage

On Windows:

ptllang.bat  -lang lang_code [ -s portal_schema] [-sp portal_schema_password] [-c portal_db_connect_string] [-log log_file_directory]

On UNIX:

ptllang.sh  -lang lang_code [ -s portal_schema] [-sp portal_schema_password] [-c portal_db_connect_string] [-log log_file_directory]

Table 5-10 lists and describes the parameters supported by ptllang.

Table 5-10 ptllang Parameters

Parameter Definition

-s

Oracle Portal schema name.

Default: portal

-sp

Oracle Portal schema password.

-c

Connect string to the target database where Oracle Metadata Repository is installed. The format must be DbHostName:DbPortNumber:DbServiceName.

-lang

Abbreviation for the language to install. For a list of abbreviations of all the supported languages, see Table 5-9.

-log

The directory to which the log file is written.

Usage example

The following examples pass in the input provided on the command line. The examples load the Dutch language strings into the portal schema in the Oracle Metadata Repository.

On Windows:

ptllang.bat -s portal -sp portal -c myDBhost.domain.com:1521:dbServiceName -lang nl -log c:\temp

On UNIX:

ptllang.sh -s portal -sp portal -c myDBhost.domain.com:1521:dbServiceName -lang nl  -log /oracle/log

5.10.2 Enabling the Use of Territories

Once a language is installed into Oracle Portal, the end user can select the language to be used from the languages displayed in the Set Language portlet. For a given language, portal users may also select their geographic location (territory) so that localization settings such as date, currency, and decimal formats are displayed correctly. For example, if the portal language is set to English, portal users may select from territories such as, America, Australia, Canada, Ireland, United Kingdom, and so on.

Territory selection is not available on the Set Language portlet by default. If you want portal users to be able to specify their geographical location (territory), you must edit the Set Language portlet.

The Set Language portlet is not displayed by default. However, you can add it to the Portal Builder page or any other Oracle Portal page.

Adding the Set Language Portlet to a Portal Page

To add the Set Language portlet to a portal page:

  1. Log in to Oracle Portal as the portal schema owner.

  2. Display the page where you want to display the Set Language portlet. For example, you might want to add the Set Language portlet to the Administrator tab on the Portal Builder Page.

  3. Click Edit on top of the page.

  4. Click the Add Portlet icon in the region where you want to add the portlet.

  5. In the Portlet Repository, click Portal Content Tools.

  6. Click Set Language in the Available Portlets area, and click OK.

    The Set Language portlet is now available on the portal page.

    Note:

    If you add the Set Language portlet to a page and subsequently install another language, the new language is not displayed when you view the page. As a workaround, remove the portlet and add it to the page again.

Enabling the Use of Territories and Locales

To enable the use of territories and locales:

  1. Log in to Oracle Portal as the portal schema owner.

  2. Click the Edit Defaults icon for the Set Language portlet.

  3. In the Edit Set Language Portlet Settings screen shown, select the Enable Territory Selection option.

  4. Click OK.

By selecting the Enable Territory Selection option, the appropriate locales for each registered language are displayed. The locales are listed after the languages in the Set Language portlet, as shown in Figure 5-3.

Figure 5-3 The Set Language Portlet

Description of Figure 5-3 follows
Description of "Figure 5-3 The Set Language Portlet"

Note:

The Oracle Portal online Help system, which uses Oracle Help for the Web, relies on certain fonts to render the online Help user interface in different languages. To get the correct fonts installed, you must select all the languages in which you want to render the online Help, at the time of installation of the middle-tier server. To do this, click the Product Languages button, and select your languages on the Select a Product to Install screen, during the installation.

Additionally, you must make sure that the languages that are installed on the middle tier correspond with the languages that are installed on the infrastructure tier, to avoid problems with the Set Language request issued to OracleAS Single Sign-On.

Installing all languages increases the time required for the middle-tier installation.

5.11 Configuring Oracle Portal for WebDAV

WebDAV is a protocol extension to HTTP 1.1 that supports distributed authoring and versioning. With WebDAV, the Internet becomes a transparent read and write medium, where content can be checked out, edited, and checked in to a URL address. mod_dav is an implementation of the WebDAV specification. The standard mod_dav implementation supports read and write access to files.

The term OraDAV refers to the capabilities available through the mod_oradav module. mod_oradav is the Oracle module that is an extended implementation of mod_dav, and is integrated with the Oracle HTTP Server. mod_oradav can read and write to local files, but also to an Oracle Database. The Oracle Database must have an OraDAV driver installed. The OraDAV driver is installed by default on installation of Oracle Portal. mod_oradav calls this driver to map WebDAV activity to database activity. mod_oradav enables WebDAV clients to connect to an Oracle Database, read and write content, and query and lock documents in various schemas.

See Also:

Oracle Fusion Middleware Administrator's Guide for Oracle HTTP Server

When Oracle Fusion Middleware is installed, all required OraDAV parameters are set with values that enable access to Oracle Database content through a Web browser or a WebDAV client. If necessary, you can modify parameter values if the default values do not meet your needs.

Similar to the portal DAD configuration file, WebDAV has it own configuration file (INSTANCE_HOME/config/OHS/ohs1/moduleconf/mod_oradav.conf) that contains the OraDAV parameters and start with DAV and DAVParam. These parameters are specified within a <Location> directive. The oradav.conf file is included in the httpd.conf file.

See Also:

Oracle Fusion Middleware User's Guide for Oracle Portal

5.11.1 Performing Basic WebDAV Configuration

After Oracle Portal has been installed as part of the Oracle Fusion Middleware installation, the mod_oradav.conf file should be populated with a <Location> directive that points to the portal schema. In Example 5-11, the location /dav_portal/portal will be OraDAV-enabled and will (once populated with the correct values) connect to the portal schema so that users can use WebDAV clients to access portal data.

Example 5-11 Configuration Parameters for Portal Access

<Location /dav_portal/portal>
   DAV Oracle
   DAVDepthInfinity On
   DAVParam ORACONNECTSN
   <dbhost:dbport:dbservicename>
   DAVParam ORAUSER <portal schema name>
   DAVParam ORACRYPTPASSWORD <portal schema crypted password>
   DAVParam ORACONTAINERNAME wwdav
   DAVParam ORAPACKAGENAME
   <portal_schema>.wwdav_api_driver   DAVParam ORAException RAISE
   DAVParam ORATraceLevel 0   DAVParam ORACookieMaxAge 28800   Options Indexes
</Location>

By default, the Oracle Portal DAV URL is:

http://<host>:<port>/dav_portal/portal/

For example:

http://mysite.oracle.com:8090/dav_portal/portal

The dav_portal part of the URL is the default name of a virtual directory used to differentiate between portal access through a WebDAV client and portal access that uses the pls virtual directory. portal is the DAD of the portal installation. You can also configure virtual hosts to provide a different, simpler, or easier to remember URL for WebDAV access, if need be.

Users connect to a portal in WebDAV clients using the same user name and password that they use to log in to the portal itself. If the portal is in a hosted environment, users also need to add their company information to their user name, as follows:

<username>@<company>

Authentication

Due to the way some WebDAV clients behave, users might experience authentication requests multiple times. To avoid this, the portal administrator can enable the cookie option by adding the following line to the oradav.conf file:

DAVParam ORACookieMaxAge <seconds>

where seconds is the amount of time in seconds before the cookie expires.

For example a value of 28800 is 8 hours and means that once a user has logged on through a WebDAV client, the client tool will not send the user name and password again until 8 hours has passed. Many WebDAV clients (For example: Oracle Drive, WebFolders and Cadaver) do not prompt the user for a user name and password after that time as they retain the values entered when the user first connected and use them to create a new cookie.

Note:

Some WebDAV clients, for example, Dreamweaver, do not support cookies, so even if the cookie option is enabled, users may still be prompted for their passwords multiple times.

If you are using the SQL*Net Advanced Security Option (ASO), the ORACONNECT parameter in the mod_oradav.conf file must be replaced with ORASERVICE dbhost as shown next:

<Location /dav_portal/portal>
  DAV Oracle
  DAVParam ORASERVICE dbhost
  DAVParam ORAUSER portal_schema
  DAVParam ORAPASSWORD portal_schema_password
  DAVParam ORAPACKAGENAME portal_schema.wwdav_api_driver
  Options Indexes
</Location>

This allows the database alias to be resolved by the tnsnames.ora file.

Notes:

  • When you add a new DAD without specifying the user name and password, or if you change the portal database schema user name or password using SQL*Plus, you will need to update the portal_dads.conf and mod_oradav.conf files manually.

  • Whenever you make changes to portal_dads.conf or mod_oradav.conf, Oracle HTTP Server and managed server (WLS_Portal) must be restarted before the new settings will take effect.

Default Time Limit for File Locks

The new DEFAULTLOCKTIMEOUT parameter provides information about the amount of time for which any single lock created by a DAV client will endure if the client does not actively maintain the lock. This is an optional parameter. By modifying this value, you can define the default amount of time beyond which the locks will expire.

The DEFAULTLOCKTIMEOUT parameter is available in the following format in the mod_oradav.conf file:

DAVParam DEFAULTLOCKTIMEOUT 86400

The unit of measurement for this parameter is seconds. If the parameter is not specified in the configuration file, then Oracle Portal will create locks that will expire in one day, that is, 86400 seconds.

If the time specified for a lock expires, then any temporary document related to that lock is removed. This is expected behavior, for example:

  • If Microsoft Word crashes while you are updating a document, you will lose changes to the document if the lock time has expired.

  • If you perform operations such as LOCK, PUT, PUT and then close a client without specifying UNLOCK, all data that was PUT will be lost if the lock time has expired.

5.11.2 Setting Up a WebDAV Client

The steps required to set up a WebDAV client to connect to Oracle Portal varies depending on the client. All clients will eventually request a URL. The Portal DAV URL is very similar to the URL you use to access the portal itself in your Web browser, and uses the following format:

http://<host>:<port>/<dav_location>

5.11.3 WebDAV Clients and SSL

Although OraDAV does support Secure Socket Layer (SSL), some WebDAV clients do not. Refer to the WebDAV client's documentation for details.

5.11.4 Checking the Version of OraDAV Drivers

You can check the version of the OraDAV drivers from any Web browser, as shown in the following example:

http://<computer>:<port>/<dav location>/~OraDAV-Version

The output will be like the following example:

Version 1.0.3.2.3-0030 
Using Container Version 1.5

5.11.5 Checking version of oraDAV

You can check the version of oraDAV by going to dav_portal at http://host:portal/dav_portal/portal. In the Dav portal url, the version will be displayed as oraDav Portal Driver (Version Number).

5.11.6 Viewing Errors

Any errors that occur when a user performs actions on a portal using a WebDAV client are recorded in an error log that is created in that user's personal page (as an item titled My Error Log) the first time an Oracle Portal-related WebDAV error occurs. This can be very helpful for interpreting the error messages reported in WebDAV clients, such as the message 'An error has occurred while trying to complete this operation' that is often displayed in Web Folders, or HTTP error numbers reported in Cadaver.

All errors are also recorded in the Apache error log file (ORACLE_INSTANCE\diagnostics\logs\OHS\ohs1), so if the user does not have a personal page, or is a public user, the errors can still be examined.

The OraTraceEvents parameter in the mod_oradav.conf file ensures that certain information about an error, such as Agent, User, ECID, URL, and Method, is logged in the Apache error log file. This information is helpful to portal administrators and Oracle Support Services in resolving the error. The OraTraceEvents parameter is available in the following format in the mod_oradav.conf file:

DAVParam OraTraceEvents agent

The information logged in the Apache error log file will be in a format similar to the following example:

[Wed Sep 22 10:38:46 2004] [notice] OraDAV: Agent [Secret-Agent-Man] User
[Hanckel] ECID [Viscous] URI [/orddav_var2/images/var2] Method [MKCOL].

For more verbose error reporting in the Apache error log file, add the following parameter to the oradav.conf file:

DAVParam ORATraceLevel 1

Notes:

  • Remember that Oracle HTTP Server needs restarting whenever a change is made to the mod_oradav.conf file. For information about how to do this, refer to the Oracle Fusion Middleware Administrator's Guide for Oracle HTTP Server.

    You can also refer to the section "OraDAV Configuration Parameters" in the Oracle Fusion Middleware Administrator's Guide for Oracle HTTP Server for details of other OraDAV parameters.

  • The error log is not truncated and may become quite a large file. We recommend that you periodically delete this file. The next time an error is encountered a new file will be created.

  • "Not Found" messages are sometimes seen in the error log because the client computer checks for the existence of a file name. If the file does not exist, the error log correctly displays a 404 error message.

5.12 Configuring Resource Proxying

If you plan to use JPDK resource proxying to choose a key that can be shared between the Portal and providers, then you will need to configure the resourceURLKey parameter. This key is used by the Parallel Page Engine to calculate checksums for URLs that are requested by WSRP and JPDK resource proxying. For WSRP resource proxying to work, the key must be set to an alpha-numeric value of 10 characters or more. The WSRP samples that are shipped with the product use resource proxying. Therefore, if this is not configured correctly, then you will not be able to view images in WSRP portlets. In addition, for JPDK proxying, a JNDI environment variable, also called resourceUrlKey, must be set for the provider. Refer to Section 5.6.9, "Configuring the Portal Parallel Page Engine" for more information.

To configure WSRP resource proxying, perform the following steps:

  1. Set the value for the resource_url_key parameter to an alphanumeric value of 10 characters or more, by using the WLST command configurePortalPageEngine.

    Note:

    You can set the Resource URL Key through Fusion Midlleware Control from the Portal menu, by selecting Settings, and then selecting Page Engine.

  2. Restart the WLS_PORTAL.