Custom Jobs without Job Processor

If you are building your own custom job, you do not have to plug-in to Job Processor if you don’t want to.  The job queue can be accessed through the Vault web services API, just like with files and folders. 

The recommended approach is to use Job Processor.  That approach is what you see in the SDK documentation and sample apps.  But the Job Processor can’t handle all the cases.  There are some times when you may want to just write your own service.  This article will help you identify those cases and provide some help writing the code.

First let’s talk about what Job Processor does well.  It’s a single application than can handle multiple job types.  It has various job handlers loaded out-of-the box, and additional functionality can be plugged in.  For a Vault admin, this is good because everything can be managed from a single app.  If something goes wrong, there is only one place to look, one log file to check, and so on.  From the developer's point of view, Job Processor offers some nice features.  You don’t have to worry about Vault authentication, managing the job queue and logging.  None of these things are very hard, but it’s nice to have the app take care of them.

On the flip side, Job Processor does have some limitations.  First, it’s not a true Windows service.  A user has to log in, launch the app, and leave it running.  Job Processor handles jobs one at a time.  There is no parallel processing.  And you can only run a single process on a machine.  A common problem is that Job Processor gets bogged down with jobs that take a long time, like DWF generate jobs.  This prevents other types from running even if they take less time to run. 

If you are running in a multi-site environment, Job Processor can only process jobs from one site.  Vault requires that a job can only be handled by the site that queued it.  So if you have 5 sites queuing jobs, you would need 5 Job Processors running.

By communicating directly with the job queue you can bypass these limitations and build exactly the app you want.  Working with the job queue is easy.  You just need to use the following functions from the JobService:

• ReserveNextJob – This grabs a job and reserves it to you so that nobody else works on it.  You pass in the job types you support and Vault passes back the “next” job based on the priority and the time it was queued.
• UpdateJobSuccess – This tells Vault that you are done with the job, and it can be removed from the queue.
• UpdateJobFailure – This tells Vault that something went wrong.  The job stays on the queue in the error state.  You can pass back information on what went wrong.
• UnReserveJobById – This function is used for cases where a job gets reserved but never updated.  For example, maybe the service crashed or there was a power outage. 

If you want an example, have a look a Q-Tools.  It’s a Windows service that can interact with queues from multiple Vault sites.