Skip Headers
Oracle® Fusion Applications Administrator's Guide
11g Release 1 (11.1.2)

Part Number E14496-03
Go to Documentation Home
Home
Go to Book List
Book List
Go to Table of Contents
Contents
Go to Feedback page
Contact Us

Go to previous page
Previous
Go to next page
Next
PDF · Mobi · ePub

23 Troubleshooting Oracle WebCenter Portlets

This chapter describes common problems that you might encounter when using Oracle WebCenter portlets and explains how to solve them.

This chapter contains the following topics:

This chapter focuses on troubleshooting Oracle WebCenter portlets. For information about troubleshooting general Oracle WebCenter configuration issues, see the "Troubleshooting WebCenter Application Configuration Issues" section in the Oracle Fusion Middleware Administrator's Guide for Oracle WebCenter. Also, review the Oracle Fusion Middleware Error Messages Reference for information about the error messages you may encounter.

23.1 Introduction to Troubleshooting Oracle WebCenter Portlets

Oracle Fusion Applications utilizes portlet technology in various places, typically to remotely invoke a business view that is implemented as an Oracle Application Development Framework (ADF) task flow. This enables functionality that is implemented on one Oracle Fusion application, for example, HCM, to be incorporated into another Oracle Fusion application, for example, CRM, as if it was embedded in the same application. The CRM application is in fact embedding a portlet that obtains its markup from the remote HCM application, which is running on another server. The task flow that is implemented on the HCM server is made available as a portlet through a component called the Oracle JSF Portlet Bridge. This wrapper makes the task flow available as a portlet producer that can be consumed by another application.

Useful Terminology

The following list defines some common terms for Oracle WebCenter portlets:

Useful Resources

The following list provides some useful resources to use when diagnosing problems with Oracle WebCenter portlets:

Process

Follow the process outlined in Table 23-1 when using the information in this chapter. If the information in a particular section does not resolve your problem, proceed to the next step in this process.

Table 23-1 Process for Using the Information in this Chapter

Step Section to Use Purpose

1

Section 23.2

Perform problem-specific troubleshooting procedures. These section describes:

  • Possible causes of the problems

  • Solution procedures corresponding to each of the possible causes

1

Section 23.3

Perform general diagnostics steps with when you encounter problems with Oracle WebCenter portlets.

2

Section 23.4

Use My Oracle Support to get additional troubleshooting information about Oracle Fusion Applications or Oracle WebCenter portlets. My Oracle Support provides access to several useful troubleshooting resources, including Knowledge Base articles and Community Forums and Discussions.

When you encounter problems with Oracle WebCenter portlets, there are some general diagnostics steps that you can follow.

3

Section 23.4

Log a service request if the information in this chapter and My Oracle Support does not resolve your problem. You can log a service request using My Oracle Support at https://support.oracle.com.


23.2 Problems and Solutions

When running Oracle Fusion Applications, it may not be readily apparent which portions of the user interface are implemented as portlets. The only time this may actually be evident is when there is a problem.

This section describes common problems and solutions. It contains the following topics:

23.2.1 Portlet Displays a Portlet Consumer Error

The message Portlet Consumer Error (shown in Figure 23-1) typically indicates that an error occurred within the operation of the portlet parts of the portlet consumer application. Occasionally, the error may indicate that the remote portlet producer is refusing connection.

Figure 23-1 Portlet Displaying a Portlet Consumer Error

Description of Figure 23-1 follows
Description of "Figure 23-1 Portlet Displaying a Portlet Consumer Error"

Problem 1

An error has occurred within the operation of the portlet parts of the portlet consumer application. In other words, the error is unrelated to the remote portlet producer application.

Solution 1

Consult the diagnostic log file to determine the cause of the exception.

If the DebugErrorRenderer is enabled, the cause exception is displayed in the portlet along with links to the log file. If running in production mode, then consult the consumer-side logs.

The exception that caused the error message to be displayed is logged. Wherever possible, a message is included in the log at the start of the exception stack to indicate for which portlet binding the exception occurred. Example 23-1 shows a message logged for a portlet error.

Example 23-1 Example Message Logged for a Portlet Error

<PortletRenderer> <setErrorState> An error has occured for Portlet Binding
portlet1.
oracle.portlet.client.container.PortletContentTypeException: Unexpected content
type "null" in WSRPGetMarkup response.
...

Pay particular attention to the cause exceptions in the stack as this is likely to indicate what the real underlying problem is.

The cause is likely to be an internal error and the appropriate course of action is to contact Oracle Support.

Problem 2

The remote portlet producer application server is refusing connections completely. This usually occurs when the server is not running. This situation is characterized by the an exception stack on the consumer-side logs similar to that shown in Example 23-2.

Example 23-2 Exception Stack When Portlet Producer Refuses Connection

oracle.portlet.client.container.PortletContentTypeException: Unexpected content
type "null" in WSRPGetMarkup response.
 at oracle.portlet.client.techimpl.wsrp.WSRPBaseTerminalPipe.processException
  (WSRPBaseTerminalPipe.java:109)
 at oracle.portlet.client.techimpl.wsrp.WSRPGetMarkupPipe.execute
  (WSRPGetMarkupPipe.java:248)
...
Caused by: HTTP transport error: java.net.ConnectException: Connection refused
 at oracle.portlet.client.connection.wsrp.HTTPClientTransport.invokeOneWayInternal
  (HTTPClientTransport.java:546)
 at oracle.portlet.client.connection.wsrp.HTTPClientTransport.invoke
  (HTTPClientTransport.java:197)
 at oracle.j2ee.ws.client.StreamingSender._sendImpl(StreamingSender.java:232)
 at oracle.j2ee.ws.client.StreamingSender._send(StreamingSender.java:148)
 at oracle.portlet.wsrp.v2.soap.runtime.WSRP_v2_Markup_Binding_SOAP_Stub.getMarkup(WSRP_v2_Markup_Binding_SOAP_Stub.java:80)

Solution 2

If the cause exception indicates that the remote producer is down, then the resolution is to bring the producer up. You need an understanding of which Oracle Fusion applications are associated with which portlet producers in order to determine which applications need to be started up.

23.2.2 Portlet Displays a Portlet Timeout

If a Portlet Timeout is displayed in the area of the page that you would expect to contain a portlet (as shown in Figure 23-2), this means that the consumer waited for a configured period of time for the producer to respond and did not get a response during that time, or the response did not complete during that time. There are a number of possible causes.

Figure 23-2 Portlet Displaying a Portlet Timeout Error

Description of Figure 23-2 follows
Description of "Figure 23-2 Portlet Displaying a Portlet Timeout Error"

Problem 1

The producer machine is overloaded.

Solution 1

Check the load on the producer managed server (the tools used to do this vary depending on the operating system that is running on the producer). If the load is high, check whether a particular process is causing this high load, and whether such a process could be run on another machine, or at a less busy time. If no single process is causing the high load, or if the Oracle WebLogic Server is causing the high load, and if the load is consistently high, consider whether the producer hardware is adequate, or whether it is necessary to upgrade it (or add further nodes to the cluster). Also consider adjusting the Oracle WebLogic Server configuration to increase the size of the request thread pool. For more information, see the Oracle WebLogic Server documentation.

Problem 2

The network is overloaded, or there are problems with the network affecting communication between the consumer and producer.

Solution 2

Check that you can ping the producer machine from the consumer machine. Check that you can access the producer's WSRP Producer Test Page in your local browser. If this works, check that you can access this same page from a browser running on the consumer machine. If any of these steps cause problems, and the machine is not overloaded, this could be a network problem, which should be investigated by a system administrator.

Problem 3

There is a deadlock (or a stuck thread) on the producer machine causing the request thread to hang.

Solution 3

This should not happen during normal operation. If it does occur, there will generally be an error in the producer's log files indicating the point at which the deadlock occurred. This may help diagnose the problem. In some cases, it may be possible to alleviate this by modifying the configuration of Oracle WebLogic Server. For more information, see the Oracle WebLogic Server documentation.

Problem 4

The producer application is running slowly (for example, due to processing large quantities of data).

Solution 4

In this case, the producer application may be processing large quantities of data, causing it to spend too long building the response. If the application will regularly deal with large quantities of information, it may be necessary to either add or improve producer hardware, or to increase the portlet timeout duration. The portlet timeout can be configured on the producer connection in the consumer application using Enterprise Manager or the WLST setWSRPProducerConnection command. Additionally, minimum and maximum timeouts for all producer connections within the application can be configured within the portlet section of the adf-config.xml file.

Problem 5

The producer application is waiting for a response from another resource, such as a database, that is taking too long (for example, if the database is overloaded).

Solution 5

Check that the resource in question is functioning correctly. If it is, the solution the same as Solution 4.

Problem 6

The producer application is being debugged and has hit a breakpoint.

Solution 6

This only happens if the producer application Oracle WebLogic Server is running in debug mode, and a debugger has been connected. In this case, if an incoming request causes a breakpoint to be triggered, the execution of the producer application stops and the consumer times out when the portlet timeout interval is reached. This scenario is unlikely to occur in a production environment.

Problem 7

The portlet timeout values in adf-config.xml have been misconfigured such that the timeout period is too short.

Solution 7

The portlet section of the adf-config.xml file allows minimum, maximum, and default values for portlet timeouts to be configured across the whole application. The maximum timeout imposes an upper limit on timeouts specified by portlet producers, so if the maximum timeout is too short, this could cause unwanted portlet timeout errors even if the timeout specified on the producer connection is longer.

23.2.3 Portlet Displays a Remote Portlet Communication Error

When a section of the screen shows the Remote Portlet Communication Error message (as shown in Figure 23-3), and there is an otherwise blank region surrounding it, this area is expected to be filled with a portlet, which the application is not able to contact.

Figure 23-3 Portlet Displaying a Remote Portlet Communication Error

Description of Figure 23-3 follows
Description of "Figure 23-3 Portlet Displaying a Remote Portlet Communication Error"

Problem 1

The producer is down.

Solution 1

It could be that the producer application is not running, or the managed server on which it is deployed is not started. In this case, it will need to be started. Identify the application that needs to be started based on the task being attempted at the time of the portlet failure.

Problem 2

The web services security is incorrectly configured.

Solution 2

In Oracle Fusion Applications deployments, web services security (WS-Security) is managed with global web services security policies.

Troubleshooting steps for web services security depend on the type of security profile being used, for example AuthN, SSL, or Message Security.

For more information about troubleshooting web service security, see:

For information about the different types of security profile, see the "Locking Down Web Services: Points to Consider" section in the "Hardening Backchannel Network and Services" chapter of the Oracle Fusion Applications Security Hardening Guide.

The security policies set on the portlet producer's WSRP_v2_Service web service ports are as follows:

  • WSRP_v2_ServiceDescription_Service port: oracle/no_authentication_service_policy

  • WSRP_v2_PortletManagement_Service port: oracle/no_authentication_service_policy

  • WSRP_v2_Markup_Service port: no policy specified, so that it picks up the globally attached policy

  • WSRP_v2_Registration_Service port: oracle/no_authentication_service_policy

If the producer ports are configured in any other way, then it may be the cause of the problem. In particular, if a local policy is applied to the WSRP_v2_Markup_Service port, and the policy does not match the corresponding policy on the producer connection, then the port or the connection will need to be updated to specify matching policies, or be removed, so that the globally attached policies can take effect.

Problem 3

The producer managed server cannot be reached.

Solution 3

