Analytic App logistics: Use existing workflow or create a new one?

[zara4580]

I have a relatively complex workflow which involves multiple control containers running in sequence, multiple streams, some python tools reading & creating files in the background, and finally a bunch of Excel files being output.

This workflow will be scheduled to run daily on Server.

I'd like to create an app that will allow a user to do one of two things on-demand:

1) View a read-only version of one of the output files from the above scheduled workflow

~ or ~

2) Create a new Excel file with some summary info from several of the output files from the above scheduled workflow

Q: Would it make more sense to turn my current scheduled workflow into an app (even though i don't want those python scripts, etc. running each time a user runs the app), or to create a new workflow for the app that starts by reading in all of the output files from the current workflow?

If the latter, could there potentially be a problem if someone tries to use the app while the original scheduled workflow is actively writing to the output files?

TIA for any advice!

[caltang · Accepted solution]

If you go with Option 1, you'll need to add the interface layer on the Server and then scheduling goes out the window. If you do not want the scripts etc. to run each time the user interacts, then by default, Option 1 is out. 

Modifying Option 2 - Since your workflow is scheduled to run, the output should be stored somewhere in the Server or on SharePoint by design. The user can go and fetch the outputs themselves. This means that you can retain the schedule, and give two outputs each run. 

Then you can set an auto-purge of outputs every 10 days? Depends on you. I would say this is what I would do.

[Peachyco · Accepted solution]

Yeah, it makes sense to me to create a new app that just reads the output of the existing, scheduled workflow.

As they are separate workflows, there is the risk of the on-demand app being run while the scheduled workflow is still running.

To handle that issue, you might use a flag in some file or table, such as a text file (.csv) or an Alteryx database (.yxdb). I'm imagining it would run like so:

• Scheduled Workflow (SW) turns the flag to TRUE at the start of its run, and then turns the flag to FALSE as one of its last steps.
• On-Demand App (ODA) reads the flag when it runs. If the flag is TRUE, it informs the user that SW is still running and to try again later (or keep looping until the flag changes). If the flag is FALSE, then it reads the files accordingly.

It's not fool-proof as the ODA might be run at the very point that the SW is switching the flag, but I think it can reduce the risks.

[zara4580]

Thank you both! I created a new workflow for the app, and actually had it read from the most recent backup copy of the original workflow's output. The backups shouldn't ever be open, so there's no conflict when someone tries to run the app but an output file is already open somewhere.