15 RSB in Operation

This section contains common issues that need to be thought about and addressed by a retailer as they progress towards a production environment involving RSB. It is not a comprehensive list, nor does it seek to answer the questions, since they are very dependent on the retailer implementation. The intent of this section is to provide a starting point for a site-specific RSB operations planning effort.

Operational Considerations

RSB has built-in alerts and notification through JMX. An external system can subscribe to all of the built-ins. The JMX alerts are raised by the underlying OSB. Any JMX client adhering to JMX standard should be able to subscribe to the JMX alerts.

Log File Archive and Purge

RSB uses log4j for all of its logging control. It manages the logs size through its control file. In various phases of deployment and in triaging a problem it is often desirable or necessary to archive the logs so the logs are smaller and scanning by tools or people is easier.

The number of log files retained and size of the log files are fixed during RSB deployment. However, these configurations can be changed through the WebLogic Admin Console.

Message Flow in a Decorator Proxy Service

A message flow is associated with a proxy service. It shows various nodes in the flow of control from the proxy to business and back. Message flow provides a means to tap into the flow of control and perform any custom processing like transformation, routing etc. The flow can be modified using XSLT or XQuery as the primary programming language. The decorator already has a flow configured with calls to RSB instrumentation code. Do not modify this code, since there are a lot of RSB features dependent on the instrumentation.

Note:

For more information, see the Oracle Retail Service Backbone Developers Guide.

Error Handling in Decorator Services

In RSB the decorator proxy services comes with a default OSB error handler at the service level. This error handler replaces the soap body with the error reason from the edge app service and the operation name. Then the error handler calls the instrumentation code and returns a failure to the service consumer. OSB allows users to configure error handling at the message flow, pipeline, route node, and stage level.

Service and Business Alerts

Oracle Service Bus evaluates rules against its aggregated metrics each time it updates that data. When a rule evaluates to True, it raises an alert.

All the SLA alerts are shown in RIC as System Alerts and all pipeline alerts are shown as Business Alerts. You can also view the alerts through OSB console. RIC is retrieving the alerts from OSB using JMX. If the alerts are purged in OSB, they will also disappear in RIC.

Users or applications can subscribe to the alerts using JMX clients or by configuring e-mail server in OSB. See RSB Developers Guide for instructions to configure OSB server for subscription of alerts through e-mail.

RSB comes with a default SLA alert configured. Users can change the rule or add new rule depending on the business requirements.

Adding New Alerts

Both Business (pipeline) and Service (SLA) alerts can be added either through OSB console or programmatically. If the alert is added through OSB console, the alert configuration will get overwritten when the OSB project is redeployed. So it is recommended to add only temporary alerts through OSB console. Any alerts that are permanently needed must be added programmatically. SLA alerts are added at the proxy or business services. Pipeline alerts are added to the message flow. Take the following steps to add an SLA alert to a business service:

Click on the Business Services link in Resource Browser of OSB console.
Click the service for which you want to add the alert.
Select the SLA Alert Rules tab. Click Add.
Enter Rule Name and Alert Destination corresponding to the decorator.
Construct the Alert Rule Condition as shown in the following screen:
Save the alert and activate the session.
Click Update and then Create.
Activate the session.

Note:

See also Oracle Service Backbone Developers Guide.

Performance Monitoring

The decorator services are designed for minimal impact on the service invocation. However, there can be many reasons for a slow-performing system. RSB provides helpful information to identify potential reasons for performance drop. RIC is very useful in narrowing down the components that may be causing the performance issues. RIC provides different ways to monitor the performance of service invocation.

In the RSB Integration Summary tab of RIC, you can view the CPU and Memory usage of RSB servers. So, if the RSB server is the bottleneck in the performance flow, it would be indicated by a high CPU usage and/or memory usage.

In the RSB Integration Summary tab, the applications are shown in the graph against the average response time. This graph helps in identifying applications that are slow. This potentially indicates slow application servers or network performance issue to slow performing application servers.

Performance tab under Performance and Diagnostics, you can query for slow performing services or high volume service. If the performance issue is at a service level, it can be identified here.

System Logs screen is another place to look for any log entry that would point towards the causes of performance degradation. RIC provides a consolidated view of logs from all the domain servers. Users can also filter to log entries by severity, timestamp, server and so on.

OSB Console

OSB console is the operational console for Oracle Service Bus. OSB console helps to perform many operational tasks of the OSB hosted applications.

Manage Transport, SOAP binding and Message handling configurations
Manage Monitoring, Throttling and Tracing configurations
Manage SLA alert rules
Manage Security Policies
Export WSDLs
Export Projects

Note:

Service Activity Table Growth and Purge

The service activity table stores the data collected by instrumentation. The services for which trace is enabled are intercepted and meta data is persisted in this table. If audit is enabled, the payload is also saved to the database. There will be one row per each service invocation.

RSB system will not remove any records from this table. The table will grow with each call of the instrumented service.

Each implementation should design their own purge strategy for the service activity table. This may depend on various factors like

How many days of historical data have to be maintained.
The average volume of transactions per day.
How many services are audit enabled.

If the table is not purged, the data will grow indefinitely.

Support Staff Requirements

RSB requires OSB as the infrastructure component. This is one of the main differences between RSB and other Oracle Retail applications. Thus, familiarity of OSB is an additional skill requirement for support staff of RSB.