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.
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 COPYof 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.
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.
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.
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.
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.
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.
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?