Archive

Archive for November 1, 2010

Integrated Document Management Solutions

November 1, 2010 Comments off

Document management is defined as a system for controlling the capture (when created or received), classification (cataloguing), storage, retrieval, revision, sharing and reuse, protection, archiving of documents.  Documents include electronic and non-electronic objects.  Electronic objects include softcopy documents, e-mail, imaged material, e-fax etc. Non-electronic objects include paper, documentation, photographs, maps etc. The common processes of Integrated Document Management systems include :

  • Capture/Receive documents – document is received from an external source (could be electronic or physical papers)
  • Generate/Create – Document is created internally within the document management system
  • Indexing – facilitate identification of document by applying context relevant metadata to it.
  • Document formatting – convert the electronic document into appropriate format, like .pdf, .tiff etc
  • Store documents – document is stored in an online media (we are assuming that the IDM solution is electronic storage of all documents)
  • Retrieve documents – document retrieval facility for viewing and editing
  • Document Versioning – to be able to maintain multiple versions of document
  • Document manipulation – to be able to move and delete documents
  • Security – document need to be secured depending on the business and legal requirements
  • Workflow management – it’s an optional feature. Documents need to be routed to appropriate user groups based on the workflow
  • Archiving & Long term storage – document management system should provide scheduling feature to schedule document archival. The archiving could be a different storage location like CDs, microfilms or some hard disks
  • Long term retrieval of documents – document is retrieved as needed during its archived status from whatever the archival storage location
  • Purge/Dispose documents – documents need to be deleted when its no-longer needed

Will try to bring more about IDM in brief may be with a diagram in my next Post.

Enabling Logging in DFC Applications

November 1, 2010 Comments off

Log4j is a Java based logging utility primarily used as a debugging tool. It’s an open source project of Apache Software Foundation that provides a reliable, fast and extensible logging library for Java.

Dflogger is a Documentum DFC class (available with version 5.1 and higher) that can be used to enable logging from DFC Applications. This post describes how to configure and use the logging library from DFC.

Enabling Logging:
Let us have a look at how to enable logging for a java application.
Open the $DOCUMENTUM/config/log4j.properties file (created during the DFC install itself). And, enter the following lines of code at the end of the file and save it.
# Enable log messages for a custom class
log4j.logger.com.documentum.custom.webui=DEBUG,WebUI
#WebUI Appender
log4j.appender.WebUI=org.apache.log4j.RollingFileAppender
log4j.appender.WebUI.File=C\:/WebUI.log
log4j.appender.WebUI.MaxFileSize=10MB
log4j.appender.WebUI.layout=org.apache.log4j.PatternLayout
log4j.appender.WebUI.layout.ConversionPattern=%d{HH:mm:ss} %p %c %m %n

Let us have a look at each of the lines that we have appended to the properties file.
Line 1 : log4j.logger.com.documentum.custom.webui=DEBUG,WebUI
This line specifies the following:
a) the package/class being logged,
b) the priority level – 5 levels of priority are defined in log4j (DEBUG,INFO,WARN,ERROR & FATAL). In our example, we have set it to DEBUG resulting in all messages being logged.
c) the name of the Appender. Log4j allows logging requests to print to multiple destinations. In log4j jargon, an output destination is called an appender. Currently, appenders exist for the console, files, GUI components, remote socket servers, JMS, NT Event Loggers, and remote UNIX Syslog daemons. It is also possible to log asynchronously. We have named our appender WebUI. Lines 2-6 are for configuring the appender.
Line 2 : log4j.appender.WebUI=org.apache.log4j.RollingFileAppender
This line specifies the type of appender to use. RollingFileAppender backs up log files once they reach a max size(specified by the next line).

Line 3 : log4j.appender.WebUI.MaxFileSize=10MB
This line specifies the maximum size of the log file. Once the file reaches this size, the appender backs it up and creates a new log file.
Line 4 : log4j.appender.WebUI.File=C\:/WebUI.log
This line specifies the name of the log file to be created as well as its location. In case the location is not specified, then the log file gets created in the location of the executing class.
Line 5 : log4j.appender.WebUI.layout=org.apache.log4j.PatternLayout
This line specifies that a pattern layout is being used
Line 6 : log4j.appender.WebUI.layout.ConversionPattern=%d{HH:mm:ss} %p %c %m %n
This line specifies the interpretation of the pattern layout. The conversion pattern used here is as follows :
%d{ HH:mm:ss}–date and time of logging, %p- priority level of the message, %c- name of the category (i.e the class/package name),%m- the message, %n- newline character.
Others that could be used are: %t – name of current thread, %F – java source filename, %C –java class name, %M – java method name, %L – java source line number

Now, execution of any of the classes in the webui package will result in the creation of a file called WebUI.log in the specified location (see the entry ‘log4j.appender.WebUI.File’). This is the file into which all the log statements would be written to. But, the log statements cannot come out of thin air, we need to insert a call to DfLogger in our DFC code.
Using DfLogger
To log a message in the log file, we need to insert a call to the DfLogger class in our DFC code. The signature of the method is as follows:
DfLogger.debug(Object arg0, String arg1, String[] arg2, Throwable arg3)
Object arg0 : specifies the class for which the debug message is being logged. Usually, the DfLogger class is called from the class for which we log the message and hence we use the ‘this’ keyword. It refers to the current class instance.
String arg1 : the message to log
String[] arg2 : parameters to use when formatting message
Throwable arg3 : a throwable to log ,can be used to print a stack trace to the log file in case of an exception.
Ex: DfLogger.debug(this,”The Debug Message”,null,dfe);
If we need to print the stack trace of any exception in the class, we need to pass the instance of the Throwable class as the fourth argument.

Ex: catch(DfException dfe){
DfLogger.debug(this,”The Debug Message”,null,dfe);
}
The Outcome
Say, these are DfLogger class calls in our custom code :

DfLogger.error, DfLogger.fatal, DfLogger.info, DfLogger.warn are the method calls to log messages in that priority.
Then, when the user clicks on the link called search, the message gets logged in the log file as follows :

Note the conversion pattern. Also, since we have given the priority level as DEBUG in the properties file, it’s printing out all the log messages i.e other than DEBUG ones. Had we given FATAL (which is the highest level), then only the message for the call DfLogger.fatal(..) would have got logged.

Just a small configurational change and this could go a long way in helping a developer trace the root cause of any issue, understand the application, track the control flow in the application etc. But, one thing needs to be taken care, increasing the number of log messages in an application could bring down its performance.

%d bloggers like this: