The Vault 2014 SDK has some nice goodies for the development community. Of course there are also changes that you need to make when upgrading your old code. I’ll be going into each of these topics in more detail. For now, here is a quick overview of what’s new.
The VDF
We came up with a set of tools so cool, we had to come up with a new acronym. The Vault Development Framework (VDF) is a set of client-side libraries to support higher level operations and workflows. It’s basically there so that you can do more with less code.
Here is a brief look at the architecture.
The VDF doesn’t provide complete feature coverage, so there are still many cases where you need to make web service calls. If you are updating your code from a previous release, your web service calls can stay in place for the most part.
There are some VDF pages on the Vault Wiki. I’ll be covering the same content on my blog in the upcoming weeks.
Filestore Server
The web services have shifted around to incorporate the concept of a filestore server. For many years now, the top tier Vault products have allowed for the filestore and database to be on separate servers. This is a good feature, but the API wasn’t reflecting the architecture. All API calls used to go through the server with the filestore on it. It’s not a very good approach since a second hop would be needed for database data.
In Vault 2014, the API has been re-designed so that database-related calls go straight to the database server and file-related calls go straight to the file store. The WebService manager takes care of most of this for you, but there are some changes that will impact your code…
Uploading and Downloading
Uploading and Downloading requires both database and filestore data, so those operations can no longer be done in a single call. The good news is that the VDF wraps the extra complexity. I suggest you use Connection.FileManager.AcquireFiles for download and check out. The FileManager also has AddFile and CheckinFile for the upload-related tasks.
API Compatibility
Vault 2014 continues with the web service API compatibility feature from the last release. This time around, Vault supports 2 releases back, which means Vault 2012 and Vault 2013 clients will still be able to talk to a Vault 2014 server.
Just like before, the compatibility feature only applies to the web service layer. All other API features are version-specific.
Vault 2014 will be the last release that supports the 2012 web services.
.vcet.config Syntax
The XML syntax has changed for the .vcet.config files. The new format is more flexible and allows for new extension types. The easiest thing to do is copy-paste from the Getting Started section of the SDK documentation. If you want to see the full spec, it’s in the Knowledgebase section of the SDK documentation.
Vault Explorer and Job Processor Extensions
The VaultContext class has been removed. Instead your extension will be given a fully working Connection object. Things are much cleaner this way since you don’t have to construct your own WebServiceManager. It also fixes a couple of other issues, such as error 300.
The interface for Vault Explorer extensions has been renamed from IExtension to IExplorerExtension.
Persistent IDs
In the past, there was never a reliable way to reference a File from outside Vault. File names can change, so that’s not good. File ID and MasterId are database keys, so it’s not a good idea to use those. In Vault 2014, we now support persistent IDs, which are guaranteed to never change. The feature applies to Files, Folders, Items, Change Orders, and Custom Entities.
The relevant functions are GetPersistentIds and ResolvePersistentIds in the KnowledgeVaultService.
Leave a Reply