| Author |
Message
|
| rekarm01 |
 Posted: Sat Sep 02, 2017 6:03 pm Post subject: Re: WEBSPHERE MQ WITH IIB User Exit - UNABLE TO MODIFY HEADE |
 |
|
Grand Master
Joined: 25 Jun 2008
Posts: 1415
|
| iibdevYANDEX wrote: |
| Code: |
(0x01000000:Element):Application_Properties = (
(0x03000000:Attribute):testkey = 'testvalue' (CHARACTER)
) |
|
Looking at the rest of the JMSTransport header, the problem could be that "testKey" is an Attribute, when it probably should be an Element:
| Code: |
(0x01000000:Element):Application_Properties = (
(0x01000000:Element):testkey = (
(0x02000000:pcdata): = 'testvalue' (CHARACTER)
)
) |
On a separate matter, the XML domain is deprecated:
| iibdevYANDEX wrote: |
| Code: |
| (0x01000010:ParserRoot):XML = ( ['xml' : 0x7f911024a6c0] |
|
|
|
| Back to top |
|
 |
| mqjeff |
| Posted: Mon Sep 04, 2017 8:15 am Post subject: Re: WEBSPHERE MQ WITH IIB User Exit - UNABLE TO MODIFY HEADE |
|
|
Grand Master
Joined: 25 Jun 2008
Posts: 17447
|
| rekarm01 wrote: |
| iibdevYANDEX wrote: |
| Code: |
(0x01000000:Element):Application_Properties = (
(0x03000000:Attribute):testkey = 'testvalue' (CHARACTER)
) |
|
Looking at the rest of the JMSTransport header, the problem could be that "testKey" is an Attribute, when it probably should be an Element:
| Code: |
(0x01000000:Element):Application_Properties = (
(0x01000000:Element):testkey = (
(0x02000000:pcdata): = 'testvalue' (CHARACTER)
)
) |
|
Does the JMSTransport header support additional, random user defined values, attributes or elements regardless?
Is there some kind of properties element or something that they should be under?
_________________
chmod -R ugo-wx / |
|
| Back to top |
|
|
| iibdevYANDEX |
| Posted: Mon Sep 04, 2017 9:26 pm Post subject: |
|
|
Novice
Joined: 11 Aug 2017
Posts: 14
|
| Quote: |
Looking at the rest of the JMSTransport header, the problem could be that "testKey" is an Attribute, when it probably should be an Element:
|
That's interesting, I did not notice that. I will change to be of type element instead of attribute and see what happens.
Thanks. |
|
| Back to top |
|
|
| iibdevYANDEX |
| Posted: Tue Sep 05, 2017 11:01 pm Post subject: |
|
|
Novice
Joined: 11 Aug 2017
Posts: 14
|
Thank you @rekarm01
That worked for JMS headers! So adding a new element (instead of attribute) and setting its value worked.
However, it still does not work for MQ headers  . My suspicion that both of them were not getting updated because of the same reason turned out to be false. With the MQ header, I am unable to even edit an incoming
MQRFH2/usr/key->value TO MQRFH2/usr/key->newValue |
|
| Back to top |
|
|
| mqjeff |
| Posted: Wed Sep 06, 2017 4:19 am Post subject: |
|
|
Grand Master
Joined: 25 Jun 2008
Posts: 17447
|
You usually have to edit the MQMD on the output message, not on the input message.
It still seems to me to be an odd choice to use an IIB exit instead of a subflow or etc. to handle this conversion.
_________________
chmod -R ugo-wx / |
|
| Back to top |
|
|
| rekarm01 |
| Posted: Wed Sep 06, 2017 5:44 pm Post subject: Re: WEBSPHERE MQ WITH IIB User Exit - UNABLE TO MODIFY HEADE |
|
|
Grand Master
Joined: 25 Jun 2008
Posts: 1415
|
| iibdevYANDEX wrote: |
With the MQ header, I am unable to even edit an incoming
MQRFH2/usr/key->value TO MQRFH2/usr/key->newValue |
Again, it might help to see some code, and some Trace node output, to make sure the MQRFH2 gets constructed correctly. An MQRFH2 header can't have more than one "<usr>" folder, it should probably appear after the statically defined fields, "usr" and "key" should be NAME elements, while "value" and "newValue" should be a VALUE elements.
There are also some constraints on what parts of the message the cciInputMessageCallback function can modify. For example:
| Quote: |
| The user exit code must not update transport headers or Properties elements in this tree. |
That probably doesn't mean MQRFH2 headers, but it may take a PMR to verify that. |
|
| Back to top |
|
|
| mqjeff |
| Posted: Thu Sep 07, 2017 3:49 am Post subject: |
|
|
Grand Master
Joined: 25 Jun 2008
Posts: 17447
|
And you certainly don't need to tell me.
But using an exit, when you could for example just call a C function from ESQL sounds very much like either false optimization or false simplicity.
I.e. too much work for not enough value.
_________________
chmod -R ugo-wx / |
|
| Back to top |
|
|
| iibdevYANDEX |
| Posted: Fri Sep 08, 2017 11:46 am Post subject: |
|
|
Novice
Joined: 11 Aug 2017
Posts: 14
|
Thank you for your responses, everyone. Really appreciate it.
As suggested by @mqjeff, I am now modifying the MQRFH2/usr in MQOutput node. As a first step, I am trying to make sure that I am able to update an incoming key under the MQRFH2/usr/
I have the following flow;
//Reads message from Q1
JMSInput---->Trace1---->JMSOutput (Updates the JMSTransport/Transport_Folders/Application_Properties to add a new key->value)
// Messsage goes out to Q2
// Reads message from Q2
MQInput1----->Trace2---->MQOutput(Updates the incoming messages' key->value to key->newValue)---->Trace3----->File out
// Message goes out to Q3
// Reads message from Q3
MQInput2----->Trace4---->File out
What happens:
* JMSInput receives a message whose header does not have any key->value pairs under application_properties
* Trace node 1 traces the message tree, listed below under "Trace 1". We can see that there is no entries under application_properties
* JMSOutput creates a new key->value pair under application_properties and sends message to "Q2"
* MQInput1 receives a message from Q2
* Trace node 2 traces the message tree, listed below under "Trace 2". We can see the key->value pair created by the JMSOutput node.
* MQOutput updates the key->value to key->newValue and sends message to Q3
* Trace node 3 traces the message tree, listed below under "Trace 3". We can see the key->newValue pair created by the JMSOutput node.
* MQInput2 receives a message from Q3
* Trace node 4 traces the message tree, listed below under "Trace 4". We can see the entry under /MQRFH2/usr is still key->value and not key->newValue.
Trace 1:
| Code: |
(0x01000010:ParserRoot):JMSTransport = ( ['jms_transport' : 0x7ff0281957f0]
(0x01000000:Element):Transport_Folders = (
...
(0x01000000:Element):Header_Values = (
(0x01000000:Element):JMSDestination = (
(0x02000000:pcdata): = 'topic://jms' (CHARACTER)
)
.......
)
(0x01000000:Element):Application_Properties =
(0x01000000:Element):JMS_Provider_Properties = (
(0x01000000:Element):JMS_IBM_Format = (
(0x02000000:pcdata): = 'MQSTR ' (CHARACTER)
)
.....
)
(0x01000000:Element):Standard_Properties = (
(0x01000000:Element):JMSXDeliveryCount = (
...
) |
Trace 2:
| Code: |
(0x01000000:Name):MQRFH2 = ( ['MQHRF2' : 0x7ff02831c4d0]
(0x03000000:NameValue):Version = 2 (INTEGER)
(0x03000000:NameValue):Format = 'MQSTR ' (CHARACTER)
......
(0x01000000:Name ):jms = (
(0x01000000:Name):Dst = (
)
(0x01000000:Name ):usr = (
(0x01000000:Name):key = (
(0x02000000:Value): = 'value' (CHARACTER)
)
)
)
) |
Trace 3:
| Code: |
(0x01000000:Name):MQRFH2 = ( ['MQHRF2' : 0x7ff038178650]
(0x03000000:NameValue):Version = 2 (INTEGER)
(0x03000000:NameValue):Format = 'MQSTR ' (CHARACTER)
...
(0x01000000:Name ):jms = (
(0x01000000:Name):Dst = (
....
(0x01000000:Name ):usr = (
(0x01000000:Name):key = (
(0x02000000:Value): = 'newValue' (CHARACTER)
)
)
)
) |
Trace 4:
| Code: |
(0x01000000:Name):MQRFH2 = ( ['MQHRF2' : 0x7ff0084a38f0]
(0x03000000:NameValue):Version = 2 (INTEGER)
(0x03000000:NameValue):Format = 'MQSTR ' (CHARACTER)
....
(0x01000000:Name ):jms = (
(0x01000000:Name):Dst = (
....
)
(0x01000000:Name ):usr = (
(0x01000000:Name):key = (
(0x02000000:Value): = 'value' (CHARACTER)
)
)
)
) |
Code (Not putting in exception checks for conciseness):
| Code: |
void propagatedCallBack(CciDataContext* userContext,
CciMessage* message,
CciMessage* localEnvironment,
CciMessage* exceptionList,
CciMessage* environment,
CciConnection* connection)
{
updateKeyValue(message)
}
void updateKeyValue(CciMessage* message)
{
int rc = CCI_SUCCESS;
CciElement* root = cniRootElement(&rc, message);
char nodeName[3][32] = {"MQRFH2","usr","key"}
CciElement* element = 0;
for(int i=0; i<3; i++)
{
element = findChildByName(nodeName[i], root);
root = element;
}
CciChar conversionBuf[32];
cciMbsToUcs(&rc, "newValue", conversionBuf, 32, 1208 /*code page*/);
cniSetElementCharacterValue(&rc, root, conversionBuf, 10);
} |
[/code] |
|
| Back to top |
|
|
| mqjeff |
| Posted: Fri Sep 08, 2017 12:25 pm Post subject: |
|
|
Grand Master
Joined: 25 Jun 2008
Posts: 17447
|
Are you sure your User Exit isn't rewriting the value when the MQInput node reads from Q3?
That is, overwriting the value.
_________________
chmod -R ugo-wx / |
|
| Back to top |
|
|
| iibdevYANDEX |
| Posted: Fri Sep 08, 2017 12:33 pm Post subject: |
|
|
Novice
Joined: 11 Aug 2017
Posts: 14
|
| Quote: |
Are you sure your User Exit isn't rewriting the value when the MQInput node reads from Q3?
That is, overwriting the value. |
Yes, I am not doing any processing on input callback. So the "trace 3" is essentially giving the header information that came in from Q3. |
|
| Back to top |
|
|
| rekarm01 |
| Posted: Sat Sep 09, 2017 7:32 pm Post subject: Re: WEBSPHERE MQ WITH IIB User Exit - UNABLE TO MODIFY HEADE |
|
|
Grand Master
Joined: 25 Jun 2008
Posts: 1415
|
| iibdevYANDEX wrote: |
| As suggested by @mqjeff, I am now modifying the MQRFH2/usr in MQOutput node. |
mqjeff's suggestion seemed to be more along the lines of modifying the output message in an ESQL Compute Node, instead of writing a user exit.
| iibdevYANDEX wrote: |
Code (Not putting in exception checks for conciseness):
| Code: |
| void propagatedCallBack(...) |
|
Not putting in the cciRegisterUserExit() calls either. Despite the name, it looks like the function was registered as an output callback. Unfortunately:
| Quote: |
| You can update the message body. However, because this callback is called after the message has been sent to the transport, any changes do not appear in that message. |
So, this:
| iibdevYANDEX wrote: |
| * MQOutput updates the key->value to key->newValue and sends message to Q3 |
should be:
| Quote: |
| * MQOutput sends the message to Q3, and then the user exit updates the key->value to key->newValue |
The update does not appear in "Q3", but does appear in the "Trace3" Trace node, and whatever the "File Out" represents. To see the update in "Q3", it should probably happen in an input callback, not an output callback. |
|
| Back to top |
|
|
| mqjeff |
| Posted: Sun Sep 10, 2017 2:17 pm Post subject: Re: WEBSPHERE MQ WITH IIB User Exit - UNABLE TO MODIFY HEADE |
|
|
Grand Master
Joined: 25 Jun 2008
Posts: 17447
|
| rekarm01 wrote: |
| iibdevYANDEX wrote: |
| As suggested by @mqjeff, I am now modifying the MQRFH2/usr in MQOutput node. |
mqjeff's suggestion seemed to be more along the lines of modifying the output message in an ESQL Compute Node, instead of writing a user exit. |
_________________
chmod -R ugo-wx / |
|
| Back to top |
|
|
| iibdevYANDEX |
| Posted: Mon Sep 11, 2017 9:36 am Post subject: |
|
|
Novice
Joined: 11 Aug 2017
Posts: 14
|
@mqjeff and @rekarm01 - Thank you for the response. I agree that using ESQL with compute nodes is a better way of achieving this. But my constraint is that, I will not have access to modifying the flow. Right now I am testing these things out on my setup where I can change the flow and try out a few things. The flow is customer configured and the only way I am allowed to interact with it is via UserExits.
Here is the registerUserExit code
| Code: |
CCI_UE_VFT vft = {CCI_UE_VFT_DEFAULT};
vft.iFpInputMessageCallback = inputCallBack;
vft.iFpTransactionEventCallback = transactionCallBack;
vft.iFpPropagatedMessageCallback = propagatedCallBack;
vft.iFpNodeCompletionCallback = completionCallBack;
// Convert name to Universal Character Set and register the User exit
int rc = CCI_SUCCESS;
CciChar cciConversionBuffer[256];
cciMbsToUcs(&rc, "sampleUserExit", cciConversionBuffer, 256, 1208 /*code page*/);
exceptionHandler("cciMbsToUcs", rc, __FILE__, __LINE__);
cciRegisterUserExit(&rc, cciConversionBuffer, 0x00, &vft);
exceptionHandler("cciRegisterUserExit", rc, __FILE__, __LINE__); |
I can confirm that the method "propagatedCallBack" is not registered as an output callback. Actually, I have not even registered the output callback in my userExit. |
|
| Back to top |
|
|
| rekarm01 |
| Posted: Mon Sep 11, 2017 6:55 pm Post subject: Re: WEBSPHERE MQ WITH IIB User Exit - UNABLE TO MODIFY HEADE |
|
|
Grand Master
Joined: 25 Jun 2008
Posts: 1415
|
| iibdevYANDEX wrote: |
| I can confirm that the method "propagatedCallBack" is not registered as an output callback. Actually, I have not even registered the output callback in my userExit. |
The described behavior seemed to suggest an output callback, rather than a propagated callback:
| Quote: |
As suggested by @mqjeff, I am now modifying the MQRFH2/usr in MQOutput node.
...
// Reads message from Q2
MQInput1----->Trace2---->MQOutput(Updates the incoming messages' key->value to key->newValue)---->Trace3----->File out
// Message goes out to Q3
...
* MQInput1 receives a message from Q2
* Trace node 2 traces the message tree, listed below under "Trace 2". We can see the key->value pair created by the JMSOutput node.
* MQOutput updates the key->value to key->newValue and sends message to Q3
* Trace node 3 traces the message tree, listed below under "Trace 3". We can see the key->newValue pair created by the JMSOutput node. |
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"? |
|
| Back to top |
|
|
| mqjeff |
| Posted: Tue Sep 12, 2017 3:23 am Post subject: |
|
|
Grand Master
Joined: 25 Jun 2008
Posts: 17447
|
It seems like it needs to be both an input exit and an output exit.
one that can add data to messages after reaching an output node and one that can add data while leaving an input node.
_________________
chmod -R ugo-wx / |
|
| Back to top |
|
|
|
|
