Author |
Message
|
lancelotlinc |
Posted: Mon May 03, 2010 10:37 am Post subject: Question: How to specify MQMD/Expiry from JCN. |
|
|
 Jedi Knight
Joined: 22 Mar 2010 Posts: 4941 Location: Bloomington, IL USA
|
Hello there. First I'd like to say how much I appreciate this forum. Great answers and great discussion.
I've been trying for a day now to set the expiry on an MQ message. My flow is pretty simple:
MQInput -> Java Compute -> MQOutput.
In my JCN, I have tried this code:
Code: |
outMessage.getRootElement().evaluateXPath("MQMD/Expiry[set-value('30000')]");
|
When viewing the output from a trace node located just after the JCN, this is what I see:
Code: |
(0x01000000:Name):MQMD = ( ['MQHMD' : 0xe23ee8]
(0x03000000:NameValue):SourceQueue = 'XYZ.IN' (CHARACTER)
(0x03000000:NameValue):Transactional = TRUE (BOOLEAN)
(0x03000000:NameValue):Encoding = 546 (INTEGER)
(0x03000000:NameValue):CodedCharSetId = 1208 (INTEGER)
(0x03000000:NameValue):Format = 'MQSTR ' (CHARACTER)
(0x03000000:NameValue):Version = 2 (INTEGER)
(0x03000000:NameValue):Report = 0 (INTEGER)
(0x03000000:NameValue):MsgType = 8 (INTEGER)
(0x03000000:NameValue):Expiry = -1 (INTEGER)
(0x03000000:NameValue):Feedback = 0 (INTEGER)
|
indicating that the Expiry value did not change. (Also the message flow does not throw an error, so I assume that the evaluateXpath statement did not either.)
Would greatly appreciate your assistance on this one.
Sincerely,
lancelotlinc
 |
|
Back to top |
|
 |
Karan |
Posted: Mon May 03, 2010 11:18 am Post subject: |
|
|
Apprentice
Joined: 21 Oct 2009 Posts: 29
|
I think you can use new Integer() in java and then add the object created in set value function |
|
Back to top |
|
 |
lancelotlinc |
Posted: Mon May 03, 2010 11:28 am Post subject: |
|
|
 Jedi Knight
Joined: 22 Mar 2010 Posts: 4941 Location: Bloomington, IL USA
|
Thanks for your response Karan. Maybe I should explain further. The issue is not creating a new Integer, but the problem is the evaluateXPath function fails to properly set the MQMD.Expiry value.
If you have any other ideas, please let me know. Still looking for an answer. Have tried 30000 with and without quotes. Either way, the evaluateXPath function does not throw an error, but the resulting MQMD.Expiry value is -1.
The correct result of the call should set the MQMD.Expiry value to 30000, which is 3000 seconds, or 50 minutes. At present, this function does not change the existing MQMD.Expiry value from -1, which is no expiry. We want the messages to expire after 50 minutes. |
|
Back to top |
|
 |
fjb_saper |
Posted: Mon May 03, 2010 11:34 am Post subject: |
|
|
 Grand High Poobah
Joined: 18 Nov 2003 Posts: 20756 Location: LI,NY
|
Have you double checked the syntax of your evaluateXpath method? (see infocenter)
I seem to remember that the square brackets are not actually used in the code, they represent an optional feature... and I thought there was a "?" missing somewhere there...  _________________ MQ & Broker admin |
|
Back to top |
|
 |
lancelotlinc |
Posted: Mon May 03, 2010 11:47 am Post subject: |
|
|
 Jedi Knight
Joined: 22 Mar 2010 Posts: 4941 Location: Bloomington, IL USA
|
Hi fjb - yes, I have. Thanks for asking, great question.
Here is the statement just prior to the Expiry, which this statement sets the queuename in the destination list, and it works fabulously.
Code: |
localEnv.getRootElement().evaluateXPath("?Destination[1]/?MQ[1]/?DestinationData[1]/?queueName[1][set-value('"+s+"')]");
|
The above statement works, setting the queuename. The expiry statement does not work and does not throw and exception.
Anyone have any more ideas? |
|
Back to top |
|
 |
Karan |
Posted: Mon May 03, 2010 12:03 pm Post subject: |
|
|
Apprentice
Joined: 21 Oct 2009 Posts: 29
|
Try this way
Traverse to MQMD->Expiry . Store this as MbElement say e. And use e.setValue(object) where the object is created using new Integer(i) where i is an int. |
|
Back to top |
|
 |
Esa |
Posted: Tue May 04, 2010 2:31 am Post subject: |
|
|
 Grand Master
Joined: 22 May 2008 Posts: 1387 Location: Finland
|
outMessage.getRootElement().getFirstElementByPath("MQMD").evaluateXPath("Expiry[set-value(30000)]"); |
|
Back to top |
|
 |
zpat |
Posted: Tue May 04, 2010 2:45 am Post subject: |
|
|
 Jedi Council
Joined: 19 May 2001 Posts: 5866 Location: UK
|
Do it the easy way, pass the message through a MQHeader node and just set the value you want for Expiry.  |
|
Back to top |
|
 |
lancelotlinc |
Posted: Tue May 04, 2010 5:05 am Post subject: |
|
|
 Jedi Knight
Joined: 22 Mar 2010 Posts: 4941 Location: Bloomington, IL USA
|
For Karan and Esa, both of your suggested solutions still had the same result, the Expiry value did not change and no Exceptions were thrown.
For zpat, the MQHeader node does set the value, however, customer business requirement is to vary the Expiry according to a field in a BLOB payload portion of the MQ message. This flow is integrating with existing business processes that use XQ interprocess communication for last 15 years. In the existing system, Expiry values are variable, and customer wants to continue to support that functionality in the new ESB. Customer business requirement is to use JCN not ESQL.
I appreciate all the responses. It appears this is a bug ("feature") of Java Compute Nodes, wherein the Expiry value is unable to be modified by JCNs. Does anyone disagree that this is a bug?
 |
|
Back to top |
|
 |
zpat |
Posted: Tue May 04, 2010 5:08 am Post subject: |
|
|
 Jedi Council
Joined: 19 May 2001 Posts: 5866 Location: UK
|
Using JCN over ESQL is not a business requirement, it is a technical choice.
I can't see the harm in using ESQL (which is often used by the broker internally for example in mapping nodes). |
|
Back to top |
|
 |
lancelotlinc |
Posted: Tue May 04, 2010 5:41 am Post subject: |
|
|
 Jedi Knight
Joined: 22 Mar 2010 Posts: 4941 Location: Bloomington, IL USA
|
Hi zpat,
The business requirement to use Java over other languages was made at the executive level to leverage existing source code base over the last 15 years. Some of the existing source code ports very nicely into JCNs without too much effort. It was part of the ROI value proposition that sold WMB to this client.
For example, the code that decompiles the BLOB was a direct port with zero changes (1000 lines). IBM's sales team represents this as a value add, the ability to use existing source code with little modification when porting functionality into the new ESB architecture. In addition, IBM sales team represents that there are many Java resources available that can easily step into the WMB product and be productive immediately without having to learn a new language. Therefore, you can imagine the edict for using Java.
HTH.
Lance |
|
Back to top |
|
 |
Esa |
Posted: Tue May 04, 2010 6:36 am Post subject: |
|
|
 Grand Master
Joined: 22 May 2008 Posts: 1387 Location: Finland
|
This worked in version 6.1.0.2:
Code: |
MbElement cursor = outMessage.getRootElement().getFirstElementByPath("MQMD");
cursor = cursor.getFirstElementByPath("Expiry");
cursor.setValue(30000); |
So I would say the problem is not with JCN, but with Xpath.
My previous example worked, too, but the value in Expiry was of data type character even when I tried with
Code: |
Expiry[set-value(number(3000))] |
|
|
Back to top |
|
 |
lancelotlinc |
Posted: Tue May 04, 2010 6:54 am Post subject: |
|
|
 Jedi Knight
Joined: 22 Mar 2010 Posts: 4941 Location: Bloomington, IL USA
|
Hi Esa,
I tried this code verbatim and still the Expiry is -1.
We use WebSphere Message Broker Toolkit - Message Broker, Version: 7.0.0, Build id: 7.0.0-20091028_2100.
I noticed several expiry issues for 6.1 in which fix packs were released to address. Maybe another fixpack is needed to correct this problem?
Lance |
|
Back to top |
|
 |
Karan |
Posted: Tue May 04, 2010 8:33 am Post subject: |
|
|
Apprentice
Joined: 21 Oct 2009 Posts: 29
|
MbElement inExpiry=altRoot.getFirstElementByPath("./MQMD/Expiry");
inExpiry.setValue(new Long(30240000)); //Expires after 35 days
This code works fine (Mb 6.0) .
One of the difficulties I had was making the replytoQ and replytoQmngr blank. It was because message type was request-response. But I cant think of any other property that expiry may be dependant on. |
|
Back to top |
|
 |
lancelotlinc |
Posted: Tue May 04, 2010 8:53 am Post subject: |
|
|
 Jedi Knight
Joined: 22 Mar 2010 Posts: 4941 Location: Bloomington, IL USA
|
Hi Karan, thanks for your effort. I really appreciate it.
Your code resulted in this output for me on version 7.0.0:
Code: |
(0x01000000:Name):MQMD = ( ['MQHMD' : 0xe443f8]
(0x03000000:NameValue):SourceQueue = 'aa' (CHARACTER)
(0x03000000:NameValue):Transactional = TRUE (BOOLEAN)
(0x03000000:NameValue):Encoding = 546 (INTEGER)
(0x03000000:NameValue):CodedCharSetId = 1208 (INTEGER)
(0x03000000:NameValue):Format = 'MQSTR ' (CHARACTER)
(0x03000000:NameValue):Version = 2 (INTEGER)
(0x03000000:NameValue):Report = 0 (INTEGER)
(0x03000000:NameValue):MsgType = 8 (INTEGER)
(0x03000000:NameValue):Expiry = -1 (INTEGER)
(0x03000000:NameValue):Feedback = 0 (INTEGER)
(0x03000000:NameValue):Priority = 0 (INTEGER)
(0x03000000:NameValue):Persistence = 0 (INTEGER)
Time: 2010-05-04 11:46:18.839521
|
So, I think this is a JCN bug. Everyone is at the Impact conference today, so when I get the team back together, we will discuss the option of using MQHeader instead as a temporary fix until IBM can patch the JCN.
Reason I think it is JCN and not XPath is the problem still occurs when XPath is not used. I think maybe the JCN is not correctly writing the assembly. While reviewing documentation on WebSphere site, it looks like special consideration/coding is needed when dealing with Expiry since it can be represented as tenths of second or UTC, either one. This may have introduced a bug in version 7 JCN. As you have said, it seems to work in version 6 JCN.
Thanks again.
Lance |
|
Back to top |
|
 |
|