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 » JCN equivalent of ESQL InputRoot.BLOB.BLOB

Post new topic  Reply to topic
 JCN equivalent of ESQL InputRoot.BLOB.BLOB « View previous topic :: View next topic » 
Author Message
inMo
PostPosted: Sat Jun 27, 2009 10:53 am    Post subject: JCN equivalent of ESQL InputRoot.BLOB.BLOB Reply with quote

Master

Joined: 27 Jun 2009
Posts: 216
Location: NY

1000 thanks to anyone that can help. I have to accomplish what I thought was a simple task in a Java Compute Node. The task is to take in a message and add some text to the begining of it.

The incoming format is BLOB as anything can be inside. I need to stamp the begining of the message body with a 10 characters of information. It would be like "NewText + InputRoot.BLOB.BLOB".

I can prepare the NewText as a byte array just fine. My problem is coming when attempting to gather the original message body as a byte array to join with the NewText.

I created a code line that works just fine in the debugger with breakpoints active. However, with no breakpoints this code line always fails:

Code:

MbElement inputRoot  = contact admin.getMessage().getRootElement();
MbElement inputBlob  = inputRoot.getLastChild();
byte[] originalMsgByteArray = (byte[])inputBlob.getLastChild().getValue();

Can anyone provide me an alternative approach to capture the message body? I am really an ESQL guy and thought this woulod take about 15 minutes - but it has been 3 days now
Back to top
View user's profile Send private message
Vitor
PostPosted: Sat Jun 27, 2009 12:35 pm    Post subject: Reply with quote

Grand High Poobah

Joined: 11 Nov 2005
Posts: 26093
Location: Texas, USA

Someone's going to ask why Java & not ESQL, so it might as well be me.

Especially as I've no idea what to say about the Java...
_________________
Honesty is the best policy.
Insanity is the best defence.
Back to top
View user's profile Send private message
inMo
PostPosted: Sat Jun 27, 2009 6:04 pm    Post subject: Reply with quote

Master

Joined: 27 Jun 2009
Posts: 216
Location: NY

First, thank you for responding. Second, I understand your point. The JCN decision was made by parties other then me. If I am able to work this out, the functionality would be targeted for a user-defined java plugin node. So perhaps that is part of the consideration(?)

When you say

Quote:
..I've no idea what to say about the Java...

Are you saying any of the below?

    A) Your code is terrible and I can't even comment on it!
    B) Your code appears reasonable and don't know why it wouldn't work?
    C) Your topic is not at all JCN friendly and I don't know how to approach it.
    D) JCN is just not my thing, hopefully someone else can help you

I am just trying to evaluate if I am up against a mountain of a problem or an unexpected bump in the road
Back to top
View user's profile Send private message
smdavies99
PostPosted: Sat Jun 27, 2009 11:44 pm    Post subject: Reply with quote

Jedi Council

Joined: 10 Feb 2003
Posts: 6076
Location: Somewhere over the Rainbow this side of Never-never land.

inMo wrote:

When you say

Quote:
..I've no idea what to say about the Java...

Are you saying any of the below?

    A) Your code is terrible and I can't even comment on it!
    B) Your code appears reasonable and don't know why it wouldn't work?
    C) Your topic is not at all JCN friendly and I don't know how to approach it.
    D) JCN is just not my thing, hopefully someone else can help you



On behalf of Vitor, let me be the first to say that he has said several (if not many) times on this forum that he known 'nowt about Java'. That is where his comment is based.
_________________
WMQ User since 1999
MQSI/WBI/WMB/'Thingy' User since 2002
Linux user since 1995

Every time you reinvent the wheel the more square it gets (anon). If in doubt think and investigate before you ask silly questions.
Back to top
View user's profile Send private message
Vitor
PostPosted: Sun Jun 28, 2009 1:07 am    Post subject: Reply with quote

Grand High Poobah

Joined: 11 Nov 2005
Posts: 26093
Location: Texas, USA

smdavies99 wrote:
inMo wrote:

When you say

Quote:
..I've no idea what to say about the Java...

Are you saying any of the below?

    A) Your code is terrible and I can't even comment on it!
    B) Your code appears reasonable and don't know why it wouldn't work?
    C) Your topic is not at all JCN friendly and I don't know how to approach it.
    D) JCN is just not my thing, hopefully someone else can help you



