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.

[patrick_digan]

+1! This has been logged as a bug internally by @MattB, but it was low on the priority list when I brought it to his attention many months ago. Here was his response then:

Thanks for following up! I had one of our developers take a look and this appears to be a bug whether you package the macro or not. Per the dev…
 
When I try it, if the macro containing the data connection is not in the same directory as the parent module, 
it fails to package the data connection properly (because it tries to adjust the path as if the data connection was a file).  
If I have the macro in the same directory as the parent, it works, but in that case I can’t put it in the common macro directory, 
which is the only way I know to get it to work on the gallery if you don’t package the macro.
 
He also added that since the data connection is essentially an ID, there is no size on disk savings by not packaging it. 
So, for a new version, there is no real disk penalty and you would just package up a new version.
 
I have created a bug in our system. Given our current priorities and that this is the first time we have heard about this issue, 
it is unlikely to get into a near release. However, if you don’t mind, please post this in the Community for awareness. 
Ideally, if other customers find your post and comment, we can try and bump up the priority.

I've tagged him here in case anything has changed on this issue.

[KenMoorhead]

@patrick_diganthanks for joining in here! I saw that thread from earlier in the year while we were troubleshooting recently. We're growing our practice here going into the new year and the apps we're creating for gallery users are growing in complexity.

Hopefully this isn't a major pain to resolve and get working in line with the easy-use spirit of the Gallery Data Connections. The gap from how I'd expect it to behave and how things are actually behaving seems small, but the devil's in the details...

[MattB]

@patrick_digan, thanks for replying to the thread.

@KenMoorhead, unfortunately, this remains lower in the seemingly endless stack of exciting features we want to deliver ASAP and bugs we need to address. I have noted this as additional market evidence which is reviewed every time we plan.

[MattB]

Updating to reflect current status

[David-Carnes]

@MattB

The Not Planned status has me frustrated, sad, and disappointed.  I had assumed, and hoped, that a macro that used a Gallerified data connection would make it easier for me to share macros and keep a tighter rein on version control.  Mainly though, the ability to control data connections with Gallery is a phenomenal tool I using for our data governance push.  Macros need this.

I hope y'all revisit this idea.

Best,

David

[MJ]

Second what David said

[kwinstead]

I wanted to job in on this thread and see if anyone has given this any additional thought?  We have a few workflows developed and more on the project list that have hit a roadblock because of this issue.  As it currently stands, the only feasible workaround is to have copies of the workflow on the server and properly note to the users and other analysts that they have to be run locally.  Is there any additional workaround that is available in the interim?

Thanks!

Kevin W

[David-Carnes]

@kwinstead 
The only current solution is to go old-school*.  On both the user's computer and the server running Alteryx Server, run Designer as admin and add System level data connections, using the same drivers and the same exact name.

Downsides to this approach are the amount of work administer the separate users' computers and the fact you've got a database connection that can be exploited by anyone that has Remote Desktop permissions to your Alteryx Server box.

* I still like old-school punk, hip hop, etc. but I really like the new stuff, too.  However, with Alteryx data connections I only want to hear Gallery Database Connections.  Managing individual workstations' data connections now sounds like quartet of out of tune kazoos.

[kwinstead]

Thanks for the additional info! I really appreciate it and was fearful that was the only route we can take : (

[brucks]

We've built workstation level drivers as well as System level drivers and still encounter this issue.  I've had this issue impact my ability to add additional output information when I use an Email Event and attempt to add a payload to the email thinking it is going to be sending the most recent version of the payload (an Excel spreadsheet) only to find that it isn't the most recent version of the Excel spreadsheet, it is actually the spreadsheet from the first time I ran the workflow.  This is a pretty lousy user experience that we shouldn't have to find a work-around for.  Just my $0.02