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.
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
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.
The workflow version that is used when you select Run,Download, or Scheduleon the workflow details page depends on whether you are the workflow owner.
For workflows that you own (that is, workflows in your private studio), theRun,Schedule, andDownloadbuttons point to the latest version of the workflow, regardless of whether it is the published version.
For workflows that you don't own, theRun,Schedule, andDownloadbuttons point to the published version.
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.