| |
|
RSS Feed - WebSphere MQ Support
|
RSS Feed - Message Broker Support
|
  |
|
| subflows and variable scope |
« View previous topic :: View next topic » |
| Author |
Message
|
| chrisc |
 Posted: Wed Nov 17, 2010 5:10 pm Post subject: subflows and variable scope |
 |
|
Voyager
Joined: 19 Mar 2006
Posts: 77
|
Sorry, I know this is resurrecting an older thread (over a month old) but I have been investigating a similar problem for a while here at the client where I work and I personally think there is a bit of a flaw in the design of the UDP scope in the Broker.
An example...
We have a main flow that has a promoted user defined property, say MyUDP.
We also have a subflow that has a promoted ESQL snippet (promoted from a Database node), so the ESQL itself appears in the main flow's ESQL file. The sub-flow is a black box, and the promoted ESQL is to allow the main flow to configure aspects of the sub-flow.
In this snippet we declare the variable that picks up the UDP, or defaults it to 'Undefined' if it isn't set, i.e.:
| Code: |
| DECLARE MyUDP EXTERNAL CONSTANT CHAR 'Undefined'; |
Now I can understand that the ESQL that is internal to the subflow shouldn't have access to the UDPs of any parent flow, but in this case I would have thought the ESQL was promoted to, and therefore should be in the scope of, the main flow - hence able to access its UDPs.
That's clearly not the case, though, because the default value of 'Undefined' is always picked up, whereas in a piece of ESQL from the main flow that is not promoted from a sub-flow can pick it up fine.
At the moment, the only obvious way we can get around this is to store the main flow's UDP in a the Environment, then pull it from that place in the Environment in the promoted ESQL module. It seems redundant, given all the code is located in the same place and it's all under the control of the main flow.
Is there any intention of "fixing" this in a future version? It seems like a pretty logical thing to do to make the scope of any executed piece of code be the same as the final, promoted destination rather than the place it is executed.
Cheers,
Chris |
|
| Back to top |
|
 |
