Abstract: An approach is provided that detects inbound messages being put to message queues managed by a middleware message queuing platform. The approach retrieves activity trace data corresponding to each of the inbound messages, with the activity trace data maintained by the middleware message queuing platform. The approach generates inbound event records corresponding the inbound messages based on the activity trace data. The approach then detects outbound messages retrieved from the message queues. Activity trace data corresponding to the outbound messages is retrieved and the approach generates an outbound event record for each outbound message. The approach receives a transaction request from a requestor that corresponds to a message. The approach retrieves and returns the inbound event records and outbound event records that correspond to the requested message. The retrieved event records are used for transaction tracking: to build transaction flow topologies and to report transaction performance metrics.

Abstract: An approach is provided that detects inbound messages being put to message queues managed by a middleware message queuing platform. The approach retrieves activity trace data corresponding to each of the inbound messages, with the activity trace data maintained by the middleware message queuing platform. The approach generates inbound event records corresponding the inbound messages based on the activity trace data. The approach then detects outbound messages retrieved from the message queues. Activity trace data corresponding to the outbound messages is retrieved and the approach generates an outbound event record for each outbound message. The approach receives a transaction request from a requestor that corresponds to a message. The approach retrieves and returns the inbound event records and outbound event records that correspond to the requested message. The retrieved event records are used for transaction tracking: to build transaction flow topologies and to report transaction performance metrics.

Abstract: At each intermediate transaction hop from among multiple transaction hops in a transaction flow through a composite application, an entry with tracking data for a current transaction hop of the multiple transaction hops is inserted into a tracking envelope associated with the transaction flow and the tracking envelope is passed to a next transaction hop of the transaction hops in the transaction flow. At a final transaction hop of the multiple transaction hops, a final entry with tracking data for the final transaction hop is inserted into the tracking envelope and the multiple entries with tracking data for each of the transaction hops in the tracking envelope are exposed in a single tracking event.

Abstract: An approach is provided to correlate transaction data occurring at two different domains running on a common operating system image without using static, or common, correlators. Request-type event records are collected at a first domain within the operating system image, with each of the request-type event records including execution identifiers and a unique token that indicates the order in which the corresponding request-type event occurred on the first domain. Similarly, response-type event records are collected at a second domain within the operating system image. The request-type event records are matched with the response-type event records based on the execution identifiers and an overall order that is indicated by unique tokens included in the records. The matching of request-type event records with response-type event records indicate a number of inter-domain transactions which are recorded in a correlation data store.

Abstract: An API bridge service retrieves a generic API message request, placed in a request queue of a message queuing network by a message queuing application, from the request queue. The API bridge service formats the generic API request into a particular API call for at least one specific API. The API bridge service calls at least one specific API with the particular API call. Responsive to the API bridge service receiving at least one API specific response from at least one specific API, the API bridge service translates at least one API specific response into a response message comprising a generic API response. The API bridge service, places the response message in a response queue of the message queuing network, wherein the message queuing application listens to the response queue for the response message.

Abstract: An LDAP bridge service retrieves a generic LDAP message request, placed in a request queue by a message queuing application, from the request queue. The LDAP bridge service formats the generic LDAP request into a particular API call for at least one LDAP API. The LDAP bridge service calls at least one LDAP API with the particular API call for requesting at least one LDAP service from at least one LDAP server managing a distributed directory. Responsive to the LDAP bridge service receiving at least one LDAP specific response from at least one LDAP API, the LDAP bridge service translates the LDAP specific response into a response message comprising a generic LDAP response. The API bridge service, places the response message in a response queue of the message queuing network, wherein the message queuing application listens to the response queue for the response message.