| |
|
RSS Feed - WebSphere MQ Support
|
RSS Feed - Message Broker Support
|
  |
|
| Strange behaviour with MRM and ASBITSTREAM |
« View previous topic :: View next topic » |
| Author |
Message
|
| oli |
 Posted: Tue Nov 22, 2011 2:38 am Post subject: Strange behaviour with MRM and ASBITSTREAM |
 |
|
Acolyte
Joined: 14 Jul 2006
Posts: 68
Location: Germany
|
Hi all,
I have build message flow for testing purposes that shows some strange behavior that I cannot explain. For sure this is not a productive flow. It looks as follows:
MQ Input is configured for MRM domain with corresponding message set, message type and message format. Compute node has the fllowing ESQL code:
| Code: |
BEGIN
DECLARE cc INTEGER;
DECLARE enc INTEGER;
DECLARE theBlob BLOB;
SET OutputLocalEnvironment = InputLocalEnvironment;
CALL CopyEntireMessage();
SET cc = InputRoot.Properties.CodedCharSetId;
SET enc = InputRoot.Properties.Encoding;
SET theBlob = ASBITSTREAM(InputBody, enc, cc);
RETURN TRUE;
END;
|
When looking at the above message flow I would assume that either the Trace Fail node never receives a message or that an infinite loop is produced and the Trace Out node never receives a message.
BUT:
When the Compute node receives the message from the MQ Input node a failure occurs and the message is routed to the failure terminal. The Trace Fail node output with the exception list can be found here: Trace Fail.
Then the message is processed again by the Compute node and now a failure does not occur and the message is routed to the out terminal. The output of the Trace Out node can be found here: Trace Out
I cannot find an explanation for that behavior. Can anybody explain in a few words what happens here?
Thanks, Oli |
|
| Back to top |
|
 |
