Armedia Blog

Archive for the ‘Documentum Development’ Category

Think Alfresco from Documentum perspective –Take 1

July 14th, 2010 by Balaji Sampath

Open Source ...</ins>

When you work for a while in the software you get numbed to “technologies have come and gone…” occasionally though some become commodities and others trend setters. We have seen that with many products like Apache, Tomcat, Lucene, Drupal …etc that have stabilized and matured over the past years with the help of increased development from the open source realm. Wait! Did I mention the word “Open Source” and going to talk about the enterprise content management?

So without any more ado, we have Alfresco- catering to a rapidly increasing demand of the enterprise content management solutions which is built over the open source technologies such as Spring, Hibernate, and Lucene platforms. Having done years of Documentum development and several Alfresco projects of late, I think there are some interesting overlaps and differences of approach that I feel would make the developers get adapted quicker.

With the wiki site overwhelmed with Introduction, API’s, Development, Deployment and the Forums to answer all the questions regarding the issues faced during the project phase, I am here to talk purely from the developers perspective on what’s the key areas that I happen to witness the difference from the Documentum space.

The road map for my next series of blog is going to cover each of the areas mentioned below in more detailed, code abundant and developer centric approach which will answer the questions:

  • Does this feature exist in Documentum or Alfresco or both?
  • If yes, how different is the approach?

So with that preamble, and in no particular order, I give you my list of the key areas I got hands on and learnt how different Alfresco is:

Custom data model is the core for any enterprise content management solution. The use of “Aspects” as its core is the fundamental concept for content modeling in Alfresco. Although in the form D6, aspects was introduced, how different is the use and approach in Alfresco is something I will take a deep dive in my next blog.

Alfresco Web Scripts brings together the world of content repository and the web. Being a Documentum developer earlier ways of interaction with the repository have been either using DFC API’s or DQL. In Alfresco, Web Scripts provide RESTful access to content within the repository and we can build our own interface using java script. A custom move operation is implemented using the Web Scripts and the comparison of the implementation with the Documentum would be a something to be noted.

On my last project, we had requirements for the customers to be able to permanently redact Personally Identifiable Information (PII) from existing documents stored in the repository and version the original document upon save. For various reasons, we decided to integrate the 3rd party tool Daeja ViewOne module to provide this capability. I will discuss the topic as part of this blog series.

I started this series based on my experience implementing Alfresco projects and I invite you to share any of your experiences with any part of the road map wherein you run into interesting twists and turns? Did you drive off the road to get some help? I welcome your feedback as the blog takes its shape. See you all soon in Take 2.

Documentum-Composer

July 6th, 2010 by Aparna Thimmavajjala

It was year 2004, when I was first introduced to EMC Documentum. As I first fired up the DAB IDE, I felt man this IDE is Unintuitive, slow and cryptic. Apart from learning the DFC API’s in Documentum, getting accustomed to DAB itself was an excruciating experience. Finally after three years Documentum Composer came as a savior.

I liked Documentum Composer for 3 main reasons:

1. It has better interface than DAB, and its easy to use providing support for keeping multiple projects open at the same time. You need not checkout and checkin the artifacts every time you make any changes only thing you will be doing is installation of the project.

2. It comes as combined feature of both DAB and DAI where in you create the DAR and install from the same IDE into a repository.

3. Composer is built on the Eclipse platform, and the installation includes a bundled Eclipse environment. One of the benefits of the Eclipse platform is that it offers a number of paradigms that are familiar to developers thus allowing users to identify the issues at the DocApp development level instead of installation level.

Composer helps to develop applications faster and easier by reducing the learning curve through user interface consistency and the familiar standards-based Eclipse tooling framework. Composer can be run in “headless Eclipse mode”, which enables command-line scripting and automation of project installation. This feature provides self-contained, fully automated deployment of projects into a repository, without the need for a previous DFC installation or DMCL client.

One thing that I like about Composer is the ability to install into multiple repositories, assuming they share a connection broker, without restarting and on the other hand ability to work offline. To install the application or migrate the data model a user would use DAI to install the docapp archive into one or more production Docbases, where as with composer you can do both the task in one single place without the need of DAI to deploy.

It is both an artifact project, supporting artifact development, and it is also a DFS project, supporting consumer and service DFS development.

Another feature that I liked about Composer is the ability to deploy java methods as BOF module without the need for the user to copy the class files under /dba/java_methods folder in the CS location and to be able to deploy on the java method server without having to bring down the content server. Also when Business Object Framework (BOF) came out in 6.0, DAB was extended to support creation of modules which served as “container” for custom BOF code.  However, you still had to have a java environment to build JAR files that contained BOF code.  In addition, any customizations to WDK/Webtop were not supported in DAB.  The WAR build and deployment process was entirely separate from docapp installation process. Composer is an effort by EMC to come up with a single tool that help developers to Configure Documentum artifacts, Create Business Objects, Build DFS Services, Deploy Documentum applications across multiple repositories.

Once you begin using Documentum Composer the benefits are easily evident. To name a few:

  • Developing applications quickly and easily
  • Learning curve is reduced due to the consistency of user interface and familiar standards of Eclipse tooling framework

Personally I consider composer a great gift to the Documentum developer community.

