F Additional Portlet Configuration

F.2.1 Configuring the OmniPortlet Producer to Access Data Outside a Firewall

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.

• To set the proxy information in the command line when starting the WebLogic server, set the parameters as described in Table F-1, if you are using an HTTP Proxy Host, or Table F-2, if you are using an HTTPS Proxy Host.

  Table F-1 HTTP Proxy Information Command Line Parameters

  Parameter	Description
  http.proxyHost	The host name of a proxy server if one is required to make a URL connection from the OmniPortlet producer to its data sources.
  http.proxyPort	The port number for the HTTP Proxy Host.
  http.nonProxyHosts	The name of any domain or hosts to which you can directly connect, bypassing a proxy server, such as your local machine: localhost|localhost.localdomain Hosts can be fully qualified host names or can be IP addresses.
  http.proxyUser	The user to log in to the proxy server if the proxy server requires authentication.
  http.proxyPassword	The password to log in to the proxy server if the proxy server requires authentication.
  http.proxyAuthType	The authentication type of the proxy server. Acceptable values: Basic | Digest.
  http.proxyAuthRealm	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 F-2 HTTPS Proxy Information Command Line Parameters

  Parameter	Description
  https.proxyHost	The host name of a proxy server if one is required to make a URL connection from the OmniPortlet producer to its data sources.
  https.proxyPort	The port number for the HTTPS Proxy Host.
  https.nonProxyHosts	The name of any domain or hosts to which you can directly connect, bypassing a proxy server, such as your local machine: localhost|localhost.localdomain Hosts can be fully qualified host names or can be IP addresses.
  https.proxyUser	The user to log in to the proxy server if the proxy server requires authentication.
  https.proxyPassword	The password to log in to the proxy server if the proxy server requires authentication.
  https.proxyAuthType	The authentication type of the proxy server. Acceptable values: Basic | Digest.
  https.proxyAuthRealm	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 F-3 for a list of parameters and their descriptions.

  Table F-3 Provider.xml Tags

  Parameter	Description
  httpProxyHost	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.
  httpProxyPort	Enter the port number for the HTTP Proxy Host.
  dontProxyFor	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: *.company.com, *.us.company.com Hosts can be fully qualified host names or can be IP addresses.
  proxyUseAuth	Acceptable values: true | false Enter true if your proxy server requires authentication. The authentication parameters are specified by the following tags: proxyType, proxyRealm, proxyUseGlobal, proxyUserName, and proxyPassword.
  proxyType	Acceptable values: Basic | Digest Choose the type of proxy server this provider. For more information about basic or digest authentication, see http://www.faqs.org/rfcs/rfc2617.html.
  proxyRealm	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.
  proxyUseGlobal	Acceptable values: true | false If true, then the <proxyUser> and <proxyPassword> values are used for all users. Users do not see the Proxy Authentication section on the Source tab and Personalize page. If false, then page designer must log in using the Proxy Authentication section on the Source tab when they define the portlet. The end user must log in using the Proxy Authentication section on the Personalize screen. If <proxyUsername> and <proxyPassword> are given, then they are only used for public users.
  proxyUserName	Enter the user name to log in to the proxy server.
  ProxyPassword	Enter the password for the specified user name. You must prefix ! before your plain password text. It is then encrypted in the provider.xml file for protection when the producer starts.

  
  

  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>
  

F.2.2 Configuring the OmniPortlet Producer to Access Other Relational Databases

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/technology/index.html).

This section contains the following steps:

• Section F.2.2.1, "Installing DataDirect JDBC Drivers"

• Section F.2.2.2, "Registering DataDirect Drivers in OmniPortlet"

F.2.3 Configuring Portal Tools and Web Producers (Optional)

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 F.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 F.5, "Portlet Preference Store Migration Utilities"and in the PDK article titled "Installing the DBPreferenceStore Sample (V2)", (with the filename installing.db.preference.store.v2.html) located in the pdksoftware10132.zip file on the Oracle Technology Network (http://www.oracle.com/technology/products/webcenter/index.html).

1. 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:

   1. Navigate to the WebCenter Oracle home directory using the following command:

      cd WC_ORACLE_HOME
      

   2. 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 F.5, "Portlet Preference Store Migration Utilities" for more information about the PDK Preference Store Migration Utility.

2. 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:

   1. 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.

   2. You can change the HTTP Proxy settings in the provider.xml file. For more information, see Section F.2.1, "Configuring the OmniPortlet Producer to Access Data Outside a Firewall."

   3. 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.

3. Restart middle tier M2.

4. Update portlet producer registration in your custom WebCenter application. Change the first part of the producer registration URL from http://m1.abc.com:7777/ to http://lbr.abc.com/.

5. 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.

F.3.1 Web Clipping Repository Configuration

Web clippings have definitions that must be stored persistently in an Oracle Metadata Services (MDS) store or an Oracle database.

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.

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 F-1 shows the Provider Test Page of Web Clipping.

Figure F-1 Web Clipping - Provider Test Page

Description of "Figure F-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.

> find DOMAIN_DIR -name "provider.xml" | grep -i webClipping

JDEV_SYSTEM_DIRECTORY/DefaultDomain/servers/DefaultServer/tmp/_WL_user/portalTools_11.1.1.2.0/RANDOMLY_GENERATED_DIRECTORY/war/WEB-INF/providers/webClipping/provider.xml

FMW_HOME/user_projects/domains/wc_domain/servers/WLS_Portlet/tmp/_WL_user/portalTools_11.1.1.2.0/RANDOMLY_GENERATED_DIRECTORY/war/WEB-INF/providers/webClipping/provider.xml

This section includes the following subsections:

• Section F.3.1.1, "Using Oracle Metadata Services (MDS) as the Web Clipping Repository"

• Section F.3.1.2, "Using an Oracle Database as the Web Clipping Repository"

• Section F.3.1.3, "Configuring Web Clipping Repository in provider.xml"

• Section F.3.1.4, "Attributes and Child Tags of the repositoryInfo Tag"

  <repositoryInfo class="oracle.portal.wcs.provider.info.MdsInformation">
    <mdsConfigLocation>mds-config.xml</mdsConfigLocation> 
  </repositoryInfo>

JDEV_SYSTEM_DIRECTORY/DefaultDomain/servers/DefaultServer/tmp/_WL_user/portalTools_11.1.1.2.0/RANDOMLY_GENERATED_DIRECTORY/war/WEB-INF

<property name="metadata-path" value="portletdata/tools/webClipping"/>

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

MW_HOME/wlserver_10.3/wc_domain/servers/WLS_Portlet/tmp/_WL_user/portalTools_11.1.1.2.0/yyggl7/war/WEB-INF

mycompany.dbhost.com

!AX3tR

F.3.2 HTTP or HTTPS Proxy Configuration

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 application administrators can set proxy settings manually according to the HTTP or HTTPS configuration. Edit the appropriate entries in the provider.xml file.

Example F-5 shows the relevant portion of provider.xml.

- <!-- 
 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 F-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.

F.3.3 Web Clipping Producer Security

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:

• Section F.3.3.1, "Adding Certificates for Trusted Sites"

• Section F.3.3.2, "Configuring Oracle Advanced Security for the Web Clipping Producer"

F.4.1 WSRP Producers

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 F-7 lists and describes the JNDI variables used to specify the preference store for WSRP producers.

The following examples show the entries in a producer's web.xml file.

<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>

<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>

When you have updated the relevant web.xml files, restart your WebLogic Server.

F.4.2 PDK-Java Producers

The type of preference store used for PDK-Java producers is determined by the preferenceStore tag in the provider.xml file. Table F-8 lists and describes the attributes and parameters used with the preferenceStore tag when a database preference store is specified.

<preferenceStore class="oracle.portal.provider.v2.preference.DBPreferenceStore">
  <name>MyPDKProducerPreferenceStore</name>
</preferenceStore>

<preferenceStore class="oracle.portal.provider.v2.preference.FCFDBPreferenceStore">
  <name>MyPDKProducerPreferenceStore</name>
  <connection>java:comp/env/jdbc/portletPrefs</connection>
</preferenceStore>

<preferenceStore class="oracle.portal.provider.v2.preference.FilePreferenceStore">
  <name>PDKProducerPreferenceStore</name>
  <useHashing>true</useHashing>
</preferenceStore>

F.5.1 JPS Portlet Preference Store - PersistenceMigrationTool

A WSRP container preference store is a mechanism used for persisting consumer registration and portlet preference data. Currently, there are two preference store implementations, database preference store and file-based preference store. A database preference store persists data using a relational database. A file-based preference store persists data using the file system. A file-based 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 the database preference store.

The WSRP container preference store migration utility, PersistenceMigrationTool, enables you to migrate existing data between different 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.

The syntax of the PersistenceMigrationTool is:

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/wsrp-container.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 F-8 demonstrates running the PersistenceMigrationTool utility. In this example, preferences from a database store are copied to a file store.

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/wsrp-container.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

F.5.2 PDK-Java Portlet Preference Store - Migration and Upgrade Utilities

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:

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]
  {-pref1RootDirectory directory |
   -pref1User username -pref1Password password -pref1URL url}
  [-pref1UseHashing true | false]
  {-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 F.5.2.1, "Migration Mode" for more information about this mode.

• file or db indicates to run in upgrade mode. See Section F.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.

• -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.

• -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.

• -upfixwpi indicates a log file for the operation.

This section includes the following subsections:

• Section F.5.2.1, "Migration Mode"

• Section F.5.2.2, "Upgrade Mode"

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

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

F.5.3 Web Clipping Repository

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 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:

1. Run the Predeployment tool in export mode on all WebCenter applications that use the Web Clipping producer. For more information, see Section 32.1.3, "How to Implement Export/Import of Customizations (WSRP 2.0)."

2. Update the producer to use a different repository. For information, see Section F.3.1.3, "Configuring Web Clipping Repository in provider.xml."

3. Run the Predeployment tool in import mode on all WebCenter applications that use the Web Clipping producer. For more information, see Section 32.1.3, "How to Implement Export/Import of Customizations (WSRP 2.0)."

F.5.4 Moving a Producer

In some situations, you may want to move a portlet producer. To do so, you must:

1. Install the new producer.

2. 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 F.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.

3. Update the URL of the producer registration by using Enterprise Manager Fusion Middleware Control or the WLST commands: setWSRPProducerRegistration or setPDKJavaProducerRegistration.

F.6.1 Exporting Portlet Producers at Design Time

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:

1. 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.

2. In JDeveloper, open the application that contains the producers to export.

3. From the menu, choose Application and then Export Portlet Producers.

   This menu option appears only if the current application contains producers.

4. 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.

5. 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 the disableRemoteExport 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.

F.6.2 Importing Portlet Producers at Design Time

You can import producer data, including customizations made at runtime, from a deployed application into your application at design time.

For information about how to create an export archive of producer metadata from a deployed application, see the section "Exporting Portlet Client Metadata (Custom WebCenter Application)" in the Oracle Fusion Middleware Administrator's Guide for Oracle WebCenter.

1. Edit the WC_ORACLE_HOME/jdeveloper/jdev/bin/jdev.conf file and set the following JVM flag:

   AddVMOption  -Doracle.webcenter.portlet.dt.enableImport=true
   

2. In JDeveloper, open the application into which you want to import the producers.

3. From the menu, choose Application and then Import Portlet Producers.

4. 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.

5. Click OK.