Service Virtualization

Hi Kevin Kevin.Bowman,

DevTest Solutions 9.5.1:Getting "MQRC_UNKNOWN_OBJECT_NAME" error intermittently when I am using ReplyToQueueManager option in "NativeMQ" step. 

As per my analysis, when VS is unable to resolve "Operation Name" I am getting following error. Do you think MQ is causing this error because I am not putting any message(Response for Unknown Conversational Request -->The request failed to produce a response for the virtual service to reply with.) in ReplyToQueue?

Error Message:     Error opening queue <<QueueManagerName>>/<<QueueName>> with options 10256, Completion Code 2 (MQCC_FAILED), Reason Code 2085 (MQRC_UNKNOWN_OBJECT_NAME)

Thanks,

Narasimha.

I need more details on every sentence in your post.

> DevTest Solutions 9.5.1:Getting "MQRC_UNKNOWN_OBJECT_NAME" error intermittently

Does this mean the exact same replyto information works sometimes but not other times?

> ReplyToQueueManager option in "NativeMQ" step.

> VS is unable to resolve "Operation Name"

What exactly do you mean by these?

> I am not putting any message(Response for Unknown Conversational Request -->The request failed to produce a response for the virtual service to reply with.) 

Are you trying to say you did not send a request message?  I am very confused at this point.

> Error Message: Error opening queue <<QueueManagerName>>/<<QueueName>> with options 10256, Completion Code 2 (MQCC_FAILED), Reason Code 2085 (MQRC_UNKNOWN_OBJECT_NAME)

What is "<<QueueManagerName>>/<<QueueName>>"?  Is that the actual format that the error message takes, with both the queue manager name and queue name in there, separated by a slash?  That should just be the queue name in that error message. 

Thanks Kevin. Kindly look into my inline comments.

Thanks,

Narasimha.

I don't seen any inline comments?

However, looking at your screenshots I have a few questions:

 - Why are you doing replyTo the hard way?  By default the replyTo queue manager and replyTo queue should be handled automatically.  You shouldn't have to do things manually the way you're doing them.

 - Why are you using the "<queue manager>/<queue"> format for the queue name instead of just using the separate 'Override Queue Manager' field for the queue manager name?  The purpose of that field is to allow you to specify a queue that's on a different queue manasger.

 - When the VS receives a request that does not match any transaction, does that request actually contain replyTo information?

Sorry Kevin, I have attached the email with my inline comments.

- Why are you doing replyTo the hard way?  By default the replyTo queue manager and replyTo queue should be handled automatically.  You shouldn't have to do things manually the way you're doing them.

Narasimha: In Respond step I don't find "Automatic"  option under "ReplyTo Queue" drop down( Where as in "Native SendReceive" step this option is available) and more over  VS is throwing error if I don't select any value for "Put Queue" or If I don't mention the Override Queue Manager Name

 - Why are you using the "<queue manager>/<queue"> format for the queue name instead of just using the separate 'Override Queue Manager' field for the queue manager name?  The purpose of that field is to allow you to specify a queue that's on a different queue manasger.

 Narasimha: I will make this change Kevin.

 - When the VS receives a request that does not match any transaction, does that request actually contain replyTo information?

 Narasimha: Yes, request is having replyTo queue details though source system is sending incorrect request(Operation name).

Thanks for your assistance.

Narasimha.

Okay, so I can't read your attachment.  Can you just paste the answers through the forum?  Email doesn't seem to be working so well.

> In Respond step I don't find "Automatic" option under "ReplyTo Queue" drop down

The 'ReplyTo Queue' field on the Respond step controls the ReplyTo header field that is sent with the *response* message.  99% of the time you will not need to send a ReplyTo header in your response message.

The parameter governing the behavior of ReplyTo in the Respond step is the 'Ignore ReplyTo' field, which is set to 'No' by default:

> Yes, request is having replyTo queue details though source system is sending incorrect request(Operation name).

Can I go back to the error message you mentioned?

> Error Message: Error opening queue <<QueueManagerName>>/<<QueueName>> with options 10256, Completion Code 2 (MQCC_FAILED), Reason Code 2085 (MQRC_UNKNOWN_OBJECT_NAME)

