8 Configuring Operational and Global Settings

This chapter describes the settings that control the operation of Oracle Service Bus services in the runtime, including monitoring, alerts, message tracing, execution tracing, alerts, reporting, logging, and business service performance tuning. Certain operational settings are set at the service level, some are set at the global level, and some need to be set at both the service and global level in order to take effect.

This chapter includes the following sections:

8.1 Introduction to Operational Settings

By configuring operational settings in Fusion Middleware Control, you can control the state of each individual service and of all services globally. Along with controlling the state of each service and all services in a domain, operational settings let you enable and disable monitoring, alerting, reporting, and logging features.

You can also manage business services by specifying how to handle offline endpoint URIs, limiting the message flow, and enabling result caching. Global operational settings override service-level settings.

8.1.1 Available Operational Settings

Operational settings let you configure things like monitoring, alerts, reporting, logging, message tracing, and business service result caching. You can specify operational settings for all services, at the service and global level, and use the global settings to turn on and off monitoring, SLA alerts, pipeline message reporting, and pipeline message logging. The available settings are described in the following sections.

8.1.1.1 State

This operational setting enables or disables a service. By default, the state of all services is enabled.

8.1.1.2 Monitoring

This operational setting enables or disables service monitoring. For pipelines and split-joins, you can also configure the level at which monitoring is performed. Certain other operational settings, such as logging and alerts, rely on monitoring being enabled. By default, monitoring is disabled for all services.

For pipelines, monitoring can be enabled at the following levels.

  • Action (A)

  • Pipeline (P)

  • Service (S)

For split-joins, monitoring can be enabled at the following levels.

  • Activity (A)

  • Branch (B)

  • Service (S)

You configure the level on the pipeline or split-join Properties page, and the level indicator is displayed on the Service Bus and Service Bus Project Operations pages.

8.1.1.3 Aggregation Interval

This operational setting defines the aggregation interval for the service in hours and minutes. The aggregation interval is the time period over which statistical data is collected and displayed. The default interval is 10 minutes.

8.1.1.4 Service-Level Agreement Alerts

This operational setting enables service-level agreement (SLA) alerting for services at a specific severity level or above. You can also use this to disable SLA alerting for a service. By default, SLA alerting is enabled for all services.

SLA alerting can be enabled at the following levels. You configure the alerting level on the service's Properties page, and the level indicator is displayed on the Service Bus and Service Bus Project Operations pages.

  • Normal (N)

  • Warning (W)

  • Minor (Mn)

  • Major (Mj)

  • Critical (C)

  • Fatal (F)

8.1.1.5 Pipeline Alerts

This operational setting enables alerting for pipelines at a specific severity level or above. You can also use this to disable pipeline alerting. By default, pipeline alerts are enabled at the Normal level or higher. For more information about monitoring pipeline alerts, see Monitoring Oracle Service Bus Alerts. For information about configuring alerts, see Reporting Actions and Adding Alert Actions in Developing Services with Oracle Service Bus.

Pipeline alerting can be enabled at the following levels. You configure the level on the pipeline's Properties page, and the level indicator is displayed on the Service Bus and Service Bus Project Operations pages.

  • Normal (N)

  • Warning (W)

  • Minor (Mn)

  • Major (Mj)

  • Critical (C)

  • Fatal (F)

8.1.1.6 Reporting

This operational setting enables or disables message reporting for pipelines. In Service Bus, message data can be captured from the message body and other message variables. This data is then delivered to one or more reporting providers. Information about SLA violations is also included in the reporting data. By default, reporting is enabled at the Normal level or higher.

8.1.1.7 Logging

This operational setting enables logging at a specific severity level or above for pipelines and split-joins. The severity level of the log actions in the pipeline or split-join must match the Logging severity level on that pipeline's or split-join's operational settings. By default, logging is enabled at the Debug level or higher.

Logging can be enabled at the following levels. You configure the level on the Properties page for the pipeline or split-join, and the level indicator is displayed on the Service Bus and Service Bus Project Operations pages.

  • Debug (D)

  • Info (I)

  • Warning (W)

  • Error (E)

To see log data in the log file or standard out (server console), Oracle WebLogic Server logging must be set to specific severity levels. For more information, see Configuring Message Tracing for a Service.

8.1.1.8 Execution Tracing

