My team currently uses the API to call a large number of workflows via a Python based scheduler process. We use this currently by having ~10 users in a single subscription (Private Studio).
All of the Private Studio sites on the Alteryx help state that they are going away in the near future to be replaced by individual studios and Shared Collections.
From our testing, this would kill our processing as we cannot have an API for 1 Private Studio call workflows from a different private studio even if they have access through a shared collection.
Are there plans to adjust the API endpoints in the future to better account for this?
Our IT department is looking to move to the Collections based structure now in preparation for the removal of the current Studio setup, so another question is when the structural update is planned to go into effect (which server version should we expect this?) so that we can get ready to account for this or if we can ask them to back off a little.
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.
Using current version of the server - you can see that there is no OAuth managed or published API endpoint for canvas delete (screenshot 1). However this API does CLEARLY exist as you can see if you inspect what happens when you hit the delete button (screenshot 2 clearly shows the API being called - but it requires user login security token)
Please can you enable this API for OAuth - the API already exists, it just needs to be exposed with the others.
We use the Server API to manage our server environment - and we recently noticed that the Workflows API (/admin/v1/workflows) ignores any canvasses after the 10 000'th submission.
By querying Mongo directly (appinfos collection) we know that we have 18 800 or so unique applications in our environment.
Please can you remove this cap from the API so that it can be used to query any number of canvasses on a larger environment?
I’ve had a query from a Team here at my organisation regarding OAuth2. They are trying to investigate whether a Robotic Process Automation Tool can be integrated with the Alteryx Gallery API.
It uses OAuth2 but my understanding is Alteryx Gallery uses OAuth1.
Can Alteryx Gallery API be enhanced to use OAuth2? A plan to support OAuth2 authentication for a REST API in a future release?
A nice to have is a connector for Microsoft Flow to trigger workflows. With Microsoft Flow, users can automate processes, or set conditions that can trigger services across many different providers.
Having the ability to use a Microsoft Flow can enable alteryx users to run workflows and feed in data that could be used by Microsoft Flow to feed into other processes.
This would be a game changer for many users.
We have a usecase where we want to check how often a workflow runs via the API so we can automate the consumption reporting we do internally. Right now the API only reads out workflows that were scheduled using said API. That doesn't make a whole lot of sense. Enabling it to also read out all the other workflows would really make this a powerful feature for us and I suspect others.
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.
I created before a post about managing chained workflows using the API.
After reaching out the support, it turns out to be impossible, which is unfortunate.
So I post this idea here, in case anyone is needing it too.
Feels free to ask me details if needed.
We use external corporate scheduler and we would like to start scheduling Alteryx workflows in this way. However, collections don't have API which would simplify our way of running workflows which we are shared by the users. Are you planning to enable such feature?
We are taking an incremental feed of all server canvasses in order to look for patterns - however there is no option on the server admin APIs (the Workflow API specifically) that allow you to filter by date.
Please can you add to this API to allow API users to specify an upload/updated date filter and only take items after this date.
There are two key APIs that we use for extracting canvasses for governance & surveillance:
- the Workflows API which lists all canvasses on the server;
- and the API call which returns a packaged version of the application by AppID
Unfortunately - when we query for all workflows to get the first list - there is no flag to indicate that a subset of these are actually deleted. The result is that you need to make the second call to find this out which is wasteful.
Please add a "deleted" flag to the Workflows API so that we can identify which applications have been deleted without having to call the specific App ID post.
We've confirmed with @KevinP that the Alteryx Gallery / Server API does not currently support downloading canvasses in unzipped data-stream format. (https://community.alteryx.com/t5/Alteryx-Server-Discussions/Server-API-Download-packages-for-surveil...)
Please can we add an API end-point that allows the following:
Current API only allows this to be downloaded to a zipped file; which then needs to be unzipped; and then loaded back into a data stream.
Our company has workflows where we use the Gallery API to kick off executions on server. The user kicking off the workflow has setup API access using his account, but when he kicks off his jobs, it does not show up under his Gallery so he is unable to view the results. In the admin panel, it shows the owner as (None) so it does not appear that workflows kicked off via the API get assigned to the user tied to the API key.
Conversations with Alteryx support revealed that these results are available via an API call, but not within the Gallery web UI. It would be great if the user tied to the API key were added to the workflow execution so they could see results within the Gallery rather than going back through the API.
It might be helpful to be able to use an API to call and pass parameters to/from an Alteryx App or Workflow on an Alteryx Server. Then a user could use a browser or another application to call an Alteryx app/workflow.
Just like the workflow upload API, could you please provide an API end-point for deleting the workflow,Job results and it's related information. In a scenario we might use gallery for one time execution of workflow, once the output was generated there is no point to have some workflows in the Gallery hence in this scenario the Delete API helps as a clean up activity on the Gallery to avoid the Junk/Unused information (Workflow/Job/Outputs).
Are there any plans to add support for the Spatial Object, File Browse and Tree questions for the Gallery REST API?
I see via the Interface Viewer in Designer that the "answers"/values to these questions are just (messy) XML I realize the File Browse could be difficult because it would involve accommodating some type of BLOB data but the Spatial Object (one or more lat/lngs describing a point or shape) and the Tree questions seems to be fairly straightforward.
We currently get around the Spatial Object limitation by specifying a latitude and longitude (for a Point) in text boxes. For shapes (polygons) we just stuff the WKT (Well Known Text) representation of the polygon in a text box. This works fine but requires special handling on the workflow side.