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.
Context: My team and I have created several workflows that use a set of macros. At regular intervals, we freeze everything and ship to our client. The release is made of all the workflows and all the macros, in their current, tested version.
Issue: We'd like to be able to run workflows from a previous release, with the corresponding version of the macros, to compare results with the current version.
My first try was to just keep previous releases (including their macros) in their own separate folder, but a problem arises when running workflows that call macros. Alteryx would use the current version of the macro. So to be clear, if I'm on v2, and I try to run the workflow /code/v1/Workflow.yxmd that calls a macro MyMacro.yxmc, it will use the macro in /code/v2/macros/MyMacro.yxmc, even though /code/v1/macros/MyMacro.yxmc exists.
This is of course because /code/v2/macros is in the macro path in the Designer. So the obvious thing is to add /code/v1/macros in the macro path, but then Designer complains that macros are duplicated. I've noticed that I could also update the workflows' XML to change the path of macros to be absolute, but (1) this feels super hacky and (2) doing this across 10s of workflows would require some level of automation and risk of error.
I'm sure people have faced the same issue, let me know if you have found a solution or have some guidance.
Put both versions in the same directory, call one current and one previous or v1/v2 etc. Then create a new macro called Macro selection, which will have both macros and detour tools. The macro will choose which macro to run based on the detour select at the top macro level (ie test, new/old version, etc.). You basically will send your data through the macro with a new field called version or detour and that will determine which macro is used.
Thanks Ryan, however this doesn't scale well enough. We typically have 5-6 releases per year, so the "macro selection" would soon become something very difficult to manage. For instance, if the interface of the macro changes over time, one would need to add plumbing and switches to ensure compatibility.
@Amaury I'm not sure it this will help in your case, but you may be able to just place the workflow in the same directory as the macro you want it to run. So if you want it to run an old macro, you would just move the workflow to be in the same directory as the macro. I'll explain.
For example, I've setup a single macro repository of \\server\folder\alteryx\macros. My Workflow1 is saved at \\server\folder\workflows and references a macro called "macro1" that is saved here \\server\folder\alteryx\macros\macro1.yxmc in my repo. If I look at the xml for workflow1, it will have a line like this:
<EngineSettings Macro="macro1.yxmc" />
Notice that it's a relative reference. Because I've identified a repo in my alteryx user settings, it will check that repo. But BEFORE it checks there, it will actually check in the workflow directory. So you could have an old version of macro1 saved at \\server\folder\alteryx\oldmacros\macro1.yxmc. For workflow1 to reference your old macro, you would just need to place them in the same folder. So you could copy your workflow1 to \\server\folder\alteryx\oldmacros\workflow1.yxmd. When you run that workflow from that location, it will actually pick up the old macro1 instead of your production macro1. I haven't tried this on complicated setups (nested macros for one) but it may work for you. I've actually been tricked by this before when I've accidentally saved a workflow to a dummy folder with a bunch of old macros. I couldn't figure out why my macros were suddenly out of date with no warning.
Very valuable info, I didn't know that! My setup is a bit more complicated than this as I have multiple workflows in multiple subdirectories. But your idea might work with some sophistication as illustrated by this file structure (v1 being the old version and v2 the current one):
- v1\macros\macros_repo (has the macro files from v1)
- v1\dir1\macros_repos (symlink to v1\macros\macros_repo)
- v1\dir1\workflow1.yxmd (references macros it uses as "macro_repo\macro.yxmc")
- v1\dir2\workflow2.yxmd (same idea for all subdirs of v1)
- Exact same setup for v2
- Alteryx is configured to use v2\macros as the macro repo. So that when I drag and drop a macro in a workflow belonging to v2, it will automatically be referenced in the workflow's XML as a link to "macro_repo\macro.yxmc"
The result of this is that each workflow "sees" all the macros in a relative subdirectory "macro_repo". This means each of them will use their own version of the macro, thanks to the mechanism you described. The downside is the creation and maintenance of all the symlinks, and ensuring they are ignored by git, otherwise it'll lead to duplicates.