BOF Page 1 of 5

Business Objects Framework:

The Business Objects Framework BOF is a set of functionality introduced in
Documentum 5.1 that allows developers to extend the Documentum Foundation Classes
(DFC). You can think of it as a layer on top of DFC that allows you to add your own
business logic; all of the existing DFC methods and behaviors are still available, BOF
simply gives you some additional (and much needed) features. Although we think of
BOF as being a layer on top of DFC, it is actually only a logical separation. BOF is
included as part of DFC 5.1 - it is in fact intrinsically interwoven into DFC.

The main purpose of BOF is to act as a business logic middleware layer for your
applications. Prior to DFC 5.1, Documentum did not provide any middleware tools. BOF
is Documentum's attempt to give developers a framework on which to add customer-
specific extensions.

Another important thing to note is that BOF was developed and optimized for web-based
applications. There are several features that make it easy to use BOF within an
application server, such as trusted logons and connection pooling. However, you will also
get huge value out of BOF if you are creating a client server application or customizing
the Desktop Client.

Benefits of BOF

There are several benefits of using the Business Object Framework, providing an
enhanced development environment for building and maintaining Documentum systems.

• Reduced Development Time - Because Documentum provides this framework for

implementing business logic, you do not have to develop and maintain your own
framework.
• Abstraction of Business Logic from Presentation - Separating the business logic
from the presentation layer has two main benefits. First, it allows you to have a
different team implementing the presentation layer than the one implementing the
business logic. Second, if changes must be made to the business logic, you will
not have to make changes to the presentation layer; you only need to redeploy
your Business Objects.
• Encourages Reuse - Business Objects are designed to be reused. Because they
are part of DFC, any application that uses DFC can use your Business Objects
(including Desktop Client, Office Integrations, and WebTop)
• Portable Across Applications - Because Business Objects are written in Java,
they can be deployed on multiple platforms, and again, they can be deployed
across all the Documentum clients that use DFC.
 BOF Page 2 of 5

When to Use BOF

If you are doing any non-trivial Documentum-related development, you are probably
going to want to use Business Objects. Not only will your code be available in multiple
Documentum clients, but you will no longer have to re-integrate your customizations
whenever Documentum releases a new version of the client.

Even if you are not planning to support multiple clients, you should still probably use the
BOF. It forces you to use object-oriented principals and to keep the business logic out of
the GUI layer, both of which are good things. Also, we expect to see the BOF becoming a
more and more important part of Documentum's development methodology, so the
sooner you become familiar with it, the better.

If you are developing a web-based application that accesses a docbase, you will
absolutely want to use the Business Objects Framework. The BOF was created with web
application developers in mind, and there are enough performance improvements and
conveniences offered by the framework that it will certainly be worth your time to learn
about it.

Key Features

Polymorphism

Polymorphism is an object-oriented programming term. If a programming environment

supports polymorphism, it means that different types objects can behave differently when
the same method is called on them. A system that supports polymorphism treats sub-
classes the same as it treats superclasses and allows the programmer to modify the
methods of the subclass that are inherited from the superclass. The syntax of the method
stays the same, but the implementation changes. For example, if a method acts on a
widget object, you can also pass that method a sub-class of the widget object. And if the
widget object has a method named foo(), you can create your own foo() method on the
sub-class that does something different.

In Documentum 4.x, DFC didn't really support polymorphism (at least not from the point
of view of a developer using DFC to create an application). You could not sub-class DFC
objects or extend their behavior. Clever programmers would get around this by creating
their own objects that implement the same interfaces as the DFC objects. But in this case,
they would have to re-implement every method in the DFC object's interface. This is a
real pain.

However, with the addition of BOF, you can now sub-class DFC objects and extend them
to either override existing methods or add your own methods. You don't have to re-
implement every method - you only need to re-implement the methods that you want to
override.
 BOF Page 3 of 5

Object Factory Guaranty

An object factory is design pattern where one object (the factory) creates other objects.
Factories are used to prevent programmers from explicitly declaring the implementation
class in their code. Instead, programmers declare the interface that they are using and
have the factory instantiate the implementation class.

DFC has always used an object factory to create the Java objects that you use in your
code. You have never been able to create a DFDocument directly, you always have to use
the factory to create one.

WRONG: DFDocument doc = new DFDocument();

RIGHT: IDFDocument doc = sess.newObject("dm_document");

The main drawback to this approach is that in version 4.x, even if you were a clever
programmer and rolled your own object that implemented the IDFDocument interface,
there was no way that your object would get used by any existing DFC applications.
Since all the applications used the object factory, and the object factory only created
Documentum's objects, your custom objects would never get created.

