This site uses different types of cookies, including analytics and functional cookies (its own and from other sites). To change your cookie settings or find out more, click here. If you continue browsing our website, you accept these cookies.
I've recently come across the 'Runner' tool and have been using it to chain workflows - when one workflow runs it triggers another workflow to start running. However, this has it's limitation. I'm just wondering if anyone has a better idea at how to best do this. What if I have multiple workflows I want to trigger?
It is also worth noting that if you look at the ideas forum under items related to scheduling/the scheduler, there are many ideas related to the ability to add workflow dependencies, etc. that have been marked as accepted/in progress/under review. If chained apps or the Runner macro don't accomplish what you're looking for, you might consider up-voting on an idea that encapsulates your expected function - that said, you can see from our feedback on these topics in the ideas forum that we have stuff planned and are looking into ways to make this a more delightful experience.
Is it true that if you're wanting to run these chained apps from server, that the first app is published and the 2nd is attached as a dependency in the workflow assets dialogue? Which then necessitates that server has access to the file location of the 2nd?
Is it potentially clunky to run it from a file location rather than the Server?
edit: i've tried this with every config option i can think of and I can't get the chained app to actually run.
@davidhenington Here are my thoughts. I do believe you have to package the second app as a dependency. I wasn't able to reference my chained app via UNC pathing, leave it unchecked when saving to the server, and then have the server run the second app. It would simply finish the first app and be done.
When you package it, it should save the second app with your first in one 2 places: either in an externals folder, or in the same folder as the first. Your second app should work on the server either way, but it's sometimes nice to have it relative if your writing data between the first and second app. In that case, you should put both apps in the same folder and just put the filename of the second app (second app.yxwz) in the chained app box of your first workflow. Then when you save your first workflow to the server and package your second workflow, it will run them from the same folder whenever it's run in the gallery.
First stupid question: can you clarify what you mean here, really granularly? "you should put both apps in the same folder and just put the filename of the second app (second app.yxwz) in the chained app box of your first workflow."
now i'm really stumped. When I do this: "just put the filename of the second app (second app.yxwz) in the chained app box of your first workflow." there is no way to link the asset and the gallery doesn't even recognize the app as a chained app.
@davidhenington I'm attaching an example. The first app has you pick a gender, and the second app has you pick a name from a filtered list. My key to making things simple is relative pathing.
My first workflow looks like this:
When you open my workflow, you'll see that my output is being written relative to the path of the workflow since I've just included a filename and no folder.
In the interface designer, I specify the name of the second workflow that I want to run:
Chain the second app
New Workflow2.yxwz must then be in the same folder as New Workflow1. Here is what new workflow 2 looks like:
It reads in the step1 results and then filters down further based on the name you select. The drop down is also reading from step1 results. Both the input tool and the dropdown just have the filename so they're using relative pathing again.
Back on Workflow1, we can go to file >>> save as >>> select your gallery. It brings up this box:
Save to Gallery
I select manage workflow assets and it shows me this:
You have to check New Workflow2 so that it gets packaged. For our purposes, it doesn't matter whether you check step1.yxdb or output.yxdb. I'm putting the further discussion on this in a spoiler since it's off topic but very interesting.
Workflow1 shows output.yxdb and step1.yxdb as output tools with the option to package them. In general, when alteryx shows you an asset with the (OUTPUT) tag on the left in blue, it will NOT package them even if you have them checked. I find this very confusing. To make it more confusing, alteryx WILL package assets with an (OUTPUT) tag if they're also included somewhere else other that the output tool. For example, step1.yxdb will be packaged since the second workflow includes it in both the input tool and the dropdown tool. Since output.yxdb is only referenced as an output in the second workflow, it doesn't get packaged up. Again, it doesn't matter in our case since we're using yxdb files and they'll be overwritten at runtime. But with other file formats and situations it can make a difference.
Now that we've saved our workflow to the gallery, here is the first screen where we pick a gender:
First workflow in gallery
When you click next, alteryx will run the first workflow. This will write the step1.yxdb file (to a temp folder on the server where it's running our job from). Once new workflow1 is complete, it will then fire up our second workflow. This will read from the step1.yxdb to give us this dropdown:
Second workflow in gallery
We can select a name and click run to execute the second workflow. The output is then displayed for the user:
If you want to see how/what files are being sent to the server when you save it, you can use the options >> export workflows feature which will save a yxzp. If you have 7-zip (or just change the extension to .zip), you can open the archive to see what is/isn't getting packaged:
I believe when you save to the gallery it just creates a temporary yxzp that gets moved from your machine to the gallery via an under the hood api call.