ASG
IBM
Zystems
Cressida
Icon
Netflexity
 
  MQSeries.net
Search  Search       Tech Exchange      Education      Certifications      Library      Info Center      SupportPacs      LinkedIn  Search  Search                                                                   FAQ  FAQ   Usergroups  Usergroups
 
Register  ::  Log in Log in to check your private messages
 
RSS Feed - WebSphere MQ Support RSS Feed - Message Broker Support

MQSeries.net Forum Index » WebSphere Message Broker (ACE) Support » Problem reconstructing cached DFDL message

Post new topic  Reply to topic Goto page 1, 2  Next
 Problem reconstructing cached DFDL message « View previous topic :: View next topic » 
Author Message
Dave Ziegler
PostPosted: Tue Sep 09, 2014 3:23 pm    Post subject: Problem reconstructing cached DFDL message Reply with quote

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
View user's profile Send private message
smdavies99
PostPosted: Tue Sep 09, 2014 10:01 pm    Post subject: Reply with quote

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
Code:

NAME('xxxxxx')


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
View user's profile Send private message
fjb_saper
PostPosted: Wed Sep 10, 2014 3:36 am    Post subject: Reply with quote

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
View user's profile Send private message Send e-mail
Dave Ziegler
PostPosted: Wed Sep 10, 2014 4:03 am    Post subject: Reply with quote

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
View user's profile Send private message
smdavies99
PostPosted: Wed Sep 10, 2014 4:23 am    Post subject: Reply with quote

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
View user's profile Send private message
mqjeff
PostPosted: Wed Sep 10, 2014 4:35 am    Post subject: Reply with quote

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
View user's profile Send private message
Dave Ziegler
PostPosted: Wed Sep 10, 2014 4:36 am    Post subject: Reply with quote

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
View user's profile Send private message
vicentius
PostPosted: Wed Sep 10, 2014 4:54 am    Post subject: Reply with quote

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
View user's profile Send private message
Dave Ziegler
PostPosted: Wed Sep 10, 2014 5:43 am    Post subject: Reply with quote

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
View user's profile Send private message
Dave Ziegler
PostPosted: Wed Sep 10, 2014 6:02 am    Post subject: Reply with quote

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
View user's profile Send private message
mqjeff
PostPosted: Wed Sep 10, 2014 6:05 am    Post subject: Reply with quote

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
View user's profile Send private message
Dave Ziegler
PostPosted: Wed Sep 10, 2014 6:10 am    Post subject: Reply with quote

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
View user's profile Send private message
Dave Ziegler
PostPosted: Wed Sep 10, 2014 6:24 am    Post subject: Reply with quote

Centurion

Joined: 15 Apr 2014
Posts: 118

OHMYGODOHMYGODOHMYGODOHMYGOD...

I think this is working. Everyone, hold your breath...
Back to top
View user's profile Send private message
Dave Ziegler
PostPosted: Wed Sep 10, 2014 6:27 am    Post subject: Reply with quote

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
View user's profile Send private message
vicentius
PostPosted: Wed Sep 10, 2014 6:34 am    Post subject: Reply with quote

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
View user's profile Send private message
Display posts from previous:   
Post new topic  Reply to topic Goto page 1, 2  Next Page 1 of 2

MQSeries.net Forum Index » WebSphere Message Broker (ACE) Support » Problem reconstructing cached DFDL message
Jump to:  



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
Protected by Anti-Spam ACP
 
 


Theme by Dustin Baccetti
Powered by phpBB © 2001, 2002 phpBB Group

Copyright © MQSeries.net. All rights reserved.