| Author |
Message
|
| kimbert |
 Posted: Wed Dec 20, 2006 1:57 pm Post subject: |
 |
|
Jedi Council
Joined: 29 Jul 2003
Posts: 5543
Location: Southampton
|
| Quote: |
| Any suggestions on how to achieve this "dynamic existence" behavior I'm aiming for regarding the embedded message (IOW, sometimes it'll be there, sometimes not, but when it is, it can be either message A, B, C, etc.)? [/b] |
There is a solution, but you will need to write some ESQL to guide the parse.
1. Parse the header
2. If the message identifier is not the empty string,
a) (optional) Work out the message name from the message identifier.
b) CREATE LASTCHILD OF myTreeReference Name 'innerMessage' DOMAIN 'MRM' SET 'myMessageSet' TYPE 'MyMessageName' FORMAT 'myPhysicalFormatName';
You might choose to name your messages so that step a) is not required. If not, you will need to write some ESQL to map message identifiers to message names.
| Quote: |
| Also, the defect you mention... do you mean "product" or "MY code"? |
'product'. That's an internal error. |
|
| Back to top |
|
 |
| Sandman |
| Posted: Thu Dec 28, 2006 5:25 am Post subject: |
|
|
Centurion
Joined: 16 Oct 2001
Posts: 134
Location: Lincoln, RI
|
Thanks kimbert.
So, if I go this route, does that mean I need to undo the Message Identity technique and ALWAYS handle the embedded message (if present) via code?
Also, what is wrong w/ my syntax? (I admitted being an MRM noob  )
| Code: |
CREATE LASTCHILD OF OutputBody.InqPolicy.LOB
DOMAIN 'MRM'
NAME 'innerMessage'
SET 'Amica CWF Message Set'
TYPE 'PolicyAuto'
FORMAT 'CWF1';
|
I get the red X next to the line w/ the SET on it, telling me invalid syntax.
Thank you. |
|
| Back to top |
|
|
| fjb_saper |
| Posted: Thu Dec 28, 2006 3:00 pm Post subject: |
|
|
Grand High Poobah
Joined: 18 Nov 2003
Posts: 20767
Location: LI,NY
|
SET TYPE and FORMAT are fields of the Properties folder for the usage you are trying to make of them....
See the exact appropriate name in the documentation....
You are not doing a CREATE ...PARSE ... and as such cannot use these 3 fields the way you did....
Enjoy 
_________________
MQ & Broker admin |
|
| Back to top |
|
|
| kimbert |
| Posted: Fri Dec 29, 2006 3:01 pm Post subject: |
|
|
Jedi Council
Joined: 29 Jul 2003
Posts: 5543
Location: Southampton
|
| Quote: |
| Also, what is wrong w/ my syntax? |
Very simple. You forgot the PARSE clause. Check the docs or search this forum for an example. |
|
| Back to top |
|
|
| Sandman |
| Posted: Tue Jan 02, 2007 5:41 am Post subject: |
|
|
Centurion
Joined: 16 Oct 2001
Posts: 134
Location: Lincoln, RI
|
| kimbert wrote: |
| Quote: |
| Also, what is wrong w/ my syntax? |
Very simple. You forgot the PARSE clause. Check the docs or search this forum for an example. |
Ah... I wasn't sure, as you also didn't include the PARSE phrase in your reply above. Thank you. I'll fiddle around a bit more. |
|
| Back to top |
|
|
| kimbert |
| Posted: Tue Jan 02, 2007 8:56 am Post subject: |
|
|
Jedi Council
Joined: 29 Jul 2003
Posts: 5543
Location: Southampton
|
|
| Back to top |
|
|
| Sandman |
| Posted: Tue Jan 02, 2007 9:59 am Post subject: |
|
|
Centurion
Joined: 16 Oct 2001
Posts: 134
Location: Lincoln, RI
|
No problem. I really appreciate your help.
Ok, so I'm still toying w/ this CREATE/PARSE syntax.
I let the MQInput node parse my header area. Then, if my embedded message type indicator field (LOB in my case) is not blank, then I want to do the CREATE/PARSE.
But for the target of the CREATE LASTCHILD OF ... what do I specify? Logically, I want "the rest of the bitstream after the part that was already parsed". I tried OutputRoot.MRM.*[<] to no avail.
Thank you. |
|
| Back to top |
|
|
| kimbert |
| Posted: Tue Jan 02, 2007 12:23 pm Post subject: |
|
|
Jedi Council
Joined: 29 Jul 2003
Posts: 5543
Location: Southampton
|
| Quote: |
| But for the target of the CREATE LASTCHILD OF ... what do I specify? Logically, I want "the rest of the bitstream after the part that was already parsed". I tried OutputRoot.MRM.*[<] to no avail. |
Fair question. you are starting a new parse, so unless you say otherwise, the CREATE LASTCHILD...PARSE statement will start from the beginning of the bitstream.
If you don't mind re-parsing the header, you can include a reference to the global element which defines the header in each of the inner message definitions. Otherwise you can parse the message in the BLOB domain and use SUBSTRING to get the part of the bitstream that you need. This might help : http://www.mqseries.net/phpBB2/viewtopic.php?t=21385 |
|
| Back to top |
|
|
| Sandman |
| Posted: Wed Jan 03, 2007 11:55 am Post subject: |
|
|
Centurion
Joined: 16 Oct 2001
Posts: 134
Location: Lincoln, RI
|
I had thought of that (reparsing the whole message again, including the already-parsed header), but thought that would be inefficient. But I guess as long as it's not too big...
If I'm going to do that, could I still use the embedded Message and Message Identity that I already had working (but failed when a message arrived that did not contain an embedded message)? On the MQInput node, specify a message def that is just the header. Then in a Compute node, interrogate my message identity field to see if it's blank. If not, then could I use a RCD node to reparse as the now-known message def? Wouldn't that at least save me coding a CASE statement to handle the "CREATE LAST CHILD..." for each possible instance of embedded message type - one for auto, home, etc.?
Thank you. |
|
| Back to top |
|
|
| kimbert |
| Posted: Thu Jan 04, 2007 2:09 am Post subject: |
|
|
Jedi Council
Joined: 29 Jul 2003
Posts: 5543
Location: Southampton
|
Yes - that would be quite a neat design. If your message identity field is always at the same offset in the bitstream ( or is easily parsed in some other way ) you could parse in the BLOB domain first, extract and check the message identity using a snippet of ESQL, and then either
a) parse the entire message using the Message Identity technique
or
b) parse only the header ( because the Message Identity was empty ). |
|
| Back to top |
|
|
| Sandman |
| Posted: Thu Jan 04, 2007 5:03 am Post subject: |
|
|
Centurion
Joined: 16 Oct 2001
Posts: 134
Location: Lincoln, RI
|
Hmmm... but then would I need to maintain 2 versions of the message header:
1. One that has an embedded message (composition=message) and a message identity field and
2. One that has the field to interrogate as "identity", but not technically defined as such (to stop the parser from trying to search for a message def to go w/ an identity field?
Does that make sense?
Thanks again for your help. |
|
| Back to top |
|
|
| kimbert |
| Posted: Thu Jan 04, 2007 5:49 am Post subject: |
|
|
Jedi Council
Joined: 29 Jul 2003
Posts: 5543
Location: Southampton
|
| Quote: |
| but then would I need to maintain 2 versions of the message header |
No. The parser only cares about Message Identity when it encounters an embedded message in the message model. If you happen to parse a string element which has 'Interpret Value As' set to 'Message Identity', that's OK - even if your model does not contain an embedded message. |
|
| Back to top |
|
|
| Sandman |
| Posted: Thu Jan 04, 2007 6:26 am Post subject: |
|
|
Centurion
Joined: 16 Oct 2001
Posts: 134
Location: Lincoln, RI
|
That's what I had originally tho - a string element w/ "Interpret Value As" set to "Message Identity". I also had - in the message model, but not in the test message - an embedded message defined. And that was causing errors. (Recall, I was hoping to get this to work: "if the test message has an embedded message, then parse according to Identity field, and if it does not, then the Identity field would be blank, so ignore"?)
I'm a bit [more] confused now. |
|
| Back to top |
|
|
| kimbert |
| Posted: Thu Jan 04, 2007 6:58 am Post subject: |
|
|
Jedi Council
Joined: 29 Jul 2003
Posts: 5543
Location: Southampton
|
| Quote: |
| I also had - in the message model, but not in the test message - an embedded message defined. And that was causing errors. |
Of course it was. The input message did not match the message model.
Please re-read my previous post. I did not say that the above scenario would work. I did give you a way to parse your messages by using some ESQL to control the parsing. |
|
| Back to top |
|
|
| Sandman |
| Posted: Thu Jan 04, 2007 7:03 am Post subject: |
|
|
Centurion
Joined: 16 Oct 2001
Posts: 134
Location: Lincoln, RI
|
| Quote: |
| If you happen to parse a string element which has 'Interpret Value As' set to 'Message Identity', that's OK - even if your model does not contain an embedded message. |
Ok, to see if I understand this... I could have a string field as defined above, and "manually" interrogate it to determine if I have an embedded message (not defined as such in message model) to manually parse? If that's the case, I guess the part I don't get is "What would be the purpose of defining the field as "message identity" if I have no plan to allow the parser to automatically parse the embedded message? Couldn't I do all that you've outlined simply w/ a normal string field?
Thank you for your patience. |
|
| Back to top |
|
|
|
|
