| |
|
RSS Feed - WebSphere MQ Support
|
RSS Feed - Message Broker Support
|
  |
|
| Any MB8 "rules of thumb" for library subflows |
« View previous topic :: View next topic » |
| Author |
Message
|
| NealM |
 Posted: Thu Apr 04, 2013 2:06 pm Post subject: Any MB8 "rules of thumb" for library subflows |
 |
|
Master
Joined: 22 Feb 2011
Posts: 230
Location: NC or Utah (depends)
|
Hi, I've been through the MB8.0.0.2 infoCenter trying to find any restrictions on subflows in a shared library.  Can't find anything. (I mean truly shared. There are no Applications, just Libraries and Broker Projects that heavily use several common subflows from the deployed libraries)
 Before I build some experiments I thought I'd ask if anyone else has tried the following:
1. A node property promoted to the subflow's top level. For instance, an MQOutput Node's Queue name. Several different broker projects use the subflow, each assigning a unique output queue name.
2. UDPs promoted to the subflow's top level. And each broker project that uses the subflow assigns a unigue value to these user-defined properties, all different than the default value (that MB8 now forces the UDP to have).
3. Any others that I haven't thought about yet but someone else on this forum has.
Thanks |
|
| Back to top |
|
 |
| NealM |
| Posted: Fri Apr 05, 2013 12:19 pm Post subject: |
|
|
Master
Joined: 22 Feb 2011
Posts: 230
Location: NC or Utah (depends)
|
Well, no responses, so I had to build some experimental flows and answer my own questions.
Here is what I did:
1. I created a new Experiments_Library library, with one simple subflow, OutQueue_sub.subflow, which consists of an Input Terminal, a Compute Node named Try_UDP and an MQ Output Node.
1a. The Try_UDP node has a UDP declared with a 'SubflowDefault' default value. The Node's ESQL has the matching EXTERNAL declaration with a 'ESQLLevelDefault' default value. The ESQL places the UDP value into an output message.
1b. The MQ Output Node has no values filled in; The Queue name property is promoted to the (sub)flow level. At the subflow level I assigned a queue name of NEAL.OUT.DEFAULT to the promoted property.
1c. I then created and deployed a bar file for this library to an empty EG.
2. I created a new Experiment2_MFP broker project, added the Experiments_Library to it as a library reference.
2a. I created two simple flows, each with an MQInput Node connected to the OutQueue_sub.subflow. The first flow had queue NEAL.IN.TRY1 as it's input, the second used NEAL.IN.TRY2
2b. In the first flow I put the queue name NEAL.OUT.TRY1 in the promoted MQOutput Node's property, and a 'Try1' in the subflow's UDP property value. The 2nd flow got ...TRY2 and 'Try2' values in those fields.
2c. I then created a bar file for these two flows. Before deploying however, I deleted the Experiments_Library that got pulled into the bar.
3. I then used RFHUTILC.exe to place a simple message on each input queue
3a. The message that I placed on NEAL.IN.TRY1 went to NEAL.OUT.TRY1 and had been updated with the correct 'Try1' UDP value.
3b. The message that I placed on NEAL.IN.TRY2 went to NEAL.OUT.TRY2 and had been updated with the correct 'Try2' UDP value.
So, my conclusion is, IBM did a pretty good job with these shared libraries. They act like reentrant code. Promoted properties and UDP values unique to an independent Broker Project do not effect those set by another broker project using the same objects.
 |
|
| Back to top |
|
|
| whiting |
| Posted: Tue Apr 09, 2013 4:41 am Post subject: Didn't work for me |
|
|
Acolyte
Joined: 26 Mar 2002
Posts: 64
Location: Greenville, SC
|
I tried to duplicate your experiment, but the toolkit tells me that I can't override the properties of a .subflow
Do you have a fixpack applied to your toolkit? |
|
| Back to top |
|
|
| mqjeff |
| Posted: Tue Apr 09, 2013 5:03 am Post subject: Re: Didn't work for me |
|
|
Grand Master
Joined: 25 Jun 2008
Posts: 17447
|
| whiting wrote: |
I tried to duplicate your experiment, but the toolkit tells me that I can't override the properties of a .subflow
Do you have a fixpack applied to your toolkit? |
First off, anything dealing with subflows should be using 8.0.0.2. There are a number of unfortunate APAR that are fixed in 8.0.0.2 that will make using subflows before that difficult at best.
Secondly, you would apply properties and override properties on the instance of the subflow in the message flow, not on the subflow file itself.
That's how Neal's experiment works - the properties are not in any way attached to the subflow itself, they are attached to the flow that uses the subflow. Many containers, each holding one set of properties, rather than one container holding many sets of properties. |
|
| Back to top |
|
|
| NealM |
| Posted: Tue Apr 09, 2013 5:22 am Post subject: |
|
|
Master
Joined: 22 Feb 2011
Posts: 230
Location: NC or Utah (depends)
|
whiting, here is my current Toolkit level:
Version: 8.0.0.2
Build id: 8.0.0.2-20130322-1723
But, I had subflows with promoted properties prior to FP2. In fact most of our many subflows were imported from WMB v6.1 and converted, without any issues. These features aren't new, what is new is the concept of sharing one deployed copy of the subflow across several libraries or independent resources at runtime. Prior to MB8, each using flow would have it's own copy of the subflow deployed.
Which part are you having problems with, the UDP or the promoted Queue name? (We also have subflows with UDPs within subflows, thus using UDPs as promoted properties) |
|
| Back to top |
|
|
| whiting |
| Posted: Wed Apr 10, 2013 4:57 am Post subject: fixed |
|
|
Acolyte
Joined: 26 Mar 2002
Posts: 64
Location: Greenville, SC
|
I installed fp2 and that solved the problem.
Thanks! |
|
| 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
|
|
|
|
