Repair Macro Path

[StephenR]

We all love seeing this.  And, it's fairly easy to fix, just go find the macro and insert a new copy.  But, then you have to remember the configuration and hope that it was simple. 

With the tool that's there, the XML still contains the configuration, all that's missing is the tool path.    It would be great to be able to right click and repair the path from the context of the missing macro.

[willperkins]

+10000000

I sound like I'm grading a scantron test or something when I'm helping my peer fix this by looking at the XML and they're updating the widget.

True

True

False

True

False

False

et...

[chrisha]

+1

We have a directory on a fileserver where we have our internal macros. In the past, every macro had its own directory that was added manually to the User Settings. When I tried to reorganize the folder and add only the top-level directory to the settings, all workflows break, because the reference in the workflow XML points to the macro file. In the XML file I would only add the appropriate sub-folder to the reference.

A better macro management and error handling would be much appreciated.

[Hollingsworth]

I submitted a similar idea last year.

https://community.alteryx.com/t5/Alteryx-Designer-Ideas/Find-Missing-Macro/idi-p/46346

Please go star.

[JTCairns]

+1

[fharper]

Since my last comment in May 2018 on this I have become familiar with the Server product and the additional nuances that brings.  I have also learned more about how things are packaged and how Alteryx searches for macros.  My current view is to insure you have a single golden source folder for your "production" macros.  Then set up an ".ini" file for it, the same as is done when you install "CReW" macros or would be built if you set up a macro path in "User Settings".  I would make an instal module same as "CReW" but for your specific shared library if you have more than a few people to support.  That way the user id running Server can install it and everyone else can also install it and now all share the same source and point to the same place.  then you just drag and drop from the tool bar as you would CReW macros. 

the internal result is in the XML the macro is referenced as Macro="macro_name.yxmc" and the system will search the predefined locations Alteryx looks for macros in and find it because the ini file puts that folder path in the search path. and everyone references the same so sharing modules will not "break" any path reference.

At this point in my evolution of using Alteryx I think the broken macro problem is more a training issue where Alteryx could do a better job in educating users in the cause and best practices around it.

The only remaining issue is migration from development to test to prod during development change control.

For change control I use a User Dev, Test and Prod folder structure and built a change control flow that copies (checks out) a module from "Prod" and copies it to the destination folder structure and modifies the pathing in the xml for macros and file references to the full path for that destination.  

In this scenario if someone else tries to get a flow or macro from Prod to make a change to it with intent to ultimately replace the current one in "Prod" they must use the tool due to security settings on the Prod folders and the tool lets the user know if someone else also has it checked out so they can coordinate and avoid double work and or mutually destructive changes.  

Only one developer can have it at a time.  It is copied and modified and put into the user's development folder.  once they are done and have user tested they use the tool to promote it to the Test folder

In the Test folder we typically have someone else test the module for a variety of reasons and insure larger and more complete test data is used and we insure a known set of test cases are represented.

When we are ready to promote to Prod only certain users are allowed to make that change and a check off list/change control sheet is created to document the change and test criteria and results to satisfy audit needs and best practices.  In the final step the tool converts the test paths to Prod Paths and the Macro pathing is revised as well to the paths appropriate for the ini paths.

It was a little work to create the tool but worth it.  It was a bigger issue identifying and gathering and migrating the dirth of modules in folders across everyones laptops and shared drive folders and determining which is the right version of a flow and settling on the "Golden" source....and then getting everyone to work off of the new file paths on the network drive.

The benefits were many including reduced redundant work...now if someone builds a useful flow others share and it always works...no surprises in code changes on the fly affecting people who maybe needed it to stay as it was...etc. an auditable change control process with better testing.

[jcalvo92]

+1

[CatheyH]

+1 from me.

We migrated the location of our macros and missed a few older workflows that are nonetheless a bit of a pain.

[NicoleJ]

Stay tuned, coming soon!!! 😁

(PS. Check out announcements about our Public Previews for the 23.2 release if you'd like a sneak peek of this functionality!)

[altrx002]

It became even worse in 2022.3 :-)

Error: MyMacro (38): <EngineSettings> tag for ToolID="57" does not specify a plugin entry point and does not give a macro