The producer may be in a location that cannot be reached by the consumer application, due to intervening firewalls or incorrect routing rules. In an environment that is installed by Oracle's provisioning software, this should not be the case, but it is worth checking that you are able to access the WSDL endpoint for the producer from the machine hosting the consumer, by going to:

http://host:port/context-root/portlets/wsrp2?WSDL

Where:

  • host is the server to which the portlet producer is deployed

  • port is the port to which the server is listening for HTTP requests

  • context-root is the producer web application's context root

For example:

http://portlets.example.com:9999/sample/portlets/wsrp2?WSDL

23.2.4 Portlet Displays a Remote Portlet Error

If the portlet displays a Remote Portlet Error (as shown in Figure 23-4), this indicates that the producer responded with an error message. The error message is returned in the form of a SOAP fault message inside the response document. There are a number of reasons the producer might return an error. The best strategy to diagnose these errors is to first find the corresponding exception stack trace in the consumer diagnostic logs. This stack trace shows what kind of fault was returned by the producer, plus any further information required in the response. Some faults you may encounter are listed in the following sections.

Figure 23-4 Portlet Displaying a Remote Portlet Error

Description of Figure 23-4 follows
Description of "Figure 23-4 Portlet Displaying a Remote Portlet Error"

Problem 1

OperationFailedException. This is the most common type of Remote Portlet Error and it is a catch-all for most unhandled exceptions raised in the producer application.

Solution 1

To resolve an OperationFailedException, examine the exception in the consumer diagnostic logs. This generally shows any exception that was raised in the producer application to trigger the fault response as the final Caused by exception.

If required, you can then examine the diagnostic logs on the producer application for more detail, or for any related exceptions that occurred prior to the fault being triggered. In some cases, the exception in the producer log indicates a problem that can be simply resolved, such as a database connection failure or configuration problem. In other cases, the exception might indicate a product bug.

Problem 2

InvalidRegistrationException. This error indicates that the producer has not been properly registered with the consumer before the consumer attempted to communicate with it. This could also occur if the producer's preference store has been moved or deleted since the consumer registered it.

Solution 2

This error should not occur in the Oracle Fusion Applications environment. If it is observed, the most likely cause is a problem during provisioning. It is also worth checking the producer application's web.xml file setting to ensure that the entry shown in Example 23-3 is present.

Example 23-3 Persistent Store Setting in web.xml

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

Problem 3

InvalidHandleException. This indicates that the consumer has asked the producer to render, or otherwise interact with, a portlet instance that the producer does not know about. This could occur if the producer's preference store has been corrupted in some way since the portlet was added to the page.

Solution 3

This error should not occur in the Oracle Fusion Applications environment. It is most likely caused by a problem during provisioning, or a missing persistentStore setting in the web.xml file, as described in Solution 2.

Problem 4

AccessDeniedException. This indicates that the producer application decided that the current user did not have access to the portlet or task flow in question.

Solution 4

This error should not occur in the Oracle Fusion Applications environment. This could either be a legitimate error message or an indication of a configuration problem. In most cases, Oracle Fusion Applications should deal with authorization errors gracefully, without a Portlet Remote Error being displayed.

23.2.5 Portlet Displays a Server Connection Failed Dialog

If the portlet displays a dialog containing the message "A connection to the server has failed" (as shown in Figure 23-5), this indicates that the producer responded to a portlet resource proxy request with an error message.

Figure 23-5 The Server Connection Failed Dialog

Description of Figure 23-5 follows
Description of "Figure 23-5 The Server Connection Failed Dialog"

Portlet resource proxy requests are made from the browser for any partial page render (PPR) request from the portlet. There are a number of reasons the producer might return an error.

The best strategy to diagnose these errors is first to find the corresponding exception stack trace in the consumer diagnostic logs. You can use the ECID in the error dialog to find the relevant exceptions in the log files. The stack trace shows what kind of fault was returned by the producer, plus any further information. You may also use other tools, such as Firebug, to look at the response of the request.

Problem

PortletTimeoutException. This exception means that the consumer has waited longer than the configured time out period for a response from the producer. This may happen if the system is under excessive load, or it may indicate problems in the producer application, for example, a slow database connection. Note that you will typically not see any errors logged in the producer application in this scenario, this is an indication that the producer is slow, not that anything is causing errors.

Solution

To resolve a PortletTimeoutException, use the Oracle Enterprise Manager Fusion Middleware Control Console or the Oracle WebLogic Server Administration Console console to look at the health of the producer server. If possible, render the same task flow on the producer server as a servlet, rather than as a portlet. If it is slow to respond check whether there are slow running database queries in the application.

23.3 Diagnosing Oracle WebCenter Portlet Problems

When you encounter problems with Oracle WebCenter portlets, there are some general diagnostics steps that you can follow.

This section contains the following topics:

23.3.1 Using Diagnostic Tools

There is a set of tools available for both the consumer and producer to help identify and resolve issues when running Oracle JSF Portlet Bridge portlets.

If you encounter a portlet error message when a portlet is rendered, or if the portlet displays but you cannot interact correctly with it, there are some general steps using these tools that you should follow to diagnose the issue.

This section contains the following topics:

23.3.1.1 Identify the Portlet Instance

The first step when you encounter a portlet error, is to identify which portlet producer and portlet instance is being invoked. Execute the portletDebugShow() JavaScript from your browser to display this information in the main portlet content area.

To identify the portlet instance:

  1. Enter the following command in the Location field of your browser:

    javascript:portletDebugShow()
    
  2. After running the script, every portlet now displays the following information:

    • Producer name

    • Portlet name

    • Portlet instance ID

    • Execution Context IDs (ECIDs)

      The ECIDs are unique IDs used to identify a portlet request. Use the ECIDs to correlate the messages across different consumer and producer log files using Fusion Middleware Control. The same ECID is propagated from the consumer to the producer. For more information, see the "Correlating Messages Across Log Files and Components" section in the Oracle Fusion Middleware Administrator's Guide.

      Note:

      Broken portlets show two ECIDs: one for the request in which the error occurred and one for request in which the error was reported. For inline portlets (that is, portlets that are not displayed in an IFRAME), these two ECIDs are the same.

      For IFRAME portlets, for example Oracle JSF Portlet Bridge portlets, the ECIDs are different. This is because the error is reported in a later request than the one in which the original exception occurred. When checking the logs, you should look for both ECIDs, as either may contain relevant information.

    Description of portlet_debug.gif follows
    Description of the illustration portlet_debug.gif

    You can use this information in the subsequent diagnostic steps to help locate the issue.

    Note:

    The ECIDs shown in the portlet diagnostic information do not reflect partial page rendering requests that have been made to the portlet producer (using the portlet consumer resource proxy). These requests may update the portlet, but the ECIDs are not recorded in the portlet diagnostic information. Errors that occur during these requests are logged on the producer and by the portlet resource proxy on the consumer but you cannot use the ECID information reported in the portlet diagnostic information to help you determine the ECIDs for the relevant log entries.
  3. When you have finished debugging the portlets, enter the following command to hide the portlet debugging information:

    javascript:portletDebugHide()
    

23.3.1.2 Examine the Portlet Consumer Test Page

The next step in diagnosing a portlet error is to access the Portlet Consumer Test Page (shown in Figure 23-6) to locate the portlet producer and, if necessary, test the portlet in isolation.

Figure 23-6 The Portlet Consumer Test Page

Description of Figure 23-6 follows
Description of "Figure 23-6 The Portlet Consumer Test Page"

The Portlet Consumer Test Page contains three tabs:

  • Producers: This tab lists all the producers registered with the consumer application. Selecting a producer provides specific information about that producer.

  • Sanity Checks: This tab may contain a predefined set of portlet instances and required parameters that can be run in the consumer application, as configured by the consumer application developer. Any failures within these portlets indicate a problem with the corresponding producer and/or portlet.

  • Configuration: This tab enables you to identify the consumer configuration entries for portlet consumption. You cannot change these values as they are stored within the application; they are displayed for reference information only.

