Moving workflows between Dev/Test/Prod

[dadams]

I've been searching, with no luck, for a "best practice" to use for moving workflows between environments.  I found a post here that gave a good method for automating file paths, but manually changing all the database connections to point to Prod instead of Test seems really tedious.  Any help would be much appreciated.

[TylerNg]

@dadams Can you expand more on your situation? So your PROD and TEST servers are clones of each other? Including clones of databases? 

This is how I am interpreting your 

1. Develop workflow on Test Server
2. Workflow's database connections point to a database on the Test server
3. Once workflow is ready you want to move it to your Prod server
4. Moving the workflow is fine but the problem is changing the database connection on that workflow to a database on your Prod server

Do you have a gallery on both servers?

Tyler Nguyen

Customer Support Engineer

[dadams]

Hi Tyler - thanks for your response!  Your assumptions are very close.

The data sources are varied, from .xlsx to api's.  All three environments will use the same sources.  The workflow outputs to one of three postgres databases - one for each environment.  These three databases are all hosted on one postgres server instance.  We have one Alteryx Server license, so there's only one Alteryx Server to work with.

The goal here is to move workflows from environment to environment without having to change database connections.  Or, if that's not possible, then to make one change to them.

Maybe we make some collections in Alteryx Server?  I've searched a lot for best practices in managing this process and have come up with almost nothing.  Any insight would be much appreciated.

Best regards,

Dave

[TylerNg]

Hi Dave,

There a couple things you can do...

1. Use workflow constants. This would require changing one value as you move workflows from environment to environment
2. Use the detour tool
3. Make 3 different shared Data Connections on your Gallery each one pointing to their respective database. You can then go in Workflow Dependencies and change the alias to whichever one when moving environments. 

I would personally use the 3rd option. You can go into the Workflow Dependencies of the workflow and just change the part after "aka:" 

You can change that to the Alias of your Data Connection (whatever you named your Data Connection on Gallery) or you can use the ID which appears on the URL of the data connection 

Tyler Nguyen
Customer Support Engineer

[benjamesdavis]

I tried using workflow constants to swap out parameters of a DB connection string, using:

oci:username/%User.Password%@(DESCRIPTION=(ADDRESS_LIST=(ADDRESS=(PROTOCOL=TCP)(PORT=%User.Port%)(HOST=%User.Host%)))(CONNECT_DATA=(SERVICE_NAME=%User.ServiceName%)))

However...for %User.Password%, it seems Alteryx is encrypting the workflow constant name (i.e. "%User.Password%") before the value (i.e. the actual password) has had a chance to load in. Therefore, I get hit with an invalid username/password error.

Does anybody know a way round this?

Cheers,
Ben

[DCPDamon]

Tyler, I can't get this aka ID change to work in our sytem.  From our Dev server I opened a workflow from the Prod gallery.  There should have been two sets of dependencies, one that said aka:eSuite (for inputs) ad one that was just .\ (for outputs).  When I opened Workflow dependencies, every input and output tool was lumped as a dependencey of .\.  Which means first I had to sort out all the inputs fro outputs.  Then, I tried to put in the ID for the data connection in that environment (aka:123123245345).  But when I tested it, it said directory not found.

I've found that when using Workflow dependencies, if the dependency is already a aka, then you can put in a new aka.  But, if it has .\ it thinks it's looking for a file and there's not way to make it understand you want it to use a gallery connection.  So you're left with going into each and every tool and retyping in the aka.

Any thoughts?

[dalchand]

Database connections are relatively easy to maintain. You can create ODBC DSN with same name in DEV/TST/PRD and use the DSN in your workflow to connect to the database.