| Author |
Message
|
| zurg |
 Posted: Thu Jun 06, 2013 12:37 am Post subject: serialize a tree |
 |
|
Novice
Joined: 04 Feb 2013
Posts: 10
|
Hello experts,
I'm trying to prepare a universal functions to serialize a tree (LocalEnvironment). The point is to store/restore in database some information about session. But for that in should allow to eg. store also messages within tree.
For that I wanted to use ASBITSTREAM function.
And to deserialize to use CREATE/PARSE contruction.
As long as I have a simple tree structure inside LocalEnvironment this approach is working. But I'm getting problems when I want to store there also message. When deserializing I'm getting errors about namespaces.
Any idea what I'm doing wrong?
Code:
| Code: |
Create FIRSTCHILD of OutputLocalEnvironment DOMAIN 'XMLNSC' Name 'MagicSession';
SET OutputLocalEnvironment.MagicSession.Root.Message.Root = InputRoot;
SET OutputLocalEnvironment.MagicSession.Root.Local.Root = InputLocalEnvironment;
DECLARE BlobIt BLOB ASBITSTREAM(OutputLocalEnvironment.MagicSession ENCODING 273 CCSID 1208);
SET Environment.Variables.BLOBIT = BlobIt;
CREATE LASTCHILD OF OutputLocalEnvironment DOMAIN ('XMLNSC') PARSE (Environment.Variables.BLOBIT, 273, 1208);
SET OutputRoot = OutputLocalEnvironment.XMLNSC.Root.Message.Root;
RETURN TRUE;
|
Error:
| Code: |
An XML parsing error 'The namespace prefix "xmlns" was not declared.' occurred on line 1 column 1700 when parsing element '/Root/XMLNSC/Root/Message/Root/XMLNSC/urn:tss/bcl/quote/IGetQuoteApprovers:inGetQuoteApprovers'
|
|
|
| Back to top |
|
 |
| lancelotlinc |
| Posted: Thu Jun 06, 2013 3:18 am Post subject: |
|
|
Jedi Knight
Joined: 22 Mar 2010
Posts: 4941
Location: Bloomington, IL USA
|
ESBs are supposed to be session-less. That is, they do not care what state the overall transaction is in. They process data in a stateless way. Your attempt to add state to WMB may cause more pain than you realize. Think differently, as in, let WMB be stateless, as it was designed to be a high-speed messaging engine, not a WAS server. If you want to keep track of session state, then use WAS, not WMB.
That said, here is some code which works for me, from a database node, to store the Root payload into a database column using INSERT ... VALUES:
| Code: |
DECLARE options INTEGER RootBitStream ;
SET payl = CAST( ASBITSTREAM( Root.XMLNSC OPTIONS options CCSID 1208 ) AS CHARACTER CCSID 1208 );
|
_________________
http://leanpub.com/IIB_Tips_and_Tricks
Save $20: Coupon Code: MQSERIES_READER |
|
| Back to top |
|
|
| mqjeff |
| Posted: Thu Jun 06, 2013 3:22 am Post subject: |
|
|
Grand Master
Joined: 25 Jun 2008
Posts: 17447
|
| Code: |
| SET OutputLocalEnvironment.MagicSession.Root.Message.Root = InputRoot; |
This doesn't do what you want it to do. |
|
| Back to top |
|
|
| zurg |
| Posted: Thu Jun 06, 2013 4:47 am Post subject: |
|
|
Novice
Joined: 04 Feb 2013
Posts: 10
|
Thank you for the responses.
@lancelotlinc,
Yes, you are right about main role of ESB solutions. In fact they should be able to store at least some minimal information about session when we are doing async calls. As we can see in sample "Coordinated Request Reply" where also also Global Cache is used for session storing. But that's a theoretical discussion:)
Thank you for your sample. Yes, I tried that approach. It's working as long as I want to store one message tree. What in fact you are doing in this sample.
As I wrote, I wonder if it's possible to store for example two-tree messages using that technique. I'm facing problems probably because I want to use XMLNSC parser to store the whole message tree with XMLNSC parser already attached to part of it. At least I think so.
Problem:
I have 3 "small" services doing some operations. And I want to build a "big" service that calls this 3 "small" services. Since I'm calling them in a row I need to know the previous responses. And since I'm communicating with them using queues I cannot store information about previous responses in Environment/LocalEnvironment.
Putting this straight: I'm looking for some solution to store some information in database. By "some information" I mean everything that is in LocalEnvironment. For example two message trees (response 1 and response 2 from "small" services) and MQMD from original request.
Without that I cannot see solution to do this (calling 3 "small" services) working. Of course I may be missing something. Please let me know. |
|
| Back to top |
|
|
| lancelotlinc |
| Posted: Thu Jun 06, 2013 4:52 am Post subject: |
|
|
Jedi Knight
Joined: 22 Mar 2010
Posts: 4941
Location: Bloomington, IL USA
|
Yes, you can do this if you attach the three payloads to your message tree as CDATA.
I encourage you to think more carefully however, as it seems you are trying to fit the square peg in the round hole.
_________________
http://leanpub.com/IIB_Tips_and_Tricks
Save $20: Coupon Code: MQSERIES_READER |
|
| Back to top |
|
|
| zurg |
| Posted: Thu Jun 06, 2013 5:08 am Post subject: |
|
|
Novice
Joined: 04 Feb 2013
Posts: 10
|
@mqjeff,
thanks for pointing that.
you would go rather with something like:
| Code: |
Create FIRSTCHILD of OutputLocalEnvironment DOMAIN 'XMLNSC' Name 'MagicSession';
SET OutputLocalEnvironment.MagicSession = InputRoot.XMLNSC;
DECLARE BlobIt BLOB ASBITSTREAM(OutputLocalEnvironment.MagicSession ENCODING 273 CCSID 1208);
SET Environment.Variables.BLOBIT = BlobIt;
CREATE LASTCHILD OF OutputLocalEnvironment DOMAIN ('XMLNSC') PARSE (Environment.Variables.BLOBIT, 273, 1208);
CREATE LASTCHILD OF OutputRoot DOMAIN 'XMLNSC';
SET OutputRoot.XMLNSC = OutputLocalEnvironment.XMLNSC
|
?
This way it's working but not doing what I want it to do.
Well, I'd like to store the whole message tree (Properties, MQMD, XMLNSC) and LocalEnvironment somewhere.
With my approach, I wanted to cast in into BLOB, store in database, read it back and PARSE back into tree. So far I'm:
1) loosing all the namespaces
OR
2) unable to make it work
The question is how/if is it possible to achieve the functionality I want.
@lancelotlinc,
it seems your are responding faster than I'm asking 
Thank you for suggestion, I will investigate this idea.
You mean the whole idea of storing somewhere so many information session-related is wrong as long as I'm working WMB? Or just I'm approaching it from wrong direction?
Personally, I would prefer to build the "big" service on some BPM solution. But I don't have any at hand... |
|
| Back to top |
|
|
| mqjeff |
| Posted: Thu Jun 06, 2013 6:04 am Post subject: |
|
|
Grand Master
Joined: 25 Jun 2008
Posts: 17447
|
What your code does is store the whole message tree, Properties, MQMD, etc, as a set of children of the XMLNSC parser.
That's not correct. |
|
| Back to top |
|
|
| fjb_saper |
| Posted: Thu Jun 06, 2013 6:23 am Post subject: |
|
|
Grand High Poobah
Joined: 18 Nov 2003
Posts: 20756
Location: LI,NY
|
Sounds very much like trying to reinvent the aggregation pattern?? 
_________________
MQ & Broker admin |
|
| Back to top |
|
|
| mqjeff |
| Posted: Thu Jun 06, 2013 6:27 am Post subject: |
|
|
Grand Master
Joined: 25 Jun 2008
Posts: 17447
|
| fjb_saper wrote: |
| Sounds very much like trying to reinvent the aggregation pattern?? |
Or collection. |
|
| Back to top |
|
|
| zurg |
| Posted: Thu Jun 06, 2013 6:46 am Post subject: |
|
|
Novice
Joined: 04 Feb 2013
Posts: 10
|
@fjb_saper, @mqjeff,
aggregation/collection is ok if I would like to call "small" services in parallel. But, as I wrote, I need to do it in row, since I need some data from previous response to do another call.
Yes, theoretically I could send previous response as one of the responses to collector node and wait for other response. But it seems as a hack for me.
@mqjeff,
| Quote: |
What your code does is store the whole message tree, Properties, MQMD, etc, as a set of children of the XMLNSC parser.
That's not correct. |
True.
Any another way to achieve the target? |
|
| Back to top |
|
|
| mqjeff |
| Posted: Thu Jun 06, 2013 6:51 am Post subject: |
|
|
Grand Master
Joined: 25 Jun 2008
Posts: 17447
|
| zurg wrote: |
@fjb_saper, @mqjeff,
aggregation/collection is ok if I would like to call "small" services in parallel. But, as I wrote, I need to do it in row, since I need some data from previous response to do another call.
Yes, theoretically I could send previous response as one of the responses to collector node and wait for other response. But it seems as a hack for me.
@mqjeff,
| Quote: |
What your code does is store the whole message tree, Properties, MQMD, etc, as a set of children of the XMLNSC parser.
That's not correct. |
True.
Any another way to achieve the target? |
Don't stick them under an XMLNSC tree...
It's not clear why you need the entire message for each response in order to build the next request. |
|
| Back to top |
|
|
| fjb_saper |
| Posted: Thu Jun 06, 2013 7:16 am Post subject: |
|
|
Grand High Poobah
Joined: 18 Nov 2003
Posts: 20756
Location: LI,NY
|
Use the responses to build the request and send a copy of the response to the collection queue. Then use a collection to assemble all the responses....
Have fun
_________________
MQ & Broker admin |
|
| Back to top |
|
|
| stevarg |
| Posted: Thu Jun 06, 2013 11:56 pm Post subject: |
|
|
Novice
Joined: 20 Nov 2012
Posts: 24
|
| You could use and MQGet node to browse the response and then continue the processing for the next requests or services .... this way you could have the response from the previous call to create the request for the next service. |
|
| Back to top |
|
|
| Y75 |
| Posted: Mon Aug 05, 2013 2:09 pm Post subject: |
|
|
Apprentice
Joined: 29 Jul 2013
Posts: 32
|
Is it possible to store a MbMessage/MbMessageCollection object in global cache for purpose of maintaining state in v9? I read this in documentation
"Warning: caching MbMessage objects over multiple message flow invocations is unsupported because the internal state may be reset at the end of the current message invocation."
There is a copy constructor in MbMessage, I was thinking if I take a copy and stick it in globalmap, would it remain across message invocation? I also have the option of turning the MbMessage to bit stream as discussed in this thread before. |
|
| Back to top |
|
|
| fjb_saper |
| Posted: Mon Aug 05, 2013 7:46 pm Post subject: |
|
|
Grand High Poobah
Joined: 18 Nov 2003
Posts: 20756
Location: LI,NY
|
What you need to have / cache is a recognizable key for your message + the state information. You can then retrieve / save this information into global cache for every invocation...
But as discussed previously, the most efficient model is stateless. Use at your own risk.
_________________
MQ & Broker admin |
|
| Back to top |
|
|
|
|
