Abstract

With BOF 2.0, business objects are registered and stored in a repository unlike the previous model where they needed to be registered in the dbor.properties file. This document describes our experience of registering a Service Business Object (SBO) for BOF 2.0

Software Environment

Introduction

Type Business Objects(TBOs) are bound to a repository and are stored in the corresponding repository. For example, if you have a TBO for customizing 'checkin' on a type dp_mytype you would have to register it with every repository that contains the type dp_mytype and for which you want checkin to be customized. For example, assume you have two repositories A and B both containing the type dp_mytype. If you register the TBO with only respository A, then the checkin customization will be invoked only when using objects of type dp_mytype from repository A and not when using dp_mytype objects from repository B.

Service Business Objects are meant to encapsulate cross-repository functionality. It is not efficient to register them in every repository. A repository needs to be selected that will act as global registry for generic modules like Service Business Objects(SBOs). Thus, SBOs need to be registered and stored only in the repository designated as the global registry and not all the accessible repositories. DFC 5.3 implements caching to account for cases when this global registry is inaccessible. To access this repository, a special user needs to be created with privileges to only access the registered modules.

Global Registry User

A 5.3 Repository creates a user called dm_bof_registry. If the repository is to act as a global registry of modules like SBOs, this user needs to be enabled. This user's credentials are used to read the modules from the repository. To enable this user, we set the user's state to 'Active' and modified the password to something familiar using Documentum Adminitrator.

Fig - Modifying User Properties in DA

Note:It is not necessary to only use the dm_bof_registry user. We could have created a different user instead. We stayed with dm_bof_registry user for the sake of convenience.

For more details refer to the Content Server Installation Guide -> Preparing for the Content Server Installation -> Preparing for the Business Objects Framework Global Registry.

Modifying the dfc.properties

We then modified the dfc.properties to point to the Global Registry and specified the user name and password. On our machine, dfc.propertie was in C:\Documentum\config. Here are the lines that we added,

dfc.bof.registry.repository=devprog dfc.bof.registry.username=dm_bof_registry dfc.bof.registry.password=GrRNPhLJrkoTDAZE0RGJow==

DFC provides a utility to encrypt the password. We navigated to the folder that contains dfc.jar and ran the following from the command prompt. Our password is this case was 'dm_bof_registry', which is needed as a parameter to the RegistryPasswordUtils application. The utility then printed out the value on the command prompt, which we then copied and pasted into dfc.properties.

C:\Program Files\Documentum\Shared>java -classpath dfc.jar com.documentum.fc.tools.RegistryPasswordUtils dm_bof_registry

For BOF 2.0, we separated the interfaces and implementation classes of the business object into different jars. Our interfaces were stored in folderPolicyService.jar and the implementation classes in folderPolicyServiceImpl.jar . From a developer's perspective, we separated out the interfaces and implementation into separate packages. The interfaces were contained in a root package com.documentum.devprog.lifecycle.fldr and the implementations were contained in a subpackage 'impl' i.e. com.documentum.devprog.lifecycle.fldr.impl. However, that is not strictly necessary.

Note:Do not bundle the interface classes in the implementation classes jar file and vice versa. This can lead to hard-to- debug exceptions, specifically ClassCastException.

For more details refer to DFC 5.3 Development Guide -> Using the Business Objects Framework -> BOF Infrastructure -> Global Registry

Registering the Business Object

In Documentum Application Builder(DAB), we first inserted a new module using Insert->Module.

On the 'Implementation' tab, we filled in the various properties. The name of the module was the fully qualified name of the interface - com.documentum.devprog.lifecycle.fldr.IFolderPolicyService.For interface jars, we selected folderPolicyService.jar and for implementation jars we selected folderPolicyServiceImpl.jar.

Fig - Implementation Tab in DAB

On the 'General' tab, we selected the class name as com.documentum.devprog.lifecycle.fldr.impl.FolderPolicyService. DAB detected the next two fields - 'BOF Version' and 'Interfaces'.

Fig - General Tab in DAB

We left the 'Runtime Environment' and 'Dependencies' tabs untouched as these are advanced options and not necessary in our case. On the 'Description' tab we filled in the preliminary information like 'Contact' and 'Description'

Next, we checked-in the new module into the repository and ran our code that tested the service.

For more details refer to the Documentum Application Builder Help -> Working with Modules.

Verification

To verify proper setup of global registry, here is some simple code that prints all the registered modules in it.Notice that you do not need to create a new session because DFC uses the registry user defined in the dfc.properties file.

private static void testGlobalRegistry() { try { IDfClient localClient = DfClient.getLocalClient(); IDfGlobalModuleRegistry gmr = localClient.getModuleRegistry(); IDfEnumeration mods = gmr.getServiceDescriptors(); while(mods.hasMoreElements()) { IDfModuleDescriptor md = (IDfModuleDescriptor) mods.nextElement(); System.out.println("Module name: " + md.getObjectName()); } } catch(Exception ex) { ex.printStackTrace(); } }

Summary

• Enable a repository to be a global registry by creating a user with read access to /System/Modules folder in the repository
• Reference this user in the dfc.properties file on the DFC machine.
• Separate the business object into interface and implementation jars.
• Register the business using Application Builder
• Reference the interface jars in the DFC applications classpath

Bugs or Comments

If you find bugs or issues with the component/article, please contact developer_program@documentum.com with a short description of the issue, steps to reproduce it and the relevant software environment.