Export / Convert Alteryx Workflow to External Queries

[CameronMitchell]

Hello Team,

We have some use cases to migrate our Alteryx Workflows to queries native to external systems.

This is from a data re-usability, performance and strategic architecture approach.

An example:

The current Alteryx Workflow to be migrated and managed via second team who exclusively works within SQL.

The system is firewalled for security reasons so no ETL from the Alterx flow can be placed into this server.
The current use of the data presented form the Alterx flow will be migrated into this strategic architecture for automation.

The question we are posing is, does anyone know of how to convert the current workflow operations into a script that can be utilised within External systems/languages?

To be clear, for the example above. we do not want to have this workflow running within the Alteryx environment, but would like to convert it into a singular SQL script that can then be utilised within the SQL environment for the strategic automation.

[AbhilashR]

Hi @CameronMitchell, I don't think there exists a solution (at least none I have come across) that converts an Alteryx workflow into a SQL logic (or any form of script). 

[JagdeeshN · Accepted solution]

@CameronMitchell 

While there is no out-of-the-box way to achieve what you have described, you can possibly implement an external script to do this for you.

Any alteryx workflow/macro is an XML in the background. So the script can be designed to parse through the queries (input tools) and the tool functions. This can then be used to create a stored proc with all the ELT/process logic that was built into the workflow.

This scripting logic can also be built as part of a 'conversion' workflow in Alteryx which in turn creates the respective stored proc/query.

This way of implementation would require decoding/parsing through the XML and making sense out of the tool actions in SQL terms.

[CameronMitchell]

@JagdeeshN 

Thank you for the confirmation that there is no out-of-the-box approach with this flow.

Our current discussed/discovered approach is to use a combination of manual flow analysis to determine where streams interact and then use a combination of an extract from the XML data and a pseudocode approach to build "table sets" which we can recombine into a flow / query within the end tables.

We are currently following the below approach:

1. Flow Analysis (Determine what occurs, transformations required, split points/combination groups, etc)
2. Re-optimisation (To ensure as many "like" items are grouped together and determine/remove duplicity)
3. Flow Analysis (Re-map after optimisation, determine "end points" for combination sets)
4. Pseudo-code mapping (Map steps/transformations required in each combination group, transformation required between combination groups)
5. Data mapping (Source data specifics mapped, output requirements mapped)
6. System mapping/creation (Create the flow in the designated host system)

The above is a bit expanded, but gives the highest overview of the approach that we are currently taking.

[JagdeeshN]

@CameronMitchell 

Thanks a lot for the detailed explanation of the approach you are taking. Do you have this as a working model currently?

[rvinther]

Did you manage to create this approach? We are looking into converting 500-ish workflows to SQL if possible.