Hi,
Probably not an answer to your questions but some remarks first.
First of all, a virtual service does not have an internal state, there is no internal database with business data. If during you recording there has been some request or response that contained the information "balance = 1000" that is not stored somewhere internally.
So, if your testcase is using a stateful conversation and doing
Deposit-100
Withdrawl-100
Withdrawl-100
then for this to work there must have been some request or response at the start of the conversation that contains the balance otherwise the 1000 will not be known at all during the execution of the conversation
You will have to store that balance in a property to be updated during the execution of the conversation. Either you will have to do that in additionnal steps within your VSM but you also have a lot of possibilities by using scripting inside your double curly braces within your responses.
Example, if your response contains a magic string which contains the balance that was received in your request then you might have something like {{request_balance}} in your response. You can instead put {{conversation_balance=request_balance;}} . Your response will still contain the same number but now you have also stored that number inside the property "conversation_balance" for this instance of the conversation.
Now your Deposit and Withdrawl transactions can have snippets in their responses like {{conversation_balance=conversation_balance+request_amount;}} (for a deposit). If the balance is not a piece of data in your response then you can still do the calculation by putting this snippet in a comment within your response eg. for XML that would be <!-- {{conversation_balance=conversation_balance+request_amount;}} --> It depends on your data protocol if you can use comments.
Finally, there is no concept of "looping" in a conversation, instead there is the concept of navigation tolerance which indicates what type of next request is accepted in the conversation and which can make the conversation move to another node in your conversation tree. Have a look at Navigation Tolerance - DevTest Solutions - 10.3 - CA Technologies Documentation
And then finally, probably the most important question which you need to ask yourself first: does the result of your testcase really depends on the balance being updated correctly? You are virtualizing your back-end, it is not part of your System Under Test, it is the backend that contains the business logic to store and calculate the balance for an account, this should normally not be something that your testcase should be worried about. Because if it would, if the correctness of that calculation is critical to the success of your testcase than it means that the back-end is part of your System Under Test and you should not virtualize it in the first place. If it is not critical then you can make an agreement that an "update balance" has a specific numeric format like the amount always ends with digits 999, so you know your System Under Test is displaying the upodated balance correctly without the actual number having to be correct.
The above is not to be pedantic, there can be valid reasons why the virtual service would need to have to do these calculations, but the objective for every virtual service should always be to make the simplest possible simulation of your back-end which supports your testing, so the question should always be asked.
Cheers,
Danny