Hi,
When I extract workflow data from AS_Applications, either using the MongoDB tool or an API call, I get a tree of information, as would be expected for a document based storage system. A rough representation of that tree, as I understand it, is shown below.
What I need to know is how I determine the current values of the fields that are held under the revision structure?
Are they held in revision0 (for convenience that would be ideal)
Or do I have to determine the highest revision number for each field and get the value from there(since not every revision appears to contain every field)?
Workflow "Header" fields
- e.g. creator.email
creator.firstName
creator.id
creator.lastName
creator.subscription.Id
creator.subscription.Name
iconId
.====>revisions
* revision number
-e.g. author.email
author.firstName
author.id
author.lastName
author.subscription.Id
author.subscription.Name
canDownload
credentialType
dateCreated
.====.====>applications
* application number
(a couple of fields that describe application parameters for multiple apps for this revision)
name
filename
Solved! Go to Solution.
I would recommend using the PublishedRevision metadata from the appInfos collection, within the AlteryxGallery database. That's where I pull the current metadata for workflows.
Thanks. That's at least a solution for going direct to the MongoDB.
I'm trying to move over to using the API. I'm thinking that is the correct thing to do in future as it should be agnostic to any changes in the DB schema and presumably will be the way that the Gallery actually accesses the data?
It looks like there is some sanity in the MongoDB design in that revision0 is the current state of the meta-data and revision1+ are the previous states going back in time. The give away here was that I spotted the "version" field which increments as the revision decrements. A bit of testing then confirmed that this appears to be the case.
I have come to the same conclusion, that version 0 is the latest workflow, with each new version bumping the old versions out by 1.
Your logic might be slightly flawed, as it is theoretically possible for the LATEST version to not be the PUBLISHED version (ie. you can denote version 3 as the published version, even if there are 5 versions of a given workflow).
As such, I suspect that PublishedRevision might not always = Revision0, in terms of Metadata. I haven't actually confirmed this, but it is my suspicion.
>> it is theoretically possible for the LATEST version to not be the PUBLISHED version
Hmm, that's pretty frustrating since the API call for workflows (GET /admin/v2/workflows/all/) doesn't appear to return any information on the published version, presumably because that is held in the Gallery database and not the Alteryx Service DB 😞
I'm thinking now that I need to use GET /admin/v1/workflows/ , which is unfortunate since that throws a 500 error when I try to use it on our 2020.4 system.
Also would you be able to point me to the documentation on how to make a version other than the latest one the "Published" version.
This isn't formal documentation, but here's a screenshot of a workflow of mine with multiple versions. Note the P (published) next to Version 8. I can easily click any other version and then click the 'Make Published Version' button to transfer the P to that version. Note that scheduled jobs will always run the published version, and the default option when saving a new version of a workflow to the Gallery makes the new version the published version.
Here's Alteryx' version of what I just said:
https://help.alteryx.com/current/server/publish-workflow-version
Thanks for the additional information. I'd missed that as I'm usually in the Admin view and on those pages the Workflows don't show version information.
>>Note that scheduled jobs will always run the published version
Yes but... no, just to add to the mix I just found this:
https://help.alteryx.com/20204/server/workflow-version-history
Latest versus Published Versions
The workflow version that is used when you select Run, Download, or Schedule on the workflow details page depends on whether you are the workflow owner.
The idea is that, as the owner of the workflow, you would want to run the most recent version for development and testing purposes. If you want to run a different version of the workflow you can do so from the Version History screen.
That is a great find! I wasn't aware of that, but it does make sense.