Oracle® Fusion Middleware Developer's Guide for Oracle WebCenter 11g Release 1 (11.1.1.5.0) E10148-16 |
|
![]() Previous |
![]() Next |
This appendix discusses configuration information for the portlet technologies available with Oracle WebCenter.
This chapter includes the following sections:
For more information about using the portlet technologies at design time, see their respective chapters throughout this guide:
For more information about using these technologies at runtime, see their respective chapters in Oracle Fusion Middleware User's Guide for Oracle WebCenter Spaces.
This section contains configuration information for OmniPortlet. To learn more about the OmniPortlet wizard, see Chapter 64, "Creating Portlets with OmniPortlet." This section contains configuration information for the following areas:
Section E.1.1, "Configuring the OmniPortlet Producer to Access Data Outside a Firewall"
Section E.1.2, "Configuring the OmniPortlet Producer to Access Other Relational Databases"
Section E.1.3, "Configuring Portal Tools and Web Producers (Optional)"
Note: In this section,OmniPortlet_WAR_DIR indicates the directory where omniPortlet.war is deployed in the WebLogic Server. The exact path can vary depending on your installation. To determine this path, search for omniPortlet/provider.xml in the file system. For example, run the following command in UNIX:
> find DOMAIN_DIR -name "provider.xml" | grep -i omniportlet
In the Integrated WebLogic Server (Integrated WLS or Default Server), the path of OmniPortlet's JDEV_SYSTEM_DIRECTORY/DefaultDomain/servers/DefaultServer/tmp/_WL_user/portalTools_11.1.1.2.0/RANDOMLY_GENERATED_DIRECTORY/war/WEB-INF/providers/omniPortlet/provider.xml Note that, on a Windows platform, pages in WebCenter Portal applications are not rendered if there is a space in the path to the system directory in JDeveloper. Therefore, ensure that the In the Fusion Middleware 11g installation, the path of OmniPortlet's FMW_HOME/user_projects/domains/wc_domain/servers/WLS_Portlet/tmp/_WL_user/portalTools_version_number/RANDOMLY_GENERATED_DIRECTORY/war/WEB-INF/providers/omniPortlet/provider.xml |
If the OmniPortlet producer is inside your firewall, then you must configure the proxy information so that OmniPortlet can access URLs of data (such as CSV, XML, or Web Services) located outside the firewall. To do so, you can either set the proxy information in the command line when you start your WebLogic server. Or, you can set up the proxy information in OmniPortlet's provider.xml
file, located here: OmniPortlet_WAR_DIR
/WEB-INF/providers/omniPortlet/provider.xml
.
Note: For the Web Service data source, you must set the proxy information in both theprovider.xml file and using the command line parameters. |
To set the proxy information in the command line when starting the WebLogic server, set the parameters as described in Table E-1, if you are using an HTTP Proxy Host, or Table E-2, if you are using an HTTPS Proxy Host.
Table E-1 HTTP Proxy Information Command Line Parameters
Parameter | Description |
---|---|
|
The host name of a proxy server if one is required to make a URL connection from the OmniPortlet producer to its data sources. |
|
The port number for the HTTP Proxy Host. |
|
The name of any domain or hosts to which you can directly connect, bypassing a proxy server, such as your local machine:
Hosts can be fully qualified host names or can be IP addresses. |
|
The user to log in to the proxy server if the proxy server requires authentication. |
|
The password to log in to the proxy server if the proxy server requires authentication. |
|
The authentication type of the proxy server. Acceptable values: |
|
The name of the realm of the proxy server. If you do not know the name of the realm, contact the proxy server administrator. |
Table E-2 HTTPS Proxy Information Command Line Parameters
Parameter | Description |
---|---|
|
The host name of a proxy server if one is required to make a URL connection from the OmniPortlet producer to its data sources. |
|
The port number for the HTTPS Proxy Host. |
|
The name of any domain or hosts to which you can directly connect, bypassing a proxy server, such as your local machine:
Hosts can be fully qualified host names or can be IP addresses. |
|
The user to log in to the proxy server if the proxy server requires authentication. |
|
The password to log in to the proxy server if the proxy server requires authentication. |
|
The authentication type of the proxy server. Acceptable values: |
|
The name of the realm of the proxy server. If you do not know the name of the realm, contact the proxy server administrator. |
The following are examples of three parameters and their values:
-Dhttps.proxyHost=myProxyServer.mycompany.com -Dhttps.proxyPort=80 -Dhttps.nonProxyHosts=localhost|localhost.localdomain|127.0.0.1|
To configure the proxy information in the provider.xml
file, see Table E-3 for a list of parameters and their descriptions.
Table E-3 Provider.xml Tags
Parameter | Description |
---|---|
|
Enter the host name of a proxy server if one is required to make a URL connection from the OmniPortlet producer to its data sources. |
|
Enter the port number for the HTTP Proxy Host. |
|
Enter the name of any domain or hosts 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:
Hosts can be fully qualified host names or can be IP addresses. |
|
Acceptable values: Enter true if your proxy server requires authentication. The authentication parameters are specified by the following tags: |
proxyType |
Acceptable values: Choose the type of proxy server this provider. For more information about basic or digest authentication, see |
|
Enter the name of the realm of the proxy server that is accessed by the user according to the login information described later in the table. If you do not know the name of the realm, then contact the administrator of the proxy server. |
|
Acceptable values: true | If true, then the |
|
Enter the user name to log in to the proxy server. |
|
Enter the password for the specified user name. You must prefix ! before your plain password text. It is then encrypted in the |
The following is a basic example of using a proxy to access data outside a firewall:
<proxyInfo class="oracle.portal.provider.v2.ProxyInformation"> <httpProxyHost>www-proxy.example.com</httpProxyHost> <httpProxyPort>80</httpProxyPort> <proxyUseAuth>false</proxyUseAuth> </proxyInfo>
The following example requires a login and basic authentication for all users for the proxy server:
<proxyInfo class="mycompany.portal.provider.v2.ProxyInformation"> <httpProxyHost>myport.example.com</httpProxyHost> <httpProxyPort>8080</httpProxyPort> <proxyUseAuth>true</proxyUseAuth> <proxyType>Basic</proxyType> <proxyRealm>myport</proxyRealm> <proxyUseGlobal>false</proxyUseGlobal> </proxyInfo>
The OmniPortlet SQL data source is preconfigured to access Oracle databases using the Oracle JDBC drivers, and ODBC data sources using Sun Microsystem's JDBC-ODBC driver. Oracle allows developers to access other relational databases using DataDirect JDBC drivers.
See Also: For a list of supported databases, Certification Matrix for Oracle Application Server and DataDirect JDBC available on the Oracle Technology Network (http://www.oracle.com/technetwork/index.html ). |
This section contains the following steps:
The following DataDirect JDBC drivers are included with the WebLogic Server installation:
wlinformix.jar
wlsqlserver.jar
wlutil.jar
wldb2.jar
wlresource.jar
wlspy.jar
wlbase.jar
If you do not plan to use these DataDirect drivers, you can instead download DataDirect JDBC drivers to access the desired database. These drivers are packaged in a single ZIP, which you can download from the following location:
http://www.oracle.com/technetwork/topics/datadirect-index-091847.html
To install DataDirect JDBC drivers:
Unzip the contents of the ZIP file into a temporary directory, for example /temp/datadirect
.
Copy the DataDirect JDBC drivers from the temporary directory to your WebLogic Server directory: WLS_DOMAIN_DIRECTORY/lib
.
OmniPortlet is implemented as a Web producer 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:
Back up the file, OmniPortlet_WAR_DIRECTORY
/WEB-INF/providers/omniPortlet/provider.xml
, and then open the file.
Add the drivers to use for the SQL data source configuration entry:
Search for the XML tag, driverInfo
.
Add a new entry after the last driverInfo
tag.
The following are examples of the driverInfo for WebLogic DataDirect drivers:
Microsoft SQL Server:
<driverInfo class="oracle.webdb.reformlet.data.jdbc.JDBCDriverInfo"> <name>Microsoft SQL Server</name> <sourceDataBase>other</sourceDataBase> <subProtocol>weblogic:sqlserver</subProtocol> <connectString>mainProtocol:subProtocol://databaseName</connectString> <driverClassName>weblogic.jdbc.sqlserver.SQLServerDriver </driverClassName> <dataSourceClassName>weblogic.jdbcx.sqlserver.SQLServerDataSource </dataSourceClassName> <connHandlerClass>oracle.webdb.reformlet.data.jdbc.JDBCConnectionHandler </connHandlerClass> <connPoolSize>5</connPoolSize> <loginTimeOut>30</loginTimeOut> </driverInfo>
Sybase:
<driverInfo class="oracle.webdb.reformlet.data.jdbc.JDBCDriverInfo"> <name>Sybase</name> <sourceDataBase>other</sourceDataBase> <subProtocol>weblogic:sybase</subProtocol> <connectString>mainProtocol:subProtocol://databaseName</connectString> <driverClassName>weblogic.jdbc.sybase.SybaseDriver </driverClassName> <connHandlerClass> oracle.webdb.reformlet.data.jdbc.JDBCODBCConnectionHandler </connHandlerClass> <connPoolSize>5</connPoolSize> <loginTimeOut>30</loginTimeOut> </driverInfo>
DB2:
<driverInfo class="oracle.webdb.reformlet.data.jdbc.JDBCDriverInfo"> <name>DB2</name> <sourceDataBase>other</sourceDataBase> <subProtocol>weblogic:db2</subProtocol> <connectString>mainProtocol:subProtocol://databaseName</connectString> <driverClassName>weblogic.jdbc.db2.DB2Driver </driverClassName> <connHandlerClass> oracle.webdb.reformlet.data.jdbc.JDBCODBCConnectionHandler </connHandlerClass> <connPoolSize>5</connPoolSize> <loginTimeOut>30</loginTimeOut> </driverInfo>
Informix:
<driverInfo class="oracle.webdb.reformlet.data.jdbc.JDBCDriverInfo"> <name>Informix</name> <sourceDataBase>other</sourceDataBase> <subProtocol>weblogic:informix</subProtocol> <connectString>mainProtocol:subProtocol://databaseName</connectString> <driverClassName>weblogic.jdbc.informix.InformixDriver </driverClassName> <connHandlerClass> oracle.webdb.reformlet.data.jdbc.JDBCODBCConnectionHandler </connHandlerClass> <connPoolSize>5</connPoolSize> <loginTimeOut>30</loginTimeOut> </driverInfo>
Table E-4 describes the parameters in the driverInfo
property.
Table E-4 Parameters in the driverInfo Property
Parameter | Description |
---|---|
|
Name of the database you want to use. This name is 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, see 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. See Table E-5 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 waits while attempting to connect to a database. |
Table E-5 lists the values for the driverClassName
and dataSourceClassName
properties for specific DataDirect JDBC drivers.
Table E-5 Parameters and Values for driverClassName and dataSourceClassName
DataDirect Drivers Supported | Properties |
---|---|
Microsoft SQL Server |
Parameter: Value: |
Sybase |
Parameter: Value: |
DB2 |
Parameter: Value: |
Informix |
Parameter: Value: |
Save the provider.xml
file.
Stop and start the Oracle WebLogic Managed Server instance where your portlet producer was deployed. To do so, navigate to your WL_HOME
, then to the subdirectory opmn/bin
.
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 about how to use DataDirect JDBC drivers, see Chapter 64, "Creating Portlets with OmniPortlet." |
To ensure that the OmniPortlet and Web Clipping producers, locally built, and custom built Web producers work properly in the middle-tier environment, some additional configuration may be needed. If OmniPortlet or any other Web producers have customizations in the file system, then PDK-Java provides a Preference Store Migration/Upgrade Utility that you can use to migrate the existing customizations to the database and upgrade customizations from earlier releases. See Section E.5, "Portlet Preference Store Migration Utilities" for more information about the PDK Preference Store Migration Utility.
Configuring Portal Tools Producers in the Multiple Middle-Tier Environment
By default, the OmniPortlet producer uses the Database Preference Store. It can work in a multiple middle-tier environment without additional configuration.
You can find more information about configuring the database Preference Store in Section E.5, "Portlet Preference Store Migration Utilities."
If you have created an OmniPortlet instance with customizations in the file system, then you must migrate these customizations to the database using the Preference Store Migration Utility.
To run the migration utility:
Navigate to the WebCenter Oracle home directory using the following command:
cd WC_ORACLE_HOME
Run the following command to migrate OmniPortlet data from a file-based Preference Store (FilePreferenceStore
) to the database Preference Store (DBPreferenceStore
):
java -classpath lib/dms.jar:jdbc/lib/ojdbc14dms.jar:portal/jlib/pdkjava.jar:portal/jlib/ ptlshare.jar oracle.portal.provider.v2.preference.MigrationTool -mode filetodb -pref1UseHashing true -pref1RootDirectory portal/portletdata/tools/omniPortlet -pref2User User_Name -pref2Password User_Password -pref2URL jdbc:oracle:thin:@infra.host.com:1521:orcl
See Section E.5, "Portlet Preference Store Migration Utilities" for more information about the PDK Preference Store Migration Utility.
Typically, you perform the HTTP Proxy configuration for OmniPortlet and Web Clipping before you configure the Load Balancing Router (LBR). To do it after the LBR is configured, perform the following steps:
The Portal Tools configuration information is stored in the provider.xml
file on the middle-tier server. You must update the configuration directly on one middle tier (for example, M1) and then propagate it across all middle tiers front-ended by the LBR. You must first shut down all middle tiers except M1.
You can change the HTTP Proxy settings in the provider.xml
file. For more information, see Section E.1.1, "Configuring the OmniPortlet Producer to Access Data Outside a Firewall."
Propagate the changes made to the provider.xml
file to middle tier M2:
Copy OmniPortlet_WAR_DIR
/WEB-INF/providers/omniPortlet/provider.xml
from M1 to M2.
Copy WebClipping_WAR_DIR
/WEB-INF/providers/webClipping/provider.xml
from M1 to M2.
Restart middle tier M2.
Update portlet producer registration in your WebCenter Portal application. Change the first part of the producer registration URL from http://m1.abc.com:7777/
to http://lbr.abc.com/
.
Verify that OmniPortlet and the Web Clipping producers work properly through the LBR, by going to the test pages at the following URLs.
OmniPortlet Producer: http://lbr.abc.com/portalTools/omniPortlet/producers/omniPortlet
If you see the "No Portlets Available" message under the Portlet Information section in the OmniPortlet Producer test page, then you may not have configured OmniPortlet correctly in Step 1. If OmniPortlet is configured correctly, then the OmniPortlet and Simple Parameter Form portlets are available on the test page.
Web Clipping Producer: http://lbr.abc.com/portalTools/webClipping/producers/webClipping
Note: To use the Web Clipping portlet, or the Web Page Data Source for OmniPortlet, then you must also enable session binding in Oracle Web Cache. |
Before you use Web Clipping, you must perform some administrative tasks, including the following:
Web clippings have definitions that must be stored persistently in an Oracle Metadata Services (MDS) store or an Oracle database.
Note: You cannot use a Microsoft SQL Server or IBM DB2 database as the Web Clipping repository. |
You can view the Web Clipping repository configuration by accessing the Web Clipping Producer Test Page at:
http://host:port
/portalTools/webClipping/providers/webClipping
Where, host
is the server to which your Web Clipping producer has been deployed and port
is the port to which the server is listening for HTTP requests.
Note: Integrated WLS and theWLS_Portlet managed server are deployed to different ports even if they may be available on the same system. By default, Integrated WLS is deployed to port 7101 and WLS_Portlet is deployed to port 8889. |
The Provider Test Page automatically detects whether the Web Clipping producer is configured with a valid repository. If it is not, then the Status column for the Web Clipping Repository displays Not Configured. Figure E-1 shows the Provider Test Page of Web Clipping.
Figure E-1 Web Clipping - Provider Test Page
You cannot change the Web Clipping configuration information by using the Provider Test Page. You can configure the Web Clipping repository by setting appropriate values in the provider.xml
file. In this file, you use the repositoryInfo
tag to specify the Web Clipping repository settings.
This section includes the following subsections:
Section E.2.1.1, "Using Oracle Metadata Services (MDS) as the Web Clipping Repository"
Section E.2.1.2, "Using an Oracle Database as the Web Clipping Repository"
Section E.2.1.3, "Configuring Web Clipping Repository in provider.xml"
Section E.2.1.4, "Attributes and Child Tags of the repositoryInfo Tag"
By default, in Oracle JDeveloper, the Web Clipping producer hosted on Integrated WLS, the default server, is configured to use MDS, which is file-based, as the Web Clipping repository.
Note: In a full Oracle Fusion Middleware installation, the Web Clipping portlet producer is also included within theWLS_Portlets managed server in the default domain. By default, this Web Clipping portlet producer is configured to use the Oracle database, which is installed as part of Oracle WebLogic Server, as the Web Clipping repository. |
Example E-1 shows MDS as the default repository in provider.xml
.
Example E-1 MDS as the Default Web Clipping Repository in provider.xml
<repositoryInfo class="oracle.portal.wcs.provider.info.MdsInformation">
<mdsConfigLocation>mds-config.xml</mdsConfigLocation>
</repositoryInfo>
For an MDS repository, the repositoryInfo
tag is set to the MdsInformation
class. The mdsConfigLocation
entry specifies the path to the mds-config.xml
file, which contains the metadata store configuration information, including the path to the actual metadata store. In Oracle JDeveloper, the mds-config.xml
file is located at the following path:
JDEV_SYSTEM_DIRECTORY/DefaultDomain/servers/DefaultServer/tmp/_WL_user/portalTools_11.1.1.2.0/RANDOMLY_GENERATED_DIRECTORY/war/WEB-INF
Note: On a Windows platform, pages in WebCenter Portal applications are not rendered if there is a space in the path to the system directory in JDeveloper. Therefore, ensure that theJDEV_SYSTEM_DIRECTORY path does not contain spaces. |
The mds-config.xml
file specifies the location of the repository in a property tag:
<property name="metadata-path" value="portletdata/tools/webClipping"/>
The location specified for value
is relative to JDEV_HOME
/portal
. Any relative path specified is interpreted to be relative to JDEV_HOME
/portal
. To use another location, for example, a location outside the Oracle JDeveloper home, then specify an absolute path, such as c:\mds
.
Note: For a multiple middle tier deployment, change the metadata path to a shared file system. |
Although MDS is the default repository in Oracle JDeveloper, you can alternatively select to use a database schema for your Web Clipping repository.
Note: If you use a database as your Web Clipping repository, any customizations are retained even if the Web Clipping producer or the consuming application is redeployed. |
You can use either of the following database schemas for Web Clipping:
The default PORTLET
database schema created by RCU for Oracle WebLogic Server
A user-defined database schema for Oracle 9i
or later
Note: You cannot use a Microsoft SQL Server or IBM DB2 database as the Web Clipping repository. |
This section includes the following subsections:
For Web Clipping repository, you can use the Oracle database installed as part of Oracle WebLogic Server, through a JNDI data source named jdbc/portletPrefs
. To access the database, the schema named PORTLET
is used.
Note: ThePORTLET schema must be created in the Oracle database configured for Oracle WebCenter. For more information, see the "Installing WebCenter" chapter in the Oracle Fusion Middleware Installation Guide for Oracle WebCenter. |
You can use any user-defined schema for an Oracle 9i
or later database as the Web Clipping repository. To create a database schema for Web Clipping definitions and clippings, run the Java command described in Example E-2.
Example E-2 Java Command for Creating a Schema for Web Clipping Portlet Definitions and Clippings
java -classpath WC_ORACLE_HOME/lib/xmlparserv2.jar: WC_ORACLE_HOME/jdbc/lib/ojdbc14.jar:WC_ORACLE_HOME/portal/jlib/wce.jar oracle.portal.wcs.Installer -installSchema -username dbuser -password dbpassword -dburl jdbc:oracle:thin:@//host:port/dbid
Where:
WC_ORACLE_HOME
is the path to your WebCenter Oracle home directory
dbuser
is the database user for the schema
Consider using the same database user you use to create the WSRP and PDK-Java preference store database schema. If you do not use the same user, then you must create a new user and grant it connect and resource privileges.
dbpassword
is the specified user's password
dburl
is the URL for the database
This is the database that contains the schema that you create for Web Clipping portlet definitions and clippings by using the following syntax:
jdbc:oracle:thin:@//dbhost:dbport/service_name
For example:
jdbc:oracle:thin:@//shobeen:1521/sales_us
Note: The classpath in Example E-2 uses different separators for UNIX and Windows. On UNIX systems, theclasspath uses a colon (:) separator. On Windows systems, the classpath uses a semicolon (;) separator. |
To change the repository configuration for the Web Clipping producer deployed to Integrated WLS:
Open the provider.xml
file in a text editor.
Specify the setting for your Web Clipping repository:
Use the PORTLET
schema referred by the JNDI data source created by RCU. Specify the entries shown in Example E-3.
Example E-3 Oracle Database as the Web Clipping Repository
<repositoryInfo class="oracle.portal.wcs.provider.info.JdbcDbInformation"> <connectionName>jdbc/portletPrefs</connectionName> <useRAA>false</useRAA> <useASO>false</useASO> </repositoryInfo>
For information about tag parameters, see Section E.2.1.4, "Attributes and Child Tags of the repositoryInfo Tag."
Use the database schema, created for an Oracle database 9i
or later, where you can manually specify connection information.
To specify Oracle 9i
or later database as the Web Clipping repository, specify database connection parameters in the entry shown in Example E-4.
Example E-4 Setting Oracle Database 9i or Later as Web Clipping Repository
<repositoryInfo class="oracle.portal.wcs.provider.info.DatabaseInformation"> <useRAA>false</useRAA> <databaseHost>dbhost.mycompany.com</databaseHost> <databasePort>1521</databasePort> <databaseSid>iasdb</databaseSid> <databaseUsername>scott</databaseUsername> <databasePassword>!tiger</databasePassword> <useASO>false</useASO> </repositoryInfo>
For information about tag parameters, see Section E.2.1.4, "Attributes and Child Tags of the repositoryInfo Tag."
If you require a secure database connection, then enable the Advanced Security Option (ASO) by setting the useASO
entry to true
. For more information about configuring ASO, see Section E.2.3, "Web Clipping Producer Security."
Note: Only one entry of<repositoryInfo> can exist in provider.xml . Depending on the Web Clipping repository you choose, you must uncomment only that entry. |
Save the provider.xml
file.
Restart Integrated WLS.
Table E-6 lists and describes the attributes and child tags of the repositoryInfo
tag.
Note: The attributes and child tags of therepositoryInfo tag are also described in the comments in the Web Clipping provider.xml file.
In the comments in the |
Table E-6 Attributes and Child Tags of the repositoryInfo Tag
Attributes/Parameter | MDS/Database | Description |
---|---|---|
Both |
The
|
|
MDS |
Use the
|
|
Database |
Specifies the JNDI name of the data source where the Web Clipping repository has been installed using the RCU. By default, the connection name is In an interoperability scenario where an Oracle WebLogic Server 11g Middle Tier is paired with an Oracle Application Server 10g repository, the connection points to the |
|
Database |
Set to
|
|
Database |
Set to
|
|
Database |
Specify the host name of the Oracle database. Use only version 9i or later. For example: mycompany.dbhost.com |
|
Database |
Specify the port number of the Oracle database listener. This is usually |
|
Database |
Specify the Oracle SID of the database that hosts the Web Clipping repository. |
|
Database |
Enter the user name used to log in to the database. |
|
Database |
Enter a plain text password for the specified database user name. Prefix the password with an exclamation point (!) to allow the Web Clipping producer to encrypt the password when the producer starts. For example: !AX3tR |
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 by manually editing the provider.xml
file.
WebCenter Portal application administrators can set proxy settings manually according to the HTTP or HTTPS configuration. Edit the appropriate entries in the provider.xml
file.
Example E-5 shows the relevant portion of provider.xml
.
Example E-5 Proxy Settings
- <!-- proxy information: Fill the following up if you have a proxy server between the provider and external sites. <proxyInfo class="oracle.portal.provider.v2.ProxyInformation"> <httpProxyHost>proxy.mycompany.com</httpProxyHost> <httpProxyPort>80</httpProxyPort> <dontProxyFor>*.mycompany.com</dontProxyFor> <proxyUseAuth>true</proxyUseAuth> <proxyType>Basic</proxyType> <proxyRealm>realm1</proxyRealm> <proxyUseGlobal>false</proxyUseGlobal> <proxyUser>scott</proxyUser> <proxyPassword>!tiger</proxyPassword> </proxyInfo> -->
It is optional to specify values for the following tags: <proxyUseAuth>
, <proxyType>
, <proxyRealm>
, <proxyUseGlobal>
, <proxyUser>
, and <proxyPassword>
.
Table E-3, available earlier in this appendix, describes the proxy settings you specify in the provider.xml
file. The descriptions in the table are applicable for Web Clipping producers also.
The preceding sections described the administrative tasks that must be performed before you are able to use the Web Clipping producer. The following sections describe some security configuration options that you must implement to enable the Web Clipping producer to access Secure Sockets Layer (SSL)-enabled web sites and encrypt the channel between itself and the database:
When a user navigates to a secure site, the web site typically returns a certificate, identifying itself to the user when asking for secure information. If the user accepts the certificate, then the certificate is placed into the list of trusted certificates of the browser so that a secure channel can be opened between the browser and that server. Like a web browser, the Web Clipping producer acts as an HTTP client to external web sites. To keep track of trusted sites, the Web Clipping producer uses the cacerts
file, which is the Java keystore to store trusted certificates.
By default, the cacerts
file stores various certificates including the Equifax, VeriSign, and Cybertrust certificates. However, it does not include all possible server certificates that exist on the web. For this reason, when a user navigates to a secure server using HTTPS, the user can get an SSL handshake failed exception in the Web Clipping Studio. To solve this problem, you must add the certificate of that site to the cacerts
file.
To add a certificate to the cacerts
file:
Download the certificate of the HTTPS web site and save the certificate in the PEM format.
Tip: Mozilla Firefox 3.0 or later enable you to save a certificate file in the PEM format. |
Locate the path to the cacerts
file:
Log in to the Oracle WebLogic Server Administration Console by using the following URL format:
http://
host:port
/console
Open the Keystore tab for the WLS_Portlets managed server.
Note down the location of the cacerts
file given in the Java Standard Trust Keystore field.
At the command prompt, navigate to the location of the cacerts
file and run the following command to add the certificate:
keytool -importcert -alias
certi_alias
-file
certifi_name
-keystore cacerts -storepass
password
Where, certi_alias
refers to the alias used for the certificate, certifi_name
refers to the certificate file name, and password
refers to the password of the cacerts
file. The default password is changeit
.
For example,
keytool -importcert -alias stamf05 -file stamf05.crt -keystore cacerts -storepass changeit
Tip: It is advisable to import trusted certificate into thecacerts file by using an alias. It makes it easier for you to delete or list the entries in the keystore. |
The Web Clipping producer can use Oracle Advanced Security Option (ASO) to secure and encrypt the channel between itself and the database that hosts the Web Clipping repository. This feature is available only if you have selected any Oracle database as the Web Clipping repository. This feature is disabled by default as Oracle Metadata Services is the default Web Clipping repository in Oracle JDeveloper.
To enable ASO:
Open provider.xml
in a text editor.
Under the repository settings section in the file (shown in Example E-3), set the useASO
entry to true
.
Save the provider.xml
file.
In addition, you must set the following ASO configuration parameters in the sqlnet.ora
file to ensure that the database connections created between the Web Clipping producer and the database hosting the Web Clipping repository are using ASO.
SQLNET.AUTHENTICATION_SERVICES
-- This parameter is used to select a supported authentication method in making database connections with ASO. For more information about setting this parameter, see the Oracle Database Advanced Security Administrator's Guide.
SQLNET.CRYPTO_SEED
-- This parameter denotes the cryptographic seed value (FIPS 140-1 setting), used in making database connections with ASO.
For more information about setting parameters and about the values to use for various possible combinations of parameters, see the Oracle Database Advanced Security Administrator's Guide.
Note: When setting these parameters after the initial configuration (where the database parameters are already set up), database connections are assumed to be open. Because enabling the ASO affects all connections made to the database, it is advisable to restart Integrated WLS containing the Web Clipping producer to reset all the current connections to use ASO. You must also do this when disabling ASO. |
If you do not want all users to be able to see the WSRP test page, you can protect it so that only administrators can see it. To do this, add the code shown in Example E-6 to the web.xml
file.
Example E-6 Hiding the WSRP Test Page
<security-role> <description>AdministratorRole</description> <role-name>Admin</role-name> </security-role> <security-constraint> <display-name>TestPageInfo</display-name> <web-resource-collection> <web-resource-name>TestPageInfo</web-resource-name> <description>Protect the test page servlet.</description> <url-pattern>/info/*</url-pattern> </web-resource-collection> <auth-constraint> <description>Administrators</description> <role-name>Admin</role-name> </auth-constraint> <user-data-constraint> <transport-guarantee>NONE</transport-guarantee> </user-data-constraint> </security-constraint>
If you want to remove the WSRP test page completely, you must modify the web.xml
file to comment out the element shown in Example E-7.
Note: This element is injected intoweb.xml at packaging time, so you must edit the web.ml file in the resulting EAR file. |
The portlet preference store is used for persisting consumer registration handles and portlet preference data. Portlet producers can use one of three types of preference store: File, Database and Consumer.
Using a consumer preference store ensures that the preference store data is always stored with the consumer application. Whatever happens to the producer over time, the consumer application's registrations and portlets continue to be valid while the producer connections point to functionally compatible producers (that is, the producer should be able to decode the portlet name from the portlet handle and be able to resolve this to the portlet that the consumer application developer expects). When this mechanism is used, the producer itself stores no persistent state whatsoever, meaning that a producer can be switched for another compatible one at any time, with no requirement to perform a preference store migration or export/import cycle.
In a clustered environment, Oracle recommends the use of a database or consumer preference store. If you prefer to use a file-based preference store, then you must also use a shared file system.
If you configure the WebLogic Server to run portlet applications, then the database preference store is configured for you. For more information, see the Oracle Fusion Middleware Installation Guide for Oracle WebCenter.
This section contains configuration information for the following areas:
WSRP producers have a JNDI preference value that determines which preference store is used, and is set in the web.xml
file of the portlet application. Table E-7 lists and describes the JNDI variables used to specify the preference store for WSRP producers.
Table E-7 WSRP Producer Database Preference Store-Related JNDI Variable
Variable Name | Variable Value | Description |
---|---|---|
|
Determines which data store (File, Database, or Consumer) is used for persisting a portlet application's consumer registration handles and portlet preferences. |
|
|
|
Defines the path to the root directory to be used by the file preference store. Absolute paths are interpreted relative to the file system root. Relative paths are interpreted relative to the Note that all producers running within the same WebLogic Server must use the same path for this variable. Otherwise, you get a |
The following examples show the entries in a producer's web.xml
file.
Example E-8 Configuring web.xml to Use a Database Preference Store
<env-entry> <env-entry-name>oracle/portal/wsrp/server/persistentStore</env-entry-name> <env-entry-type>java.lang.String</env-entry-type> <env-entry-value>Database</env-entry-value> </env-entry>
Example E-9 Configuring web.xml to Use a File-Based Preference Store
<env-entry> <env-entry-name>oracle/portal/wsrp/server/persistentStore</env-entry-name> <env-entry-type>java.lang.String</env-entry-type> <env-entry-value>File</env-entry-value> </env-entry> <env-entry> <env-entry-name>oracle/portal/wsrp/server/fileStoreRoot</env-entry-name> <env-entry-type>java.lang.String</env-entry-type> <env-entry-value>myPrefStore</env-entry-value> </env-entry>
Example E-10 Configuring web.xml to Use a Consumer Preference Store
<env-entry> <env-entry-name>oracle/portal/wsrp/server/persistentStore</env-entry-name> <env-entry-type>java.lang.String</env-entry-type> <env-entry-value>Consumer</env-entry-value> </env-entry>
When you have updated the relevant web.xml
files, restart your WebLogic Server.
The type of preference store used for PDK-Java producers is determined by the preferenceStore
tag in the provider.xml
file. Table E-8 lists and describes the attributes and parameters used with the preferenceStore
tag when a database preference store is specified.
Table E-8 Attributes and Parameters of the preferenceStore Tag
Attribute/Parameter | Description |
---|---|
This required attribute specifies the Java class that defines the location and other details of portlet preferences. For example, a file-based preference store might use:
A database preference store might use:
OmniPortlet uses its own class, for example:
|
|
This required parameter provides a name for the preference store. Use any value you choose. For example:
<preferenceStore class="oracle.portal.provider.v2.preference.DBPreferenceStore">
<name>MyPDKProducerPreferenceStore</name>
</preferenceStore>
|
|
This required parameter for a database preference store points to a JNDI connection that connects with a schema containing the portlet preference store. For example:
<preferenceStore class="oracle.portal.provider.v2.preference.FCFDBPreferenceStore">
<name>MyPDKProducerPreferenceStore</name>
<connection>java:comp/env/jdbc/portletPrefs</connection>
</preferenceStore>
|
|
|
This optional parameter specifies the location where the file-based preference store preferences are stored.When this parameter is not included with the |
|
This optional parameter is used when specifying a file based preference store, and accepts the value For example: <preferenceStore class="oracle.portal.provider.v2.preference.FilePreferenceStore"> <name>PDKProducerPreferenceStore</name> <useHashing>true</useHashing> </preferenceStore> |
A preference store is a mechanism for storing information like user preference data, portlet and producer settings, or even portlet data. Preferences can be stored in a database, which is recommended for high availability configurations, a file system, or with the consuming application. You can migrate the following stores for your WebCenter Portal applications:
Section E.5.1, "JPS Portlet Preference Store - PersistenceMigrationTool"
Section E.5.2, "PDK-Java Portlet Preference Store - Migration and Upgrade Utilities"
A WSRP container preference store is a mechanism used for persisting consumer registration and portlet preference data. Currently, there are three preference store implementations, database preference store, file-based preference store, and consumer preference store. A database preference store persists data using a relational database. A file-based preference store persists data using the file system. A consumer preference store ties the producer metadata to the consumer application. A file-based or consumer preference store may be used for testing, since it removes the dependency on a database. But, for highly available configurations, Oracle recommends that you use a database or consumer preference store.
The WSRP container preference store migration utility, PersistenceMigrationTool
, enables you to migrate existing data between database and file-based preference stores (for example, from a database preference store to a file preference store). This utility also enables upgrading users to ensure that their existing locale-specific portlet preference data uses a naming format compatible with the latest JPS release. You can also use this utility to migrate between source and destination stores of the same type, enabling data to be moved from one database store to another.
Note: You cannot use the preference store migration utility to migrate to or from a consumer preference store. To migrate to or from a consumer preference store, you must export the data from one producer from the consumer and import into another.
For information about exporting and importing producers using JDeveloper, see Section E.6, "Exporting and Importing Portlet Producers at Design Time." For information about exporting and importing producers using WLST, see the section "Exporting and Importing Custom WebCenter Applications for Data Migration" in the Oracle Fusion Middleware Administrator's Guide for Oracle WebCenter. |
The syntax of the PersistenceMigrationTool
is:
Note: You must set the classpath when running this tool to includeportlet-producer-container-persistence.jar , oracle.portlet-api.jar and ojdbc6.jar . For example:
java -classpath \ WC_ORACLE_HOME/webcenter/modules/oracle.portlet.server_11.1.1/oracle-portlet-api.jar: WC_ORACLE_HOME/webcenter/modules/oracle.portlet.server_11.1.1/portlet-producer-container-persistence.jar: WC_HOME/server/lib/ojdbc6.jar \oracle.portlet.server.containerimpl.PersistenceMigrationTool |
java oracle.portlet.server.containerimpl.PersistenceMigrationTool -sourceType [file | db] -destType [file | db] {-sourcePath [dir | -sourceUsername username -sourcePassword password -sourceDatabase db]} {-destPath [dir | destUsername username -destPassword password -destDatabase db]} [-debug]
where
sourceType
indicates whether the source store is in a file or database. You can have source and destination stores of the same type. Hence, you can migrate from one database to another or one file system to another.
destType
indicates whether the destination store is in a file or database. You can have source and destination stores of the same type. Hence, you can migrate from one database to another or one file system to another.
sourcePath
is the location of a file-based preference store. This argument is required when sourceType
is file
.
sourceUsername
is the database user name for a preference store database. This argument is required when sourceType
is db
.
sourcePassword
is the database password for a preference store database. This argument is required when sourceType
is db
.
sourceDatabase
is the name of a preference store database. This argument is required when sourceType
is db
.
destPath
is the location of a file-based preference store. This argument is required when destType
is file
.
destUsername
is the database user name for a preference store database. This argument is required when destType
is db
.
destPassword
is the database password for a preference store database. This argument is required when destType
is db
.
destDatabase
is the name of a preference store database. This argument is required when destType
is db
.
debug
turns on full logging through standard output to enable users to diagnose issues that arise when the tool runs.
Example E-11 demonstrates running the PersistenceMigrationTool
utility. In this example, preferences from a database store are copied to a file store.
Example E-11 Running the PersistenceMigrationTool Utility
java -classpath \ WC_ORACLE_HOME/webcenter/modules/oracle.portlet.server_11.1.1/oracle-portlet-api.jar: WC_ORACLE_HOME/webcenter/modules/oracle.portlet.server_11.1.1/portlet-producer-container-persistence.jar: WC_HOME/server/lib/ojdbc6.jar \oracle.portlet.server.containerimpl.PersistenceMigrationTool -sourceType db \ -sourceUsername scott \ -sourcePassword tiger \ -sourceDatabase abc.mycompany.com:1521:yourdatabase \ -destType file \ -destRoot /data/prefs
PDK-Java has two PreferenceStore
implementations, DBPreferenceStore
and FilePreferenceStore
. DBPreferenceStore
persists data using a JDBC-compatible relational database and FilePreferenceStore
persists data using the file system.
If you have installed Oracle PDK, then you can manage the information stored in the preference store by using the Preference Store Migration and Upgrade Utility, which is included in the pdkjava.jar
file. Note that you must run this tool from WC_ORACLE_HOME
. The syntax of the migration utility is:
Note: You must set the classpath when running this tool to includepdkjava.jar , ptlshare.jar , and ojdbc6.jar . For example:
java -classpath WC_ORACLE_HOME\jdeveloper\modules\oracle.dms_11.1.1\dms.jar; WC_ORACLE_HOME\wlserver_10.3\server\lib\ojdbc6.jar;WC_ORACLE_HOME\jdeveloper\webcenter\modules\oracle.portlet.server_11.1.1\pdkjava.jar; WC_ORACLE_HOME\jdeveloper\webcenter\modules\oracle.portlet.server_11.1.1\ptlshare.jar oracle.portal.provider.v2.preference.MigrationTool |
java oracle.portal.provider.v2.preference.MigrationTool -mode [file | db | filetodb | filetofile | dbtofile | dbtodb] [-remap language | locale] [-countries iso_country_code] [-pref1UseHashing true | false] [-pref1Driver driver] {-pref1RootDirectory directory | -pref1User username -pref1Password password -pref1URL url} [-pref2UseHashing true | false] [-pref2Driver driver] {-pref2RootDirectory directory | -pref2User username -pref2Password password -pref2URL url} [-upfixwpi filename]
where
-mode
is the mode in which you want to run the Preference Store Migration and Upgrade Utility
filetodb
, filetofile
, dbtofile
, or dbtodb
indicates to run in migration mode. See Section E.5.2.1, "Migration Mode" for more information about this mode.
file
or db
indicates to run in upgrade mode. See Section E.5.2.2, "Upgrade Mode" for more information about this mode.
-remap
is the localePersonalizationLevel
(language or locale). Note that you only must use this option to change localePersonalizationLevel
as part of your upgrade or migration.
-countries
specifies a prioritized list of ISO country codes, indicating your order of preference in a collision between remapped preferences for different countries. -countries
is only meaningful if you also specified the -remap
option.
-pref1UseHashing
specifies whether you want to employ hashing on the source for this operation.
-pref1Driver
is the driver for the source database. If you do not specify this parameter, the nearest matched driver is used.
-pref1RootDirectory
is the path of a source file system, for example, j2ee/home/applications/jpdk/jpdk/WEB-INF/providers/sample
.
-pref1User
is the user name for a source database.
-pref1Password
is the password for a source database.
-pref1URL
is the URL to a source database, for example, jdbc:oracle:thin:@myserver.mydomain.com:1521:mysid
.
-pref2UseHashing
specifies whether you want to employ hashing on the destination for this operation.
-pref2Driver
is the driver for the destination database. If you do not specify this parameter, the nearest matched driver is used.
-pref2RootDirectory
is the path of a destination file system, for example, j2ee/home/applications/jpdk/jpdk/WEB-INF/providers/sample
.
-pref2User
is the user name for a destination database.
-pref2Password
is the password for a destination database.
-pref2URL
is the URL to a destination database, for example, jdbc:oracle:thin:@myserver.mydomain.com:1521:mysid
.
-upfixwp
i indicates a log file for the operation.
This section includes the following subsections:
Use a migration mode to copy data from a source preference store to a target preference store. When the utility is run in this mode, the preference stores for all the portlet definitions are updated.
Table E-9 describes the migration modes in which you can run the utility.
Table E-9 Migration Modes in Which to Run the Utility
Mode | Description |
---|---|
|
Use when data must be copied from a |
|
Use when data must be copied from one |
|
Use when data must be copied from a |
|
Use when data must be copied from one |
If the destination for the operation is a database, you must ensure that the destination WebLogic Server is created using the WebCenter portlet template and the appropriate schemas have been created using the RCU. For more information, see Oracle Fusion Middleware Installation Guide for Oracle WebCenter.
When using a migration mode, you can also use the -remap
and -countries
options to specify that the data must be upgraded while being migrated. Specifically, you use these options to ensure that the locale-specific preferences are appropriately remapped.
You can use the other options accepted by the utility to specify the properties of the preference stores involved in the upgrade or migration process. These options must correspond to the tags you specify in provider.xml
to describe the preference stores.
Properties beginning with the prefix -pref1
correspond to properties of the source preference store (in an upgrade mode, this is the only preference store). For example, specifying -pref1UseHashing true -pref1RootDirectory j2ee/home/applications/jpdk/jpdk/WEB-INF/providers/sample
sets the useHashing
and rootDirectory
properties of a source FilePreferenceStore
.
When a migration basic mode is selected, properties beginning with the prefix -pref2
correspond to properties of the target preference store. For example, specifying -pref2User portlet_prefs -pref2Password portlet_prefs -pref2URL jdbc:oracle:thin:@myserver.mydomain.com:1521:mysid
sets the database connection details on a target DBPreferenceStore
.
Example E-12 PDK-Java Migration Utility Command Line, Migration
java -classpath WC_ORACLE_HOME/webcenter/modules/oracle.portlet.server_11.1.1/pdkjava.jar: WC_ORACLE_HOME/webcenter/modules/oracle.portlet.server_11.1.1/ptlshare.jar:WC_ORACLE_HOME/ucm/shared/classes/ojdbc14.jar \ oracle.portal.provider.v2.preference.MigrationTool \ -mode dbtofile \ -pref1User portlet_prefs \ -pref1Password portlet_prefs \ -pref1URL jdbc:oracle:thin:@myserver.mydomain.com:1521:mysid \ -pref2RootDirectory /mydirectory/preferences
Use an upgrade mode to upgrade data in place, and to modify existing locale-specific preferences in the preference store so that the naming format used is compatible with the current version of Oracle Portal and a given localePersonalizationLevel
setting.
Table E-10 describes the upgrade modes in which you can run the utility.
Table E-10 Upgrade Modes in Which to Run the Utility
Mode | Description |
---|---|
|
Use when data in a |
|
Use when data in a |
An upgrade mode can be used in the following scenarios:
You have upgraded from Oracle PDK 9.0.4.0.0 or earlier and want to use existing portlets with the default localePersonalizationLevel
setting of language (In earlier releases, the default setting was locale
).
You have upgraded from Oracle Portal 9.0.2.0.0 or earlier and want to use existing portlets with a localePersonalizationLevel
setting of locale
(Oracle Portal now uses different names for some locales and therefore some existing data must be remapped).
You want to change the localePersonalizationLevel
for an existing portlet from locale
to language
or vice-versa.
When using an upgrade mode, you must use the -remap
option to specify the localePersonalizationLevel
(language
or locale
) that you are upgrading to. You can also use the -countries
option to specify a prioritized list of ISO country codes, indicating your order of preference in a collision between remapped preferences for different countries. For example, if you specify -remap language -countries GB,US
in the command, then it means that if the utility comes across both US English and British English preferences (en_US
and en_GB
) in a given preference store, it remaps the British English preference to become the English-wide preference (en
).
Example E-13 PDK-Java Migration Utility Command Line, Upgrade
java -classpath WC_ORACLE_HOME/webcenter/modules/oracle.portlet.server_11.1.1/pdkjava.jar: WC_ORACLE_HOME/webcenter/modules/oracle.portlet.server_11.1.1/ptlshare.jar:WC_ORACLE_HOME/ucm/shared/classes/ojdbc14.jar \ oracle.portal.provider.v2.preference.MigrationTool \ -mode file -remap language -countries GB,US -pref1UseHashing true -pref1RootDirectory j2ee/home/applications/jpdk/jpdk/WEB-INF/providers/sample
Web Clipping does not have a preference store as such, but it stores Web Clipping definitions and associated metadata. By default, it uses MDS, which is file-based, for this purpose. But you can configure Web Clipping to use a database. To migrate this repository for WebCenter Portal applications, you can use the Predeployment tool in export and import mode to go from MDS to a database, or vice versa. This procedure must be done for each application as follows:
Run the Predeployment tool in export
mode on all WebCenter Portal applications that use the Web Clipping producer. For more information, see Section 60.2.10, "How to Implement Export of Customizations (WSRP 2.0)."
Update the producer to use a different repository. For information, see Section E.2.1.3, "Configuring Web Clipping Repository in provider.xml."
Run the Predeployment tool in import
mode on all WebCenter Portal applications that use the Web Clipping producer. For more information, see Section 60.2.10, "How to Implement Export of Customizations (WSRP 2.0)."
In some situations, you may want to move a portlet producer. To do so, you must:
Install the new producer.
Make the preference store of the original producer available to the new producer by performing one of the following tasks:
Migrate the preference store using the Preference Store Migration and Upgrade Utilities (see Section E.5.2, "PDK-Java Portlet Preference Store - Migration and Upgrade Utilities" for more information), or
Configure the new producer to use the same preference store as the original producer. If the database preference store is being used, then you must point the WebLogic Server data source to the same database as the original producer.
Update the URL of the producer registration by using Enterprise Manager Fusion Middleware Control or the WLST commands: setWSRPProducerRegistration
or setPDKJavaProducerRegistration
.
You can export and import portlet producers at design time.
This section includes the following subsections:
When you package an application for deployment, any portlet producers referenced by the application are contacted so that the producer data can be included in the MAR file. If any of the producers are not running, they cannot be contacted and the data cannot be included.
By creating an export archive of the producer data at design time instead, you can ensure that the producers are running, therefore all the producer data, including remote customizations and client-side metadata, can be retrieved. WebCenter Framework can then use the export archive at deployment, instead of having to contact the remote producers.
To export portlet producers at design time:
Edit the WC_ORACLE_HOME
/jdeveloper/jdev/bin/jdev.conf
file and set the following JVM flag:
AddVMOption -Doracle.webcenter.portlet.dt.disableRemoteExport=true
Setting this flag ensures that, when the application is packaged for deployment, the export archive you create in the following steps is included in the MAR file, rather than the remote producers being contacted to retrieve producer data.
Restart JDeveloper to apply the new setting.
Open the application that consumes the producers to export.
From the menu, choose Application and then Export Portlet Producers.
This menu option appears only if the current application contains producers.
In the Export Portlet Producers dialog, in the Export Archive File Name (.ear) field, enter the absolute path and file name to use for the export set.
Click OK.
When the application is packaged for deployment, because you set the disableRemoteExport
flag to true
, WebCenter Framework checks for the presence of the export archive at the location specified in the dialog. If the export archive exists, the contents of the archive are included in the MAR file instead of contacting the remote producers to retrieve producer data.
Note: If thedisableRemoteExport flag is set and there is no export archive, a default export archive, without the remote producer data, is created and included in the MAR file. |
You can import producer data, including customizations made at runtime, from a deployed application into your application at design time.
Note: The producers in the export archive (EAR file) must be the same as those in the application into which they are being imported. |
For information about how to create an export archive of producer metadata from a deployed application, see the section "Exporting Portlet Client Metadata (WebCenter Portal Application)" in the Oracle Fusion Middleware Administrator's Guide for Oracle WebCenter.
To import portlet producers at design time:
Edit the WC_ORACLE_HOME
/jdeveloper/jdev/bin/jdev.conf
file and set the following JVM flag:
AddVMOption -Doracle.webcenter.portlet.dt.enableImport=true
Restart JDeveloper to apply the new setting. This ensures that the Import Portlet Producers menu option is available.
Open the application into which you want to import the producers.
From the menu, choose Application and then Import Portlet Producers.
In the Import Portlet Producers dialog, in the Import Archive File Name (.ear) field, enter the absolute path and file name of the export archive to import.
Click OK.
Note: If the application into which you import producers is currently running in Integrated WLS, you must re-run the application to see the updated producers. Simply refreshing the page may result in errors caused by the different MDS instances used at design time and runtime. |