| Author |
Message
|
| JohnSmith |
 Posted: Tue Jun 01, 2010 5:51 am Post subject: changes in the subflow can reflect in all the main flows? |
 |
|
Voyager
Joined: 17 Mar 2010
Posts: 86
|
All, another challenge we are facing currently is we are having a N number of flows all using a particular subflow(lets say X). All these flows are running fine in an execution group.
Now, there has been some changes made in this flow X, now the question is 1. Do we need to deploy all the N flows again after re-building them ??
2. OR is there any way we can only deploy 1 of the main flow with the changes in this subflow and it gets reflected across all the flows in that execution group(whoever is using this subflow).
As building N bar files for N number of flows seems quite a daunting task.
Please share if you have any suggestions.
Regards, |
|
| Back to top |
|
 |
| zpat |
| Posted: Tue Jun 01, 2010 6:01 am Post subject: |
|
|
Jedi Council
Joined: 19 May 2001
Posts: 5866
Location: UK
|
Subflows are build-time concept not run-time.
Every flow using a sub-flow includes the sub-flow into its logic when it is built. |
|
| Back to top |
|
|
| JohnSmith |
| Posted: Tue Jun 01, 2010 7:04 am Post subject: |
|
|
Voyager
Joined: 17 Mar 2010
Posts: 86
|
| Quote: |
Subflows are build-time concept not run-time.
Every flow using a sub-flow includes the sub-flow into its logic when it is built. |
Hi zpat, It means I have to build each and every main flow(which is using this subflow) and deploy it again
Regards, |
|
| Back to top |
|
|
| Vitor |
| Posted: Tue Jun 01, 2010 7:19 am Post subject: |
|
|
Grand High Poobah
Joined: 11 Nov 2005
Posts: 26093
Location: Texas, USA
|
| JohnSmith wrote: |
| It means I have to build each and every main flow(which is using this subflow) and deploy it again |
It does. 
This is why you automate the build process. Most sites have common sub-flows that handle errors, logging and so forth. A lot of sites use sub flows for different business areas. All these changes mean the main flows need rebuilding.
_________________
Honesty is the best policy.
Insanity is the best defence. |
|
| Back to top |
|
|
| mqjeff |
| Posted: Tue Jun 01, 2010 7:34 am Post subject: |
|
|
Grand Master
Joined: 25 Jun 2008
Posts: 17447
|
| Vitor wrote: |
| JohnSmith wrote: |
| It means I have to build each and every main flow(which is using this subflow) and deploy it again |
It does.
This is why you automate the build process. Most sites have common sub-flows that handle errors, logging and so forth. A lot of sites use sub flows for different business areas. All these changes mean the main flows need rebuilding. |
It *also* means that if you make a change to a subflow that is used by *every* main flow, that you can TEST that change against EACH mainflow in an orderly fashion, and don't have to regression test your entire infrastructure all at once. |
|
| Back to top |
|
|
| zpat |
| Posted: Tue Jun 01, 2010 7:44 am Post subject: |
|
|
Jedi Council
Joined: 19 May 2001
Posts: 5866
Location: UK
|
You have to rebuild each main flow that needs the new function from the subflow, or requires the latest version for some other reason.
If the mainflow will work with its existing copy of the subflow then it does not require a rebuild.
It depends how easy it is to test everything, I am not a fan of the constantly rebuild everything and retest approach (because the automated testing, if it even exists, is unlikely to be comprehensive enough).
It's a bit like re-assembling and road-testing your entire fleet of cars, because one of them had a tyre change!
For this reason you may prefer to run your common flows, not as sub flows, but as separate main flows, which execute independently and therefore do not form part of other flows.
Then you can pass them the rogue messages to deal with, or whatever function they perform. |
|
| Back to top |
|
|
| Vitor |
| Posted: Tue Jun 01, 2010 8:14 am Post subject: |
|
|
Grand High Poobah
Joined: 11 Nov 2005
Posts: 26093
Location: Texas, USA
|
| zpat wrote: |
| If the mainflow will work with its existing copy of the subflow then it does not require a rebuild. |
This is a good point - you should attempt to enforce "backward compatibility" on your sub flows.
| zpat wrote: |
| It depends how easy it is to test everything, I am not a fan of the constantly rebuild everything and retest approach (because the automated testing, if it even exists, is unlikely to be comprehensive enough). |
It's easy enough to cover the basic functions and business logic. The Hudson builds referred to earlier work rather well.
| zpat wrote: |
| It's a bit like re-assembling and road-testing your entire fleet of cars, because one of them had a tyre change! |
It's more like filling one with ethanol because you need to and proving it'll work but leaving the others with the regular gas in their tanks until they need a top up.
| zpat wrote: |
For this reason you may prefer to run your common flows, not as sub flows, but as separate main flows, which execute independently and therefore do not form part of other flows.
Then you can pass them the rogue messages to deal with, or whatever function they perform. |
This too is a viable strategy.
_________________
Honesty is the best policy.
Insanity is the best defence. |
|
| Back to top |
|
|
|
|
