| Author |
Message
|
| EricCox |
 Posted: Thu Sep 21, 2017 10:00 am Post subject: IIB Overwriting OutputRoot.MQMD.ReplyToQM |
 |
|
Master
Joined: 08 Apr 2011
Posts: 292
|
To all,
MY ESQL is setting the MQMD correctly but then the MQ Output Node tries to send the message to the local QM rather than the one I previously set in the MQMD via ESQL.
Can someone assist me with what I'm missing. How can I get IIB to stop overwriting what I've set in ESQL successfully.
Here is the trace. The Output Node is set to Dest List. I tried ReplyToQ but that didn't work. The ESQL is working to set MQMD without error, but then IIB overwrites.
All help is greatly appreciated.
Thanks,
Eric |
|
| Back to top |
|
 |
| Vitor |
| Posted: Thu Sep 21, 2017 10:26 am Post subject: Re: IIB Overwriting OutputRoot.MQMD.ReplyToQM |
|
|
Grand High Poobah
Joined: 11 Nov 2005
Posts: 26093
Location: Texas, USA
|
| EricCox wrote: |
| Here is the trace. |
No it isn't
| EricCox wrote: |
MY ESQL is setting the MQMD correctly but then the MQ Output Node tries to send the message to the local QM |
On v9 and below, functioning as designed. on v10, potentially functioning as configured.
Your subject line talks about OutputRoot.MQMD.ReplyToQM, and your post talks about a destination list. So are you trying to send a message to a list of recipients, the ReplyToQM or a list of recipients with a specific ReplyToQM that's not the IIB queue manager?
_________________
Honesty is the best policy.
Insanity is the best defence. |
|
| Back to top |
|
|
| EricCox |
| Posted: Thu Sep 21, 2017 11:11 am Post subject: Trace |
|
|
Master
Joined: 08 Apr 2011
Posts: 292
|
Right, I'm trying to set the ReplyToQ and MQMD.ReplyToQMgr to what was sent in by the service consumer. You can see the trace output here that shows the ESQL is setting the MQMD properties the way I want.
But then immediately after that you see it try to use QMBKRS12 instead of what is shown in the trace output as QMOLBD98.
I am setting properties for MQ Output Node ReplyToQ Dest Mode and DestinationList mode with the properties setting in ESQL ok and both methods are failing by being overwritten.
(0x03000000:NameValue):ReplyToQ = 'IWD.CUST.INQ.RS ' (CHARACTER)
(0x03000000:NameValue):ReplyToQMgr = 'QMOLBD98 ' (CHARACTER)
(0x03000000:NameValue):UserIdentifier = 'n016438 ' (CHARACTER)
(0x03000000:NameValue):AccountingToken = X'160105150000007c16855dfd6a6f8f61107bbb0fa4020000000000000000000b' (BLOB)
(0x03000000:NameValue):ApplIdentityData = ' ' (CHARACTER)
(0x03000000:NameValue):PutApplType = 11 (INTEGER)
(0x03000000:NameValue):PutApplName = ':\Programs\ih03\rfhutilc.exe' (CHARACTER)
(0x03000000:NameValue):PutDate = DATE '2017-09-21' (DATE)
(0x03000000:NameValue):PutTime = GMTTIME '18:16:46.640' (GMTTIME)
(0x03000000:NameValue):ApplOriginData = ' ' (CHARACTER)
(0x03000000:NameValue):GroupId = X'000000000000000000000000000000000000000000000000' (BLOB)
(0x03000000:NameValue):MsgSeqNumber = 1 (INTEGER)
(0x03000000:NameValue):Offset = 0 (INTEGER)
(0x03000000:NameValue):MsgFlags = 0 (INTEGER)
(0x03000000:NameValue):OriginalLength = -1 (INTEGER)
)
)
'' from trace node 'getCustomerInfoForOLB.Trace'.
The trace node 'getCustomerInfoForOLB.Trace' has output the specified trace data.
This is an information message provided by the message flow designer. The user response will be determined by the local environment.
2017-09-21 14:16:46.842824 6994 UserTrace BIP4067I: Message propagated to output terminal for trace node 'getCustomerInfoForOLB.Trace'.
The trace node 'getCustomerInfoForOLB.Trace' has received a message and is propagating it to any nodes connected to its output terminal.
No user action required.
2017-09-21 14:16:46.842852 6994 UserTrace BIP11303I: A Parser of type ''MQROOT'' has been created at address ''0x12cb65c10''. This thread now has ''25'' cached parsers.
2017-09-21 14:16:46.843004 6994 UserTrace BIP7945I: A message is being processed in node ''getCustomerInfoForOLB.MQ Output'', with the following attributes derived from the policy at '''': ''destinationQueueManagerName: QMBKRS12, connection: SERVER, logLabel: getCustomerInfoForOLB.MQ Output'', and the following attributes derived from the local environment ''queueManagerName: QMOLBD98 , queueName: IWD.CUST.INQ.RS ''.
Each message processed by the node might use different attributes derived from a policy or the local environment. This message records the attribute values that are used for a specific message.
No user action required.
2017-09-21 14:16:47.843568 6994 UserTrace BIP13032E: Failed to open WebSphere MQ queue ''IWD.CUST.INQ.RS ''.
Failed to open WebSphere MQ queue ''IWD.CUST.INQ.RS '' on queue manager ''QMBKRS12'' because of reason code ''2087''. |
|
| Back to top |
|
|
| Vitor |
| Posted: Thu Sep 21, 2017 12:19 pm Post subject: Re: Trace |
|
|
Grand High Poobah
Joined: 11 Nov 2005
Posts: 26093
Location: Texas, USA
|
Ok, maybe it's been a long day but I'm not getting this at all. Allow me to step through my confusion.
| EricCox wrote: |
| Right, I'm trying to set the ReplyToQ and MQMD.ReplyToQMgr to what was sent in by the service consumer. |
This doesn't immediately make sense. Why would you set the reply parameters? Normally you'd use them to reply. I don't understand the objective here.
| EricCox wrote: |
| You can see the trace output here that shows the ESQL is setting the MQMD properties the way I want. |
I see the MQMD ReplyToQ parameters set to IWD.CUST.INQ.RS on QMOLBD98. Let's gloss over the requirement for a moment.
| EricCox wrote: |
| But then immediately after that you see it try to use QMBKRS12 instead of what is shown in the trace output as QMOLBD98. |
Yeah....this is where I really lose the plot.....
| EricCox wrote: |
| I am setting properties for MQ Output Node ReplyToQ Dest Mode and DestinationList mode with the properties setting in ESQL ok and both methods are failing by being overwritten. |
The MQOutput node has 3 modes: QueueName (the node property from design time or a deploy override); ReplyToQ (the reply values in the MQMQ); DestinationList (the values specified in a LocalEnvironment tree passed to the node). I absolutely do not understand how you're setting ReplyToQ dest mode and DestinationList mode simultaneously.
| EricCox wrote: |
2017-09-21 14:16:46.843004 6994 UserTrace BIP7945I: A message is being processed in node ''getCustomerInfoForOLB.MQ Output'', with the following attributes derived from the policy at '''': ''destinationQueueManagerName: QMBKRS12, connection: SERVER, logLabel: getCustomerInfoForOLB.MQ Output'', and the following attributes derived from the local environment ''queueManagerName: QMOLBD98 , queueName: IWD.CUST.INQ.RS ''.
Each message processed by the node might use different attributes derived from a policy or the local environment. This message records the attribute values that are used for a specific message.
No user action required.
2017-09-21 14:16:47.843568 6994 UserTrace BIP13032E: Failed to open WebSphere MQ queue ''IWD.CUST.INQ.RS ''.
Failed to open WebSphere MQ queue ''IWD.CUST.INQ.RS '' on queue manager ''QMBKRS12'' because of reason code ''2087''. |
Ok, now the plot thickens. In addition to using both ReplyTo and DestinationList, you also appear to have an MQEndpoint policy attached to this poor MQOutput node, which seems to be the cause of your woes:
| Code: |
| with the following attributes derived from the policy at '''': ''destinationQueueManagerName: QMBKRS12, connection: SERVER, logLabel: getCustomerInfoForOLB.MQ Output'' |
So the output node is following policy, trying to use QMBKRS12 as a destination queue manager and going bang because it's an unknown remote queue manager (I'd guess because it's not that remote - IIB is sitting on it!)
So what exactly is going on here? How and why are you setting these values? Why have you got an Endpoint policy naming a locally bound queue manager? How much caffeine do I need to drive home safely???
_________________
Honesty is the best policy.
Insanity is the best defence. |
|
| Back to top |
|
|
| mqjeff |
| Posted: Fri Sep 22, 2017 3:59 am Post subject: Re: Trace |
|
|
Grand Master
Joined: 25 Jun 2008
Posts: 17447
|
| Vitor wrote: |
| How much caffeine do I need to drive home safely??? |
Ooeer. Lookit tha optimism!
_________________
chmod -R ugo-wx / |
|
| Back to top |
|
|
| Vitor |
| Posted: Fri Sep 22, 2017 4:11 am Post subject: Re: Trace |
|
|
Grand High Poobah
Joined: 11 Nov 2005
Posts: 26093
Location: Texas, USA
|
| mqjeff wrote: |
| Vitor wrote: |
| How much caffeine do I need to drive home safely??? |
Ooeer. Lookit tha optimism! |
_________________
Honesty is the best policy.
Insanity is the best defence. |
|
| Back to top |
|
|
| EricCox |
| Posted: Fri Sep 22, 2017 4:47 am Post subject: Confusion |
|
|
Master
Joined: 08 Apr 2011
Posts: 292
|
There was mass of confusion. Our delivery team deployed multiple copies of the same flow on WMB8 and IIB using the same QM.
And I was missing the correct ESQL for QM and switching Dest List or ReplyToQ Dest Mode. Once the confusion of the multiple deployed flows the haze cleared.
Thanks for the sanity check.
Much appreciated. |
|
| Back to top |
|
|
| Vitor |
| Posted: Fri Sep 22, 2017 4:51 am Post subject: Re: Confusion |
|
|
Grand High Poobah
Joined: 11 Nov 2005
Posts: 26093
Location: Texas, USA
|
| EricCox wrote: |
| There was mass of confusion. |
At this end as well.
| EricCox wrote: |
| Thanks for the sanity check. |
Now that's something I don't hear often.
_________________
Honesty is the best policy.
Insanity is the best defence. |
|
| Back to top |
|
|
|
|
