Wednesday 7 March 2012

Troubleshooting and Logging Basics for Oracle SOA Suite

SOA troubleshooting must be performed in the following scenarios:
  1. The Oracle Fusion application transaction flow has an error and it has been identified as an error in SOA (or you want to check if it is a SOA-related error).
  2. The Oracle Fusion application transaction flow has not completed and is taking longer than it should and it has been identified as stuck in SOA (or you want to check if it is stuck in SOA).
  3. The Oracle Fusion application transaction flow is not working as expected, and the wrong data is passed.
The recommended approach to troubleshooting SOA issues is as follows:
  1. Check the server and composite status log in Oracle WebLogic Server Administration Console and check if the SOA server is up and running successfully (that is, not in a failed state).
    1. Log in to Oracle WebLogic Server Administration Console.
    2. In the Domain Structure, click Deployments.
    3. In the Name column of the Deployments section, find soa-infra.
    4. Check that the State column is set to Active and the Health column is set to OK.
    5. Click soa-infra > Monitoring tab.
    6. Expand to ensure that all components have Health set to OK.
    7. Note the server name on which SOA is deployed.
    8. Go to the Domain Structure and click Environment > Servers to verify that the State column is set to RUNNING and the Health column is set to OK.
    9. Note the Listen Port column value, as this is the SOA runtime port.
  2. Check if any Oracle Fusion application incident was created for the problem encountered.
    For information about Oracle Fusion application incident processing, see Section 17.4.1.
  3. Check whether the event was delivered to the SOA cluster by checking the log messages in Fusion Applications Control.
    This requires the oracle.integration.platform.blocks.event logger to be set to TRACE:32 (FINEST). There are potentially many types of exceptions that can appear in the log messages on the client side that raised the event. For example:
    • If a Java class is not in the class path, then a ClassNotFoundException may appear.
    • If the JNDI for the context or connection factory is not configured properly, then a NamingException or FabricException may appear.
    • If the event payload XML that you create is invalid or contains invalid characters, you may receive a FabricException indicating that enqueueing of the event fails at the PL/SQL API with invalid characters, and so on.
    For information about enabling this log and troubleshooting business events, see Section 21.3.2.
  4. Check the composite instance flow. If the event was fired, then find your composite instance based on the application data.
    See Section 21.3.1 for primary key mapping to the composite instance ID.
  5. Review the composite instance flow and fault details. If the instance is in error and it is recoverable, attempt recovery using the Recovery tab of the BPEL process service engine in Fusion Applications Control.
  6. View the logs.
    If the problem still cannot be solved, increase the log level of the system to debug the transactions. See the list of loggers and log levels in the "Troubleshooting Oracle SOA Suite" appendix of Oracle Fusion Middleware Administrator's Guide for Oracle SOA Suite and Oracle Business Process Management Suite. To simplify troubleshooting, it is recommended that you enable the following parent loggers at the TRACE32 (FINEST) level in Fusion Applications Control:
    • oracle.soa
    • oracle.fabric
    • oracle.integration
    The oracle.wsm logger can remain set to the ERROR level where it logs the required error messages. The oracle.apps logger should be set to ALL. To change logger levels, perform the following steps:
    1. Go to Fusion Applications Control.
    2. In the navigation pane, select WebLogic Domain.
    3. Right-click a Managed Server from within the domain (each server's log levels can be independently set).
    4. Choose Logs > Log Configuration.
    5. In the Logger Name column, expand the oracle runtime loggers to display loggers such as oracle.soa.
    6. Change the logging level to TRACE:32. The change should take effect within a few minutes.
      Description of loglevel.gif follows
      Description of the illustration loglevel.gif

      Note that in a production system, setting the trace at a fine-grained level can result in a large amount of output that must be diagnosed. You can alternately use selective tracing that provides a way to get a detailed, on-disk trace selectively (for example, by user name, thereby eliminating trace output for other users).
    7. To activate selective tracing, right-click the domain under WebLogic Domain and choose Logs > Selective Tracing.
      Note that Selecting Tracing does not display as an option when you right-click an Administration Server or Managed Server and choose Logs.
    8. From the Option Name list, choose the type of selective trace (for example, based on user name), and start the trace.
    9. When the problem has been reproduced, disable the trace and view the output to narrow down the issue.
      For more information on selective tracing, see the "Configuring and Using Selective Tracing" section of Oracle Fusion Middleware Administrator's Guide.
    10. Review the error logs (from Fusion Applications Control) for more information on the error.

No comments:

Post a Comment

xslt padding with characters call template for left pad and right pad

  Could a call-template be written that took two parameters ?   a string, and a   number) return the string with empty spaces appended t...