Alteryx Server Ideas

The current Enterprise Utility Workflow does not have a match/look-up in place between the two environments for user ID's.  Thus, the migration workflow doesn't work without adding in a couple extra API calls.  When we upgrade to a new version of the utility, I have to add this back in. 

It would be nice if the workflow would come with this already configured.

The V3 jobs API endpoint woefully lacks any usefulness. The current endpoint only has a get jobs/{jobid} method that is not useful because a database admin must query the database to get a list of all job IDs. To add insult to injury, this method is only limited to the user whose job is running or queued.

These are new features that I am proposing

1. GET jobs/list—This method must be callable by all users. Parameters such as none (default—full list), running, or queued will display jobs with the appropriate status. The job ID of the running or queued job and the worker it is running on must be included in the resultset.

2. GET jobs/{ownerid} — This method must be callable by all users. Like the GET jobs/list above, the resultset must include the job ID of the running or queued job and the worker it is running on.

3. DELETE jobs/{jobid} — This method must be callable by the person who scheduled the job, the owner of the workflow, or the curator. This method is the equivalent of cancelling a job on the Server Admin page - #!/admin/jobs by a curator. All three mentioned people have a vested interest in the running or queued jobs on the server and must be able to cancel those jobs.

4. POST jobs/reassign/{jobid}/{new_job_tag} — This method is restricted to the curator and applies to any job in a queued state. It allows a curator to reassign a job to another job tag or the first available worker for reasons determined by the curator.

This is an enhancement that I am proposing
1. GET jobs/{jobid} — This method must be callable by all users. This will allow any user to get the details of any running or queued job.

Logging requirements

All DELETE or POST methods must be logged and purged based on the Persistence Option > Delete queue and results after (days).

You cannot currently upload a new workflow and specify your own workflow_id GUID.  This would be useful for systematic workflows that need to be referenced in code.  Currently, you either to search for a workflow by name, but you are not guaranteed it a workflow instance you uploaded.  This would be helpful for server and workflow administration.

Given there are multiple api versions.  I need a way to call the api and get the server version so I can make the correct API call or construct code logic which provides the user code requirement based on the versions features or limitations.

I propose a api call ../getserverinfo/ that returns server metadata like version, default worker thread count, and default memory allocation.

There is currently not a way to call the API and find out the calling user.  For instance, if I have a user API key and secret, I  to return the rest of the user info for the calling user or who is calling the api.  I propose a api call like ../user/whoami

Hello all,

According to https://openlineage.io/ 

An open framework for data lineage collection and analysis

Data lineage is the foundation for a new generation of powerful, context-aware data tools and best practices. OpenLineage enables consistent collection of lineage metadata, creating a deeper understanding of how data is produced and used.

 
This is typically the open standards needed for lineage analysis and I think it will become more and more a differenciator with your competitors. As of today, DBT or Apache Airflow already supports it (as producer), Egeria or Marquez already support it (as consumer) and guys from Datahub are working on it  (as consumers)https://feature-requests.datahubproject.io/p/openlineage
So I think Alteryx should implement this standard API as a producer, it's the next big thing in Data Governance and you don't want to stay behind !

Best regards,

Simon

Hello,

Tableau has a nice Postman Collection available... it's really easy to use since you can download or forkt it on Postman and all you have to do is to write the variable values.

I would like the same thing but for Alteryx.

Best regards,

Simon

The AlteryxService internal authenticated API that the nodes use to communicate with each other for status is not accessible to customers because it is using an undocumented authentication method. The data this appears to provide would be useful to server administrators to determine the true health of the individual nodes and for reporting purposes.

API that allows to specify the workflow version to download.

I have tried so many python packages to Refresh excel Pivot table automatically through Alteryx and save the refreshed data, most of the packages are working perfectly on designer but none of them are working on server.

If we find out anyway that will refresh pivot tables of Excel through Alteryx then it will be great for us. 

Currently, the API V3 endpoints does not have anything for Data Connection Manager (DCM). Create an endpoint to allow users to add/delete/update and list data sources, credentials, and users of DCM data sources. Also include an "admin" endpoint that can list all of the above for the entire server.