On behalf of Vitor, let me be the first to say that he has said several (if not many) times on this forum that he known 'nowt about Java'. That is where his comment is based.




Absolutely d) - taking Java advice from me is like getting bomb disposal tips from a blind man. Silly and potentially dangerous.
_________________
Honesty is the best policy.
Insanity is the best defence.
Back to top
View user's profile Send private message
Vitor
PostPosted: Sun Jun 28, 2009 1:12 am    Post subject: Reply with quote

Grand High Poobah

Joined: 11 Nov 2005
Posts: 26093
Location: Texas, USA

inMo wrote:
FIf I am able to work this out, the functionality would be targeted for a user-defined java plugin node. So perhaps that is part of the consideration(?)


Still staying well clear of this Java stuff (and in many ways playing for time until a Java competant poster turns up), this functionality's a bit odd on the face of it. What happens if the message body was an XML document? Or a JPG?

Even if it's a CWF, all the downstream message models will need to reflect that there's 10 characters of information at the front of the message now. Thereby eliminating the possibility of just importing copybooks or structs (which will only reflect the actual content).

If you've got 10 characters of information to add to a message, why not put it in the RFH2? Using a JCN if that's what The Powers That Be have decided?
_________________
Honesty is the best policy.
Insanity is the best defence.
Back to top
View user's profile Send private message
fjb_saper
PostPosted: Sun Jun 28, 2009 9:55 am    Post subject: Reply with quote

Grand High Poobah

Joined: 18 Nov 2003
Posts: 20756
Location: LI,NY

I see where you are coming from.
Have you looked at the different ways to address the values?
http://publib.boulder.ibm.com/infocenter/wmbhelp/v6r1m0/topic/com.ibm.etools.mft.doc/ac30320_.htm#ac30320_
And remember you have to first build the outmessage before you can prepend or append anything to it...

Have fun
_________________
MQ & Broker admin
Back to top
View user's profile Send private message Send e-mail
inMo
PostPosted: Mon Jun 29, 2009 9:29 am    Post subject: Reply with quote

Master

Joined: 27 Jun 2009
Posts: 216
Location: NY

I continue to work through this and believe I am close to a solution. One of the bigger struggles has been the debugger. I actually get different results at times when using the debugger w/active breakpoints in the Java code then when the code has no active breakpoints. However, that is not the topic of my post.

To answer the question of why? This code would be used to effectively stamp a message for applications that are for one reason or another limited to reading message body. When the message enters the code, we assume it is text-based data (I'm really not sure how a jpg would impact this scenario, so I am ignoring it via this assumption). The code will grab the input blob, capture the stamp, join the 2 byte arrays (FORMAT: Stamp + Input BLOB) and pass the new message on. Participating apps know the first 10 chars represent the stamp.

Any and all WMB broker activity can be done before or after this node. So for the copy books, you could import, work with, and RCD to BLOB prior to this node's use as the last node in a flow. (opinions welcome)
Back to top
View user's profile Send private message
shanson
PostPosted: Tue Jun 30, 2009 12:43 am    Post subject: Reply with quote

Partisan

Joined: 17 Oct 2003
Posts: 344
Location: IBM Hursley

I see what you are doing, but you would better off carrying the stamp somewhere else if you could. If your apps are MQ based, use the MQRFH2 <usr> folder, for example. If your apps are HTTP then use an HTTP header field. You get the idea.

If that's no good, then why not model the stamp+blob as a message in its own right, with two fields, a string of fixed length 10 followed by a hexBinary with Length Units = end of bitstream. You'd need to use MRM CWF for this as TDS does not support Length Units = end of bitstream.

If you wanted to use TDS, so you could treat FORMAT as a tag, then you'd need to include a length field between the stamp and the blob (ie, stamp+length+blob) and specify that the length of the BLOB is given by the length field, using Length Reference property.

With the model approach, your node just builds an MRM owned tree containing the fields, and the MRM parser does the serialisation.
Back to top
View user's profile Send private message
Display posts from previous:   
Post new topic  Reply to topic Page 1 of 1

MQSeries.net Forum Index » WebSphere Message Broker (ACE) Support » JCN equivalent of ESQL InputRoot.BLOB.BLOB
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.