Archive hierarchy (offline paths)

[magnussandstrom]

I have a couple of flows (with many different output folders) where some outputs is not always online. For example I have a few flows that sending files to a Fiery Command Workstation DFE. During the weekends the Fiery server is shut down, and it's happens to be during the weekends I do maintenance and updates on our Switch server. And when I restart Switch and the Fiery is down I cannot start these certain flows. But since the flows have many other outputs I would prefeer to be able to start the flows anyway (and if a files is sent to the offline Fiery I would like it to go to problem jobs).

So to my question:

Is it possible to setup a flow that have an offline output paths but still be able to start the flow some how?

[patej]

Not to my knowledge. I have requested it years ago, but haven't heard from it since…

It is a problem for us, too, and we currently only have a workaround where we have a separate flow for such output folders that can be offline. This way, the main output flow can always be activated and jobs going to those possibly offline folders are routed (using our own script, but similar to switch2switch/flow links etc) to this other flow and go to problem jobs if the other flow isn't activated.

[Padawan]

I have a done a quick and dirty workaround for this by removing the folder elements and using Execute Command/Run Command to move the job to the output folder.

Since the actual output folder is not in the flow Switch will allow you to activate the flow.

Of course, it is possible to have a Switch script which does this in a cleaner way.

[mkayyyy]

Not to my knowledge. I have requested it years ago, but haven't heard from it since…

It is a problem for us, too, and we currently only have a workaround where we have a separate flow for such output folders that can be offline. This way, the main output flow can always be activated and jobs going to those possibly offline folders are routed (using our own script, but similar to switch2switch/flow links etc) to this other flow and go to problem jobs if the other flow isn't activated.

I also requested this awhile ago but haven't heard anything since. In my request I asked if it would be possible to keep retrying sending jobs to the output folder rather than moving them to Problem jobs

[patej]

Not to my knowledge. I have requested it years ago, but haven't heard from it since…

It is a problem for us, too, and we currently only have a workaround where we have a separate flow for such output folders that can be offline. This way, the main output flow can always be activated and jobs going to those possibly offline folders are routed (using our own script, but similar to switch2switch/flow links etc) to this other flow and go to problem jobs if the other flow isn't activated.

I also requested this awhile ago but haven't heard anything since. In my request I asked if it would be possible to keep retrying sending jobs to the output folder rather than moving them to Problem jobs

Thanks for the info. This is a good example where it would be nice to have visibility to the feature requests. I'm really hoping Enfocus would one day add a place to the my.enfocus portal where you could see open feature requests, both your own and others', so that users could comment/clarify/vote/refine them. I'm sure that would help both us and Enfocus. I've requested that, too…

[magnussandstrom]

I have a done a quick and dirty workaround for this by removing the folder elements and using Execute Command/Run Command to move the job to the output folder.

I did a similiar thing now, but it aint pretty

The reason for the temp folder is to get rid of the unique switch prefix, there is probably a better way to do it.

xcopy.png (39.89 KiB) Viewed 2551 times

[Padawan]

In xcopy you have to provide the full path (including filename )to the source file and the path to the destination folder (excluding the resulting filename).

You can avoid this if you have a command where you have to provide the filename in both the source and the target path, this way you can combine a move and a rename in one command.

I did some quick tests with Run Command and this should be possible with the copy command:

Screenshot 2023-02-14 at 14.44.55.png (132.19 KiB) Viewed 2535 times

This uses this command:

Code: Select all

copy "%%InputFilePath%%" "\\path\to\shared\folder\[Job.Name]"

Something similar should be possible with Execute Command

[magnussandstrom]

Thanks Padawan, that was so much better. I have changed it now.