Creating a Custom Module in DFC
| February 2006 | |
|
Software Environment
| Feature | Tested on |
| Operating System | Windows 2000 Server SP4 |
| Compiler | Sun JDK 1.4.2_08 |
| Runtime | Sun JRE 1.4.2_08 |
| DFC | 5.3, 5.3 SP1, 5.3 SP2 |
| Content Server | 5.3 SP1 |
Abstract
DFC 5.3 introduced the concept of modules. A generic definition of a module is that it is a discrete, self-contained unit that can be combined with other modules to create a larger application. Service-based Business Objects(SBOs) and Type-based Business Objects(TBOs) are types of modules. This article discusses the process for creating a custom module.
Description
DFC provides the base interface com.documentum.fc.client.IDfModule and the base classes com.documentum.fc.client.DfSingleDocbaseModule and com.documentum.fc.client.DfMultipleDocbaseModule to create your own modules. The com.documentum.fc.client.DfSingleDocbaseModule class should be subclassed when you are creating modules specific to a repository. com.documentum.fc.client.DfMultipleDocbaseModule should be subclassed when you are creating a module that performs cross-repository operations. Creating your own modules allows you leverage the dynamic deployment model for modules introduced in DFC 5.3. Lets look at creating a simple module -
Interface
Create an interface that extends the com.documentum.fc.client.IDfModule interface and add any custom methods that you want.
/*
* Created on Feb 1, 2006
*
* EMC Documentum Developer Program 2005
*/
package com.documentum.devprog.mods;
import com.documentum.fc.common.DfException;
import com.documentum.fc.client.IDfModule;
public interface IModuleTest extends IDfModule
{
void sayHello() throws DfException;
}
|
Implementation Class
Create a class that subclasses either the DfSingleDocbaseModule or DfMultipleDocbaseModule class and implement the custom interface that you defined in the previous step. Note that we have used a separate package for the implementation class. Within the implementation class the session management guidelines are similar to those for SBOs - the session should be obtained within the method body and released before the method exits (typically done within the finally clause).
/*
* Created on Feb 1, 2006
*
* EMC Documentum Developer Program 2005
*/
package com.documentum.devprog.mods.impl;
import com.documentum.fc.common.DfException;
import com.documentum.fc.client.DfSingleDocbaseModule;
import com.documentum.fc.client.IDfSession;
import com.documentum.devprog.mods.IModuleTest;
public class ModuleTest extends DfSingleDocbaseModule implements IModuleTest
{
public void sayHello() throws DfException
{
IDfSession sess = null;
try
{
System.out.println("Repo Name: " + super.getDocbaseName());
sess = super.getSession();
System.out.println("Session id: "
+ sess.getSessionId());
}
finally
{
if(sess != null)
{
super.releaseSession(sess);
}
}
}
}
|
Registration
Now create separate jars for the interface (e.g. testGenericModule.jar) and implementation class (e.g.
testGenericModuleImpl.jar). Now register this module in the repository (this need not be the global registry) using Documentum Application Builder. The following are the properties -
Module name: is com.documentum.devprog.mods.IModuleTest, which is fully-qualified name of the interface.
Interface Jar: testGenericModule.jar
Implementation Jar: testGenericModuleImpl.jar
Implementation Class: com.documentum.devprog.mods.impl.ModuleTest
Fig - Registration using Documentum Application Builder
Testing
The following test program invokes the module. Notice that the module instance is created using the IDfClient#newModule(...) method. The first argument is the repository name in which the module resides. This implies that the session manager provided to the newModule(...) method must have an identity set for this repository. Also, remember to place the interface jars in your DFC application's classpath.
public static void main(String[] args)
{
try
{
IDfClientX cx = new DfClientX();
IDfClient lc = cx.getLocalClient();
IDfLoginInfo li = cx.getLoginInfo();
li.setUser("dmadmin");
li.setPassword("dmadmin");
IDfSessionManager sm = lc.newSessionManager();
sm.setIdentity("devprog53sp1",li);
String name = IModuleTest.class.getName();
IModuleTest mt = (IModuleTest) lc.newModule("devprog53sp1",name,sm);
mt.sayHello();
}
catch(Exception ex)
{
ex.printStackTrace();
}
}
|
Module Type
In the 'Module Type' field in the image above, we have entered a new type instead of selecting 'TBO' or 'SBO'. You can create a new type too.
Example -
You could create different types based on some base custom interface that extends the IDfModule.
interface IMyModuleType extends IDfModule
{
String getSomeCustomMethod();
}
|
Then you could call all modules that extend and implement the IMyModuleType interface to belong to a custom category like 'MyCategory'. For the above test module, we entered a type of 'DevprogCustomModule'. This resulted in creation of a folder with that name as a peer of the folders 'SBO', 'TBO', ...Within this folder is contained the actual module - com.documentum.devprog.mods.IModuleTest.
Fig - Type of Module
Points to Note
DFC does not enforce single or multi repository behavior for the classes DfSingleDocbaseModule and DfMultipleDocbaseModule respectively. It is the implementor who needs to enforce the single/multi repository behavior. The DfSingleDocbaseModule should be stored in the repository for which it is meant. The DfMultipleDocbaseModule can be stored in any repository. You could standardize a repository into which all the multi docbase modules are stored very much like the global registry does for SBOs. Note that multi docbase modules are not loaded using the global registry mechanism. The credentials stored in the dfc.properties, used to load SBOs from the global registry are not used to load multi docbase modules. The global registry is strictly only for SBOs.
Source Code
Download.
The download contains the docapp for the module, the source code and the interface jar.
|
