BOF 1.0 and BOF 2.0

BOF is critical in getting business logic and processes implemented accurately *enterprise* wide. And its capabilities play significant role with development, deployments and migrations. First of all, I have to be honest and say how much I adore the BO framework in Documentum. When the first version came out, I loved it and loved the control it offered. And soon realized how the BO functionality wasn’t being invoked on machines where BO registration wasn’t done. And it was taken care of in 2.0, but it was not recommended to use dbor.prop although it was backward compatible. This intangible setup on a machine (using 2.0), leaves you hanging when things do not work. And the fact that individual interfaces/implementations for each business object need to be deployed OR define the same jar over and over for each business object if you decide to club all together – not perfect yet…

What I would have loved to seen is the power of BOF 2.0 with the control of BOF 1.0. In other words,

1. To be able to invoke the business objects dynamically by holding the jar’s in a central location (2.0)
2. To be able to define these explicitly on the machine (1.0), if you want to
3. To be able to dynamically invoke the BO call unless explicitly restricted (partly 2.0)
4. To be able to use single JAR and manage all the BO definitions in one place (1.0)

This would be perfect.

Right in the definition, if we could have an option to disable the BO call (default being, invoke), it would make some of the unique migrations easier. I had been involved in scenario’s where if a piece of content is created of certain type, a WF is triggered. Now, imagine importing legacy content of this type into Documentum and you didn’t want the BOF to kickoff for the legacy part of it… it just would have been great to flip a switch and turn BO off when the import is executed from that machine – or even better, be able to point to a different class.

While we are in this framework, providing a “debug” option right in the BO definitions for the machine would be a life saver. Imagine logging standard BOF calls: which docbase is the BO call request is being made to; are the bof_registry user credentials available; did bof_registry user successfully connect; did the CS find a new version of jar it should download etc. What this gives us, is to explicitly look and confirm that a certain machine is configured to utilize the business objects (using the BOF definitions) and be able to narrow down any issues when a JAR doesn’t invoke on a certain machine — sure, we can turn the trace on for the system, but if you are deploying on PROD and you realize that a specific SBO is not being invoked, this setup will quickly confirm where the problem might lie.