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.
Putting it All Together:
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
There, much better.
Leave a Reply