It's All Just Ones and Zeros

How to Acquire Files

Downloading and checking-out is so last year.  The fashionable Vault API developer acquires their files.  It has more style and class.  Also, DocumentService.DownloadFile and DocumentService.CheckoutFile are no more in the 2014 API.  So that kind of forces the issue.  Connection.FileManager.AcquireFiles is the replacement.  I’ll go over the architectural reason for the change in a later article.

---

Benefits of AcquireFiles

Yes, it’s a pain to have to update your code, but let me go over the benefits before you get too distraught. 

• Downloads files to the working folder by default.
• Automatically handles large files.
• Automatically repairs broken references for known CAD file types.
• Can download entire assemblies in one call.
• Multi-thread download.  It’s about 2x quicker when downloading an assembly.
• Get/checkout dialog available.
• Automatically sets file attributes, such as read-only and create date.

The only disadvantage that I have come across is that you can’t read a file directly into memory.  You always acquire to a location on disk.  The workaround is to acquire to a temp location, read the file to memory, then delete the temp file.

---

Here is some sample code.

// C# using VDF = Autodesk.DataManagement.Client.Framework;   public void DownlodFiles(ICollection<VDF.Vault.Currency.Entities.FileIteration> fileIters) {     // download individual files to a temp location     VDF.Vault.Settings.AcquireFilesSettings settings =         new VDF.Vault.Settings.AcquireFilesSettings(m_conn);     settings.LocalPath = new VDF.Currency.FolderPathAbsolute(@"c:\temp");     foreach (VDF.Vault.Currency.Entities.FileIteration fileIter in fileIters)     {         settings.AddFileToAcquire(fileIter,             VDF.Vault.Settings.AcquireFilesSettings.AcquisitionOption.Download);     }       VDF.Vault.Results.AcquireFilesResults results = m_conn.FileManager.AcquireFiles(settings); }   public void DownloadAssembly(VDF.Vault.Currency.Entities.FileIteration topLevelAssembly) {     // download the latest version of the assembly to working folders     VDF.Vault.Settings.AcquireFilesSettings settings =         new VDF.Vault.Settings.AcquireFilesSettings(m_conn);     settings.OptionsRelationshipGathering.FileRelationshipSettings.IncludeChildren = true;     settings.OptionsRelationshipGathering.FileRelationshipSettings.RecurseChildren = true;     settings.OptionsRelationshipGathering.FileRelationshipSettings.VersionGatheringOption =         VDF.Vault.Currency.VersionGatheringOption.Latest;     settings.AddFileToAcquire(topLevelAssembly,         VDF.Vault.Settings.AcquireFilesSettings.AcquisitionOption.Download);       VDF.Vault.Results.AcquireFilesResults results =         m_conn.FileManager.AcquireFiles(settings); }   public void DownloadDialog(VDF.Vault.Currency.Entities.FileIteration fileIter,     IntPtr parentWindowHandle) {     // pop up the Get/Checkout dialog     VDF.Vault.Forms.Settings.InteractiveAcquireFileSettings settings =         new VDF.Vault.Forms.Settings.InteractiveAcquireFileSettings(             m_conn, parentWindowHandle, "Download files");     settings.AddEntityToAcquire(fileIter);       VDF.Vault.Forms.Library.AcquireFiles(settings); }

' VB Imports VDF = Autodesk.DataManagement.Client.Framework   Public Sub DownlodFiles(fileIters As ICollection(Of VDF.Vault.Currency.Entities.FileIteration))        ' download individual files to a temp location        Dim settings As New VDF.Vault.Settings.AcquireFilesSettings(m_conn)        settings.LocalPath = New VDF.Currency.FolderPathAbsolute("c:\temp")        For Each fileIter As VDF.Vault.Currency.Entities.FileIteration In fileIters               settings.AddFileToAcquire(fileIter, _ _                VDF.Vault.Settings.AcquireFilesSettings.AcquisitionOption.Download)        Next          Dim results As VDF.Vault.Results.AcquireFilesResults = _            m_conn.FileManager.AcquireFiles(settings) End Sub   Public Sub DownloadAssembly(topLevelAssembly As VDF.Vault.Currency.Entities.FileIteration)        ' download the latest version of the assembly to working folders        Dim settings As New VDF.Vault.Settings.AcquireFilesSettings(m_conn)     settings.OptionsRelationshipGathering.FileRelationshipSettings.IncludeChildren = True     settings.OptionsRelationshipGathering.FileRelationshipSettings.RecurseChildren = True     settings.OptionsRelationshipGathering.FileRelationshipSettings.VersionGatheringOption = _            VDF.Vault.Currency.VersionGatheringOption.Latest        settings.AddFileToAcquire(topLevelAssembly, _            VDF.Vault.Settings.AcquireFilesSettings.AcquisitionOption.Download)          Dim results As VDF.Vault.Results.AcquireFilesResults = _            m_conn.FileManager.AcquireFiles(settings) End Sub   Public Sub DownloadDialog(fileIter As VDF.Vault.Currency.Entities.FileIteration, _     parentWindowHandle As IntPtr)        ' pop up the Get/Checkout dialog        Dim settings As New VDF.Vault.Forms.Settings.InteractiveAcquireFileSettings( _            m_conn, parentWindowHandle, "Download files")        settings.AddEntityToAcquire(fileIter)          VDF.Vault.Forms.Library.AcquireFiles(settings) End Sub

Getting to Know the VDF

The VDF will feel a lot different than the rest of the Vault API.  It’s almost as if it was built by a completely different team.  The reason is because it was built by a completely different team.  There are other reasons too.  Working with UI components is different than working with server calls.  Also, the VDF is able to follow a more object oriented approach than the web service layer.

But I'm getting ahead of myself.  This post is about getting to know the VDF.  No talk of commitment or marriage or anything.  It's just a nice casual tour of the major components.

---

The DLLs

There are 4 DLLs that make up the VDF.  They are the ones that start with Autodesk.DataManagement.

Autodesk.DataManagement.Client.Framework.dll - This contains components that are not Vault-specific and do not contain UI.  Features include logging and error parsing.

Autodesk.DataManagement.Client.Framework.Forms.dll - This contains UI components that are not Vault-specific.  Features include an error dialog and progress dialog.

Autodesk.DataManagement.Client.Framework.Vault.dll - This contains Vault utilities but no UI.  Features include Connection management, download/upload workflows, working folder information, and Entity objects.

Autodesk.DataManagement.Client.Framework.Vault.Forms.dll - This contains Vault UI.  Features include the login dialog, browse control, and checkout dialog.

---

Entry Points

Each DLL has a Library object which contains a set of static methods.  The methods themselves are dependent on the feature set of the DLL.  The other major entry point is the Connection object, which has a set of managers.  Each manager contains methods for invoking high level workflows.  There is some overlap between VDF managers and web service managers.  For example, you can add a category through Connection.CategoryManager.AddCategory or Connection.WebServiceManager.CategoryService.AddCategory.

---

Currency and Services

The VDF has its own set of currency objects.  These are basic objects used only for structured data.  Objects that perform actions are referred to as services (aka. managers).  VDF currency is similar to the Web Service currency, but there is usually more information in the VDF currency.  For example, the VDF’s FileIteration object has object references to the parent Folder and Category object reference.  The web service equivalent, File, has only ID references to parent Folder and Category.

You will frequently have to convert between the VDF and web service currency.  You can construct a VDF object from a web service object.  You can also cast down from VDF to web service object.  So it’s not too bad, but you still have to keep track of the different sets of currency.

---

Settings and Results

The VDF supports many complex workflows, which may have multiple configuration options.  Instead of having functions with 20+ inputs, the VDF uses a settings object instead.  If you want the default behavior, you can just new up a settings object and pass it in to the workflow or UI.  Alter the settings object if you want non-default behavior.

The results of a workflow can be just as complex as the inputs, which is where the results object comes in.  If something goes wrong, don’t assume you will get an exception.  In many cases, you need to check the results object to see if there were failures or not.  Also, when UI is involved, you can’t assume that the user did what they were supposed to do.

