Hi All,
I have a requirement where i wanted to send multiple responses to a single request.
For example I have request holdings_request1 and responses holdings_response1, transactions_response1. When i send holdings_request ill have to get holdings_response1 and immediately transactions_response1.
I added the transactions_response in VSI using add a new response to the transactions option available in VSI response tab.
But still when i hit request am getting only top response. i.e response 1 of 2.
Could you please help me what needs to be fixed.
Thanks in advance!
Regards,
Girija K
Using this requirement:
2. The requirement is after sending the Holdings response I have to send ongoing_transactions response as well. In ongoing_transactions again I have four response XMLs , but no request. So what I did is I created a Virtual service with holdings request and those ongoing transactions response XMLs.
I believe the above means that a consumer application sends a Holdings Request. When this happens, you need to:
If the above is true, what we are trying to communicate is:
- The VSM Listen Step receives a holdings request,
- At a minimum, the VSI Selection Step selects a holdings response but could select up to 5.
- The VSM Responder Step sends holdings response only
Under HTTP 1.1, the sending of the holdings response closes the socket between the consumer and virtual service. This is standard HTTP 1.0 & 1.1 behavior.
So the issue is, the 4 Ongoing Transactions need to be sent after the Holdings transaction has been sent.
The caveat is that the Ongoing transactions must be sent back to the consumer application using a REST or Webservice step (assuming everything is HTTP) where the endpoint of the REST or WS step is some endpoint on the Consumer application. The point is that the Ongoing Transactions will not be sent on the HTTP connection (i.e., socket) that was used to send the Holdings request - because this socket is closed when the Respond Step for Holdings executes. This is OOTB behavior.
After the Holdings VSI Selection step executes, the lisa_vse_response (object of type List), contains all 5 responses. By design an HTTP Responder Step only sends the first occurrence from this list (e.g., lisa_vse_response.get(0) ).
Your decision will be how to deal with response 2, 3, 4, & 5. But, you cannot deal with these responses until you have dealt with the Holdings response.
1) You might add an assertion in the Responder step that checks the size of the lisa_vse_response list. If the List has a size greater than 1, then VSM branches to a series of steps that iterate over the List and send REST calls for each of the Ongoing Transaction request XMLs. Perhaps a Sleep step is added to this loop to slow down the responses. NOTE: Due to the complexity of the VSM model (it handles Summary, Holdings, Database I/O, etc.), it would be best to iterate over the list returned by the Holdings VSI Selection Step (e.g., lisa_vse_response.get( i ).setBody(testExec.parseInState( lisa_vse_response.get( i ).getBodyAsString() where "i" is an index in a for loop). This logic sets the body on each occurrence and should be performed before the Holdings Responder Step executes so you don't lose references to magic string data.
2) Given your example and the complexity of this VSM, I would consider delegating the job of sending the Ongoing Transactions to a second VSM. The Holdings VSM would place each of the Ongoing Transactions on the Shared Model Map or Persistent Model Map and the second VSM would contain the logic to send REST or WS Ongoing Transactions calls back to the consumer application. The issue is that each response placed on the Model Map a) needs to call testExec's parseInState() method before the transaction is placed on the map and b) the key to each Ongoing Transaction request needs to be unique so entries on the Model Map are not overlayed. I would consider using a key of date/time/millis. The key represents the "time" you want the second VSM to send the transaction. Perhaps, the Holdings VSM calculates this as current time plus "n" number of seconds. The second VSM has no Listen Step, rather it just has a Marker Step. A loop step iterates the Model map and based on a comparison of current date/time/millis in the second VSM to the date/time key from the Map's keyset, the VSM sends the transaction to the consumer if the date/time/millis on the Map is less than the current date/time/millis. The second VSM removes the "sent" transaction from the map, makes the REST or WS call, looks to see if any more transactions need to be sent. If no transactions to send, the VSM sleeps for 10 seconds, wakes up and iterates the map again. The VSM does this every 10 seconds, 24 hours / day, 365 days / year. The majority of this option requires JSR script logic and Model Map processing.