Skip Headers
Oracle® Enterprise Manager Cloud Control Getting Started with Oracle Fusion Middleware Management Plug-in
Release 12.1.0.5

E24215-09
Go to Documentation Home
Home
Go to Book List
Book List
Go to Table of Contents
Contents
Go to Index
Index
Go to Feedback page
Contact Us

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

11 Discovering and Monitoring the SOA Suite

This chapter describes how you can discover and configure the components of the SOA Suite 11g using Enterprise Manager Cloud Control.

In particular, this document covers the following:

11.1 New Features in This Release

The new features that have been introduced in the 12c version of the SOA Suite are:

  • Target Setup Verification allows you to perform a series of tests that can help diagnose and repair setup problems required for target monitoring.

  • Fault Management allows you to perform a real-time search and recovery of faults and BPEL/BPMN messages. In addition to this, you can perform bulk recovery of faults, and track and monitor the status of submitted bulk recoveries.

  • Oracle RAC Database Support for Dehydration Store Performance allows you to monitor the health and performance of RAC-based Dehydration Store for Multi Data Source or GridLink Data Source type.

  • Instance Tracing Enhancements allows you to perform the following operations:

    • Tracing instances using the Instance Id.

    • Viewing payloads for BPEL component instances.

    • Tracing instances at SOA Infrastructure level.

  • Support Work Bench Enhancements is enhanced to generate BPEL and Mediator dumps. The enhanced capability is supported for SOA PS6 (11.1.1.7.0).

  • SOA Composite Targets Discovery is enhanced to discover only the default versions of SOA Composites, if required. Unlike the previous release, where the default and only option was to discover all the deployed SOA Composites, you can now choose to only discover the default versions of the SOA composites. To do so, follow the steps listed in Section 11.5.1.

11.2 List of Supported Versions

The following are the versions of the SOA Suite 11g that are supported in Enterprise Manager Cloud Control 12c:

  • 11.1.1.2.0 (PS1)

  • 11.1.1.3.0 (PS2)

  • 11.1.1.4.0 (PS3)

  • 11.1.1.5.0 (PS4)

  • 11.1.1.6.0 (PS5)

  • 11.1.1.7.0 (PS6)

11.3 Monitoring Templates

The following Oracle-certified default templates are being shipped for Enterprise Manager Cloud Control 12c Release 2 and Enterprise Manager Cloud Control 12c Release 3 agents. Table 11-1 describes the available templates, and the agents to which they apply:

Table 11-1 Monitoring Templates

Target Type Agent Name Template Name

SOA Infrastructure

PS1 Agent

Oracle Certified Fusion Apps Template for SOA Infrastructure for FMW Plugin 12.1.0.3.0

SOA Infrastructure

PS1 Agent

Oracle Certified FMW Template for SOA Infrastructure for FMW Plugin 12.1.0.3.0

SOA Infrastructure

PS2 Agent

Oracle Certified Fusion Apps Template for SOA Infrastructure

SOA Infrastructure

PS2 Agent

Oracle Certified FMW Template for SOA Infrastructure

SOA Composite

PS1 Agent

Oracle Certified Fusion Apps Template for SOA Composite for FMW Plugin 12.1.0.3.0

SOA Composite

PS1 Agent

Oracle Certified FMW Template for SOA Composite for FMW Plugin 12.1.0.3.0

SOA Composite

PS2 Agent

Oracle Certified Fusion Apps Template for SOA Composite

SOA Composite

PS2 Agent

Oracle Certified FMW Template for SOA Composite


Note:

The templates created using older versions of OMS (Enterprise Manager Cloud Control 12c Release 2, Enterprise Manager Cloud Control 12c BP1, and so on) should not be used in Enterprise Manager Cloud Control 12c Release 3.

11.4 Overview of the Discovery Process

The following describes the overall process involved in discovering and monitoring SOA Suite 11g in Enterprise Manager Cloud Control. Follow the instructions outlined against each step in this process to successfully discover and monitor the SOA Suite.

Table 11-2 Understanding the Discovery Process

Oracle SOA Suite Version Application Server Deployed To Discovery Mechanism Process

Oracle SOA Suite 11.1.x

Oracle WebLogic Managed Server

Manual Discovery

  1. First, manually discover Oracle WebLogic Managed Server. For procedures, see Section 9.5.2.1, "Discovering Oracle WebLogic Managed Server".

  2. To monitor the SOA Suite, you can use an agent running locally on the Administration Server of the WebLogic domain or a remote management agent running on another host that is not part of the WebLogic domain.

    Note: If you use a remote agent to monitor the SOA Suite, then certain the following operations like:

    - Instance Tracing, Viewing Recoverable Instances, Fault Recovery, and Provisioning SOA Artifacts is not supported.

    - Host Metrics cannot be captured by the remote agent.

  3. To ensure the all the metric data is collected, add the soa-infra-mgmt.jar and the oracle-soa-client-api.jar files to the $AGENT_HOME/plugins/oracle.sysman.emas.agent.plugin_12.1.0.0.0/archives/jlib/ (the Agent Home directory). If the extjlib directory does not exist, it can be created under $FMW_PLUGIN_HOME/archives/jlib. This step is required only if you are using a remote agent to monitor the SOA Suite.

    Note: For SOA PS3 (11.1.1.4.0) and higher, the jrf-api.jar file must also be present in the Agent Home directory.


11.5 Discovering the SOA Suite

This section describes the procedure for discovering the SOA Suite 11g.

11.5.1 Discovering the SOA Suite

You can use a local or a remote Management Agent to perform the discovery process. as follows:

Discovering the SOA Suite Using a Local Agent

In the case of discovery using a local agent, you need to use a Management Agent that is running on the same host as the Administration Server.

  1. From the Targets menu, select Middleware.

    Oracle Enterprise Manager Cloud Control displays the Middleware page that lists all the middleware targets being monitored.

  2. In the Middleware page, from the Add list, select Oracle Fusion Middleware / WebLogic Domain and click Go.

    Specify the Administration Server Host, Port, User Name, Password, Agent (local or remote) and the JMX Protocol and click Continue.

  3. In the Add Oracle Fusion Middleware/Weblogic Domain: Find Targets page, specify the Administration Server Host, Port, Username, Password, and Agent (local or remote) details.

    Figure 11-1 New Domain Discovery

    Discovering SOA Composites.

    In the Advanced section, select the JMX Protocol from the list.

    Starting with Cloud Control 12.1.0.5.0 plug-in release, you have the flexibility to discover only the latest default version of SOA composites. The advantage of this flexibility is that you have full control on the targets that you want to centrally manage and monitor from the Cloud Control console. To discover only the default SOA composites, in the Advanced section, uncheck the Discover Application Versions.

    By default, this option is checked which enables administrators to discover all versions of deployed SOA Composites. Note that, unlike the previous releases where the default behaviour was to have one target for each composite version (with the version number as part of the target name), in this release, if you uncheck the Discover Application Versions option, you have one target for all SOA Composite versions (without any version number in its name). This target collects metrics only for the current default version and not for older versions.

    Note:

    • If you have targets which were discovered with the “Discover Application Versions” box checked (which is the default, see Figure 11-1), but now want to disable this option, perform the following steps:

      • Go to the WebLogic Domain target page.

      • On the Monitoring Configuration page, update the value of Discover application versions to false. (See Figure 11-2.)

      • Perform a domain refresh

      Doing this will discover new composite targets (without any version numbers in their names) that will not contain the metric history from the previous targets.

    • Once you are in a state where you have composite targets without version numbers in their names, if you add more SOA composite versions, the version specified as the default version in the SOA Suite will be monitored. Historical metrics will be retained on the same target whenever the default version changes.

    Figure 11-2 Upgrade Domain Discovery

    Upgrade Domain Discovery

    Click Continue.

  4. You will return to the Middleware page. You will see the SOA instances under the WebLogic Domain.

    Note:

    SOA Composites that are created after the discovery of SOA Suite Domain are not displayed automatically. To view all the SOA Composites, navigate to the Home page of the WebLogic Server target and select the Refresh Domain option from the menu.

Discovering the SOA Suite Using a Remote Agent

You can discover the SOA Suite 11g using a remote agent which may be running on a host that is different from the host on which the Administration Server is running. In this case, you may not be able to perform certain operations like instance tracing, fault recovery, viewing recoverable instances, provisioning SOA Artifacts, and capturing the host metrics.

To ensure the all the metric data is collected, add the soa-infra-mgmt.jar and the oracle-soa-client-api.jar files to the $AGENT_HOME/plugins/oracle.sysman.emas.agent.plugin_<plugin version>/archives/jlib/extjlib (the Agent Home directory). If the extjlib directory does not exist, it can be created. This step is required only if you are using a remote agent to monitor the SOA Suite.

Note:

For SOA PS3 (11.1.1.4.0) and higher, the jrf-api.jar file must also be present in the Agent Home directory.

11.5.2 Configuring the SOA Suite