Setting File Attributes on Upload

A while back, I wrote an article on the extra steps you need to do on download in order to avoid the “edited out of turn” status .  Unfortunately, I neglected to provide the extra steps you need to do on upload.

When adding or checking in a file from the working folder, you should set the file to read-only.  This makes the file less likely to get updated by accident.  It also insures the correct file status in Vault Explorer. 

You should also set the create date on the local file so that it matches the CreateDate value from the File object returned from Vault.  This part is a bit confusing because File.CreateDate is the datetime that the version was created (aka. the check-in time).  So your file on disk will have a create date larger than the last modified date.

Those are the two basic things to set: read-only and create date.  They are same two steps are used for download.  Here is some example code:

// C# File file = m_svcMgr.DocumentService.AddFile(     folder.Id, filename, comment,     System.IO.File.GetLastWriteTime(localpath),     null, null, FileClassification.None, false, byteArray);   FileAttributes baseAttr = System.IO.File.GetAttributes(localpath); FileAttributes rwAttr = baseAttr & ~FileAttributes.ReadOnly; FileAttributes readOnlyAttr = baseAttr FileAttributes.ReadOnly;   // clear the read-only bit if it is there System.IO.File.SetAttributes(localpath, rwAttr);   // set create time to match Vault System.IO.File.SetCreationTime(localpath, file.CreateDate);   // set the read-only bit System.IO.File.SetAttributes(localpath, readOnlyAttr);

' VB Dim file As File = m_svcMgr.DocumentService.AddFile( _     folder.Id, filename, comment, _     System.IO.File.GetLastWriteTime(localpath), _     Nothing, Nothing, _     FileClassification.None, False, byteArray)   Dim baseAttr As FileAttributes = _     System.IO.File.GetAttributes(localpath) Dim rwAttr As FileAttributes = _     baseAttr And Not FileAttributes.[ReadOnly] Dim readOnlyAttr As FileAttributes = _     baseAttr Or FileAttributes.[ReadOnly]   ' clear the read-only bit if it is there System.IO.File.SetAttributes(localpath, rwAttr)   ' set create time to match Vault System.IO.File.SetCreationTime(localpath, file.CreateDate)   ' set the read-only bit System.IO.File.SetAttributes(localpath, readOnlyAttr)

If you are uploading from a location other than the working folder, you don’t need to worry about these steps.  The Vault status will be empty since it won’t find a match on the local file system.  If you are checking in and keeping the file checked out, you can also ignore these steps. 

Job Processor logins

Job Processor is constantly logging in and out of Vault.  So plugging-in to that app is different than with Vault Explorer, where you assume that the user is mostly staying logged in as a single user.  Job Processor, on the other hand, may have zero, one or two simultaneous log-ins at any given time.

It’s probably best if I just go over Job Processors timeline:

1. Job Processor wakes up.
2. Job Processor logs in to the server, but not to a specific Vault.  This type of log in has limited functionality and does not consume a license.
3. IJobHandler.OnJobProcessorWake is called.
4. Job Processor checks the Job queue.
5. For each job:
   1. Job Processor logs in to a Vault. This part consumes the license.
   2. Job Processor sends the job off to the corresponding handler. (IJobHandler.Execute)
   3. Job Processor logs out of Vault, which frees the license.
6. Job processor logs out of the server.
7. IJobHandler.OnJobProcessorSleep is called.
8. Job processor goes to sleep.
9. Go back to step 1 after X number of minutes.

---

So yes, at times Job Processor is logged in twice.  Although the same username and password are used, the contexts are different.  For all intents and purposes, they are completely separate log-ins.  Each job gets its own log-in, so your Execute handler should not be remembering anything about the context.  If your plug-in wants to do any useful Vault operations during the Wake or Sleep events, it will have to have its own set of credentials (see Watch Folder 2013).

Here are some other random facts:

