Blog

SBO's, what and how?

I received some feedback on my previous blog on TBO's: http://www.docbyte.com/blog/creating-custom-tbo and a question that came back was: what are SBO's, and how are they connected with TBO's?

So in this tutorial, I'll try to do the following things:

• what is an SBO?
• how do you create an SBO?
• how do you use an SBO?
• provide a sample project

An SBO is a Service-Based Business Object.

"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." (dmdeveloper.com)

An SBO could do anything that doesn't specify to one object type:

• calculating and assigning a value
• adding a keyword
• generate a document
• ...

In my example I will create a simple SBO that will set the title to "Accessed from the SBO!" and add my name to the authors attribute from a sysobject.

Ofcourse this functionality is extremely simple in an actual situation your requirements would almost never be this simple.

To create your own SBO in Documentum Composer, follow these steps:

1. Create an interface IMyService that extends IDfService

public interface IMyService extends IDfService
{
//your method that executes your code
//it is possible to define more than one method

public void setAttributes(IDfSysObject sysObj, IDfSession session) throws DfException;
}

As you can see, I pass a sysobject to the SBO.  This is the object we will modify.
I also pass a session to the SBO.  This is not mandatory, as you can get a session from within the SBO.  It's just how I learned to do it.

2.  Create the implementation class for your interface: MyService.  Make sure it extends DfService and implements your service.

 

public class MyService extends DfService implements IMyService

{

//implement your method(s) you have defined in the interface
public void
setAttributes(IDfSysObject sysObj, IDfSession session) throws DfException
{
sysObj.setTitle("Accessed from the SBO!");
sysObj.setAuthors(sysObj.getAuthorsCount(), "Bart Thierens");
}
}

 

It's important to notice that I do not call sysObj.save() in the SBO.
Usually an object is not saved in an SBO, but it is ofcourse perfectly possible and it depends your requirements.
This is because SBO's are commonly called from within a TBO, and super.doSave(...) is called at the end.  And saving an object 2 times, is unneccessary time-wasting.

3. Package the interface and implementation in 2 different jars.

4. Create JAR Definition-artifacts for the 2 jars (ie. my_service_impl 
and my_service_inter).

• If you have used thirdparty libraries, create jardefs for them
  aswell and put those in a Java Library-module.

5. Create a Module-artifact of type SBO.  I suggest using the full packagename of your interface as the SBO-name:

• com.mycompany.sbo.inter.IMyService.module
  I do this for consistency's sake.  Documentum also names its SBO's like that (check under /System/Modules/SBO and you'll see some standard SBO's).
  Also, in the past I have had some trouble with SBO's that couldn't be found.

  Use this approach and your SBO WILL work.

Also, in the Module artifact set the following data:

• Implementation JARs: my_service_impl and select your MyService class
• Interface JARs: my_service_inter
• Required Modules (optional): select other Modules if you have referenced them
  This can be the case when your SBO uses a specific TBO, or another SBO.
• Dependencies (optional): when your SBO uses thirdparty libraries, select the Java library

6. If you have entered the correct data, it's time to install the SBO.
Build the project, and install it in the repository.

To check if your SBO is installed:

• Browse to /System/Modules/SBO
• Check if your SBO is present
• If your SBO uses other modules or dependencies, you can check there if they are correct.

NOTE:

This is the approach when your repository is a global repository.  This is the case for most Documentum set-ups.

When your repository uses a separate global repository, you will need to install the SBO on the global repository.

If you don't, you will see similar errormessage like: Global registry does not know of service com.mycompany.sbo.inter.IMyService

Now, the SBO is ready and installed, but it's just sitting there.

We can use our SBO in a custom DFC application, or directly from another module (TBO or even another SBO). 
It is always done using the same approach.

To call a TBO from a TBO or DFC application, follow these steps:

1. Include the interface jar from the SBO in your classpath.

2.  type the following code in your TBO/DFC app:

IDfSession session = ...;
IDfSessionManager sessionMgr = session.getSessionManager();
IDfClient client = session.getClient();

String serviceName = IMyService.class.getName();

