Hello fellow Vault enthusiasts! I’ve been doing some spring cleaning here (yeah, I know it's not spring yet), and ran across some of the docs that I’ve used in my travels for Vault implementations. I’ll be posting these from time to time, and the first one helps capture Categories/Behaviors for files in Vault. Hope these are of some use. Let me know what y’all think…
Download Worksheet for Planning Behaviors-web
-Brian Schanen
Here’s a Vault Fun Fact based off a recent customer discussion about Vault Workgroup/Collaboration/Professional and Categories. The process of assigning files upon Check In to Vault to a specific Category can be achieved multiple ways. Typically a property in the file triggers a Category rule, and upon check in to Vault that file is categorized properly, Revisions are set, Lifecycle State is established, and life is good.
Another option to consider is leveraging the automatic file naming in Vault Workgroup to drive this categorization. If for instance, you had an auto naming scheme with a drop down list, and that list contained characters, you can leverage this in the Category rules. First, start with defining the naming scheme.
Then, under Tools>Administration>Vault Settings>Behaviors tab, create a Category rule that triggers off of characters in the file name, derived from the automatic file name generator.
-Brian Schanen
Catchy title, eh? Or confusing. This is essentially a collective follow up to this post and video tutorial on identifying and categorizing Inventor’s Content Center components. Why? It all has to do with setting these file to a happily Released state upon check in to Vault. For most of you this worked out based on feedback. On the other hand, many noted that while this works great for nuts and bolts, there were files that triggered the ‘Is CC Part’ property flag and became released and locked – but they were not really supposed to. These are the Tube & Pipe parts, the Frame Generator parts. These in theory should not jump into a Released state, they are part of the project and may need additional tweaking. Let’s take a look at how we can have the best of both worlds with Vault, and identify these not-quite-standard Content Center components.
First, reflect on how we triggered the other CC parts. There is a dormant property in all parts that are born out of the Content Center called Is Content. We took steps to identify this and we need to take another step for Tube & Pipe, Frame Gen, etc. So, we’ll again use Properties that are in all of those files. Take a look below at images of Custom iProperties in those individual .ipt files. First, the G_L iProp from Frame Generator:
Next, the Overall Pipe Length “OPL” iProp from a pipe run:
Then the ‘PL’ iProperty from Tube & Pipe:
So, now that we have target properties, the next step is to log into Vault as an Administrator. Go to Tools>Administration>Vault Settings>Behaviors tab. Click Properties and create a new User Defined Property. Call this ‘Channel Length’ and associate it to all file categories.
Now, click the Mapping tab. Click to add a new mapping, and either select files in or outside Vault that posses these custom iProperties mentioned above. In the example below, I mapped my User Defined Property (UDP) ‘Channel Length’ to G_L, OPL, and PL to pick up on the values contained in those files, This will ultimately populate into Vault, and we can search or report on them later. For now however, all we need it to expose a value in that property for the Category Rule to trigger off of.
Next, create a new Category (optional) for these Custom Standard parts. Like all Categories, you have the ability to assign behaviors. I suggest no implied Rev scheme, and a Lifecycle Definition that does not default to Released.
Now for the final step. Go to the Category Rules area under the Behaviors tab and modify the existing Content Center rule. Add the Channel Length, condition Is Empty. then make a copy of this, place it below, and call it Custom Content Center, and change the Channel Length to Is Not Empty. Still with me? We’re trying to trigger off whether there is a value or not from the Inventor Content Center part custom iProperty. If there is one, its a custom cc part, if its empty, its get the CC Category.
-Brian Schanen
Today we’ll discuss a significant feature for those who count themselves Vault Administrators. I have always recommended having a “Test Vault” for sampling new functionality, training, testing the waters, etc. This means you can validate new workflows by using house money, so to speak. Then you can save all of your hard work out and import it into a new Vault, and move forward with the implementation, hitting the ground running. With the release of Vault Family 2010 (except base Vault) we had this functionality. Recall this earlier post for review.
The 2011 Vault Family has some enhancements to this wonderful feature, and this is the focus of this post. First, let’s examine the information captured in the configuration file (.cfg):
To export a configuration from one Vault to another, log in to the ADMS (Autodesk Data Management Server) console. Choose the specific Vault database and right click. Choose Export configuration and save this to disk. Hint: save this to a public location, fir instance C:\Users\Public\Documents.
Now, to leverage this on the same ADMS in another Vault, you can right click another Vault and select Import Configuration. Or, you may create a new Vault and during the process, use a custom configuration file. see image below:
Only objects not already existing in the target Vault are imported. Existing object with same name will not be imported or modified. No Users or Groups set in the Life Cycle Definitions security for the states and the transitions will be imported, but will have to be defined BEFORE import. If you are keeping this on the same ADMS, this is not an issue. But what if you are targeting this cfg onto another server/ADMS?
As mentioned, what is not stored in the configuration is Users and Groups – which of course are important in connection to Life Cycle Definition , where the permission are a great part of the setup. But this can be accomplished any way by planning a little ahead and using generic user and group names, which after the import are renamed and added with more users.
First if all – if you are going to export/import configurations remember to start by creating a COPY of the standard setup element be it a Life cycle definition of a revision scheme. The reason is during a import to a new Vault, the ADMS will always first import the custom settings and THEN run a stored procedure to recreate the standard elements – which means all customization will be over written unless named differently.
The Process of creating a Generic setup is:
Start by creating a number of Generic Groups (and the corresponding users needed to create a group) like indicated below:
|
Groups: Generic names indicating Engineer, Manager, Sales and Production in example below. Add the correct roles on Group level |
Users: These user names are the same profiles as for groups, and are just needed as placeholders to be able to create Group |
|
|
|
Best practice is to use Groups when assigning permission and security to Lifecycle Schemes, and to apply user roles on a group level rather than on a user level.
Now develop the Configuration and save it out in a .cfg file in ADMS. Also make a Backup as . cfg files cannot be migrated to a new release. Instead you migrate the Backup and then save a new .cfg file from the next release.
When preparing a new Vault, start by creating it in ADMS Console, add the Users and the Groups with EXACTLY the same names as you used when exporting the .cfg in the first place.
Then use Import Configuration, and you should have a empty Vault with all the above settings preset, and the last step is to rename the Groups to relevant names, and to add users to the group.
This also work for imported Active Directory users and groups, and you just include the AD group into the relevant Vault Group, without further need for changes.
-Brian Schanen
This is one topic that I’ve been asked about many time, and perhaps it’s time for a deep dive into it. What you’re about to see is for Vault Family 2011 and does not apply to Vault Family 2010 products. There was a change in the Vault Properties engine and let’s just say its better, more flexible, in 2011 but there is an additional step to take over the 2010 release. In short, we’ll need to make a User Defined Property (a.k.a UDP) to expose the Rev from CAD, and then making Vault’s revision equal that rev from the file.
So, how do you know when you need to do this? If you’ve been using AutoCAD or Inventor and you have properties in the files already that hold a Revision value, and you check it into Vault, you may see the error in the image below:
Let’s talk about why this is happening. It’s usually after categorizing files upon check in to Vault. This typically assigns a Lifecycle Definition, therefore a Lifecycle State. And it also assigns a Revision Scheme, and that Revision scheme – whether Alphabetical or Numeric – has a starting value. Chances are, if you’ve been using an “honor system” Rev method outside of Vault, the files might not always be at this start value like ‘A’ or ‘1’. They may look like the screen cap below, which is a view of an Inventor assembly in which components have a variety of Rev level.
You have a few options. One of which is to accept Vault’s starting revision of A or 1 and overwrite what’s in the CAD file upon the next synchronization of properties. If that’s alright, stop reading here. If preserving the CAD rev level is important, read on…
First, log in with an Administrative account. Go to Tools>Administration>Vault Settings>Behaviors tab and click the Properties button. Create a new User Defined Property, I suggest ‘CAD Rev’ to make this neutral and possibly mapped to Inventor, AutoCAD, etc. Make it Text type and apply it to all Categories.
Jump over to the Mapping tab. Add a mapping, select the property drop down and import properties from Vault as below.
In my example, I am selecting an Inventor file, but an AutoCAD file with attributed title blocks or even fields, custom properties would work the same.
Now, this mapping is a one-way street. All we need to do is get the CAD file revision exposed so we can fast track Vault’s rev level to it. It’s important to note that Vault will take over Revision Management after that point.
Click OK and close all dialog boxes, return to Vault Explorer. Back to the first image in this post, we had a non-compliant equivalence state, that red bang symbol that’s really hard to ignore is there in the Properties grid. You can target files one-at-a-time, or you can use a clever little search trick to isolate these files.
Start a search using the Advanced tab. First criteria is the noncompliant equivalence, and add to that another criteria where your CAD Rev property is greater than the rev level of you rev scheme. In my example and image below, any noncompliant prop and CAD Rev greater than A (using an Alpha scheme) yields the files listed below. If a Numeric scheme, use greater than 1, and so on.
Ok, getting to the good part. Select a file and click the Revise button. At the bottom of the list is an option to Revise from user defined properties.
Add the new CAD Rev property from the left to right side and click OK.
The rev value from the CAD files will appear as the new Revision values. Anything that will change will appear as bold. Click OK, and your done with this set.
Finally, you can expose the CAD Rev column in any window in Vault, and I suggest this for Admin usage only. Eventually, you can turn this CAD Rev column off once all file rev levels are matched up with Vault. Remember that Vault will take over Revision Management from this point forward.
-Brian Schanen
Last post we looked at one optional workflow with Autodesk Inventor iParts – generating all members before hand and pre-populating your Vault. The advantage here is knowing that the files are created correctly, checked into Vault, and released. This also allows users to choose directly from the created members for placement in an assembly.
Now, there is a limit to this workflow and a point where you would not want to create one-of-each member for a particular Factory. This will differ from company to company and you’ll need to decide for yourself where you draw that line. In my next example, I have an iPart Factory that has hundreds of members, certainly we do not want to take the time nor bloat the Vault with all of those members.
Before we begin, let’s review one of my favorite tips for working with Inventor and Vault: Saved Search folders. See the image below. in the Advanced tab on the Find dialog, run a search for Property Classification is Configuration Factory. (Recall this is the Categorization Rule from a previous post?). From this dialog box, go to File>Save Search and save this down with a descriptive name and a check box to create a folder.
Next it’s time to launch Inventor and open an Assembly file. Use the Place from Vault button from the Assemble or the Vault ribbon.
Here’s where you’ll be able to leverage that Saved Search folder created earlier in Vault. Click the drop down carrot next to My Shortcuts and choose My Saved Searches.
This will provide you a list of all available Factories in Vault. Select one and click Open.
The next steps include:
So, at this point those iPart members are in your workspace, but not Vaulted yet. Check in the top level Assembly and note the check in dialog. The new member is listed. Once checked in, this will be categorized and released as in previous examples in other posts.
This concludes the majority of set up and usage of standard iParts with Inventor and the Document Management functionality within Vault Workgroup, Collaboration, and Professional. Watch for additional posts on custom iParts and iAssemblies, as well as discussions about use of Content Center with Vault. Enjoy!
-Brian Schanen
If you’ve been following the odyssey of Vault and iPart posts on Lifecycles and Revisions, this next section is critical in automating the behaviors of your standard Inventor configuration files. Within Vault, the almighty Category defines exactly how a file behaves in Vault. This dictates the Lifecycle definition, which in turn dictates the Lifecycle states available, which dictates the security on those files, which ultimately makes using iParts with Vault palatable and prevents the frenzy of save after save (we’ll cover this in the workflow section). Categories also define which Rev scheme to use, along with Property assignments, etc. But how do we get these configurations to trigger appropriately in Vault?
The good news is that Vault will assign Categories based on a rule generator. So, here are the clues to proper Configuration Category assignment:
On the behaviors tab under Tools>Administration>Vault Settings, click the Rules button. Provided you’ve created Categories for Configuration Members and Factories, click the New button on the top bar. Enter a Rule name called Factory, and choose the Factory Rule from the pull down. Repeat the same step for Configuration Members.
Next, select the rule for Factories. In the lower half of the window is the Rule Condition Builder. This allows you to leverage a number of Properties in the system: Indexed, User Defined, and intrinsic. From the Property pull down, select Classification, Condition Is, and Value = Configuration Member. Ensure that the Apply rules on file creation box is checked, and click OK. Repeat for the Member rule, Classification Is Configuration Member.
Finally, select the rules you’ve created for Factories and Member, and move them to the top of the list using the arrows. Why? The rules engine works from top to bottom, and it stops once a rule is satisfied. Remember that iParts and iAssemblies have file extensions of .ipt and .iam respectively, so if you have other Category Rules that trigger off these file extensions, you’ll want to ‘catch’ the configurations first.
Stay tuned, and we’ll outline workflows and categorization strategies.
-Brian Schanen
Following the post on Autodesk Vault and Inventor Configurations, I had the privilege to test some of my theories and new workflows during several hands-on advanced Data Management Workshops here in the Novi office. These workflows were well received, and I think its time to share these with the Vault community. First, we’ll talk about standard - not custom - iPart workflows.
Let’s start with a review of the basics. Inventor iPart Members get their values from a table (MS Excel) within the Factory file. This includes a variety of data like parameters, properties, feature suppression, work features, etc. Another way to look at this is tabulated drawings, but in a 3D representation. All of this is designed to configure the Member file to a pre-defined configuration upon placement within the context of an Assembly, thus conforming to standards. Finally, the file format for iPart Factories and Members alike is .ipt, and Yes, Vault recognizes and knows the differences.
Now, if you’ve ever examined a generated iPart Member, you’ve noticed that this file isn’t meant to be modified directly. The usual part editing tools are not available, and this is by design. In other words, the files are ‘locked’ in their chosen configuration.
You could also say that the member file is set/frozen/released etc. Given that fact, my first suggestion is to leverage the Document Management behaviors and set these files to a Released state.
In an effort to automate this ‘released’ behavior, we’ll create two new Categories: Configuration Member and Configuration Factory.
Once the Categories are established, you can assign them to either existing Lifecycle Definitions or create new ones. For my example with Configuration Members, I am using the Simple Release Process which I’ve used with Categorizing Content Center Files in Vault. You can also create your own Lifecycle Definition specific to Members with unique state names. The important step here is to modify this Lifecycle Definition to default to the Released state, and this will provide the security that matches our needs for generated iPart Members immediately upon check in to Vault.
The Configuration Factory Category on the other hand can be assigned to another Lifecycle Definition that doesn’t default to Released, and has more Lifecycle states.
The Basic Release Process is suggested here as it has the Obsolete state, which is useful in the event you retire an iPart in the future. This will ensure that user will not place it within an assembly, yet keep a record of it in Vault.
In the next post, we’ll examine Revision Schemes assignment on Configuration Members and Factories within Vault. Stay tuned….
-Brian Schanen
Administrators and users alike will find more consistency between the file environment and the item environment with the Autodesk Vault Professional 2011. Property sets are now based on categories for file and item objects, making the administration and creation workflows consistent between the two environments.
Further, just as files used rules to assign categories to a file object in the previous release, rules may now be used to determine which category gets assigned to an item, added more configurability and flexibility to your deployment. Finally, categories bring the added benefit of exposing multiple revision schemes to items, now giving users the flexibility they need to change the revision scheme on an item as business demands.
-Brian Schanen
Subscribe