Change flow parameters directly in flow XML?

[magnussandstrom]

We are transitioning to DFS paths (from static UNC) in our server environment and I need to change ALOT of paths in my Switch flows. Instead of doing this manually 'flow by flow' I was thinking that maybe I can change this in an editor using search and replace directly in the flow XML-files in Data_Root\flows.

My plan is to do the following:
1. Stop flows,
2. Search for the legacy path in the flow XML-files with FileLocator Pro and replace them with DFS-paths with Notepad++
3. Saving the flow xml's
4. Starting the flows

Is this a valid approach or is there a checksum or something that will break the flows?

[patej]

We had a similar case where the server name was changed so UNC paths had to be modified in hundreds of places. On another occasion we moved our PS action list location and we managed to change those in batch, too.

We did as you outlined + server reboot before starting the flows, but if I remember correctly (it was ~7 years ago…), there were some problems that not all flows activated correctly until we had done an extra reboot round… But in general that process should work, although not in any way an official or supported way to do it...

[freddyp]

Make a backup before you do this and do not come crying if you skin your knees

If you are going to change a lot of settings anyway, consider using this app: https://www.enfocus.com/en/appstore/product/global-data. Instead of using fixed values here and there you always use a dataset/private data and in the beginning of the flow you get the values from global data. It has the advantage that all values come from one location. The downside is that you have to add the getting of the global data to (almost) every flow in the beginning and you have to set something up to manage the values.

[patej]

If you are going to change a lot of settings anyway, consider using this app: https://www.enfocus.com/en/appstore/product/global-data. Instead of using fixed values here and there you always use a dataset/private data and in the beginning of the flow you get the values from global data. It has the advantage that all values come from one location. The downside is that you have to add the getting of the global data to (almost) every flow in the beginning and you have to set something up to manage the values.

…if only you could define e.g. Archive hierarchy path as private data That we've wished for years because currently we need one Archive hierarchy for each file server. That Global Data is a good one for many users, but we're working with multiple Switch servers so global data isn't ideal, therefore, we store many settings etc. in our own database, but these paths for Submit/Archive hierarchies are one thing that's hard to go around…

[patej]

But in general that process should work, although not in any way an official or supported way to do it...

Just came to mind that I have no idea if there has been developed any "security measures" to prevent this in the last few years because it's a while since we did that last time… Good luck and keep us updated if you decide to try it!

[freddyp]

…if only you could define e.g. Archive hierarchy path as private data

There is an app for that: https://www.enfocus.com/en/appstore/product/store-it

I agree it should be in Archive hierarchy.

[patej]

…if only you could define e.g. Archive hierarchy path as private data

There is an app for that: https://www.enfocus.com/en/appstore/product/store-it

I agree it should be in Archive hierarchy.

Oh, yeah, I had forgotten about that. It's a pity that users have to create workarounds for features that should be in the built-in elements/apps… We had considered that, too, but decided to continue with Archive hierarchy. I hope the development of Archive hierarchy hasn't been stopped because there is an alternative on app store? Regarding third-party apps, for us it always requires more careful consideration to begin using those than Enfocus-developed ones, to ensure that we don't end up in a situation where support ends and we're left with a big mess or even no other option than to recreate the app ourselves (speaking of experience…).

[tdeschampsBluewest]

Hi there,
Global data could work great, one flow creating global, and other flow restoring it before use!

But as we talked about it together recently, having a property directly in switch to have something like this could be a real game changer for some flow conception:

Code: Select all

[Switch.GlobalData.text:name="myGlobalData", scope="Global"]

May we ask it as a christmas gift for switch 2024 fall?

[mkayyyy]

Hi there,
Global data could work great, one flow creating global, and other flow restoring it before use!

But as we talked about it together recently, having a property directly in switch to have something like this could be a real game changer for some flow conception:

Code: Select all

[Switch.GlobalData.text:name="myGlobalData", scope="Global"]

May we ask it as a christmas gift for switch 2024 fall?

Adding this to my Christmas wish list as well

[jan_suhr]

I do my Feature request to a Support issue, then it get booked in the system and sent to the proper channel at Enfocus.

One such feature request would be to have a proper feature request page on the Enfocus website.

[sander]

+1 for the Christmas Gift haha!

Like!

[magnussandstrom]

+1 for the Christmas Gift. Global data at Switch server level would be a great tool!

[patej]

I do my Feature request to a Support issue, then it get booked in the system and sent to the proper channel at Enfocus.

…and the feature request goes into a black hole you never hear from again and you can't follow its progress...

One such feature request would be to have a proper feature request page on the Enfocus website.

I've made this kind of a request, or more specifically a site where users can also see each others' requests and comment on them, too. Something similar to e.g. Esko Ideas. Currently, many users might request similar things without the knowledge of each other and/or they might have something to contribute to an existing request which would help its development, too. Also Enfocus developers could ask for clarifications or request testing etc.

[Soul Forge]

Hi there,
Global data could work great, one flow creating global, and other flow restoring it before use!

But as we talked about it together recently, having a property directly in switch to have something like this could be a real game changer for some flow conception:

Code: Select all

[Switch.GlobalData.text:name="myGlobalData", scope="Global"]

May we ask it as a christmas gift for switch 2024 fall?

+1

I've been dreaming day and night for this

[germen@grafistore.nl]

+1 for me too!

We really see a need for dynamic lists from Global Data in Submit points. Standard it is not possible.
Often the Database Module and Scripting Module are overkill only to have them for this feature.