| Author |
Message
|
| Dave Ziegler |
 Posted: Tue Sep 09, 2014 3:23 pm Post subject: Problem reconstructing cached DFDL message |
 |
|
Centurion
Joined: 15 Apr 2014
Posts: 118
|
I've been at this a while and could use another set of eyes on it.
| Code: |
| DECLARE messageCache SHARED ROW NULL; |
At some point in the flow, I need to hang onto this message. I'm attempting to use a technique suggested by IBM support when I wanted to do the same thing with a SOAP message:
| Code: |
SET messageCache.Properties = InputRoot.Properties;
SET messageCache.MQMD = InputRoot.MQMD;
SET messageCache.MQRFH2 = InputRoot.MQRFH2;
SET messageCache.BLOB = ASBITSTREAM(InputRoot.DFDL OPTIONS FolderBitStream ENCODING InputProperties.Encoding CCSID InputProperties.CodedCharSetId); |
And then I try to reconstruct it later on:
| Code: |
SET OutputRoot.Properties = messageCache.Properties;
SET OutputRoot.MQMD = messageCache.MQMD;
SET OutputRoot.MQRFH2 = messageCache.MQRFH2;
CREATE LASTCHILD OF OutputRoot DOMAIN('DFDL') PARSE(messageCache.BLOB OPTIONS FolderBitStream ENCODING messageCache.Properties.Encoding CCSID messageCache.Properties.CodedCharSetId);
|
I think I'm seeing an issue similar to the one described in this thread, but it sounded like that was fixed in v8... I'm on v9.
| Code: |
| Text:CHARACTER:Cannot continue - messageTypeName is empty |
Suggestions? |
|
| Back to top |
|
 |
| smdavies99 |
| Posted: Tue Sep 09, 2014 10:01 pm Post subject: |
|
|
Jedi Council
Joined: 10 Feb 2003
Posts: 6076
Location: Somewhere over the Rainbow this side of Never-never land.
|
Whenever I'm doing a
| Code: |
CREATE LASTCHILD OF OutputRoot DOMAIN('xxxxxx')...
|
I always include the
for example
| Code: |
-- Create The message Tree
SET OutputRoot.Properties = InputRoot.Properties;
CREATE LASTCHILD of OutputRoot DOMAIN 'MQMD' NAME 'MQMD';
SET OutputRoot.MQMD.Version = 2;
CREATE LASTCHILD of OutputRoot DOMAIN 'XMLNSC' NAME 'XMLNSC';
|
_________________
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 |
|
|
| fjb_saper |
| Posted: Wed Sep 10, 2014 3:36 am Post subject: |
|
|
Grand High Poobah
Joined: 18 Nov 2003
Posts: 20756
Location: LI,NY
|
SMDavies has it right.
The difference between
| Code: |
| SET sharedvar = InputRoot; |
and
| Code: |
| SET sharedvar.xxx = InputRoot.xxx; |
is quite subtle.
The main point here is that the second set up will not copy the associated parser (domain) and when you try to restore, even if you do attach below the associated parser you risk some bizarre errors usually not seen but specific to your situation.... This is because some formatting has been lost in the move/copy to shared var.
Normally SET OutputRoot.xxx is supposed to attach the corresponding domain (specific case of OutputRoot), however in this case I would go as far as specifying it (both for sharedvar and OutputRoot). This should then keep you whole.
Have fun 
[/code]
_________________
MQ & Broker admin |
|
| Back to top |
|
|
| Dave Ziegler |
| Posted: Wed Sep 10, 2014 4:03 am Post subject: |
|
|
Centurion
Joined: 15 Apr 2014
Posts: 118
|
I wondered about that and even tried it at one point yesterday, but still got the same error. I will try again today and report back. It is possible I had something else wrong at the time.
Edit: actually, I think the toolkit was complaining that the parse statement didn't like the Name clause in there, but again I will verify and report back. |
|
| Back to top |
|
|
| smdavies99 |
| Posted: Wed Sep 10, 2014 4:23 am Post subject: |
|
|
Jedi Council
Joined: 10 Feb 2003
Posts: 6076
Location: Somewhere over the Rainbow this side of Never-never land.
|
| Dave Ziegler wrote: |
Edit: actually, I think the toolkit was complaining that the parse statement didn't like the Name clause in there, but again I will verify and report back. |
My code snippet was taken from a flow that has been running on V7.0.0.4 for 18 months and is also running on V9.0.0.2 (UAT). The V9 Tooklit was used to rebuild the flow (after changing some .msgflow files that were sub-flows to .subflow types).
_________________
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: Wed Sep 10, 2014 4:35 am Post subject: |
|
|
Grand Master
Joined: 25 Jun 2008
Posts: 17447
|
I wouldn't expect the name clause to be mandatory.
I would expect that simply specifying the domain will create the name correctly.
Likewise that a simple trace of the tree will show whether it does or not.
I suspect the problem is that DFDL needs to know the name of the message model to use to parse the BLOB with. XMLNSC can use the name of the root tag to look up the model, but I don't think DFDL can. |
|
| Back to top |
|
|
| Dave Ziegler |
| Posted: Wed Sep 10, 2014 4:36 am Post subject: |
|
|
Centurion
Joined: 15 Apr 2014
Posts: 118
|
| I think your example is a bit different though, you're not using parse to rehydrate the blob right? |
|
| Back to top |
|
|
| vicentius |
| Posted: Wed Sep 10, 2014 4:54 am Post subject: |
|
|
Apprentice
Joined: 01 Mar 2013
Posts: 28
|
The syntax for CREATE ... PARSE allows for specifying all the information needed to interpret the bit stream.
Have you tried it like this?
CREATE LASTCHILD OF someRef DOMAIN 'DFDL' PARSE(someBitStream, someEncoding, someCCSID, '', '{}:YOURMODEL','', someOptions)
(where ''s are for SET and FORMAT, respectively. Both are not interesting for DFDL.) |
|
| Back to top |
|
|
| Dave Ziegler |
| Posted: Wed Sep 10, 2014 5:43 am Post subject: |
|
|
Centurion
Joined: 15 Apr 2014
Posts: 118
|
| vicentius wrote: |
The syntax for CREATE ... PARSE allows for specifying all the information needed to interpret the bit stream.
Have you tried it like this? |
I have not, I've only attempted what is in my post and additionally at one point I did specify the NAME clause.
| vicentius wrote: |
| Both are not interesting for DFDL.) |
So... should this matter or no? I'm using DFDL.
Edit: Wait... I understand what you meant. Let me do some experimenting and report back. Thank you. |
|
| Back to top |
|
|
| Dave Ziegler |
| Posted: Wed Sep 10, 2014 6:02 am Post subject: |
|
|
Centurion
Joined: 15 Apr 2014
Posts: 118
|
| smdavies99 wrote: |
for example
| Code: |
-- Create The message Tree
SET OutputRoot.Properties = InputRoot.Properties;
CREATE LASTCHILD of OutputRoot DOMAIN 'MQMD' NAME 'MQMD';
SET OutputRoot.MQMD.Version = 2;
CREATE LASTCHILD of OutputRoot DOMAIN 'XMLNSC' NAME 'XMLNSC';
|
|
I did try using NAME at one point last night, but wasn't having any luck. I switched to the PARSE method suggested by IBM support (with SOAP messages) and here we are. I don't see a way to stuff NAME in there when using the PARSE technique.
| mqjeff wrote: |
Likewise that a simple trace of the tree will show whether it does or not.
|
Working on this now...
| mqjeff wrote: |
I suspect the problem is that DFDL needs to know the name of the message model to use to parse the BLOB with. XMLNSC can use the name of the root tag to look up the model, but I don't think DFDL can.
|
I suspect you are correct, I'm just not sure what to do about it. /noob |
|
| Back to top |
|
|
| mqjeff |
| Posted: Wed Sep 10, 2014 6:05 am Post subject: |
|
|
Grand Master
Joined: 25 Jun 2008
Posts: 17447
|
| Dave Ziegler wrote: |
| mqjeff wrote: |
I suspect the problem is that DFDL needs to know the name of the message model to use to parse the BLOB with. XMLNSC can use the name of the root tag to look up the model, but I don't think DFDL can.
|
I suspect you are correct, I'm just not sure what to do about it. /noob |
That's the bit that vicentius posted, with the {}:YOURMODEL. Just use any kind of *Input node (MQInput, for example) and set the domain to DFDL and then set the message model to whatever your model is. That will show you what to put in place of '{}:YOURMODEL'. It will almost certain include the {}. |
|
| Back to top |
|
|
| Dave Ziegler |
| Posted: Wed Sep 10, 2014 6:10 am Post subject: |
|
|
Centurion
Joined: 15 Apr 2014
Posts: 118
|
| mqjeff wrote: |
That's the bit that vicentius posted, with the {}:YOURMODEL. |
I worded that poorly. I'm working on it now along with the trace. Thanks! |
|
| Back to top |
|
|
| Dave Ziegler |
| Posted: Wed Sep 10, 2014 6:24 am Post subject: |
|
|
Centurion
Joined: 15 Apr 2014
Posts: 118
|
OHMYGODOHMYGODOHMYGODOHMYGOD...
I think this is working. Everyone, hold your breath... |
|
| Back to top |
|
|
| Dave Ziegler |
| Posted: Wed Sep 10, 2014 6:27 am Post subject: |
|
|
Centurion
Joined: 15 Apr 2014
Posts: 118
|
Outstanding. The DFDL message has been successfully reconstructed.
However... now I have a MQRFH2 problem to look into. I'm getting a popup 'An internal error occurred during: "has children update".' and two line items: Label job, has children update.
Progress at least. Thanks for the suggestion vicentius  |
|
| Back to top |
|
|
| vicentius |
| Posted: Wed Sep 10, 2014 6:34 am Post subject: |
|
|
Apprentice
Joined: 01 Mar 2013
Posts: 28
|
| Do you see "'An internal error occurred during: "has children update".'" in the Broker Toolkit debugger? If so, you can safely ignore it - it's an Eclipse bug. If you see it also in an user trace, then please share more details with us. |
|
| Back to top |
|
|
|
|