This operational settings enables or disables execution tracing for pipelines and split-joins. Service Bus lets you trace messages without having to shut down the server, making it easier to troubleshoot and diagnose a message flow. By default, execution tracing is disabled. After you enable execution tracing, the system logs various details culled from the pipeline context and the message context. These details include: stage name; pipeline or route node name; and the current message context.

For tracing to appear in the log file or standard out (server console), Oracle WebLogic Server logging must be set to the Info severity level. For more information about execution tracing, see Using Execution Tracing to Diagnose Problems.

8.1.1.9 Message Tracing

This operational setting enables or disables message tracing for services at a specific detail level or above. You can also set the payload limit (in kilobytes) and the default encoding. By default, message tracing is disabled.

For tracing to appear in the log file or standard out (server console), Oracle WebLogic Server logging must be set to the Info severity level. For instructions on configuring message tracing, see Configuring Message Tracing for a Service. Additionally, you must provide the default encoding of the payload. For example, if the payload is in Shift_JIS encoding, specify that in the Default Encoding field to ensure that those bytes are converted to UTF8 in the log file.

8.1.1.10 Offline Endpoint URIs

This operational setting enables or disables non-responsive endpoints for business services. When you select this option, the business service removes non-responsive endpoint URIs (takes them offline), at runtime, so that only the responsive URIs are used for retry attempts and for processing subsequent requests.

You can specify the interval of time to wait before retrying the offline endpoint URI. You can enable or disable offline URIs for business services only. By default, offline endpoint URIs are disabled.

For more information about offline endpoint URIs, see Monitoring and Managing Endpoint URIs for Business Services For instructions on marking endpoint URIs offline, see Configuring Service Bus to Take Unresponsive Endpoint URIs Offline.

8.1.1.11 Throttling Settings

You can restrict the flow of messages through a business service by enabling throttling for the service and configuring concurrency, the throttling queue, and a time to live (TTL) for queued messages. Throttling properties include the following:

  • Throttling State: This operational setting enables or disables throttling for a business service. By default, throttling is disabled.

  • Maximum Concurrency: This operational setting restricts the number of messages that can be concurrently processed by a business service. The default number of messages is 0 (zero), indicating no limit.

  • Throttling Queue: This operational setting restricts the maximum number of messages in the throttling queue. The default number of messages is 0 (zero), which implies that there is no queue.

  • Message Expiration: The maximum time interval (in milliseconds) for which a message can be placed in throttling queue. The default number of messages is 0 (zero), indicating no limit.

For more information about throttling business services, see Configuring Business Services for Message Throttling.

8.1.1.12 Result Caching State

This operational setting enables or disables result caching for a business service. By default, result caching is enabled globally. For more information about result caching, see "Improving Performance by Caching Business Service Results" in Developing Services with Oracle Service Bus.

8.1.1.13 Automatic Service Migration

Automatic Service Migration (ASM) leverages the WebLogic service migration framework to migrate services from servers that are down due to failure or maintenance to other available servers in the cluster.

Note:

This SOA Suite feature is part of Oracle Integration Continuous Availability. Please refer to Oracle SOA Suite for Oracle Middleware Options in the Oracle Fusion Middleware Licensing Information User Manual for more details on Oracle SOA Suite for Middleware Options.

Service Bus supports ASM for the following:

  • Singleton services, such as the Aggregator and the SLA Alert Manager

  • The File, FTP, SFTP, and Email poller transports. These transports are cluster singleton services that run on only one managed server in a cluster.

Note:

ASM is only available for clustered domains. It has no effect in single-node domains.

See Prerequisites to Enabling Automatic Service Migration for prerequisites to enabling ASM. Refer to Configuring Operational Settings at the Global Level to enable ASM.

When the ASM option is enabled, Service Bus deploys an app-scoped singleton service for the Aggregator service and each poller proxy service with a target of the preferred managed server first and the cluster second. Both the Aggregator service and the poller proxy services are eligible for migration to any server in a cluster; there are no sub-sets of servers in the cluster for service migration. A service’s polling will start on the preferred managed server initially. When the preferred managed server goes down, the services target managed servers available in the cluster sequentially. Even if the preferred managed server comes up in between, polling may not start on that server. All servers must be restarted after enabling ASM before processing messages.

Tip:

It is best practice to ensure that all managed servers are not running before enabling ASM. This avoids any ambiguous situations for message processing, particularly for poller transports.

After the ASM option is selected and the managed servers are restarted, performing these actions on poller proxy services in the Service Bus console has the following results:

  • Create: A new app-scoped singleton service is created for the new service.

  • Update/Rename/Move: A new app-scoped singleton service is created for that service and; the old singleton is undeployed and its files are deleted.

  • Delete: The singleton for that service is undeployed and its files are deleted.

  • Clone: A new app-scoped singleton service is created for the cloned service; the singleton for original service still exists.

  • Undo: Undoes the most recent change.

When the ASM option is disabled (after previously being enabled), Service Bus undeploys the singleton services that were created for the poller transports and deletes all files associated with them. All servers must be restarted after disabling ASM before these changes take effect.

ASM does not affect synchronous services, such as EJB, JEJB, and HTTP services. In these cases, the client receives and exception during invocation if the service is not available; the client must send the request again or the retry option must be configured, if available.

See Service Migration in Administering Clusters for Oracle WebLogic Server for additional information about the WebLogic Server service migration framework.

8.1.1.13.1 Prerequisites to Enabling Automatic Service Migration

Before enabling Automatic Service Migration in Enterprise Manager, update the Migration Basis for services and configure the alert store to use a WLDF JDBC-based store.

To complete the prerequisite tasks:
  1. Update the Migration basis in the WebLogic Administration Console, as described in the Leasing for Migratable Services topic in Administering Clusters for Oracle WebLogic Server. For production environments, Database leasing is recommended.
  2. Configure the Alert store to use a WLDF JDBC-based store instead of a file-based store.

    Note:

    If this store is not migrated, SLA and pipeline alerts will not be visible in the event that the Aggregator is migrated to a new server. For example, if the Aggregator singleton is migrated from Server 1 to Server 2, and then back to Server 1, the alerts from Server 1 are visible again, but the alerts from Server 2 are not visible.

8.1.1.13.2 What You Need to Know About Domain Behavior in ASM and Dynamic Clusters

This topic lists the different behaviors of the domain depending on whether the environment is clustered with or without ASM.

During domain creation in the Configuration Wizard:

  • ASM is selected and No Dynamic cluster chosen: The Enterprise Manager flag for OSB Singleton migration (OSB Singleton Components Automatic Migration) is automatically enabled in the Global Settings Page. The Aggregator Marker Application will be deployed to the cluster.

  • ASM is not selected and Dynamic cluster chosen with configured managed server: The Enterprise Manager flag for OSB Singleton migration (OSB Singleton Components Automatic Migration) is automatically enabled in the Global Settings Page. The Aggregator Marker Application will be deployed to the cluster.

  • ASM is selected and Dynamic cluster chosen with configured managed server: The Enterprise Manager flag for OSB Singleton migration (OSB Singleton Components Automatic Migration) is automatically enabled in the Global Settings Page. The Aggregator Marker Application will be deployed to the cluster.

  • ASM is not selected and No Dynamic cluster chosen: The Enterprise Manager flag for OSB Singleton migration (OSB Singleton Components Automatic Migration) is automatically disabled in the Global Settings Page. The Domain Marker Application will be deployed with target as one of the configured managed servers of the cluster.

  • ASM is not selected and Dynamic cluster chosen without configured managed server: The Enterprise Manager flag for OSB Singleton migration (OSB Singleton Components Automatic Migration) is automatically enabled in the Global Settings Page. In this case, the flag should not be changed from the Enterprise Manager. If it is changed, an exception will be raised in the server log and the flag is not updated.

Except for the last scenario, the OSB Singleton migration flag (OSB Singleton Components Automatic Migration) can be enabled and disabled from the Global Settings Page of the Enterprise Manager for OSB. If it is enabled, the Aggregator Marker Application is deployed to the cluster. If it is disabled, the Domain Marker Application is deployed to one of the configured managed servers of the cluster.

8.1.1.14 Comment Logging

Select this option to display a comment (description) in the <server_name>-diagnostic.log file in case of an error during pipeline execution. If this option is not selected, only the fixed node name appears in the log. The default value is false.

Note:

If you change the value of this parameter, the server must be restarted for the changes to take effect at runtime.

8.1.1.15 JavaScript Timeout

The JavaScript timeout is a value defining the time interval after which any JavaScript execution will be aborted with an error. The default value is 30 seconds.

8.1.1.16 Resequencer Settings

For services that use the resequencer to put messages in sequence, you can configure the resequencer settings, including the length of time the locker thread waits when it is unable to find a group with messages to process and the maximum number of resequencer groups to retrieve at one time. You can also configure the resequencer to purge messages that have been processed from the resequencer database.

8.1.2 Global and Service-Level Operational Settings

The runtime effects of the service-level settings depend on their corresponding global settings. You must enable both the global and service-level settings for a service to be completely enabled at runtime. The service state must also be enabled. You can change and save monitoring configuration settings even if the service will be not be enabled at runtime. For example, you can change and save the aggregation interval even if service monitoring is disabled. In this manner, you can edit settings and later enable them.

When you enable or disable monitoring at the global level, it enables or disables monitoring for all services that have individually been enabled for monitoring. If monitoring for a particular service has not been enabled, you must first enable it and set the aggregation interval for that specific service before the system starts collecting statistics for that service.

Enable or disable these settings at the global level in conjunction with the settings at the service level to effectively enable or disable them. The operational settings at the global level supersede the operational settings at the service level. The following settings must be enabled at the global level in order to be enabled for a specific service:

  • Monitoring

  • SLA Alerting

  • Pipeline Alerting

  • Reporting

  • Logging

  • Result Caching

  • Automatic Service Migration

  • JavaScript Timeout

  • Comment Logging Enabled

8.2 Viewing and Configuring Operational Settings

Use the Operations pages to easily locate proxy services, business services, pipelines, and split-joins, and to specify service-specific operational settings.

On the Service Bus or Service Bus Project Operation pages, you can set the aggregation interval, enable settings, and disable settings for multiple services. You can configure operational settings for a single service on that service's Properties page. When you update operational settings from the Service Bus or Service Bus Project Operations pages, you cannot specify an alerting or logging severity level, configure message tracing properties, or configure throttling or endpoint URIs for business services.

Keep in mind the following guidelines when configuring operational settings:

  • In general, properties must be enabled at both the service level and the global level in order to take effect.

  • Although you can configure SLA Alerts independently from Monitoring, there is an interaction between the two settings at runtime. If global monitoring is enabled, SLA alerts can be enabled or disabled. However, if global monitoring is disabled then SLA alerts are also effectively disabled because SLA alert rule conditions depend on monitoring statistics being evaluated.

  • If you disable monitoring for all services, all statistics collected so far for those services are deleted as well and the deletion of the statistics is irreversible.

Some operational settings such as service state, monitoring, SLA alerting, and pipeline alerting can also be enabled or disabled using public APIs. For more information, see Java API Reference for Oracle Service Bus.

8.2.1 Configuring Operational Settings at the Global Level

When you configure an operational setting at the global level (also called global settings), it affects all applicable services in the domain. Most settings must be enabled at both the service and global levels in order to take effect at runtime. Use the Global Settings tab of the Service Bus home page to update settings at the global level.

Figure 8-1 The Global Settings Tab

Description of Figure 8-1 follows
Description of "Figure 8-1 The Global Settings Tab"

To configure operational settings at the global level:

  1. In the Target Navigator, expand SOA and then select service-bus.

    The Service Bus Dashboard appears.

  2. Click the Global Settings tab.

    The Service Bus settings for the domain appears.

  3. To enable a setting, select its check box; to disable a setting, clear the check box.

    Each global setting is described in Table 8-1

  4. To revert all unapplied changes back to the saved settings, click Revert.
  5. When you are done configuring operation settings, click Apply to save your changes to the runtime.

8.2.2 Operational Settings at the Global Level

The following table describes operational settings at the global level.

Table 8-1 Operational Settings at the Global Level

Operational Setting Usage

Monitoring Enabled

Select this check box to enable monitoring for all services at the domain level. When this is enabled, the system collects monitoring statistics for all services whose monitoring is enabled at the service level.

Clear this check box to disable monitoring for all services at the domain level.This not only overrides the operational monitoring setting, but also the operational SLA alerts setting. If you disable monitoring at the global level, SLA alerts are also disabled, even though the SLA Alerts check box is selected for certain services.

Note: If you disable monitoring for all services, all statistics collected so far for those services are deleted as well. These statistics cannot be restored; the deletion of the statistics is irreversible.

SLA Alerting Enabled

Select this check box to enable SLA alerts for all services at the domain level. When SLA alerting is enabled, the system starts evaluating alert rules for all services in the domain.

Clear this check box to disable SLA alerts for all services at the domain level. When SLA alerting is disabled, the system stops evaluation alert rules for all services in the domain.

Although you can configure SLA Alerts independently from Monitoring, there is an interaction between the two settings at run time. If global monitoring is enabled, SLA alerts can be enabled or disabled. However, if global monitoring is disabled then SLA alerts will be effectively disabled because SLA alert rule conditions depend on monitoring statistics being evaluated.

Pipeline Alerting Enabled

Select this check box to enable pipeline alerting for all pipelines at the domain level. When pipeline alerting is enabled, the system executes any pipeline alert actions for proxy services.

Clear this check box to disable pipeline alerting for all pipelines at the domain level. When pipeline alerting is disabled, the system no longer executes any pipeline alert actions.

Reporting Enabled

Select this check box to enable pipeline report actions at the domain level and start any pipeline report actions. This option controls pipeline report actions on the message context only. It does not effect SLA alerts or pipeline alerts targeted to the reporting framework.

Clear this option to disable pipeline report actions at the domain level and stop any report actions for all proxy services.

Logging Enabled

Select this check box to enable pipeline and split-join log actions at the domain level. When this is enabled, pipeline and split-join Log action messages are sent to the WebLogic Server logging service. To view the messages, you must configure WebLogic Server to forward these messages to the domain log.

Clear this check box to disable pipeline and split-join log actions at the domain level. This stops any Log actions for all pipelines and split-joins.

Result Caching Enabled

Select this check box to enable result caching for business services at the domain level. If you invoke business services whose results seldom change, result caching improves business service performance by returning cached results to the client instead of waiting for the results of a service invocation.

Clear this check box to disable result caching for business services at the domain level. When you disable result caching globally, Service Bus flushes the entire cache, removing cached results for all business services with result caching enabled.

OSB Singleton Components Automatic Migration

Select this check box to enable Automatic Service Migration (ASM). When selected, Service Bus creates and deploys an app-scoped singleton service as an EAR, one for each poller proxy service and the aggregator service, targeted to the preferred managed server and cluster. When the preferred managed server goes down, the poller will target any available server in the cluster sequentially. All servers must be restarted after enabling ASM.

Clear this check box and apply the change to undeploy and delete all app-scoped singleton services. All servers must be restarted for this change to take effect.

Email Header Trim Enabled

Select this option to enable Service Bus to trim the message header in email business transport if it has more than 998 characters.

Comment Logging Enabled

Select this option to display a comment (description) in the <server_name>-diagnostic.log file in case of an error during pipeline execution. If this option is not selected, only the fixed node name appears in the log. The default value is false.

Note:

If you change the value of this parameter, the server must be restarted for the changes to take effect at runtime.

JavaScript Timeout

Specify the time interval (in seconds) after which any JavaScript execution terminates with an error. The default value is 30 seconds.

Resequencer Locker Thread Sleep

Specify the sleep interval for the locker threads in seconds. When the resequencer is unable to find a group with messages that can be processed, the locker thread sleeps for the specified duration. The locker thread does not sleep between each iteration of a database seek, as long as it finds groups with messages that can be processed. The default value is 10 seconds.

Resequencer Maximum Groups Locked

Specify the maximum number of groups that can be retrieved for processing in a single iteration of a database seek. Once retrieved, the groups are assigned to worker threads for processing. The default value is 5.

Purge Completed Messages

Select this option to purge resequenced messages that have completed processing from the resequencer database. This option is selected by default.

Note: When this option is selected completed messages cannot be viewed on the Resequence Messages tab.

8.2.3 Searching for Services to Configure Their Operational Settings

Fusion Middleware Control provides several options for configuring operational settings, but all begin with performing a search for the services you want to configure.

Note:

The following steps describe how to view and update operational settings for multiple services. You can also view and update settings for a single service on that service's Properties page.

