Tuesday, September 30, 2008

Docapp Distractions

I know Composer is out there and useful in many installations, however it’s tempting to still use the Docapp Builder to build real time object models and once you start you kind of have to keep going. Also, there are still a ton of 5x installations out there that need to be maintained and eventually upgraded.

Different versions of Docapp Builder and Docapp Installer
I was recently in a situation where one developer was developing on D6 sp1 with a Docapp Installer version 6 and another was developing using 5.3 sp5 update1. The D6 developer was creating docapp archives for Forms and Process Builder which when installed using the 5.3 sp5 update1 installer left out certain form properties and functionality. It was a real waste of time trouble shooting these issues.

Creating a workflow docapp with auto activities for lifecycle promotion
If you create a workflow and have an auto activity for promoting a lifecycle state regardless of whether the lifecycle is added to the Docapp, the lifecycle will get added to the Docapp archive and installed on the target docbase.

ACLs with non dm_dbo domains
If you have set up ACLs with an owner that is not the dm_dbo (docbase user account) then these permission sets will not show up in the Docapp’s Lifecycle, Action, Add permission set drop down list.

Versions
If you are splitting the docapp work between a few developers, get ready to deal with a lot of versions of the docapp and all of the workflows, lifecycles, activities, etc.

ACL inheritance from Folder
If your docbase is set up with ACL inheritance from folders be sure to set the “System/Applications” folder ACLs. If you don’t do this, everytime you deploy a docapp its components, such as a lifecycle will inherit the ACLs of the docapp folder and may or may not work in the application.

Scoping of Display configurations
This is very strange when it happens. Let’s say you start out with a small object model of two levels and configure the display. Then you need to add a new parent level and redo the display. Sometimes the scope remains with the original model and object type. The only way I found to fix this was to dissect the database scope config and cut out the disease.

Mandatory attribute changes with old references
If you ever decide to change an object type’s attribute from required to not required, sometimes this change is held in a reference or cache somewhere. The only way I’ve been able to clear it is to delete the attribute using DAB, closing DAB, clearing the cache and inserting the attribute again.

Importance of having one source for docapp creation
I can’t stress it enough that Docapps should be created and control from one source, with the same versions of the Docapp Builder and Installer on the source and target machines. Configure the object type’s display only when the attributes and object model are final. Add workflows in with lifecycles. Try not to version docapps or its objects unless absolutely necessary. Finally, beware of the permissions that are inherited by the docapp installation.

No comments: