Escolar Documentos
Profissional Documentos
Cultura Documentos
Abstract: This document highlights the technically obscure areas of Content Server to facilitate
Developer Support assignments.
Date 3/15/2007
Copyright © 2007 EMC Corporation. All rights reserved.
EMC believes the information in this publication is accurate as of its publication date. The information is subject to change without
notice.
THE INFORMATION IN THIS PUBLICATION IS PROVIDED “AS IS.” EMC CORPORATION MAKES NO
REPRESENTATIONS OR WARRANTIES OF ANY KIND WITH RESPECT TO THE INFORMATION IN THIS PUBLICATION,
AND SPECIFICALLY DISCLAIMS IMPLIED WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR
PURPOSE.
Use, copying, and distribution of any EMC software described in this publication requires an applicable software license.
EMC2, EMC, and EMC Documentum product names are trademarks of EMC Corporation. All other trademarks used herein are the
property of their respective owners. All other brand names are trademarks or registered trademarks of their respective owners.
The Content Server process orchestrates the entire function of repository. When a client invokes a method
server call, it delegates the call (based on the method) to appropriate execution agents. The Content Server
version 5.2.5 and 5.3 has three execution agents:-
1) Content Server
2) Docbasic method server
3) Java method server
The methods can be a Docbasic script, Java class or a self executable program written in another
programming language such as C++.
For every method, we have to create a method object of type dm_method. The attributes of that method
object will define arguments and the execution parameters. Methods are executed by issuing a
DO_METHOD administration method or using a job. Using a DO_METHOD allows you to execute the
method on demand. Using a job allows you to schedule the method for regular, automatic execution.
Not just any Visual Basic application can run as method. The rules are the same for development in Visual
Basic as well as Docbasic or GAWK. You can NOT have any graphical user interface in a method. The
process runs on the server host and there is no way to interact with it from the client. Also, you must make
the program a command line executable that accepts the necessary parameters at the start of execution.
buff = "connect," & docBase & "," & UserName & "," & ticket
sess_id = dmAPIGet(buff)
' If any error occues then: Call Connect_Handler()
End Sub
'
' Handle and report any errors
'
Sub Error_Handler (sess As String)
buff$ = "getmessage," & sess
mesg$ = dmAPIGet(buff$)
print "Message: ";mesg$
Stop
End Sub
'
' Retrieve any connection related information
'
Sub Connect_Handler ()
buff$ = "getmessage,a"
mesg$ = dmAPIGet(buff$)
print "Message: ";mesg$
Stop
End Sub
The java methods are executed as Servlets under Tomcat Application Server. So we can invoke many
instances of the method without spawing multiple instances of JVM process, each of which running an
instance of the method. This will save lot of memory and processing resources and provide performance
benefits. The benefits are same like running a Servlet instead of running a CGI application.
Java method server runs as an independent process. It can be stopped or started without recycling the
content server. In Windows platform, method server can be run as a Windows service or as a process.
A common mistake
The Tomcat provided with Content Server to run Java method is not a full blown Tomcat. It has been
customized by eliminating many features, so it is not suitable to work as a generic Servlet container. Often,
a customer may deploy a WDK application on this Tomcat and run into issues. Such deployment will not
work and unsupported by Documentum.
import java.util.*;
import java.io.OutputStream;
import com.documentum.mthdservlet.IDmMethod;
import com.documentum.fc.client.*;
import com.documentum.fc.common.*;
} catch (DfException e) {
ostream.write("A DfException occurred".getBytes());
ostream.write(e.getMessage().getBytes());
e.printStackTrace();
// spit out to stderr as well throw e;
} finally {
1) Compile the Java method. Note that if you make changes to the workflow method, you must re-
compile the method and restart the Java Method Server for the changes to take effect.
2) Stop Tomcat, if it’s already running.
3) Start Windows Explorer and change to the following directory:
%DOCUMENTUM%\dba\java_methods. This directory represents the location for all java
methods that you develop, and which are executed by a Documentum supplied servlet called
DO_METHOD on the application server.
4) Copy the java method class to deploy into this folder.
5) Restart the Tomcat application server.
6) Connect to your Docbase using Documentum Administrator.
7) Click Administration > Job Management > Methods in the left pane.
8) Click File > New > Method from the drop-down menu to create a new method.
9) In the Name field, enter your custom method name Do not use the format dm_methodname to
name the method. This naming convention is reserved for default Documentum objects.
10) In the Verb field, enter DmSampleMethod. Note: The method_verb attribute must correspond
to the same Java class used in Tomcat. For other type of methods, the method verb is the
command-line name of the procedure or the name of the interpretive language that will execute the
program file. It is a good practice to specify the fully-qualified class name of the Java class as the
command verb. If your class is contained with a jar file then you must specify the fully-qualified
class name. For example;
com.documentum.bpm.bpsintegration.bps.DmBPSHTTPIntegration
11) Select java as the Method Type.
12) Check Run As Server. If checked, it indicates that you want the method to run as the installation
owner account, with the installation owner’s privileges. Otherwise, the method runs as the user
creating the method, with that user’s privileges. The default is unchecked. Run as Server must be
checked to execute a method on the method server or application server.
13) UnCheck Launch Direct. This controls whether the program is executed by the operating
system’s system or exec API call. If checked, the server uses the exec call to execute the
The figure below shows a typical entry in method object for a Java method
-otrace_method_server
Tracing information generated by Content Server is stored in the server log file. Tracing information
generated by the method server is stored in the method server log file. The log file is stored in
%DOCUMENTUM%\dba\log\<repository_id>\MethodServer\MethodServer\server_config_name.log
or
$DOCUMENTUM/dba/log/<repository_id>/MethodServer/MethodServer/server_config_name.log
<init-param>
<param-name>trace</param-name>
<param-value>t</param-value>
</init-param>
The web.xml file is found in %DM_HOME%\tomcat\webapps\DmMethods\WEB–INF\web.xml
($DM_HOME/tomcat/webapps/DmMethods/WEB–INF/web.xml).
The log files generated by the Java method server are stored in
%DM_HOME%\tomcat\logs ($DM_HOME/tomcat/logs).
Order of starting index sever and java method server do not matter. For shutdown, follow the
reverse order.
If not restart it. Navigate to the $DM_HOME/tomcat/bin/ directory and run startup.sh script for UNIX.
For windows
Click Start-->Programs-->Administrative Tools-->Services.and start java method server
The Tomcat server used for the method server can be configured to reduce the number of simultaneous
threads active. This could theoretically provide some flow control by limiting the number of methods that
can simultaneously be executed. Unfortunately it appears error handling in the Content Server for
asynchronous methods is rather weak. If the Java Method Server is already processing all the simultaneous
methods that it is capable of, all new requests get discarded. The application never knows that its method
requests were discarded.
Please note asynchronous method execution can overload the server and may cause substantial delay in
execution of the method.
When switching to synchronous method execution there are still problems. Under heavy load the
"DO_METHOD" calls will fail with a rather vague error message. It is up to the application to decide that
the server is under heavy load and therefore should just keep retrying the method submission until the
server has bandwidth to service it. As it stands now the user requests simply fail when the server gets busy.
Challenge Questions