The admin screen of Alteryx gallery does not have an admin function for DCM sources, its users, and credentials. This can cause visibility issues during audits of the gallery. An API endpoint can alleviate this issue until it is added to the UI.

Enhance the v3 APi for workflows - /v3/workflows/{workflowid} - to get information for first n versions and/or last n versions of the workflow.

The problem

The current API will return information about all versions of a workflow. If a workflow has several hundred versions, you'll get all version information, much of which is useless and can take a long time to process.

The (potential) solution

Allow the API to take parameters like first n versions and last n versions. This will allow the API to return only the respective version information that would be of interest to the user.

The red box in the image is the enhancement in swagger:

Hello Alteryx Developers,

It would be great if you develop a way to connect the Alteryx Designer to AWS Redshift by SSO. When i try to set this type of connection at the Simba ODBC Driver it opens the connection several times with AWS at the browser and that ruin the customer experience.

Best Regards

Danilo Benjamin

Today the v3 api requires curator access.  V3 has Getters that should work for users with API permission.  The Getter should return the objects that user has access to.   Example:   GetCredentials for a normal user with API access should return credentials that the user has access to.  Today they get a 401 auth error.

We don't want to make these users curators just to let them access the V3 api.

I have inherited admin duties, and have been running to many problems. Some of which will escalate when the subscriptions go away. 

The pages desperately need to be updated for a more streamlined admin experience.

Couple examples I came up with below. 

Naming Convention

• Allow workflow renaming without the replace function.
• Force a unique plan name across all private studios. instead of being unique on just ID.

API Access

• Allow any user who can access the module from Collections to be able to trigger it from the API using their own API key.
• Store results of "API" triggered workflows on the page.
• Groups:

• Identify Users without a group
• Identify users in more than one group
• Add multiple users at one time (Muticheck box) with filters.

User Page

• Add/remove Users to Groups
• View, add, and remove Collections from Their User Page

Collection Page

• Add Collection from the Admin collection Page

Designer "save" window.

• Give the ability on Save As & Save for the user to automatically share the plan with their collection(s).
• Default all "Workflow" assets to be unchecked by default, rather than relying on users to click "workflow options"," manage workflow assets", and then uncheck everything.

Workflow Page

• Change Owner (Can be limited to admin only)
• Add directly to collection from this page.
• Do not reset the "private data exemption" to default every time an updated version is updated.
• Allow admin users to see logs of all users who run the plan (Also add this to the admin page while you are at it)

Would like to see more flexible options for workflow run-as credential settings, both for when publishing the workflow and kicking off the job. 

Here is a thread where we discuss the limitations we are seeing when trying to publish the workflow to Gallery via an API. We would also like to see more flexibility when our users want to kick off their workflows via an API where they could pass in different run-as credentials they would like the job to run as.

Currently we can only configure questions and flow priority when using the POST API to queue workflows.

Would be good to be able be able send some of the Runtime configurations as well.

This would allow for much more flexibility.

Example

{

"questions":

[

{"name":"Test_dt","value":"1/1/2020"}
,{"name":"Test_Num","value":"53"}
,{"name":"Test_txt","value":"schedule test"}
]

, "priority": ""

"disable browse":"True"         // When running flows in production this would reduce resource usage as data will no longer be cached. Having it as a parameters would mean that we can ensure that it is disabled

,"disable output":"False"       

}

Current Fields

Possible other fields

The full question tree is not visible within the JSON object returned when requesting the 'Questions' in the .yxwz file on the Alteryx Server. There are nested questions that are visible but there is no indication that they are nested, missing label groups, tabs and no indication whether a question should be shown or hidden. This is limiting.

A full question tree in the JSON would allow for dynamic interpretation of the 'Questions' in the .yxwz file as structured through the Interface Designer.

Regards,

Ben

Currently, in order to run an app via the API, you have to have uploaded the app to your private studio. Frankly, I don't find this function useful because you have to download then re-upload an app in order to gain access to the API. The API would be more useful if when an app is shared with you (or a collection is shared with you), then it would also allow for that app to be run via API by the user it was shared with. Right now, the only person who can run the app via API is the user who originally uploaded said app.