When good intentions go awry

So I was reading the Using Registered Tables vs Object Types design patterns discussion a few months back on EMC Developer Network.

I’m a Documentum old timer, so I was more comfortable using registered tables. Those of you who have used registered tables as lookups knows that its pretty straight forward. Create a table and then REGISTER it so that you can query against it using DQL. The hitch is that if you dont have privileges on the database (or the database is managed by a different group), you are highly dependent on them getting the table schema created with the appropriate permissions. Also, you are dependent on them to move the table and its values from one environment to the next OR you have to have strict version management of table population scripts. Anyways, I have followed this tedious process for many, many years.

After reading the design patterns discussion, I decided for my new project, I would try using object types for lookups. I was not too concerned about security on the objects given that the users were using Taskspace and would not have the ability to delete/manipulate the lookup objects.  I created custom type will null supertype, since I wasnt planning to have any content associated with them.  See Laurence Hart’s posting on using Contentless Objects as Lookups.

So I created quite a few custom types and created several hundred object instances of my custom lookup types.  It was very easy to change the value of the lookups and create new ones using DA or any other Documentum application.  Not only did I not have to worry about managing table population scripts, but I did not have to get DBA team involved, since creation of custom object types can be done using DA or DAB.  Everything work as expected.

Fast forward a couple of months and now we are ready to deploy our Taskspace application from DEV environment to testing environment.  Taskspace was designed to use the docapp archive feature of DAB to move form templates (components), processes, tabs, roles, and presets from one environment to the next.

Lo and behold, DAB does not support the archiving of contentless objects with null supertype.  There is no way to include object instances of this kind in docapp archive.  This makes sense at object type definition level; if custom type is not derived from dm_sysobject, then it doesnt have i_folder_id attribute, which means the object lives in what I like to call “La La Land”.   Application Builder supports the inserting of objects, but it assumes that the object resides in some folder.  Unfortunately, there is no “Insert Persistent Objects.”

I havent tried Composer to see if this is supported, but it really was a surprise to me that this feature was not in DAB.  In the end I had to remap the custom lookup types to be derived from dm_sysobject.  I hope my experience with this will prevent someone from going down the wrong path.


14 responses to “When good intentions go awry

  1. Johnny, never tried this myself, but would a dump-and-load have grabbed the objects and moved them?

    Regardless, great post and thanks for sharing.


  2. I didnt try it. My goal was to fully utilize the docapp archive and not have any ancillary steps as part of the migration process.

  3. Interesting post and observations . Just to share my experience .. i have been using dm_folder objects as lookups ..

    it works well for cascading lookups also and the beauty of it is you can assign acls to folders so some users that dont have access to it these values are displayed in lookup for them ..

    And you can use application builder to move folders .. the only catch we have discovered with this . if the folder tree is really deep app installer chokes on that …

  4. Thank you for sharing your experiences summitsoft.

  5. In my opinion this situation is like having a system without a proper data entry point. In all my projects I have observed the need to update multiple entries at one go with consistency checks. I have a custom component (that is tweaked as per my current project) to load the picklist data. It uses Apache POI, the excel sheets are named after the type names and the first row of each sheet always contains the col headers. The user uploads it and you have the values in the table. There is a similar ‘Print’ component that exports data to excel. This is similar to a stripped down docloader style data loading. even if we made docapps to transfer contentless object, I can see situations where the list may need to be customised /docbase, /department or /site.

  6. Johnny, Thanks for sharing this pitfall. I have used null-(super)type contentless objects for lookups in the past. I have written some scripts that simulate the archiving of these objects. Essentially the input is the objects in the docbase and the output is a DQL script file for creating these objects. The point of using null supertype is not to carry the baggage of all those attributes that you don’t need – but I don’t think that is a big deal.

  7. Hi doquent,
    I do agree with you with the purpose of null supertype. I believe the flaw is in the design of the App Builder. I just cant believe that this feature, which is not complicated, has not made it into the product.

  8. Hi Johnny

    I am under the same umbrella and i have to use contentless objects to create some tables using script so do you have any idea how do i do that ?

  9. If you want the ability to archive the objects in docapp archive, then you have to create them as subtype of dm_sysobject.

  10. Johnny, we’re using TaskSpace too and I have a question for you that is related to this post. We have over 100 forms that will be recreated in TaskSpace. For the form elements, would you create structured data types (process variables) or would you create custom object types to store the data from the forms?

  11. Hi eroomexpert,
    Your question depends on whether you want to persist the data from the forms. Process variables only exist in the context of the workflow. Once the workflow completes, these variables (and values) get lost. That being said, Forms Builder also allows you store the form values directly in the xml in addition to storing on object attribute level. Which option to use depends on whether you need to search for any particular xml element, given that embedded FAST search engine cannot search for specific xml element values.

  12. Thanks Johnny. You know how clients are…. they will surely want to search for specific form field entries. So, I guess that means we need custom object types, am I right?

  13. Yes. I would explain to your client that they analyze and identify which attributes that they truly want to search against. The last thing you want to do is create an object type that has hundreds of attributes.

  14. Hi Johnny,

    Thanks for sharing this. The only question that rises is how a system administrator would actually change lookup values in this solution. Since the contentless objects are in “La La Land” there’s no easy way to open them in DA when changes must be made, except for searching for them… Or do you have other options for this?

    As for my experience, we used dm_folder subtypes for this as well, which made it possible to even have local lookup values (Set ACLs of english users to only see the english lookups and set ACLs of Dutch users to only seethe Dutch values).

    Anyway, thanks a lot for your posts… they’re of great help!

    Perhaps we’ll see eachother some day in Prague this november.


    Kees van Bemmel.

Leave a Reply

Please log in using one of these methods to post your comment:

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