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 believe the answer to this question is "Yes" but I wanted to confirm and to also understand if there are viable workarounds.
Here's the situation:
- We have a workflow that uses a Conditional Runner to call a workflow that resides in Dropbox.
- The workflow in Dropbox leverages a macro that also lives in Dropbox, since the Runner macros cannot "unzip" a packaged workflow, i.e. all assets used by the workflow being called by a Runner cannot be packaged.
- This all performs fine when we run the workflow locally. But when we save the workflow to Gallery and try to run it, we get errors because certain assets required by the Runner macro are not accessible.
Here is what our Runner macro configuration looks like:
Even though I've selected the Conditional Runner workflow in the macro assets, I still get this error when I save to gallery:
And when I run that workflow from Gallery, I get the following error:
So, working off of the assumption that all of these files need to be packaged into the workflow, I went back to the workflow in Designer and included these files:
I was unclear how to set up the AlteryxRunner executable file into an appropriate nested folder, which I believe is the cause of the error I get on Gallery when I try to run this modified workflow.
Is there anything I am missing? Any help/guidance here would be appreciated. 🙂
Packaging macros is not necessarily recommended, as if the Macro changes, you will have to repackage and re-publish the workflows that point to that Macro.
The better route is to have someone with access to your server machine log onto the machine and open Alteryx designer and install the macros the same way that you would on a local designer instance -> User Settings -> Macros.
I personally recommend storing all 'productionalized' macros somewhere that both users and the server can get access to (like a shared drive) and then the references are identical between users and published workflows.
Let me know if this is clear as much and I can expand on the idea.
Thanks Zak. That is exactly what we are trying to pursue. Have you encountered any issues installing the CREW macros onto the gallery server? I know they aren't officially supported tools, but they seem pretty robust.
While not officially supported, they have worked continuously for a long time. 'Officially supported' just means that with each release we specifically check them for continuity, since they were developed by CReW (a partner of Alteryx), they are not checked in such a manner, but they havent had to change or release updates for almost 2 years.
Its also worth noting that Adam Riley, one of the CReW members involved in creating them, is a principle software engineer here at Alteryx - long story short, they are stable and I recommend them to my customers regularly.
We placed the CReW macros in this directory (C:\ProgramData\Alteryx\Tools\CReW) on both the gallery machine and our local machines and they work perfectly. We don't need to package them with our workflows when we save to gallery, since Alteryx automatically checks this location for any shared resources. And so long as the macros exist in both places (under the same path), you're good to go.
Although the CReW macros have been used with great success, I would emphasize that the CReW Runner macros in particular should be avoided on Alteryx Server. Beyond the fact that they are not supported, their jobs will not count toward the maximum workflows allowed to run simultaneously, they don't show up in the queue, the Server Usage Report, the Server Schedule Forecast, etc.
Instead I recommend using Batch macros to orchestrate workflow processes. Then the workflow itself will define what comes first, second, and so on.
Scott Gurney Strategic Sales Engineer Alteryx, Inc.