Bundling nested macros in export workflow

[david_fetters]

I'm having a problem ensuring that macro components are included in workflows that I export.  Our organization stores many of our macros in a commonly accessible network folder, and then includes that location as MyMacros in each alteryx installation.  I am aware that macros stored in a MyMacros folder (any folder accessible natively from within alteryx) is not included when a workflow is exported.

We have a teammate who is not local and needs to access some of these macros, but is not on the network.  Some of our macros are nested and include several other macros from our MyMacros folder.  When I attempt to export a workflow containing the outer macro, none of the nested macros are included in the output and the exported workflow will inevitably fail when unpackaged remotely.

I've tried copying the MyMacros folder to another location, but the macro path is absoloute and not relative.  Moreover, macros do not show up in the workflow dependency options and therefore cannot have their path changed to relative.  When we send the files, even if we send all of the macros, our nested macros will not work due to the hardcoded file paths.

Anyone have a quick solution to this?  The only thing I can think of is to remove the MyMacros folder from the config file, close and reopen alteryx, and then package the workflow in that way (which should include the nested macros as they are no longer in a local macro folder).  This is a little clunkier than I'd like, and I wondered if anyone else has had similar problems.  Thanks in advance!

[TaraM · Accepted solution]

You can add Macros or any other dependencies through the Asset Management options. Check out this knowledge base article that describes how to turn it on and how to add assets before packaging them.

http://community.alteryx.com/t5/Alteryx-Knowledge-Base/Attaching-additional-files-to-a-workflow-pack...

[david_fetters]

Thanks Tara!  That was a useful guide and the Add Assets option is really helpful when packaging our workflows.  The guide was correct with the following caveat:

If you have multiple levels of macros nested within a workflow, then you need to specifically add each macro as an asset to the macro that directly contains it.  Adding all of the macros as an asset to the top macro container will not change the associations.  To make it clearer:

Imagine a workflow "modeling.yxmd" which contains "modeler.yxmc" a macro that contains a nested set of macros, "forest container.yxmc" which contains "forest macro.yxmc"

A rough diagram of the dependency hierarchy would be:

- modeling.yxmd

   - modeler.yxmc

      - forest container.yxmc

         -forest macro.yxmc

I could only get the packaged workflow to properly include all of the required macros (along with changing their path to a relative path rather than referring to the original location) by adding assets to the macro as shown:

- modeling.yxmd

   - modeler.yxmc  (add forest container.yxmc as asset)

      - forest container.yxmc  (add forest macro.yxmc as asset)

         -forest macro.yxmc

If I attempted to add both of the nested macros as assets to the modeler.yxmc, it would always refer to the original "forest macro.yxmc" at its original location, e.g. the following will not include a properly relative pathed version of "forest macro.yxmc"

- modeling.yxmd

   - modeler.yxmc (add forest container.yxmc and forest macro.yxmc as an asset)

      - forest container.yxmc

         -forest macro.yxmc

In the above situation, forest macro's file path still referred to the "B:\MyMacros\forest macro.yxmc" location, rather than one of the "_\external\....." paths.

In sum, it appears that child macro assets need to be added to the specific parent macro that uses it in order to work.  Hope this clears up an issue for some lonely forum searcher later!

[danielbrun2]

Hi David,

You also have the option to go to "options->export Workflow". This gives you a list of assets and makes the path's relative. 

Best regards,

Daniel

[david_fetters]

Hey Daniel,

You are correct, except we cannot get it to include macros as dependencies if they are located in a folder that has been attached to alteryx (as in, any macro that shows up in your tools because its containing folder has been attached via adding the folder through Options > User Settings > Edit User Settings > Macros > Add Macro Search Path).

Our organization shares commonly used macros, some of which are nested inside of other commonly used macros.  Your tip works perfectly during development (when none of the macros are included in a macro search path) but has not worked once the macro is visible in the list of Tools.

Sorry if the distinction was unclear in my original post!

[danielbrun2]

Hi David,

No worries. I just read the blog post Tara attached and figured out you already had that info. What I primarily noticed was your comment about relative paths. 

I have build quite a few macros recently and started forcing myself to always specify relative paths like ".\Assisting\assistingFile". This would make you able to zip a folder and send it to someone else. Also using full UNC path's help minimizing problems (\\Server\folder\file).

Hope you have some good ideas for the future development now.

Best regards,

Daniel

[hursic]

I find that highly irregular.

Do you really have the same drives mapped and permissions on production servers as you do desktops ?

Also I've encapsulated the Crew macros and my own into deployment packages, but when on the server the crew macros are in a "macros" subdirectory which then cannot be found. And I do use relative paths, but they don't get deployed into a subdirectory not matter what I try.