• You can query the job queue without being logged into a specific Vault.  However, adding a job to the queue requires you to be logged in to a Vault.
• Speaking of Watch Folder, I hooked it up to our internal Vault at Autodesk.  Every day I get a report of what’s going on in the Vault, and it’s been running solid for the past 8 months.
• IExplorerUtil had a bug that was caused by it remembering the login context.  If you are using IExplorerUtil tool inside Job Processer 2013, make sure to grab the hotfix.
  Note: The hotfix has been rolled up into Service Pack 1.

Generating File Names

The Vault API is sometimes redundant, and it can also repeat itself.  One place were this is painfully obvious is with file name generation.  If you want to generate a file name, there are two completely separate mechanisms to choose from.  Each has its own set of API functions with their own sets of pros and cons.  You have to choose which is best for your needs.  There is no one mechanism to rule them all.

To make matters worse, they have similar names.  Once engine is for file naming schemes and the other is for file numbering schemes.  If you are not paying attention, you may mistake one word for the other.  It’s annoying, I know.  It’s like reading a three volume fantasy epic where one villain is called Sauron and the other is called Saruman.

---

File Naming Schemes:

This is a pretty basic mechanism, so it's good if you want something quick and simple.  It consists of an auto-increment number with a string prefix and suffix.  I believe that Copy Design uses this feature.

One nice feature is that you can “rollback” a name if you decide not to use it.   For example, the user hits Cancel on your dialog. 

Functions for generating names:

• GetAllFileNamingSchemes
• ReserveFileNamingDescriptions
• RollbackFileNamingDescriptions

Admin functions:

• AddFileNamingScheme
• DeleteFileNamingScheme
• SetDefaultFileNamingScheme
• UpdateFileNamingScheme

---

File Numbering Schemes:

This is much more complex.  You chain together different field types to create your naming pattern.  It’s more powerful, but it’s also more difficult to work with.  Items and Change Orders use this engine too. 

Unfortunately, there is no way to “rollback” a number.  Once it’s generated, it’s reserved forever.

Functions for generating names:

• GenerateFileNumber
• GenerateFileNumbers
• GetNumberingSchemesByType

Admin functions:

• ActivateNumberingSchemes
• DeactivateNumberingSchemes
• DeleteNumberingScheme
• DeleteNumberingSchemeUnconditional
• SetDefaultNumberingScheme
• UpdateNumberingScheme

Here are some screenshots from Vault Explorer that illustrate how fields are hooked together to form the numbering scheme.

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.

Caching

If you’ve looked at any of the source code for my apps, first, let me apologize.  I went for quantity over quality on those apps.  So I didn’t structure the code for people not named Doug Redmond.  Even if you are a professional programmer, I’m guessing you don’t want to spend hours of your time deciphering a bunch of uncommented C#.  It’s probably best if I explain some techniques in the more human-readable blog format.

For this article, I’d like to talk about a caching technique that I’ve found useful in some of my apps.  Caching is pretty much a necessity when working with Vault.  You are constantly running into cases where you have an ID and you need to look up the object.  For things like Categories, Property Definitions and Lifecycle States the objects are unlikely to change.  So the optimial thing to do is store them in memory to reduce the number of API calls.

I like to call my cache Cache.  It contains two main things: The WebServiceManager and collections of cached Vault data.

For the collections of cached data, I usually use lazy initialization.  That way I don’t look up something if I don’t have to.  The first request for the data triggers the API call.  Any further requests for the data use the cache.

The data structure I use depends on how I want to use it.  Just because Vault returns an array doesn’t mean I have to store it that way in the cache.  Frequently I’ll store it as a dictionary using the ID or system name as the key.  The ToDictionary feature in LINQ is a nice little trick.

Example code from DECO:

public class Cache {     private Lazy<Dictionary<string, CustEntDef>> m_custEntDefsBySysName;     public Dictionary<string, CustEntDef> CustEntDefsBySysName     {         get { return m_custEntDefsBySysName.Value; }     }             public Cache(WebServiceManager mgr)     {         m_custEntDefsBySysName =            new Lazy<Dictionary<string, CustEntDef>>(GetCustEntDef_SysName_Map);     }       private Dictionary<string, CustEntDef> GetCustEntDef_SysName_Map()     {         Dictionary<string, CustEntDef> retVal = null;         CustEntDef[] defs = Mgr.CustomEntityService.GetAllCustomEntityDefinitions();           retVal = defs.ToDictionary(n => n.Name);         return retVal;     } }