After discovering the SOA Suite 11g, you must perform the following additional configuration steps:

  1. Set the SOA database details like the host name, port, and credentials.

    1. Navigate to the Middleware page in Enterprise Manager Cloud Control.

    2. Select a SOA Infrastructure home from the list and click Configure.

    3. The SOA Infrastructure Home page is displayed. Click Monitoring Configuration from the SOA-Infra drop-down menu.

    4. Set the SOA database details in the Monitoring Configuration page.

  2. Set preferred credentials for the WebLogic Domain.

    1. From the Setup menu, select Security, then select Preferred Credentials.

    2. Select the Oracle WebLogic Domain target and click Managed Preferred Credentials.

    3. Select WebLogic Administrator Credentials in the Target Preferred Credentials and click Set.

    4. Enter the user name and password in the Select Named Credentials window and click Save.

11.6 Metric and Collection Settings

For the following metrics the collection schedule is not available on the Metric and Collection Settings page. Detailed steps to update the collection intervals are listed in the following table:

Table 11-3 Metric and Collection Settings

Target Type Metric Name Collection Interval Update Steps

SOA Infrastructure

Response

Navigate to the associated weblogic server where SOA is deployed, to do so, follow these steps:

  1. From the Targets menu, select Middleware.

  2. On the Middleware page, click the SOA Infrastructure target.

  3. On the SOA Infrastructure target page, from WebLogic Server menu, select Monitoring, and click Metric and Collection Settings.

  4. Click Other Collected Items tab.

  5. Click Collection Schedule corresponding to Application Metrics to update the collection interval.

Note: This change is applicable to all the applications deployed in that WebLogic server.

SOA Composite

Response

For SOA PS5 (11.1.1.6.0) or earlier, follow these steps:

  1. From the Targets menu, select Middleware.

  2. On the Middleware page, click the SOA Composite target.

  3. On the SOA Composite target page, from SOA Composite menu, select Monitoring, and click Metric and Collection Settings.

  4. Click Other Collected Items tab.

  5. Update the collection interval for the metric SOA Composite Status (11.1.1.6.0 and earlier)

For SOA PS6 (11.1.1.7.0) onwards, navigate to the associated SOA Infrastructure where SOA composite is deployed. To do so, follow these steps:

  1. From the Targets menu, select Middleware.

  2. On the Middleware page, click the SOA Infrastructure where SOA composite is deployed.

  3. On the SOA Infrastructure target page, from SOA Infrastructure menu, select Monitoring, and click Metric and Collection Settings.

  4. Click Other Collected Items tab.

    Update the collection interval for the metric SOA Composite Status.

Note: This change is applicable to all the SOA composites which are deployed in that SOA Infrastructure

SOA Composite

SOA Composite - Component Detail Metrics

Navigate to the associated SOA Infrastructure where soa composite is deployed. To do so, follow these steps:

  1. From the Targets menu, select Middleware.

  2. On the Middleware page, click the SOA Infrastructure where SOA composite is deployed.

  3. On the SOA Infrastructure target page, from SOA Infrastructure menu, select Monitoring, and click Metric and Collection Settings.

  4. Click Other Collected Items tab.

    Update the collection interval for the metric SOA Infrastructure - Recoverable Faults.

SOA Composite

SOA Composite - Recoverable And Rejected Messages

Navigate to the associated SOA Infrastructure where soa composite is deployed. To do so, follow these steps:

  1. From the Targets menu, select Middleware.

  2. On the Middleware page, click the SOA Infrastructure where SOA composite is deployed.

  3. On the SOA Infrastructure target page, from SOA Infrastructure menu, select Monitoring, and click Metric and Collection Settings.

  4. Click Other Collected Items tab.

    Update the collection interval for the metric SOA Infrastructure - Recoverable And Rejected Messages.


11.6.1 Viewing Application Dependency and Performance (ADP) Metrics

If the SOA instance is being monitored by the ADP Manager, additional metrics such as Arrival Rate, Minimum, Maximum, and Average Response Time will be collected.

Tip:

The ADP Manager must be registered before it can collect the metric data. For details on registering the ADP Manager, see Oracle Enterprise Manager Cloud Control Advanced Installation and Configuration Guide.

11.7 Configuring Instance Tracing

Before enabling Instance Tracing, ensure that you meet the following prerequisites:

  • Ensure that the SOA infrastructure is monitored by an Oracle Management Agent (Management Agent) that is running on the same host as the SOA infrastructure.

  • Set the following as preferred credentials:

    • Credentials of the host on which the SOA server is running.

    • Administrator credentials of the Oracle WebLogic Domain.

To enable Instance Tracing for any SOA Infrastructure instances involved in executing composite instances:

  1. Set the preferred credentials for the WebLogic Domain. To do so, follow the steps listed in Section 11.5.2.

  2. To view the state of the listed instances, enable the Capture Composite State flag on the instance tracing page as follows:

    1. On the SOA Infrastructure home page, from SOA Infrastructure menu, select Fusion Middleware Control.

    2. Navigate to the home page of the SOA Infrastructure target.

    3. From SOA Infrastructure menu, select SOA Administration, and then click Common Properties.

    4. On the SOA Infrastructure Common Properties page, select the Capture Composite Instance State check box.

11.8 Setting Up and Using SOA Instance Tracing

Starting with Enterprise Manager Cloud Control 12c Release 3, Instance Tracing functionality is also available at the SOA Infrastructure level, in addition to the existing SOA Composite level.

The section contains the following topics:

11.8.1 SOA Instance Tracing at SOA Infrastructure Level

At SOA Infra level, an instance search is performed across SOA Composites, and a particular SOA composite instance is traced. To do so, follow these steps:

  1. In Cloud Control, from Targets menu, select Middleware.

  2. On the Middleware page, click the SOA Infrastructure target.

  3. On the SOA Infrastructure home page, from SOA Infrastructure menu, select Instance Tracing.

  4. On the Trace Instance page, search for the instance you want to trace by specifying search criteria such as Instance ID, Instance Creation Time Window, Instance Count, Sensor Values and so on. Click Search.

    Note:

    You must set the Preferred Credentials for the WebLogic Domain and the Monitoring Agent Host to retrieve search data. These settings for Instance tracing can be done from the Target Setup Verification page. To do so, from the Targets menu, select Middleware. On the Middleware page, click the target you are interested in. For example, SOA Infrastructure. On the Home page of the target, from the target-specific menu, select Target Setup, and click Verification.
    • WebLogic Domain: To set the Administrator Credentials for the WebLogic Domain (SOA Domain Target), select Security, then select Preferred Credentials from the Setup menu. Select Oracle WebLogic Domain as the Target Type and click Manage Preferred Credentials. Specify the WebLogic Administrator credentials and click OK.

    • Monitoring Agent Host: To set the Preferred Credentials for the host on which the Management Agent has been installed, select Security, then select Preferred Credentials from the Setup menu. Select Host as the Target Type and click Manage Preferred Credentials. Specify the Normal Host Credentials for the host and click OK.

    All the instances across all the SOA Composites are displayed. A new QBE feature has been introduced into the instance table which allows you to filter the instances based on different fields like: Instance id, Partition name, Composite name, Instance State, Tracing job status, Name, ECID, and Conversation Id.

  5. Select the Instance Id of a particular SOA Composite that you want to trace, click Trace.

  6. In the Trace Instance dialog box, click Add to add one or more SOA Infrastructure targets for which the trace information is to be gathered. Specify the WebLogic Administration and Host Credentials for these targets and click OK.

    A trace job is submitted to collect the instance trace data from the selected targets and the flow trace for the instance is generated.

  7. When the job has been completed, click Tracing Job Status to view the flow trace data.

  8. Click the Component Instance to drill down to the component instance audit trail which shows the activity level execution details.

    To view the payloads for BPEL component instance, click the component instance to drill down to the component audit trail, and then click View Payload to view the payloads.

11.8.2 SOA Instance Tracing at SOA Composite Level

To configure and trace a SOA Composite instance, follow these steps:

  1. In Cloud Control, from Targets menu, select Middleware.

  2. On the Middleware page, click the SOA Composite target.

  3. On the SOA Composite home page, from the SOA Composite menu, select Trace Instance.

  4. On the Trace Instance page, search for the instance you want to trace by specifying search criteria such as Instance ID, Instance Creation Time Window, Instance Count, Sensor Values and so on. Click Search.

    Note:

    You must set the Preferred Credentials for the WebLogic Domain and the Monitoring Agent Host to retrieve search data. These settings for Instance tracing can be done from the Target Setup Verification page. To do so, from the Targets menu, select Middleware. On the Middleware page, click the target you are interested in. For example, SOA Infrastructure. On the Home page of the target, from the target-specific menu, select Target Setup, and click Verification.
    • WebLogic Domain: To set the Administrator Credentials for the WebLogic Domain (SOA Domain Target), select Security, then select Preferred Credentials from the Setup menu. Select Oracle WebLogic Domain as the Target Type and click Manage Preferred Credentials. Specify the WebLogic Administrator credentials and click OK.

    • Monitoring Agent Host: To set the Preferred Credentials for the host on which the Management Agent has been installed, select Security, then select Preferred Credentials from the Setup menu. Select Host as the Target Type and click Manage Preferred Credentials. Specify the Normal Host Credentials for the host and click OK.

    The list of instances that match the search criteria are displayed. A new QBE feature has been introduced into the instance table which allows you to filter the instances based on different fields like: Instance id, Partition name, Composite name, Instance State, Tracing job status, Name, ECID, and Conversation Id.

  5. Select the Instance Id for tracing instances present within a SOA Domain, to trace instances that span across various SOA domains in you infrastructure, click Trace.

  6. In the Trace Instance dialog box, click Add to add one or more SOA Infrastructure targets for which the trace information is to be gathered. Specify the WebLogic Administration and Host Credentials for these targets and click OK.

    A trace job is submitted to collect the instance trace data from the selected targets and the flow trace for the instance is generated.

  7. When the job has been completed, click Tracing Job Status to view the flow trace data. Click the Log Viewer link to access the log messages related to the instance.

  8. Click the Component Instance to drill down to the component instance audit trail which shows the activity level execution details.

    To view the payloads for BPEL component instance, click the component instance to drill down to the component audit trail, and then click View Payload to view the payloads.

