Storing Custom Data: Let Jobserver Handle It

Welcome back to my Storing Custom Data series, where I go into the various ways you can store custom data needed by your Vault customization.  Last time I talked about using the Vault Options concept to store your data. 

Job Server:
In this article, I'll be focusing on the Job Processor API, which allows you to hook to the Jobserver feature.  If you are writing a custom job handler, you might want it to remember some settings.  Although Vault Options can be used, I want to explore something that doesn't involve additional Vault API calls.

It's possible to have the job handler store all the data itself, with a local settings file for example.  The theory is that the job handler "owns" the data.  Any edits to the data, must go through the custom job handler.  From the client's point of view, the data maintenance tasks are a black box.  Any outside changes to this data would have do be done through a custom job.

Example:
Watch Folder has an example of this technique.  Most of the work in that utility is done by a custom job handler.  That handler also keeps track of which users are watching which folders.

When a user says that they want to watch a folder, it causes a job to be queued.  The job informs the handler of the update to the watch settings.  The handler reads this job and updates the settings accordingly.  In this case, the settings are in an XML file local to the handler.

When a job comes in telling the handler to scan for new files and send out emails, it does a re-read the settings file.

HandlerClass.cs in the WatchFolderJobHandler project has the sample code.  WatchCollection.xml is the file that remembers the folders being watched for each user.  "Autodesk.WatchFolder.SettingJob" is the job type that tells the hander to update the settings.  "Autodesk.WatchFolder.NotificationJob" is the job type that tells the handler to scan for new files and send out the emails.

Analysis:
This technique is probably more trouble than it's worth, but it's still worth looking into.  It's up to you to decide if this technique is best for your requirements.

Let's list out all the issues:

• No easy way for a client to see the settings.  Because the job handler owns the settings, the only way to see them is talk to the job handler.  And the only way to talk to a job handler is to queue up a job.  Once the handler gets the job, some sort of mechanism needs to be developed for the job handler to pass the data back to the client (for example, an email).  Best case scenario is a few minute delay between the request and the results.
• Multiple handlers may be on the network at a given time.  This can result in a fragmented data set.  One way to solve this would be to put the settings in a file on a network share.  The handlers would need to handle things gracefully if they both try to write to the file at the same time.
  Another option is to require only one handler on the network at a time.  But there is no framework in place to enforce this configuration.
• Connected workgroups add problems too.  Each workgroup has its own queue, which does not get replicated to the other workgroups.  So again, it's possible to have fragmented data.  This might be OK as long as users stick to a single workgroup.  Another workaround is for the user to log-in to the workgroup with the job handler running to do the one or two things needed for that operation.  Then they can log-out and go back to their local workgroup.
• From a permissions standpoint, the user needs to be at least Document Editor (Level 1) to be able to add jobs to the queue.