Hi Team,
Looking forward for some help. We have developed lot of virtual services and requests do come from different channel for consumption. When certain test fails consumer come and ask if lisa can capture both request and response when it hits SV. I would like to know if there is way to capture them (e.g soap calls) that actually comes/sent and can be made available to consumers at console. Apologies I haven't done deep search on communities as its urgent if it is already answered.
It sounds like you do not have the time to implement a customization; therefore, take a look at the facility called Inspection View. Keep in mind that it seems your requirement probably needs a customization to provide the level of detail your consumers appear to be asking for in a more organized or concise way.
Inspection View - DevTest Solutions - 10.0 - CA Technologies Documentation <-- this link speaks to the inspection view.
Some screen shots from a live service look like these:
Accessing by right click on a service, then selecting Inspection View.
Locate the operation and view various request-side artifacts including the actual inbound request:
Navigate to the response side. Note ID below ties to the response located in the VSI:
When a high number of service calls are being made, the above process can be confusing for the average service consumer (channels) because their requests are commingled along with every other consumer's requests. Paging through a significant amount of history to find their respective request/responses may be problematic.
Other Manual Approaches:
The information above is also written into the vse.log, vse_matches.log, and VS_yourService.log (where yourService is the name of your virtual service) if the logging.properties file is set to INFO. The data found in the logs requires some stitching based on the timestamp and other inputs to align the request and response information. DevTest does not provide an OOTB tool that stitches the log output into a readable format. This activity is most likely something your consumers will not be able to do with ease. Similarly, the logs contain more information than just the request / response information.
Custom Approaches:
Some customers have implemented custom logging routines in their models to write additional supporting information into the DevTest log files or separate the output into service-specific log files. These approaches are custom in that the VSM must be modified to write the request/response output to the file system. This approach is not overly complex, but you indicated that you a) need a mechanism to turn it on & off, and b) you indicated that you have a high number of services so modifications to each service may be a limiting factor.
Additionally, customers that use tools such as Splunk often insert custom logging messages into the DevTest logs so that Splunk can consume the information and make it query-able. I had a very large customer use this technique for all virtual services. Each step in the model logged information (prefixed with an identifying key) that enabled the customer to use Splunk queries to retrieve not only the request / response, but much more information about the flow the service executed.
Thanks a lot Joe..appreciate your time and effort to look into this. As I have used 9.5 earlier I can correlate the screens and options available in DevTest 10.0. Its my bad that I should have told you on version I am working and log level access as it would be clear on probable solutions you have recommended.
1. DevTest version is 7.5.2 and inspection view available on devtest console doesn't give that level of information what portal gives. There is way to track response returned by switching it to transition tracking but shortfall of this is that it doesn't give request and 2nd this mode is not available if vsm is developed in recording mode. Also the inspection level ->request event details doesn't throw up request and responses but gives inbound request in the format isn't useful.
2. We have more than 30 servers dedicated for different consumers and access to backend to check vse.log, vse_matches.log, and VS_yourService.log is restricted to the consumers. Also there are dedicated NFT servers where loads of request come and verifying log and matching for specific failed transactions will be tedious task to do.
3. Custom approach is something that I can consider as long term solution but this requires rework on existing assets which is again time consuming as each of the servers have plenty of services running and consumed.This needs to be carefully managed as we don't want to disrupt the service. If you can hint me a solution or share a sample project I can take a look.
4. Splunk event logging tool looks good option but comes with the price which I need to check.
Overall from your response it looks like there is no easy and quick way in lisa 7.5 but its featured in devtest 10.0.
The Console Inspection View in 7.5 is similar to Portal's Inspection View in 9.x and higher. The major difference is the UX. However, both seem likely to fall a bit short of your needs.
I believe some type of customization is necessary.
Off the wall idea? Maybe or maybe not...
This may be a stretch, but what if you created a front-end virtual service that performs what amounts to live invocation? Your consumers call this front-end service. The front-end passes the request to the virtual service back-end. When the response comes back from the virtual service, the request and response are logged to a consumer accessible file share using some type of directory and file naming standard for the R/R pairs.
I don't know if it is feasible to choke all of the services through a single endpoint since I do not know what kind of transaction volumes and response time characteristics you have.
If you are running a functional VSE with a reasonable amount of concurrent input requests, this might create throughput issues which could result in HTTP timeouts.
Logic would need to be added to setup the virtual service endpoint and port -- probably based on analysis of the incoming operation and/or URI information, create a bogus VSI response, send the lisa_vse_request body to the endpoint, and fill in the lisa_vse_response with the response from the downstream service. After the responder step, write the R/R pair to the appropriate directory on the file system. You may also need to marshal the response headers into the lisa_vse_response Meta Data prior to sending the response to the consumer. Rather than a Live Invocation step, you would likely use a REST or WS Execution XML step.
You could get fancy and set up an interface on the front-end that that allows you to enable and disable writing the R/R pairs so transactions are only logged when the "log step" is enabled.
Short of modifying the individual services, the above may or may not be an alternative to consider.
Perhaps, others have ideas....
Others always have ideas, Joel
An option similar to the Splunk one, but free, could be to use the Elastic Stack. I have no idea how people use these log parsers & filterers, but I created a quick configuration to read DevTest log files, so FileBeat reads the logs, LogStash stores the data into a database, ElasticSearch can mine the data (for requests and corresponding responses, presumably), and Kibana can visualise it all.
Thanks Rick. I will try this soon, need lot of approvals to get something that is free so hopefully I will get through
If I'm developing something new then yes I will definitely consider this option but situation at my end isn't something like this as lot of systems are involved where endpoints needs to be changed by build team its a massive work.
The Console Inspection View in 7.5 is similar to Portal's Inspection View in 9.x and higher. The major difference is the UX. However, both seem likely to fall a bit short of your needs.
I believe some type of customization is necessary.
Off the wall idea? Maybe or maybe not...
This may be a stretch, but what if you created a front-end virtual service that performs what amounts to live invocation? Your consumers call this front-end service. The front-end passes the request to the virtual service back-end. When the response comes back from the virtual service, the request and response are logged to a consumer accessible file share using some type of directory and file naming standard for the R/R pairs.
I don't know if it is feasible to choke all of the services through a single endpoint since I do not know what kind of transaction volumes and response time characteristics you have.
If you are running a functional VSE with a reasonable amount of concurrent input requests, this might create throughput issues which could result in HTTP timeouts.
Logic would need to be added to setup the virtual service endpoint and port -- probably based on analysis of the incoming operation and/or URI information, create a bogus VSI response, send the lisa_vse_request body to the endpoint, and fill in the lisa_vse_response with the response from the downstream service. After the responder step, write the R/R pair to the appropriate directory on the file system. You may also need to marshal the response headers into the lisa_vse_response Meta Data prior to sending the response to the consumer. Rather than a Live Invocation step, you would likely use a REST or WS Execution XML step.
You could get fancy and set up an interface on the front-end that that allows you to enable and disable writing the R/R pairs so transactions are only logged when the "log step" is enabled.
Short of modifying the individual services, the above may or may not be an alternative to consider.
Perhaps, others have ideas....