Categories

Access and Supported Products

Why don’t I see the End-to-End Monitoring option on the app switcher?

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

If you satisfy the mentioned criteria but still not able to access End-to-End Monitoring, contact IBM support and share the details such as tenant name, cloud provider, and region to enable the capability.

What products are currently supported by End-to-End Monitoring?

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

How do I access the End-to-End Monitoring capability?

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.

How is transaction duration calculated?

Total transaction duration is the overall time 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 amongst all the services 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 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 which 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 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 will have 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 having the latest value.

Why is the End-to-End Monitoring transaction duration higher?

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. On the other hand, the transaction duration of a product or service 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 usually translates to End-to-End Monitoring transaction duration being higher than the transaction duration of products or services 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 IBM webMethods Integration product monitoring page shows a transaction duration of one second depicted by point 2 above. However, the End-to-End Monitoring node representing this IBM webMethods Integration Flow service shows a transaction duration of three seconds, depicted by points 2, 3 and 4 above. The client notices the overall transaction duration of five seconds, depicted by all 4 points above.

Example 2

Consider another scenario as an extension to example 1.

In this scenario, the Flow service mentioned in example 1 is called by a 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 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 execute 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 IBM webMethods Integration product monitoring page shows a transaction duration of one second. This 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 representing 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.

Why does Develop Anywhere, Deploy Anywhere Flowservices monitoring show inconsistent results for transactions running in a loop?

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

Integration Server (IS) package-based Hybrid Monitoring Agent

Why do I see a blank page when I click on the Home icon in the IS package list?

Verify if WmE2EMAPIAgent and WmE2EMIntegrationAgent are checked out together, since only one package is supported per instance. Retain any one package as per your requirement and restart the Integration Server.

Why does Integration Server fail to start up after installing End-to-End Monitoring agent?

Integration Server fails to start up after installing End-to-End Monitoring agent for either of the following reasons:

• custom_wrapper.conf file contains old installed directory details. Remove the old entries and restart the Integration Server.
• IS package is in disabled or inactive state. In Administration, go to Packages > Management, enable the IS package and restart Integration Server.
• custom_wrapper.conf file is corrupt. Restore the file from your backup file and restart Integration Server.

Why is the agent collector connectivity status Offline ?

• Check your logs from the web interface and verify if the agent has started without any issues.
• Verify the end point URL in the agent.config file.
• Verify your cloud settings.
• Restart Integration Server for the above changes to take effect.

Why do changes to agent.config file not take effect?

Restart the Integration Server for configuration changes in agent.config file to take effect.