This site uses different types of cookies, including analytics and functional cookies (its own and from other sites). To change your cookie settings or find out more, click here. If you continue browsing our website, you accept these cookies.
I've seen this question before and have run into it myself. I'd like to see a new tool that would allow a developer (of a workflow) to choose a path of logic based upon criteria known only during the execution of a module.
If LEFT INPUT Count of records < 10,000 THEN Path1 (e.g. use a calgary join)
Currently, the scheduling via designer controller is independent of the gallery. So, even after a canvas is deleted, the scheduler still continues to execute the cached version of the canvas, as long as the scheduler exists.
Note, this issue does not occur when the canvas is directly scheduled in the gallery, and only occurs when you schedule via the Designer on the controller directly.
Steps to replicate issue:
1) Publish a canvas into gallery
2)Schedule the canvas to run daily via the Designer --> Options --> View Schedules --> Select Controller --> Create new workflow and schedule
3) Delete the canvas from gallery
4) You will notice that the canvas is still getting run on the defined schedule, even though you have deleted the canvas
Observed in Alteryx 11.5.1
Golden copy of a canvas should be the version existing in the gallery. Once the gallery instance of the canvas is deleted/replaced with a new version,
All related artifacts to the old version should be marked as "Deleted"
All existing schedules should be stopped from being executed
We should continue to retain all meta data attributes and execution history related to the old version (should not be wiped out) but clearly marked as archived/deleted
Preface: I have only used the in-DB tools with Teradata so I am unsure if this applies to other supported databases.
When building a fairly sophisticated workflow using in-DB tools, sometimes the workflow may fail due to the underlying queries running up against CPU / Memory limits. This is most common when doing several joins back to back as Alteryx sends this as one big query with various nested sub queries. When working with datasets in the hundereds of millions and billions of records, this can be extremely taxing for the DB to run as one huge query. (It is possible to get arround this by using in-DB write out to a temporary table as an intermediate step in the workflow)
When a routine does hit a in-DB resource limit and the DB kills the query, it causes Alteryx to immediately fail the workflow run. Any "temporary" tables Alteryx creates are in reality perm tables that Alteryx usually just drops at the end of a successful run. If the run does not end successfully due to hitting a resource limit, these "Temporary" (perm) tables are not dropped. I only noticed this after building out a workflow and running up against a few resource limits, I then started getting database out of space errors. Upon looking into it, I found all the previously created "temporary" tables were still there and taking up many TBs of space.
My proposed solution is for Alteryx's in-DB tools to drop any "temporary" tables it has created when a run ends - regardless of if the entire module finished successfully.
I was wondering if any of you have achieved "Transaction rollback" type of feature in alteryx.
Following is the usecase:
If a workflow that writes data into multiple outputs (could be relational tables / files) is failed half way through in writing to one of the outputs, is there an option to rollback the partially loaded data & reset the process to the original state (i.e., before the execution of the workflow)? (OR) does this needs to be done programatically?
There is a workflow level property - "Cancel Running Workflow on Error". This stops the execution but doesn't perform rollback.
The Listbox (interface macro) is currently populated statically when sourcing values through a Connected tool. Whatever, I configure in the macro is retained. When I use the macro in a workflow the LIstbox values are not updated when the fields in the connected tool are changed. This practically limits my capabilities to build a truely dynamic macro/app.
The Listbox should be able to show dynamically the fields coming in through the connected app.
Currently if a user has multiple connections in a workflow that connect to a password-protected source, and that password changes, the user will be locked out of their account by login attempts as Alteryx attempts to validate the connection.
Today I had to manually edit the XML of another user's workflow in order to remove references to their server, so they could correct their password without locking the account for a third time today.
While I understand that aliases are a good workaround to this problem, the issue still has potential to occur.
Having an option to load a workflow in a "SECURE" or "SAFE" mode, where it would not validate a query until runtime, or refreshing the metadata manually, would help to significantly reduce lockouts which would improve the usability of the tool.