Service Virtualization

 View Only
Expand all | Collapse all

Stateful virtualization of MQ services

  • 1.  Stateful virtualization of MQ services

    Posted Nov 18, 2015 11:44 AM

    Need some ideas on how to proceed with stateful virtualization when message is in copybook over MQ. There is no session id which can be used to manage session.


    Flow is like


    UI ->tibco webservice over http -> copybook over MQ to mainframe.


    My UserInterface maintain session but tibco webservice is stateless which in turn calls mainframe over MQ in stateless fashion.


    Now i want to virtualize a call to mainframe i.e Copybook over mainframe.


    My scenario is like first user logins from UI, select credit card number , then checks account holders details which returns 1 person details. He adds one more account holder name, and then again checks account holder details which returns 2 person details.


    Operation flow is like that for below copybook operstions.






    I tried first in stateless manner in VSI and selected allow duplicate transactions for operation getaccountholdersdetails to give 2 person details second time when this operation get calls but problem is what if user session ends after 1st request to getaccountholdersdetails call and again if he logins and first time checks getaccountholder operation he will get two holders details.


    How to handle user session here in backend.


    Please feel free if you need more information from my side.




  • 2.  Re: Stateful virtualization of MQ services
    Best Answer

    Posted Nov 18, 2015 12:38 PM

    To make a stateful service there *has* to be some kind of persistent session ID that we can extract, from either the message headers or the message body itself.  Even if your duplicate transaction scheme works, and the user always makes the second  'Getaccountholderdetails' call, it will still fail if more than one user hits the service at the same time.  For stateful to work there has to be a some kind of identifier that separates distinct user sessions.


    If there is absolutely no such identifier you can latch onto, then you might be able to use a Shared Model Map to keep some state in a stateless service.  I'm not really familiar with that functionality so I can't give you many details.

  • 3.  Re: Stateful virtualization of MQ services

    Posted Nov 18, 2015 01:51 PM

    keep in mind you can use a synthetic "session id" for example user id + accountNumber extracted from the payload it does not have to be a full class sessionId sent from the client.  However my experience is that even though you might think you need a stageful service the use case may be completed with stateless services and a little help with functions to create dynamic data in the response.

  • 4.  Re: Stateful virtualization of MQ services

    Posted Nov 18, 2015 07:09 PM

    Thank you kevin n perez. But in backened there is no sessionid, no user id in request, only account number passed in request in webservice call of getaccountholdersdetails. In most of the webservice call, there is no sessionid passed. Webservice calls are stateless.


    Can someone give highlight is there any way we can pass the user sessionid to tibco webservice call and also to mainframe copybook call over MQ. So that i can create statefull virtual service instead of coding the logic in every match script of virtual service transaction.


    Also if it is shared model map, I know , to keep state using code is tough to maintain in each specific transaction match script. Because the current scenario is just single scenario i gave. But we have so many scenario like this with different services. If not possible way to go for stateful, then hav to go this way. :-(

  • 5.  Re: Stateful virtualization of MQ services

    Posted Nov 18, 2015 07:17 PM

    only account number passed in request in webservice call of getaccountholdersdetails

    Is this account number present in the copybook MQ request?  And is it also present in the Addaccountholderdetails MQ request?  If so, then can you use that as your session ID?

  • 6.  Re: Stateful virtualization of MQ services

    Posted Nov 18, 2015 07:26 PM

    You r right kevin.this account number is same in all 3 request and also present in copybook too. But wat if user logout after first call of getaccountholderdetails and addaccountholderdetails and login again and call getaccountholderdetails.


    I think lisa session will not expire in this case. It will call the second getaccountholderdetails in first call only next time.


    Please correct me if i m wrong.

  • 7.  Re: Stateful virtualization of MQ services

    Posted Nov 18, 2015 07:36 PM

    But wat if user logout after first call of getaccountholderdetails and addaccountholderdetails and login again and call getaccountholderdetails.

    If someone calls getaccountholderdetails, then addaccountholderdetails, then logs out, then logs back in, and is still using the same account number when they call  getaccountholderdetails again then it seems like the correct behavior would be to pick up where they left off, with the second response.  That's how the live application would respond, right?

  • 8.  Re: Stateful virtualization of MQ services

    Posted Nov 19, 2015 06:16 PM

    You are right for live application scenario kevin.


    Actually User Interface tester requirement is limited to one session only.


    They dont want to get back two holders details on first call.


    They want to see in one flow of automation testcase.


    Once logout or session expire anywhere in between the virtual service position should get reset to the starting point. So that they can run their next testcase.


    I think its complicated based on user interface session to handle virtual service.


    Sharedmodelmap have to choose. I will try this as of now.


    Thank you kevin. Very helpful ideas.

  • 9.  Re: Stateful virtualization of MQ services

    Posted Nov 18, 2015 07:21 PM

    why do you think you need a state full service ?  in general there should be a way to uniquely identify a response without having to use stateful service or using/inserting MATCH script that would be an option that i would try later since the maintenance like you mentioned.  What response is dependent on a previous requests?  can you share the match script example it would help understand the context a bit more.  Also , have you considered engageing CA PS or other Partner PS organization to help resolve your issue?

  • 10.  Re: Stateful virtualization of MQ services

    Posted Nov 18, 2015 07:28 PM

    i re-read your original post and problem this is a common issue and comes up quite often in client engagements.


    heres' what i would suggest;


    first why does the second call to the Getaccountholderdetails, have to show the  "changes" to data in the backend, are u testing the backend provider or the TIBCO application?


    if your testing the tibco app, then simply use two accounts/use cases to represent the second scenario, your testing should focus on the ability of your app to properly send and receive the various types of responses from the backend , the data should not be the focus of your testing but rather how your app responds to the various kinds of responses,


    if you capture / model two accounts or use cases one can represent the pre-add state and the second use case can represent the post-add...i would go further and say that SV you can model all kinds of positive and negative scenarios.

  • 11.  Re: Stateful virtualization of MQ services

    Posted Nov 18, 2015 07:41 PM

    Perev we are removing copybook mainframe data modification constraints. So we are virtualizing at backend layer. User will test User Interface and some user will test webservice call using my back end virtual service.

  • 12.  Re: Stateful virtualization of MQ services

    Posted Nov 21, 2015 04:23 AM

    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...