Currently, even if Alteryx Server is installed in E drive, RuntimeSettings.xml is generated in C¥programdata¥alteryx. Users cannot replace RuntimeSettings.xml to other folders.
It would be nice if a feature that users can specify place to save RuntimeSettings.xml.
Or, it would be nice if this specification is put in the documentation.
This issue relates to an inability to input data from a database where access to only certain columns is permitted. This is due to PII data being present in the data.
I am trying to pull data from one table at a time using the standard ‘Input Data’ tool.
As I do not have table level access I am explicitly specifying the column names and not using a wildcard. Please see the example below, query highlighted in yellow and the returned error in red. You will see the error message returned from Alteryx suggests a * wildcard has been used despite specifying the exact fields to pull.
Several of the Ford GDIA team and Ford HPC team have reviewed this with me and cannot assist. The HPC team believe it is a bug in Alteryx which has been reported by other users internally, that is ‘Select *’ commands being sent from Alteryx despite specific columns being outlined in the query to the data lake. As we only have access to specific fields within Ranger (due to PII data) the select * fails and returns an error.
I can confirm my ODBC connections are all set correctly as I can pull from certain tables where I have full table level access but not others. Access rights are all in place as I can use the same query on Ambari without issue.
Thank you for any assistance you can provide,
Select STATION_ID, STATION_DESC from dsc60082_qlscm_tz_db.qlsc_station limit 10
Info: Input Data (3): ODBC Driver version: 03.80
Error: Input Data (3): Error SQLPrepare: [Hortonworks][Hardy] (97) Error occurred while trying to get table schema from server. Error: [Hortonworks][Hardy] (80) Syntax or semantic analysis error thrown in server while executing query. Error message from server: Error while compiling statement: FAILED: HiveAccessControlException Permission denied: user [mhiggi37] does not have [SELECT] privilege on [dsc60082_qlscm_tz_db/qlsc_station/*]
I believe it would require turning off the queries we currently run to retrieve metadata and retrieving metadata only for the columns selected in the query.
Please submit to our Idea Center for consideration. Thanks!
Angela Ogle | Customer Support Engineer
Would like to see a Notification hierarchy implemented to Gallery. Currently, the settings that control notifications are at the Gallery-level....where only the admin can control, for example, notifying users if a new workflow was added to a collection they belong too. Could this setting be inherited, but then, for example, a Collection owner can implement their own notification settings that overrides the Gallery default? Using the same example as before, perhaps the Collection owner could disable notifying their Users if a new workflow is loaded to the collection.
I have three team members all in the same private studio. We can see each others' workflows. However, when looking at a workflow that another team member has published to the gallery, it looks like:
This is a massive impediment to collaboration because my team handles ETL for most of the company. If a user complains that their data isn't up to date, whoever receives that support ticket needs to be able to see if the workflow is actually running and whether it was successful or had an error during the last run.
Preventing a team from seeing this for each others' workflow schedules and results means that the only person who can deal with an issue is the person who originally made the workflow. Which makes the idea of a shared private studio wholly pointless as we may as well be operating in different universes.
Please create a studio-level setting where all members of a studio can see all schedules and results of all workflows in that studio.
The Save to Gallery window does not resize. When I try to Save my Workflow to my Gallery and Manage Workflow assets, I can not widen that window to see the full path to my assets.
This makes it very hard when you have many assets to know if they need to be included or not with the promotion. It may take two or three attempts guessing what asset is what to get the correct combination to make my App run correctly.
It would be nice to be able to widen this window much like we can with the Workflow dependencies window.
When an artisan moves positions (within or external) away from their current responsibilities, their collections and workflows should be able to be transferred via an administrator to another user.
we are in a dynamic team where people move from 1 project to the other that implies moving series of workflows from private studio to collections prior to sharing. I have not found other ways but to do that 1 by 1 with very limited ways to filter the flows.
Could there be, from the collection, a way to
- increase number of possibilities to filters to find the proper flows (or maybe just simply allow folders in the Private studio)
- be able to multi select the one to add / delete from / to the collection
As the Server Admin I'd like to have the ability to view ALL "Workflow Results" for all Subscriptions.This will give the highest level admin the ability to monitor all schedules (on the entire server instance) and monitor if they are unable to complete successfully (example- unable to allocate memory) and any other errors are occurring.
Knowing this information will help the server administrator understand if there are issues with the server itself (e.g. if we need more workers or to simply adjust actual server system settings..etc..)
Now, gallery does not support AD group , need to setup user one by one.
If gallery support AD group synchronization, it is more convenient for gallery admin to manage large number of users.
By assigning AD users to AD group, it will reduce the maintenance task of gallery admin, since gallery admin don't need to grant rights in the gallery directly.
This post illustrates the current state of how the Gallery and Scheduler interact with time zones as of V11.7. The behavior it showed in that test is unintuitive and may lead to issues with setting schedules correctly. One possible correction would be to unify all times on the server to server time, but I think we can do better.
What I suggest instead is to add time zone as an option on the scheduler. This way users that set schedules don't ever have to wonder at what time the workflow is actually going to run. That information can also be passed through to results such that users that want to make sure a schedule is working as planned don't have to back track and figure out if 5pm means 5pm their time or server time. Finally, it would allow a more intuitive way for an employee in Denver, CO schedule a workflow such that his or her boss in Irvine, CA receives the resulting report exactly when needed/expected.
So - one of the biggest challenges that we have with the MongoDB used by Alteryx Server is that we continually have issues with locking (where our admins have to go in and undo locks)
Additionally - the current implementation of MongoDB connectivity does not support full Kerberos authentication which means that we're on a non-compliant install (which in a large enterprise is an uncomfortable place).
Given that a very large amount of what the server does is transactional - it would make sense to have an option to use a large-scale SQL server instead of using Mongo. For large enterprise customers, there must be flexibility to allow the databases that they have large supported instances of (my strong preference would be MS SQL 2016).
MS SQL natively supports XML so all the canvasses can be stored in native format. Additionally, MS SQL allows very fast query across XML, and given the clustering and reporting capabilities in MS SQL, this would dramatically increase our ability to self-manage our infra.
Given that Alteryx is looking more and more at large Enterprise customers - a move to a large-scale clustered SQL env as the back-end would be a very positive move.
NOTE: as we consider DB options for a SQL backend - please consider your large-scale enterprise customers. For example - MS SQL or Oracle or DB2 are all much more prevalent in enterprises than databases like Postgres - so it's important to focus on the enterprise support for the DB that you choose.
Given the need for administrators to be able to perform analysis and monitoring on server performance; user usage etc - it is necessary to provide full documentation for both the API and the database underlying the server so that admins can use this to good effect.
Although very limited documentation is available on the server API (https://gallery.alteryx.com/api-docs) what we're looking for is a much more fully formed and navigable experience like some of the examples below.
This will make building helper processes substantially easier; as well as allow admins to fully manage their environment.
Please support GZIP files in input tool in Server. This is related to https://community.alteryx.com/t5/Alteryx-Product-Ideas/Support-for-GZIP-gz-compressed-files-in-input..., but logged in a separate Idea because the staff indicated in the thread that they are planning support for GZIP in Designer only in 2018.2. We need it in Server as well.
When we create a shared macro on the Gallery, the desire is that we are able to:
- publish this down to users simply and seamlessly
- Allow them to use these assets in their canvasses
- Allow them to simply update to the latest version of the asset on an existing canvas.
Unfortunately - right now the only way to distribute shared macros is to create a shared folder; and the only way to manage version upgrades of a shared macro is to manually find every single usage and manually upgrade.
We currently have the ability to store connections on the server which protects the credentials - however this capability does not exist for APIs for Sharepoint sites etc.
Please could you extend this to cover authentication for ALL connectors?
There is no good way to get server user credentials into a workflow without asking them for it in an App interface. It would be great if we could have a built in Constant that could be used to silently pass user credentials into a workflow for things like API's or logging user information.
Currently there are certain locations on server that are paginating content results:
Each of these pages require users to either know exactly what they want to find by using keyword filtering or know exactly what page they want to go to and use the bottom arrows/page numbers to navigate to that page. Ditching pagination for something more intuitive helps users that may not be as acclimated with the depth of content when there are a lot of results, and also saves users multiple click interactions to find what they want.
There are tons of solutions for this, but infinite scroll is the most user-friendly & least taxing server & client side.
https://infinite-scroll.com/ has code & examples, and jquery seems to be the most widely used implementation.
Currently the InDB tools require to select a DSN that is defined on your computer.
This makes any workflow which uses a DSN incredibly painful to deploy to the server, since the DSN needs to be created on every worker node and for a large server environment this can mean creating DSN entries on 6+ worker nodes in prod plus prod server plus dev/UAT environment plus dev/UAT worker nodes.
Could we please change the InDB tools to default to DSN-less connections, where the connection persists the connection details in-line so that it can deploy to the server without a DSN setup (since all connection details are contained within the connection string)?
This idea covers 2 things:
- Disabling certain tools for users
- Pushing out other tools
- If we want to disable a particular tool for everyone or for specific users - then we need to go to every single deployed machine and adjust settings or delete some DLLs.
- What we would need is to be able to take a user / group of users - and de-select certain tools or apply limits
- In our corporate environment - every designer needs to check in with the server before fully starting up. If it cannot connect to the server, it needs to terminate gracefully
- As the designer logs in - the first negotiated conversation is "What tools and capabilities and standard default settings should I have"
- If a useful tool is brought into our environment (like the JIRA connector here: https://gallery.alteryx.com/#!app/JIRA-Connector/58d87c2feffc2a0dd0b5ed8f or the CREW macros) - we want to be able to push these out to all the users
- Again - every designer checks in with the server first
- Then negotiates tools
- then downloads any missing tools or updates new versions of existing tools.
This kind of central server capability is essential in any enterprise deployment of several hundred seats.