It's All Just Ones and Zeros

An Introvert’s Guide to AU

I’m pretty much what you expect from a professional programmer.  I have all 7 seasons of Star Trek: TNG on DVD.  I play computer games long into the night.  And when it comes to people, my official policy is “no thanks”.  I can write code for 8 hours solid without any problems.  But put me in a group of people and ask me to mingle, and I’m burnt out within an hour.

In a few weeks, I’ll be going to my 5th Autodesk University conference.  Here are some of the techniques I’ve picked up over the years to cope.  Don’t get me wrong, I love AU.  I just don’t ease through the conference like my extrovert co-workers.

---

Be a Wallflower
If you are a regular attendee, you can quietly slip into the background.  Attend the classes you care about, visit the exhibit hall, watch a few sales pitches, and you’re done.  Despite the crowds of people, you can remain fairly anonymous.  The only thing is to make sure that you don’t miss out on anything important.  If you have a question about something, make sure to hunt down the right people and get the answers you need.

For my first AU, I was able to mostly get away with this technique, but those days are over.  This year I’m presenting two lectures, co-presenting one lecture, presenting at ADN DevDays, providing support for ADN DevLab, and manning both the Vault and PLM 360 booths.  Also there are about a dozen contacts, inside and outside of Autodesk, that I need to hook up with while I’m there.  There is no way for me to slip into the background.  So, I’ve had to come up with some new techniques.

---

Alcohol
Just about every AU event has a generous supply of alcohol.  I find that one or two beers really takes the edge off.  Of course, you must know and respect your limits.  There is nothing more pathetic than getting bombed and making a fool of yourself at a software convention. 

I have to represent Autodesk, so my limit is pretty low.  I also make sure to balance things out with food, of which there is also a generous supply at AU.  Remember, this is a marathon.  Pacing is everything.

---

Tablets and Smartphones
For us introverts, mobile devices are probably the best inventions of all time.  If you are at a table full of people, you can just pull out your phone and start playing away.  You are not being rude; you are working!  Also, about half the people at the table will also be busy on devices too, so you won’t even look out of place.  These devices are turning everyone into introverts.  I guess we really will be inheriting the Earth.

---

Get Enough Sleep and Food
Social situations are exhausting enough, you don’t need to make it worse by being hungry or tired.  The goal here is to make everything as confortable as possible to counter-balance any social discomfort.  If I know I’m in for a busy day, I usually pay for the full breakfast at the hotel restaurant instead of the free conference breakfast.  It’s worth the money to insure that I can perform better.

Advanced Advanced Find 2013

Update:  Click here for the 2014 version

Moving down the list of apps to update, Advanced Advanced Find is up next.  I’m a bit surprised.  The app really doesn’t do much despite the name.  I intended it more as a code sample.  But if you guys want it, you got it.  Here is the 2013 version of Advanced Advanced Find.

If you are not familiar with the app, it’s a simplified version of the Advanced Find feature, but it allows for OR style searches.  The Must rule is the default AND behavior.  The May rule gives you new OR style behavior.

Again, I didn’t have much time to add features.  There is now support for Folder and Custom Object searches, but that’s it.

Requirements:
Vault Workgroup/Collaboration/Professional 2013

Click here to download the application
Click here to download the source code

Click here for the 2011 version.  Sorry, there is no 2012 version.

As with all the sample apps on this site, the legal disclaimer applies.

More on Hacking

I indicated very clearly that my last post was a hack.  I want to take a bit of time to explain exactly why it was a hack.  I’ll also point out things that were not a hack.

 

Assuming I could properly emulate Job Processor
Verdict:  Hack
In theory, the hosting app and the plug-in are decoupled.  But the reality is that they often are not.  Unless an API provides specific support for this decoupling, you should assume a tight coupling.  The Vault API makes no claims that you can load and run Job Handlers outside the context of Job Processor.

Using JobProcessor.exe.config to figure out the DLL and class for DWF creation
Verdict: Not a hack
If you’ve implemented a custom Job handler, you know that you have to edit JobProcessor.exe.config and add your own <jobHandler>.  So the <jobHandler> syntax is spelled out right in the API documentation.

Figuring out the parameters on Autodesk.Vault.DWF.Create.ipt
Verdict:  Hack
Just because one job showed a single parameter, FileVersionId, doesn’t mean that all jobs of that type have the same single parameter.  There may be optional parameters not shown.  There may also be cases where certain files require additional parameters.  Again, there is no way of knowing what those cases are.  Without any official documentation, the best one can do is guess.

My Fake Job Processor

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.

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