When working with WebSphere MQ, you can enable the DevTest Java Agent on the client, the server, or both the client and the server. The contents of the path graph vary depending on the scenario.
Note: DevTest can behave as if it is an agent-enabled client. This behavior occurs when a test case uses an IBM WebSphere MQ step to invoke the service.
Scenario 1: Client Enabled, Service Not Enabled
The client is agent-enabled, and the service is not agent-enabled. This scenario simulates a Java-based client running against a Windows or mainframe-based service that cannot be agent-enabled.
When you view the transaction details in the DevTest Portal, the path graph contains two nodes.
The first node represents the request. To view the message body, select the node and then click the Request tab.
The second node represents the response. To view the message body, select the node and then click the Response tab.
Scenario 2: Client Not Enabled, Service Enabled
The client is not agent-enabled, and the service is agent-enabled. This scenario simulates a Windows or mainframe-based client that cannot be agent-enabled running against a Java-based service.
The first transaction in the DevTest Portal is a priming transaction. The agent on the service side discovers that it is running on the service side and initializes itself.
The subsequent transactions are the same as for scenario 1. The path graph contains a request node and a response node.
Scenario 3: Client Enabled, Service Enabled
Both the client and the service are agent-enabled. This scenario simulates a Java-based client running against a Java-based service.
The first transaction in the DevTest Portal is a priming transaction. The agent on the service side discovers that it is running on the service side and initializes itself.
For the subsequent transactions, the path graph contains four nodes:
Copyright © 2014 CA Technologies.
All rights reserved.
|
|