Service Virtualization

Hi  Kevin.Bowman, we are migrating MQ virtual service from IBM MQ Series (Deprecated) to IBM MQ Native.. I am successfully able to develop MQ VS in native method and it works fine.. integrated with SOAP based client and tested too. However, we also need to migrate the existing  MQ VSI (old mq vsi) which was created in previous mq method (i.e., IBM MQ Series) to work with latest new MQ model..  what I have done is pointed to old vsi from new model and copied all data filters which were added in previous model listen step to new model listen step.. Whenever I test it through my soap call, mq service fails and this is the error description I could see in DevTest Server console..

2 AE6E69395A2511E6ACC9E22C20524153 5D62E4815E5211E6A94C005056803F17 5D51F4755E5211E6A94C005056803F17 MQ1 [VS_MQ1_Run] local 1 0 0 1 /home/lisa/lisatmp_8.3.0/lads/5D51F4755E5211E6A94C005056803F17/IBMMQ_native/Configs/LISA4-QUEUE-ST.config     1470761852847 2016-08-09 17:57:32 1470761857339 2016-08-09 17:57:37 false         abort     AE6E693F5A2511E6ACC9E22C20524153     1470761857339     2016-08-09 17:57:37     5D51F4755E5211E6A94C005056803F17     Test Aborted     5D62E4815E5211E6A94C005056803F17     2     0     0                     S         lisa.abort.rsp.time         0         1470761857339                                           Respond     null     1470761857330     2016-08-09 17:57:37     5D51F4755E5211E6A94C005056803F17     IBM MQ Native VSE Respond     5D62E4815E5211E6A94C005056803F17     2     8     0                     S         lisa.Respond.rsp         ============================================================================ | Exception: ============================================================================ | Message:     Value for Sender was null ---------------------------------------------------------------------------- ============================================================================         1470761857338                       S         lisa.Respond.rsp.time         8         1470761857338                                      62         1470761857339         17:57:37         Finished transaction processing         Ending         5D51F4755E5211E6A94C005056803F17                                      Respond : ============================================================================ | Value for Sender was null ============================================================================ | Step:        Respond ---------------------------------------------------------------------------- | Message:     Value for Sender was null ---------------------------------------------------------------------------- | Trapped Exception: Value for Sender was null | Trapped Message:   ============================================================================ | Exception: ============================================================================ | Message:     Value for Sender was null ---------------------------------------------------------------------------- ============================================================================ ---------------------------------------------------------------------------- STACK TRACE ============================================================================ | Exception: ============================================================================ | Message:     Value for Sender was null ---------------------------------------------------------------------------- ============================================================================ at com.itko.lisa.asset.spec.SpecStringPayload.getValueInstance(SpecStringPayload.java:84) at com.itko.lisa.asset.spec.SpecStringPayload.getValueInstance(SpecStringPayload.java:33) at com.itko.lisa.messaging.builder.AbstractMultiSendOperation.getSendOperations(AbstractMultiSendOperation.java:318) at com.itko.lisa.messaging.builder.AbstractMultiSendOperation.doPreEvaluate(AbstractMultiSendOperation.java:360) at com.itko.lisa.asset.operation.AbstractRuntimeOperation.evaluate(AbstractRuntimeOperation.java:80) at com.itko.lisa.asset.operation.AbstractOperationStep.execute(AbstractOperationStep.java:146) at com.itko.lisa.asset.operation.AbstractOperationStep.execute(AbstractOperationStep.java:109) at com.itko.lisa.messaging.vse.AbstractVseRespondStep.execute(AbstractVseRespondStep.java:87) at com.itko.lisa.test.TestNode.executeNode(TestNode.java:981) at com.itko.lisa.test.TestCase.execute(TestCase.java:1280) at com.itko.lisa.test.TestCase.execute(TestCase.java:1195) at com.itko.lisa.test.TestCase.executeNextNode(TestCase.java:1180) at com.itko.lisa.test.TestCase.executeTest(TestCase.java:1124) at com.itko.lisa.coordinator.Instance.run(Instance.java:204) ============================================================================          E          5D51F4755E5211E6A94C005056803F17          1470761857338               

  I think the issue is because of request meta data or response meta data ? but not getting exactly which parameter is causing this issue.. there are close to 50 parameters in meta data section so not sure.. I have attached new MQ VSM, new MQ VSI , old MQ VSI.. You can see new MQ VSI and old MQ VSI responses are 100% same apart from metadata section which is something new mq model generated..

thanks for help

Add the following key/value in the Response meta data & see if your issue is resolved (the key is msg.type, value is java.jms.TextMessage) - I assume your messages are of type TextMessage)

msg.type

javax.jms.TextMessage

Thanks but we process responses as String as per the client

This is not related to the 'msg.type' problem.

The meta-data property your VSI responses are missing is 'channel.name'.  Its value should be 'Response 1' if you generated your IBM MQ Native VSM with the default response channel name.  Otherwise, it should match the channel name used in your VSM's 'Respond' step.

This is fixed in v9.5, so you can run a VSI that's lacking the 'channel.name' meta-data property on its responses and the VSM will just use the first response channel on your 'Respond' step.  It looks like I already made a patch to backport this fix to 8.3.  If you would like that patch then please contact support and ask for the patch on our internal case number 'TA328809'.

Thanks @Kevin_Bowman it worked after manually adding into response parameter.

So by using this patch will it allow us to continue without adding channel name in each response meta data ?

and other question I had to check is .. unlike previous version of MQ , the newer version uses asset and when you deploy, in server console it shows asset name rather than actual queue name... in my case we run the same MQ service on different configs (ex: different queue names as well) so it would be helpful if still be able to see the queue names when running.. or any  other better suggestions to achieve this still ?

> So by using this patch will it allow us to continue without adding channel name in each response meta data ?

Yes.

> in server console it shows asset name rather than actual queue name...

If you leave the asset name blank then by default its displayed name is the queue name.  This works even when you change configs.

You mean which asset name should be blank ? the MQ queue asset names ? if so when we create more queues in the model for different purpose and if we do not specify the asset name of those queues in models then it will be confusing on which to choose.. correct me if I am wrong here..

> You mean which asset name should be blank ? the MQ queue asset names ?

Yes, the 'IBM MQ Native Queue' asset.  The one that actually contains the name of your queue.

> when we create more queues in the model for different purpose and if we do not specify the asset name of those queues in models then it will be confusing on which to choose.. correct me if I am wrong here..

If you're creating assets for queues with different names then there's no problem.  They will have correspondingly different default display names.

However, if you create two assets with the exact same queue name then they will also have the same default display name.  That's not unheard of; you can have the same queue name on different queue managers.  In that case, the only way to tell them apart would be to manually specify names.  Note that when you override an asset in another config you can actually change the manual name as well, although that's usually a recipe for more confusion unless you're careful.

Yes in my case I have same queues across different queue managers .. so in earlier version I can have all these as config property and manage.. I have same queue names for different QM, which creates me problem while creating a asset.. the other reason I dont want to use different name because model is always should be one and should be able deploy across different QM and Channels

Are you aware that you can override assets in the same way you can override config properties?  Open your alternate config and double click on an Asset, or right click and select 'Override'.  You can change the queue name and/or give it a different display name, and those changes only take effect when that alternate config is active.  In your alternate config, assets that are inherited verbatim from the project config are listed in gray, and overridden assets are black.  This should allow you to do whatever you need with alternate configs for the same VSM, and with getting names you recognize to show up in the VSE server console.