| kimbert |
| Posted: Tue Nov 22, 2011 5:31 am Post subject: |
|
|
Jedi Council
Joined: 29 Jul 2003
Posts: 5542
Location: Southampton
|
This just shows that it's impossible to predict what users will do with the available features... 
Anyway. it's a valid message flow, for some meanings of 'valid'. so let's analyse what's going on.
- The input node associates the MRM parser with the incoming message. No parsing happens at the input node, unless you forgot to mention that you changed Parse Timing from its default value.
- In the Compute node the environment gets copied. No parsing necessary yet.
- Then the message gets copied from input to output. Still no parsing required, because the message tree has not been looked at.
- Now we get to the ASBITSTREAM function. You have carefully coped CCSID and encoding from InputRoot.Properties but you have not specified SET, TYPE or FORMAT. They will *probably* be picked up from InputRoot.Properties automatically, but I honestly don't remember.
- Something ( presumably ) is going wrong in the ASBITSTREAM function call, causing the message to be routed to the Failure terminal.
- Something gets traced in the Trace Fail node. I don't know what pattern you put into the node, so no point in guessing.
- The message arrives back on the input terminal of the Compute node. Something is different this time, but we don't know what.
Notice anything about that description? Lots of 'maybe' and 'probably' and 'possibly'. Not good for debugging. Fortunately, message broker has a great feature that will tell you what the flow is doing and WHY. It's called user trace. I strongly suggest that you take a user trace and read it carefully. If you still don't know what's happening, then post the relevant parts, and we should have enough information to answer your questions. |
|
| Back to top |
|
|
| mqjeff |
| Posted: Tue Nov 22, 2011 6:15 am Post subject: |
|
|
Grand Master
Joined: 25 Jun 2008
Posts: 17447
|
Also, be aware that by wiring the nodes in a loop as you have, you are certain to create a chain of events at some point that causes this loop to be executed enough times to cause a stack overflow and thus an EG abend.
So think twice about doing this, in any circumstances at all, ever. |
|
| Back to top |
|
|
| oli |
| Posted: Tue Nov 22, 2011 11:18 pm Post subject: |
|
|
Acolyte
Joined: 14 Jul 2006
Posts: 68
Location: Germany
|
As mentioned earlier this message flow is only for demonstration not for production 
Unfortunately I'm not very exprienced using message sets and MRM message domain. I did a user trace as proposed by kimbert a got the following result.
When processing the ESQL of the compute node for the first time the following (extracted) trace is written (I hope is human readable):
| Code: |
2011-11-22 15:17:49.605056 3084 UserTrace BIP2537I: Node 'com.daimler.test.TestMRMVerySimple.Compute': Executing statement ''SET theBlob = ASBITSTREAM(InputBody ENCODING enc CCSID cc);'' at ('com.daimler.test.TestMRMVerySimple_Compute_Fail.Main', '13.3').
2011-11-22 15:17:49.605076 3084 UserTrace BIP2539I: Node 'com.daimler.test.TestMRMVerySimple.Compute': Evaluating expression ''enc'' at ('com.daimler.test.TestMRMVerySimple_Compute_Fail.Main', '13.40'). This resolved to ''enc''. The result was ''546''.
2011-11-22 15:17:49.605084 3084 UserTrace BIP2539I: Node 'com.daimler.test.TestMRMVerySimple.Compute': Evaluating expression ''cc'' at ('com.daimler.test.TestMRMVerySimple_Compute_Fail.Main', '13.45'). This resolved to ''cc''. The result was ''1208''.
2011-11-22 15:17:49.610044 3084 UserTrace BIP5493W: Message, element or attribute 'Order' is self-defining within parent 'http://com.dcx.iap/2007/BIBTestNSA:Application'.
The message, element or attribute 'Order' did not match with any corresponding
artifact in the message model hence it is considered to be self-defining.
If it is not intended that this message, element or attribute be self-defining,
check that the message set is referenced in the message properties, or
modify the message model to correspond to the instance message, or
modify the instance message to correspond to the message model.
2011-11-22 15:17:49.610124 3084 UserTrace BIP5493W: Message, element or attribute '@id' is self-defining within parent 'Order'.
The message, element or attribute '@id' did not match with any corresponding
artifact in the message model hence it is considered to be self-defining.
If it is not intended that this message, element or attribute be self-defining,
check that the message set is referenced in the message properties, or
modify the message model to correspond to the instance message, or
modify the instance message to correspond to the message model.
2011-11-22 15:17:49.610652 3084 UserTrace BIP2231E: Error detected whilst processing a message in node 'com.daimler.test.TestMRMVerySimple.Compute'.
The message broker detected an error whilst processing a message in node 'com.daimler.test.TestMRMVerySimple.Compute'. The message has been augmented with an exception list and has been propagated to the node's failure terminal for further processing.
See the following messages for details of the error.
2011-11-22 15:17:49.610672 3084 RecoverableException BIP2488E: ('com.daimler.test.TestMRMVerySimple_Compute_Fail.Main', '13.3') Error detected whilst executing the SQL statement ''SET theBlob = ASBITSTREAM(InputBody ENCODING enc CCSID cc);''.
The message broker detected an error whilst executing the given statement. An exception has been thrown to cut short the SQL program.
See the following messages for details of the error.
2011-11-22 15:17:49.610684 3084 ParserException BIP5136E: Invalid Wire Format Identifier ''''.
When processing an MRM message the broker requires a valid wire format identifier.
Check that you have packaged the message correctly and set the correct message properties then resubmit the message.
|
When processing the ESQL for the second time that's the trace:
| Code: |
2011-11-22 15:17:49.612172 3084 UserTrace BIP2537I: Node 'com.daimler.test.TestMRMVerySimple.Compute': Executing statement ''SET theBlob = ASBITSTREAM(InputBody ENCODING enc CCSID cc);'' at ('com.daimler.test.TestMRMVerySimple_Compute_Fail.Main', '13.3').
2011-11-22 15:17:49.612192 3084 UserTrace BIP2539I: Node 'com.daimler.test.TestMRMVerySimple.Compute': Evaluating expression ''enc'' at ('com.daimler.test.TestMRMVerySimple_Compute_Fail.Main', '13.40'). This resolved to ''enc''. The result was ''546''.
2011-11-22 15:17:49.612200 3084 UserTrace BIP2539I: Node 'com.daimler.test.TestMRMVerySimple.Compute': Evaluating expression ''cc'' at ('com.daimler.test.TestMRMVerySimple_Compute_Fail.Main', '13.45'). This resolved to ''cc''. The result was ''1208''.
2011-11-22 15:17:49.616384 3084 UserTrace BIP2540I: Node 'com.daimler.test.TestMRMVerySimple.Compute': Finished evaluating expression ''ASBITSTREAM(InputBody ENCODING enc CCSID cc)'' at ('com.daimler.test.TestMRMVerySimple_Compute_Fail.Main', '13.17'). The result was ''X'3c3f786d6c2076657273696f6e3d22312e3022206............'''.
|
As mentioned above I'm not experienced with the messageset stuff but for me it seems that there is maybe a problem with the message set ...
Any hints?
Thanks,
Oli |
|
| Back to top |
|
|
| smdavies99 |
| Posted: Wed Nov 23, 2011 12:22 am Post subject: |
|
|
Jedi Council
Joined: 10 Feb 2003
Posts: 6076
Location: Somewhere over the Rainbow this side of Never-never land.
|
| Quote: |
The message, element or attribute 'Order' did not match with any corresponding artifact in the message model hence it is considered to be self-defining. If it is not intended that this message, element or attribute be self-defining, check that the message set is referenced in the message properties, or modify the message model to correspond to the instance message, or modify the instance message to correspond to the message model
|
Either Order is node defined in the message set OR it is defined in a different place from where is it appearing in the message tree.
Your detective work starts now.
_________________
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 |
|
|
| kimbert |
| Posted: Wed Nov 23, 2011 1:49 am Post subject: |
|
|
Jedi Council
Joined: 29 Jul 2003
Posts: 5542
Location: Southampton
|
smdavies99 is right - you should not be getting self-defining elements in your message.
However...the input node has just parsed that message without complaining, so I'm struggling to see how the message tree can contain any self-defining elements ( unless you are using MRM to parse an XML message - surely not! ).
My suggestion would be to supply the SET, TYPE and FORMAT parameters to ASBITSTREAM and try again. |
|
| Back to top |
|
|
| oli |
| Posted: Wed Nov 23, 2011 4:13 am Post subject: |
|
|
Acolyte
Joined: 14 Jul 2006
Posts: 68
Location: Germany
|
For testing purposes I'm currently using an XML message and the message set was created using an XML schema
Maybe I would be a good idea not to use XML ...
Thanks,
Oli |
|
| Back to top |
|
|
| mqjeff |
| Posted: Wed Nov 23, 2011 4:26 am Post subject: |
|
|
Grand Master
Joined: 25 Jun 2008
Posts: 17447
|
Are you using MRM to model that XML schema?
Or are you using XMLNSC to model that XML schema?
IN EITHER CASE A MESSAGE SET WOULD BE PRODUCED.
So be specific. Are you using MRM to parse the XML? If so, [i]stop/i] using MRM to parse the XML. |
|
| Back to top |
|
|
| kimbert |
| Posted: Wed Nov 23, 2011 11:07 am Post subject: |
|
|
Jedi Council
Joined: 29 Jul 2003
Posts: 5542
Location: Southampton
|
Let's not talk about *modelling* a message using a parser. A message model is just an abstract description of the message structure. You can create a model outside of broker and import it - then you can instruct a parser to parse and write messages using the imported model.
As mqjeff says, please do not write new message flows that use MRM to parse XML. Use XMLNSC for XML, and MRM ( or even better, DFDL if on v8 ) for non-XML. |
|
| Back to top |
|
|
|
|
|
| |
|
Page 1 of 1 |
|
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
|
|
|
|
