This may be a little controversial. As of today, when you buy an Alteryx Server, the basic package covers up to 4 cores :
I have always known that. But these last years, the technology, the world has evolved. Especially the number of cores in a server. As an example, AMD Epyc CPU for server begin at 8 cores :
So the idea is to update the number of cores in initial package for 8 or even 16 cores. It would :
-make Alteryx more competitive
-cost only very few money
-end some user frustration
Moreover, Alteryx Server Additional Capacity license should be 4 cores.
As your analytics work grows - you find yourself using the power of Alteryx to create shared macros. These act as an accelerator for a team because one team member can us a reusable solution created by another team member. For example - many teams need to get data out of JIRA (or some other system) so you create a connector that everyone can use.
That's going well - and now you have 20 teams all publishing canvasses to your server (possibly 100s of canvasses running in production) which make use of your JIRA connector - all good so-far!
BUT THEN - you discover an issue with the JIRA connector and you need to fix it and publish a new version!
It's at this point that you realise that the canvasses on your server which use your JIRA connector are NOT pointing to it, but they have made a copy and included this inside their canvas. So when you fix the problem with the JIRA connector - no-one gets the fix!
This is because every application uploaded to the server is a yxzp file, which zips up a COPY of all the shared macros and uses this in an isolated way.
So - in order to get the new JIRA connector (with the defect repaired) used instead of the old one you now need to:
- Download EVERY canvas on your server
- Unpack them all to expose the sub-macros being used
- Inspect them to see if they are actually an instance of the JIRA Macro
- Make a list of the owner and application IDs
- reach out by e-mail or phone to every one of these folk to ask them to republish their Alteryx workflow with your new version of the JIRA connector.
Please can we revisit this - we really do need the power of shared macros - and we also need the ability to fix and manage these like a product over time. This will have an impact on the engine (hence copying @AdamR )
- When you build a canvas using a shared macro - it doesn't store the macro itself, but rather a reference to the version on the server - unless you explicitly decide to break the connection and take a copy.
- When you check this canvas into the server - your application / yxzp does NOT include a copy of the shared macro - instead it has a reference link
- this means that Alteryx Server can now track which canvasses use this shared macro very simply
- When I fix this shared macro - I can then do an in-place update; or if the interface is not the same (i.e. different inputs or outputs) then this has to be a new version and the users will stay pointing to version 1.
This is how shared assets are managed in a micro-service world, which is the way that all of our architecture is going - and it seems important that we build this thinking into the Alteryx infrastructure too.
We need a way to read a workflow log file while the workflow is running .. we want to peek inside the log file to see what is happening in the workflow, especially for the case when the workflow seems to be "hung". This would be an invaluable troubleshooting tool.
Currently these worklfow log files are locked by Windows and are inaccessible by all but unapproved 3rd part utilities .. if at all.
Often these logs disappear if the workflow needs to be deleted in order to save the environment
It is noted that the service logs do not exhibit this behavior, so the request is to
1) allow the running workflow logs to have the same behavior as the service logs
2) provide a work around to allow reading of the running workflow logs
Thank you for thinking about this
Many people maintain valuable information in Excel files, and many organizations, like ours, also use SharePoint to store and share structured and unstructured information. We see most user-generated and maintained data in Excel files in SharePoint document libraries, and one of the great benefits of Alteryx is the ability to join that Excel data with other data sources. Unfortunately, the v11.0 Scheduler cannot resolve the UNC-style ( \\server@SSL\DavWWWRoot\site-name\document-library\filename ) addresses, so workflows that access this valuable SharePoint Excel data must be run manually. The SharePoint List Input tool can read the list-style metadata for Document Library files, but does not access the file content.
The Scheduler should be enhanced so that scheduled workflows can read Excel data stored in SharePoint Document Libraries.
Admin settings for the Alteryx server are currently split between the Admin GUI in the gallery (screenshot 1 below) and a tool called "Alteryx System Settings" (screenshot 2 below).
Please could you move all of the system settings into the Admin section of the GUI. Not only will this allow an admin to administer the settings remotely (rather than having to be logged into the actual server with an interactive login which is needed now) - it will also consolidate them into one place which makes things easier for admins to ensure that all settings are set up correctly.
This could be done progressively - a little bit in every release - over the next couple of releases, it does not need to be done in a big reengineering or a massive big-bang release (in fact - progressive release is much more favourable since you learn along the way and big-bang releases are well known to be failure prone).
I would like to set a retry count when scheduling a job, and also to specify to duration in between retries, e.g. job fails, but then will retry to run 3 times with a 5 minute wait in between each retry.
Also would like a radio button next to all workflow results, so when you get a list of failed jobs you can click all the jobs and then hit rerun. This should be complimented with select all functionality. This will prevent me from having to go into each job and rerunning, i.e. save me loadsa clicks!
Can we make API function available to assign specific worker node while submitting job request using api.
When posting an app to the Gallery, if the app has, say, one PCXML output for the user to see, and one Excel file for the user to download, it would be helpful for to be able to specify which shows first to the user. For example, I have a PCXML that gives the user summary tables, and instructions on how to go to the drop down above and select the second report, click on the Excel icon, and download it. But if the Excel report shows up first, then there is no ability to give them instructions and many simply won't be savy enough to go find the PCXML in the drop down.
Along with setting a schedule for an app in the gallery, the user should also be able to set the different interface values for each schedule he/she makes.
My main use case is regarding having generic templates for ETL processes, that have multiple different types of runs based on configuration values, but I'm sure there are plenty others.
The Alteryx Server Usage Monitoring & Reporting reports are very useful. In order to automate the distribution and leverage our Tableau Server we have modified one of the macros within to publish the TDE to the Server and reworked the workbook to point to it. This is a fairly time consuming process to do, so the idea is to introduce a version of the workflow which pushes the datasource, producing a version of the workbook pointing to it.
I have described my issue in the Community post here:
Is there a way to retrieve an exact date when new version of a workflow was uploaded to Gallery? I know it works when it is today, yesterday or couple days ago but after that you can only see "2 months ago" etc. in Creation Date, which is not sufficient for any version management.
On the workflow results window, I'd like to see a column for "Start Time". If I have a workflow that is running, I'd like to know what time it started running so I have an idea on when it might finish.
Alteryx Server does a pretty good job of tracking all the information you need in order to find out who ran a workflow at a given time, even if that workflow has been deleted from the Gallery.
However, if I need to identify what that workflow actually did on a specific date, and that version is no longer available on the Gallery, it gets really hard to track down.
There are some posts throughout the community on leveraging the MongoDB to try and reconstruct this, but in some cases the workflow is "Chunked" and becomes impossible for an end user to reconstruct.
I spoke to support about this recently and they suggested that by using the Scheduler, I could schedule the historical instance of the workflow and then "Really quickly" grab it when it was reconstructed from the temporary staging folder used by our Alteryx Server. This has a few concerns, among them, finding a way to run this workflow so that the files can be created but it has no impact on tables, for instance if the given workflow drops a table as part of its execution. Additionally, the only way to schedule with a different set of permissions in a 1-Worker environment is to change the default "Run Workflows As" to a different user, who also needs permission to access all files on the Alteryx Server. This can also impact any other Scheduled or Gallery job that is executed while this recovery is underway, effectively causing downtime to do file recovery.
These restrictions are specific enough as to be impractical for most organizations using Alteryx Gallery/Server.
I think this could be solved by adding to the Scheduler an option along the lines of "Download a copy of the workflow", available to administrators. Ideally this copy could include some important metadata, like when that version of the workflow was uploaded, who uploaded it, and its ID/Version Number from the Gallery.
This would go a long way towards making it easier to Audit and respond to requests for historical information about Alteryx Workflows on the Server, and since the Alteryx Engine can already recreate these workflows, I think that a basic version of this feature could simply save out that temporary file, rather than executing it.
We are hoping to move to Mongo Enterprise as the backend for our Alteryx server, however we may not be able to given that Alteryx does not currently support Kerberos & Keytab authentication.
Please could you add this to the server so that larger clients with Enterprise Mongo can scale upwards?
We spent almost a full day on Friday internally, and also about 3 or 4 hours of time for 3 Alteryx Server engineers (thank you all - MattH; ZachH; WayeW) and Ben Burkholder trying to get our gallery server to start.
Error message was "
Failed to construct Gallery daemon process, process exited code <9002>
This was all that was provided in the server log files; the gallery log files; and the Windows Event Viewer.
In the end, it turned out that the issue was very simple - the MongoDB had open locks in place that needed to be deleted; and then the service came up immediately.
Several man-days of our effort; as well as the precious time of the Alteryx Engineers who gave up their Friday afternoon to help could have all been avoided if the error-message on the server failure said "Login failure on server due to open locks - please clean out locks on db.locks collection" with a link to the solution or a lookup code that be researched on the Alteryx support site.
Please could we go through the server service and eliminate all the exit codes and replace with human-friendly error messages - that way we could allow this kind of issue to be self-diagnosed, and allow the Alteryx Engineers to spend their time building the next generation of Alteryx Server rather than diagnosing a table lock.
Although the connectivity to the eMail infrastructure is set up on the controller and worker nodes - there is no ability to set up automated alerting for errors on workflows from the server.
We would like to be able to set up the gallery as follows:
- Every job is owned by a user or a distribution list
- If that workflow throws an error or warning (this should be configurable on the server, whether warnings are included), then the author should be e-mailed with a link to the specific workflow and the error log.
This can be done in a round-about way, by running an error-reporting alteryx job after the fact - but this kind of alert needs to go out almost immediately given our dependance on Alteryx for specific SLAs.
Hey Alteryx Dev Gurus -
I've got a situation wherein the user runs something in Gallery, and complains. I have to log in as that user to view the output files that came back out. As a super user, I should be able to have all seeing ability! Thanks!
Hi all, Per this thread, it would be helpful if we could have finer control of scheduled jobs in Alteryx Server: https://community.alteryx.com/t5/Publishing-Gallery/Resource-control-on-scheduled-jobs/m-p/61016/hig...
- Dependancies (one job should run after another in a chain)
- lower priority (some jobs should go down the priority queue to allow for others so that high priority jobs are not blocked by other less important ones)
Thank you Sean