IMyService myService = (IMyService)client.newService(serviceName, sessionMgr);
myService.setAttributes(sysObj, session);

The serviceName variable should be the name you have given the SBO.  If you didn't give your SBO the name I suggested, you have to enter a different serviceName here.

3. That is all there is to it.

NOTE:

If you call the SBO from within a TBO or other SBO, you have to add the SBO as a required module.

I've included a demo project that contains

• an SBO (code, artifacts)
• a custom type (sbo_test_type) that has a custom TBO
• a TBO (code, artifacts) that uses the SBO 

To view the project, dowload it and change .txt to .zip.

Thanks for reading,

Bart

Creating a custom TBO

As my first blogpost, I decided  to start off easy and do a (modified) repost of my blogpost on the EMC Community site on how to develop a custom TBO: https://community.emc.com/people/BartThierens/blog/2010/03/15/steps-to-create-a-custom-tbo

The question on how to create a custom TBO is frequently asked on the internet (specifically the EMC and other Documentum related forums), and although there are many other tutorials out there, I felt the need to write down the steps once again in a simple, yet explanatory manner.

"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." (dmdeveloper.com)

Steps to create a custom TBO for a type in Composer:

1. Create a Type-artifact for your custom type (ie. custom_type or whatever)
2. Create an interface ICustomType that extends IDfSysObject or any of its subtypes (even custom ones): IDfFolder, IDfDocument, IMyPreviousCustomDocument. In this example we'll use IDfFolder.
   

   public interface ICustomType extends
   IDfFolder, IDfBusinessObject
   {
   //optional custom methods
   }

3. Create a class CustomType that implements ICustomType and IDfDynamicInheritance, and
   also extends DfSysObject (or DfFolder, DfDocument, ...) if your interface extended another interface than IDfSysObject).

   public class CustomType extends DfFolder implements ICustomType, IDfDynamicInheritance
   {
   //implement optional methods you have defined in the interface
   }

4. Package the interface and implementation in 2 different jars.
5. Create JAR Definition-artifacts for the 2 jars (ie. custom_type_tbo_impl  and custom_type_tbo_inter).
   • If you have used thirdparty libraries, create jardefs for them aswell and put those in a Java Library-module.
6. Create a Module-artifact of TBO-type (give it the same name as your custom type: custom_type) and set the implementation-jardef (+ set the class) and interface-jardef + optional dependencies or required modules.
   • dependencies = if you used thirdparty libraries
   • required modules = if your TBO implementation references SBO's, TBO's or similar.
7. Install the Composer Project in the docbase.

To
view the changes (example webtop):

1. Clear your cache (delete the <tomcat>/bin/documentum/cache folder).
2. Delete the work folder (delete <tomcat>/work/Catalina)
   • not always needed, but to be safe.
3. Clear your browser cache (delete cookies, temp files, ...).

To
use your TBO in your development:

1. Add the interface-jarto the classpath of any development projects (Eclipse, Composer,...).
2. No need for the implementation-jar as you'll only work with the interface
   • Documentum returns proxy-classes that implement your interface but are not the same type as your implementation
     • interface: ICustomType
     • implementation: CustomType
     • object returned from DCTM: CustomType__PROXY

3. No need to add your jars to the classpath of the webtop-webapp.  webtop downloads them to
   <tomcat>/bin/documentum/cache/... dynamically when it needs them.

A Composer Project with an example is added to this blogpost if you want to try it out (change .txt to .zip).

I hope this
helped you out...

For more info or questions, feel free to comment, pm or mail.

Cheers,

Bart

Next Generation Documentum Clients: ECM 2.0

In the past, I've already reported about My Documentum (MyDocumentum) and Centerstage. Now, with the release getting closer, there is some more news about these clients.

General Acceptance release of both is September 1st. The release date has been pushed back, apparently due to the possible late addition of the Sharepoint Web parts to the My Documentum suite. EMC says not to be taking any chances with proper testing of the client applications...

The true innovation is CenterStage. But let's start with My Documentum. 

My Documentum Suite

My Documentum is from a functional point of view nothing new, but it is, what is nicely called, a "marketing bundle".  But a bundle with an appealing price tag.

What does the bundle contain?

• My Documentum for Outlook: The new and revamped DCO (Documentum Client for Outlook). DCO now integrates natively into Outlook and offers conflict resolution, version comparison,  preview functionalities and a bunch of new goodies.
• My Documentum Offline: The Documentum Offline Client which was freely available with D6.0 SP1. The offline client offers quite good automatic synchronization functionalities.
• My Documentum for Desktop: This is the old FSS (FS2 or File Share Services) a pretty unknown product, which made it possible to map Documentum as a file share but was a hastle to install. FSS was part of AIS (Application Integration Services), but will be taken out of that offering.
• (My Documentum for Sharepoint: The old Sharepoint Web Parts are offered with this bundle. This is not certain yet.)

The My Documentum suite is aimed at the Microsoft user, who only uses standard MS apps to access his information.

CenterStage Essentials and Pro

But the real killer app is CenterStage. CenterStage will rock the industry, if it delivers what it is promising. CenterStage will be available in 2 flavours: Essentials and Pro. Where it was first said that CenterStage was going to be aimed at collaboration and the "basic" knowledge worker, it is now apparent that over time it will replace WebTop entirely. Which is a good thing.

The catch phrase is "The New Standard for Extended Enterprise Collaboration", but it seems to be offering quite a lot more than just collaboration. It looks like the ideal client to handle several functional needs.

So now for the characteristics:

• Essentials and Pro: The Essentials version will normally be included with a content server license. The Essentials version will only offer document management and document-oriented collaboration functionalities and the aim is to replace WebTop over time. The Pro version offers Wiki, Blog, Federated Search, mobile support and a whole bunch of other goodies.
• ECM 2.0:  CenterStage not only offers Wikis and Blogs, but will also allow users to create their personal profile. That way, it will be easier to discover people's professional interests and skills.
• Flex: The user interface is flex based. It not only looks great, but it is user friendly as well.
• Contextual Search & Text Analysis: All documents are automatically indexed, analysed and categorized. That way, on performing a search, the search results can be scoped using different types of categories to which the search results apply.
• Federated Search: ECIS (Enterprise Content Integration Services), the federated search solution EMC bought from AskOnce, is going to be shipped with CenterStage Pro.
• Spaces: The old "cabinet" paradigm is replaced by spaces (Alfresco?), which allows for each space to have its own characteristics. 

In my opinion, CenterStage could become a real unified ECM client. It already combines collaboration and DMS, why not add other disciplines?

PS: Another interesting newsbit is, that EMC is finally going to build it's own search engine based on Lucene (not just simply repackaging Lucene-

Creating a Flat Panel in Flex

The Panel in the Adobe Flex lay-out containers stack is a great component. It immediately reminds users of the typical windows we get in most operating systems today, in contrast to most other container components. It's for that reason that the Panel component is very popular, and rightly so. However, there's one thing that has always bothered me while developing Flex-based applications: the main content area of a Panel.

The Default Panel

Just to remind everyone and to highlight the differences; the default Panel components that ships with the Flex 3 SDK looks a little like this:

Personally, I think the main content area (the white space) stands out too much from the surrounding border. It looks almost like it was just quickly pasted on there in a hurry. Child components are added to this white space which, more often than not, looks just weird. In an attempt to remedy this, I tried to get rid of the content area and make it look exactly like its surroundings. Like most things in Flex, it was surprisingly easy.

The MXML Way

To create a flat-looking Panel on the fly in your MXML definitions, you can add the following properties in the tag definition:

backgroundAlpha="{this.myFlatPanel.getStyle('borderAlpha')}" backgroundColor="{this.myFlatPanel.getStyle('borderColor')}"

What happens then is when the Panel is initialized, we set the content area (which is usually white) to the colour of the border. We do the same for the backgroundAlpha style property so that the content area always looks exactly like the border surrounding it, effectively creating a "flat' look.

The ActionScript Way