11.9 Monitoring Dehydration Store

The Dehydration Store Diagnostics feature provides a dedicated view that allows you to analyze the behavior of the SOA Dehydration database. You can monitor SQL performance metrics and table growth specifically in the context of the SOA Suite's use of the database. The view displays both throughput and wait bottleneck data which allows you to monitor the general health of the target database instance. Using Active Session History, you can track usage data and display it as a table space chart, a growth rate chart, or an execution chart.

Note:

In addition to monitoring Oracle standalone database, the Dehydration Store now supports reviewing the general health of the RAC database engine, and identifying problems that are causing performance bottlenecks.

You can also monitor Real Application Cluster (RAC) databases. For RAC, you can monitor Multi Data Source and GridLink Data Sources. In RAC scenario, the dehydration store tab lists all the associated database nodes in the form of a drop down menu. You can select any particular instance from the Show Database Instance menu, and view the associated metric data.

11.9.1 Enabling Monitoring of the SOA Dehydration Store

To configure and enable monitoring of the SOA Dehydration Store, follow these steps:

  1. From the Targets menu, select Databases to check if the database target representing the SOA Dehydration Store has been discovered in Enterprise Manager.

  2. Check if at least one configuration for the SOA Infrastructure and WebLogic Server targets is available.

  3. On the monitoring configuration for the SOA Infrastructure target, the following fields related to SOA Repository must be configured:

    • SOA Repository Connection Descriptor: The connection URL string specified for the JDBC data source on the WebLogic server. This configuration is collected as part of the configuration collection mechanism for the SOA Server instance. For example,

      On Single Instance Database

      host:port/sid (or service_name)

      On RAC Database

      • Multi Data Source:

        (DESCRIPTION=(ADDRESS_LIST=(ADDRESS=(PROTOCOL=TCP)(HOST=<Host
        1>)(PORT=<Port 1>)))(CONNECT_DATA=(SERVICE_NAME=<Service
        Name>)(INSTANCE_NAME=<Instance 1>)));(DESCRIPTION=(ADDRESS_LIST
        =(ADDRESS=(PROTOCOL=TCP)(HOST=<Host 2>)(PORT=<Port 2>)))(CONNECT_DATA
        =(SERVICE_NAME=<Service Name>)(INSTANCE_NAME=<Instance 2>)))
        
      • GridLink:

        (DESCRIPTION=(ADDRESS_LIST=
        ADDRESS=(PROTOCOL=TCP)(HOST=<Host>)(PORT=<Port>)))
        (CONNECT_DATA=(SERVICE_NAME=<Port>)))
        
    • SOA Repository Host Name: The database listener host for the SOA database instance. This is optional if the connection string has already been configured.

    • SOA Repository Port: - The database listener port for the SOA database instance. This is optional if the connection string has already been configured.

    • SOA Repository Schema Name: The schema name configured for SOA Dehydration Store.

    • SOA Repository User Name: The schema name configured for SOA Dehydration Store.

    • SOA Repository Password: The password for the SOA schema user.SOA Repository SID: The SID for the SOA database instance.

If you do not see data after these configuration details have been specified, you must wait for the next collection interval.

11.9.2 Viewing the SOA Dehydration Store Data

To view the dehydration diagnostics data, follow these steps:

  1. From the Targets menu, select Middleware, then click on a SOA Infrastructure target.

  2. In the SOA Infrastructure Home page, click the Dehydration Store tab.

  3. The following details area displayed:

    • Throughput indicators that provide details of the general health of the database instance.

    • Wait bottleneck issues related to the CPU, I/O, and Wait events.

    • Tablespace utilization for the SOA schema.

    • Performance data recorded by the ASH.

    • Key SOA tables and tablespace details related to the SOA schema.

11.10 Viewing the Service Topology

The Service Topology provides a graphical end to end view of the composite applications. It depicts the various application components and their interactions happening at runtime. It allows you to view the service level dependencies among the components and provides key performance statistics and incidents information for them. Composite applications are distributed in nature and this view helps you quickly visualize the structure, status, availability, dependencies, configuration changes, and performance of business-critical distributed applications from one place and easily identify any availability or performance issues.

The Service Topology Viewer shows the following:

  • Service to Service Calls: It allows you to view the Service to Service calls between any two SOA entities (Composites/J2EE Applications/OSB/BPEL 10g instances) by clicking the link between the entities.

  • Dependency Highlighting: It allows you to view the dependencies for any service. If you click on a service, all the services that it is dependent on and vice versa are highlighted.

  • Database Associations: Shows all the databases used by the SOA Composites, BPEL 10g instance and J2EE applications.

  • External Services: Shows the services that are used by a SOA Composite application but are external to it or not managed by Enterprise Manager Cloud Control.

For more details, refer to the Enterprise Manager Online Help.

11.11 Publishing a Server to UDDI

To publish a service to UDDI, navigate to the Services and References Home page, select a service from the table and click Publish to UDDI from the menu. The Publish Service to UDDI window is displayed with the following fields:

  • Service Name: The name of Web Service to be published to the UDDI Registry. This is a Read Only field.

  • Service Description: The description of the selected Web Service.

  • Service Definition Location: The URL location of the Service Definition. This is a Read Only field.

  • UDDI Source: A logical name for an external UDDI registry source. Select the UDDI Source from the drop-down list.

  • Business Name: The name of the data structure in the UDDI registry. Select a Business Name that has been registered with the UDDI from the list.

Click OK to start the process that publishes the web service to UDDI or click Cancel to cancel publishing the service.

11.12 Generating SOA Reports Using BI Publisher

You can use Enterprise Manager to print SOA reports using BI Publisher Enterprise Reports. Oracle Business Intelligence (BI) Publisher is an enterprise reporting solution for authoring, managing, and delivering highly formatted documents. Oracle BI Publisher also allows you to build custom reporting applications that leverage existing infrastructure. Reports can be designed using familiar desktop products and viewed online or scheduled for delivery to a wide range of destinations.

The following table describes the SOA reports that can be generated using BI Publisher:

Table 11-4 SOA Reports

SOA Report Description

SOA Infrastructure Performance Report

The SOA Infrastructure Performance Summary Report provides information about the average response time, error rate, throughput, system faults, business faults, web service policy violation faults for selected SOA Composite. It displays a chart with the top 5 SOA Composites based on average response time or throughout across the selected SOA composites for specified time period. The report can be sorted based on performance metric (average response time) or the usage metric (instance count). As part of the report parameters setting, you can use options that allow you to select the SOA Composite by Partitions or by selecting individual composites.

SOA Composite Detailed Performance Report

The SOA Composite Detailed Performance Summary Report provides information about the average response time, error rate, throughput, system faults, business faults, web service policy violation faults for each selected composite assembly part such as service, reference, and service component. This is an in-depth report that provides complete details about the each assembly part in the SOA Composite.It displays a chart with the top 5 SOA Composites based on average response time or throughout across the selected SOA Composites for a specified time period. The report can be sorted based on performance metric (average response time) or the usage metric (instance count).

As part of the report parameters setting, you can use options that allow you to select the SOA Composite by Partitions or by selecting individual composites.

Top 5 SOA Composites (From Dehydration Store)

This report shows how the SOA Composites have been performing over a period of time. Charts listing the top 5 SOA composites are displayed and critical metric data for all the SOA composites are displayed in a table.


To print SOA reports using BI Publisher, follow these steps:

  1. From the Enterprise menu, select Reports, then select BI Publisher Enterprise Reports.

    Enterprise Manager Cloud Control displays the login page for BI Publisher Enterprise Reports.

  2. Enter your credentials to log into BI Publisher.

  3. The BI Publisher Enterprise page displays, showing you Recent reports, Others, and Favorites. You can use this page to create a new report, submit a report job, and perform other tasks.

  4. Click the Report you want to view.

  5. You can select different filters such as SOA Composite Name, Partition Name, Date Range, and so on to view the report. You can also select a Sort By option to sort the report on Composite Name, Sorted Instances, and so on.

  6. You can refresh the report anytime by clicking the Refresh icon on the upper right side of the SOA Report tab. You can hide or display the search parameters by clicking the Parameters icon. You can choose to view the report in various formats such as HTML, PDF, RTF, Excel, and PowerPoint by clicking the View Report icon. Likewise you can display more available actions by clicking the Actions icon. For more help about using BI Publisher, click the help icon.