| fjb_saper |
| Posted: Wed Nov 17, 2010 8:55 pm Post subject: |
|
|
Grand High Poobah
Joined: 18 Nov 2003
Posts: 20756
Location: LI,NY
|
So you would want to be able to see variables that are in the main flow when in the subflow... kind of main flow scope....
Looks like you're out of luck as this is not even possible in the main flow.
AFAIK
- The variable is defined as external and then is in scope for the part it is declared in...
- The variable is declared as shared and is in scope across multiple invocations within the same flow.
- There is no scope across nodes if the variable has been declared inside a node.
- To get the scope across the nodes you need to define your variable in the ESQL outside of any node / procedure /function. The scope is then that of the flow instance for an EXTERNAL variable or the flow across instances for a SHARED variable. You may combine EXTERNAL SHARED.
- Anything else that needs to be passed from node to node needs to be passed in the Environment or LocalEnvironment trees.
This is nothing new and the behavior is consistent. So why would you want to change it? If you need a property to be available to both main and subflow you can always promote it.
Have fun 
_________________
MQ & Broker admin |
|
| Back to top |
|
|
| chrisc |
| Posted: Wed Nov 17, 2010 9:17 pm Post subject: |
|
|
Voyager
Joined: 19 Mar 2006
Posts: 77
|
Hmm, not sure if I quite explained it properly.
Perhaps an example would illustrate why it looks wrong...
| Code: |
-- This module belongs to a node in the main flow
CREATE DATABASE MODULE Main_Flow_AccessUDP
DECLARE MyUDP EXTERNAL CONSTANT CHAR 'Undefined';
CREATE FUNCTION Main() RETURNS BOOLEAN
BEGIN
SET Environment.StoreValue = MyUDP; -- Assigns the actual UDP value
END;
END MODULE;
-- This module belongs to a node in the main flow
CREATE DATABASE MODULE PromotedFromSubflow_AccessUDP
DECLARE MyUDP EXTERNAL CONSTANT CHAR 'Undefined';
CREATE FUNCTION Main() RETURNS BOOLEAN
BEGIN
SET Environment.StoreValue = MyUDP; -- Assigns the value 'Undefined';
END;
END MODULE;
|
As you can see, the module code looks identical in both cases, and belongs to the same ESQL file attached to the same main flow. And yet because the promoted ESQL is executed in the sub-flow, it behaves differently because the scope is different.
It may not be anything new, but it still seems counter-intuitive given the sub-flow ESQL was (or should have been, IMHO) promoted to the same level as the UDP was defined in.
Cheers,
Chris |
|
| Back to top |
|
|
| fjb_saper |
| Posted: Thu Nov 18, 2010 6:46 am Post subject: |
|
|
Grand High Poobah
Joined: 18 Nov 2003
Posts: 20756
Location: LI,NY
|
| chrisc wrote: |
Hmm, not sure if I quite explained it properly.
Perhaps an example would illustrate why it looks wrong...
| Code: |
-- This module belongs to a node in the main flow
CREATE DATABASE MODULE Main_Flow_AccessUDP
DECLARE MyUDP EXTERNAL CONSTANT CHAR 'Undefined';
CREATE FUNCTION Main() RETURNS BOOLEAN
BEGIN
SET Environment.StoreValue = MyUDP; -- Assigns the actual UDP value
END;
END MODULE;
-- This module belongs to a node in the main flow
CREATE DATABASE MODULE PromotedFromSubflow_AccessUDP
DECLARE MyUDP EXTERNAL CONSTANT CHAR 'Undefined';
CREATE FUNCTION Main() RETURNS BOOLEAN
BEGIN
SET Environment.StoreValue = MyUDP; -- Assigns the value 'Undefined';
END;
END MODULE;
|
As you can see, the module code looks identical in both cases, and belongs to the same ESQL file attached to the same main flow. And yet because the promoted ESQL is executed in the sub-flow, it behaves differently because the scope is different.
It may not be anything new, but it still seems counter-intuitive given the sub-flow ESQL was (or should have been, IMHO) promoted to the same level as the UDP was defined in.
Cheers,
Chris |
Have you tried moving the declaration to a flow scope like:
| Code: |
DECLARE MyUDP EXTERNAL CONSTANT CHAR 'Undefined';
CREATE DATABASE MODULE Main_Flow_AccessUDP
CREATE FUNCTION Main() RETURNS BOOLEAN
BEGIN
SET Environment.StoreValue = MyUDP; -- Assigns the actual UDP value
END;
END MODULE;
|
Have fun
_________________
MQ & Broker admin |
|
| Back to top |
|
|
| chrisc |
| Posted: Thu Nov 18, 2010 4:18 pm Post subject: |
|
|
Voyager
Joined: 19 Mar 2006
Posts: 77
|
| fjb_saper wrote: |
Have you tried moving the declaration to a flow scope like:
| Code: |
DECLARE MyUDP EXTERNAL CONSTANT CHAR 'Undefined';
CREATE DATABASE MODULE Main_Flow_AccessUDP
CREATE FUNCTION Main() RETURNS BOOLEAN
BEGIN
SET Environment.StoreValue = MyUDP; -- Assigns the actual UDP value
END;
END MODULE;
|
Have fun |
Unfortunately that's not moving it to flow scope, it's moving it to namespace scope. So even if this did work (and I haven't actually tried it), but it creates namespace pollution where any other flow in that namespace that happens to declare a variable with the same name will cause a compilation error.
And if it's in namespace scope, and there are multiple flows that declare a UDP with the same name, e.g. something generic like RESPONSE_QUEUE, then how would it know which UDP I actually wanted to access with that variable?
Cheers,
Chris |
|
| Back to top |
|
|
| fjb_saper |
| Posted: Thu Nov 18, 2010 8:31 pm Post subject: |
|
|
Grand High Poobah
Joined: 18 Nov 2003
Posts: 20756
Location: LI,NY
|
| chrisc wrote: |
| fjb_saper wrote: |
Have you tried moving the declaration to a flow scope like:
| Code: |
DECLARE MyUDP EXTERNAL CONSTANT CHAR 'Undefined';
CREATE DATABASE MODULE Main_Flow_AccessUDP
CREATE FUNCTION Main() RETURNS BOOLEAN
BEGIN
SET Environment.StoreValue = MyUDP; -- Assigns the actual UDP value
END;
END MODULE;
|
Have fun |
Unfortunately that's not moving it to flow scope, it's moving it to namespace scope. So even if this did work (and I haven't actually tried it), but it creates namespace pollution where any other flow in that namespace that happens to declare a variable with the same name will cause a compilation error.
And if it's in namespace scope, and there are multiple flows that declare a UDP with the same name, e.g. something generic like RESPONSE_QUEUE, then how would it know which UDP I actually wanted to access with that variable?
Cheers,
Chris |
My mistake. I get your point. However would you not have a limited number of flows in the same namespace? Or do you not use namespace at all where the flows are concerned? (That would give you at least namespace scope = eg scope...)
Why would you want a name as generic as response queue? You will have to overwrite the correct value either with bar override (scripting) or manually anyways for the UDP. Why not specify a real queue name that can then be modified according to the environment. It certainly gets rid of the confusion if you have multiple flows with the same need (defining a response queue) in the same scope.
And yes it may make your scripting a little bit more complicated with specific values instead of generic ones... but at this point it is all about convention and the number of scripts / routines you will need to write.
Anyways the biggest difference on the different reply to queues should be the permissions... The broker doesn't care so much as I expect it to read the message by correlId... for a synchronous scenario.
If talking about an asynchronous scenario wouldn't you expect some kind of routing by message type?
Getting more confused by the minute...
_________________
MQ & Broker admin |
|
| Back to top |
|
|
|
|
|
| |
|
Page 1 of 1 |
|
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
|
|
|
|
