If you have upgraded to Vault 2011, you may have noticed some changes regarding how properties work. And when I say "some changes," I really mean "many changes." Actually, "re-architecture" is probably a better term to describe what we did to properties.
If you read my earlier article on properties, feel free to forget it. Some of it is still relevant, but some of it isn't. So to make things easy, I'll just start over from the beginning.
One more thing, make sure to read my article on Entities. The new property architecture doesn't even begin to make sense until you understand Entities.
At a High Level:
Properties are a type of Behavior, which basically means it's a feature that works on Entities instead of specific object types. There are 2 things we do with this concept: 1) we consolidate the feature and 2) we allow data to be shared across entity types.
These concepts can be seen on the Properties dialog (Tools menu->Administration->Vault Settings->Behaviors tab->Properties button). Everything is in one dialog instead of being separated by File, Item and Change Order.
This dialog gives you a nice list of Property Definitions. Notice how each definition is associated with 1 or more entity classes. This is nice because you can define a property definition once and use it multiple places. A property definition can only work with entity classes that it is associated with.
You can also associate property definitions with categories. This allows you to change the behavior of the property depending on the category that the entity is. This feature allows for more specialization while still promoting reuse.
System Properties and UDPs:
Properties maintained by Vault are either System properties or User Defined Properties (UDPs). The main difference is that UDPs values can be edited directly, and system property values are set by the system. At the property definition level, system properties have only a few edit options. Likewise, system properties cannot be added or deleted.
Content Source Properties:
Vault Properties do many things. They fill in the data grids, they allow searching, they allow lifecycle state restrictions, etc. All this is possible because Vault "owns" this data. Vault keeps the data in its tables and indexes, and everything is organized to support the Vault features.
But what about properties not owned by Vault? Those properties aren't organized by Vault and aren't in a format that Vault recognizes. We refer to these as Content Source Properties because they are content form a source other than Vault. So how can Vault work with this data?
The solution is to map the content source property to a UDP. That way Vault can do all it's operations on the UDP without having to know or care about the mechanics of the content source property.
The glue between the content source property and the UDP is a module called a Content Source Provider. It contains the logic to read and/or write content source properties and interact with the Vault framework. These providers are broken up by file type. So there is one for AutoCAD and one for Inventor and so on. There is also an "All Files" provider to handle all files not claimed by another provider.
That's all I have for this article. Next week, I'll go into some of the specifics of File properties. Then after that, I'll post an article on Item properties.