However, using MXML requires you to do this for every Panel you want to make flat, which adds quite a bit of overhead to your MXML files just for getting the Panel to look flat. The real power of Adobe Flex lies in the ActionScript class library behind the MXML definitions. To create a reusable flat Panel, let's use the ActionScript object-oriented capabilities to define a FlatPanel class.

The next bit of code has exactly the same effect as the MXML properties we added earlier, but this time it's done in a more object-oriented and cleaner way. All we have to do is create a new class that extends the existing Panel class and sets the appropriate style properties:

To set the actual style properties, we override the parent's updateDisplayList function. This function is called near the end of the initialisation of the component, which suits our needs perefectly. Setting these style properties earlier may result in unexpected behaviour for a number of reasons:

• the parent component's style may not have been properly initialized yet, resulting in default values being returned byt the super.getStyle function
• the parent's properties may not have been initialised at all

It's important that the updateDisplayList function of the parent Panel component is called prior to setting our own style properties for more or less the same reasons listed above. Not doing so has an undesired yet pretty funky effect.

All that's left to do is set the appropriate styles to their border equivalents and Bob's your uncle. This class can be used in exactly the same way as you would a default Panel. You can also add it to your own company's or personal component library, any project or an SWC library file and include it in all your Flex projects whenever you want. I've included my own component class as an attachment (rename the file to FlatPanel.as), have fun!

News from Momentum Prague 2008

Last week we attended the annual Documentum fest (still sounds better than the EMC Software Group fest). Great organization, long days and long nights. Reconnected with familiar faces.

But was there anything special to announce? Yes, there was.

First of all, there were a lot of things that we already knew:

• The integration of the X-Hive XML Store, which allows to finally handle XML with a good level of performance.
• An integrated solution for e-mail archiving, i.e. moving away from the current 2-lane solutions of e-mail archiving and Client for Outlook.
• A new Sharepoint integration framework, with support for journaling.

But was there anything new to talk about?  Quite a lot, in fact. Here's a quick overview of the most important newsbytes:

Architecture

There wasn't a lot to announce in this field, since the platform has heavily changed with D6. D6.5 and D7 will mainly focus on new user interfaces.

• EMC is going to work on Documentum Solution Frameworks. As it was announced, it is supposedly going to be off-the-shelf solutions for specific user needs. These "frameworks" would be easy to configure to the user environment. A first of these frameworks, aimed at case management, would be released second half of 2009. Several EMC consultants and representatives had never heard about this initiative before when Mark Lewis made the announcement. We'll see... Maybe, it might be something like our own docTools.
• Flex is the future. TaskSpace, Flex components and other components will be interchangeable in the different client interfaces. In a first phase that is. Between the lines, it was obvious that WDK will be disappearing in a future not that far away.

Transactional Content Management (BPM & Capture)

• High fidelity forms: Create forms with the look & feel of a Word processor.
• In flow scanning: Web based scanning integrated in TaskSpace
• "webHTML" (no official name yet): End 2009 (or later) there will finally be a possibility to publish your forms to the web and reintegrate the form in your repository/process.
• The future of Captiva looks bright. Captiva is beginning to capitalize on its stronger architecture (in comparison to its main competitors).

Interactive Content Management (DAM & WCM)

• Site Caching Services: 2-way publishing allows to reintegrate data generated on the web site in the repository (e.g. user feedback)
• Site Caching Services: The new Site Caching Services supports "webXML", publishing to an online XML store. Making Documentum WCM the ideal solution to integrate with a high-end CMS.
• Media Workspace: DAM and Page builder (the nifty Flex based interface for creating web templates released with 6.5) integrated into a single, sexy interface
• Web Publisher: Web 2.0 functionalities added
• There is no replacement for Site Delivery Services (ContentCaster) yet, but they're working on it.

Knowledge Worker (DMS & Collaboration)

• As we already knew, Documentum Client for Outlook and MyDocumentum (the offline client) have been postponed to January 2009.
• The MyDocumentum, FileShareServices and
  Documentum Client for Outlook products will be merged into a single product:
  MyDocumentum.
• The advanced version of CenterStage will be officially named Pro and will be available with the 1.5 release. The Essentials version basically only offers Basic Content Services, the Pro version will also offer Wikis, Blogs, etc.
• CenterStage 1.0 will be released somewhere first half of 2009 (one presentation said februari, the second one april and the third one "first half of 2009).
• CenterStage 1.5 Essentials and Pro will be released (if all goes well) September 2009.
• The D7 release of CenterStage Pro should comprise all functionalities that can be found in eRoom.
• CenterStage Essentials will be heavily promoted as the interface of choice for standard users.
• CenterStage will boast quite a decent support for mobile users; Blackberry will be the first device to be supported and the iPhone is the next in line to be supported.
• Unofficial:
  • CenterStage Essentials will be free for WebTop customers.
  • eRoom customers will get CenterStage Pro free of charge.
  • The migration tool to migrate from eRoom to CenterStage (RedCarpet) will be free of charge.

There was nothing new to announce (or we might have overlooked it) in the Compliance & Archiving suite. 

See you next year in Athens, giving us plenty of time to be catching up on sleep.

Why CMS is not ECM (or WCM)?

Although I've had my own theory about the difference between CMS and WCM for years, I've never come across any other source that clearly explains the difference between both acronyms. This has cost several business 100.000s of euros and is going to cost them several 100.000s of euros in years to come. 

Not everyone will agree with this article, but a lot of users might benefit from having a clear view on the distinctions between both.

The Rise of WCM

The mid 90's saw the rise of the first WCM (Web Content Management) solutions. They allowed for non-technical users to contribute content to the web via templates. Other major companies, such as Documentum and FileNet, jumped on the bandwagon around the turn of the century. These weren't native WCM solutions but, with some expansions to the core product, they could offer most of the same functionalities existing WCM players (Vignette and Interwoven) were offering. This effectively created ECM (Enterprise Content Management), as you could now manage content with a different purpose from a single repository (this must have been around 2001, the year of my first WCM implementation).

Enter CMS

The .com-hype (and in some cases regulatory reasons) caused for a huge popularity of these WCM solutions. The hype cooled down quickly for several reasons: too costly, long implementation cycles, bad user experience, etc.  This was also due to the rise of a new phenomenon: the CMS.  The CMS seemed to be able to offer a set of functionalities and a user experience WCM was unable to deliver. Especially marketing and communication departments were longing for these new functionalities (let's forget about portals for the moment, what has happened to portals anyway?).

Several companies abandoned their WCM solution and shifted their attention to CMS. At a certain point in time it seemed as if every web agency, web designer and even traditional integrator had become a CMS development companies.

Former pure-WCM vendors Stellent (now taken over by Oracle) and Vignette expanded their capabilities to become ECM-platforms in an attempt to lure new customers.

CMS: Not the holy grail?

But still, in several cases a CMS wasn't able to resolve the business requirements. There is a general misconception in the market (certainly the Belgian market) about the difference between WCM and CMS. CMS integrators generally don't know what a WCM is supposed to do, because their background is traditionally not in the field of ECM. 

Therefore, it might be useful to clearly define both acronyms. Plenty of businesses might benefit from this, as it might help them to better evaluate and choose the solution(s) for their requirements.

Which one is which and what does what?

There are hundreds CMS'es out there, so I'm not going to describe the characteristics of every CMS out there. The CMS Matrix has a pretty extensive list of CMSes with their functionalities, but it is still not complete... due to reasons mentioned above. 

Below, I'll give a set of core differences/characteristics between/of WCM and CMS.

(These two terminologies might be useful in order to be able to interpret some of the statements below:

• Back-end: User interface and platform used for editing and managing the content / information
• Front-end: Interface used by website users to consult the information

)

   CMS:

• Front-end and back-end use the same technology (PHP, .Net, Java, etc.)
• Content is very often stored in a database; The same database is used by front-end and back-end. Generally back-end and front-end are installed on the same machine.
• CMS offers advanced front-end functionalities:
  • Front-end user management
  • Blogs
  • Wiki
  • Front-end search
  • WYSIWYG web-editing *1
  • Is generally used for pure web content

   WCM:

• Front-end and back-end are technologically independent *2
• The data and database are generally not shared by the front-end and back-end (some WCM systems offer this option)
• A WCM generally publishes the information, i.e. the content and data are pushed to the front-end
• Multiple targets can be used for publishing, generally there is at least a staging environment and a production environment
• Different targets can use a different look & feel
• Advanced version control
• Content can be more easily multi-channeled, multi-purposed, multi-site and multi-lingual.
  The level of multi-purposing is logically higher when the WCM is part of an ECM platform, i.e. the content is not only made available via the web

When to use WCM or CMS?

The answer to that question depends solely on your requirements, but nothing keeps you from implementing a combination of both. Such a combination helps you in more rapidly creating your front-end (website) and allows you to manage your pure web content via the CMS. This architecture allows your communication team to keep their hands on the CMS, while content from other business user might be delivered via the WCM system.

The image below shows what such an environment might look like:

Of course, such an architecture imposes additional technical requirements on the WCM and CMS of your choice.

The future of WCM

Several of the WCM products have expanded their functionalities by
offering site templates, microsites, pagebuilders, blue prints, etc. in
order to reduce the time required to deploy a WCM solution. Only
one moved on to become a true WCMS, offering both WCM and CMS
capabilities (unfortunately, this is not an ECM platform). 
Several of the traditional WCM vendors now also offer, via several techniques, RSS, marketing management, WYSIWYG editing.

I've seen (things you people wouldn't believe. Attack ships on fire... stop!) WCM platforms that were turned into bad CMSes with the front-end accessing the back-end. CMSes that were fitted with a repository to try multi-purpose the content.

I hope that this article might prevent such abominations in the future.

Oh, so why is CMS not ECM?  It has been mentioned implicitly several times above: A CMS only manages web content.

(FYI, this site is powered by a Drupal CMS.)

*1 WYSIWYG web-editing is mimicked by some WCM platforms

*2 Sharepoint WCM can not be considered as a pure WCM, since the front-end and back-end are not techologically independent. 

The Wiki

As you might have noticed, if you've clicked on the wiki link at the top of this page: The wiki doesn't seem to be a part of this site. Correctly so!

We've started the ECM Handbook in an effort to create a community and one central resource in relation to Enterprise Content Management. For several reasons we think the time is ripe to start building some sort of central memory of ECM. Among those there's our concern for the "ECM knowledge gap".

We can identify several causes for this knowledge gap:

• ECM keeps ever expanding. The original 5 disciplines have been multiplied by 4 and new disciplines are being added every year.
• With the passing of time, the functional knowledge related to each of these disciplines is out of reach of most present day consultants. 

We hope that the ECM Handbook can assemble functional information about each of the disciplines and on the other hand offer funtional -and technical product comparisons, thus reducing the time that should be invested in preliminary research for people looking into implementing an ECM solution and shifting the focus to the user and his needs.

It is our hope that the ECM Handbook will soon be a proper site and community in its own right. The Wiki is currently referred on our website to get it known in the community, but as you'll notice the wiki user management is not linked to the user management of this site.

Success in ECM

On the 25th of September, Docbyte is attending the Congress Innovations@DocumentManagement. I'm giving a presentation about how you can make the best of your ECM implementation, based on the experience we have in this field.

The key reasons for ECM project failures are taken from the AIIM website. The major interesting fact about those key reasons for ECM implementation failures, is that non of these reasons are directly technology related, as many of us ECM professionals have known for quite a while.

The main reasons are related to issues about lack of knowledge, sponsorship and change management:

• Sponsorship shift due to long implementation cycles.
• Unsufficient knowledge, in regard to ECM, by user and implementator, due to feable training,   insufficient experience and lack of change management.

In regard to the above, I'd also like to discuss the knowledge gap.

There are reasons for these failures that are common with regular IT-project failures, but there are quite a few that are specific to ECM-implementations. 

The subject of my presentation at the Congress is about what is needed to turn your ECM-implementation into a success, i.e. what is required to tackle the main reasons for a failure?

I'll post some more information about this subject after the congress.