Service Virtualization

Hi All,

I have a MQ Virtual service deployed in VSE. I have developed it with IBM MQ Native protocol. The request Queue which it listens have various requests. I want to listen to specific request so that Virtual response can be pushed.

Like in JMS, do we have any message selector to filter out the request from Queue in IBM MQ Native protocol. And if yes, how to achieve it.

Kevin.Bowman Rick.Brown 

I'm not an expert in the differences and similarities between JMS & MQ, but I'm under the impression that message selectors are called "JMS Message Selectors" because they're only valid in JMS. I don't think MQ natively has that concept.

IBM Knowledge Center  seems to agree with me.

In DevTest, using a current MQ VSM (I don't know about the deprecated stuff, because it's deprecated), so long as you're using proxy queues, and DevTest knows where your real queues are, you can put your virtual service in "Dynamic" mode, and write a quick script in the "Virtual Service Router" step, which would scan your request and change mode to "LIVE" or "EFFICIENT" depending on logic you put there. Would that emulate the JMS Message Selector functionality you're after?

Hi Rick,

My request snippet is having a field like this. And I have 3 VS listening on same queue.

<typeOfCar>Skoda</typeOfCar> [other values are GM and Ford for this field]

I want to achieve:

If typeOfCar value is Skoda -> VS 1 should pick the request and respond

If value is GM -> VS 2 should pick the request and respond.

I want to implement above logic. Which protocol and how should i do this? Please help.

There are various ways to do this in DevTest. Personally, I would look at merging all the responses into the VSI, so the selection is done on matching against typeOfCar.

An alternative would be to edit the VSM and add multiple Response Selection steps, a different step called in the workflow depending on the typeOfCar value.

Neither of these mechanisms would require multiple VSMs to listen to the queue.

If we assume that your MQ queue has multiple subscribers, and the multiple subscribers are virtual services that are matching against typeOfCar, I suppose a logical thing to do on a NO_MATCH would be to respond to a dead letter queue, to respond to a temporary queue that has no listener, or even to not respond whatsoever. Using one of these mechanisms, DevTest would be acting like an extended message selection provider, much like how IBM explain the integration bus in the Knowledge Centre article that I linked in my previous response.

Hi Rick,

In our project each VS 1 is having only one response queue. And VS 2 and VS 3 have 2 response queue's. And there will be time when I just want virtual response from VS1 and not from VS2 and VS3 (they should call live backend) by changinf the mode of VS. In this case clubbing aboe scenarios to single VS wont work.

If i want to have 3 VS in VSE listening same queue and want VS1, VS 2 nd VS3 to pick specific request, how should i proceed. What will be the best way to do it.

From your description, I believe all three of your virtual services should run in DYNAMIC mode. Your Virtual Service Execution Router steps should contain a small script to parse typeOfCar and return LIVE or EFFICIENT depending on whether the value of typeOfCar matches the required value.

Some people like to parse the lisa.vse.request object in that step. I prefer to create a request-side Scriptable DPH to grab the typeOfCar argument and use testExec.setStateValue() to store a DevTest property from it that I can query against in the Router step.

My Scriptable DPH would be something like this:

%beanshell%

import com.itko.util.ParameterList;

import com.itko.util.Parameter; //Do I need this for such a simple DPH?

ParameterList args = lisa_vse_request.getArguments();

typeOfCar = args.getParameterValue("complete_argument_path_to_typeOfCar");

testExec.setStateValue("typeOfCar", typeOfCar);

My Virtual Service Execution Router script (for VS1, which wants "Skoda") would have something like this:

import com.itko.lisa.vse.ExecutionMode;

typeOfCar = testExec.getStateString("typeOfCar", "noCar");

if(typeOfCar.equals("Skoda"))

   return executionMode.EFFICIENT;

return executionMode.LIVE;

For the other virtual services, change "Skoda" in the router step for the car that you want to match against. Your virtual services will respond if they are the correct car, or drop through to live if not.

The scripts above haven't been checked for syntax or logic.

Message selectors should fail to respond if there's not a match, but your situation looks different, so I think you'll need to put a bit of thought into the circumstances where no response is made (i.e.: my suggestions above about responding on throwaway queues).

Hi Rick,

Please correct me if understanding is wrong.

With your above approach:

• My 3 VS will run in dynamic mode
• All 3 VS will have Scriptable DPH and VSE Router script to match typeOfCar

So, if I have 3 different independent requests in Queue dropped have typeOfCar field value as:

• typeOfCar = Skoda: then VS1 will pick the request
• typeOfCar = Ford: then VS2 will pick
• typeOfCar = GM: then VS3 will pick

MQ Virtual Service done with: IBM MQ Native protocol - Request Response pairs.

Awaiting your response.

Correct, and I believe it meets your requirement "I just want virtual response from VS1 and not from VS2 and VS3 (they should call live backend)".

Doing it like this, you won't need to worry about "by changinf the mode of VS", because it will happen automatically.

Hi Rick,

Please look this thread where you answered my query for same issue. I need your help to know which way should I follow. The one mentioned above or one mentioned in this link.

Multiple VS listening on same Queue 

The other thread talks about using a proxy virtual service and publishing to MQ in JMS mode to use JMS Message Selectors. I haven't noticed a JMS Message Selector option in the MQ Native listener step (although I didn't look for it, as I don't think it can be done in native MQ - it's one of the reasons for using MQ in JMS mode).

As to which option you choose, try them and see which mechanism works for you.

Hi Rick.Brown

For the other thread: Multiple VS listening on same Queue 

For the Proxy VS - I guess we have to create another proxy queue which first extracts the request from Queue and extracts the paymentMethod value. And re-transfer the request to another proxy Queue with JMS header property.

If my understanding is correct - Could you let me know how to pass the paymentMethod as JMS header property along with original request?