The third type of event we introduced in Vault 2012 is the Web Service Invoke Events. If you want to read up on the other two types, you can go here and here. The purpose of the Invoke events is to give you a single choke point for whenever your code invokes a web service call to the Vault Server.
Notice that I stressed the word your. This type of event is not for hooking to the existing Vault features. That’s what the Web Service Command Events are for.
The Invoke events just helps you manage your own code. And because it’s limited to you code, there is a lot more you can do with it. For example, you can alter parameters going in and out. With all the other event types, you are just an observer.
So what is this good for? Offhand, I can think of 4 uses:
1. Common Error Handling – I find that I want to handle Exceptions from the Vault Server in the same way most of the time. I don’t want to have the same handler code sprinkled all over my app, so I can just put it all in an event handler.
2. Logging – Let’s say you’re a consultant, and you developed an app for a customer. That app is not working properly, and you have to figure out why. You can’t just run in the debugger on the customer’s machine. So how to you get information on what is happening inside your app? The solution is to sprinkle logging capability throughout your code so that you can get a nice trace from the customer. Using Invoke events you now have a way to log every Vault server call.
3. Debugging – Even during the development process it’s good to have a print out of what is going on between your code and the Vault server. If you code is very complex, it’s very difficult to keep track of which commands result in which API calls. These events can help sort things out for you.
4. Performance – If you app is slow, it’s helpful to know how much time is being used by calls to the Vault server. Based on my past experience, slowness is usually due to redundant API calls or calls that can be optimized.
Coming soon: Sample code....
Subscribe
My Take-away from AU
I was busy at AU last week, which is why there wasn't much activity from me online. I'm not going to repeat AU news that has already been posted elsewhere (PLM, Autodesk 360, etc), that's not what this blog is about. I'll keep things focused on the Vault API and share some things I learned.
Yes, I learn things at AU. Not things about the Vault API, but how people perceive and use the Vault API. The more I understand my users, the better I can distribute information.
I've known for some time that the API consumers fall into two camps, the professional programmers and the non-professional "scripters". Since I'm a professional programmer myself, I'm good at providing information targeted at the first group. The second group is where I rely heavily on feedback.
The Scripter persona
Let me take a crack at describing the Scripter (feel free to let me know if I missed something). This person wants to customize the Vault but doesn't want to spend days learning the entire Vault API. Usually they want to write tools tailored to their own environment. There is a task that they do over and over and they want to automate the process or reduce mouse clicks. The best-case scenario for them is to find a similar tool that they can tailor to their own needs. Having to start from scratch is a big pain and sometimes a show stopper.
Cost of entry is also a big factor. It's very important that a scripter can get something working early on, even if its just a Hello World example. Spending hours figuring out how to get a command to load is not acceptable.
Feedback
Most of the feedback I get from scripters is positive so I'd like to share that with you. I don't get much feedback on things that aren't working, but I do get questions like "Do you have an app that does X?"
The good: SDK Samples
These examples are easy to read and easy for scripters to modify.
How to make it better: More samples in the same style. In other words, samples that illustrate one useful concept in a clear and simple way.
The good: .NET
It's an easy-to-use and powerful programming platform. It's free and supports VB.
How to make it better: Get rid of the "compile" step. This goes back to reducing cost-of-entry. The less steps equals lower cost-of-entry. And, technically, scripting means that the code does not need to be compiled. There are a couple of techniques that can help with this goal, such as PowerShell and run-time compilation. I haven't yet taken a serious look at these techniques, but it's on my agenda.
Posted at 08:09 AM in Commentary | Permalink | Comments (0) | TrackBack (0)