Skip navigation

MainView Middleware Mgmt

4 Posts authored by: Eric Olson
Share This:

The Problem

In service oriented architectures, just as with any composite application environment, the biggest problem associated with management isolating a problem to a specific service.  Is a service slow because of internal problems or because it has called another service and is waiting on a response?  Is the fault seen by an end user caused by the Enterprise Service Bus or is it within one of the actual back end services?  Solving such problems is the function of BMC Application Transaction Tracing (BATT).  BATT handles formal services very well since it gathers the needed information by intercepting the data of the service requests and responses directly at the protocol level.  BATT supports virtually all common HTTP and JMS providers including Microsoft, IBM, Oracle, TIBCO, JBoss, and Apache among others.  This allows BATT to monitor solely based on the service interfaces without a dependency on the internal runtimes.

One of the challenges of implementing BATT, however, is that it requires a “Transaction Id” to uniquely identify each service call and relate those calls together as part of a larger business transaction.  While BATT can get this transaction id from anywhere in the SOAP Header, SOAP Body, or the transport metadata (HTTP Headers, JMS Properties, …), there must be such a field.  It is often difficult to get multiple services to agree on this.

The Solution

This same issue applies across all Service Monitoring solutions and having such a transaction id can be greatly useful to the services themselves so the global community has defined a standard location for this in the WS-Addressing standard.  At the simplest level, WS-Addressing provides a MessageID field in the SOAP Header to hold this unique identifier.  Where you are handling more complex transactions (e.g. one request generates multiple responses or is fanned out to multiple providers), WS-Addressing also provides a RelatesTo field to hold the MessageID of related messages. (For people used to MQ or JMS work, this is much like the Correlation Id field in those transport headers).  BATT V7 provides full out-of-the-box support for the WS-Addressing standard so, in the attached doc, I’ll first take a bit of time to discuss the standard itself and then finish up with showing you how to use the WS-Addressing Fields in BATT.

Share This:

Service Models Using Data from BMC Application Transaction Tracing

The Problem

Applications are typically and increasingly composites that run across multiple systems and use multiple technologies.  When a problem occurs, it may be visible to the end user, but it is often extremely difficult to find the root cause.  Similarly, parts of the application are increasingly shared services that may be reused as part of multiple applications.  This makes it difficult to understand the impact of outages or changes.

In order to address these problems, organizations work steadily to define service models that store and show the relationship between components.  We have moved a long way toward standardizing the infrastructure components that applications depend on and the possible relationships between them using Configuration Management Databases (CMDBs).  However, to complete the picture, it is just as important to standardize the way that we think about application components and their relationships and to connect these objects to the infrastructure object that they depend on.

The Solution

The attached Microsoft Word Doc describes in detail how to build an effective BPPM Service Model of a composite application using the data monitored by BMC Application Transaction Tracing and BMC Middleware Monitoring.

Share This:

The Problem

IBM WebSphere Message Broker provides considerable flexibility for controlling resource usage of Message Flows through the Additional Instances.  The appropriate setting depends on the internal performance of the message flow as well as the load on it.  This can make it difficult for the Message Broker administrator to find the optimal value for each message flow to maximize the performance of the broker.

The Solution

The BMC Middleware Monitoring Extension for WebSphere Message Broker provides the key metrics for making an objective decision on the best value.  See the attached MS Word document for details.

Share This:

The Problem

The largest challenge in monitoring MQ channels is that they do not reside in one place, but inherently cross between two systems.  While BMC Middleware Monitoring provides out of the box Physical Views for monitoring each side of the channel, it is much more effective to monitor the channel as a whole.  For example, when you see a Sender Message Channel Agent (MCA) in a retrying state, this is an issue that needs to be dealt with.  The action that you need to take, however, is different depending on what is happening to the Receiver MCA.  If that is Inactive, then the problem is almost certainly a network issue between the two systems.  On the other hand, if the Receiver channel is Stopped, that channel is Disabled and you need to restart the Receiver MCA.  Similarly, the channel might be retrying because the Sequence numbers are mismatched or a unit of work is unresolved.  To know which of these is the case, it is important to look at the two ends of the channel simultaneously.

 

Download the attached zip file and open the enclosed Microsoft Word file for the way I approach this problem.  Also contained in the zip are the files you need to import my solution into your BMC Middleware Monitoring environment.

Filter Blog

By date:
By tag: