Announcements

Starting in December, we will archive content from the community that is 10 years and older. This FAQ provides more information.

Vault 2012 Revision Table Integration

Anonymous

Vault 2012 Revision Table Integration

Anonymous
Not applicable

I was very excited to see this feature (as I'm sure others were as well), but only to be let down by it's functionality.

 

After doing some testing, it seems that the Revision Table on the drawing only gets populated once the drawing goes into a 'Released' state and then use the 'Populate Date from Vault' with a right-click on the Revision Table.  This causes an issue, because the DWF of that drawing will show out of date information thus causing an issue for the Web Client users relying on that up-to-date information by the DWF.

 

Here are my steps as followed (assuming you did the configuration of the Vault Revision Table prior using the guidelines here - http://underthehood-autodesk.typepad.com/blog/2011/04/vault-2012-revision-block-integration.html)

 

  1. Assign your drawing to a category so it's assigned a Lifecycle and Revision Scheme.
  2. Your drawing should be at WIP and your initial Revision 'REL' (I'm using 'REL' for my example).
  3. Release your drawing.
  4. Take it back to WIP, which should trigger a Rev level change, your drawing should now be at Rev A.
  5.  Check out your drawing from Vault, open inside Inventor and place in your Revision Table using Vault Revision.  Your table should show a Rev level of 'A' with none of the other properties being filled out.
  6. You can fill out some of these properties (i.e. Description) and you would think it would populate the Revision Table if you right-click the Revision Table and click "Populate with Vault Data".  Nothing gets populated. It explains the Revision table is already up-to-date.
  7. Now, save and Check In your drawing. (Leave the drawing open in Inventor - this is key to seeing the issue)
  8. Within Vault, take your drawing and put it into a Released state.
  9. Go back to Inventor (DO NOT REFRESH THE BROWSER) and right-click the Revision Table and choose the "Populate with Vault data" option.  It will tell you the file is locked, but you can continue to edit anyways.
  10. Your table will now update the the property information into the Revision Table that it should have prior to Releasing the drawing.

The problem is that if you check the DWF inside Vault, it will display the Rev A row, but no property information.  There is no way to update the DWF with the way the drawing currently looks, because it's in a Released state and you cannot get this back into the Vault.

 

A workaround would be to take this to a Quick-Change state, check out and open the drawing, update the Revision Table, save, check it back in and then take it back to Released.  This will update the Revision Table without bumping the Rev level from taking it out of a Released state. (Not the intended workflow I'm sure)

 

Another thing I tried was to make sure the transition from WIP to RELEASED updated properties and view using the Job Server, but this is more than just a property update that needs to happen.  There is an extra command that needs to be ran to update the Revision Table on the drawing as well which never gets done.

 

Has anyone else experimented with this new feature and found the same thing I have or found a solution around this?

0 Likes
Reply
Accepted solutions (1)
4,054 Views
14 Replies
Replies (14)

Anonymous
Not applicable

Finally, someone else ran into this.  I've been trying to figure out if we were doing something wrong.  Why wouldn't there be an out-of-the-box Job Processor routine that handles the updating of Rev Tables like there is for property synchronization?  As of now, it’s an inefficient process to have to release the file, cycle it to quick change state, update the table, and then re-release it.  Like the previous poster, I hope we missed something and this isn't the actual "as intended" workflow.

0 Likes

alan_ho
Autodesk
Autodesk

Hi mdurst,

 

I assume you do not have the Job Processor services enabled?

The Vault Revision Table works best with the Job Server whereby the data in the Vault Revision Table can be updated upon release via a transition state (sync properties) action.

 

If the above is turned ON, then there will be no requirement for you to re-release your drawing again.

Let me know if this works for you.



Alan Ho
Principal Experience Designer
Digital Platform & Experience
Autodesk, Inc.

alan_ho
Autodesk
Autodesk

Hi CodeMonkey831,

 

Essentially, if you have both the Vault Revision Table and JobServer feature turned ON (and your transition actions set for property synchronization), then your revision table will be updated by the Job Processor every time a property sync takes place.

 

However do note that the Job Processor will not update Vault Revision Table for legacy Inventor drawings by default. To work around this, please visit the following URL for the required setup:

http://wikihelp.autodesk.com/Vault/enu/2012/Help/02._Working_with_Vault/01._Vault_Client/1296AboutRe...



Alan Ho
Principal Experience Designer
Digital Platform & Experience
Autodesk, Inc.

Anonymous
Not applicable

Alan,

Thank you for the reply.  I do have the Job Server enabled and I am logged into the Job Processor.  I set the transition state Work In Progress --> Release to "Synchronize properties and update view using Job Server".  This seems like it would work, HOWEVER the sync properties command fails in the Job Server Queue with an error resulting in the file being locked.

 

You can't sync properties on a file that is in a released state, so how is this supposed to work?

 

Sync Props.jpg

 

 

0 Likes

Andy.Spivey
Community Manager
Community Manager
Accepted solution

You can create a job processor user (with a strict password) and add them to the released lifecycle state to grant them access.  This will also allow you create a DWF file for a released file

 

Reference - http://crackingthevault.typepad.com/crackingthevault/2011/05/file-locked-when-releasing-a-file.html


Andy Spivey
SQA Engineer

Anonymous
Not applicable

Andy,

    Thank you for the reply.  I created another user called "Job Processor" and added this user to have Read, Modify and Delete access on the "Released" state within the Lifecycle Definition.  After doing so, the Job Processor was able to do 3 tasks: Sync Properties, Update the Revision Block and then Update the View (In that order).

 

The DWF is now showing updated information that wasn't being shown at the time the file was released.  Here is the screenshot showing how the date was added to the Revison Table only on the DWF inside the Vault and not inside Inventor at the time it was released.

 

This seems to resolve the issue I was having.  Thank you.  There is a lot riding on the Job Processor at this point, so one would hope that it never fails for these 3 tasks.

 

Security Added.jpg

0 Likes

Anonymous
Not applicable

Such an inuitive and user-friendly workflow to get it working!

Anonymous
Not applicable

Andy,

The Job Processor method is working great as far as updating the Revision Table upon releasing the file.  One question I have is "Why can't Vault update the Revision Table inside Inventor prior to releasing?"  You can see all the properties are up to date inside the Vault and current yet the table is not updated inside Inventor.  There is even a command to "Populate with Vault Data".  It seems that command inside Inventor needs to be reprogrammed to do the same thing as the Job Processor job "autodesk.vault.updaterevisionblock.idw".  

 

Can you answer this for me please or recognize that this is an issue that somebody is looking into?

 

Vault Revision Table.jpg

0 Likes

Anonymous
Not applicable

Andy,

         Another thing I want to note is how the "Revise" command works inside Inventor.

 

In this example:

1. Revision "C" was created by rolling the file through a lifecycle (Released ---> WIP).  

2. The file was then never re-released so the table was never updated because it never got sent to the Job Processor (referring the my post right above this one).  

3. I then used the "Revise" command and it created a Revision "D" and overwrote Revision "C" in the table (as you can see).  

4. I then released the file and Revision "D" updates with properties as expected, but Revision "C" in the table is nowhere to be found.

 

Is there a way to update the table without "Releasing" the file every single time to force it to the Job Processor?  

Is there a manual command I can run inside Vault? - View Update (Queue Update) only updates the DWF, no Property Sync or RevBlock Update.

 

I'm really struggling with this.  Revison Tables have ALWAYS been the biggest challenge with Vault.  The changes made in 2012 are definitely headed in the right direction.  I just wanted to give some honest feedback.  If I don't hear from you, then I'm going to take that as you agree and there isn't anything you can do about this now.

 

Thanks for your time Andy.

 

-Matt

 

Vault Revision Table 1.jpg

0 Likes

alan_ho
Autodesk
Autodesk

Hi mdurst,

 

The Vault Revision Table was intended to display only released revision data.

Therefore in your example, Rev C would not show the Change Description, Engr Approved By and Date simply just because it is still in the Work in Progress state. One of the reasons why this was impletmented in such a way is because these properties may be subjected to changes prior to release.

 

We still allow the display of the Revision C row so our users can tag revision balloons to them or add values (which are not mapped to those in the Vault). But however if Revision C is skipped for release, this row will be deleted in the next Revision Table update as it doesn't fulfil the released criteria. 

 

The command inside Inventor and the Job Processor is essentially doing the same thing with the same rules. The only difference between them is that the Job Processor acts on the file upon a trigger (on the releasing of the file) whereas the command in Inventor performs the update anytime during WIP. You can have Inventor mimick the same behavior for released files if you have sufficient rights to act on released files.



Alan Ho
Principal Experience Designer
Digital Platform & Experience
Autodesk, Inc.
0 Likes

alan_ho
Autodesk
Autodesk

Hi mdurst,

 

There are some pretty stiff rules that the Vault Revision Table is employing:

  • Displaying only released data (which I stated in my previous post).
  • Displaying only the first released revision data (that is if you have multiple revisions of the same letter that are re-released, only the first released version will be retained for display)

Unfortunately, there is no way to override (or relax) these rules as of now.

I hear your feedback and will escalate this to our Product Managers for their review.

 

Meanwhile, hang in there.



Alan Ho
Principal Experience Designer
Digital Platform & Experience
Autodesk, Inc.
0 Likes

Anonymous
Not applicable

The following is our desired workflow, and as of now, I have not been able to configure Vault to properly manage this workflow.  The problem comes during the release state and how Vault populates the revision block on the drawing.

 

To Create New
     1. Create new part file
     2. Design part (sketch, extrude, etc…)
     3. Save the part file
     4. Add the file to vault
          a. Vault assigns the .ipt file to the Engineering Category.
          b. Lifecycle rules and revision rules are then applied to the file
               i. State: Work in Progress
     5. Continue design work (periodically syncing with Vault)
     6. Finalize design
          a. Populate iProperties
          b. Create Drawings (iProperties are brought forward from the part and copied to the drawings iProperties)
     7. Save the drawing file (same name as part file)
     8. Add the drawing to Vault
     9. Release part/drawing for fabrication
          a. Vault automatically populates the revision title block on the drawing
               i. REV column with “–“ to represent initial release*
               ii. APPROVED column with the person’s name that released the drawing
               iii. DATE column with the date it was released
               iv. COMMENT column with default value from drop down list, “INITIAL RELEASE”
          b. .dwf is created

 

To Revise
     1. Change state to “Work in Progress”
     2. Make Change
     3. Change state to “Released”
          a. Vault automatically populates the revision title block on the drawing with a new row
               i. REV column with “A“ to represent new release*
               ii. APPROVED column with the person’s name that released the drawing
               iii. DATE column with the date it was released
               iv. COMMENT column with comments from drop down list or typed at time of release, “REDUCED SLOT TO 3mm”
          b. .dwf is created

 

*Our revision scheme is set up as follows: -, A, B, C, etc…  The reason we use “-“ is because we don’t document in the title block who drew the drawing.  Instead, we automatically track who released the drawing in the revision block.  This name can be used to ask questions about the design because whoever released the drawing would know enough about the design to answer these questions, or able to direct the question to the appropriate person.  The revision block also keeps a history of who released the drawing in what revision.  If you want to know who drafted the drawing, you can search the properties in vault.  We want fabricators to call the person who released the drawing if there are questions, and NOT the drafter.  There is a good chance the drafter wouldn’t have a clue if a tolerance can be modified or if an obround can be modified to fit a standard punch.

 

REV to us means that a design and its respective drawing have been released in a new form, fit or function.  The rev bump occurs at the time of release (instead of Vaults default setup…from released to WIP).  The thought behind this is that we don’t want to demarcate a revision until the changes are made.  Not BEFORE the changes are made as Vault’s default.

 

We are also trying to automate as much as possible, with automatic population of the revision block.  All of the information exists in Vault when a design is released, but for some reason, this information can’t easily be extracted to automatically populate the revision block!

0 Likes

Anonymous
Not applicable

@Andy.Spivey wrote:

You can create a job processor user (with a strict password) and add them to the released lifecycle state to grant them access.  This will also allow you create a DWF file for a released file

 

Reference - http://crackingthevault.typepad.com/crackingthevault/2011/05/file-locked-when-releasing-a-file.html



Doesn't this mean that the Vault Revision Table would show "Job Processor" in the Approved Column?

0 Likes

Anonymous
Not applicable

Just ran the experiment...As Alan mentioned in his rule two above, "Displaying only the first released revision data" will make it so that the Revision Table shows the user that releases the file.  The job server is not recorded here.

 

The job server actually works well...for the most part.  It's slow though...I've decreased the time it takes to look for work to 1 minute (the lowest value I think) by editing a line in the file C:\Program Files\Autodesk\Vault Professional 2012\Explorer\JobProcessor.exe.config to <add key ="PeriodInMinutes" value="1" />

 

The .dwf was updated and reflected the correct rev number, description, date and approver.

 

A potential drawback would be that the Job Server leaves (overwrites your comment) a little note in the vault comments, "Revision table updated by Job Server."

 

Fortunately releases aren't everyday sort of things. 

 

It would be nice if we could also request the job server to create .pdf, .igs, .stp, and so forth.  It would also be nice to have an option to keep the drawing revision and part revision at the same level.  I cant see a time when our drawings would ever be at a different rev state than the part.  In fact, we want all of the information to flow from the part.  The drawing is just a 2-D, paper way of expressing the part!  In my opinion, all information should originate in the part....but I'm getting off topic.

 

There has got to be a better way of doing this that doesn't REQUIRE a job server...considering the job server requires a license to run the job.

0 Likes