To search for services to configure their operational settings:

  1. Do one of the following:
    • To search for services across the domain, in the Target Navigator expand SOA and select service-bus.

    • To search for services in a Service Bus project, in the Target Navigator expand SOA, expand service-bus, and select the name of the project in which to search.

  2. Click the Operations tab.
  3. Specify the search criteria to use to locate the services who settings you want to modify.

    You can specify the following criteria, all of which are optional except Type:

    • Type: Select from the list of available options, which includes all services, both business and proxy services, business services, proxy services, pipeline, or split-joins.

    • Name: Enter the name of the services to locate.

    • Path: The path (project name and folder names, if any) to the services to locate. If you are on the Service Bus Project Operations tab, the path is already filled in for you.

  4. Click Search.

    A list of services matching your criteria appears in the Operations table, as shown below. For more information about these settings, see Available Operational Settings and the online help provided with Fusion Middleware Control.

  5. To configure operational settings, continue to Enabling and Disabling Operational Settings for Multiple Services

8.2.4 Enabling and Disabling Operational Settings for Multiple Services

The settings you can configure for a service vary depending on whether you are configuring a business service, proxy service, pipeline, or split-join. When you configure settings for multiple services, you do so on the Operations tab of the Service Bus or Service Bus Project page. The Operations list on these pages only includes enabling and disabling operational settings. Any settings that require specific configuration, like throttling or offline endpoint URI management, can only be configured on a specific service's Properties page.

For information about configuring specific operational settings, see Available Operational Settings and the online help provided with Service Bus.

To configure operational settings for multiple services:

  1. Perform a search for services, as described in Searching for Services to Configure Their Operational Settings.
  2. For any service in the results list, select a check box to enable the corresponding operational setting, or clear a check box to disable the operational setting.
  3. To enable or disable an operational setting for all the services in the list, select or clear the check box in the column header for that setting.

    For information about the settings and notations in the Operations list, see Available Operational Settings and the online help provided with Fusion Middleware Control.

  4. To revert all unapplied changes back to the saved settings, click Revert.
  5. When you are done configuring operation settings, click Apply to save your changes to the runtime.

8.2.5 Enabling and Disabling Operational Settings for a Single Service

In addition to enabling and disabling operational settings from the Operations page of the Service Bus or Service Bus Project page, you can also enable and disable settings for a service from its Properties page. For most services, you can also configure the operational settings in more detail, such as setting logging and monitoring levels.

For information about configuring specific operational settings, see Available Operational Settings and the online help provided with Service Bus. The following figure shows the Properties page for a service.

Figure 8-3 Service Bus Service Properties

Description of Figure 8-3 follows
Description of "Figure 8-3 Service Bus Service Properties"

To enable or disable operational settings for a single service:

  1. Perform a search for services, as described in Searching for Services to Configure Their Operational Settings.
  2. In the Operations table, click the service you want to configure.

    The Properties page for that service appears.

  3. To enable a setting, select the Enabled check box for that setting.
  4. To disable a setting, clear the Enabled check box for that setting.
  5. To revert all unapplied changes back to the saved settings, click Revert.
  6. When you are done configuring operation settings, click Apply to save your changes to the runtime.

8.2.6 Setting the Aggregation Interval for a Service

Use a service's Properties page to set the aggregation interval for that service. The aggregation interval is the period over which aggregated statistics are computed for display in Fusion Middleware Control. The default aggregation interval setting is 10 minutes.

To set the aggregation interval for a service:

  1. Perform a search for services, as described in Searching for Services to Configure Their Operational Settings.
  2. In the Operations table, click the service you want to configure.

    The Properties page for that service appears.

  3. In the Aggregation Interval field under Monitoring, select the number of hours or minutes for the interval.

    If your selection for hours exceeds 1, then the default selection for minutes is always zero. However, if your selection for hours is 0 or 1, then you can configure intervals in terms of minutes.

  4. When you are done configuring operation settings, click Apply to save your changes to the runtime.

8.2.7 Configuring the Monitoring Level for a Pipeline or Split-Join

For pipelines and split-joins, you can specify the level at which the services are monitored. For more information, see Monitoring and the online help provided with Service Bus.

To configure the monitoring level for a service:

  1. Perform a search for services, as described in Searching for Services to Configure Their Operational Settings.
  2. In the Operations table, click the pipeline or split-join you want to configure.

    The Properties page for that service appears.

  3. In the Monitoring Level field under Monitoring, do the following:
    • For a pipeline, select Service, Pipeline, or Action to indicate the level.

    • For a split-join, select Service, Branch, or Activity to indicate the level.

  4. To revert all unapplied changes back to the saved settings, click Revert.
  5. When you are done configuring operation settings, click Apply to save your changes to the runtime.

8.2.8 Configuring Message Tracing for a Service

After you enable message tracing for a proxy service, the system logs messages exchanged between the pipeline and the proxy service, including inbound request and response as well as outbound request and response messages. After you enable message tracing for a business service, the system logs messages exchanged between the pipeline and the business service (outbound request and response messages).

When applicable, logged outbound messages can also include the retry number, error code, and error message. In order for the tracing information to be logged to the server log file or server console, you must also configure the severity level for Oracle WebLogic Server logging.

To set Oracle WebLogic Server log levels:

To see tracing in the log file or standard out (server console), Oracle WebLogic Server logging must be set to the following severity levels:

  • Minimum severity to log: Info

  • Log file: Info

  • Standard out: Info

For information on setting log severity levels, see "Using Log Severity Levels" in Configuring Log Files and Filtering Log Messages for Oracle WebLogic Server.

To enable message tracing for a service:

  1. Perform a search for services, as described in Searching for Services to Configure Their Operational Settings.
  2. In the Operations table, click the service you want to configure.

    The Properties page for that service appears.

  3. Next to Message Tracing, select Enabled.
  4. From the Tracing Detail Level list, select the level of detail from among the following:
    • Terse: Display the date, time, service type, service name, and URI.

    • Headers: Display terse information along with the XML representation of the message metadata.

    • Full: Display the headers information along with the raw payload, including attachments if any.

  5. If you selected Full from the Detail Level list, do the following:
    • In the Payload Tracing Unit field, specify the maximum size (in kilobytes) for the message payload.

    • In the Default Encoding field, specify the default encoding for logging the payload.

      This can be useful when logging binary payloads or SOAP messages with binary attachments.The default encoding value can be Base64 or any Java-supported encoding.

      Note:

      If you leave the Default Encoding field empty, Service Bus uses the host's default encoding for the payload. The default encoding depends on a combination of the JVM, the underlying operating system (OS), and OS-level locale settings.

      If the setting specified in the Default Encoding field cannot be used (for example, it is not a valid option for the configuration), Service Bus uses Base64 encoding for the payload.

    • Click Apply.

8.2.9 Configuring the SLA Alert Level for a Service

You can configure the alert level for SLA alerts for a service. For more information, see Service-Level Agreement Alerts and the online help provided with Service Bus.

To configure the SLA alerting level for a service:

  1. Perform a search for services, as described in Searching for Services to Configure Their Operational Settings.
  2. In the Operations table, click the service you want to configure.

    The Properties page for that service appears.

  3. In the SLA Severity field under SLA Alerting, select the level at which you want to start generating alerts.
  4. To revert all unapplied changes back to the saved settings, click Revert.
  5. When you are done configuring operation settings, click Apply to save your changes to the runtime.

8.2.10 Configuring the Pipeline Alert Level

You can configure the alert level for pipeline alerting for a service. For more information, see Pipeline Alerts and the online help provided with Service Bus.

To configure the pipeline alerting level for a service:

  1. Perform a search for services, as described in Searching for Services to Configure Their Operational Settings.
  2. In the Operations table, click the service you want to configure.

    The Properties page for that service appears.

  3. In the Pipeline Severity field under Pipeline Alerting, select the level at which you want to start generating alerts.
  4. To revert all unapplied changes back to the saved settings, click Revert.
  5. When you are done configuring operation settings, click Apply to save your changes to the runtime.

8.2.11 Configuring the Logging Level for a Service

You can configure the logging level for pipelines and split-joins. For more information, see Logging and the online help provided with Service Bus.

To configure the logging level for a service:

  1. Set the Oracle WebLogic Server log levels, as described in To set Oracle WebLogic Server log levels:
  2. Perform a search for services, as described in Searching for Services to Configure Their Operational Settings.
  3. In the Operations table, click the service you want to configure.

    The Properties page for that service appears.

  4. In the Logging Level field under Logging, select the level at which you want generate log entries.
  5. To revert all unapplied changes back to the saved settings, click Revert.
  6. When you are done configuring operation settings, click Apply to save your changes to the runtime.

