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