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.
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!
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 COPYof 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.
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 )
- 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.