Managing Shared Gallery Connections Across Several Environments

[raychase]

Hi all,

I'm curious how other companies are managing shared gallery connections across multiple environments.  Let's simplify the scenario, and assume that a company has two distinct Alteryx Server environments (QA and PD).

Designer users would be developing workflows using gallery connections from the QA Gallery.  They promote the workflows to the QA Gallery and they run fine.  Now they decide they are ready to productionize the workflow via the PD Gallery.  How do they get the gallery connections working on the PD Gallery without creating identical instances of those connections, sharing them, and repointing each input/output to the corresponding connection on the PD Gallery?

I've been able to restore data connections from one Server to another using a MongoDB backup; however, this necessitates treating the environments as identicals (ie. the controller tokens must match).  In doing so, I've noticed that having identical connections configured on two separate environments can cause issues within Designer.  On many occasions, I've seen the data connections flip-flop who they belong to, as Designer doesn't seem to be able to distinguish that the connections live on separate Galleries (likely because they have identical cosmetic names AND underlying GUIDs).  The problem here is that the aliases are sometimes not properly packaged as assets when saving the workflow to the Gallery, and thus fail to resolve during Server runs.

It's possible to mitigate the issue above by only keeping one Gallery configured within Designer at a time, but this wastes a lot of time adding/removing Galleries.  You also need to make sure that neither is configured as the default Gallery, as you cannot easily remove the default Gallery within Designer.

I'm very curious to hear how others are handling this situation.

[joshuaburkhow]

@raychase 

Great question! I am assuming you are referring to gallery (data) connections and not specifically designer > gallery connections. I have a pretty large installation and I don't create or allow gallery data connections to be created. It's too much work and a hassle to manage without APIs which in the future are coming however today I require our users to use DSN-less connection strings. Now it's not perfect and we are looking at some 'adjustments' to this approach but from a productivity point of view it's vastly better than doing the connections manually and god forbid trying to manage users access to them or monkeying around the with the data connections collection in Mongo (don't do this ;)). 

Hope this makes sense and more than happy to talk through more with you. 

[raychase]

@joshuaburkhow thanks for the quick reply!

Are you saying your users are using their own aliases created within Designer? Or are they simply putting the entirety of the DSN-less connection string within the Input/Output tool? I feel like the latter is quite inconvenient as it would have basically zero reusability.

If you were referring to the former, then that makes more sense to me. I assume that requires enabling the option to allow user aliases to override gallery aliases within the server configuration?

I have a few concerns with allowing users to create their own strings:

How do you ensure the integrity of the strings? In our environment, data security is complex and critical, so we rely on windows authentication to pass-through the credentials of the run-as user (defined at the workflow-level on the Gallery). What would prevent someone from avoiding the trusted authentication parameter in favor of embedding SQL credentials in the string and then sharing with peers? How do you ensure they are using the recommended driver provider?

I love the thought of alleviating data connection administration from my plate, especially with sharing not working at the subscription-level.

Have you identified any issues with your approach? Do you find yourself consistently coaching users on writing proper strings? Can the connections be used within macros (both packaged as assets and living on shared drives)?

[raychase]

Also: any implications with in-db connections? Today, we have users create user-type in-db connections within Designer and then an admin would create an identically named/stringed system-type in-db connection on the Server. That seems to work pretty seamlessly.

[AntonioKeyrus]

Hi raychase,

I have exactly the same situation in my current project. We decided to switch from one environment to the other one every time user needs to modify + promote a flow from QA to PD but, as you mentioned, it takes a lot of time to do the switch and, potentally, it creates issues due to human factor.

It would be good to have Alteryx support/expert involved into this conversation as this topic affects many customers, specially, those with large/complex environments.

Regards,

Antonio

[afv2688]

Hello @raychase ,

following the comments to this thread I agree with @joshuaburkhow. We are currently using dsn-less connection string for a vast amount of different drivers and while it might not be pretty it helps a lot when having multiple servers and environments.

We have also on our side implemented SSO to connections enabled for different services by using SAML which again, it is not pretty but works perfectly once implemented.

Regarding the in database topic. At the moment dsn-less connections are not supported there and Alteryx is working on it, therefore you would need to have some alias. Would recommend maybe trying out connection files for this case but had no time to test it to be honest.

Hope it helps.

Regards