| |
|
RSS Feed - WebSphere MQ Support
|
RSS Feed - Message Broker Support
|
| WEBSPHERE MQ WITH IIB User Exit - UNABLE TO MODIFY HEADERS |
« View previous topic :: View next topic » |
| Author |
Message
|
| iibdevYANDEX |
 Posted: Thu Sep 14, 2017 10:01 pm Post subject: |
 |
|
Novice
Joined: 11 Aug 2017
Posts: 14
|
| Quote: |
The propagated callback, as posted, should update the key when propagating the message from the "MQInput1" node to the "Trace2" node, so that the update would also appear in the "Trace2" output.
Unless there is still more un-posted code, that would cause the update to occur at a later point in the message flow. How exactly was the user exit meant to update the key "in the MQOutput node"? |
You are correct, I have not posted the business logic from my callback functions. I have a check in my propagatedCallBack where I retrieve the node type (from connection object) and only try to update the key:value if my node type is MQ Output or JMS Output
Apologies, I should have mentioned this before. |
|
| Back to top |
|
 |
| mqjeff |
| Posted: Fri Sep 15, 2017 3:24 am Post subject: |
|
|
Grand Master
Joined: 25 Jun 2008
Posts: 17447
|
It really doesn't matter, at least AFAIK, what your exit does.
If you want to change any value going TO an *Output node, then you need to also have your exit work as a "input" exit ("propogated?)
Unless you have configured your node to alter the values *leaving* the Trace node.
You might also have configured the *Output nodes to do the wrong thing when sending messages, or the queues it's sending to, such that MQRFH2 headers get turned into message properties, so they don't appear at the JMS input ndoe.
Then your code would have to work with message properties rather than an MQRFH2.
But this is all just guesses, as I've never worked with - or needed to work with - exits.
_________________
chmod -R ugo-wx / |
|
| Back to top |
|
|
| rekarm01 |
| Posted: Mon Sep 18, 2017 7:15 pm Post subject: Re: WEBSPHERE MQ WITH IIB User Exit - UNABLE TO MODIFY HEADE |
|
|
Grand Master
Joined: 25 Jun 2008
Posts: 1415
|
Based on the limited information posted so far, the user exit is successfully updating the MQRFH2 header, just not at the desired point in the message flow.
| iibdevYANDEX wrote: |
| I have not posted the business logic from my callback functions. |
Deciding where in the message flow to update the header is business logic? Regardless, that's the bit of un-posted code that seems to need debugging.
| iibdevYANDEX wrote: |
| I have a check in my propagatedCallBack where I retrieve the node type (from connection object) and only try to update the key:value if my node type is MQ Output or JMS Output |
And that seems like as good a place as any to start. "the" node type? A connection object connects two nodes. It might have been useful to mention whether that check was for the source node or the target node.
| iibdevYANDEX wrote: |
| Apologies, I should have mentioned this before. |
The longer it takes to describe the problem, the longer it takes to resolve. |
|
| Back to top |
|
|
| iibdevYANDEX |
| Posted: Tue Sep 26, 2017 2:00 pm Post subject: |
|
|
Novice
Joined: 11 Aug 2017
Posts: 14
|
Thanks @rekarm01 and @mqjeff
Ok, I will try and explain the problem with a lot of details.
Firstly;
Editing an existing key:value and adding a new key:value in a JMS header "JMSTransport/Transport_Folders/Application_Properties" works great! Thank you @rekarm01 and @mqjeff for your help in getting this to work.
Now coming to MQ nodes, I am unable to see the updated key:value or newly created key:value, once this message (with updated header) is sent to another queue and read from there.
In short, this below is what happens with JMS nodes vs MQ nodes:
JMSInput --> JMSOutput (created/updated new key value in propagate call back) --> Q --> JMSInput1 --> Trace (the new key value created by JMSOutput is visible)
MQInput --> MQOutput (created/updated new key value in propagate call back) --> Q --> MQInput1 --> Trace (the new key value created by MQOutput is NOT visible)
The below image is the flow I am using to debug the issue
[img]https://ibb.co/gaNMDk[/img]
I have tried to name the nodes logically so that the message flow is clear. I've added multiple trace nodes to show the value of the message being passed along to different nodes.
The code related to creating/updating (if key exists) is in the propagatedCallBack. In that method I check if the "target" node type is either "ComIbmJMSClientOutputNode" or "ComIbmMQOutputNode" and update the key value pair in either "JMSTransport/Transport_Folders/Application_Properties" (or)
"MQRFH2/usr/", depending on node type.
Whats happening in a sample run of the flow;
1.) The JMS Output node (To Q1) creates a [key:value] under application_properties of the JMS header and sends it to the queue Q1.
2.) The MQ Input node (Read From Q1) reads the message from Q1. The trace node (Trace Edited Header Sent To Q1) shows the [key:value] that the JMS Output node (To Q1) had created. So far so good.
3.) The MQ Output node (To Q2) updates the [key:value] to [key:newValue] and sends the message to queue (Q2) and also the message gets forwarded in the flow to trace node (Trace Edited Header). The trace displays the updated [key:newValue] that was done by the MQ Output node (To Q2).
4.) The MQ Output node (To Q3) updates the [key:newValue] to [key:newNewValue] and sends the message to queue (Q3)
5.) The MQ Input node (Read From Q2) receives the message from queue (Q2) and forwards the message to trace node (Trace Edited Header sent to Q2). The expected trace should be [key:newValue] but the actual trace is [key:value]
6.) The MQ Input node (Read From Q3) receives the message from queue (Q3) and forwards the message to trace node (Trace Edited Header sent to Q3). The expected trace should be [key:newNewValue] but the actual trace is [key:value]
Below is the output from all the traces:
| Code: |
Trace Unedited Header:
(0x01000010:ParserRoot):JMSTransport = ( ['jms_transport' : 0x7f38c0165e30]
(0x01000000:Element):Transport_Folders = (
(0x01000000:Element):Message_MetaData = (
(0x01000000:Element):PayloadType = (
(0x02000000:pcdata): = 'jms_text' (CHARACTER)
)....
(0x01000000:Element):Application_Properties =
(0x01000000:Element):JMS_Provider_Properties = (
(0x01000000:Element):JMS_IBM_Format = (
(0x02000000:pcdata): = 'MQSTR ' (CHARACTER)
)
------------------------------------------------------------------------------------------
Trace Edited Header Sent To Q1:
( ['MQROOT' : 0x7f38c0642440]
(0x01000000:Name):Properties = ( ['MQPROPERTYPARSER' : 0x7f38c0675650]
(0x03000000:NameValue):MessageSet = '' (CHARACTER)
(0x03000000:NameValue):MessageType = ' ' (CHARACTER)
...)
(0x01000000:Name):MQMD = ( ['MQHMD' : 0x7f38c0685420]
...
(0x03000000:NameValue):OriginalLength = -1 (INTEGER)
)
(0x01000000:Name):MQRFH2 = ( ['MQHRF2' : 0x7f38c068d940]
(0x01000000:Name ):usr = (
(0x01000000:Name):key = (
(0x02000000:Value): = 'value' (CHARACTER)
)
)
)
------------------------------------------------------------------------------------------
Trace Edited Header:
( ['MQROOT' : 0x7f38c0642440]
(0x01000000:Name):Properties = ( ['MQPROPERTYPARSER' : 0x7f38c0675650]
....
)
(0x01000000:Name):MQMD = ( ['MQHMD' : 0x7f38c0685420]
...
(0x03000000:NameValue):OriginalLength = -1 (INTEGER)
)
(0x01000000:Name):MQRFH2 = ( ['MQHRF2' : 0x7f38c068d940]
(0x03000000:NameValue):Version = 2 (INTEGER)
(0x01000000:Name ):usr = (
(0x01000000:Name):key = (
(0x02000000:Value): = 'newValue' (CHARACTER)
)
)
)
------------------------------------------------------------------------------------------
Trace Edited Header Sent To Q2:
( ['MQROOT' : 0x7f38c8362ba0]
(0x01000000:Name):Properties = ( ['MQPROPERTYPARSER' : 0x7f38c8363150]
(0x03000000:NameValue):MessageSet = '' (CHARACTER)
....
)
(0x01000000:Name):MQMD = ( ['MQHMD' : 0x7f38c8046140]
(0x03000000:NameValue):SourceQueue = 'MQOUT' (CHARACTER)
...
)
(0x01000000:Name):MQRFH2 = ( ['MQHRF2' : 0x7f38c8049500]
...
(0x01000000:Name ):usr = (
(0x01000000:Name):key = (
(0x02000000:Value): = 'value' (CHARACTER)
)
)
)
------------------------------------------------------------------------------------------
Trace Edited Header Sent To Q3:
( ['MQROOT' : 0x7f388ea0b9b0]
(0x01000000:Name):Properties = ( ['MQPROPERTYPARSER' : 0x7f388ea19210]
...
)
(0x01000000:Name):MQMD = ( ['MQHMD' : 0x7f388ea0bcc0]
...
)
(0x01000000:Name):MQRFH2 = ( ['MQHRF2' : 0x7f388ea19bf0]
(0x03000000:NameValue):Version = 2 (INTEGER)
...
)
(0x01000000:Name ):usr = (
(0x01000000:Name):key = (
(0x02000000:Value): = 'value' (CHARACTER)
)
)
) |
|
|
| Back to top |
|
|
| mqjeff |
| Posted: Wed Sep 27, 2017 4:13 am Post subject: |
|
|
Grand Master
Joined: 25 Jun 2008
Posts: 17447
|
Again, you have to look closely at how message properties are being handled by the queuemanger/queues in question.
Message properties are usually automatically turned into MQRFH2 headers, but it's easy to set things up so the *aren't*.
This means that your new fields in the output message RFH2 may have been turned into message properties, and then not converted back to RFH2 fields at the getting side.
Use amqsbcg to look at the raw contents of the MQ message.
_________________
chmod -R ugo-wx / |
|
| Back to top |
|
|
| rekarm01 |
| Posted: Wed Sep 27, 2017 6:41 pm Post subject: Re: WEBSPHERE MQ WITH IIB User Exit - UNABLE TO MODIFY HEADE |
|
|
Grand Master
Joined: 25 Jun 2008
Posts: 1415
|
Another possibility is that the message flow with the MQ nodes doesn't detect that the user exit has modified the MQRFH2 header. If so, then the output node would just copy the input bitstream to the output bitstream, and ignore the message tree. Maybe that's why all the callback functions come with a warning:
| Quote: |
| The user exit code must not update transport headers or Properties elements in this tree. |
One way to test that is to have the user exit (or message flow) also modify the message body, and check whether that has the side effect of writing out the modified MQRFH2 header too.
The message flow with the JMS nodes is already modifying the message headers, converting them from MQRFH2 to JMSTransport and back again, so maybe that explains why that message flow also writes out the user exit modifications.
But that's all just a guess. If modifying the message body doesn't yield any useful clues, then it might be time to open a PMR. |
|
| Back to top |
|
|
|
|
|
|
You cannot post new topics in this forum
You cannot reply to topics in this forum
You cannot edit your posts in this forum
You cannot delete your posts in this forum
You cannot vote in polls in this forum
|
|
|
|