What is the exact contents of the error message, specifically, the part you seem to have replaced with <<...>>?  Does that contain the actual name of a queue and queue manager, or does it contain "{{lisa.ibmmq.Recv.MQMD.ReplyToQueueName}}"?  If it's the latter, and you have the 'Quiet' checkbox on your 'Listen' step unchecked, then the request did not have a replyTo value.

If it's former and it's the actual name of a queue, then the error is telling you the queue or the queue manager cannot be found by that name.  Do other request messages with correct operation names use that exact same replyTo information?  Or is that replyTo information only used by the requests with the wrong operation name? 

Are you using temporary queues for your response queues?

Hi Kevin,

Please find my inline comments.

> DevTest Solutions 9.5.1:Getting "MQRC_UNKNOWN_OBJECT_NAME" error intermittently

Does this mean the exact same replyto information works sometimes but not other times?

Narasimha: Yes Kevin, VS is failing with the above issue for one transaction out of 1000 transactions

> ReplyToQueueManager option in "NativeMQ" step.

> VS is unable to resolve "Operation Name"

What exac:tly do you mean by these?

Narasimha: VSI is unable to match the incoming request with Match Tolerance Type as “Operation During “Virtual Service Image Response Selection” step. I have created VS using RR pair and the recorded operation name in the request is different from the actual operation name in the request.

Ex: Operation name during VS creation(as per sample RR pair) is “OutboundPaymentRequest”  and Operation name during playback mode is “OutboundPaymentResponse” (in the incoming request)

 > I am not putting any message(Response for Unknown Conversational Request -->The request failed to produce a response for the virtual service to reply with.) 

Are you trying to say you did not send a request message?  I am very confused at this point.

Narasimha: I can’t replicate this in ITR as I explained above(Getting error once out of 1000 times). I have attached Inspection view details below.  

> Error Message: Error opening queue <<QueueManagerName>>/<<QueueName>> with options 10256, Completion Code 2 (MQCC_FAILED), Reason Code 2085 (MQRC_UNKNOWN_OBJECT_NAME)

What is "<<QueueManagerName>>/<<QueueName>>"?  Is that the actual format that the error message takes, with both the queue manager name and queue name in there, separated by a slash?  That should just be the queue name in that error message. 

Narasimha: This conversation is synchronous hence I have used “ReplyToQueueManager” option. And the reply to queue is available on different queue manager. Hence to override this I have mentioned queue manager in the queue name. And this is working fine absolutely and I can see the VS responses reaching the source system.

> In Respond step I don't find "Automatic" option under "ReplyTo Queue" drop down

The 'ReplyTo Queue' field on the Respond step controls the ReplyTo header field that is sent with the *response* message.  99% of the time you will not need to send a ReplyTo header in your response message.

 Narasimha: VS is failing if I don't select any queue name under "Put Queue" drop down. 

In Listen step I have unchecked "Asynchronous" option and in Respond step I have selected "No" for IgnoreReplyToQueue.

I have not selected any queue for "Reply To Queue" in Respond step. However it is working fine

I have selected queue for "Reply To Queue" in Respond step and this option is also working fine

The parameter governing the behavior of ReplyTo in the Respond step is the 'Ignore ReplyTo' field, which is set to 'No' by default:

> Yes, request is having replyTo queue details though source system is sending incorrect request(Operation name).

Can I go back to the error message you mentioned?

> Error Message: Error opening queue <<QueueManagerName>>/<<QueueName>> with options 10256, Completion Code 2 (MQCC_FAILED), Reason Code 2085 (MQRC_UNKNOWN_OBJECT_NAME)

What is the exact contents of the error message, specifically, the part you seem to have replaced with <<...>>?  Does that contain the actual name of a queue and queue manager, or does it contain "{{lisa.ibmmq.Recv.MQMD.ReplyToQueueName}}"?  If it's the latter, and you have the 'Quiet' checkbox on your 'Listen' step unchecked, then the request did not have a replyTo value.

Narasimha: "<< >>" it contains original queue name and in listen step under Reply to Mappings tab it looks something like below

Do you think this is because of the different Channel names? All these are the default channel names populated by DevTest when I created VS using RR pair

If it's former and it's the actual name of a queue, then the error is telling you the queue or the queue manager cannot be found by that name.  Do other request messages with correct operation names use that exact same replyTo information?  Or is that replyTo information only used by the requests with the wrong operation name? 

