Earlier this week I listened in on a webinar on Vault Data Standard and it got me to thinking. Coming from a Vault API background, I have a different view of Data Standard then what is usually presented. So I’d like to provide my thoughts since this is a blog and all....
APIs on top of APIs
Data Standard provides a lot of features you can get through the API. You can create custom commands, custom UI and make calls to the Vault server. What’s interesting is that Data Standard itself is a Vault Explorer plug-in. So the Data Standard API is basically an API on top of the Vault API.
It’s basically like the movie Inception, but with APIs instead of dreams.
Many pieces of the Data Standard just pass through to the Vault API. Adding custom commands is an example of this. The settings in the DS .mnu files are exactly the same as the properties on CommandItem from the Vault API. In this aspect, knowledge of the Vault API transfers directly over to Data Standard.
Another example is the $vault object that shows up in the .ps1 files. The purpose of the object is for making web service calls to the Vault server. $vault is a WebServiceManager object being passed in directly from the Vault SDK DLLs. If you want to do anything with $vault, you need the Vault API documentation on-hand. Again, if you are already familiar with the Vault API, than this is no problem.
What I’m more curious about is the people without a Vault API background. How well are they able to utilize Data Standard? Does DS ease them into the world of Vault programming, or does the Vault API hit them like an impassable brick wall?
Beyond the API
The stuff that interests me most is the stuff that can’t be done through the Vault API.
First and foremost, the CAD plug-ins are awesome. Data Standard is not just a plug-in to Vault; it plugs into AutoCAD and Inventor as well. That way you can easily create an Inventor dialog that is Vault-aware, for example. Going through the traditional APIs would be a daunting task. You would need to be an expert in both APIs and would have to figure out how to hook the two together. DS solves all that stuff for you in a way that makes it look easy.
Another aspect of DS are the template features. New CAD files can be copied from a template instead of staring from a blank file. DS uses Vault functionality to centralize the storage of the templates. This is less of an example of a generic API and more of an example of a focused solution. Data Standard is really a dual product: It’s an API, and it’s an end-user utility.
The two aspects are not at odds with each other, but I’m not sure if they blend well together either. It feels to me more like a Swiss Army knife. It’s a bunch of seemingly unrelated stuff packaged together. Maybe that’s why it’s a hard product to describe it to people.
One thing like like about compiled programming languages, such as C#, is that you get compile errors when something goes wrong. That way if an API changes, you know right away what broke. PowerShell, however, is a scripting language. So it’s harder to find the breakages. Usually, they show up at runtime and only if specific pieces of code are run.
If you have a lot of PowerShell code in your Data Standard implementation, you may find it hard to maintain. Everything will seem fine at first after an upgrade, but things start failing as people start using the custom functions. Even if you think you have everything updated, a CAD user somewhere may hit lesser-used code that calls an obsolete Vault API function.
Yes, Vault provides compatibility for older versions of the web service API, but in order to use them, you need to have the older SDK objects. If Data Standard is passing in the 2015 version of the WebServiceManager, then you can’t make use of the 2014 server APIs.
There are lots of ways to solve, or minimize these issues when they do come up. For now, Data Standard is new, so nobody has run into migration issues... yet.