Supporting Gallery Data Connections in Macros run on Private Gallery

[KenMoorhead]

I love the gallery data connection feature - we're going through some big systems architecture changes, resulting in new locations for many datasets. Having a single place in the Gallery Admin area to update connection information works beautifully.

We're running into issues with the gallery-hosted data connections when trying to run some apps on our private gallery though. The trouble comes up when the gallery-hosted data connection appears inside a macro that's part of an app. We get an "Unable to translate alias" error when trying to run these types of apps.

If we have an app using gallery-hosted data connections that are outside of a macro, the gallery is able to resolve the connection alias fine and work properly. The issue only appears when the gallery data connection is part of a macro used inside an app.

We use macros a lot in our app development because it allows us to use standard methods for accomplishing common tasks. Using macros also enables us to set up automated testing workflows to make sure our processes produce expected results. As it is, we're unable to take full advantage of the gallery-hosted data connections because they don't work within macros, and instead have to continue using hardcoded connection strings. These are a bigger maintenance burden as our underlying systems evolve and are updated.

[venza]

I can reliably reproduce it on several complex workflows, I will try to make a simpler workflow that still reproduces this problem. I just tried with a very simple workflow+macro created from scratch and it worked.

Basically I have a workflow that calls a macro to write a line in an Oracle database. So the macro has an output configured with a Gallery data connection. When saving to the gallery I get the "no such alias" error during validation.

The workaround is to add an input or output with the same data connection used in the macro in the top-level workflow.

If I manage to reproduce it with a workflow that I can share I will post here and contact support.

[JohnPelletier]

@venza What version are you on? Have you submitted a ticket to support?

[KylieF]

This idea is being updated to Implemented as we were able to correct this issue in the 2020.2+ version of Server!

Thank you all for your feedback and ideas!

[brianscott]

Ninja Edit:  If you select manage assets, then include any macros when you publish, this bug is gone.  If you don't, you'll continue to get the alias error.  Of course, the upshot to this is that if someone updates the macro, your workflow won't get to use any fancy new code.  You'll need to (somehow) remember which workflows have macro X in them, go download them all, and reapply the macro and republish.  Frankly, it's probably better to just keep using the old disabled container 'fix' as opposed to try to deal with that several months down the line when you've forgotten all of the places you have the macro in use.  :nauseated_face_emoji: 

Second edit:  Sorry for the spam edits. 

[venza]

Hello everyone,

@JohnPelletier @KylieF : the bug is still there in 2021.4 and all our workflows use the disabled container workaround.

I didn't actively monitor this thread since there is a workaround, but a new team member joined and I had to explain the workaround to him.

Support was unable to help, since it's a bug, it's known and you are conviced it's fixed.

I showed the sample workflow with a macro and a Oracle data source in it (but any DB data source is the same) and the error. I got some awkward silence, then the two known "solutions" : embed the macro or use a disabled container. For support no action was needed on your (Alteryx) part.

A waste of time for me and for the support guy.

Anyway the whole "macro repository" concept being a shared folder on some windows server is basically a workaround in itself. You should just be clear and say that data sources in macros on a "macro repository 🙄" are not supported.

Best,

Daniele