Posts Tagged ‘TBO’

Documentum Business Objects Registry

May 4, 2010 Comments off

When creating a new document of document type ‘dm_document’ using WebTop application, internally DFC system will create instance of DFC classes DfSysObject, DfDocument and so on, thus limiting the functionality to that provided by DFC standard classes.

When using business objects, classes mapped to an existing object type (or custom object type) can be extended to provide our own business logic; this is done while developing TBO. Through object oriented mechanism called polymorphism, methods of these new classes gets called in bottom up order, i.e., methods in the parent class can be overridden in the new classes written. These new methods will be called automatically by DFC system.

The object factory guarantees that the correct object will be instantiated at runtime. This applies to TBO but not necessarily to SBO. When a TBO is developed and deployed on application server or content server, the framework guarantees that the new object gets called automatically. Two things make this happen. One is Documentum Business Object Repository (DBOR) . The other is that use of registry is now an integral part of DFC. Whenever someone attempts to access a custom-type Docbase object, DFC first checks the registry for a mapping to a custom Java class, then loads and instantiates that class.

DBOF provides the following mapping at runtime:

1. Docbase Type name to Java Class mapping: When the DFC core loads a Docbase object, its type name is looked up in the registry. If the name is found, its corresponding Java class is loaded and instantiated.

2. Service Interface name to Java Class mapping: When requesting the client to load a service, the service is identified by its published interface name, such as com.documentum.IInbox. If DFC finds the interface name in the registry, the corresponding service class is loaded and instantiated and returned to the caller.

Session Manager: Whenever an application requires access to a DocBase, authentication is required. Session Manager encapsulates the DFC session object and automatically manages the session pool. To get session in SBO java class, one has to acquire it using Session Manager and release it when not needed. Whereas in TBO’s, a reference to TBO’s session is embedded inside the object by default.

Session Pooling: Session Pooling provides for an application to connect and disconnect from DocBase session many times without incurring the overhead of real sessions with the server. Session Manager puts back the session into the pool when the client releases it, free to be used by other requests for sessions.

The concept of TBO and SBO is similar to the EJB in J2EE, TBO represent entity beans
and SBO represent stateless session beans

Business Objects Framework in Documentum

April 30, 2010 Comments off

Documentum Business Objects Framework (DBOF) is a new framework for developing and executing reusable business object components. The framework is built into DFC and
accessible from applications written using DFC.

DBOF provides a way for developers to hook their own logic into normal DFC procedures by extending DFC classes. DBOF lives wherever DFC lives, either on the Content Server or Application Server, or on any of the other clients.

There are two types of Documentum business objects type based business objects (TBO) and service based business objects (SBO).

Type Based Objects (TBO):

Type based objects are implemented as classes that extend basic persistent DFC types such as DfDocument, DfSysObject, DfPersistentObject, DfFolder, etc. They allow you to encapsulate business logic that is specific to a particular Docbase object type. In this case, DFC dynamically constructs an instance of the new subclass at runtime. Even when accessed by programs unaware of the new subclass.

There are two main reasons for creating a TBO:

1) To provide a new behavior for new or existing custom object types. For instance, a developer may decide to add getter and setter methods for object specific attributes or add new methods like adding a Product to a Catalog TBO.

2) Customizing low-level operations to enforce data validations, referential integrity and object specific business rules. For instance, a developer may decide to override the save() and checkinEx () methods to be able to validate data before saving them in the persistent storage.

In a TBO, typically the business rules and any other logic is implemented in the methods save(), checkout(), checkin(), saveLock(). Because checkout () and checkin () methods are final, the DFC system has provided methods checkinEx(…) and checkoutEx(…) methods for such operations.

Service Based Objects (SBO):

Service based objects are not tied to a specific Documentum object type. They are generalized objects that provide a specific service that may operateon different Documentum object types or other business objects.

%d bloggers like this: