ALERT: Some images may not load properly within the Knowledge Base Article. If you see a broken image, please right-click and select 'Open image in a new tab'. We apologize for this inconvenience.

How to use the Inspection View and options to help debugging VSE transactions.


Article ID: 43193


Updated On:


Service Virtualization CA Application Test CA Continuous Application Insight (PathFinder)


How to use the Inspection View and options to help debugging transactions.


Release: DevTest 10.3, 10.4, 10.5, 10.6


Component: Portal



When we open the Inspection View we have two options:

. Matching View

. Request Event Details

The information showed in these tabs are impacted by the log level set in the file with the property below:


This property keeps a separate log for VSE transaction match/no-match events. Having a separate log makes debugging much easier. Change INFO to WARN for production/performance systems. Do not simply comment out the following line. Explicitly set the log level to OFF or WARN instead of INFO.

Note that if there are no transactions against the VS, then there will be no Inspection View details either.


Matching View

The Matching View lists recent requests that the virtual services processed. When you select a request, the dialog shows a description of how the request was or was not matched. 

The same information is recorded in the vse_matches.log file. If any events were associated with the selected request, they display at the bottom of the panel.

As mentioned before, the information displayed in the Matching view depends on how VSE logger is set.

If the property log4j.logger.VSE is set to DEBUG:

log4j.logger.VSE=DEBUG, VSEAPP

We will see all the events in the “Events” panel, like in the image below:

The “Long Info” column shows the source request details and what matched or didn’t match.

If the property log4j.logger.VSE is set to INFO:

log4j.logger.VSE=INFO, VSEAPP

DevTest won’t generate as much log as in DEBUG mode and we won’t have information to be displayed in the Events panel. See image:



If the property log4j.logger.VSE is set to WARN:

         log4j.logger.VSE=WARN, VSEAPP

DevTest will only generate log when there is a WARN scenario. In this level we won’t see any transactions in the Inspection View/Matching tab.


There is a property that controls how many VSE matching related events are buffered. These events are the source for the "Matching" tab of the VS model inspection page in the VSE dashboard.


The default value is 100, but it is possible to increase this number – with caution, it can impact memory usage. To increase its value you can add this property to the file and set it to 200.

The number of events is per VS model so if you have 2 VS models deployed with the default event buffer size of 100, then a total of 200 events will be buffered.

If the number of events per VS is higher than the value specified with this property then we won’t be able to see some events in the matching tab.

This can happen when a VSI has too many transactions. When a request is sent to the VSM the VSE checks each transaction until it finds one that matches. For every check performed the VSE generates events. If the request that was sent doesn't match one of the first transactions in the VSI, we are going to get several events. If there is no match, it will go through the whole VSI and generate events for every check. In DEBUG mode, DevTest logs every analysis the VSE performs until it finds the right transaction to match. These events are stored in the vse_matches and VS_<VSMName> log files. 

If a request is being forwarded to the live system we won’t be able to see the transaction in the matching tab – that happens because the VSI is not verified, the request goes directly to the live system.


Request Event Details View

The Request Event Details view shows the list of inbound requests, the ones that caused the virtual service to error out and the good requests. When you select a request, the list of VSM steps that was executed is shown. To see the events that occurred during processing for that step (similar to the ITR), select a step.

The information displayed on this tab is also impacted by the log level set in the file – DEBUG, INFO or WARN.

Sometimes we won’t see the remaining VSM steps executed in the “Execution Step Events” panel or we will see the steps as “(unknown)”, as highlighted in the image.

When that happens we can add the property below to the file and increase its value:


This property controls how many inbound VSE requests for which a full set of DevTest events is buffered.  The default value is 50.

If we increase this property value – with caution, we will be able to get the whole list of steps executed. You can increase it from 50 to 200.


If you are still having problems to see the step required, try to increase it to 500.

It also depends on how many events your virtual service is generating, if there are too many assertions and filters in the VSM, it could be that you need to increase this buffer a little more.

The image below shows what happened after the value of the property above was increased.

Depending on the request size, we will see the transactions body as “_TRUNCATED_” in the Inspection View/Request Event Details:

To change this behavior add the property below to the VirtualServiceEnvironmentService.vmoptions or VirtualServiceEnvironment.vmoptions file:


Save the vmoptions file and restart the VSE Service.

Additional Information

The steps on this document is for debugging purpose only. The content of this document is not recommended for performance environment. The logging can slow down systems with high transaction rates.


There is no need to restart DevTest components after modifying the file.


The file should never be modified.


The properties referenced here should be added to the and vmoptions file only.


After editing and vmoptions file, DevTest components should be restarted.