11.13 Generating SOA Reports Using Information Publisher

This section describes the procedure to create SOA Reports.

  1. From the Targets menu, select Middleware, and click on a SOA Infrastructure target. The SOA Infrastructure Home page appears.

  2. From the SOA Infrastructure menu, select the Information Publisher Reports.

    The out-of-box SOA reports are displayed under the SOA Performance Reports section.

  3. Select a report from the section (for example, you can select Pending Instance Statistics) and click Create Like. The Create Report Definition page is displayed.

  4. In the General page, enter the following details:

    1. Enter the BPEL Process Name as the title.

    2. Click the Set Time Period to set the time interval for the report.

    3. Click the Run report using target privileges of the Report Owner (SYSMAN) check box in the Privileges section.

  5. Click the Elements tab and click the Set Parameters icon for the Pending Instance Statistics Element in the table.

  6. In the Set Parameters page, click the torch icon to select a Composite Name. The Result Set Size with default values for the Pending Instance Statistics report is displayed.

  7. Select a Component Name from the list, enter the Result Set Size and click Continue to return to the Elements page.

  8. The selected target name is displayed in the Elements table.

  9. To schedule periodic report generation, click the Schedule tab.

  10. Specify the schedule type and other details and click OK.

  11. You will return to the Report Home page where the newly scheduled report is displayed in the table. Click the report name to view the details.

11.14 Provisioning SOA Artifacts and Composites

The SOA Artifacts Deployment Procedure allows you to:

  • Provision SOA Artifacts from a reference installation or from a gold image

  • Create a gold image of the SOA Artifacts

  • Provision SOA Composites either from the Software Library or from another accessible location.

For more details on the SOA Artifacts Deployment Procedure, see the Enterprise Manager Administrator's Guide for Software and Server Provisioning and Patching.

11.15 Diagnosing Issues and Incidents

To diagnostic data for problems and incidents, access the Support Workbench page. To do so, navigate to the SOA Infrastructure Home page, and from the SOA Infrastructure menu, select Diagnostics, then select Support Workbench.

Enter the credentials for the host on which the WebLogic server is running and the WebLogic credentials for the WebLogic server. Click Continue to log into the Support Workbench page. On this page, you can do the following:

  • View problem or incident details.

  • View, create, or modify incident packages.

  • View health checker findings

  • Close resolved problems.

11.16 Verifying Target Monitoring Setup

As a prerequisite, verify the target monitoring setup before you perform any operations on the SOA infrastructure. Use the Target Setup Verification page to run a series of diagnostic scans and verify if you have met all functional as well as system-level prerequisites required for monitoring targets in Enterprise Manager. This helps you discover and repair all target monitoring setup-related issues beforehand.

This section describes the following:

Note:

If the following error is displayed while trying to access the Target Setup Verification page, then you must upgrade the Management Agent version to 12.1.0.3 or higher:
Current agent version is not supported for Functionality Check
scan. Upgrade to 12.1.0.3.0 agent version or higher for performing
this scan.

Note:

You will not be able to click on the torch icon available next to the database system field in Dehydration Store repair pop-up if an association exists between the database system and SOA infrastructure. It is enabled only when the association is missing. When the association is missing, you can select appropriate database system target from target selector popup. Pop-up can be launched by clicking on the torch icon.

11.16.1 Running Functionality-Level Diagnostic Checks

To run diagnostic scans on the functionalities associated with an Enterprise Manager target and identify any setup issues, follow these steps:

  1. From the Targets menu, select Middleware.

  2. On the Middleware page, click the target you are interested in. For example, SOA Infrastructure.

  3. On the Home page of the target, from the target-specific menu, select Target Setup, and click Verification.

  4. On the Target Setup Verification page, in the Functionality Check section, click Scan.

  5. If setup problems are detected, repair them. See Section 11.16.3.

11.16.2 Running System-Level Diagnostic Checks

To run diagnostic scans on the system components that monitor an Enterprise Manager target and check their availability rate, follow these steps:

  1. From the Targets menu, select Middleware.

  2. On the Middleware page, click the target you are interested in. For example, SOA Infrastructure.

  3. On the Home page of the target, from the target-specific menu, select Target Setup, and click Verification.

  4. On the Target Setup Verification page, in the System Check section, click Scan.

    Note:

    • The Availability(%) column shows the availability rate of the target types. Click the rate to drill down and view more details.

    • The Time since last collection (min) column shows the total time elapsed since the last metric collection for the target.

11.16.3 Repairing Target Monitoring Setup Issues

To repair any target monitoring setup-related issues, follow these steps:

  1. Run functionality-level diagnostic scan to identify setup-related issues. See Section 11.16.1.

  2. If setup issues are found in the Functionality Check section, click the repair icon against the functionality that requires to be fixed.

    In the dialog that appears, enter the required details, and click Re-Scan and Save to validate the credentials, run the functionality check again, and save the details in Enterprise Manager. If you are sure the credentials are correct, then click Save to save the details without running the check again.

    Note:

    • The host credentials you are expected to provide are credentials of the host where the Management Agent, which monitors the SOA Infrastructure, is running.

    • While repairing dehydration store issues, you are required to provide SOA dehydration store configuration details such as the database system and the SOA repository credentials.

      If the configuration information has been collected, and if the association between the database system and the SOA infrastructure already exist, then the database system is prepopulated by default, and you need to enter only the credentials of the SOA repository. Otherwise, click the torch icon and manually select the database system with which the SOA infrastructure communicates, and enter the credentials of the SOA repository.

      The connection descriptor is prepopulated by default is an editable field, and appears in multiple rows if it is an Oracle RAC database. Do not modify the descriptor unless you want to correct it.

      The data source type is displayed only if the database system is an Oracle RAC database. The data source type can be either Multi Data Source or GridLink Data Source. Also note, that the data source type appears as 'NA' if details of the database system do not match with the connection descriptor.

11.17 Searching Faults in the SOA Infrastructure

This section describes how you can search faults in the SOA infrastructure. In particular, you can perform the following tasks:

11.17.1 Overview of Faults and Fault Types in SOA Infrastructure

The following are the types of SOA composite application faults displayed in Enterprise Manager Cloud Control:

  • Business: Application-specific faults that are generated when there is a problem with the information being processed (for example, a social security number is not found in the database).

  • System: Network errors or other types of errors such as a database server or a web service being unreachable.

  • Oracle Web Service Manager (OWSM): Errors on policies attached to SOA composite applications, service components, or binding components. Policies apply security to the delivery of messages.

The following are the categories of SOA composite application faults in Enterprise Manager Cloud Control:

  • Recoverable

    • Business faults and some specific system faults

    • Oracle Mediator input file path and output directory mismatch

    • An Oracle BPM Worklist user is not authorized to perform relevant (expected) actions

  • Nonrecoverable

    • Rejected messages

    • Most system faults

    • Non-existent references

    • Service invocation failures

    • Policy faults

  • Rejected Messages

    A fault is classified as a rejected message based on where it occurs. If a fault occurs before entering a SOA composite, without generating a composite instance, it is classified as a rejected message. A system or a policy fault can be identified as a rejected message.

11.17.2 Overview of the Recovery Actions for Resolving Faults

Recovery actions enable you to recover or resolve the SOA composite application faults. The following describes the recovery actions supported for different SOA engines.

Table 11-5 Overview of the Recovery Actions for Resolving Faults

Recovery Action Description Applicable To SOA Engine Type

Retry

Retries the instance directly. An example of a scenario in which to use this recovery action is when the fault occurred because the service provider was not reachable due to a network error. The network error is now resolved.

  • BPEL

  • BPMN

  • Mediator

Abort

Terminates the entire instance.

  • BPEL

  • BPMN

  • Mediator

Continue

Ignores the fault and continues processing (marks the faulting activity as a success).

  • BPEL

  • BPMN

Rethrow

Rethrows the current fault. BPEL fault handlers (catch branches) are used to handle the fault. By default, all exceptions are caught by the fault management framework unless an explicit rethrow fault policy is provided.

  • BPEL

  • BPMN

Replay

Replays the entire scope again in which the fault occurred.

  • BPEL

  • BPMN


11.17.3 Prerequisites for Searching, Viewing, and Recovering Faults

Meet the following prerequisites before searching, viewing, and recovering SOA composite application faults:

  • Ensure that the SOA infrastructure is monitored by an Oracle Management Agent (Management Agent) that is running on the same host as the SOA infrastructure. At the moment, there is no support for searching, viewing, and recovering faults from a SOA infrastructure that is monitored by a remote Management Agent.

  • Set the following as preferred credentials. These credentials can be set from the Target Setup Verification page. To do so, from the Targets menu, select Middleware. On the Middleware page, click the target you are interested in. For example, SOA Infrastructure. On the Home page of the target, from the target-specific menu, select Target Setup, and click Verification:

    • Credentials of the host on which the SOA server is running.

    • Administrator credentials of the Oracle WebLogic Domain.

