Vault Integration Pattern – Real-time Events

Welcome to part 2 of my 3-part series on Vault integration patterns.  There are many more than 3 patterns, but I’m going to stick to ones that I’ve actually used on an app or product. 

Today’s pattern is the idea that Vault communicates with the other system, in real time, whenever things change.  I used this pattern for Vault ♥ Bluestreak.  In that app, I hooked to events from Vault Explorer and Events.  This allowed the app to “listen” to what the user is doing and send out notifications to Bluestreak.  Bluestreak would then post on the notification on it’s Activity Stream, which is similar to a Facebook wall.

Maybe it will be clearer if you see the demo video (no audio):

The general idea here is that the integration app listens to events and interacts with the other system as soon as the event comes in.  Vault doesn’t have server side events, so the app has to be client-side.  In this case, the communication is one way.  I’m sending alerts to Bluestreak, but I don’t need to get any sort of response.  So the code makes heavy use of Post events.  The communication with Bluestreak is done in another thread for performance reasons.

If you have a case where you need to read data from the other system, this pattern still works.  The only difference is that you would be using the GetRestrictions or Pre events.  Multi-threading probably won’t work here since you need to halt the Vault operation while waiting for the other system to respond.

Advantages:

• Operations occur in real time – No need to keep hitting the refresh button, like when working with the Job Processor.
• User Interaction – If you need input from the user, you can do it.  You can also pop up errors immediately if something goes wrong.

Disadvantages:

• Events are not guaranteed – Because the operations are client-side, they occur outside the database transaction.  This means that there is a chance that the event happens, but the Post event never fires.  For example, a file changes lifecycle state, and the power goes out right before the Post event fires.  In this case, the Post even is lost forever.  Along the same lines, a Pre event may fire, but the actual operation my never get a chance to run.  So if you need 100% guarantee on your data, this is not the pattern to use.
• Client side install – If you have 100 Vault users that need to integrate with the other system, you need to install the app on 100 machines.  If an app starts failing for a user, it may not be immediately obvious.