This article is such a hack that I created a new category to mark the occasion. It goes without saying (but I’m going to say it anyway) that Autodesk isn’t going to provide support for what I’m about to say.
In talking with people about various Vault customizations, I find that sometimes it would be useful to get at functionality provided by a job handler. For example, you want to create a DWF. Theoretically, it should be possible to call directly into the DWF create job handler, so I decided to play around a bit and see if I could get it working for real.
Before I go into the details, let’s get abstract. Plug-in architectures usually follow the same pattern. There is the the hosting app, the plug-in and an interface connecting the two. Each side is not supposed to care about what’s on the other side of the interface.
My test app takes advantage of that abstraction. The DWF handler, for example shouldn’t care if it’s running inside Job Processor or not. The handler just processes jobs. So all I need to do is pretend to be the job processor. I load the handler, create the DWF create job, pass it to the handler, and get a DWF file as a result…. in theory.
My test app
The first step is to figure out which DLL to load. Looking at JobProcessor.exe.config, I see a bunch of <jobHandler> elements, which tell me which job types are handled by which classes. For this example, I decided to create DWF files. The .config file tells me that they are all handled by the class “Connectivity.Explorer.JobHandlerDwfPublish.InventorDwfJobHandler” in the assembly “Connectivity.Explorer.JobHandlerDwfPublish”. So let’s load Connectivity.Explorer.JobHandlerDwfPublish.dll using the System.Reflection libraries.
|
// load the assembly Assembly assembly = Assembly.LoadFile( System.IO.Path.Combine(EXPLORER_FOLDER, "Connectivity.Explorer.JobHandlerDwfPublish.dll"));
// create a new handler object IJobHandler handler = assembly.CreateInstance( "Connectivity.Explorer.JobHandlerDwfPublish.InventorDwfJobHandler", true, BindingFlags.CreateInstance, null, null, null, null) as IJobHandler; |
Now I have the IJobHandler object, I need to pass in an IJob (which tells the handler which operation to run on which file) and an IJobProcessorServices (which provides context information). The IJobProcessorServices class was pretty easy to implement just by looking at the interface. For the IJob implementation, I needed to figure out what the parameter list was. I found this out by queuing up a DWF job from the Vault client. Then I used the API to see what the parameters were on the job.
|
// create the context IJobProcessorServices context = new JobContext( vaultName, mgr.SecurityService.SecurityHeader.UserId, mgr.SecurityService.SecurityHeader.Ticket, uri);
// create the job IJob job = new DwfJob(vaultName, partFile.Id);
// run the job handler.Execute(context, job); |
Click here to download the entire project
Results
So did the app actually work? Yes and no. At first, my app was a stand-alone EXE. The app would always fail when running the Execute command. Remember how, in theory, the handler shouldn’t care about the hosting app? That’s not true for the DWF handler. It definitely cares about the app context and refuses to run if the environment hasn’t been initialized properly.
My next attempt was to run it as a custom Vault Explorer command. The idea is that Vault Explorer will perform whatever operation is needed to make the job handler happy. My command actually worked. There is brief dialog that pops up and disappears during the Execute. But otherwise, it runs as expected.
I have no idea if SyncProperties or UpdateRevisionBlock handlers will work with this hack.
Leave a Reply to cadfish1Cancel reply