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 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 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 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: 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 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.