After accessing the Portlet Consumer Test Page, you can perform further diagnostic steps.

This section contains the following topics for using the Portlet Consumer Test Page to diagnose portlet issues:

Task 1   Access the Portlet Consumer Test Page

The Portlet Consumer Test Page provides diagnostic information about the portlet consumer.

To access the Portlet Consumer Test Page:

  1. In your browser, enter the URL for the Portlet Consumer Test Page:

    http://host:port/context-root/faces/oracle/portlet/client/adf/diagnostic/pages/ConsumerTestPage.jspx
    

    Note:

    If the consumer application is secured, the Portlet Consumer Test Page can be accessed only by users granted permission to view those pages.
  2. In the Portlet Consumer Test Page, you can perform further diagnostic steps as described in the following sections.

Task 2   Locate the Portlet Producer

The Producers tab of the Portlet Consumer Test Page lists all the producers that have been registered with the consumer application. If a portlet instance in your application displays an error message, you can view information about the producer that owns the portlet by selecting it on this tab.

To locate the portlet producer:

  1. In the Portlet Consumer Test Page, select the portlet producer that owns the portlet instance that is reporting the error.

    You noted this information in Section 23.3.1.1.

  2. The following information is provided for the selected producer:

    • Producer Test Page: A link to the Producer Test Page.

    • Configuration: Details of potential issues surrounding skins, security, and timeouts associated with the using producer.

    • Offered Portlets: A list of all portlets offered by the producer. If there are no offered portlets listed, this indicates that there is a problem with the registration metadata for the producer.

    • Portlet Instances: A list of all portlet instances for the selected producer in the consumer application. This list may be empty.

    You can use this information to identify potential issues with the producer.

Task 3   Locate and Run the Portlet Instance

If you have still not been able to identify the cause of the portlet error, the issue may lie with the portlet instance itself.

To locate and run the portlet instance:

  1. In the Portlet Consumer Test Page, select the portlet producer that owns the portlet instance that is reporting the error.

    You noted this information in Section 23.3.1.1.

  2. Under Portlet Instances, select the portlet instance to display the Consumer Test Page: Portlet page.

    You noted this information in Section 23.3.1.1.

    Description of portlet_test_page.png follows
    Description of the illustration portlet_test_page.png

  3. The Portlet Consumer Test Page: Portlet page renders the portlet in a standalone page. If the portlet runs correctly on this page, the problem is most likely caused by other components on the page containing the broken portlet.

  4. If the portlet contains parameters, a parameter section is displayed that lists all the public parameters for the portlet. Enter values for any parameters to test that the portlet is receiving parameters correctly.

  5. To navigate back to the Portlet Consumer Test Page, click the producer name link at the top of the page.

Task 4   Perform Sanity Checks

The Sanity Checks tab of the Portlet Consumer Test Page (shown in Figure 23-7) provides a quick overview of the state of portlet communication in your application across all producers.

Figure 23-7 The Sanity Checks Tab

Description of Figure 23-7 follows
Description of "Figure 23-7 The Sanity Checks Tab"

The Sanity Checks tab references portlet instances used within the consumer application. This list is configured by the application developer who chose the portlets to include and the parameters to pass to these portlets.

The checks on this page do not render the output in the UI, but simply create a runnable instance of the portlet under the covers and report any failures if any exception is returned by the portlet.

To perform sanity checks:

  1. In the Portlet Consumer Test Page, click the Sanity Checks tab.

  2. Click the check link next to the portlet that you want to test.

    The results of the sanity tests are displayed in the Status column.

  3. To run sanity checks on all listed portlets, click the Run all Sanity Checks link.

Task 5   Check Consumer Configuration Entries

The Configuration tab of the Portlet Consumer Test Page (shown in Figure 23-8) enables you to identify the consumer configuration entries for portlet consumption. This tab displays settings defined in the adf-config.xml file, for example, the minimum and maximum timeout values and the consumer version number. You cannot change these values as they are stored within the application; they are displayed for reference information only.

Figure 23-8 The Configuration Tab

Description of Figure 23-8 follows
Description of "Figure 23-8 The Configuration Tab"

23.3.1.3 Examine the Producer Test Page

If you cannot identify the cause of the error in the consumer application, the next step is to use the Producer Test Page (shown in Figure 23-9) to identify potential issues with the portlet producer application.

Figure 23-9 The Producer Test Page

Description of Figure 23-9 follows
Description of "Figure 23-9 The Producer Test Page"

Access to the main Producer Test Page is public, but links to the test pages for each portlet are accessible only to users granted permission on the underlying pages and task flows.

The Producer Test Page contains five sections:

  • Portlets

    A list of all the portlets within the producer. For Oracle JSF Portlet Bridge portlets, each portlet also provides a separate link to run the portlet as a servlet (this is a prerequisite to running them as portlets: if a portlet does not run as a servlet, it cannot run as a portlet).

  • Container Configuration

    Information on where the consumer preference information is stored.

  • Container Version

    The version number of the Portlet Producer Container.

  • WSDL URLs

    Links to the Web Service Definition Language (WSDL) documents to use for registration.

  • SOAP Monitor

    A link to the WSRP SOAP monitor where users with the Monitors or Administrators role can track the SOAP messages between the consumer and producer.

After accessing the Producer Test Page, you can perform further diagnostic steps.

This section contains the following topics:

Task 1   Access the Producer Test Page

The Producer Test Page provides diagnostic information about the portlet producer.

To access the Producer Test Page:

  1. In your browser, enter the URL for the Producer Test Page:

    http://host:port/context-root/info
    
  2. In the Producer Test Page, you can perform further diagnostic steps as described in the following sections.

Task 2   Run the JSF Portlet as a Servlet

To verify that an Oracle JSF Portlet Bridge portlet producer is running correctly, you must first verify that the producer application runs correctly through standard HTTP requests. If the artifacts the producer exposes as portlets do not run as servlets, they will not run as portlets.

To run a JSF portlet as a servlet:

  1. In the Producer Test Page, click the run as servlet link next to the portlet.

  2. The portlet is called using standard HTTP to request the underlying page or task flow. The results of the request are displayed in a new browser window.

    If the resulting page or task flow does not render correctly, then there is a problem with the producer application that must be resolved before you can run the page or task flow as a portlet.

  3. If the application developer configured the producer application with seeded parameters, there is also a run as servlet with parameters link next to the portlet in the Producer Test Page. Click this link to run the underlying page or task flow with those seeded parameters.

Task 3   Check the Persistent Store Type

Oracle Fusion Applications has adopted a standard to use a consumer preference store as the persistent store. Therefore, for Oracle Fusion applications producers, the Persistent Store Type displayed on the Producer Test Page should always be set to Consumer.

Although other configurations are acceptable for applications that are built to assume such a configuration, having a non-consumer setting in Oracle Fusion applications indicates an issue in the producer. For Oracle Fusion applications to work correctly, they require a consumer preference store.

Task 4   Examine the SOAP Monitor

The SOAP monitor provides access to the SOAP requests between the consumer and producer when rendering a portlet. This is very useful in diagnosing problems at the communication level.

