Hi Tausif-
I read thru this conversation. If your scenario requires stateful behaviors then the best way to create VS using DevTest platform is with a Conversation ID. This is out of the box feature and is the recommended approach. Typically the stateful behaviors are required when you are testing from the UI and the scenario to be tested is tied with user login to logout. And you have to assert the result also. ( for example regression testing from QTP with validation or training environment where the attendee should see the correct data). Here there will be always a session ID at the presentation layer to track user conversation. There are ways by which you can transmit the session ID to other layers also.. You may have to take help of your application architect.. For example , your dev team can help with a javaagent to instrument certain classes and transfer the session ID to other layers.. You need to only see the approach should not require change in the application codebase and should be only applied to lower environment. just for example.. DevTest CAI agent do the transaction stitching by a javaagent, instrumenting the right classes and adding the transaction tracking ID to the thread.. This the CAI agent does without changing the application codebase.. it only requires a agent to be deployed in the lower environment..
Coming to other 2 solution mentioned above in the thread:
1. Shared Mode Map: This approach is like stitching the stateless transaction manually with the session flow logic using java code. While this can technically work, but it will be a tedious task to do, needs java skills, strong application transaction understanding and may not be error free. Just imagine if you given a fish bowl with 1000s recorded transaction for 100s of conversation and you are asked to find all the starter transaction of each scenario. Without knowing what scenario are played in which order , the sequence of services called by each scenario and application knowledge can you find all starter transaction manually??? Now imagine this is only the starter transaction and then you need to find all other navigation path and stitch them with in memory data using Shared Model Map!!!. . Also, using any memory model is like persisting the data.. which means you burn the data.. So if you burn data then you have to again refresh the data.. To me it appears it defeats the virtualization concept . Try avoiding building logics and persisting the data with in the Virtual Model..
2. "Synthetic Session ID": With this approach, DevTest will create a one single conversation for all the scenarios no matter what is the starter operation.. That means there will be only one starter operation and then series of steps as recorded...You should remember in the VS model you can have only 1 strategy for the conversation ID. Also, if you have to restart the scenario , probably you have to give a restart to VS to remove the session details or wait till the session is timeout. Else the navigational tolerance will result into no match found result... Again though it looks technically possible, but it will be operationally challenging and also, we have to run the scenario always in the same order...
My suggestion, for stateful behavior always use the session/ conversation ID and create the VS as supported by DevTest... Avoid using any persistence solution, as that is like building a real system... And remember, that stateful scenarios are mainly observed when you are testing from the front end UI. For API testing most of the time it will be stateless...