| Author |
Message
|
| ollyc |
 Posted: Mon Jan 16, 2012 2:58 am Post subject: Struggling with subflows in v8 |
 |
|
Apprentice
Joined: 04 Dec 2009
Posts: 27
Location: England
|
Hi,
I've been trying to get library subflows to work in version 8, but haven't been able to get them to be decoupled from the application flows.
The documentation says:
| Quote: |
| If you deploy a library embedded in an application (the application refers to the library), and that library is not deployed to an execution group separately, the library is private; the library is not accessible to other applications or message flows outside the referring application. If you deploy a library separately to an execution group, that library is shared, and is accessible to other resources that are deployed to that execution group and not contained in an application. |
However, when I deploy an application that contains a reference to a library subflow, it always includes the library subflow in the local application rather than referring to the external library subflow.
This happens even if the library subflow is already deployed to the same execution group.
How do I get the application to reference the shared library subflow? is this possible?
thanks
Olly. |
|
| Back to top |
|
 |
| lancelotlinc |
| Posted: Mon Jan 16, 2012 6:19 am Post subject: |
|
|
Jedi Knight
Joined: 22 Mar 2010
Posts: 4941
Location: Bloomington, IL USA
|
I think I can speak to the theory. There may be room for a PMR if the theory and the reality are not matching up.
First, create a project which contains your library, build and deploy it to your EG.
Second, from your consumer flow's project, reference the library with a dependency in the second project to the first project.
_________________
http://leanpub.com/IIB_Tips_and_Tricks
Save $20: Coupon Code: MQSERIES_READER |
|
| Back to top |
|
|
| ollyc |
| Posted: Mon Jan 16, 2012 6:28 am Post subject: |
|
|
Apprentice
Joined: 04 Dec 2009
Posts: 27
Location: England
|
yes, that's exactly what I've tried and what I was hoping for - but the behaviour seems to be very similar to v7 and earlier (subflows are local to flows).
I'll raise a PMR as I'm sure I'm either doing something wrong or something's broken. |
|
| Back to top |
|
|
| mqjeff |
| Posted: Mon Jan 16, 2012 6:33 am Post subject: |
|
|
Grand Master
Joined: 25 Jun 2008
Posts: 17447
|
This may also merely be a 'visualization' problem. That is, it may be that the library is displayed as a library reference under the application, but not actually deployed separately under the application.
I.e. what you see in the runtime under the application may just be a pointer - but it shows up as a visible object so that you know that it's there. |
|
| Back to top |
|
|
| ollyc |
| Posted: Mon Jan 16, 2012 6:39 am Post subject: |
|
|
Apprentice
Joined: 04 Dec 2009
Posts: 27
Location: England
|
Thanks for the suggestion, I did test for whether the subflow behaved as if it was local or not - i.e. I updated the subflow and deployed directly to the library and then ran a test message through the application flow.
But the output of the application flow did not reflect the changes to the subflow.
When I made a further change to the subflow and redeployed the application I did get the latest version of the output. |
|
| Back to top |
|
|
| jlaisbett |
| Posted: Mon Jan 16, 2012 11:30 am Post subject: |
|
|
Apprentice
Joined: 27 Nov 2009
Posts: 39
|
How I believe it works (and I could be wrong) is anything in a library that is deployed directly to the execution group can be shared by any flows and updated independently.
If however you use flows in an application then it can't see shared libraries and can only see the embedded copies of the library that is deployed inside the application.
Based on that using a library for shared code that doesnt need the flows that use it to be redeployed only works if those flows aren't in an application. |
|
| Back to top |
|
|
| fjb_saper |
| Posted: Mon Jan 16, 2012 12:30 pm Post subject: |
|
|
Grand High Poobah
Joined: 18 Nov 2003
Posts: 20756
Location: LI,NY
|
| jlaisbett wrote: |
How I believe it works (and I could be wrong) is anything in a library that is deployed directly to the execution group can be shared by any flows and updated independently.
If however you use flows in an application then it can't see shared libraries and can only see the embedded copies of the library that is deployed inside the application.
Based on that using a library for shared code that doesnt need the flows that use it to be redeployed only works if those flows aren't in an application. |
Don't quite seem to recall it working that way.
I'm sure either Jeff or Matt will set us straight. 
_________________
MQ & Broker admin |
|
| Back to top |
|
|
| ollyc |
| Posted: Wed Jan 18, 2012 7:48 am Post subject: |
|
|
Apprentice
Joined: 04 Dec 2009
Posts: 27
Location: England
|
I raised a PMR and got this response back:
| Quote: |
I think that there is a misunderstanding of how the libraries are
supported in V8 GA.
If a Library is used by the application it can only be deployed within
the application. So if the changes are made to the subflow in the
library that belongs to the application then the changes will only be
visible when the parent application is deployed.
The same library can be deployed independently. But in this case the
referencing application will not see the artifacts in the library
deployed independently. Only the library artifacts deployed with the
application are available within the application scope.
As I understand sharing independently deployed libraries by multiple
applications is not supported.
If you need more information please contact Broker runtime support.
|
This reflects the behaviour I'm seeing in the application, but this is not what help pages say.
I think it might be the case that the support for subflows was not fully implemented in when v8 went GA. i.e. IBM are planning for subflows to be shareable in a future fix pack.
Anyway I followed up with more questions:
| Quote: |
1. if an application cannot access an independently deployed library
then what can? (e.g. a normal flow?)
2. if nothing can access an independent library is there any point in
deploying them?
3. in version 7 all subflows are effectively local to an application or
flow - it looks like this hasn't really changed - can you confirm?
4. Will the current behaviour be changing, e.g. to allow applications
to reference independently deployed libraries?
5. If the answer to 4 is "yes", when will this happen? |
From the response it sounds like other customers are having similar queries - I'll post more information when I get it. |
|
| Back to top |
|
|
| ollyc |
| Posted: Thu Jan 19, 2012 4:50 am Post subject: |
|
|
Apprentice
Joined: 04 Dec 2009
Posts: 27
Location: England
|
i got the following back:
| Quote: |
1. if an application cannot access an independently deployed
library then what can? (e.g. a normal flow?)
There's no such a thing as an independently deployed Library. A
Library deployed at the Execution Group level is effectively
contained by a default Application at that EG level. Unfortunately
it's not obvious that this is the case.
This means that only flows deployed at EG level can access Libraries
deployed at the EG level.
An Application is a unit of runtime isolation and it cannot access
resources outside of the Application.
So an (explicitly deployed) Application (together with its contained
Libraries) cannot access any other Library deployed at EG level
because this would break the principle of isolation.
2. if nothing can access an independent library is there any point in
deploying them?
As for question 1. There is only the illusion of an independent
Library at EG level - it is in fact contained by a default
Application and therefore isolated from other Applications
deployed to the same EG.
3. in version 7 all subflows are effectively local to an application or
flow - it looks like this hasn't really changed - can you confirm?
A subflow is just another resource within An Application and
access is restricted to the scope of that Application.
So while the subflow cannot be shared by flows in other Applications
it can be shared by flows within an Application. Please note that
there is an Open APAR related to this as referred to earlier.
4. Will the current behavior be changing, e.g. to allow applications
to reference independently deployed libraries?
Allowing libraries to be shared between Applications is a potential
enhancement. If you feel this important to your business model, please
can you raise an MQ requirement through your IBM representative.
This will enable us to prioritize future enhancements with
consideration to customer feedback.
|
So it doesn't do what I was expecting 
from jlaisbett:
| Quote: |
| How I believe it works (and I could be wrong) is anything in a library that is deployed directly to the execution group can be shared by any flows and updated independently. |
i also tried calling a library subflow from a standard flow and then updating the subflow.
This didn't work - I had to delete the main flow before the library subflow could be updated. |
|
| Back to top |
|
|
| jhosie |
| Posted: Thu Jan 19, 2012 11:53 am Post subject: |
|
|
Apprentice
Joined: 12 May 2005
Posts: 28
|
The latest problem you encountered about upgrading the subflow (while it is still in use) is a known bug. You should raise a PMR on this.
Beside that point, I hope I can help you to understand when to use libraries, when to use applications and when to use both.
Applications are a container of flows and the resources needed by those flows - and provide some level of isolation. If you want to be able to group your resources (and flows) in such a way that any updates to one group do not affect other groups, then applications are right for you.
For example, when you roll out V2 of some ESQL or subflows, do you want to maintain control of which flows pick up that version? Do you want to restrict it to only those flows which have been tested by V2 or do you want to always roll it out wholesale?
If the former, then use applications, if the later then don't.
Libraries are a container of flows and/or resources but do not provide isolation. Libraries can be useful for re-use of artifacts or simply to group artifacts together for ease of management (through both AD and operational environments). In general, you will almost always have at least one of these objectives so libraries are a good practice in most cases.
Using libraries without applications - as you are now doing - gives you the benefit of packaging related flows together for ease of management. You can package subflows for re-use and the dependency relationship can span libraries. (flows in one library sees all resources in other libraries) This allows you roll out updates of the re-used library to all dependents in one go.
If you do need to use applications but you also want to roll out a library upgrade to several applications in one shot - then the best you can do in V8.0.0.0 is to code this into your build scripts. Your scripts would take the latest version of the library from your change management system, take the latest tested version of all apps, build the apps and deploy them.
This may not fit with your operational practices and besides, there are other valid reasons for requiring that the runtime instances of the applications share a single runtime instance of the library. If this is the case, then I suggest that you contact IBM Development and/or raise a formal requirement through your IBM account team. I know the development team are already aware of this requirement so they would be interested to hear from you.
btw - I think the section of the docs that you quoted in your original post needs to be simplified and clarified. I had to read it a few times to satisfy myself that it was correct and I am still not sure. It is slightly ambiguous at best. I have provided feedback to the documentation owners to improve this.
I hope this helps. |
|
| Back to top |
|
|
| ollyc |
| Posted: Fri Jan 20, 2012 4:58 am Post subject: |
|
|
Apprentice
Joined: 04 Dec 2009
Posts: 27
Location: England
|
Thanks jhosie, IBM support have confirmed a problem with updating subflows.
I think using flows (rather than applications) + library subflows will give us the functionality we need - I'll test it further when we get a patch. |
|
| Back to top |
|
|
| NealM |
| Posted: Tue Jan 08, 2013 2:36 am Post subject: |
|
|
Master
Joined: 22 Feb 2011
Posts: 230
Location: NC or Utah (depends)
|
jhosie 12 months ago said:
| Quote: |
| The latest problem you encountered about upgrading the subflow (while it is still in use) is a known bug. You should raise a PMR on this. |
So, did FP 1 fix this issue? If not, is (overdue) FP 2 supposed to? |
|
| Back to top |
|
|
| smdavies99 |
| Posted: Tue Jan 08, 2013 4:25 am Post subject: |
|
|
Jedi Council
Joined: 10 Feb 2003
Posts: 6076
Location: Somewhere over the Rainbow this side of Never-never land.
|
If you read some of the other and more recent posts on related topics you might see that
1) there is a workaround for the access to subflows
2) A fix is planned for 8.0.0.2
If there is an iFix for this then raise a PMR on the point and I am sure that IBM will be only too happy to send it to you.
I wasn't expecting 8.0.0.2 until the end of Q1/13 at the very least
_________________
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 |
|
|
| NealM |
| Posted: Tue Jan 08, 2013 8:51 am Post subject: |
|
|
Master
Joined: 22 Feb 2011
Posts: 230
Location: NC or Utah (depends)
|
| Quote: |
If you read some of the other and more recent posts on related topics you might see that
1) there is a workaround for the access to subflows
2) A fix is planned for 8.0.0.2 |
Thanks for the info. In my defense, I did search on keywords "subflow", "migrate" and "8.0.0.2" before re-opening this aged topic, saw nothing conclusive on any (although the "subflow" search said there were 3,810 matches, it actually only returned the first 10 pages worth, so maybe the answer is out there someplace....). I chose to reopen this thread as it had the most detail on the topic.
I have yet to find the workaround reference that you mentioned, unless you mean not using applications and only referencing common subflows (and common message sets, etc) libraries from broker projects. Which is our intention anyway since the current (8.0.0.1) definition of an application says it needs be self contained, and our stuff is heavy into sharing anything common.
And I do see that IBM has recently updated their WMB planned maintenance release dates now, moving FP 2 from 4Q 2012 to 1Q 2013, so I can no longer say it is late. |
|
| Back to top |
|
|
| mqjeff |
| Posted: Tue Jan 08, 2013 9:03 am Post subject: |
|
|
Grand Master
Joined: 25 Jun 2008
Posts: 17447
|
| NealM wrote: |
| And I do see that IBM has recently updated their WMB planned maintenance release dates now, moving FP 2 from 4Q 2012 to 1Q 2013, so I can no longer say it is late. |
"Planned" != "Promised".
Also, you might want to review Using the conversion wizard |
|
| Back to top |
|
|
|
|