To examine the SOAP monitor:

  1. In the Producer Test Page, click the SOAP Monitor link at the bottom of the page.

  2. When prompted, enter your user name and password.

    Note:

    To access the SOAP monitor you must be a member of the Monitors or Administrators role in the Identity Management System.
  3. By default, the SOAP monitor is disabled, so the page is empty. You must first enable the monitor by clicking the Enable link at the top of the page.

  4. The page does not automatically refresh, so to display SOAP messages, you must click the Refresh link.

  5. To force a request to the failing portlet, go to the Portlet Consumer Test Page: Portlet page for the portlet and select Refresh Portlet.

  6. When the portlet has rendered, or failed, click the Refresh link in the SOAP monitor to display the captured request.

    Description of portlet_soap_monitor.png follows
    Description of the illustration portlet_soap_monitor.png

  7. Now, you can investigate the SOAP messages that were sent and the responses to try to narrow down the cause of the problem.

    Note:

    If, after rerunning the portlet and refreshing the SOAP monitor, you see no messages displayed, this indicates that there may be a security issue between the producer and the consumer. You must verify that the correct WS-Security settings are set up for the producer and consumer to communicate.

23.3.2 Configuring the Portlet Logging File

To troubleshoot portlet issues, it is useful to add portlet log-handlers and loggers to the logging configuration file, logging.xml.

Example 23-4 shows how to add the portlet log-handlers and loggers. The example assumes that you are running the consumer and producer applications on the same WebLogic Server instance. If you are running the consumer and producer applications on different instances, you must split them up appropriately.

Note:

Add the log entries at the end of the file to ensure that they override any seeded settings.

Example 23-4 Configuring Log Files for Troubleshooting Portlet Issues

<!-- NOTE: You need to change the path where the logfile is located -->
<log_handlers>
...
   <!-- Portlet Consumer -->
   <log_handler name="portlet-consumer-handler" class="oracle.core.ojdl.logging.ODLHandlerFactory">
      <property name="format" value="ODL-Text"/>
      <property name="path" value="/scratch/logs/portlet-consumer.log"/>
   </log_handler>

   <!-- Portlet Producer -->
   <log_handler name="portlet-producer-handler" class="oracle.core.ojdl.logging.ODLHandlerFactory">
      <property name="format" value="ODL-Text"/>
      <property name="path" value="/scratch/logs/portlet-producer.log"/>
   </log_handler>

   <!-- Portlet Bridge -->
   <log_handler name="portlet-bridge-handler" class="oracle.core.ojdl.logging.ODLHandlerFactory">
      <property name="format" value="ODL-Text"/>
      <property name="path" value="/scratch/logs/portlet-bridge.log"/>
   </log_handler>
...
</log_handlers>

<loggers>
...
   <!-- Portlet Consumer -->
   <logger name="oracle.portlet.client" level="FINEST" useParentHandlers="false">
      <handler name="portlet-consumer-handler"/>
   </logger>

   <!-- Portlet Servers -->
   <logger name="com.bea.portlets" level="FINEST" useParentHandlers="false">
      <handler name="portlet-producer-handler"/>
   </logger>
   <logger name="com.bea.netuix" level="FINEST" useParentHandlers="false">
      <handler name="portlet-producer-handler"/>
   </logger>
   <logger name="com.bea.wsrp" level="FINEST" useParentHandlers="false">
      <handler name="portlet-producer-handler"/>
   </logger>
   <logger name="oracle.portlet.producer" level="FINEST" useParentHandlers="false">
      <handler name="portlet-producer-handler"/>
   </logger>

   <!-- Portlet Bridge -->
   <logger name="oracle.portlet.bridge" level="FINEST" useParentHandlers="false">
      <handler name="portlet-bridge-handler"/>
   </logger>
   <logger name="oracle.portlet.server.bridge" level="FINEST" useParentHandlers="false">
      <handler name="portlet-bridge-handler"/>
   </logger>
...
</loggers>

The logging configuration file is located in:

DOMAIN_HOME/config/fmwconfig/servers/server/logging.xml

The log file name is also defined in logging.xml. By default the log file name is:

DOMAIN_HOME/servers/server/logs/server-diagnostic.log

23.4 Using My Oracle Support for Additional Troubleshooting Information

You can use My Oracle Support (formerly MetaLink) to help resolve Oracle Fusion Applications problems. My Oracle Support contains several useful troubleshooting resources, such as:

You can access My Oracle Support at https://support.oracle.com.