how to Publish the Crew MAcros

Question

hi all,

What is the proper approach to "installing" all the Crew Macros onto a Gallery ?

Their location appears to be hard coded into the workflows, when publishing they appear to change this hardcoding automatically to "\external\1", but then they stop working on my desktop tool.

thanks

Ian

hursic · Answer

The CrewMacros appear to get installed to where you run the install macro from not into AppData etc.

I created C:\AlteryxMacros on both my desktop and gallery and rebuilt all the referencing workflows and now they are found. I won’t be mapping a shared drive as that’s insecure and allows people to potentially break the macros.

This will be a pain to upgrade in future as I’d like them to be encapsulated into the tooling rather than a separate install onto the server.

On the version control topic, there are a set of workflows that are critical that the business do not change but that go through a change control process as its regulatory reporting. What is the mechanism for supporting external version control tooling or promoting from a staging environment to a production environment ? I can only envisage at this point that the workflows can be exported as XML for persistence, and then a single point of control exports from staging into the desktop tool, then imports into the production gallery.

JordanB · Answer

Hi @hursic

Problem 1:

CREW Macros are by default installed to Users\AppData. Therefore, if you want to be able to reference them both on the server and on the Gallery I would suggest saving these to a mapped drive that both the server and your desktop can see.

Problem 2:

It will only put the macros in an externals folder if they are ticked within the 'manage workflow assetts' option when saving the workflow.

Ultimate aim:

I believe if I am interpretting the below correctly you are looking to have one location fo the CREW macros that you can control the version and have a relative path between both your desktop and the server.

To achieve this you can do the following:

- Save the CREW Macros to a network location that the server and your desktop can see

- Uncheck the CREW macros in 'manage workflow assetts' which are in your workflow that you are uploading

- This will then keep the paths relative between the server and your desktop workflows

-Versioning: If you want to use keep tracks if you change the CREW macros on your own, you can publish the macros to the Gallery. If you make a change you can hit the save ICON on your desktop and it will replace the macro already on the Gallery.

- You can then tell users to check the gallery for updates and this can act a central repository for everyone.

- This way wheenver there is a chnage to a macro, you can check the gallery, download the tool and replace that tool in the mapped drive where the CREW Macros are also saved.

- The reason for the two step approach is that the gallery has version control and it is far easier to manage it there than allow people to overwrite within a mapped drive as this does not have clear version control.

Best,

Jordan

hursic · Answer

I've opened Crew Macro in the desktop tool. I've uploaded it into the gallery.

I've uploaded my workflows that reference it.

In workflow dependencies they are set to "All Relative". However crucially the Crew Macro does not appear in this list so I cannot tell where they are supposed to reside.

Problem 1:

When I attempt to upload my workflows to the gallery they don't find "Macros\CReW_ConditionalRunner.yxmc" etc. How can I point my worfklows to use the Crew macro I've uploaded ?

Problem 2:

Once I've tried the above and it's failed, my local copy of my workflow now reference "_externals\1\blahblah.yxmc" instead of

..\MySubDirectoryMacros\blahblah.yxmc in the "save workflow" dialoge box, so it appears to update the location of the macros I want to publish.

Crew Macros are treated differently to my own, I would like to get a consistent approach or one that works.

I don't want to map the same network drives on the hardened servers as my desktop as this would be a risk of suffering poor SDLC (we will need to version control all of this at some point).

I also don't have ultimate options on c:\program files\ etc on the server as some directories are set read-only by the server team in order to protect the stability of the server.

thanks

Ian