In DFC version 5.1, this shortcoming is rectified. You can now tell DFC's object factory
to create your custom objects instead of the normal DFC objects. As a result, existing
Documentum applications such as Desktop Client and WebTop will be able to call all the
custom business logic you include in your custom business objects. This is accomplished
through the use of the Documentum Business Object Registry. If your objects have been
registered with DBOR, the object factory guarantees that your custom object will be
created and used whenever it is appropriate.

Documentum Business Object Registry (DBOR)

The Documentum Business Object Registry (DBOR) allows developers to "register"

their custom business objects with DFC's object factory. The DBOR maps your custom
Documentum object type (in the eContent Server) to your custom business object Java
class.

Once registered, DFC will automatically create and use your business object whenever it
is dealing with a document object belonging to that custom object type. The object
factory guarantees that this will happen.

To register a business object with an object type, you can use the DborManage tool
provided with DFC or you can manipulate the DBOR registry with a new dbor object in
DFC.
 BOF Page 4 of 5

Types of Business Objects

There are two types of business objects, Type-Based Objects (TBOs) and Service Based
Objects (SBOs).

Type-Based Objects

Type-based business objects (TBOs) are the most common types of business objects.
They correspond to custom object types in the Docbase and used to apply custom
business logic to those object types. You create a TBO by extending a DFC object such
as DFDocument.

Type-based objects allow developers to override the typical DFC methods to add
validation logic or change the way that the original methods behave. You can also add
your own custom methods for your own purposes. Because all objects are created via the
object factory, your TBO is guaranteed to be used even by existing Documentum clients.

TBO Example - Custom Validation Logic

There are many ways that type-based objects can be used. One of the most common uses
is to apply custom validation logic that goes beyond what the data dictionary provides.
For example, imagine that you have created a custom object type in your Docbase called
a report. This object type has two custom attributes, report_type and report_number. You
have set up value assistance for the report_type attribute, creating a list of the types of
reports your organization creates. This list contains three possibilities: Marketing Report,
Engineering Report, and Research Report. Marketing and engineering reports can have
arbitrary report numbers that are specified by the author of the report. But research
reports must have report numbers that follow very specific rules. In this case, the report
number for a research report must be unique and it must already have been created in the
Research Department's report database

Let's examine how we would enforce this rule using Documentum 4.x. You might first
attempt to use the data dictionary, but this will not work. Unfortunately, the attribute
constraints provided in the data dictionary can not have conditional logic; you can not
have the constraint for report_number depend on the value of report_type. Also, you
can not make the data dictionary fire off a script to check with the research department's
database.

Therefore, in version 4.x, you must customize the properties dialog GUI in order to add
this logic. Unfortunately, you will have to customize the dialog for every application you
use: Desktop Client, Intranet Client, WebPublisher, etc. And each time that Documentum
upgrades one of these applications, you will have to re-integrate your customizations into
the new version.

In version 5.1, however, enforcing these validation rules is much easier. You would
simply create a business object java class to represent your report. To do this, you extend
 BOF Page 5 of 5

the existing DFDocument object. To insert your custom validation logic, you re-
implement the save() and checkinEX() methods, adding your custom code to check for
uniqueness and query the external database. Don't forget to call the superclass method to
actually do the save or checkin once the validation is complete. After you register this
object with the DBOR, all of the existing Documentum clients will begin to use your new
code. You don't have to make any GUI modifications at all.

Service-Based Objects

A service-based business object doesn't map to a particular object type in the Docbase.
Instead, it provides general purpose functions for your application to use. Service-based
objects can be used across docbases, even accessing multiple docbases at once. These
service-based objects are intended to be called from your own custom GUIs or as
convenience functions from within your type-based objects.

Service-based objects were designed and optimized for multi-user, mutli-threaded, multi-
docbase web applications.

An example of a service-based object is an object that determines if an attribute value is

unique. This SBO could be used from within our report business object described in the
example above. The SBO would take four arguments: Docbase name, object type,
attribute name, and attribute value. When invoked, the SBO would establish a session
with the Docbase (using the session manager) and would query the object type to
determine if the specified attribute value already existed. This way, multiple TBOs could
call the same SBO to check for attribute uniqueness without duplicating this code in
every TBO. You would probably even want the SBO to connect to the Docbase as a
superuser so that the query is run with superuser permissions.

Currently, there are not many service-based objects being provided by Documentum.
However, in the future, this will change. For example, all of the business logic in
WebPublisher 5.1 is being developed using BOF. This means that developers will be able
to override the existing WebPublisher SBOs with their own to change the behavior of
WebPublisher.

For example if there is a requirement where you have to validate the name of a document,
like making sure hat the document name is unique in the docbase. For this requirement
we need to implement the functionality in different components like Import, Create new,
Properties components where ever the user get access to modify the document name. In
this case, instead of writing the code in all the components, we can just create a service,
which will validate the name of the document. Use this service wherever you want to
implement this functionality.