Narasimha: All requests are using the same 'replyToQueue Information' and for other requests it is absolutely working fine. I can see the VS response in source system.

And to just find the issue I have created a new VS with multiple RR pair one is having operation names as "OutboundPaymentRequest" and "OutboundPaymentResponse". Interestingly, I don't see any MQ errors and VS is responding to all the requests (including requests having operation name as "OutboundPaymentResponse" because VSI is having 2 instances one with Match Tolerance type Operation named  "OutboundPaymentRequest" and other as "OutboundPaymentResponse")

Are you using temporary queues for your response queues?

Narasimha: These are not temporary queues Kevin.

Thanks a lot for your time.

Narasimha.

I still don't understand why you're doing things the hard way.  As far as I can tell this is a normal replyTo scenario. 

You do have to put *something* in the Respond step's 'Put Queue' field.  But that selection doesn't matter if replyTo is being used.  If your request message contains replyTo information, and you have left everything else in the VSM and VSI alone, then that replyTo information should take precedence and get used by the Respond step automatically.  You should not have to do all the manual things you're doing.  Even in 9.5.1 this should work.

Can you check your service image?  Make sure your response meta-data either does not contain a property called 'ignoreReplyTo', or its value is set to 'false'.  Check this for both your regular transactions and the 'Unknown Request' transaction.

Can you try creating a Temp Queue asset and using as both the Listen step -> ReplyTo Mapping selection and the Respond step -> Put Queue selection?  This does not mean your service will respond to a temporary queue; like I said, this should be overridden by the request's replyTo information.

> All requests are using the same 'replyToQueue Information' and for other requests it is absolutely working fine.

Just so I'm absolutely sure, and I probably should have asked this more clearly from the beginning: You're saying that all requests contain the exact same replyTo information, even the ones with the wrong operation name?  And trying to send a response to this exact same queue works 99.9% of the time and fails 0.1% of the time?  Are the requests with the wrong operation name also 1 in 1000, or do they happen more often and some of them work?

Hi Kevin,

Kindly find my inline comments.

I still don't understand why you're doing things the hard way.  As far as I can tell this is a normal replyTo scenario. 

Narasimha: I have mentioned queue manager name under "Override Queue Manager" and it's(replyToQueue) working fine

You do have to put *something* in the Respond step's 'Put Queue' field.  But that selection doesn't matter if replyTo is being used.  If your request message contains replyTo information, and you have left everything else in the VSM and VSI alone, then that replyTo information should take precedence and get used by the Respond step automatically.  You should not have to do all the manual things you're doing.  Even in 9.5.1 this should work.

Can you check your service image?  Make sure your response meta-data either does not contain a property called 'ignoreReplyTo', or its value is set to 'false'.  Check this for both your regular transactions and the 'Unknown Request' transaction.

Narasimha: 'ignoreReplyTo' option is not available in VSI.

Can you try creating a Temp Queue asset and using as both the Listen step -> ReplyTo Mapping selection and the Respond step -> Put Queue selection?  This does not mean your service will respond to a temporary queue; like I said, this should be overridden by the request's replyTo information.

Narasimha: tried and working fine

> All requests are using the same 'replyToQueue Information' and for other requests it is absolutely working fine.

Just so I'm absolutely sure, and I probably should have asked this more clearly from the beginning: You're saying that all requests contain the exact same replyTo information, even the ones with the wrong operation name?  And trying to send a response to this exact same queue works 99.9% of the time and fails 0.1% of the time?  Are the requests with the wrong operation name also 1 in 1000, or do they happen more often and some of them work

Narasimha: I am getting this error for all requests coming with incorrect Operation Name.

Thanks,

Narasimha

I still don't see an answer to whether the requests that have the wrong operation name have exactly the same ReplyTo information as other requests. 

Hi Kevin,

I can’t see(Inspection view doesn’t show these details and I can’t run the VS in ITR) ReplyToQueue details as the probability is 1 out of 1000 requests. However, when I create a VS with multiple RR pair VS is not throwing any error and working as expected.

Operation1: RiskValueRequest

Operation2: RiskValueResponse(Probability is 1 out of 1000 requests)

Thanks,

Narasimha.

Can you find see the requests' meta-data in the vse log for that service? 

After all this I'm still not entirely sure I understand the problem.  We might be at the limit of what I can do for you over the forums without an official support case.