TBOs – Part 1

In this post I will be looking at what kind of functionality should be implemented in a TBO and what could be implemented elsewhere in the Documentum software stack. So, what kind of functionality should be implemented in a TBO?  Here are some examples:

  • metadata validation – ensure certain metadata values are valid before saving or checking in an object. For example, if you have an object that is a sub-type of dm_document that must have a non-blank ‘title’ attribute, you can enforce this requirement using a TBO.  Or, you can ensure an object’s name is unique in a folder (or the entire Docbase) before saving it.
  • inherit metadata values – inherit metadata values from an object’s containing parent folder (or virtual document root).  For example, if the object is a document in a case, it must be assigned the case number to which it belongs.  The case number is a metadata value on the case folder.  When the document object is saved or moved to the case folder, it must inherit the case number from the folder.  (The same scenario could work if the case was actually a virtual document instead of a folder also.)
  • change delete behavior – override the delete behavior to log the object name, object id, date/time and user who is deleting the object.  Every time the user deletes an object of a certain type, their action is logged before the delete occurs.
  • add new behavior to an object type – add a completely new behavior to an object type.  For example, create and check the checksum of an object’s content and metadata every time it is saved.  Whenever an object is checked in, calculate the MD5 hash for the content and metadata and compare it to the existing checksum to determine if a change has been made. If the checksums don’t match, write a log entry with the object name, object id, date/time and user name who made the change and save the checksum to the object’s metadata for the next comparison.

You’re probably thinking that you could implement all of this functionality elsewhere in the Documentum software stack and you’d be right, you could, but the TBO is the best
place for all of this logic, and here’s why:

  • metadata validation – validation can be done in many places including the UI (WDK) and the object model itself (via the data dictionary).  However, putting validation code in the UI can be icky and requires custom coding.  The data dictionary can be leveraged (via the object model definition) to automatically provide validation for custom attributes, but you can’t implement validation for standard Documentum attributes like ‘title’, ‘subject’ or ‘object_name’.
  • inherit metadata values – inheriting metadata can be coded into the UI and client applications, but I don’t believe this is the appropriate place for this kind of logic.  Especially if there is a chance that someone might create or move an object outside of your application (e.g., using DA).  Implementing this logic as a TBO ensures it fires every time an object is saved, regardless of the client.
  • changing delete behavior – again, changing behavior can be implemented in the client application, but in the truer sense of object orientation, wouldn’t it be nice if each object just knew how to behave correctly and you didn’t have to make exceptions for behavior in your client code?  A TBO will ensure each instance of an object of a certain type will behave correctly when deleted, regardless of which client application does the deleting.
  • add new behavior – adding a completely new behavior like creating and checking checksums could also be implemented in the client code.  But, as stated earlier, why? Centralizing behavior like this in a TBO leaves your client code cleaner and easier to maintain (or could eliminate the need for custom client code completely).

In the next post I will outline skeleton code for implementing a TBO.


About Scott
I have been implementing Documentum solutions since 1997. In 2005, I published a book about developing Documentum solutions for the Documentum Desktop Client (ISBN 0595339689). In 2010, I began this blog as a record of interesting and (hopefully) helpful bits of information related to Documentum, and as a creative outlet.

One Response to TBOs – Part 1

  1. Pingback: TBOs – Part 0 « dm_misc: Miscellaneous Documentum Tidbits and Information

Leave a Reply

Fill in your details below or click an icon to log in:

WordPress.com Logo

You are commenting using your WordPress.com account. Log Out / Change )

Twitter picture

You are commenting using your Twitter account. Log Out / Change )

Facebook photo

You are commenting using your Facebook account. Log Out / Change )

Google+ photo

You are commenting using your Google+ account. Log Out / Change )

Connecting to %s

%d bloggers like this: