| Author |
Message
|
| sunnym |
 Posted: Tue May 31, 2011 9:30 am Post subject: Difference between Localenvironment and environment? |
 |
|
Newbie
Joined: 27 May 2011
Posts: 8
|
| I am cant understand when and where Localenvironment and environment are used and what are difference between them....please provide any examples if possible...... |
|
| Back to top |
|
 |
| lancelotlinc |
| Posted: Tue May 31, 2011 9:40 am Post subject: |
|
|
Jedi Knight
Joined: 22 Mar 2010
Posts: 4941
Location: Bloomington, IL USA
|
|
| Back to top |
|
|
| Vitor |
| Posted: Tue May 31, 2011 9:43 am Post subject: Re: Difference between Localenvironment and environment? |
|
|
Grand High Poobah
Joined: 11 Nov 2005
Posts: 26093
Location: Texas, USA
|
| sunnym wrote: |
| I am cant understand when and where Localenvironment and environment are used and what are difference between them. |
One's local to a node, one isn't. One tends to be used by WMB nodes for parameter information, one isn't.
| sunnym wrote: |
| ...please provide any examples if possible...... |
The InfoCenter contains a number of these.
_________________
Honesty is the best policy.
Insanity is the best defence. |
|
| Back to top |
|
|
| sunnym |
| Posted: Tue May 31, 2011 2:04 pm Post subject: |
|
|
Newbie
Joined: 27 May 2011
Posts: 8
|
Correct me if I am wrong but Following paragraph is contrary to what Vitor is saying.Is in't? "local environment stores information through out the flow "Then what is the difference between local environment and environment
The local environment tree is a part of the logical message tree in which you can store information while the message flow processes the message.
The root of the local environment tree is called LocalEnvironment. This tree is always present in the input message: an empty local environment tree is created when a message is received by the input node.
Use the local environment tree to store variables that can be referred to and updated by message processing nodes that occur later in the message flow. You can also use the local environment tree to define destinations (that are internal and external to the message flow) to which a message is sent. WebSphere® Message Broker also stores information in LocalEnvironment in some circumstances, and references it to access values that you might have set for destinations. (Contrast this to the Environment tree structure, which the broker refers to in one situation only, see Environment tree structure.)
http://publib.boulder.ibm.com/infocenter/wmbhelp/v6r0m0/index.jsp?topic=/com.ibm.etools.mft.doc/ac00520_.htm |
|
| Back to top |
|
|
| smdavies99 |
| Posted: Tue May 31, 2011 9:24 pm Post subject: |
|
|
Jedi Council
Joined: 10 Feb 2003
Posts: 6076
Location: Somewhere over the Rainbow this side of Never-never land.
|
Vitor's statement does not conflict with what you quoted.
| Quote: |
WebSphere® Message Broker also stores information in LocalEnvironment in some circumstances, and references it to access values that you might have set for destinations.
|
This means that various bits of Broker (ie the Nodes) use the LocalEnvironment to hold flow settable params prior to using a node or to put output data from some notes for later use in the flow.
The Environment folder is created at the start of a thread. It stays with the thread until the thread dies.
The LocalEnvironment is like any other folder (eg properties, MQMD, SOAPHeader etc) in that it can be copied inside a ComputeNode from the Input Side to the Output Side. You can use the LocalEnvironment to hold flow data but you have to remember to enure that it is copied in ComputeNodes if you want to preserve it for more than one ComputeNode.
I treat the LocalEnvironment as a temp scratchpad OR as where I setup params for the next node (Eg EmailOutputNode) OR as where a node will put output data for later reference.
I treat the Environment as a longer term scratchpad. Typically I might put a BLOB copy of the received message so that my error handling can use it. OR it might contain Flow Specific Variables that might be referenced in any of the nodes in the Flow.
This is my personal preference. Others here may well disagree. They ways they used these folders are also perfectly valid.
_________________
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 |
|
|
| cutejigs |
| Posted: Mon Mar 25, 2013 4:47 pm Post subject: |
|
|
Novice
Joined: 20 Jan 2010
Posts: 20
|
hi guys, i think this post is old but i am a little bit confused on the Environment concept.
i have a flow which has the following nodes:
MQInput-> Compute Node 1-> TCPIPServer Output
TCPIPServer Input -> Compute Node 2 -> MQOutput
Compute Node 1 stores the variables in the Environment tree, i could also see that the values have been properly set until the message was sent to the TCPIPServer Output.
but when a message came in the TCPIPServer Input and Compute Node 2 and tries to access the Environment, it returns null. i have validated this using Trace node and Debug mode.
if the Environment tree is accessible thru the entire thread, does this mean that the TCPIPServer Input node created a new thread the reason why the Environment tree is empty?
btw, i am using WMB v8 in testing this one.
thanks! |
|
| Back to top |
|
|
| Esa |
| Posted: Mon Mar 25, 2013 11:50 pm Post subject: |
|
|
Grand Master
Joined: 22 May 2008
Posts: 1387
Location: Finland
|
Your flow diagram has two separate flows.
Yes, the TCPIPServer Input node starts it's own thread. |
|
| Back to top |
|
|
| McueMart |
| Posted: Tue Mar 26, 2013 1:13 am Post subject: |
|
|
Chevalier
Joined: 29 Nov 2011
Posts: 490
Location: UK...somewhere
|
| Quote: |
| Your flow diagram has two separate flows. |
Not necessarily two different flows (you can have as many input nodes as you want in a Flow - but it's often seen as bad practice to have more than 1), but of course Esa is right when he says that each input node will create it's own thread (meaning that you cant share information like this using the Environment).
You might want to look at SHARED variables or the Message Broker Global Cache. |
|
| Back to top |
|
|
| cutejigs |
| Posted: Tue Mar 26, 2013 3:59 pm Post subject: |
|
|
Novice
Joined: 20 Jan 2010
Posts: 20
|
thanks Esa and McueMart! that clarifies it.
basically what im trying to do is sending a message to a TCPIP Server and the same TCPIP Server will send me the response. however, i need to send the exact same headers to (Properties, MQMD and MQRFH2 if there is any) back to the MQOutput node. i thought that using the Environment tree will be the best way to preserve the headers.
need to find another way though 
cheers. |
|
| Back to top |
|
|
| Esa |
| Posted: Wed Mar 27, 2013 12:02 am Post subject: |
|
|
Grand Master
Joined: 22 May 2008
Posts: 1387
Location: Finland
|
If you can put something in the request message that you know the server is going to send you back, you can use it for correlating entries that you put in some storage (MQ queue, database, V8 global cache or a SHARED ROW tree).
If you are sure that there will never be simultaneous requests, you may just store the stuff without having to bother about correlation. A way to enforce this kind of single-threadness with a flow that is split into two is to create a single-threaded preprocessor flow that will call your flow pseudo-synhcronously with an MQOutput - MQGet sequence (plus the usual correlation stuff between the nodes).
The call to the TCPIP server is in fact synchronous, but it's implemented in an asynchronous manner if you use the TCPIPServer nodes.
Another way is to write about ten lines of java code in a java compute node. That will do a synchronous request and you dont need to split the flow in two or store data. |
|
| Back to top |
|
|
|
|
