| Author |
Message
|
| Cogito-Ergo-Sum |
 Posted: Thu Apr 05, 2012 6:55 pm Post subject: JMSInput node and DFDL message model doesn't seem to work. |
 |
|
Master
Joined: 07 Feb 2006
Posts: 293
Location: Bengaluru, India
|
To parse the incoming message (simple CSV) in a JMSInput node, I am using DFDL message model. The flow fails at the JMSInput node itself. But, when I replace it with Message Set, it works. The error message is not quite helpful - just to the extent that the message flow failed at JMSInput node.
So, while the Infocenter does say that JMSInput node can use the message model, I could only get the flow working with Message Set. Thoughts, opinions ?
Using WMB 8.0, WMQ 7.0 on Windows.
_________________
ALL opinions are welcome.
-----------------------------
Debugging tip:When you have eliminated all which is impossible, then whatever remains, however improbable, must be the truth.
---Sherlock Holmes |
|
| Back to top |
|
 |
| fjb_saper |
| Posted: Thu Apr 05, 2012 7:31 pm Post subject: |
|
|
Grand High Poobah
Joined: 18 Nov 2003
Posts: 20756
Location: LI,NY
|
Strangely enough I thought this was working as designed.
Why would you think that you no longer needed the message set for your DFDL parser? 
_________________
MQ & Broker admin |
|
| Back to top |
|
|
| smdavies99 |
| Posted: Thu Apr 05, 2012 9:46 pm Post subject: |
|
|
Jedi Council
Joined: 10 Feb 2003
Posts: 6076
Location: Somewhere over the Rainbow this side of Never-never land.
|
| fjb_saper wrote: |
Strangely enough I thought this was working as designed.
Why would you think that you no longer needed the message set for your DFDL parser? |
Hmmmm
If you happened to catch the WebSphereUserGroup webcast yesterday then you would have heard and seen that you don't need what we all know and love as a message set any more when you are using the DFDL Parser.
The message model is deployed as an XSD with the message flow barfile.
Personally, I think this is a step backwards in modularisation. The message sets were an EG wide resource. Ok, so I have not tried V8 yet so I can't really comment on how the DFSL Models would be used in reality.
As to this problem,
Does a user trace show anything when you use the DFSL Parser?
Are there and errors in the event log?
Did you deploy the DFSL Model in the correct way?
_________________
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 |
|
|
| mqjeff |
| Posted: Fri Apr 06, 2012 2:10 am Post subject: |
|
|
Grand Master
Joined: 25 Jun 2008
Posts: 17447
|
One of the really really cool things about the DFDL parser is that you can test it in the Toolkit directly, rather than having to deploy the message model and run a flow.
Did your DFDL model sucessfully validate the message data in the toolkit?
the other thing is that the DFDL parser is *very very* good about reporting what it's doing in user and service trace. So if you can get a user trace of the runtime, you should get a better idea of where the flow is failing. |
|
| Back to top |
|
|
| Cogito-Ergo-Sum |
| Posted: Fri Apr 06, 2012 4:03 am Post subject: |
|
|
Master
Joined: 07 Feb 2006
Posts: 293
Location: Bengaluru, India
|
| Quote: |
| One of the really really cool things about the DFDL parser is that you can test it in the Toolkit directly, rather than having to deploy the message model and run a flow. |
Yes, I am aware and have used it many times before. In this case too, it parsed correctly.
I think, I should have mentioned that, using DFDL didn't work for me. But, MRM did.
I was looking for messages in Windows machine but couldn't find anything informative. (Yes, I am aware; error messages are quite useful; but, in this case, not much came up.) Let me try again.
_________________
ALL opinions are welcome.
-----------------------------
Debugging tip:When you have eliminated all which is impossible, then whatever remains, however improbable, must be the truth.
---Sherlock Holmes |
|
| Back to top |
|
|
| Vitor |
| Posted: Fri Apr 06, 2012 4:32 am Post subject: |
|
|
Grand High Poobah
Joined: 11 Nov 2005
Posts: 26093
Location: Texas, USA
|
| Cogito-Ergo-Sum wrote: |
| I was looking for messages in Windows machine but couldn't find anything informative. |
Finding anything informative in any messages in Windows is a challenge under all circumstances.
A user trace is the answer.
_________________
Honesty is the best policy.
Insanity is the best defence. |
|
| Back to top |
|
|
| mqjeff |
| Posted: Fri Apr 06, 2012 4:45 am Post subject: |
|
|
Grand Master
Joined: 25 Jun 2008
Posts: 17447
|
If the DFDL model successfully parses the data in the Toolkit, and you have marked the Input node that starts your flow with the DFDL parser and the correct information about the DFDL model before you deploy, then the DFDL model should be deployed when you deploy your application and findable at runtime. If you're not deploying the flow in an application, then you need to make sure you have included the DFDL model in the bar file that deploys the flow as an Independent Resource (actually deployed into the EG level application, but that's mostly irrelevant).
If it's not, again, there should be error messages about a failure to find the model. Baring such, then a user trace of the flow should show you what's happening to cause the flow to 'not work' when the DFDL model is used instead of MRM. |
|
| Back to top |
|
|
| mqjeff |
| Posted: Fri Apr 06, 2012 4:47 am Post subject: |
|
|
Grand Master
Joined: 25 Jun 2008
Posts: 17447
|
One More Thing!
The JMS sender might be, inadvertently or not, be including headers that indicate the message type, message set, and message model (an mcd structure in the MQRFH2/message properties). This could be overriding the properties on the JMSInput node. So you might see if you can tell the JMSInput node to parse the message using BLOB (which should hopefully cause it to *ignore* the mcd properties) and then use a ResetContentDescriptor to reparse using DFDL. |
|
| Back to top |
|
|
| kimbert |
| Posted: Sat Apr 07, 2012 12:44 pm Post subject: |
|
|
Jedi Council
Joined: 29 Jul 2003
Posts: 5542
Location: Southampton
|
| Quote: |
| To parse the incoming message (simple CSV) in a JMSInput node, I am using DFDL message model. |
Good choice. DFDL does CSV a lot more easily than MRM does.
This is not a DFDL versus MRM question - although you seem to be trying to make it into exactly that. If the MRM parser had failed then you would almost certainly have received exactly the same error message. However...
| Quote: |
| The flow fails at the JMSInput node itself. But, when I replace it with Message Set, it works. The error message is not quite helpful - just to the extent that the message flow failed at JMSInput node. |
...you have not quoted the error message, and you have not described any steps that you took to diagnose the problem with the DFDL parser. As mqjeff already pointed out, a debug-level user trace would be a very good start. |
|
| Back to top |
|
|
| Cogito-Ergo-Sum |
| Posted: Mon Apr 09, 2012 12:20 am Post subject: |
|
|
Master
Joined: 07 Feb 2006
Posts: 293
Location: Bengaluru, India
|
This is what I see as an error in Windows.
| Code: |
Event Type: Error
Event Source: WebSphere Broker v8000
Event Category: None
Event ID: 2628
Date: 09/04/2012
Time: 13:14:27
User: N/A
Computer: MINE
Description:
( BRKR01.default ) Exception condition detected on input node 'sample.MySample.JM1'.
The input node 'sample.MySample.JM1' detected an error whilst processing a message. The message flow has been rolled-back and, if the message was being processed in a unit of work, it will remain on the input queue to be processed again. Following messages will indicate the cause of this exception.
Check the error messages which follow to determine why the exception was generated, and take action as described by those messages.
|
This is the information message.
| Code: |
Event Type: Warning
Event Source: WebSphere Broker v8000
Event Category: None
Event ID: 4669
Date: 09/04/2012
Time: 13:14:27
User: N/A
Computer: MINE
Description:
( BRKR01.default ) JMSClient.''Broker 'BRKR01'; Execution Group 'default'; Message Flow 'sample.MySample.JM1'; Node 'ComIbmJMSClientInputNode::JMI001::ComIbmJMSClientInputNode' ''. A backout destination was not configured for a JMS node.
The node was unable to process a JMS message because of errors and cannot send it to a backout destination because none was configured.
Investigate the cause of the message failure. Consider setting Backout Destination and Backout Threshold properties for the node. |
And, the user trace debug level
| Code: |
| <?xml version="1.0" encoding="UTF-8" ?><TraceLog/> |
| Code: |
C:\Program Files\IBM\MQSI\8.0.0.0\bin>mqsichangetrace BRKR01 -u -e default -l de
bug
BIP8071I: Successful command completion.
C:\Program Files\IBM\MQSI\8.0.0.0\bin>mqsireadlog BRKR01 -t -e default -f -o C:\
BRKR01-default.xml
BIP8071I: Successful command completion.
C:\Program Files\IBM\MQSI\8.0.0.0\bin>mqsiformatlog -i C:\BRKR01-default.xml -o
C:\BRKR01-default.log
BIP8071I: Successful command completion.
C:\Program Files\IBM\MQSI\8.0.0.0\bin>mqsichangetrace BRKR01 -u -e default -l no
ne
BIP8071I: Successful command completion. |
_________________
ALL opinions are welcome.
-----------------------------
Debugging tip:When you have eliminated all which is impossible, then whatever remains, however improbable, must be the truth.
---Sherlock Holmes |
|
| Back to top |
|
|
| Vitor |
| Posted: Mon Apr 09, 2012 4:31 am Post subject: |
|
|
Grand High Poobah
Joined: 11 Nov 2005
Posts: 26093
Location: Texas, USA
|
| Cogito-Ergo-Sum wrote: |
| Code: |
C:\Program Files\IBM\MQSI\8.0.0.0\bin>mqsichangetrace BRKR01 -u -e default -l de
bug
BIP8071I: Successful command completion.
C:\Program Files\IBM\MQSI\8.0.0.0\bin>mqsireadlog BRKR01 -t -e default -f -o C:\
BRKR01-default.xml
BIP8071I: Successful command completion.
C:\Program Files\IBM\MQSI\8.0.0.0\bin>mqsiformatlog -i C:\BRKR01-default.xml -o
C:\BRKR01-default.log
BIP8071I: Successful command completion.
C:\Program Files\IBM\MQSI\8.0.0.0\bin>mqsichangetrace BRKR01 -u -e default -l no
ne
BIP8071I: Successful command completion. |
|
Do you plan to tell us at any point what the user trace says (i.e. the contents of BRKR01-default.log) or should we just guess? 
_________________
Honesty is the best policy.
Insanity is the best defence. |
|
| Back to top |
|
|
| smdavies99 |
| Posted: Mon Apr 09, 2012 6:24 am Post subject: |
|
|
Jedi Council
Joined: 10 Feb 2003
Posts: 6076
Location: Somewhere over the Rainbow this side of Never-never land.
|
You are nearly there with your commands.
| Code: |
C:\>mqsichangetrace BRKR01 -u -e default -r -l debug
|
Run your test
THEN
| Code: |
C:\>mqsichangetrace BRKR01 -u -e default -l none
C:\>mqsireadlog BRKR01 -u -e default -o C:\BRKR01-default.xml
C:\>mqsiformatlog -i C:\BRKR01-default.xml -o C:\BRKR01-default.log
|
You should now get something useful in your output file.
It is also a good idea to put these commands into a .bat (windows) or a Unix/Linux Shell script. You never know when you will need to run it again.
_________________
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 |
|
|
| Cogito-Ergo-Sum |
| Posted: Tue Apr 10, 2012 11:29 pm Post subject: |
|
|
Master
Joined: 07 Feb 2006
Posts: 293
Location: Bengaluru, India
|
Sorry, smdavies99. I followed your instructions to the letter and yet, the log generated is no different from what I have pasted above.
Thanks for your time.
_________________
ALL opinions are welcome.
-----------------------------
Debugging tip:When you have eliminated all which is impossible, then whatever remains, however improbable, must be the truth.
---Sherlock Holmes |
|
| Back to top |
|
|
| kimbert |
| Posted: Wed Apr 11, 2012 12:18 am Post subject: |
|
|
Jedi Council
Joined: 29 Jul 2003
Posts: 5542
Location: Southampton
|
| So you are claiming that your execution group never emits any user trace at all, ever. That sounds very unlikely indeed. Are you 100% sure that you put a message through the (correct) flow between the first and second invocations of mqsichangetrace? |
|
| Back to top |
|
|
| Cogito-Ergo-Sum |
| Posted: Wed Apr 11, 2012 12:51 am Post subject: |
|
|
Master
Joined: 07 Feb 2006
Posts: 293
Location: Bengaluru, India
|
| Quote: |
| Are you 100% sure that you put a message through the (correct) flow between the first and second invocations of mqsichangetrace? |
I had stopped all message flows except the one I want to test.
_________________
ALL opinions are welcome.
-----------------------------
Debugging tip:When you have eliminated all which is impossible, then whatever remains, however improbable, must be the truth.
---Sherlock Holmes |
|
| Back to top |
|
|
|
|
