Welcome to part 2 in my 2 part series on File Associations. In part 1, I went over the concepts in base Vault. In this part, I will go over concepts added by Vault Workgroup.
New concepts:
Again we have 2 concepts that are simple on their own, but become complex when added to everything else.
First we have Revisions, which is a way to give meaning to a set of versions. For purposes of this posting, I'll be using alpha characters for revisions and numeric characters for versions.
The next concept is Release States, which is a way of saying that a file is completed if it is in a certain lifecycle state. At the API level, there is a boolean property on LfCycState which tells if the state is a release state or not. A lifecycle definition usually has only one release state, but it is possible to have 0 or multiple release states. For the purposes of this posting, release states will have a darker color than the other states.
One final note: The Vault clients are set up to update files associations only with the physical file changes. If it's just a change to the Vault data (for example, changing lifecycle state) then the new file version points to the same files that the old version did.
Example:
Let's go over an example. Here we have 2 files, a parent and a child. Both files have gone through revision and lifecycle changes. The arrows represent direct associations between the file versions.
The Vault API provides 5 ways to traverse this data. In all these cases, we are starting at the Parent and asking for the entire dependency tree.
- Get Latest - no release bias
This is useful for CAD engineers who want the latest version of all the files so that they can work on them.
At the API level, you call GetLatestFileAssociationsByMasterIds in the Document Service and pass in 'false' for the releasedBiased parameter.
- Get Latest - release bias
This is useful for people outside the CAD department who are not interested in the 'work in progress' data. They just want to see the latest completed product.
At the API level, you call GetLatestFileAssociationsByMasterIds in the Document Service and pass in 'true' for the releasedBiased parameter.
- Snapshot in Time by Version
This is useful in cases where you don't care about revisions. The result is what you would get in base Vault, you only get the direct relationships between file versions.
At the API level, you call GetFileAssociationsByIds in the Document Service.
- Snapshot in Time by Revision - no release bias
This gives you the latest version within a revision, regardless of the lifecycle state.
At the API level, you call GetRevisionFileAssociationsByIds in the Document Service and pass in 'false' for the releasedBiased parameter.
- Snapshot in Time by Revision - release bias
This gives you the latest release version within a revision. If no release version exists, the latest one in the revision is returned.
At the API level, you call GetRevisionFileAssociationsByIds in the Document Service and pass in 'true' for the releasedBiased parameter.
You should be properly confused by now. However there are a rule that will simplify things.
| Rule: When dealing
with revisions, think in terms of revisions. Don't think in terms
of versions. |
Behind the scenes, revisions only care about 2 versions: the latest version in the revision and the latest release version in the revision. Many times these 2 are the same thing. When thinking in terms of revisions, you need to forget about all other versions.
So let's redo the dependency tree for 4 and 5, this time viewing things in terms of revisions.
- Snapshot in Time by Revision - no release bias
- Snapshot in Time by Revision - release bias
Subscribe