The Request Event Details tab shows the list of inbound requests that caused the virtual service to error out. When you select a request, the list of VSM steps that executed is shown, with steps containing error events selected. To see the events that occurred during processing for that step (similar to the ITR), select a step.
Note: When a virtual service exceeds 100 transactions for each second, the Property Set and Property Removed events are disabled to allow for greater overall performance.
This option lets you see the session tracking information for the virtual service. For more information, see Session Viewing and Model Healing.
If you edit the service image or the VSM, save the changes and redeploy the modified service image in the VSE Console by clicking Deploy/Redeploy.
This option lets you set an execution mode for the virtual service. The number of execution modes available for a virtual service depends on the type of test step. For example, if a model does not have a live invocation step, it does not support the Learning or Live Invocation options.
The available execution modes are:
The fastest mode; it does not execute the routing or tracking steps. This mode also restricts generated event tracking.
Stand In mode first routes a request to the virtual service (the same as Most Efficient mode). However, if the virtual service does not have a response, the request is then automatically routed to the live system. You can only enable Stand In mode for a virtual service with a Live Invocation step. Stand In mode does not do any special tracking. It simply allows for a virtual service to fall back on the live service.
This mode fires more events than Most Efficient and remembers transaction flow through sessions. This transactional information is used to help determine why a specific response was chosen for a specific request. This mode does not perform as efficiently as Most Efficient. Transaction Tracking mode does not show live system responses; it only shows the response from the service image.
This mode uses the Live Invocation step of the model to determine a response to the current request. Instead of using the response from the virtual service, it accesses the live service to get the response. The target system of the live invocation controls performance. This mode is also known as pass through.
Failover mode first routes a request to the live system (the same as Live System mode). However, if the live system does not have a response, the request is then automatically routed to the virtual service. This mode is the opposite of Stand In mode. You can only enable Failover mode for a virtual service with a Live Invocation step. Failover mode uses the service image to determine a response if the Live Invocation step actually fails (as might happen if the live system were not available).
Learning mode is like Image Validation mode but it automatically "heals" or corrects the virtual service to have the new or updated response from the live system. The next request that is passed into the virtual service automatically sees the new response that was "learned". Not only one system is being checked to learn, but both are, and the live system currently prevails.
When a virtual service is running in Learning mode and it has acquired new knowledge, there is an icon 
to the left of the virtual service name in the VSE Console. The icon remains visible until you redeploy the virtual service.
This mode uses both the VSE and the live system to derive a response to the current request. The responses are logged for applying later to the service image using the View Session and Tracking panel. This mode allows a live comparison between the responses that VSE provides and a corresponding live system and, where differences exist, patches or heals the VSE service image to keep in sync with the live system. This mode is also known as "live healing mode." Image Validation is the least efficient of all the modes.
This mode enables the model to determine for each request which of the other modes to use. Performance is, therefore, unpredictable. The only requirement is that the VS Routing step is present in the model after the protocol’s listen step or steps.
Sets both the transaction count and error count to zero for the selected virtual service.
To stop the selected virtual service, click this button. The application displays a confirmation message before the service stops.
To remove the selected virtual service from the console display, click this button. The application displays a confirmation message before it removes the service.
Opens the Configure Tracking Data Cleanup window.
Enter data cleanup values here that remain in effect until the service is stopped and restarted. When the service restarts, the values reset according to their defaults or the values in a properties file.
Defines the interval (in milliseconds, seconds, minutes, hours, days, or weeks) after which to scan for tracking data to delete.
Defines the age of data (in milliseconds, seconds, minutes, hours, days, or weeks) to delete.
To shut down the complete VSE environment, click this button. If you reply affirmatively to the shutdown confirmation message, your VSE shuts down and the corresponding window closes.
|
Copyright © 2014 CA Technologies.
All rights reserved.
|
|