ASG
IBM
Zystems
Cressida
Icon
Netflexity
 
  MQSeries.net
Search  Search       Tech Exchange      Education      Certifications      Library      Info Center      SupportPacs      LinkedIn  Search  Search                                                                   FAQ  FAQ   Usergroups  Usergroups
 
Register  ::  Log in Log in to check your private messages
 
RSS Feed - WebSphere MQ Support RSS Feed - Message Broker Support

MQSeries.net Forum Index » WebSphere Message Broker (ACE) Support » Question: How to specify MQMD/Expiry from JCN.

Post new topic  Reply to topic Goto page 1, 2  Next
 Question: How to specify MQMD/Expiry from JCN. « View previous topic :: View next topic » 
Author Message
lancelotlinc
PostPosted: Mon May 03, 2010 10:37 am    Post subject: Question: How to specify MQMD/Expiry from JCN. Reply with quote

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
View user's profile Send private message Send e-mail
Karan
PostPosted: Mon May 03, 2010 11:18 am    Post subject: Reply with quote

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
View user's profile Send private message
lancelotlinc
PostPosted: Mon May 03, 2010 11:28 am    Post subject: Reply with quote

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
View user's profile Send private message Send e-mail
fjb_saper
PostPosted: Mon May 03, 2010 11:34 am    Post subject: Reply with quote

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
View user's profile Send private message Send e-mail
lancelotlinc
PostPosted: Mon May 03, 2010 11:47 am    Post subject: Reply with quote

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
View user's profile Send private message Send e-mail
Karan
PostPosted: Mon May 03, 2010 12:03 pm    Post subject: Reply with quote

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
View user's profile Send private message
Esa
PostPosted: Tue May 04, 2010 2:31 am    Post subject: Reply with quote

Grand Master

Joined: 22 May 2008
Posts: 1387
Location: Finland

outMessage.getRootElement().getFirstElementByPath("MQMD").evaluateXPath("Expiry[set-value(30000)]");
Back to top
View user's profile Send private message
zpat
PostPosted: Tue May 04, 2010 2:45 am    Post subject: Reply with quote

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
View user's profile Send private message
lancelotlinc
PostPosted: Tue May 04, 2010 5:05 am    Post subject: Reply with quote

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
View user's profile Send private message Send e-mail
zpat
PostPosted: Tue May 04, 2010 5:08 am    Post subject: Reply with quote

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
View user's profile Send private message
lancelotlinc
PostPosted: Tue May 04, 2010 5:41 am    Post subject: Reply with quote

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
View user's profile Send private message Send e-mail
Esa
PostPosted: Tue May 04, 2010 6:36 am    Post subject: Reply with quote

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
View user's profile Send private message
lancelotlinc
PostPosted: Tue May 04, 2010 6:54 am    Post subject: Reply with quote

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
View user's profile Send private message Send e-mail
Karan
PostPosted: Tue May 04, 2010 8:33 am    Post subject: Reply with quote

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
View user's profile Send private message
lancelotlinc
PostPosted: Tue May 04, 2010 8:53 am    Post subject: Reply with quote

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
View user's profile Send private message Send e-mail
Display posts from previous:   
Post new topic  Reply to topic Goto page 1, 2  Next Page 1 of 2

MQSeries.net Forum Index » WebSphere Message Broker (ACE) Support » Question: How to specify MQMD/Expiry from JCN.
Jump to:  



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
Protected by Anti-Spam ACP
 
 


Theme by Dustin Baccetti
Powered by phpBB © 2001, 2002 phpBB Group

Copyright © MQSeries.net. All rights reserved.