Author |
Message
|
inMo |
Posted: Sat Jun 27, 2009 10:53 am Post subject: JCN equivalent of ESQL InputRoot.BLOB.BLOB |
|
|
 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 |
|
 |
Vitor |
Posted: Sat Jun 27, 2009 12:35 pm Post subject: |
|
|
 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 |
|
 |
inMo |
Posted: Sat Jun 27, 2009 6:04 pm Post subject: |
|
|
 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 |
|
 |
smdavies99 |
Posted: Sat Jun 27, 2009 11:44 pm Post subject: |
|
|
 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 |
|
 |
Vitor |
Posted: Sun Jun 28, 2009 1:07 am Post subject: |
|
|
 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 |
|
 |
Vitor |
Posted: Sun Jun 28, 2009 1:12 am Post subject: |
|
|
 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 |
|
 |
fjb_saper |
Posted: Sun Jun 28, 2009 9:55 am Post subject: |
|
|
 Grand High Poobah
Joined: 18 Nov 2003 Posts: 20756 Location: LI,NY
|
|
Back to top |
|
 |
inMo |
Posted: Mon Jun 29, 2009 9:29 am Post subject: |
|
|
 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 |
|
 |
shanson |
Posted: Tue Jun 30, 2009 12:43 am Post subject: |
|
|
 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 |
|
 |
|