My Cache object also contains a WebServiceManager.  First, the lazy initializers need to run API commands.  Second, I find it easier to manage.  If the manager and the cache were two separate things, that’s two things I have pass around all the time and keep track of in the code.  By putting the manager in the cache, I only have one object to track.  The objects work well together too.  For example, if you ever need to dispose your WebServiceManager, you will probably want to clear out your cache too.

There are some other cases where you will want to clear your cache.  Mainly, if the data you are caching gets updated.  In my Effective Permissions app, I cache all the all the user and group information.  But it’s reasonable that an admin might run Effective Permissions, update the user and group settings, then run Effective Permissions again.  So I need to clear my cache, but the Vault API doesn’t give me a way to know that users or groups were updated. 

My solution was to clear the cache whenever the Global Settings command is invoked.  Even though I don’t know for sure that anything changed, I clear the cache anyway, just to be safe.  This technique isn’t 100%.  It’s possible that another custom command updated the data, or another admin updated the data from their Vault client.  In the case of Effective Permissions, I didn't feel a 100% solution was needed.

Asking for Help - Do’s and Don’ts

Although my official job title is “Software Engineer,” my API knowledge makes me an honorary member of the tech support team.  More often than not, I read a problem and don’t have enough information to answer it properly.  This requires me to respond asking for more formation.  Usually one or two more back-and-forth sessions are needed before the question is finally answered.  This process is a wasteful, especially when different time zones are involved.  If you figure that each back-and-forth takes 24 hours, there is a definite benefit to reducing these round-trips.

So here is a list of things you can do to make the process more efficient.  The goal is to provide all the needed information upfront so that I don’t have to go back and ask you to elaborate in more detail.

---

DO... include the Vault product and version
Is it Vault Basic?  Vault Professional?  Is is the 2013 version?  Each product has a different feature set and the API may change between release years.

DON’T... use the phrase “It doesn’t work”
That statement is way too vague.  You need to be more specific like “it crashes the program” or “it locks up and I have to restart the app” or “it times out” or “it returns error 303”

DO... include the error code
If the server returns an error, don’t just say “the server throws an error”.  Tell me what the error code is.  Don’t leave me in suspense.  I even have some code snippets you can use to extract the error and restriction codes (if any).

DON’T... provide too much source code
Sometimes people will post their entire project and expect me to debug it.  That’s not a good use of anybody’s time.  If you are going to include source code, it should be isolated to a single function at most.

DO... isolate the line of code that fails
If you are sending a block of code and are getting Exceptions, you need to indicate clearly which line is causing the breakage.

DO... take screenshots
It’s amazing how much information is conveyed in a screenshot.  Even if the Vault is in a different language, I can usually figure out what is going on based on the icons and dialogs.  Videos are great too.  If you find yourself taking 4 or more screenshots, it may be easier to just record a video.

DO... use Exception.ToString()
ToString is the best thing to happen to debugging since the print statement.  Don’t be afraid to use it and include the full stack trace in your problem report.  Even if you don’t understand it all, it may make sense to me since I have access to the Vault source code.

vLogic to the Rescue - Assign Category per Folder

I created vLogic to be a useful tool in a variety of situations.  It allows for customization without the overhead of a full-blown .NET DLL.  A lot of people think vLogic is a good idea, but I’m not aware of it being use in any real capacity.  As we all know, there is sometimes a big gap between “good idea” and “useful”.  So I though I would spend a few posts taking a crack at some real-word problems using vLogic.

This week’s post will be addressing an entry on the Vault Idea Exchange.  A user wants to “Have a category automatically assigned to a document, based on the folder it is 'imported' to.  This would work only when there is a new document, or not another category, assigned to the document.”

Yes, I think I can do that with vLogic.

---

Requirements: 
Vault Workgroup/Collaboration/Professional 2013 and vLogic 2013

Steps: 

