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:
- Send a holdings response first then
- Send 4 Ongoing Transaction Responses
- The Holdings VSI has 5 responses (Rsp 1 = holdings, Rsp 2 - 5 = the 4 Ongoing Txn Responses)
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.