Hi all,
I've seen many post about how to set a macro repository for Alteryx Designer & Server though a shared drive, but in our case this was getting us trapped in Designer delays due to slow VPNs or shared drive located far from our end users (mostly working remotely).
Hope my proposed set up could help you to get out of this situation while keeping all the value of having your own shared macros repository.
In my company we have an official respository of approved macros that we want to share with all our developers and servers. We started with the common approach (macros in a shared drive and all users & servers connecting to it through UNC path). In our team we are all working remotely and depending where people is located (compared to the shared drive location) and the internet & VPN quality we were seeing big delays when Alteryx Designer was oppening or saving workflows due to shared drive latency.
This is how I'm resolving the issue, is working for us really good so far.
1. We have created a OneDrive folder containing all the shared macros, this folder is shared with our developers (without permissions to edit or add macros there, as it has to be approved by admin team before). They are syncing the folder in their local PCs and pointing the macros in Alteryx Designer to the local synced folder.
2. Servers have a copy of the same shared macros folder in their machines drive, and macros are set up to point to their local versions of these shared macros.
PROS
1. Users will be connecting to the macros directly located in their PCs, avoiding delays due to shared drive latency, VPN, etc. Using the synced functionality we, as admins, can directly deploy new macros or macro fixes to all their computers, so we are sure all have latest versions of the shared macros. Important that they keep the sync on, no just doing it first time and then stopping the sync. I assume this can also be done through other providers like Dropbox, Google Drive, etc.
2. Test & Prod macro repository. We took the opportunity to not connect both environments to the same macro repository folder. Then we have shared macros environment segregation. If we have something new, we add it to the OneDrive folder for our users and we add it to the TEST server macro repository, once it's validated we also add it to the PROD server macro repository. Same logic applies, and it's very helpful with macro fixes, first testing the fix in TEST and once it's ok, we do the replacement in PROD as well.
3. Nobody needs to do macro replacements or path replacements to run workflows in the different environments or even add macros as assets when uploading to gallery, which still give us the opportunity to easily roll out fixes in macros used in multiple workflows.
4. If you have heavy audit over your Alteryx infra and general Alteryx usage, you can guarantee that developers cannot change the macros in TEST & PROD servers (you don't need to give them access to your server macros folder, just ensure your 'Run as' server account has access to it), even in my case they cannot change their local repliclas of the shared macros (but this is up to you)
5. Developers can access to the shared macros even offline (vs shared drive solution), since they are connecting to their local copies of the macros.
CONS
1. Now we have 3 different shared macros folder to maintain. They need to follow the same extact folder structure, macros need to be named exactly the same to ensure each environment (local PCs, TEST & PROD) will find the macros the same way. From an admin perspective you have to be really meticoulous and ensure you don't place different versions of the macros to avoid it becoming a mess when debugging accros the different environments.
2. If you are using the feature 'User must specify their own credentials' in your server workflows, you will have to add the macros as assets to ensure the user running the workflow/app can access these resources. In our case these are exceptions, rather than general credentials approach, hence it's not a big deal.
All this is possible based on the logic of relative macro paths (when the macro is inserted from the Alteryx Designer tool pallete) described in this post here
Basically the workflow XML will tell Alteryx, hey! go and find this macro in your macros repository, each machine will be pointing to a different folder but all of them will keep same folder structure and macros will have same name, hence it will find the macro in all the environments.
Hope you find it useful, please let me know your thoughts, concerns, etc.
Best Regards,
Alberto HM
