Access and Supported Products

End-to-End Monitoring is available only in the enterprise edition of IBM webMethods Integration.

See Product Considerations for information on the products supported by End-to-End Monitoring.

End-to-End Monitoring is available through the app switcher of your respective product, such as IBM webMethods Integration, IBM webMethods B2B, or IBM webMethods API Gateway.

Click Accessing End-to-End Monitoring for more details.

Total transaction duration is the overall time that is taken by a cross-product transaction to complete which includes the transit and the processing time of each service in the transaction. It is calculated as the difference of the latest end time and the earliest start time of processing among all the services that are involved in the cross-product transaction.

There can be differences between total transaction duration and the sum of the processing times of each service (shown in the business flow graph) in the cross-product transaction. These differences can be attributed to transit time between services due to network latency and infrastructural overheads and also due to time spent on asynchronous service calls.

Consider a cross-product transaction where IBM webMethods API Gateway calls IBM webMethods Integration WorkFlow service that in turn calls a hybrid integration call to a IBM webMethods Integration Server service running on-premises.

The difference between the latest end time and the earliest start time that is captured from each of the products (API, WorkFlow, On-premises IS) constitutes the transaction duration.

If every call is synchronous, then IBM webMethods API Gateway has the latest end time and the earliest start time.

However, if there is an asynchronous call in the transaction, then the earliest start time is captured from IBM webMethods API Gateway and the end time is selected from any of the products in the transaction with the latest value.

End-to-End Monitoring product nodes calculate the transaction duration by finding the difference between the time when the transaction request reaches the product and the time when the transaction response exits the product. However, the transaction duration of a product or service that is contained within a transaction is calculated based on the amount of time it takes to do the intended work within the product, excluding the initialization and termination procedures of the product. This difference usually converts to End-to-End Monitoring transaction duration being higher than the transaction duration of products or services that are contained within the same transaction.

Example 1

Consider a transaction with the following sequence of events:

A client sends a request to IBM webMethods Integration at 11.00.00, and receives a response at 11.00.05.

1. The request reaches IBM webMethods Integration at 11.00.01. The one-second delay is due to network traffic in between the client and IBM webMethods Integration.

2. The run of the Flow service starts at 11.00.02, and completes at 11.00.03. The one-second delay from 11.00.01 to 11.00.02 is due to initialization procedures required within the product for the run to begin.

3. Run control exits IBM webMethods Integration at 11.00.04. The one-second delay from 11.00.03 to 11.00.04 is due to termination procedures within the product.

4. Transaction response reaches the client at 11.00.05, due to network traffic in between IBM webMethods Integration and the client.

The total end-to-end run of this transaction takes five seconds.

The total run time of the IBM webMethods Integration Flow service is one second, so the IBM webMethods Integration product monitoring page shows a transaction duration of one second depicted by preceding point 2. However, the End-to-End Monitoring node that represents this IBM webMethods Integration Flow service shows a transaction duration of three seconds, depicted by the preceding points 2, 3 and 4. The client notices the overall transaction duration of five seconds, depicted by all 4 preceding points.

Example 2

Consider another scenario as an extension to example 1.

In this scenario, the Flow service that is mentioned in example 1 is called by an IBM webMethods Integration Workflow instead of the client. The Workflow has 8 steps before calling the Flow service.

1. The client submits a request to the IBM webMethods Integration Workflow at 10.59.00.

2. The request reaches the application at 10.59.01 due to the network traffic between the client and the application.

3. The actual workflow run starts at 11.59.02 after a delay of 01 second due to the initialization process.

4. The Workflow has about 8 steps to run and completes the run of these steps at 10.59.59.

5. The Workflow calls the Flow service at 11.00.00. The sequence of events from here is the same as example 1.

6. The response from the Flow service reaches the Workflow at 11.00.05.

7. The run of Workflow ends at 11.00.06.

8. The Workflow completes the termination process and returns the response to the client at 11.00.07.

9. The client receives the response at 11.00.08 due to network traffic.

The total run time of the IBM webMethods Integration Flow service is one second, so the IBM webMethods Integration product monitoring page shows a transaction duration of one second. This time duration is represented by End-to-End Monitoring as three seconds including the initialization and termination procedure time as mentioned in example 1. The log entry by the Flow service shows five seconds in the product monitoring page under the Workflow due to network traffic in between the Workflow and Flow service, initialization process, actual run of the Flow service, termination process, and network traffic for the response from the Flow service to Workflow. The run time of the Workflow in the product monitoring page is 1 minute 4 seconds, from 11.59.02 to 11.00.06. End-to-End Monitoring node that represents the Workflow shows a duration of 1 minute 6 seconds, 10.59.01 to 11.00.07. This two-second delay due to network traffic from client to Workflow and back is not captured anywhere either in End-to-End Monitoring or in the products.

The individual nodes do not contain any of the asynchronous call durations. You can obtain the duration of the asynchronous calls only if the specific product supports child service details. You cannot view the asynchronous call details if this support is not available. However, the overall End-to-End Monitoring transaction duration includes these asynchronous call durations.

When Develop Anywhere, Deploy Anywhere Flowservice transactions that are run in a loop, inconsistent results are observed due to back-end server indexing. Allow 30-60 seconds time for Elasticsearch to complete the indexing process and provide the correct count.