Hi All, I have created a Virtual Service which communicates over HTTPs protocol. In the model file the "live invocation port" step takes response that is generated by the image, but instead I want it to get response from a custom step (The custom step makes a java call and sends the response).
I am more intrigued as to what requirements are limiting the VSI's ability to handle the responses for you. Anyway...
VSM's are editable and steps can be added, changed, and deleted. Therefore, you could 'swap' the Live Invocation step with a step that makes the call to custom Java code. The custom step would need to pass the incoming request to the custom code. When the custom code finishes, your logic would need to 'update' the DevTest objects so they conform to DevTest's expectations. The step after your custom 'live invocation' would be the DevTest Responder step which would send the response to the consumer.
The implementation of your custom logic is not likely to be trivial. Some things that come to mind are...
1) Review this document to help you understand some of the framework concepts: DevTest 8.0 - Scripting Guide - V1.1.pdf
2) You need to figure out how, or if, you are going to deal with tracking, learning, and the various fail over modes in this model. These modes use DevTest framework elements. If you replace the live invocation step (and its branching), the custom logic has to ensure that DevTest objects are properly set up in the custom code. My intuition is that you would remove these modes from the model to make the service as straight forward as possible.
3) The custom logic will need to create proper DevTest response objects. The code could instantiate and set the lisa.vse.response list manually; however, I would be inclined to call the VSI Selection Step and let that step create a skeleton lisa.vse.response list object. The custom code could utilize the public getter/setter methods to update the transient response body and meta data headers with the response data returned from the custom code.
4) The custom logic should not attempt to send the response -- let the responder step do that -- otherwise, the custom logic has to figure out how to hijack the worker thread handling the transport communications and implement its own HTTPS communications back to the consumer. This is most definitely not trivial.
5) Testing and debugging will be interesting if the developer is not familiar with the lower level DevTest framework components and how to access them. I would be inclined to implement logging steps throughout the model to aid in debugging run time errors and issues after the service is deployed. Although this will cause the vse.log file to grow, it is likely to be helpful long term.
6) You made no indication of whether or not you were creating a Custom Step or simply invoking a custom class. If you implement a custom step, search communities for the FTP Step to download and review a sample custom step implementation pattern.
Joel response is absolutely correct. VSMs are editable and you can play with it the way you want.