8.2.12 Configuring Throttling for a Business Service

Business service throttling is described in Configuring Business Services for Message Throttling. For information and instructions on configuring throttling, see Configuring Throttling for a Single Business Service.

8.2.13 Configuring Offline Endpoint URI Handling for a Business Service

Managing offline endpoint URIs is described in Monitoring and Managing Endpoint URIs for Business Services. For information and instructions on configuring endpoint URI handling, see Configuring Service Bus to Take Unresponsive Endpoint URIs Offline.

8.3 Making Bulk Updates to Operational Settings

Service Bus lets you create configuration files that you can use to update certain environment values that are likely to change when you move a project from one domain to another, such as moving from a development to a testing environment.

This includes updating operational settings at both the global and service levels. For information about creating and executing configuration files, see Configuring Service Bus to Take Unresponsive Endpoint URIs Offline.

8.4 Preserving Operational Settings During Resource Imports

When you import Service Bus configuration JAR files in Oracle JDeveloper, the Oracle Service Bus Console, or Fusion Middleware Control, the domain-level settings can be overwritten if the configuration being imported also contains the global settings of the domain from which it is being imported.

Select the Preserve Operational Settings flag when importing the service to retain the global settings in the configuration being imported. This overwrites the global settings of the existing system. The same applies for the operational settings for individual services when the service is updated by an import process.

You can also preserve operational settings when importing Service Bus configurations using APIs. For more information, see the ALSBConfigurationMBean documentation in the Java API Reference for Oracle Service Bus. Modify the MBean as shown in the following example to preserve the settings during the import.

Example - Preserve Operational Settings During the Import of Oracle Service Bus Configurations Through APIs

/**
 // Imports a configuration jar file, applies customization, activates it and
 exports the resources again
 // @throws Exception
 /
static private void simpleImportExport(String importFileName, String passphrase)
 throws Exception {
SessionManagementMBean sm = ... // obtain the mbean to create a session;
// obtain the raw bytes that make up the configuration jar file
 File importFile = new File(importFileName);
 byte[] bytes = readBytes(importFile);
// create a session
 String sessionName = "session." + System.currentTimeMillis();
 sm.createSession(sessionName);
// obtain the ALSBConfigurationMBean that operates on the
 // session that has just been created
 ALSBConfigurationMBean alsbSession = getConfigMBean(sessionName);
// import configuration into the session. First we upload the
 // jar file, which will stage it temporarily.
 alsbSession.uploadJarFile(bytes);
// then get the default import plan and modify the plan if required
 ALSBJarInfo jarInfo = getImportJarInf();
 ALSBImportPlan importPlan = jarInfo.getDefaultImportPlan();
// preserve operational values
 importPlan. setPreserveExistingOperationalValues(true);
// Modify the plan if required and pass it to importUploaeded method
 ImportResult result = alsbSession.importUploaded(importPlan);
// Pass null to importUploaded method to mean the default import plan.
 //ImportResult result = alsbSession.importUploaded(null);
// print out status
 if (result.getImported().size() > 0) {
     System.out.println("The following resources have been successfully
                         imported.");
     for (Ref ref : result.getImported()) {
         System.out.println("\t" + ref);
     }
 }
if (result.getFailed().size() > 0) {
     System.out.println("The following resources have failed to be imported.");
     for (Map.Entry e : result.getFailed().entrySet()) {
         Ref ref = e.getKey();
         // Diagnostics object contains validation errors
         // that caused the failure to import this resource
         Diagnostics d = e.getValue();
         System.out.println("\t" + ref + ". reason: " + d);
     }
// discard the changes to the session and exit
     System.out.println("Discarding the session.");
     sm.discardSession(sessionName);
     System.exit(1);
}
// peform the customization to assign/replace environment values and
 // to modify the references.
...
// activate the session
 sm.activateSession(sessionName, "description");
// export information from the core data
 ALSBConfigurationMBean alsbcore = getConfigMBean(null);
 //export the information at project level, pass only a collection of project
   refs to this method
 byte[] contentsProj = 
   alsbcore.exportProjects(Collections.singleton(Ref.DEFAULT_PROJECT_REF),null);
// the byte contents can be saved as jar file
}