11.17.4 Searching and Viewing Faults

To search and view SOA composite application faults, follow these steps:

  1. Meet the prerequisites. See Section 11.17.3.

  2. From the Targets menu, select Middleware.

  3. On the Middleware page, click the SOA Infrastructure target.

  4. On the SOA Infrastructure target page, click Faults and Rejected Messages.

  5. In the Faults and Rejected Messages tab, set the search criteria. See Section 11.17.4.1.

  6. Click Search.

  7. View the faults:

    • To know the total faults in the SOA infrastructure, see Total Faults in SOA Infrastructure, which is placed in the footer of the results table.

    • To know the number of faults displayed in the table (out of the total number of faults in the SOA infrastructure), see Displayed Faults, which is placed in the footer of the results table.

    • To view details of each fault, see the results table.

    • To hide or unhide columns in the table, from the View menu, select Columns, then select the column name you want to hide or unhide.

    • To filter or perform a fine search for a particular column, enter a search keyword in the textbox placed above the column header. See Section 11.17.4.7

      For example, to filter and list all faults related to the BPEL engine type, in the Engine Type column, type bpel.

    • To sort the fault details alphabetically, click the column header based on which you want to sort the details.

    • To find out the number of rows to which the search results have been restricted, see the note below the table.

      For example, the following note appears if the rows were restricted to 20.

      This table of search results is limited to 20 fault instances. Narrow the
      results by using the search parameters.
      

11.17.4.1 Setting Search Criteria

To search for faults and messages, enter details as described in the following table, and click Search.

Table 11-6 Setting Search Criteria

Field Description

Composite

Select the composite for which you want to search faults.

Error Message Contains

Enter the keywords you are looking for in the error messages of the faults so that faults with only such keywords can be searched. The value can be an alphanumeric value, and can have special characters, including wildcard characters. The value must not exceed 100 characters.

Fault Id

Enter the ID of the fault you want to search. The value must be a numeric value.

ECID

Enter the Execution Context ID so that only faults occurring within that particular context ID can be searched. The value must be a numeric value.

Fault Time From

Select the date and time from when you want to search for faults. By default, the date and time when you access the page appears.

For example, if you select 02/25/2013 02:45:32 AM, then all faults that occurred from this date and time will be searched for in the selected composite.

Fault Time To

Select the date and time till when you want to search for faults.

For example, if you select 02/28/2013 02:45:32 AM, then all faults that occurred till this date and time will be searched for.

Fault Type

To search for all types of faults, select All Faults.

To search for a particular type of fault, select one of the following:

  • System Faults, indicate all network errors or other types of errors such as a database server or a web service being unreachable.

  • Business Faults, indicate all application-specific faults that were generated when there was a problem with the information processed (for example, a social security number is not found in the database).

  • OWSM Faults, indicate Oracle Web Service Manager errors on policies attached to SOA composite applications, service components, or binding components. Policies apply security to the delivery of messages.

Component Type

To search for faults in all the component types, select All.

To search for faults in a particular component type, select an appropriate component type: BPEL, BPMN, Mediator, Business Rules, or Human Workflow.

Fault State

To search for faults in any state, select All. To search for faults in a particular state, select one of the following:

  • Recoverable, indicates business faults and some specific system faults, Oracle Mediator input file path and output directory mismatch faults, and other faults related to Oracle BPM Worklist, where the user is not authorized to perform any relevant (expected) actions.

  • Nonrecoverable, indicates rejected messages, most system faults, non-existent references, service invocation failures, and policy faults.

Instance ID

Enter the composite instance ID from which you want to search faults. The value must be a numeric value.

Restrict Search Result (rows)

By default, the search results are restricted to 500 rows in the table. If you want to modify this limit or restriction, enter a suitable value.

The highest value you can enter as the limit depends on the limit set on the OMS. When no limit is set on the OMS, the limit that is honored by default is 2000, so the default range you can enter in the Restrict Search Result (rows) field is 1 to 2000.

To modify this maximum limit set on the OMS, run the following command:emctl set property -name oracle.sysman.core.uifwk.maxRows -value <max_limit_value>

Note: The higher the value you set as the limit, the longer it takes to retrieve the faults. Entering a value higher than the default in Restrict Search Result (rows) field can lead to longer time to retrieve the faults, and therefore result in a longer load time.


11.17.4.2 Finding Total Faults in the SOA Infrastructure

To find the total faults in the SOA infrastructure, follow these steps:

  1. Search for faults in the SOA infrastructure. See Section 11.17.4.

  2. Once the search results appear, see Total Faults in SOA Infrastructure, which is placed at the bottom-right corner, below the table.

    Note:

    While retrieving the total faults in the SOA infrastructure, the Restrict Search Result (rows) field in the search criteria is not considered. For example, if there are a total of 700 faults, and if you enter 500 for this field, then the search is performed to list only 500 faults in the table, but the Total Faults in SOA Infrastructure field displays 700.

11.17.4.3 Limiting Faults Searched and Retrieved from the SOA Infrastructure

When you search for faults in the SOA infrastructure, the search might result in numerous faults. By default, the search results are restricted to 500 rows in the table. However, you can choose to modify this limit if you want.

To modify the limit, set the Restrict Search Result (rows) field to a suitable value while setting the search criteria (see Section 11.17.4.1). Then search.

The highest value you can enter as the limit depends on the limit set on the OMS. When no limit is set on the OMS, the limit that is honored by default is 2000, so the default range you can enter in the Restrict Search Result (rows) field is 1 to 2000.

To modify the maximum value set on the OMS, run the following command:

emctl set property -name oracle.sysman.core.uifwk.maxRows -value <max_limit_value>

Caution:

The higher the value you set as the limit, the longer it takes to retrieve the faults. Entering a higher value than the default in Restrict Search Result (rows) field can lead to longer time to get the faults, and therefor result in a longer load time.

11.17.4.4 Searching Only Recoverable Faults

There might be numerous faults in the SOA infrastructure, but you can search and view only the recoverable faults. For example, there might be 700 faults in total, but there may be only 550 recoverable faults; you can search and list only those 550 faults if you want.

To search only for recoverable faults, while searching for faults (see Section 11.17.4), set the search criteria with the Fault State list set to Recoverable. If you set it to All, then faults that are recoverable and not recoverable are searched and listed.

11.17.4.5 Searching Faults in a Particular Service Engine

There might be faults across various service engines such as BPEL, BPMN, Mediator, Business Rules, and Human Workflow. You can search and view only faults occurred in a particular service engine.

To search for faults in a particular service engine, set the search criteria with the Component Type list set to a particular service engine of interest (see Section 11.17.4.1). Then search.

11.17.4.6 Searching Faults by Error Message

There might be numerous errors in the SOA infrastructure, but you might be interested only in those errors that contain some keywords of your interest. For example, you might be interested only in errors that contain the word ORAMED. You can search and view faults with such keywords.

To search faults by error messages, set the search criteria with the Error Message Contains field set to some keywords of your interest (see Section 11.17.4.1). Then search.

Note:

  • By default, the entered keywords are searched anywhere in the error message.

  • The keywords you enter are case sensitive.

  • The only wildcard character permitted is %, which signifies all or anything after, before, or between two keywords. For example, BPEL%fault will result in faults with the error message BPEL is a fault.

11.17.4.7 Filtering Displayed Search Results

When you set the search criteria and search for faults in the SOA infrastructure, and when the search results appear in the results table, you can filter the search results further to show only those rows or fault instances that interest you, based on a keyword entered in the column header.

For example, from the displayed fault instances, to filter and view only the bpel service engine's results, enter the keyword bpel in the textbox placed above the Component Type column header. This is essentially the value shown in the bpel fault instance row for the Component Type column.

To filter the displayed search results, follow these steps:

  1. Search for faults in the SOA infrastructure. See Section 11.17.4.

  2. Once the results appear in the table, in the textbox placed above the header of the column you want to filter, enter a search keyword.

    For example, to filter and list all faults related to the BPEL engine type, in the textbox placed above the Engine Type column header, type bpel.

11.17.5 Recovering a Few Faults Quickly (Simple Recovery)

To recover only a few SOA composite application faults quickly, follow these steps:

  1. Meet the prerequisites. See Section 11.17.3.

  2. From the Targets menu, select Middleware.

  3. On the Middleware page, click the SOA Infrastructure target.

  4. On the SOA Infrastructure target page, click Faults and Rejected Messages.

  5. In the Faults and Rejected Messages tab, set the search criteria. See Section 11.17.4.1.

  6. Click Search.

  7. In the table, select one or up to 5 faults at a time, and from the Recovery Options menu, select an appropriate recovery action that matches your requirement. For information on the recovery actions, see Section 11.17.2.

  8. Enterprise Manager displays an informational message with one of the following mentioned to confirm whether or not it can submit the recovery job successfully. Click OK, and take the necessary action if required.

    • If you have selected more than 5 faults, then the recovery job is not submitted. Select 5 or fewer faults, and try again. Alternatively, select 5 or more, and try a bulk recovery. See Section 11.18.1.

    • If there are no recoverable faults, then the recovery job is not submitted.

    • If there are faults that are recoverable and not recoverable, then the recovery job is submitted only for recoverable jobs. You can track the recover job. See Section 11.18.2.

  9. Perform Step (1) to Step (5) again to verify if the faults you selected for recovery still appear in the search results. If they do not appear, then the recovery operation for those faults has been successfully submitted.

11.18 Creating and Tracking Bulk Recovery Jobs

This section describes the following:

11.18.1 Recovering Faults in Bulk (Bulk Recovery)

To directly recover a large number of faults from the SOA database, follow these steps to perform a bulk recovery:

  1. Meet the prerequisites. See Section 11.17.3.

  2. Access the Create Bulk Recovery or Bulk Recovery Jobs page in one of the following ways. (If you are already on one of these pages, ignore this step.)

  3. On the Create Bulk Recovery page, in the Composites section, click Add to add additional composites for which faults must be searched. You can add up to 10 composites.

    Note:

    You can add only up to 10 composites.
  4. In the Fault Details section, set the details of the faults you want to recover. See Section 11.18.1.3.

  5. In the Recovery Options section, set the recovery and batch parameters. See Section 11.18.1.4.

  6. In the Job Parameters section, schedule the bulk recovery job. See Section 11.18.1.5.

  7. To verify the number of faults that will be recovered for the given criteria, click Estimate Faults.

    A pop-up appears informing you of the total number of faults in the SOA Infrastructure based on the criteria you have set. Based on the count, you can decide whether or not you want to proceed. If required, you can adjust the settings. For example, you can modify the fault time period.

  8. If you are ready to perform the bulk recovery, click Submit.

  9. Track the status of the bulk recovery job. See Section 11.18.2.

  10. Search for faults again to verify if the faults you selected for recovery still appear in the search results. If they do not appear, then the recovery operation for those faults has been successfully submitted. See Section 11.17.4.

11.18.1.1 Navigating to the Bulk Recovery Jobs Page Directly

To navigate directly to the Bulk Recovery Jobs page, follow these steps:

  1. From the Targets menu, select Middleware.

  2. On the Middleware page, click the SOA Infrastructure target.

  3. On the SOA Infrastructure target page, from the SOA Infrastructure menu, select Fault Management, then select Bulk Recovery.

  4. On the Bulk Recovery Jobs page, click Create Job.

11.18.1.2 Navigating to the Create Bulk Recovery Page From SOA Infrastructure

To navigate to the Create Bulk Recovery page from the SOA Infrastructure Faults and Rejected Messages tab, follow these steps:

  1. From the Targets menu, select Middleware.

  2. On the Middleware page, click the SOA Infrastructure target.

  3. On the SOA Infrastructure target page, click Faults and Rejected Messages.

  4. In the Faults and Rejected Messages tab, set the search criteria. See Section 11.17.4.1.

  5. Click Search.

  6. In the table, select one or more faults, and click Bulk Recover.

  7. If you want to automatically include other faults, which you have not explicitly selected in the table, but belong to the same composite as the faults you have selected in the table, then in the Populate Options dialog, select Same composites as selected faults.

    Enterprise Manager automatically identifies all other faults belonging to the same composites as the selected faults, and lists them in the next page for bulk recovery.

11.18.1.3 Setting Fault Details for Recovering Faults in Bulk

To set the fault details while recovering faults in bulk, follow these steps:

  1. On the Create Bulk Recovery page, in the Fault Details section, select an engine type and enter a keyword you are looking for in the error messages so that only faults with such error messages are recovered.

  2. From the Time Period list, select a time period for which the faults must be recovered. The default is Last 1 Day, but if you want to customize the time period, you can select Custom from the list, and enter the start and end time stamp.

    Note:

    If you schedule a repeating job (see Section 11.18.1.5) with a custom fault time period, then all executions of the job use the same fault time period to recover faults. The time zone of the fault time you set is the time zone of the host where the Oracle Management Agent, which monitors the target, is installed. This information is displayed on the top-right corner of the Home page for any target.

11.18.1.4 Setting Recovery and Batch Details for Recovering Faults in Bulk

To set the recovery and batch details for recovering faults in bulk, follow these steps:

  1. On the Create Bulk Recovery page, in the Recovery Options section, from the Recovery Action list, select a recovery action. For information on recovery actions, see Section 11.17.2.

  2. By default, Batch by Fault Time is enabled so that faults can be grouped into multiple, smaller units or batches based on the time they were created, and run sequentially. Oracle recommends that you keep the option enabled to simplify the fault recovery process. However, if you do not want to create batches for some reason, then deselect this option.

  3. If you keep the Batch by Fault Time option enabled, then do the following:

    1. By default, the batches are created with faults that occurred within every 10 minutes. If you want to change this time period, then enter a value in minutes in the Batch Time Period field. The minimum time period is 5 minutes and the maximum time period is 360 minutes.

    2. By default, the delay time between two batches is set to 300 seconds. If you want to change this delay time, then enter a value in seconds in the Delay between batches (secs) field. The minimum delay time is 5 seconds and the maximum delay time is 900 seconds.

Example
You might want to recover faults that occur from 02/08/2013 2:00 am to 02/09/2013
2:00 am, in batches of 1 hour, with a delay of 300 seconds between each batch. 

To do so, while setting the fault details (see Section 11.18.1.3), select Custom
from the Time Period list, and set Fault Start Time to 02/08/2013 2:00 am and
Fault End Time to 02/09/2013 2:00 am. Then, while setting the recovery and batch
details (as described in this topic), set Batch Time Period (mins) to 60 and Delay between batches (secs) to 300. 

Based on these settings, the first batch starts recovering faults that occurred on
02/08/2013 between 2:00 am and 3:00 am. Then, there is a delay of 300 seconds. And
then, the next batch starts recovering faults that occurred on 02/08/2013 between
3:00 am and 4:00 am. This pattern of recovery continues until the final batch
recovers faults that occurred on 02/09/2013 between 1:00 and 2:00 am.

11.18.1.5 Scheduling Bulk Recovery Jobs to Run Once or Repeatedly

To schedule bulk recovery jobs, on the Create Bulk Recovery page, in the Job Parameters section, select one of the following options:

  • To run the jobs only once, select one of these options:

    • Immediately, if you want to run the job immediately.

    • Later, if you want to run the job just once, at a schedule date and time, and not immediately.

  • To run the jobs repeatedly at a set frequency, from the Repeat list, select an appropriate option, and set the frequency.

    Note:

    For a repeating job, if you set a custom fault time period (see Section 11.18.1.5), then all executions of the job use the same fault time period to recover faults. The time zone of the fault time you set is the time zone of the host where the Oracle Management Agent, which monitors the target, is installed. This information is displayed on the top-right corner of the Home page for any target.
  • To set a grace period, select Do not run if it cannot start within, and set an appropriate grace period.

    A grace period is a period of time that defines the maximum permissible delay when attempting to run a scheduled job. If the job system cannot start the execution within a time period equal to the scheduled time + grace period you set, then it skips the job. By default, all jobs are scheduled with indefinite grace periods.

Example
You might want to recover faults that occur from 02/08/2013 2:00 am to 02/09/2013
2:00 am, in batches of 1 hour, with a delay of 300 seconds between each batch,
repeatedly every 2 days, starting from 02/10/2013 10:00 am to 02/14/2013 10:00 am.

To do so, while setting the fault details (see Section 11.18.1.3), select Custom
from the Time Period list, and set Fault Start Time to 02/08/2013 2:00 am and
Fault End Time to 02/09/2013 2:00 am. Then, while setting the recovery and batch
details (as described in this topic), set Batch Time Period (mins) to 60 and Delay between batches (secs) to 300. 

Then, while scheduling the recovery job, select Repeating, set Every to 2 and
select Days, then set Starting to 02/10/2013 10:00 am and Ending to 02/14/2013 10:00 am.

Based on these settings, on 02/10/2013 10:00 am, the first batch starts recovering
faults that occurred on 02/08/2013 between 2:00 am and 3:00 am. Then, there is a
delay of 300 seconds. And then, the next batch starts recovering faults that
occurred on 02/08/2013 between 3:00 am and 4:00 am. This pattern of recovery
continues until the final batch recovers faults that occurred on 02/09/2013
between 1:00 and 2:00 am. This recovery job starts all over again on 02/12/2013
10:00 am, and repeats itself on 02/12/2013 10:00 am.

11.18.2 Tracking Bulk Recovery Jobs, and Viewing Their Results and Errors

