Community Spring Cleaning week is here! Join your fellow Maveryx in digging through your old posts and marking comments on them as solved. Learn more here!
The Product Idea boards have gotten an update to better integrate them within our Product team's idea cycle! However this update does have a few unique behaviors, if you have any questions about them check out our FAQ.

Alteryx Server Ideas

Share your Server product ideas - we're listening!
Submitting an Idea?

Be sure to review our Idea Submission Guidelines for more information!

Submission Guidelines

Shared Macros - ability use a central shared macro (not package INTO the file)

Situation:

As your analytics work grows - you find yourself using the power of Alteryx to create shared macros.    These act as an accelerator for a team because one team member can us a reusable solution created by another team member.   For example - many teams need to get data out of JIRA (or some other system) so you create a connector that everyone can use.

 

That's going well - and now you have 20 teams all publishing canvasses to your server (possibly 100s of canvasses running in production) which make use of your JIRA connector - all good so-far!

 

Problem:

BUT THEN - you discover an issue with the JIRA connector and you need to fix it and publish a new version!

 

It's at this point that you realise that the canvasses on your server which use your JIRA connector are NOT pointing to it, but they have made a copy and included this inside their canvas.   So when you fix the problem with the JIRA connector - no-one gets the fix!

 

This is because every application uploaded to the server is a yxzp file, which zips up a COPY of all the shared macros and uses this in an isolated way.

So - in order to get the new JIRA connector (with the defect repaired) used instead of the old one you now need to:

- Download EVERY canvas on your server

- Unpack them all to expose the sub-macros being used

- Inspect them to see if they are actually an instance of the JIRA Macro

- Make a list of the owner and application IDs

- reach out by e-mail or phone to every one of these folk to ask them to republish their Alteryx workflow with your new version of the JIRA connector.

 

 

Proposal:

Please can we revisit this - we really do need the power of shared macros - and we also need the ability to fix and manage these like a product over time.   This will have an impact on the engine (hence copying @AdamR_AYX ) 

 

Desired end-state:

- When you build a canvas using a shared macro - it doesn't store the macro itself, but rather a reference to the version on the server - unless you explicitly decide to break the connection and take a copy.

- When you check this canvas into the server - your application / yxzp does NOT include a copy of the shared macro - instead it has a reference link

- this means that Alteryx Server can now track which canvasses use this shared macro very simply

- When I fix this shared macro - I can then do an in-place update; or if the interface is not the same (i.e. different inputs or outputs) then this has to be a new version and the users will stay pointing to version 1.

 

This is how shared assets are managed in a micro-service world, which is the way that all of our architecture is going - and it seems important that we build this thinking into the Alteryx infrastructure too.

 

 

 

 

 

 

 

@AdamR_AYX ; @Treyson ; @SteveA @DerekK ; @BlytheE 

16 Comments
JohnPelletier
Alteryx Alumni (Retired)

To summarize:

If I'm reading this correctly, it sounds like a fundamental need to address this problem would be versioning for macros, so that a workflow can specify with which version of the macro it's designed to run, and then newer workflows can use newer versions of the macro as well.

 

And it sounds like the macro share directory idea only works well if network connectivity is super reliable, but even then that will update all workflows to run with the newest version of any macro, which in some cases can break things.

 

I wonder though if having multiple versions of macros persisted in Server would cause just as many problems as it would fix...what do you all think? @David-Carnes @karenmtheis 

David-Carnes
12 - Quasar

@JohnPelletier 

Well, Alteryx is already providing multiple versions of macros in Designer and Server, specifically in the Predictive tools.  It's a simple method, just have different file names in a location or same filenames in different directories.  Set the Custom Workflow names the same between versions and ditto with the Root Tool Names. Change the Tool Version to indicate original and subsequent versions.  An example is the Linear Regression tool.

HTH!

CristonS
Alteryx Alumni (Retired)
Status changed to: Not Planned

Thank you for your idea! At this time we are unable to include this idea in our near future roadmap due to competing priorities; as such we're updating it to Not Planned. However, should this change or we become able to return to this idea in the future we'll be sure to update this status. 

JohnPelletier
Alteryx Alumni (Retired)

I think we will address this need at some point in the future, but we've got some amazing other features currently under construction that are taking priority right now. Since we can't commit to anything in the near term, we call this one Not Planned.

hroderick
8 - Asteroid

@SeanAdams  we somewhat achieve this by

(1) creating a shared drive everyone can read for macros,

(2) have macro user paste the full path in the filename when inserting a macro, and

(3) make sure macro asset is not checked when saving to private studio

SeanAdams
17 - Castor
17 - Castor

Hey @JohnPelletier - thank you for taking the time to read the ideas forums - there's a load of great stuff in here, and people invest a lot of their time on suggestions to make Alteryx better.

 

Hopefully the other Product Managers will adopt this habit too, there's a lot of value in this data.