I have more technical/in-depth, content in the works (a developerWorks article), but a recurring theme in my discussions with IBM teams and customers who are new to the SV game is confusion around what proxy settings need to be applied - and where - and why.
Here's one situation: Imagine system 1 sends a request to system 2, and as part of its processing system 2 sends a request to system 3. We want to record tests to be able to test our SUT (system 2). If we configure system 2 to use our proxy, then we will never see system 1's request to (or response from) system 2. For that to happen, we need to configure the client that sends the request --- system 1. Seems simple, right? But this is where I see the most confusion, because this can be a subtle point to grasp.
The flip side of the coin is recording virtual services: if, as above, we have system 1 configured to use our proxy, we could create virtual services but they would be useful only for system 1 (and that is not our SUT today - tomorrow, it might be!). In fact, we can record the traffic that goes between system 1 and 2, and between system 2 and 3, at the same time. RTW is very powerful this way.
Once someone "gets it", the conversation goes much faster, logical topology diagrams are much more quickly produced, we can identify those systems where we need to make configuration changes or install agent technologies, and network security changes can be made with more confidence (configuring firewalls to allow traffic between relevant client systems and RTW/RTVS, and between RTW/RTVS and relevant back-end systems).
What we record between system 1 and system 2 can be saved as a test and used to test system 2 in the future. What we record between system 2 and system 3 (and/or system 4) can be used to create virtual services ("stubs") to be able to run all kinds of tests against system 2 while never hitting system 3 & 4 (the "live back-ends"). We can even use the tests we recorded (traffic from system 1 to system 2) and the stubs at the same time! At the far extreme, we can run tests in RIT against system 2, have system 2 use virtual services instead of live back-ends, and record at the same time (a great way to validate & debug your virtual services).
This diagram has resonated with my audience in the past, so I thought it would be good first blog entry (this was produced using the sketching module in Rational Software Architect, by the way - there's a demo at the link).
If you change the SUT to system 1, then whatever calls into that system would be recorded to be able to test against system 1, and we could virtualize system 2 so system 1 could run its regression or other tests even when system 2 is down.