Retention Policy Consolidation

June 28th, 2009 by Chris Schassler

One of the often overlooked challenges of electronic records management is the control and maintenance of retention policies.  This is particularly difficult if you are faced with a large number of members in your organization’s different record series categories.  Managed separately this means one retention policy for each individual record type.  If you only have a few different types of records to manage this is not such a big problem but it is especially difficult when you are dealing with hundreds of different types.  Additional complication comes in when you are managing permanent records that need to be archived to another organization such as NARA (National Archives and Records Administration). 

Careful consideration should be taken when creating an electronic retention policy design because trying to manage and control hundreds of retention policies that can have the tendency to change can become unmanageable very quickly.  The support and maintenance cost along with the compliance risk can eliminate your ROI and create a solution that fails to meet the goals for which it was designed.

One way to simplify and try to reduce the overhead associated with managing so many different policies is to group schedules together within your series according to their function or another applicable categorization scheme and their dispositions. 

The following basic strategy is an example of how this can be accomplished:

  • Create “buckets” representing the high-level record series areas.
  • Group record series members within the “bucket” into categories based on function and comparable disposition schedules.
  • Define and assign a common disposition strategy to each functional area that is representative and compliant for all record series members.

This concept is probably better understood using a simple example, lets use the following scenario as an illustration:

  • You have 5 different high-level record series groups.
  • Each series group has 100 individual members.
  • The schedule for each member ranges from temporary dispositions of 1 month to 10 years to permanent records with a duration of 25 years or more.
  • Each of the record series contain members that share a common purpose or function.

Using this example some basic consolidation steps would be:

  1. Define each high-level record series group as a separate “bucket”.
  2. Within each bucket you can create categories based on function such as whether the members are administrative, case related, procedural, etc.
  3. Within each of these sub-groups you would start to combine your applicable members based on corresponding disposition schedules.  For example, within a record series “bucket” if you have 25 members that are administrative records and they have temporary dispositions with durations ranging from 3 months to 5 years you can create a single retention policy with a disposition strategy of destroy/delete after 5 years and include each of these members under the policy.  By doing this you only need a single policy that can apply to 25 members instead of having 25 separate retention policies.
  4. Follow a similar process for each high-level record series and you can turn, what was in the case of our example, 500 individual retention policies into a number that is much more manageable making it easier to control and disposition your formal records.

Some items to take into consideration when consolidating retention policies are:

  • Work with your records managers and any outside agency, such as NARA, you archive records to before implementation, make sure you have their buy-in for the initiative.
  • Identify the special record series members and handle them separately with their own policy as needed to help reduce compliance risk.
  • When grouping record series members within a retention policy based on disposition schedules be wary of regulations that can be applied, it is generally best practice to only hold certain records for as long as necessary and no longer.
  • Designing an automated process for declaring formal records which will reduce workload and provide a better user experience for your records contributors/managers.  If you have or choose to implement an automated formal records declaration process you can provide more flexibility and room for growth by using an XML file or table to map the individual record series members to their applicable location in the formal file plan where the retention policy has been applied.
  • Consider structuring/restructuring your formal file plan after the consolidation strategy and apply your retention policies at the applicable level and allow the policy to be inherited by all formal records within that section of the file plan.

This information is an example of how retention policies can be simplified but in practice it is best to err on the side of caution.  Make sure you have the right people involved and do not put yourself at risk.  The goal is to reduce your overhead while minimizing risk and maintaining compliance.  You probably made a significant investment in your electronic records management solution and you need to be sure to keep the protection and savings that a solid design provides.

Producing Quality Given Time Constraints

June 6th, 2009 by James Bowling

The schedule is an ever present aspect of application development. Engineers must constantly balance producing quality work against given time constraints. This is why most engineers are constantly searching for tools and techniques that allow them to deliver more quality work in less time. Techniques, like software patterns, focus on the quality aspect of the software while many tools focus on productivity. When an engineer finds something that allows him/her to both increase productivity as well as improve the quality of work delivered, it deserves special attention.

Code Generation is writing code that writes code. When used properly, it can dramatically reduce coding time. It also stands to reason that a greater degree of thought goes into the generated code and that it is likely of higher quality than an equivalent body of hand written code.

In layered software development, one area that is ripe for code generation is the data access layer. The DAO/DTO pattern is a well known and used in the industry. Couple that with the fact that most data stores provide self-describing features for the data structures and it provides a perfect opportunity to utilize code generation.

Enter Armedia CodeGen. It generates DAO’s and DTO’s for Documentum types. It utilizes DQL within the DAO’s for optimal performance (see Rahul Raina’s May 24th, 2009 blog article). It generates JUnit test cases to verify the CRUD (create, read, update, delete) frunctionality for the generated DAO’s. Having test cases to verify/validate the data access code verifies the code is in sync with the objects and their attributes in the repository. It is highly unlikely that a project hand-coding data access would afford the time to write test cases for the data access layer.

In a Documentum application with a large number of custom types, Armedia CodeGen can dramatically shorten development time, while providing more consistency and quality than will be achieved by hand-coding. For a limited time, the Armedia CodeGen is available as a free trial. Visit http://www.armedia.com/products/generator.htm and follow the forum link.

JB