Managing Shared Gallery Connections Across Several Environments

Question

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.

afv2688 · Answer

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

AntonioKeyrus · Answer

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

raychase · Answer

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.