To track bulk recovery jobs and view their results and errors, follow these steps:

  1. From the Targets menu, select Middleware.

  2. On the Middleware page, click the SOA Infrastructure target.

  3. On the SOA Infrastructure target page, from the SOA Infrastructure menu, select Fault Management, then select Bulk Recovery.

  4. On the Bulk Recovery Jobs page, you can view details such as the job name, the date and time when it ran or is scheduled to run, the user who scheduled the job, the current status of the job, the faults that were recovered and not recovered.

    Note:

    • This page lists only those jobs that ran in the last three days, and only for the current user. The list also include jobs submitted via EM Command Line Interface (EM CLI).

    • The Recovered Faults column displays the number of faults for which the recovery has been attempted by the SOA Suite so far for the job. The Not Recovered Faults column displays the number of faults for which the recovery could not be attempted by the SOA Suite due to some errors.

  5. Click the name of the job for which you want to view more details such as its actual results, the job failure errors, and the recovery errors.

    Enterprise Manager displays the Bulk Recovery Job Details page that provides the following information.

    Section Name Description
    Results Provides the status of the recovery job, essentially details such as the composite selected for recovery, the ID of the faults selected for recovery, and the recovery attempt status of the faults, which can be either Recovered or Not Recovered.

    Note: The recovery status indicates only the recovery attempt status, and not the actual recovery status of the fault. To know the actual recovery status, search for the fault ID. How?

    Job Failure Error Provides details of the failed recovery jobs. The errors are shown from the last point of failure of the job.

    The details include:

    • Failed Step Name, the name of the step of the recovery job that failed. The job has two steps, mainly pre-check and recover_faults. The recover_faults step runs once for every batch of the job, or only once if batching is not enabled.

    • Failed Step Output, the output of the failed job step.

    • Parsed Error Message, any known error message that is as part of the step output.

    • Composite, the name of the composite selected for the recovery job.

    • Fault Time From, the start date and time from when faults occurred and for which the recovery job was submitted

    • Fault Time To, the end date and time till when faults occurred and for which the recovery job was submitted

    • Error Details, the error indicating that the status of the recovery job could not be retrieved. This means that the recovery was attempted for the given composite and time period, but there was a time-out while retrieving the status.

      To verify if the faults were recovered, search for the faults for the given composite and time period again. How?

      To run the recovery job again, reduce the batch time period to a value lower than the value you entered earlier (see Section 11.18.1.4), and submit the bulk recovery job again (see Section 11.18.1).


11.18.3 Creating Bulk Recovery Jobs Using EMCLI and Web Services

You can create Bulk Recovery Jobs for a SOA Infrastructure Target from the command line using EM CLI, from EM Job Systems using Web-Service Interface, or from Cloud Control UI.

This section contains the following sections:

11.18.3.1 Creating Bulk Recovery Jobs Using EMCLI

In EM CLI, use EM job system's get_jobs command to submit bulk recovery jobs. The inputs to the job are supplied using a properties file.

To create the bulk recovery job using EMCLI, follow these steps:

  1. Log in to EMCLI. For example:

    emcli login -username=sysman
    
  2. Find out the input parameters to be entered in the property file to run the bulk recovery job. To do so, run the following command:

    emcli describe_job_type -type=SOABulkRecovery
    
  3. Use any editor to open the properties file, and provide your inputs. You can then save and close the properties file.

    Using any editor, create a new text file. For example, temp.properties

    Here's a sample Property File:
    
    target_list=<soa-infra target name>:oracle_soainfra
    variable.CompositeList=<composite1 target name>, <composite 2 target name>
    variable.BatchDelay=300
    variable.BatchSize=10
    variable.EnableBatching=1
    variable.EngineType=BPEL
    variable.ErrorMsg=xxxx
    variable.FaultStartTime=01-01-2013 00:00:00 PST
    variable.FaultEndTime=01-02-2013 00:00:00 PST
    variable.FaultTimePeriod=Custom
    variable.RecoveryAction=Continue
    

    Note:

    Currently, Oracle supports only one SOA-Infrastructure target to be entered in the target_list property.
  4. Run the following command to submit a bulk recovery job with the updated property file as an input:

    emcli create_job -name=bulk522 -job_type=SOABulkRecovery -input_file=property
    file:/tmp/temp.properties
    
  5. Set the preferred credentials or named credentials for the WebLogic Domain and SOA Server Host. By default, the job uses the preferred credentials, that is, WebLogic Administrator Credentials for the WebLogic domain and Normal Host Credentials for the SOA Server hosts.

    To set the preferred credentials, run the following commands:

    Setting WebLogic Domain Credentials:
    emcli set_preferred_credential -target_type=weblogic_domain -target
    name=<weblogic domain target name> -set_name=WLCredsNormal -credential
    name=<existing named credential name> -credential_owner=<user>
    
    Setting SOA Host Credentials:
    emcli set_preferred_credential -target_type=host -target_name=<host target
    name> -set_name=HostCredsNormal -credential_name=<existing named credential
    name> -credential_owner=<user>
    

    Alternately, you can override the preferred credentials by supplying the named credentials as an input to the property file for the current submission.

    Following example describes how to set the named credentials for the WebLogic Domain and SOA Server host:

    target_list=<SOA-Infra TargetName>:oracle_soainfra
    cred.SOAAgentHostCred.<slc01nbo.us.oracle.com>:<host>=NAMED:xxxx
    cred.SOADomainCreds.<target_name>:<target_type>=NAMED:xxxx
    

11.18.3.2 Viewing the Submitted Jobs and Outputs Using EMCLI

The following table describes certain other operations that can be performed using EMCLI commands.

Table 11-7 EMCLI Commands For Bulk Recovery

EMCLI Command Description Example

get_jobs

This EMCLI command to view all the Bulk Recovery Jobs that have been submitted.

emcli get_jobs -targets=<SOA-Infra target name>:oracle_soainfra -format=name:csv | grep BULK521

get_job_execution_detail

This EMCLI command to view the output of the Bulk Recovery job execution. To view the details of the job steps, you need to supply the Execution ID of the job.

Note: The output of the job that is displayed using the EMCLI command is unstructured. For a complete and structured report of the output, log in to Enterprise Manager Cloud Control. From Enterprise menu, select Job, and then click Activity. On the Job Activity Page, in the Advanced Search region, enter the name of the job, and then click Go. Select the job, and drill down to the steps by click Expand All.

Run the following command to get the Execution ID of the job:

emcli get_jobs -targets=<SOA-Infra target name>:oracle_soainfra -format=name:csv | grep BULK521

Use the Execution ID in the following command to view the details of the job submitted:

emcli get_job_execution_detail -execution=D4081BAB8942F246E040F00A5AA93E04 -xml -showOutput


11.18.3.3 Creating Bulk Recovery Jobs through Web-Service

In addition to EM User Interface and EMCLI, you can also use Web-Service Interface provided by EM job system to create Bulk Recovery Jobs. The web-service interface of the Job System is available by default in an EM installation, and the URL for the WSDL is as follows:

<protocol>://<machine>:<port>/em/websvcs/extws/JobControlService?wsdl

The EM job system web services are implemented as Simple Object Access Protocol (SOAP) end-points. Client programs can access these end-points using a variety of languages like Java, C++, and Ruby. The web service is used by sending a SOAP request message to one of the end-points, and retrieving the corresponding response message.

Typically, the operations exposed by Job system in the Web-Service Interface is very similar to the EMCLI operations such as create_job, describe_job_type, and so on.

11.19 Recovering BPEL/BPMN Messages

To find recoverable instances of the BPEL or BPMN Service Engine, follow these steps:

  1. From the Targets menu, select Middleware.

  2. On the Middleware page, click the SOA Infrastructure target.

  3. On the SOA Infrastructure target page, from the SOA Infrastructure menu, select Service Engine, then select BPEL/BPMN. Based on the selection, the home page of the service engine is displayed.

  4. On the home page, select the Recovery tab.

  5. To recover messages in which faults occurred, select one or more messages in the table, up to a maximum of 5 messages at a time, and click Recover.

    Search again to verify if the faults you selected for recovery still appear in the search results. If they do not appear, then the recovery operation for those faults has been successfully submitted.

    Note:

    To mark messages so that they are never delivered, select one or more message in the table, and click Cancel.

11.20 Troubleshooting

This section describes the errors you might encounter while discovering the SOA Suite 11g and the workaround steps you can follow to resolve each of them.

This section covers the following:

11.20.1 Discovery

The following error occurs when the SOA instances are being discovered.

Table 11-8 Error Message

Error Message Workaround Steps
New SOA Composite deployed on the SOA 
Server from JDeveloper are not 
displayed automatically in Enterprise 
Manager Cloud Control.

To discover the newly deployed SOA Composites in Enterprise Manager Cloud Control, you must run the Refresh Farm menu option for the associated WebLogic Domain.


11.20.2 Monitoring

The following error occurs when the collection frequency causes a delay in the collection of configuration data.

Table 11-9 Error Message

Error Message Workaround Steps
All metrics are not displayed.

Enterprise Manager Cloud Control uses the Management Agent to collect metric data. For the first collection, the agent may need 15 minutes to upload the metric data.


11.20.3 Instance Tracing

The following error occurs when the instance is traced.

Instance Search Fails - Same reason as BPEL first column. If Management Agent is down or unreachable.

