End-to-end transaction tracking in the enterprise
Various embodiments of a method, system and article of manufacture track the processing of a transaction. A managing server receives an originator communication event record from a first collector associated with a first application environment having a first unit of execution. The first communication event record is associated with a first unit of execution identifier and a first token. The managing server receives a second communication event record from a second collector associated with a second application environment having a second unit of execution. The second communication event record is associated with a second unit of execution identifier and a second token. The managing server determines whether the first unit of execution and the second unit of execution are associated with processing a same transaction based on the first token and the second token.
Latest Patents:
- TOSS GAME PROJECTILES
- BICISTRONIC CHIMERIC ANTIGEN RECEPTORS DESIGNED TO REDUCE RETROVIRAL RECOMBINATION AND USES THEREOF
- CONTROL CHANNEL SIGNALING FOR INDICATING THE SCHEDULING MODE
- TERMINAL, RADIO COMMUNICATION METHOD, AND BASE STATION
- METHOD AND APPARATUS FOR TRANSMITTING SCHEDULING INTERVAL INFORMATION, AND READABLE STORAGE MEDIUM
1.0 Field of the Invention
This invention relates to tracking transactions; and in particular, to tracking individual transactions as they are processed across various application environments.
2.0 Description of the Related Art
With the advent of the Internet and Web computing, enterprises have had to expand their information technology (IT) to a more distributed environment, while keeping most of their business logic in a traditional mainframe environment using legacy software systems. Exemplary legacy software systems comprise IBM® (Registered trademark of International Business Machines Corporation) Customer Information Control System (CICS® (Registered trademark of International Business Machines Corporation)), IBM Information Management System (IMS™ (Trademark of International Business Machines Corporation)), and DB2® (Registered trademark of International Business Machines Corporation). The distributed environment has increased the need for software systems such as Web servers and application servers, for example, Java® 2 Platform Enterprise Edition (J2EE® (Java and all Java-based trademarks are trademarks of Sun Microsystems, Inc. in the United States, other countries, or both)) servers, to satisfy on-line access through the World Wide Web. However, transactions are still processed through the legacy software systems, using synchronous gateways or asynchronous messaging systems such as IBM WebSphere® (Registered trademark of International Business Machines Corporation) MQSeries® (Registered trademark of International Business Machines Corporation). A legacy software system is a non-J2EE software system. As a result, the processing of a business transaction is rarely confined to one application server or system. The processing of the business transaction typically flows from a Web server to an application server all the way to the legacy software system and back. In addition, the advent of the Internet has greatly increased the volume of such transactions twenty-four hours a day, seven days a week. IT organizations need to provide an acceptable end-to-end response time for processing transactions. Therefore, there is a need for IT organizations to track the processing of transactions should problems such as bottlenecks, deadlocks and hangs occur.
Traditional solutions have typically consisted of separately monitoring a software system either from the resource point-of-view or from the application point-of-view to provide information regarding the behavior of transactions while the transactions are being processed by that software system. Monitoring from the resource point-of-view comprises monitoring the memory utilization, central processing unit (CPU) time, and connection pools of the software system. Monitoring from the application point-of-view comprises monitoring transaction performance metrics, such as response time, or tracing the execution of a single instance.
Some conventional monitors only have a view of the specific software system that they are monitoring and are not able to correlate the processing across various software systems. A servlet is a Java program for providing additional features to a Web server and can be used to access existing business systems. One conventional J2EE monitor is able to identify the servlets which have requested external services from CICS. Another conventional CICS monitor is able to detect activities in CICS. However, neither the J2EE monitor nor the CICS monitor is able to associate any servlet with any CICS tasks that the servlet has invoked or sent messages to. When a problem occurs, it becomes difficult, if not impossible, to identify the problem or know what action to take in order correct the problem. Therefore there is a need for an improved technique which allows the processing of transactions to be tracked across various software systems.
SUMMARY OF THE INVENTIONTo overcome the limitations in the prior art described above, and to overcome other limitations that will become apparent upon reading and understanding the present specification, various embodiments of a method, system and article of manufacture which track the processing of a transaction are provided. A managing server receives an originator communication event record from a first collector associated with a first application environment having a first unit of execution. The first communication event record comprises a first unit of execution identifier and a first token. The managing server receives a second communication event record from a second collector associated with a second application environment having a second unit of execution. The second communication event record comprises a second unit of execution identifier and a second token. The managing server determines whether the first unit of execution and the second unit of execution are associated with processing a transaction based on the first token and the second token. In some embodiments, the managing server determines that the first unit of execution and the second unit of execution are associated with the processing of the same transaction in response to the first token matching the second token.
In this way, the processing of transactions can be tracked across various units of execution in different application environments, and therefore, the processing of transactions can be tracked across various software systems.
BRIEF DESCRIPTION OF THE DRAWINGSThe teachings of the present invention can be readily understood by considering the following description in conjunction with the accompanying drawings, in which:
To facilitate understanding, identical reference numerals have been used, where possible, to designate identical elements that are common to some of the figures.
DETAILED DESCRIPTIONAfter considering the following description, those skilled in the art will clearly realize that the teachings of the various embodiments of the present invention can be utilized to track the processing of a transaction. A managing server receives an originator communication event record from a first collector associated with a first application environment having a first unit of execution. The first communication event record comprises a first unit of execution identifier and a first token. The managing server receives a second communication event record from a second collector associated with a second application environment having a second unit of execution. The second communication event record comprises a second unit of execution identifier and a second token. The managing server determines whether the first unit of execution and the second unit of execution are associated with processing the same transaction based on the first token and the second token. In some embodiments, the managing server determines that the first unit of execution and the second unit of execution are associated with the processing of the same transaction when the first token matches the second token.
Examples of a single region application environment 38 and 39 include, and are not limited to, a CICS region and a distributed J2EE application server. A CICS region is an area of memory of the computer system in which CICS system programs have been loaded (and executed), with other memory allocated for the CICS region to use. The CICS region comprises a named collection of resources controlled by CICS as a unit. The resources in a CICS region comprise programs, Basic Mapping Support map sets, transactions, terminals, files, transient data queues, temporary storage queues and journals. In the distributed J2EE application server environment, also known as the application server instance, the application environment comprises one address space (or process or Java Virtual Machine (JVM)).
In another example, in some embodiments, an application environment comprises a plurality of regions. Examples of multi-region application environments include, and are not limited to, an IBM WebSphere Application Server (WAS/z) and IMS. In the WAS/z case, one application server instance has one control region and one or more JVMs, each JVM occupying one servant region. In another example, one IMS application environment has one control region and one or more dependent regions, where the IMS applications are executed. In the WAS/z case a single collector is associated with the servant regions of the application environment; and, the control region is not associated with a collector. On the other hand, in the IMS case a single collector is associated with the control region; and, the dependent regions report to that collector via MVS® (Registered Trademark of International Business Machines Corporation) operating system cross memory-services.
A region 38, 39, 40 and 41 comprises at least one unit of execution (UOE) 42-44, 46-48, 50-52, and 54-56, respectively. In general, a unit of execution is a group of instructions which are executed as a unit, and have a beginning and an end. A UOE has a host mechanism for execution and a unique existence in time, for example, an instance. In various embodiments, the host mechanism for execution is a process, a thread, an operating system task control block (TCB) (MVS operating system, z/OS® (Registered Trademark of International Business Machines Corporation) operating system), a task control area (TCA) (CICS) or task (MVS operating system, z/OS operating system, CICS, IMS).
In various embodiments, a transaction is a set of input data and output data with a beginning and an end point in time, originated by a request and terminated when a response is returned to that request. The request can be a message or an invocation, depending on the embodiment. A transaction is executed in one or more application environments. A transaction which is executed in a single application environment is referred to as a local transaction (“local” to that particular application environment). A transaction that is executed in multiple application environments is referred to as a composite transaction. Therefore a composite transaction is composed of a plurality of local transactions. A composite transaction may also be referred to as a business transaction.
In general, a UOE executes in an application environment, and hosts a local transaction in that application environment. In various embodiments, the local transaction is executed as a sequence of one or more programs (CICS), methods (Java), functions (C/C++), or subroutines (COBOL, PL/I) in the application environment. In some embodiments, a UOE hosts one local transaction. In other embodiments, a UOE hosts more than one local transaction, for example, a server (as in the client-server architecture). In various embodiments, a server UOE is a long executing task which “serves” multiple external requests, each request resulting in a single local transaction; in these embodiments, an external request is from a different application environment from the application environment in which the server UOE is executing. An internal request is originated from the same application environment as the server UOE. The server UOE exists, that is, is executing, before the initiation of each local transaction that the server UOE hosts and exists after the completion of each local transaction that the server UOE hosts. If a UOE does not exist prior to and after completion of the local transaction, then the UOE hosts a single transaction.
In various embodiments, a UOE comprises a set of one or more programs, subroutines, functions or methods, which host one or more transactions. In some embodiments, the host mechanism for execution of a UOE is a thread. A thread is either in an active state or a “dormant” state and is identified by a thread identifier (id). A thread remains “dormant” in a thread pool in a process until the thread is associated with a UOE, in which case the thread becomes an active thread hosting a UOE. When the UOE terminates, the thread is no longer active and is returned to the thread pool and remains in the thread pool under the same thread id, until the thread is associated with another UOE. The UOE hosts transactions, whereas the thread is the software mechanism under which programs are executed. Hence, an executing thread “hosts” a UOE (or is referred to as being associated with a UOE). In other embodiments, the host mechanism for execution is a TCB, TCA or task, rather than a thread. However, the host mechanism for execution is not meant to be limited to a thread, TCB, TCA or task; and the invention will work with other embodiments of a host mechanism for execution.
Therefore, an application environment comprises one or more regions. In various embodiments, a region is a host to one or more threads or tasks or TCBs or TCAs, which typically remain in a pool ready to be associated with a UOE. A UOE executes in a region as an active thread, task, TCB, or TCA, depending on the embodiment. In order to execute, a UOE is associated with an active thread, task, TCB, or TCA, depending on the embodiment, which is said to host the UOE. In various embodiments, a UOE hosts one or more transactions. During its lifetime, the UOE can host one transaction, or the UOE can host more than one transaction.
In some embodiments, during execution, a UOE can originate or instantiate zero or more transactions. The transactions may be local or composite transactions. In various embodiments, a unit of execution may cause one or more other units of execution in other application environments to be executed.
In the MVS and z/OS operating systems, a TCB represents an operating system task, and there is at least one TCB per address space (the main TCB).
A CICS region is an address space, that is, an application environment, with several TCB's. One specific TCB will execute the client requests which will take turns using that TCB in a round robin fashion. Each of these client requests, which are also referred to as CICS transactions, is identified by a CICS task number (not an operating system task), for which the information is to be found in the task control area (TCA). A CICS task is also referred to as a TCA, the same way as an MVS or z/OS operating system task is also referred to as a TCB. In various embodiments, a CICS transaction is identified by its task number, that is, its TCA number.
An IMS transaction is typically a local transaction which comprises a group of TCBs in different address spaces in a single IMS region.
In some embodiments, a Unix process is a UOE of an application environment which contains multiple UOEs; or alternately, a Unix process can be a single UOE of an application environment. In various embodiments, multiple transactions can be performed by the same thread, and each performance of the transaction by that thread is a separate unit of execution.
An application environment 32, 34 and 36 is typically monitored by an associated collector 62, 64 and 66, respectively. The collector 62, 64 and 66 gathers data about the units of execution 42 and 44, 46 and 48, 50 and 52, 54 and 56 of its associated application environment 32, 34, 36 and 38, respectively, and publishes data comprising communication event records as indicated by arrows 67, 68 and 69, to the managing server 20. The information gathered by the collector 62, 64 and 66 is used to provide a trace of the processing of a transaction within an application environment. Whenever a unit of execution inside a monitored application environment requests an external service from another unit of execution in a different application environment, the processing is said to leave the application environment.
In various embodiments, the processing of individual transactions is tracked across units of execution in different application environments 32, 34 and 36 using tokens. In some embodiments, a “composite” trace of the processing associated with a transaction is provided across the various application environments. For example, in various embodiments, using a graphical user interface, a user can view a method trace of a servlet within a J2EE container, see that the servlet made a request to a CICS region, switch to view a trace of the processing associated with that request in the CICS region where a CICS transaction or task is executed on its behalf, and follow a program trace of the CICS transaction. At this point the CICS transaction could send an MQ Series message to IMS through an MQ-IMS bridge, which invokes an IMS transaction which can be tracked in the same context as the servlet and the CICS transaction. In various embodiments, using the tokens, an end-to-end view of the processing of transactions across various application environments is provided with the ability to drill down to view the processing inside the various monitored application environments. Therefore, the processing related to a transaction can be viewed in the same context across different application environments in a computing network.
In some embodiments, the collector 62, 64 and 66, is implemented in an application management system (AMS) 72, 74 and 76, respectively, for example, WebSphere Studio Application Monitor (WSAM) or Tivoli® (Registered trademark of International Business Machines Corporation) Monitoring for Transaction Performance (TMTP). However, the application management system is not meant to be limited to WSAM or Tivoli TMTP, and other application management systems may be used.
In various embodiments, a UOE has a UOE identifier. In some embodiments, the UOE identifier is unique within an application environment. A thread is associated with a thread identifier; a TCA is associated with a TCA number; and a TCB is associated with a TCB number. In various embodiments, the UOE identifier is a thread identifier, a TCA number or a TCB number.
Referring back to
In various embodiments, to track composite transactions, a token is generated and exchanged between the originating UOE and the receiving UOE. Depending on the nature of the interaction, tokens are either generated by the collector using fields which are managed by that collector or generated using information from fields which are not managed by the collector. In some embodiments, the term “native token” refers to a token which is generated by the collector using fields which are managed by that collector. In other embodiments, the term “guest token” refers to a token which is generated by the collector using information from fields which are not managed by that collector, for example, using information from the communications interface structure which is managed by other applications. In some embodiments, if there is no available field in the communication interface structure which can be used to host a native token, a guest token is derived from fields in the communications interface structure the combination of which is “reasonably” unique. In other words, the guest token is sufficiently unique so that the associated UOEs and application environments can be correctly correlated. In some embodiments, the guest token allows the associated UOEs and application environments to be correctly correlated in excess of a desired probability.
For example, in various embodiments, non-message queue based communication uses native tokens 102 for both synchronous and asynchronous communication.
In various embodiments, the message identifier 112 is a byte string that is used to distinguish one message from another message. Typically, each message has a different message identifier 112. In some embodiments, the message identifier 112 is generated by the queue manager of the messaging system; and in other embodiments, the message identifier 112 is generated by the application or system.
In some embodiments, a correlation identifier 114 is a byte string that an application can use to relate one message to another message, or to relate the message to other work that the application is performing. The correlation identifier 114 is either not generated and a value of (24ב00’) is used, or alternately, the correlation identifier 114 is generated by the queue manager, or in some embodiments, the application.
The messaging system sends the message identifier 112 and correlation identifier 114 with the message. Therefore, in this embodiment, the collector does not modify any information in the message header. After executing instructions to place a message in the message queue such as MQPUT or MQPUT1, or instructions to retrieve a message such as MQGET, a message queue message descriptor, for example, an MQSeries message descriptor (MQMD), is available with the PUT-message options (MQPMO) or the GET-message options (MQGMO). In various embodiments, the message identifier 112 and correlation identifier 114 are available in the PUT-message options or the GET-message options which are associated with a message.
The following pseudo-code illustrates the generation of the guest tokens described in
For example, when a J2EE application is initiating an IMS transaction through IMS Connect (via IMS Connect for Java (IC4J)), a native token is used. If this J2EE application was to use MQSeries through the MQ-IMS Bridge, a guest token is used. For a reply message, the guest token is derived from the CorrelId and MsgType fields in the MQSeries message descriptor and has a predetermined TOKEN LENGTH, which in some embodiments, is twenty-eight bytes. Otherwise, the guest token is derived from the MsgID and CorrelId fields in the MQSeries message descriptor and has a predetermined TOKEN LENGTH, which in some embodiments, is forty-eight bytes. However, the TOKEN LENGTH is not meant to be limited to twenty-eight or forty-eight bytes, and in other embodiments, other values for the TOKEN LENGTH may be used.
The collector communicates with the managing server according to a communication protocol comprising communication event records. The collector sends communication event records to the managing server. In various embodiments, a communication event record comprises an event type, a UOE identifier and a token, and in some embodiments, a timestamp. An originator communication event record is a communication event record which is sent by the originating UOE to the managing server. A receiver communication event record is a communication event record which is sent by the receiving UOE to the managing server. In various embodiments, the originator communication event record comprises an originator event type, an originating UOE identifier, a token, and, in some embodiments, a timestamp. Originator event types comprise GPS_INVOKE_START, GPS_PUT_START, GPS_INVOKE_END and GPS_PUT_END event records. A receiver communication event record comprises a receiver event type, a receiving UOE identifier, a token, and, in some embodiments, a timestamp. Receiver event types comprise GPS_RECEIVE_START, GPS_RECEIVE_END, GPS_GET_START and GPS_GET_END.
The event types may also be classified as start event types and end event types. Start event types comprise GPS_INVOKE_START, GPS_PUT_START, GPS_RECEIVE_START and GPS_GET_START. End event types comprise GPS_INVOKE_END, GPS_RECEIVE_END, GPS_PUT_END and GPS_GET_END.
In addition the event types may be classified as message-based and non-message based. The message-based event types indicate that a messaging system is used to send the communication. The message-based event types comprise GPS_PUT_START, GPS_PUT_END, GPS_GET_START and GPS_GET_END. The non-message-based event types indicate that a communication is not sent by a messaging system, for example, the communication may be sent through invocation (synchronous or asynchronous). The non-message-based event types comprise GPS_INVOKE_START, GPS_INVOKE_END, GPS_RECEIVE_START and GPS_RECEIVE_END.
In various embodiments, traps are configured to transfer control to the collector associated with an application environment in response to a unit of execution of that application environment attempting to communicate with another application environment, for example, by invocation or by sending a message. Traps are also configured to transfer control to the collector associated with an application environment in response to a unit of execution of that application environment receiving a communication from another application environment, for example, by returning from an invocation or by receiving a message. In some embodiments, traps are configured to transfer control to the collector associated with an application environment in response to returning from a call to a communication application programming interface (API). In addition, at initialization, in some embodiments, a trip counter in a collector is set to zero, or alternately, the trip counter in a collector is set equal to one. In various embodiments, the first, that is, initial, value of the token cannot be equal to zero.
In some embodiments, the collector associated with the application environment containing an originating UOE sends an originator communication event record comprising a GPS_INVOKE_START event type, the originating UOE identifier, a token and a timestamp, to the managing server in response to trapping a CICS or IMS request which is to be sent to a receiving UOE. The collector associated with the application environment containing the receiving UOE sends a receiver communication event record comprising an event type of GPS_RECEIVE_START, a receiving UOE identifier, the received token and a timestamp, to the managing server in response to trapping the receipt of the request from the originating UOE. The receiving UOE processes the request. The request comprises the token. In various embodiments, in response to trapping the suspension or stopping of the processing at the receiving UOE to return control to the originating UOE, the collector associated with the application environment containing the receiving UOE sends a receiver communication event record comprising an event type of GPS_RECEIVE_END, the receiving UOE identifier, the token that was received in the request and a timestamp, to the managing server. The receiving UOE returns control to the originating UOE by sending a communication to the originating UOE with the token that was received in the request. In response to trapping the receipt of the communication from the receiving UOE which indicates that the execution of the request by the receiving UOE was stopped or suspended, the collector associated with the application environment containing the originating UOE sends an originator communication event record comprising an event type of GPS_INVOKE_END, the originating UOE identifier, the token that was passed in the communication from the receiving UOE and a timestamp, to the managing server, and control is returned to the originating UOE.
In other embodiments, the collector associated with the application environment containing the originating UOE sends an originator communication event record comprising an event type of GPS_PUT_START, the originating UOE identifier, a token and timestamp, to the managing server in response to sending a message using a message queue of a messaging system by, for example, issuing a PUT request or PUT API. The collector associated with the application environment containing the receiving UOE sends a communication event record comprising an event type of GPS_GET_START, the receiving UOE identifier, the received token and a timestamp, to the managing server in response to retrieving the message from the message queue. In various embodiments, a GET request or GET API is used to retrieve a message. In some embodiments, the receiver communication event record also indicates whether the GET request or API is destructive, for example, a “read” from a queue, or non-destructive, for example, a “browse” of the queue. Several units of execution in different regions can issue a browse against the same message in the queue, and those UOEs will share the same token. The receiving UOE performs the request. The collector associated with the application environment containing the receiving UOE sends a receiver communication event record comprising an event type of GPS_GET_END, the receiving UOE identifier, the received token and a timestamp to the managing server after regaining control from the GET request or API which retrieved the message from the message queue. Meanwhile, the collector associated with the application environment containing the originating UOE sends an originator communication event record comprising an event type of GPS_PUT_END, the originating UOE identifier, the token used in the communication event record having an event type of GPS_PUT_START and a timestamp, to the managing server after the UOE regains control from the PUT API or request to put a message on the message queue. Therefore, the originating UOE sends the originator communication event record having an event type of GPS_PUT_END asynchronously with respect to the receiving UOE.
In step 134, the collector generates a token. In some embodiments, the token contains the application environment identifier of the originating application environment, and the value of the trip counter in the collector is incremented by one and stored in the token. In an alternate embodiment, the token is derived from environment variables, such as a message identifier and correlation identifier as described above. The token is hosted by, that is, contained in, a communication structure which depends on the nature of the communication. For example, in a request for a CICS service, the token is hosted, that is, stored, in the COMMAREA; in MQSeries, the token is part of the MQSeries message descriptor; and if IMS is the target of the request, the token is hosted by the Open Transaction Manager Access (OTMA) prefix user data.
In step 136, the collector sends an originator communication event record to the managing server. The originator communication event record has an event type of GPS_INVOKE_START or GPS_PUT_START, the UOE identifier of the originating UOE, the token and a timestamp. In some embodiments, the timestamp indicates when the request or message was sent by the UOE; in other embodiments, the timestamp indicates when the associated communication event record was sent to the managing server. In some embodiments, the UOE identifier and timestamp are contained in a UOE tag. In various embodiments, the token is a native token which contains the application environment identifier associated with the originating UOE and a trip counter as described above. In other embodiments, the token is a guest token. The collector sends an originator communication event record having an event type of GPS_INVOKE_START in response to a request for an IMS or CICS service and uses a native token. The collector sends an originator communication event record having an event type of GPS_PUT_START in response to a sending a message using the messaging system and uses a guest token. In some embodiments using a message queue, the originator communication event record also contains the queue name. In step 138, the collector exits.
In step 140, the communication is then sent to the receiving UOE with the token. The communication API which implements the communication passes the communication structure from the originating UOE to the receiving UOE. The communication structure contains the token as described above.
In step 144, the collector extracts the token from the communication. In step 146, the collector acknowledges receipt of the communication by sending a receiver communication event record comprising an event type of GPS_RECEIVE_START or GPS_GET_START, the receiving UOE identifier, the received token and a timestamp, to the managing server. The timestamp indicates when the request or message was received, or alternately, when the receiver communication event record was sent to the managing server. In various embodiments, the UOE identifier and the timestamp are contained in a UOE tag. In some embodiments, in response to the request being an invocation of an IMS or CICS service, the event type is GPS_RECEIVE_START. In other embodiments, in response to the request being a message from a messaging system, the event type is GPS_GET_START. In some embodiments, the execution of the receiving UOE is initiated in response to the request or message; in other embodiments, the receiving UOE is already executing prior to receiving the request or message. In step 148, the collector exits. The unit of execution of the application environment processes the request or message.
In an alternate embodiment, asynchronous invocation is used rather than a messaging system. In this embodiment, in step 172, the return from an API to send a communication to the receiving UOE using asynchronous invocation is trapped; and in step 176, the event type is GPS_INVOKE_END.
In some embodiments, steps 134-138 of
In step 194, in the managing server, the GPS correlates UOEs across application environments based on the originator and receiver communication event records. The GPS determines whether two UOEs are correlated by matching the tokens of the receiver and originator communication event records. For example, a UOE associated with the UOE identifier of an originator communication event record which has an event type of GPS_INVOKE_START is correlated with a UOE associated with the UOE identifier of a receiver communication event record which has an event type of GPS_RECEIVE_START if the tokens of the originator and receiver communication event records are the same. A UOE associated with the UOE identifier of an originator communication event record which has an event type of GPS_INVOKE_END is correlated with a UOE associated with the UOE identifier of a receiver communication event record which has an event type of GPS_RECEIVE_END if the tokens of the originator and receiver communication event records are the same. A UOE associated with the UOE identifier of an originator communication event record which has an event type of GPS_PUT_START is correlated with a UOE associated with the UOE identifier of a receiver communication event record which has an event type of GPS_GET_START if the tokens of the originator and receiver communication event records are the same. A UOE associated with the UOE identifier of an originator communication event record which has an event type of GPS_PUT_END is correlated with a UOE associated with the UOE identifier of a receiver communication event record which has an event type of GPS_GET_END if the tokens of the originator and receiver communication event records are the same.
The GPS identifies the originating and receiving UOEs based on the UOE identifier sent in the originator and receiver communication event records, respectively. The managing server receives other protocol messages from the data collector which are used to establish the identity of a thread, TCA or TCB within an application environment. When a collector starts, the collector identifies itself uniquely to the managing server, including the type of the collector, that is, the type of application environment that the collector is associated with, such as, J2EE, CICS or IMS. When the managing server receives a communication event record, the managing server identifies which collector is sending the communication event record, and therefore which application environment is associated with the communication event record. Therefore, based on which collector sent the communication event record and the UOE identifier of a communication event record, the managing server can identify the UOE and the application environment associated with the communication event record. In various embodiments, the managing server maintains information such as the names of the UOEs, their associated UOE identifiers, the name of their associated application environments and their associated application environments identifier. The GPS also determines what type of connection is used (synchronous/asynchronous invocation or messaging) by the event type of the communication event record. The GPS determines the order of events based on the timestamp. In some embodiments, the GPS determines whether a communication is synchronous or asynchronous based on the timestamp.
In step 196, the managing server provides a visual indication of the correlation between the originator and receiver communication event records, and therefore indicates the correlation between UOEs in different application environments.
Various examples of the communication protocol between the collectors and the managing server will now be described. The communication protocol works with synchronous and asynchronous communication. One difference between synchronous and asynchronous communication may be indicated by the difference in the timestamp. For example, for asynchronous communication the timestamp will be such that in some instances the communication event record with an event type of GPS_INVOKE_END from the originating UOE will have a timestamp with a value which is prior to the value of the timestamp of the communication event record having an event type of GPS_RECEIVE_END from the receiving UOE. In other words, the originating UOE does not “block” while the receiving UOE is executing. In synchronous invocation, the originating UOE waits until the receiving UOE finishes executing the invocation, whereas in asynchronous invocation, the originating UOE does not wait and can perform other activities, such as invoking another UOE. Therefore, in some instances, the GPS can determine whether a communication is synchronous or asynchronous based on the timestamp.
For example, a first unit of execution UOE1 204 of a first application environment attempts to communicate with a second unit of execution UOE2 206 of a second application environment. In response, as indicated by event record number one 216, the collector associated with the first application environment UOE1 204 sends a communication event record having a GPS INVOKE_START event type to the managing server. The execution of the first unit of execution UOE1 204 is suspended as indicated by dashed line 216. In response to receiving the communication from the first unit of execution UOE1 204, as indicated by event record number two, the collector associated with the second unit of execution UOE2 206 of the second application environment sends a communication event record having an event type of GPS_RECEIVE_START to the managing server. The second unit of execution UOE2 206 attempts to communicate with the third unit of execution UOE3 208. In response, as indicated by event record number three, the collector associated with the second unit of execution UOE2 206 sends a communication event record having an event type of GPS_INVOKE_START to the managing server. The execution of the second unit of execution UOE2 206 is suspended. In response to receiving the communication from the second unit of execution UOE2 206, as indicated by event record number four, the collector associated with the third unit of execution UOE3 208 sends a communication event record having an event type of GPS_RECEIVE_START to the managing server. In response to the third unit of execution UOE3 208 suspending execution, the collector associated with the third unit of execution UOE3 208 sends a communication event record having an event type of GPS_RECEIVE_END to the managing server as indicated by event record number five. Control is transferred back to the second unit of execution UOE2 206. In response to control being transferred back to the second unit of execution UOE2 206, the collector associated with the second unit of execution UOE2 206 sends a communication event record having an event type of GPS_INVOKE_END event record to the managing server as indicated by event record number six. As shown by event record numbers seven to sixteen, the processing continues until control returns to the first unit of execution UOE1 204.
In
UOE1 232 attempts to send a message 237 to UOE2 using asynchronous messaging. In response, the collector associated with UOE1 sends an originator communication event record, as shown by event record number 1 236, to the managing server. In response to receiving the message, the collector associated with UOE2 234 sends a communication event record, indicated by event record number 2 to the managing server. In accordance with flowcharts 11 and 12, communication event records, as indicated by event record numbers 4 and 5, respectively, are sent to the managing server. UOE1 232 and UOE2 234 continue processing. UOE1 234 then attempts to send another message 239 to UOE2 234, and communication event records corresponding to event record numbers 5, 6, 7 and 8 are sent to the managing server in connection with message 239. UOE2 234 attempts to send a message 240 to UOE1 222, and the communication event records associated with event record number numbers 9, 10, 11 and 12 are sent to the managing server in connection with message 240.
In some embodiments, messages are sent to IMS using an MQ-IMS bridge. For example, a J2EE process sends a request message with a token (MsgID, CorrellID) to IMS through the MQ-IMS bridge using a PUT API, and the collector associated with the J2EE process sends an originator communication event record comprising an event type of GPS_PUT_START, the hosting thread identifier of the J2EE process, the token (MsgID, CorrellID) and timestamp to the managing server. The request message is routed to IMS with the token (MsgID, CorrellID), and IMS invokes a GET API to retrieve the message. The collector associated with the IMS application sends a receiver communication event record comprising an event type of GPS_GET_START, the UOE identifier of the IMS application, the received token (MsgID, CorrellID) and timestamp to the managing server. Since the request message does not come from IMS, the IMS application considers the token for that request message to be (MsgID, CorrellID). Because the messaging is asynchronous, the collector associated with the J2EE process sends an originator communication event record comprising an event type of GPS_PUT_END, the hosting thread identifier of the J2EE process, the token (MsgID, CorrellID), and timestamp to the managing server in response to the PUT API returning control to the J2EE process. In addition, the collector associated with the IMS application sends a receiver communication event record comprising a GPS_GET_END event type, the IMS application identifier, the received token (MsgID, CorrellID) and a timestamp to the managing server upon returning control from the GET API to the IMS application. The IMS application processes a transaction associated with the request message.
In this example, the request message specified that a response message is to be returned to the J2EE process. Upon completion of the transaction associated with the request message, the IMS application sends a response message using a PUT API to the J2EE process using the MQ-IMS bridge. The PUT API is trapped and the collector associated with the IMS application is invoked. As illustrated in the pseudo-code above, the collector generates a token (CorrellID, Msgtype) to avoid ambiguity between the token of the request message. The collector associated with the IMS application sends an originator communication event record comprising an event type of GPS_PUT_START, the IMS region identifier, the token (CorrellID, Msgtype) and timestamp to the managing server. The IMS application sends the response message to the J2EE application through the IMS bridge. In this example, the J2EE process is waiting for a response from the IMS application. In response to the J2EE process retrieving the response message using a GET API, the collector associated with the J2EE process sends an receiver communication event record comprising an event type of GPS_RECEIVE_START, the hosting thread identifier of the J2EE process, the received token (CorrellID, Msgtype) and timestamp to the managing server. Because the J2EE process and IMS application are asynchronous, the collectors associated with the receiving and originating UOEs send communication event records comprising event types of GPS_GET_END and GPS PUT_END to the managing server, respectively. In this way, the communication event records for the request and reply messages can be distinguished.
In
The term “queue names match” 273 is part of the page caption and indicates whether the names of the put and get queues match if box 274 is checked. If the names of the put and get queues do not match, then the box 276 associated with the “queues do not match” caption 277 is checked.
In some embodiments, in response to a token of a receiver communication event record of a receiving UOE which has an event type of GPS_RECEIVE_END matching a token of an originator communication event record of an originating UOE which has an event type of GPS_INVOKE_END, a receiving arrow is displayed in a graphical user interface which displays a trace of processing of the receiving UOE, and an originating arrow is displayed in the graphical user interface which displays a trace of the processing of the originating UOE.
The memory 370 generally comprises different modalities, illustratively semiconductor memory, such as random access memory (RAM), and disk drives. In various embodiments, the memory 370 stores an operating system 388 and the managing server 20 which comprises the GPS 80, an application environment 400 and associated collector 402.
Computer systems 390 and 392 are coupled to the network 382 via transmission mediums 394 and 396, respectively. Each computer system 390 and 392 comprises an application environment 32 and 36 and an associated collector 62 and 66, respectively. The application environments 32 and 36 and their associated collectors 62 and 66 are stored in a memory on computer systems 390 and 392, respectively.
In various embodiments, the specific software instructions, data structures and data that implement various embodiments of the present invention are typically incorporated in the managing server 20 and collectors 62, 66 and 402. Generally, an embodiment of the present invention is tangibly embodied in a computer-readable medium, for example, the memory 370, and is comprised of instructions which, when executed by the processor 362, cause the computer system 360 to utilize the present invention. The memory 370 may store the software instructions, data structures and data for any of the operating system 388, managing server 20, application environment 400 and collector 402 in semiconductor memory, in disk memory, or a combination thereof. Other computer memory devices presently known or that become known in the future, or combination thereof, may be used for memory 370.
The operating system 388 may be implemented by any conventional operating system such as the AIX® (Registered Trademark of International Business Machines Corporation), UNIX, Windows® (Registered Trademark of Microsoft Corporation), Linux® (Registered trademark of Linus Torvalds), Solaris® (Registered trademark of Sun Microsystems Inc.), HP-UX® (Registered trademark of Hewlett-Packard Development Company, L.P.), z/OS and MVS operating systems.
In various embodiments, the present invention may be implemented as a method, computer system, apparatus or article of manufacture using standard programming and/or engineering techniques to produce software, firmware, hardware, or any combination thereof. The term “article of manufacture” (or alternatively, “computer program product”) as used herein is intended to encompass a computer program accessible from any computer-readable device, carrier or media. In addition, the software in which various embodiments are implemented may be accessible through the transmission medium, for example, from a server over the network. The article of manufacture in which the code is implemented also encompasses transmission media, such as the network transmission line and wireless transmission media. Thus the article of manufacture also comprises the medium in which the code is embedded. Those skilled in the art will recognize that many modifications may be made to this configuration without departing from the scope of the present invention.
The exemplary computer system illustrated in
The foregoing detailed description of various embodiments of the invention has been presented for the purposes of illustration and description. It is not intended to be exhaustive or to limit the invention to the precise form disclosed. Many modifications and variations are possible in light of the above teachings. It is intended that the scope of the invention be limited not by this detailed description, but rather by the claims appended thereto.
Claims
1. A computer-implemented method of tracking the processing of a transaction, comprising:
- receiving, by a managing server, a first communication event record from a first collector associated with a first application environment having a first unit of execution, said first communication event record comprising a first unit of execution identifier and a first token;
- receiving, by said managing server, a second communication event record from a second collector associated with a second application environment having a second unit of execution, said second communication event record comprising a second unit of execution identifier and a second token; and
- determining, by said managing server, whether said first unit of execution and said second unit of execution are associated with processing said transaction based on said first token and said second token.
2. The method of claim 1 wherein said determining determines that said first unit of execution and said second unit of execution are associated with said processing said transaction in response to said first token matching said second token.
3. The method of claim 2 further comprising:
- displaying, by said managing server, an indicator that indicates that said first unit of execution and said second unit of execution are associated with said processing said transaction.
4. The method of claim 1 further comprising:
- in response to an attempt to send a communication by said first unit of execution to said second unit of execution, generating, by a first collector, said first token;
- sending, by said first collector, said first communication event record comprising said first token and said first unit of execution identifier to said managing server;
- sending said communication from said first unit of execution to said second unit of execution;
- in response to receiving said communication by said second unit of execution, storing, by a second collector, a value of said first token in said second token; and
- sending, by said second collector, said second communication event record comprising said second token and said second unit of execution identifier to said managing server.
5. The method of claim 1 wherein at least one of said first token and said second token is a native token.
6. The method of claim 5 wherein said native token comprises an application environment identifier and a trip counter, said method further comprising:
- incrementing said trip counter in response to an attempt to send a communication by said first unit of execution to said second unit of execution.
7. The method of claim 1 wherein at least one of said first token and said second token is a guest token.
8. The method of claim 7 wherein said guest token comprises a message identifier and a correlation identifier.
9. The method of claim 7 wherein said guest token comprises a message type and a correlation identifier.
10. The method of claim 1 further comprising:
- in response to an attempt to send a communication by said first unit of execution to said second unit of execution, generating, by a first collector, said first token; sending, by said first collector, said first communication event record comprising said first token and said first unit of execution identifier, and also comprising a start event type, to said managing server;
- sending, asynchronously, said communication from said first unit of execution to said second unit of execution; and
- in response to said sending said communication, sending by said first collector, a third communication event record comprising said first unit of execution identifier and said first token, and also comprising an end event type, to said managing server.
11. The method of claim 1 wherein said first communication event record comprises a first timestamp, and said second communication event record comprises a second timestamp;
- determining an elapsed time based on said first and second timestamps.
12. The method of claim 1 wherein said first and second communication event records further comprise an event type indicating that a communication associated with said first and second communication event records, respectively, is message-based.
13. The method of claim 1 wherein said first and second communication event records further comprise an event type indicating that a communication associated with said first and second communication event records, respectively, is non-message-based.
14. The method of claim 1 wherein said first application environment is associated with a Java process, and said second application environment is associated with a legacy software system.
15. An article of manufacture comprising a computer usable medium embodying one or more instructions executable by a computer for performing a method of tracking the processing of a transaction, said method comprising:
- receiving, by a managing server, a first communication event record from a first collector associated with a first application environment having a first unit of execution, said first communication event record comprising a first unit of execution identifier and a first token;
- receiving, by said managing server, a second communication event record from a second collector associated with a second application environment having a second unit of execution, said second communication event record comprising a second unit of execution identifier and a second token; and
- determining, by said managing server, whether said first unit of execution and said second unit of execution are associated with processing said transaction based on said first token and said second token.
16. The article of manufacture of claim 15 wherein said determining determines that said first unit of execution and said second unit of execution are associated with said processing said transaction in response to said first token matching said second token.
17. The article of manufacture of claim 16 wherein said method further comprises:
- displaying, by said managing server, an indicator that indicates that said first unit of execution and said second unit of execution are associated with said processing said transaction.
18. The article of manufacture of claim 15 wherein said method further comprises:
- in response to an attempt to send a communication by said first unit of execution to said second unit of execution, generating, by a first collector, said first token;
- sending, by said first collector, said first communication event record comprising said first token and said first unit of execution identifier to said managing server;
- in response to receiving said communication by said second unit of execution, storing, by a second collector, a value of said first token in said second token; and
- sending, by said second collector, said second communication event record comprising said second token and said second unit of execution identifier to said managing server.
19. The article of manufacture of claim 15 wherein at least one of said first token and said second token is a native token.
20. The article of manufacture of claim 19 wherein said native token comprises an application environment identifier and a trip counter, wherein said method further comprises:
- incrementing said trip counter in response to an attempt to send a communication by said first unit of execution to another unit of execution in another application environment.
21. The article of manufacture of claim 15 wherein at least one of said first token and said second token is a guest token.
22. The article of manufacture of claim 21 wherein said guest token comprises a message identifier and a correlation identifier.
23. The article of manufacture of claim 21 wherein said guest token comprises a message type and a correlation identifier.
24. The article of manufacture of claim 15 wherein said method further comprises:
- in response to an attempt to send an asynchronous communication by said first unit of execution to said second unit of execution, generating, by a first collector, said first token; sending, by said first collector, said first communication event record comprising said first token and said first unit of execution identifier, and also comprising a start event type, to said managing server; and
- in response to sending said asynchronous communication, sending by said first collector, a third communication event record comprising said first unit of execution identifier and said first token, and also comprising an end event type, to said managing server.
25. The article of manufacture of claim 15 wherein said first communication event record comprises a first timestamp, and said second communication event record comprises a second timestamp; wherein said method further comprises:
- determining an elapsed time based on said first and second timestamps.
26. The article of manufacture of claim 15 wherein said first and second communication event records further comprise an event type indicating that a communication associated with said first and second communication event records, respectively, is message-based.
27. The article of manufacture of claim 15 wherein said first and second communication event records further comprises an event type indicating that a communication associated with said first and second communication event records, respectively, is non-message-based.
28. A system to track the processing of a transaction, comprising:
- a plurality of communication event records comprising originator communication event records and receiver communication event records, each communication event record being associated with a unit of execution of one of a plurality of application environments, each communication event record having a token, one or more of said originator communication event records being start event records; and
- a managing server to determine whether one unit of execution in one of said application environments and another unit of execution in another one of said application environments are associated with processing said transaction based on said token of said originator communication event records and said receiver communication event records.
29. The computer system of claim 28 wherein said managing server determines that said one unit of execution and said another unit of execution are associated with said processing said transaction in response to a token of said originator communication event records matching a token of said receiver communication event records.
30. The computer system of claim 29 wherein said managing server also displays an indicator that indicates that said one unit of execution and said another unit of execution are associated with said processing said transaction.
Type: Application
Filed: Sep 14, 2005
Publication Date: Mar 15, 2007
Applicant:
Inventor: Jean-Jacques Heler (Palo Alto, CA)
Application Number: 11/227,854
International Classification: A63F 9/24 (20060101);