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: A computer implemented method, system and/or computer program product is provided for managing a messaging queue in an asynchronous messaging system. A duration for which a message can remain on the messaging queue is determined. An age of the message on the messaging queue is monitored. The age of the message on the messaging queue and the determined duration is compared and a notification is generated based on the comparison.

Abstract: In a method for generating test transactions across computing systems, a first test function of a first program on a first computing system of a plurality of computing systems receives a plurality of instructions, wherein a first instruction of the plurality of instructions is to invoke a first transaction between a second function of the first program and a second program on a second computing system of the plurality of computing systems. The first test function of the first program causes the transaction between the second function of the first program on the first computing system and the second program on the second computing system. The first test function of the first program sends the plurality of instructions to a second test function on a third computing system of the plurality of computing systems, based on a second instruction of the plurality of instructions.

Abstract: In a method for generating test transactions across computing systems, a first test function of a first program on a first computing system of a plurality of computing systems receives a plurality of instructions, wherein a first instruction of the plurality of instructions is to invoke a first transaction between a second function of the first program and a second program on a second computing system of the plurality of computing systems. The first test function of the first program causes the transaction between the second function of the first program on the first computing system and the second program on the second computing system. The first test function of the first program sends the plurality of instructions to a second test function on a third computing system of the plurality of computing systems, based on a second instruction of the plurality of instructions.

Abstract: Responsive to middleware for a domain processing a transaction instance at a processing point specified in transaction telemetry standards as a tracking point along a flow of the transaction instance from a requesting domain to a requestee domain, a facility of the middleware determines whether a token with correlation data comprising a unique identifier for the transaction instance available to both the requesting domain and the requestee domain is passed to the domain in compliance with transaction telemetry standards. Responsive to the facility of the middleware not detecting the token with correlation data, the token with generated correlation data accessible to the domain is generated. The facility of the middleware passes the token to at least one subsequent middleware instance of the plurality of middleware instances of the composite application along the flow of the transaction instance to uniquely identify the transaction instance.

Abstract: Responsive to middleware for a domain processing a transaction instance at a processing point specified in transaction telemetry standards as a tracking point along a flow of the transaction instance from a requesting domain to a requestee domain, a facility of the middleware determines whether a token with correlation data comprising a unique identifier for the transaction instance available to both the requesting domain and the requestee domain is passed to the domain in compliance with transaction telemetry standards. Responsive to the facility of the middleware not detecting the token with correlation data, the token with generated correlation data accessible to the domain is generated. The facility of the middleware passes the token to at least one subsequent middleware instance of the plurality of middleware instances of the composite application along the flow of the transaction instance to uniquely identify the transaction instance.

Abstract: In a method for generating test transactions across computing systems, a first test function of a first program on a first computing system of a plurality of computing systems receives a plurality of instructions, wherein a first instruction of the plurality of instructions is to invoke a first transaction between a second function of the first program and a second program on a second computing system of the plurality of computing systems. The first test function of the first program causes the transaction between the second function of the first program on the first computing system and the second program on the second computing system. The first test function of the first program sends the plurality of instructions to a second test function on a third computing system of the plurality of computing systems, based on a second instruction of the plurality of instructions.

Abstract: In a method for generating test transactions across computing systems, a first test function of a first program on a first computing system of a plurality of computing systems receives a plurality of instructions, wherein a first instruction of the plurality of instructions is to invoke a first transaction between a second function of the first program and a second program on a second computing system of the plurality of computing systems. The first test function of the first program causes the transaction between the second function of the first program on the first computing system and the second program on the second computing system. The first test function of the first program sends the plurality of instructions to a second test function on a third computing system of the plurality of computing systems, based on a second instruction of the plurality of instructions.

Abstract: Responsive to transactional middleware for a particular domain processing a particular transaction instance at a processing point specified in transaction telemetry standards as a tracking point along a flow of the particular transaction, a facility of the middleware accesses correlation data for the particular transaction instance in the particular domain and extracts application level context information about the particular transaction instance from the particular domain, wherein the transaction telemetry standards specify a same set of standards for application by each separate transactional middleware instance of a composite application. At least one facility of the transactional middleware creates a tracking event comprising the correlation data and the application level context information formatted into an event structure defined by the transaction tracking standards.

Abstract: A computer implemented method, system and/or computer program product is provided for managing a messaging queue in an asynchronous messaging system. A duration for which a message can remain on the messaging queue is determined. An age of the message on the messaging queue is monitored. The age of the message on the messaging queue and the determined duration is compared and a notification is generated based on the comparison.

Abstract: Responsive to transactional middleware for a particular domain processing a particular transaction instance at a processing point specified in transaction telemetry standards as a tracking point along a flow of the particular transaction, a facility of the middleware accesses correlation data for the particular transaction instance in the particular domain and extracts application level context information about the particular transaction instance from the particular domain, wherein the transaction telemetry standards specify a same set of standards for application by each separate transactional middleware instance of a composite application. At least one facility of the transactional middleware creates a tracking event comprising the correlation data and the application level context information formatted into an event structure defined by the transaction tracking standards.

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.

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: 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: Responsive to transactional middleware for a particular domain processing a particular transaction instance at a processing point specified in transaction telemetry standards as a tracking point along a flow of the particular transaction, a facility of the middleware accesses correlation data for the particular transaction instance in the particular domain and extracts application level context information about the particular transaction instance from the particular domain, wherein the transaction telemetry standards specify a same set of standards for application by each separate transactional middleware instance of a composite application. At least one facility of the transactional middleware creates a tracking event comprising the correlation data and the application level context information formatted into an event structure defined by the transaction tracking standards.

Abstract: Responsive to transactional middleware for a particular domain processing a particular transaction instance at a processing point specified in transaction telemetry standards as a tracking point along a flow of the particular transaction, a facility of the middleware accesses correlation data for the particular transaction instance in the particular domain and extracts application level context information about the particular transaction instance from the particular domain, wherein the transaction telemetry standards specify a same set of standards for application by each separate transactional middleware instance of a composite application. At least one facility of the transactional middleware creates a tracking event comprising the correlation data and the application level context information formatted into an event structure defined by the transaction tracking standards.

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.