1. Install vLogic if not installed already.
2. Download the AddFilePost.SetToParentCategory.ps1 script and put it in the vLogic’s “Event Scripts” folder.  The folder can be found at %ProgramData%\Autodesk\Vault 2013\Extensions\vLogic\Event Scripts with Windows Explorer.
3. If “Base” is not your default file category, open up the .ps1 script and edit the value for $BaseCategory.
4. Start or restart Vault Explorer.
5. Set up File and Folder categories with matching names for cases where you want the script to run.  This step is needed because categories can’t be shared across Files and Folders.
6. Set a folder category and add a file to it through Vault Explorer.  If the file goes into the default category, the vLogic script will assign it to the file category with the same name as the folder’s category.

Notes:

• The script only works for files added through Vault Explorer.
• This script can only run on clients with vLogic and the .ps1 file.  Project Thunderdome can be used to deploy them both to multiple clients.

---

Source code:

Here is the source code.  As you can see, there is not a lot of code needed here.

# This script updates new files not assigned a category are updated to match the category on the parent folder. # A manual refresh is needed to see the category change.   # Set this value to the display name of the "default" file category $BaseCategory = "Base"    if ($e.Status -eq [Autodesk.Connectivity.WebServices.EventStatus]::SUCCESS -and     $e.ReturnValue.Cat -and     $e.ReturnValue.Cat.CatName -eq $BaseCategory) {    $parentFolder = $serviceManager.DocumentService.GetFolderById($e.FolderId)    if ($parentFolder.Cat)    {       $fileCats = $serviceManager.CategoryService.GetCategoriesByEntityClassId("FILE", $true)       $fileCatId = $fileCats |             Where-Object {$_.Name -eq $parentFolder.Cat.CatName} |             Select-Object -ExpandProperty Id             if ($fileCatId)       {         $temp = $serviceManager.DocumentServiceExtensions.UpdateFileCategories(@($e.ReturnValue.MasterId), @($fileCatId),           "Setting category to match parent folder")       }    } }

Job Processor Command Line Tricks

We are working on multiple fronts to address many of the Job Processor issues that people are running into.  For this post, I want to point out some command line features we added to Vault 2013.  This feature won’t fix all problems, but it has many uses.

You can read about the command line options from the SDK documentation or the wiki.  The idea behind these commands is to make JobProcessor behave more like a service.  You can now programmatically start, pause, resume, and gracefully shutdown.  Previously, start and kill were the only things you could do from a command line.

Here are a couple of uses I came up with for these new command line operations.  Feel free to post your ideas too in the comments section.

 

Make use of idle computers

When the CAD engineers go home for the night, use the idle computers to run Job Processor.  Create a Windows task that starts up Job Processor at 8 PM and shuts it down at 5 AM, for example.  If every CAD station does that every night, it should clear out any backups on the job queue.

 

Run certain jobs at certain times

Maybe you would rather not process DWF files during the daytime.  You can set things up so that DWF files only get processed at night.  The first step is to copy JobProcessor.exe.config.  Next edit the copy in an XML editor and comment out all the <jobHandler> elemets where the class attribute starts with “Autodesk.Vault.DWF.Create”.  This config will will be the one you use when you don’t want to handle DWF files.

Set up a Windows task that runs at 5 AM.  The task will shut down Job Processor, swap in the non-DWF config file, then re-start Job Processor.  Because the DWF <JobHandler> tags are commented out, it will not process DWF files.  Set up another task at 8 PM to shut down Job Processor, swap in the original config file, then re-start.

Here is an example BAT file for the 8 AM task.

cd C:\Program Files\Autodesk\Vault Professional 2013\Explorer REM Send the stop command to Job Processor JobProcessor /stop REM Wait for Job Processor to exit :RunCheck tasklist /FI "IMAGENAME eq JobProcessor.exe" 2>NUL | find /I /N "JobProcessor.exe">NUL if "%ERRORLEVEL%"=="0" goto RunCheck REM swap in the non-DWF config file xcopy JobProcessor.exe.noDwf.config JobProcessor.exe.config /Y REM restart job processor start JobProcessor REM Job Processor should be running now and should be ignoring DWF jobs