|
Oracle® Application Server Portal Configuration Guide
10g Release 2 (10.1.4) B19305-03 |
|
 Previous |
 Next |
|
Oracle® Application Server Portal Configuration Guide
10g Release 2 (10.1.4) B19305-03 |
|
|
Previous |
Next |
Portal Tools includes two Web providers, Web Clipping and OmniPortlet, that enable page designers and portlet developers to build portlets declaratively. With the Web Clipping portlet, you can publish content from remote Web sites as portlets on a portal page. With OmniPortlet, you can publish data from various data sources, such as Web Services, XML, or a database, and display the data in various layouts, such as a table, a chart, or HTML that they define.
This appendix covers the following topics:
Web Clipping is a browser-based declarative tool that enables you to integrate any Web application with OracleAS Portal. It is designed to give you quick integration by leveraging the Web application's existing user interface. Web Clipping has been implemented as a Web provider using the Java Portal Developers Kit, which is a component of OracleAS Portal.
With Web Clipping, you can collect Web content into portlets in a single centralized Web page. You can use Web Clipping to consolidate content from Web sites scattered throughout a large organization.
Before you use Web Clipping, you must perform some administrative tasks, including:
Adding Certificates for Trusted Sites
Section 6.1.9.1 in Chapter 6, "Securing OracleAS Portal" describes how to configure or extend the trusted certificate file. A trusted server certificate file, ca-bundle.crt, generated from Oracle Wallet Manager is shipped with OracleAS Portal. This file contains an initial list of trusted server certificates that might be used for navigating to some secure servers using HTTPS. However, because it is not a complete list of all possible server certificates that exist on the Web, this file must be configured or extended to recognize any additional trusted server certificates for any new trusted sites that are visited.
Configuring Oracle Advanced Security for the Web Clipping Provider
Section 6.1.9.2 in Chapter 6, "Securing OracleAS Portal" describes configuring Oracle Advanced Security Option (ASO) to secure and encrypt the channel between itself (on the middle tier) and the database, which hosts the Web Clipping Repository.
Web clippings have definitions that must be stored persistently in the Web Clipping Repository hosted by an Oracle Database.
As portal administrator, you can configure the Web Clipping Repository using the Web Clipping Test page at:
http://<host>:<port>/portalTools/webClipping/providers/webClipping
The Web Clipping Test page automatically detects whether or not the Web Clipping provider is configured with a valid database to host the Web Clipping repository. If it is not, the Status column for the Web Clipping Repository displays Not Configured. The Edit link in the Actions column enables you to configure the connection parameters for the repository database in the Edit Provider Page. Figure I-1 shows the Web Clipping Test page:
Figure I-1 Web Clipping - Provider Test Page
By default, the Web Clipping provider is configured to use the Oracle Application Server Infrastructure database as the Web Clipping Repository. To change the repository configuration, you need to obtain a database user account from your database administrator before you begin configuring.
To change the repository settings:
In the Provider Configuration section, the Setting column contains the field Web Clipping Repository. Click its corresponding Edit link in the Actions column.
In the Repository Settings section of the Edit Provider: webClipping page, you specify the database connection information for the Web Clipping provider. Select one of the following choices for the Repository Target database:
OracleAS Infrastructure Database (default): If you select this option, no other connection parameters need be specified.
When you select this option, the Web Clipping Repository is stored in the PORTAL user schema of the OracleAS Infrastructure database.
Other Oracle9i (or later) Database: If you select this option, you must first create a database user in which to store the Web Clipping Repository. Execute the following SQL*Plus commands as a user with SYSDBA privileges:
ORACLE_HOME/bin/sqlplus /nolog SQL> connect sys/password as sysdba SQL> CREATE USER username IDENTIFIED BY password; SQL> GRANT connect, restricted session, resource TO username;
Then, in the Other Oracle9i (or later) Database field, specify the following connection parameters:
Server Host: The name of the database server
Listener Port: The listener port for the database server
SID: The database SID
Username: The database user name
Password: The password for the database user
If you require a secure database connection, in the Advanced Security Option field, select enabled (secure database connection). See Section 6.1.9.2, "Configuring Oracle Advanced Security for the Web Clipping Provider" for more information about configuring the Advanced Security Option.
Figure I-2 shows the Repository Settings section of the Edit Provider page:
Figure I-2 Web Clipping - Repository Settings
Click OK to save the settings and return to the Web Clipping Test page.
If you have specified the same database for your Repository Target as the one used for a PDK 9.0.2.4.0 installation, as part of your upgrade, you will be notified that a Repository Upgrade also needs to take place. The Web Clipping Test page will contain a Upgrade (from 9.0.2.4.0) link that enables you to do a one-click upgrade for installing new tables, and migrating existing Clipping Definitions to the latest versions.
|
Note: After the upgrade, the Clipping Definitions stored in the Web Clipping Repository will no longer work with PDK 9.0.2.4.0. |
In the Proxy Settings section of this page, you specify proxy information, if necessary. See Section I.1.3, "Configuring HTTP or HTTPS Proxy Settings" for more information.
Perform this task only if you have downloaded and installed the Web Clipping provider as part of OracleAS PDK.
|
Note: If you installed OracleAS Portal as part of the Oracle Application Server installation, the Web Clipping provider is registered by default under the Portlet Builder folder in the Portlet Repository. |
After you configure the Web Clipping provider, you must register it as a portlet provider in the OracleAS Portal instance. You can then add portlets to a portal page.
To register the Web Clipping provider, perform the following steps:
Log on to OracleAS Portal.
Navigate to the Build tab on the OracleAS Portal Home Page. By default, the Providers portlet is available on this page. If it is not available here, then use the Portal Search feature to locate the Providers portlet.
In the Providers portlet, click Register a Portlet Provider.
Follow the instructions in the registration wizard, and specify the Web Clipping provider registration settings as shown in Table I-1.
|
Note: To distinguish this Web Clipping provider from the seeded Web Clipping provider under the Portlet Builder folder in the Portlet Repository, you must give it a distinguishable name, for example,Web Clipping provider on host ABC.
|
Table I-2 lists the settings that you must specify.
Table I-1 The Web Clipping Provider Registration Settings
| Field | Value |
|---|---|
|
Name |
|
|
Display Name |
|
|
Timeout |
|
|
Timeout Message |
|
|
Implementation Style |
|
|
URL |
If you want the portlet content to be cached, then specify the Web Cache URL host name and port number to point to the OracleAS Web Cache instance. For example: http://<cache_instance_name>:<cache_port>/portalTools/webClipping/providers/webClipping |
|
The user has the same identity in the Web providers application as in the single sign-on identity |
Select this option. |
|
Select User to send user-specific information to the provider |
Select this option. |
|
Login Frequency |
Once Per User Session |
|
Require Proxy |
|
Click Finish.
You can now use the Web Clipping provider to add portlets to a portal page. The Web Clipping provider is registered, by default, under the Portlet Staging Area folder in the Portlet Repository.
Your HTTP or HTTPS proxy settings must be set to allow the Web Clipping Studio to connect to Web sites outside of your firewall. You can specify the settings in the following ways:
Using the Web Clipping Test page (see Section I.1.3.1)
Manually editing the provider.xml file (see Section I.1.3.2)
As portal administrator, you can configure proxy settings using the Web Clipping Test page at:
http://<host>:<port>/portalTools/webClipping/providers/webClipping
To configure proxy settings using the test page:
In the Provider Configuration section, the Setting column contains the field HTTP Proxy. Click its corresponding Edit link in the Actions column.
In the Proxy Settings section of the Edit Provider: webClipping page, enter the proxy settings for the Web Clipping provider:
HTTP Proxy: Enter the name of a proxy server if one is required for the provider to access the Web site being clipped. A proxy server provides access to content from servers outside a firewall.
Port: Enter the port number for the HTTP Proxy server. If you specify an HTTP Proxy server, but not a port, the HTTP Proxy port is set to default port number 80.
No Proxy for: Enter the name of any domain to which you can directly connect, bypassing a proxy server. Domain names are the part of a URL that contain the names of a business, or organization, or government agency, for example:
.company.com, .companycorp.com, .us.company.com
You can also use this field to specify a list of host names to restrict content, as described in Section I.1.3.3.
Requires Authentication: Select this check box for proxy servers that require authentication before access. Then, enter information in the following fields:
Type: Choose the type of proxy server this provider will use: Basic or Digest.
Realm: Enter the name of the realm of the proxy server that will be accessed by the user. If you do not know the name of the realm, contact the administrator of the proxy server.
Login Scheme: Choose one of the following options:
Use login below for all users: By choosing this option, the login information you enter in the Username or Password fields will be used for all users. Users will not see the Proxy Authentication section on the Edit Defaults and the Personalize pages.
Require login for all users: By choosing this option, you do not enter any information in the Username or Password fields. Page designers must enter authentication information for the proxy server on the Edit Defaults page when they define the portlet. They only need to enter the information once for the Portlet instance. End users must enter authentication information for the proxy server on the Personalize page.
Require login for all users - use login below for public users: By choosing this option, the login information you enter in the Username or Password fields will be used for all public users only. If the user is not public, they must enter authentication information for the proxy server on the Personalize page.
Username: Enter the user name to log in to the proxy server.
Password: Enter the password for the specified user name.
If you select the Requires Authentication check box and require users to log in (that is, you choose either Require login for all users or Require login for all users - use login below for public users), you must configure the Web Clipping repository. To configure the repository, see Section I.1.1.
Figure I-3 shows the Proxy Settings section of the Edit Provider page:
Click OK to save the settings and return to the Web Clipping Test page.
As the portal administrator, you can set proxy settings manually according to your HTTP or HTTPS configuration. Edit the appropriate entries in the provider.xml file located in the following directory:
On UNIX:
ORACLE_HOME/j2ee/OC4J_Portal/applications/ portalTools/webClipping/WEB-INF/providers/webClipping
On Windows:
ORACLE_HOME\j2ee\OC4J_Portal\applications\ portalTools\webClipping\WEB-INF\providers\webClipping
The following example shows the relevant portion of provider.xml:
<proxyInfo class="oracle.portal.provider.v2.ProxyInformation"> <httpProxyHost>proxy_hostname</httpProxyHost> <httpProxyPort>proxy_portnum</httpProxyPort> <dontProxyFor>list_of_proxies</dontProxyFor> <proxyUser>proxy_username</proxyUser> <proxyPassword>proxy_password</proxyPassword> <proxyType>basic_or_digest</proxyType> <proxyUseAuth>true_or_false</proxyUseAuth> <proxyUseGlobal>true_or_false</proxyUseGlobal> <proxyRealm>realm_name</proxyRealm> </proxyInfo>
The elements have the following meanings and values:
httpProxyHost: The name of a proxy server if one is required to make a URL connection with the provider, for example, when OracleAS Portal requests one of the provider's portlets. A proxy server provides access to content from servers outside a firewall.
httpProxyPort: The port number for the proxy server. If you specify an httpProxyHost, but not a port, httpProxyPort is set to default port number 80.
dontProxyFor: The name of any domain to which you can directly connect, bypassing a proxy server. Domain names are the part of a URL that contain the names of a business, or organization, or government agency, for example:
.company.com, .companycorp.com, .us.company.com
You can also use this element to specify a list of host names to restrict content, as described in Section I.1.3.3.
proxyUser: The user name to log in to the proxy server.
proxyPassword: The password for the specified user name.
proxyType: The type of proxy server this provider will use. Valid values are Basic or Digest.
proxyUseAuth: Whether or not login information is required to access this proxy server. A value of true specifies that login information is required. A value of false indicates that login information is not required.
proxyUseGlobal: Whether or not the user name and password are required for public users or all users and how the user name and password are used. This element is only relevant if proxyUseAuth is set to true.
If the value of proxyUseGlobal is true, the proxy_username specified in proxyUser and the proxy_password specified in proxyPassword are used for all users. The proxyUser and proxyPassword elements must be present in the file and must contain a user name and password. Users will not see the Proxy Authentication section on the Edit Defaults and Personalize pages.
If the value is false and the proxyUser and proxyPassword elements are present in the file, the specified proxy_username and proxy_password are used for public users only. If the user is not public, they must enter authentication information for the proxy server on the Personalize page.
If the value is false and the proxyUser and proxyPassword elements are not present in the file, all users must log in. Page designers must log in using the Proxy Authentication section on the Edit Defaults page when they define the portlet. End users must enter authentication information for the proxy server on the Personalize page.
If the value is false, regardless of whether or not the proxyUser and proxyPassword elements are present in the file, you must configure the Web Clipping repository. To configure the repository, see Section I.1.1.
proxyRealm: The name of the realm of the proxy server that will be accessed by the user. If you do not know the name of the realm, contact the administrator of the proxy server.
To restrict users from clipping content from unauthorized external Web sites, Web Clipping uses the proxy exception list. This is available only for environments that utilize a proxy server to reach external Web sites. (Usually, you use the proxy exception list to specify any domain to which you can directly connect, bypassing a proxy server.)
To add an external Web site to the proxy exception list:
Go to the Edit Provider: webClipping page, as described in Section I.1.3.1.
In the Proxy Settings section, for the No proxy for field, enter the Web sites which you want to restrict.
Click OK to save the settings and return to the Web Clipping Test page.
Users attempting to reach a Web site in one of the listed domains, from the Web Clipping Studio, will receive an HTTP timeout error.
By default, validation-based caching is used through OracleAS Portal for all Web Clipping portlets. With validation-based caching, the Parallel Page Engine (PPE) contacts the OracleAS Portal provider to determine if the cached item is still valid.
If you have Oracle Application Server Web Cache installed, you can elect to use invalidation-based caching through OracleAS Web Cache. Note that each type of caching is mutually exclusive; that is, you can use only one or the other, but not both.
With invalidation-based caching, an item remains in the cache until the cache receives notification that the item needs to be refreshed. For example, if the Web Clipping portlet contains content that is updated on a regular basis, the cache will be invalidated. Invalidation-based caching, as shown in Figure I-4, decreases the number of requests the Web Clipping provider must entertain while maintaining the same network traffic for each round trip involving PPE. Depending on your deployment scenario, you may prefer using one caching method over the other.
Figure I-4 Invalidation-Based Caching Provided by OracleAS Web Cache
See Section 1.3, "Understanding Caching in OracleAS Portal" and Section 5.8, "Managing OracleAS Portal Content Cached in OracleAS Web Cache" for more information about caching.
By default, the Web Clipping provider uses portal caching (validation-based caching). To use OracleAS Web Cache (invalidation-based caching), see one of the following sections to configure caching:
If you decide to use OracleAS Web Cache to cache Web clipping content, as a final step, you must use the Portal Navigator and change the connect string for the provider URL to point to a URL with the OracleAS Web Cache port. Usually, the OracleAS Web Cache port is 7778. Check the Application Server Control Console Ports page to verify this value. For example:
http://host:webcacheport/portalTools/webClipping/providers/webClipping
In this configuration, OracleAS Web Cache caches Web clipping content between the OracleAS Portal instance and the Web Clipping provider.
As portal administrator, you can configure caching using the Web Clipping Test Page at:
http://<host>:<port>/portalTools/webClipping/providers/webClipping
To configure caching:
In the Provider Configuration section, the Setting column contains the field Portlet Caching. Click its corresponding Edit link in the Actions column.
In the Time out settings section of the Web Clipping Portlet page, enter the number of seconds OracleAS Portal should try to connect to Web Clipping portlets before displaying a timeout message.
In the Caching Parameters section, specify a cache expires value in the Cache Expires field. The default value is 30 minutes.
In the Caching Scheme field, select the caching scheme (either validation or invalidation (requires OracleAS Web Cache).)
Figure I-5 shows the Web Clipping Portlet page:
Click OK to save the settings and return to Web Clipping Test page.
To manually enable caching with OracleAS Web Cache, take the following steps:
Check the cache.xml file in the following directory to verify the accurate values of the invalidation host and port number:
On UNIX:
ORACLE_HOME/portal/conf
On Windows:
ORACLE_HOME\portal\conf
Edit the provider.xml file located in the following directory:
On UNIX:
ORACLE_HOME/j2ee/OC4J_Portal/applications/
portalTools/webClipping/WEB-INF/providers/webClipping
On Windows:
ORACLE_HOME\j2ee\OC4J_Portal\applications\
portalTools\webClipping\WEB-INF\providers\webClipping
In the provider.xml file:
Search for the useInvalidationCaching tag and set its value to true to enable OracleAS Web Cache invalidation-based caching.
Search for the cacheExpires tag and set a default value if you wish to modify that value. This value is in minutes.
OmniPortlet is a subcomponent of OracleAS Portal that enables page designers and developers to easily publish data from various data sources using a variety of layouts. You can base OmniPortlet on almost any kind of data source, such as Web Services, spreadsheet (character-separated values), XML, and even application data from an existing Web page. OmniPortlet enables page designers and content contributors to do the following:
Access secured data
Format data using a variety of layouts including charts, forms, and reports
Accept page parameters
Pass parameters
Raise events
Expose personalizable settings to page viewers
Before you use OmniPortlet, you must perform a few administrative tasks, including:
Section I.2.2, "Performing Optional OmniPortlet Configurations"
Section I.2.3, "Registering the OmniPortlet Provider (PDK Only)"
Before you use OmniPortlet, you must perform certain administrative tasks depending on how you installed OracleAS Portal. You must perform most of these tasks only if you installed the Oracle Application Server Portal Developer Kit on a standalone Oracle Containers for J2EE (OC4J) instance, or if you downloaded the preconfigured standalone OC4J with OracleAS PDK. This manual refers to these two installations as PDK-Only installations. If you installed OracleAS Portal as part of the Oracle Application Server release, then most of the configurations are already done.
You can perform these administrative tasks using the OmniPortlet Provider Test page. The test page detects whether the OmniPortlet provider is properly configured or not. You can access the test page by clicking OmniPortlet Provider on the Portal Tools Welcome Page, located at
http://<host>:<port>/portalTools
or, by directly accessing the following URL:
http://<host>:<port>/portalTools/omniPortlet/providers/omniPortlet
The administrative tasks that you must perform are as follows:
Section I.2.1.2, "Configuring the Secured Data Repository (PDK only)"
Section I.2.1.4, "Configuring OmniPortlet to Access HTTPS URLs"
If a proxy server is required for the provider to make a URL connection to a data source outside the firewall, then you must set up the HTTP or HTTPS Proxy.
|
Note: Setting up the HTTP or HTTPS Proxy is applicable only to URL-based data sources such as XML, CSV, Web Services, and Web Page data sources. |
If you have configured the proxy settings for Web Clipping provider already using the Web Clipping Test page, then you need not configure them again for the OmniPortlet provider. If you configured the proxy settings for the Web Clipping provider manually, that is by editing the Web Clipping provider.xml file, then you need to perform the same steps for the OmniPortlet provider by editing the OmniPortlet provider.xml file located in the following directory:
ORACLE_HOME/j2ee/OC4J_Portal/applications/portalTools/omniPortlet/WEB-INF/providers/omniPortlet
To configure the proxy settings, click Edit next to HTTP Proxy on the OmniPortlet Provider Test page. An Edit Provider page is displayed, on which you can specify the HTTP Proxy Host, Proxy Port, and other proxy information. For an installation where the proxy server access requires authentication, you can specify the user name and password at the following levels:
Global: Login information is shared for all users. Specify the global login information in the Edit Provider page.
For each user: Users must set their own login information on an OmniPortlet instance as follows:
For page viewers, set the login information in the Personalize page.
For page designers, in the Edit Defaults mode, click the Source tab, then set the login information.
You do not need to restart OC4J for the new settings to take effect. Refer to the Web Clipping provider section, Section I.1.3, "Configuring HTTP or HTTPS Proxy Settings" for more information about configuring proxy settings.
OmniPortlet uses the Web Clipping repository to store credentials needed to access secured data. You must configure the repository if you intend to use the Web Page data source or work with secured data (for example, a SQL database or a URL-based data source with HTTP basic authentication). If you have configured the Web Clipping Repository already, you do not need to configure the Secured Data Repository again because they are the same repository.
To configure the repository, click Edit next to Secured Data Repository on the OmniPortlet Provider Test page. The Edit Provider page is displayed, on which you can enter the repository information. Refer to the Web Clipping provider section, Section I.1.1, "Configuring the Web Clipping Repository" for more information.
If you want the portlet content cached using invalidation-based caching, then an OracleAS Web Cache instance must be configured as a front end to the provider.
You must use the URL host name and port number to point to the OracleAS Web Cache instance when registering the provider as shown in the following example:
http://<cache_instance_name>:<cache_port>/portalTools/omniPortlet/providers/omniPortlet
This task must be performed when registering the OmniPortlet provider. Refer to Section I.2.3, "Registering the OmniPortlet Provider (PDK Only)" for details about registering the OmniPortlet provider.
When an OmniPortlet definition is altered either through the Edit Defaults or Personalize page, the provider generates a request that invalidates and removes the portlet content from the cache. The invalidation request is sent to the invalidation port of the OracleAS Web Cache instance. Information about the OracleAS Web Cache instance is maintained in the cache.xml file in the ORACLE_HOME/portal/conf directory. If the Web Cache invalidation settings change, then you must update this file. The following example shows sample entries in the cache.xml file:
<?xml version="1.0"?>
<webcache>
<invalidation
host="<cache_instance_name>"
port="<cache_invalidation_port>"
authorization="<obfuscated_username_password>"/>
</webcache>
Where:
<cache_instance_name> is the host name of the Web Cache instance.
<cache_invalidation_port> is the Web Cache invalidation port.
<obfuscated_username_password> is the invalidator user name and password.
For information about obfuscating the invalidator user name and password, refer to the Oracle Application Server Portal Developer's Guide.
You can configure OmniPortlet to access data through HTTPS URLs by doing the following:
Adding Certificates for Trusted Sites
Library For HTTPS Access (PDK Only)
Adding Certificates for Trusted Sites
Perform this task only once, either for Web Clipping or for OmniPortlet.
The trusted server certificate file, ca-bundle.crt, generated from Oracle Wallet Manager is shipped with OracleAS Portal. This file contains an initial list of trusted server certificates that may be used for navigating to some secure servers using HTTPS. However, because the file does not contain a complete list of all possible server certificates that exist on the Web, this file must be configured or extended to recognize any additional trusted server certificates for any new trusted sites that are visited. Refer to Section 6.1.9.1, "Adding Certificates for Trusted Sites" for details about configuring or extending the trusted certificate file.
Copying the Library for HTTPS Access (PDK Only)
To access HTTPS URLs, OmniPortlet needs access to the files, njssl10.dll (for Windows) or libnjssl10.so (for UNIX).
For providers running on Windows, the njssl10.dll file must be present in a folder defined in the PATH environment variable. If it is not available, then you can copy this library from the ORACLE_HOME/bin directory.
For providers running on UNIX, the libnjssl10.so file must be present in the folder defined in LD_LIBRARY_PATH environment variable. If it is not available, then you can copy this library from the ORACLE_HOME/lib directory.
After copying the library, you must restart the OC4J instance.
The following configuration tasks are optional.
Setting the LocalePersonalizationLevel
The default setting for the LocalePersonalizationLevel of OmniPortlet and Simple Parameter Form is none. This mode indicates that, when you edit the portlet defaults by using the Edit Defaults mode, the changes apply to all users, regardless of the current portal session language or the locale of the browser. If you do not want the changes made using the Edit Defaults mode to apply to all users, then you can modify the provider.xml file for the OmniPortlet provider by setting the LocalePersonalizationLevel tag to language or locale. For more information about these settings, refer to the PDK-Java Release Notes available at the following location:
ORACLE_HOME/portal/pdkjava/v2/pdkjava.v2.releasenotes.html
Reverting to Using Graph Class to Render Chart Layout Style
OmniPortlet now uses ThinGraph class to render the chart layout style. This provides better multilingual support and removes middle-tier font dependence. The chart style produced in OracleAS Portal 10.1.2.0.2 may be different from that of earlier versions where Graph class was used. To display the old chart style, you must revert to using the old Graph class.
To do this, perform the following steps:
Navigate to the provider.xml file located in the directory ORACLE_HOME/j2ee/OC4J_Portal/applications/portalTools/omniPortlet/WEB-INF/providers/omniPortlet.
Edit the useThinGraph tag as follows:
<useThinGraph>false</useThinGraph>
Save the provider.xml file.
Perform this task only if you have downloaded and installed the OmniPortlet provider as part of OracleAS PDK.
|
Note: If you installed OracleAS Portal as part of the Oracle Application Server installation, the OmniPortlet provider is registered by default under the Portlet Builder folder in the Portlet Repository. |
After you configure the OmniPortlet provider, you must register it as a portlet provider in the OracleAS Portal instance. You can then add portlets to a portal page.
To register the OmniPortlet provider, perform the following steps:
Log on to OracleAS Portal.
Navigate to the Build tab on the OracleAS Portal Home Page. By default, the Providers portlet is available on this page. If it is not available here, then use the Portal Search feature to locate the Providers portlet.
In the Providers portlet, click Register a Portlet Provider.
Follow the instructions in the registration wizard, and specify the OmniPortlet provider registration settings.
|
Note: To distinguish this OmniPortlet provider from the seeded OmniPortlet provider under the Portlet Builder folder in the Portlet Repository, you must give it a distinguishable name, for example,OmniPortlet provider on host ABC.
|
Table I-2 lists the settings that you must specify.
Table I-2 The OmniPortlet Provider Registration Settings
| Field | Value |
|---|---|
|
Name |
|
|
Display Name |
|
|
Timeout |
|
|
Timeout Message |
|
|
Implementation Style |
|
|
URL |
If you want the portlet content to be cached, then specify the Web Cache URL name and port number to point to the OracleAS Web Cache instance. For example: http://<cache_instance_name>:<cache_port>/portalTools/omniPortlet/providers/omniPortlet |
|
The user has the same identity in the Web providers application as in the single sign-on identity |
Select this option. |
|
Select User to send user-specific information to the provider |
Select this option. |
|
Login Frequency |
|
|
Require Proxy |
|
Click Finish.
You can now use the OmniPortlet provider to add portlets to a portal page. The OmniPortlet provider is registered, by default, under the Portlet Staging Area folder in the Portlet Repository.
The OmniPortlet SQL data source is preconfigured to access Oracle Databases using the Oracle JDBC driver, and ODBC data sources using the JDBC-ODBC driver from Sun Microsystems. Perform this step if you want to access other relational databases with OmniPortlet using the DataDirect JDBC drivers, which are the preferred drivers.
You can configure the OmniPortlet SQL data source to access other relational databases by using DataDirect JDBC drivers. To do this, perform the following steps:
|
See Also: For a list of supported databases, Certification Matrix for Oracle Application Server and DataDirect JDBC available at
|
DataDirect JDBC drivers are packaged in a single ZIP file containing the different drivers used to access supported databases. Download the ZIP file from the following location:
http://www.oracle.com/technology/software/products/ias/htdocs/utilsoft.html
To install DataDirect JDBC drivers, perform the following steps:
Unzip the contents of the ZIP file into a temporary directory, for example /temp/datadirect.
Create the ORACLE_HOME/j2ee/<OC4J_INSTANCE_HOME>/applib directory if it does not already exist.
From the /temp/datadirect/lib directory, copy the DataDirect JDBC drivers to the ORACLE_HOME/j2ee/<OC4J_INSTANCE_HOME>/applib directory.
Check the configuration of the OC4J_Portal instance to ensure that the DataDirect libraries are loaded. To do this, perform the following steps:
Open the ORACLE_HOME/j2ee/<OC4J_INSTANCE_HOME>/config/application.xml file. This file is used to configure all applications in this instance.
Add the XML entry, <library path="../applib"/>, to the file if it does not already exist.
OmniPortlet is implemented as a Web provider and all the configuration properties are stored in the provider.xml file. To use DataDirect JDBC drivers with OmniPortlet, you must register these drivers in the provider.xml file.
To register the new DataDirect JDBC drivers, perform the following steps:
Back up the file, ORACLE_HOME/j2ee/<OC4J_INSTANCE_HOME>/applications/portalTools/omniPortlet/WEB-INF/providers/omniPortlet/provider.xml, and then open the file.
Add the drivers that you want to use for the SQL data source configuration entry. To do this, perform the following:
Search for the XML tag, driverInfo.
Add a new entry after the last driverInfo tag.
Following is an example showing a Microsoft SQL Server entry:
For OmniPortlet version 9.0.4.1 or later:
<!-- registration of DataDirect Connect for JDBC SQL Server driver --> <driverInfo class="oracle.webdb.reformlet.data.jdbc.JDBCDriverInfo"> <name>Microsoft SQL Server</name> <sourceDataBase>other</sourceDataBase> <subProtocol>sqlserver</subProtocol> <connectString>mainProtocol:subProtocol://databaseName</connectString> <driverClassName>com.oracle.ias.jdbc.sqlserver.SQLServerDriver </driverClassName> <dataSourceClassName>com.oracle.ias.jdbcx.sqlserver.SQLServerDataSource </dataSourceClassName> <connHandlerClass>oracle.webdb.reformlet.data.jdbc.JDBCConnectionHandler </connHandlerClass> <connPoolSize>5</connPoolSize> <loginTimeOut>30</loginTimeOut> </driverInfo>
For OmniPortlet versions before 9.0.4.1:
<!-- registration of DataDirect Connect for JDBC SQL Server driver --> <driverInfo class="oracle.webdb.reformlet.data.jdbc.JDBCDriverInfo"> <name>Microsoft SQL Server</name> <sourceDataBase>other</sourceDataBase> <subProtocol>sqlserver</subProtocol> <connectString>mainProtocol:subProtocol://databaseName</connectString> <driverClassName>com.oracle.ias.jdbc.sqlserver.SQLServerDriver </driverClassName> <connHandlerClass> oracle.webdb.reformlet.data.jdbc.JDBCODBCConnectionHandler </connHandlerClass> <connPoolSize>5</connPoolSize> <loginTimeOut>30</loginTimeOut> </driverInfo>
Table I-3 describes the parameters in the driverInfo property.
Table I-3 Parameters in the driverInfo Property
| Parameter | Description |
|---|---|
|
|
Name of the database you want to use. This name will be used on the Source tab of the OmniPortlet wizard. |
|
|
Internal value. Set the value to |
|
|
JDBC subprotocol name used by OmniPortlet to create the connection string, for example |
|
|
Description of the connect string format. For DataDirect drivers, the format is: |
|
|
Name of the driver class. To get the different values, refer to the DataDirect JDBC driver documentation using the links provided at the end of this section. |
|
|
Name of the data source class that implements connection pooling. This parameter is only available in OmniPortlet version 9.0.4.1 or later. Refer to Table I-4 for the right data source class name for your driver. |
|
|
Class used by OmniPortlet to manage the driver and connection pooling. The value is either of the following:
|
|
|
Minimum number of connections that are opened by the connection pool. |
|
|
Maximum time, in seconds, that this data source will wait while attempting to connect to a database. |
Table I-4 lists the values for the driverClassName and dataSourceClassName properties for specific DataDirect JDBC drivers.
Table I-4 Parameters and Values for driverClassName and dataSourceClassName
| DataDirect Drivers Supported | Properties |
|---|---|
|
Microsoft SQL Server |
|
|
Sybase |
|
|
DB2 |
|
|
Informix |
|
Save the provider.xml file.
Stop and start the Oracle Application Server instance.
|
Note: If you are using OmniPortlet in a multiple nodes configuration, for example, in a clustering or load-balancing environment, then you must manually copy theprovider.xml file on each node.
|
|
See Also: For more information on DataDirect JDBC drivers, refer to the following documentation:
|
Troubleshooting Information
If you encounter errors or problems when configuring or using the OmniPortlet provider, refer to Appendix K, "Troubleshooting OracleAS Portal" for troubleshooting information.