Table 11-10 Error Message

Error Message Workaround Steps
Instance Tracing Job Fails
  1. Navigate to the Jobs page, and locate the Instance Tracing job (TRACE SOA INSTANCE ID + Instance ID + Submitted time) and view the output to identify the step that has failed.

  2. Resolve the issue and run the job again by clicking Retry on the Jobs page.

  3. Navigate to the Instance Tracing page to view the trace results. You can also submit a new job by running the Trace Instance option on the Instance Tracing page.


11.20.4 Recent Faults

The following errors occur when:

  • All instances with faults are not displayed as only the last 10 values are collected.

  • The most recently collected fault instances do not appear in the Faults and Messages page.

Table 11-11 Error Message

Error Message Workaround Steps
All instances with faults are not
populated in Enterprise Manager Cloud
Control. 

By default, you can only view the latest 10 faults collected during the last 15 minutes. To view additional faults, navigate to Fusion Middleware by clicking the link in the General section on the target Home page.


11.20.5 Fault Management

This section contains the troubleshooting information for fault management:

11.20.5.1 Bulk Recovery

In general when there is a Bulk Recovery Error, follow these steps to navigate to the page that describes the errors:

  1. In Cloud Control, from the Targets menu, select Middleware.

  2. On the Middleware page, click the SOA Infrastructure target.

  3. On the SOA Infrastructure target page, from the SOA Infrastructure menu, select Fault Management, then select Bulk Recovery.

  4. On the Bulk Recovery Jobs page, select the job that has failed.

  5. On the Bulk Recovery Job Details page, in the Job Failure Error section, check the Parsed Error Message and Error Details fields to understand about the error because of which the job failed.

The following are some of the error messages that you may see in the Parsed Error Message field along with their suggested fixes:

Table 11-12 Error Message

Error Message Workaround Steps
java.lang.IllegalArgumentExcept
on: Invalid Job Identifier! The
specified identifier does not
match any valid fault recovery 
jobs.
java.lang.IllegalStateException
The results job xxxx are not
available because the
processing has not yet
completed.
  1. Ensure the SOA Infrastructure is up and running.

  2. Choose a smaller value for Batch Time Period parameter that is entered while Creating a Bulk Recovery job.

    This will ensure lesser number of faults are recovered in each batch.

  3. Choose Fault time period appropriately excluding the fault time period for which faults have already been recovered by current job. To do so, follow these steps:

    1. The failed job details gives the Composite, Fault Time From and Fault Time To for which the recovery failed.

    2. Choose new Fault Time From of the new job as the Fault Time To of the failure point of the failed job.

  4. Submit another bulk recovery job with same parameters but with the reduced Batch Time Period value, and the new Fault Time From and Fault Time To.

t3://slc03dms.us.oracle.com:8001
javax.naming.CommunicationExce
ption [Root exception is
java.net.ConnectException:
t3://slc03dms.us.oracle.com:8001
/soa-infra: Destination
unreachable; nested exception
is: java.net.ConnectException:
Connection refused; No
available router to
destination]

Ensure that the SOA Infrastructure is up and running, and submit another bulk recovery job with the same parameters.


11.20.5.2 Fault Search and Recovery

The following error occurs when you are unable to connect to the SOA Infrastructure target:

Table 11-13 Error Message

Error Message Workaround Steps
Error connecting to SOA Infra
t3://slc03dms.us.oracle.com:80
01.

Ensure that the SOA Infrastructure is up and running.


11.20.5.3 Fault Management and Instance Tracing Errors

The following errors occur when the SOA database is not functional:

Table 11-14 Error Message

Error Message Workaround Steps
Error occured when getting
faults 
Java.rmi.RemoteException: EJB
Exception: ; nested exception
is: java.lang.RuntimeException:
java.lang.RuntimeException:
weblogic.jdbc.extensions.PoolD
isabledSQLException:
weblogic.common.resourcepool.R
esourceDisabledException: Pool
SOALocalTxDataSource is
Suspended, cannot allocate
resources to applications.

Ensure the SOA Database is up and running.

t3://slc03dms.us.oracle.com:80
01
javax.naming.CommunicationExce
ption [Root exception is
java.net.ConnectException:
t3://slc03dms.us.oracle.com:80
01/soa-infra: Destination
unreachable; nested exception
is: java.net.ConnectException:
Connection refused; No
available router to
destination]

Ensure the SOA Database is up and running.

Error occured when getting faults
oracle.sysman.emSDK.agent.comm
.exception.ConnectException:
Unable to connect to the agent
at
https://slc03dms.us.oracle.com
:3872/emd/main/ [Connection
refused]

Ensure the SOA Database is up and running.


11.20.6 Application Dependency and Performance Integration

When you click on the Application Dependency and Performance link in the SOA Instance Home page, you may see a blank page. This error may occur if:

  • Application Dependency and Performance is not being used to monitor the SOA instance.

  • Application Dependency and Performance has not been registered in Enterprise Manager Cloud Control.

Table 11-15 Error Message

Error Message Workaround Steps
Missing ADP Data - Add the metrics - 
and add one for blank page.

To monitor data collected using ADP, the ADP Manager must be registered and configured.


11.20.7 Information Publisher Reports

This section lists report related errors.

Table 11-16 Error Message

Error Message Workaround Steps
Report generation fails
due to invalid
database details.
  1. Navigate to the All Targets page.

  2. Select the SOA Infrastructure target on which the specific SOA Composite has been deployed and click Configure.

  3. In the Monitoring Configuration page, specify the database connection details and the credentials and click OK.

No targets found message
for Oracle
SOA Composite Reports.

You cannot use the out-of-box reports directly. You must use the Create Like option to generate custom reports based on the SOA Composite Target type.

Report generation fails
due to invalid host
details.

Set valid credentials for the host target on which the SOA Infrastructure instance is running.


11.20.8 BI Publisher Reports

This section lists BI Publisher report related errors.

Table 11-17 Error Message

Error Message Workaround Steps
Exception Encountered
For One of SOA BIP
Report If SOA
Dehydration Is Not
Configured

If the SOA Dehydration store details are not configured in BI Publisher, the SOA Composite Report (from Dehydration Store) is not generated, and the following exception message is displayed:

The report cannot be rendered because of an error, please contact the administrator. Parameter name: P_PARTITION_NAME Can not establish database connection(EMSOA)

To work around this issue, you must manually create the SOA database connection by choosing JDBC Connection from the Administration menu after the BI Publisher setup has been configured. The name of the data source name should be EMSOA. Use the following steps to create the EMSOA data source:

  1. From the Enterprise menu, select Reports, and then select BI Publisher Reports. The BI Publisher Enterprise login page appears.

  2. Enter your credentials to log in to BI Publisher.

  3. Click the Administration link available at the top right corner.

  4. Navigate to the Data Sources page by clicking the JDBC Connection link in the Data Sources section. Click Add Data Source.

  5. Enter EMSOA in the Data Source field, specify the driver type, driver class, connection string, user name, and password. Click Test Connection to ensure that the connection can be established successfully.

  6. Click Apply. The newly created EMSOA jdbc data source appears on the Data Sources page.

Once you have created the EMSOA data source, the issue should be resolved.


11.20.9 Systems and Services

The following error occurs when you try to refresh a service that has not been created.

Table 11-18 Error Message

Error Message Workaround Steps
Create Service option
does not work.

System and service creation depends on the configuration collection of the SOA Infrastructure and related targets. Check the log file for details.

Refresh Service option
does not work.

The Refresh Service function works for an existing Infrastructure service. In case the service does not exist, it should be created using the Create Service menu option.


11.20.10 BPEL Recovery

The following error occurs when invalid credentials are provided.

Table 11-19 Error Message

Error Message Workaround Steps
Invalid Host and
WebLogic Domain
Credentials

For the BPEL Recovery functionality to work, the host credentials and WebLogic Domain credentials must to be available in the preferred credential store. Set the valid credentials and try again.


11.20.11 SOA License Issue

The following error occurs if the SOA Management Pack EE has not been enabled.

Table 11-20 Error Message

Error Message Workaround Steps
The page requested is part of
the SOA Management Pack EE.

The SOA Management Pack EE must be enabled for the specific SOA Infrastructure target. To enable the license, follow these steps:

  1. From the Setup menu, select Management Packs, then select Management Pack Access.

  2. Select SOA Infrastructure in the Target Type drop-down box.

  3. Uncheck and check the SOA Management Pack EE.

  4. Click Apply and navigate to the SOA Composite page.


11.20.12 Dehydration Store Issue

Data is not displayed on the Dehydration Store page.

Table 11-21 Error Message

Error Message Workaround Steps
Data is not displayed in
the Dehydration Store
page.

This error may occur if there is a data mismatch between the values specified for the database target and the WebLogic Server Datasource. To resolve this issue, follow these steps:

  1. Compare the Database Host and SID value of the database target with the value collected for the WebLogic Server JDBC Datasource configuration.

  2. If the values are different, select Services from the Targets menu. Select DataSources, then select SOALocalTxtSource, then click Connection Pool to update the Datasource Connection URL