developing a documentum web application - dell emc · we define a component as being all of the...

Developing a Documentum Web Application

1

Developing a Documentum Web ApplicationFeaturing Documentum Web Development Kit 4.2


2

Table of ContentsOVERVIEW ....................................................................................................................................................................................4

USER INTERFACE DEVELOPMENT..................................................................................................................................4

1.0 WEB DEVELOPMENT KIT (WDK)................................................................................................................................4

1.1 PRODUCT GOALS ................................................................................................................................................................... 51.2 BENEFITS................................................................................................................................................................................ 51.3 THE TOOLKIT ......................................................................................................................................................................... 61.4 SOFTWARE REQUIREMENTS................................................................................................................................................. 7

2.0 WDK 4.2 ARCHITECTURE...............................................................................................................................................7

2.1 WHAT IS A WDK COMPONENT?.......................................................................................................................................... 72.2 CONFIGURABLE APPLICATION FRAMEWORK.................................................................................................................... 8

2.2.1 Actions and Action Service .........................................................................................................................................92.2.2 Configurable Menus.....................................................................................................................................................92.2.3 Configuration Service................................................................................................................................................102.2.4 Qualifiers......................................................................................................................................................................10

3.0 WDK 4.2 COMPONENTS..................................................................................................................................................11

3.2 EXAMPLES OF WDK 4.2 COMPONENTS........................................................................................................................... 113.2.1 Checkin, Checkout, Cancel Checkout.....................................................................................................................113.2.2 Import............................................................................................................................................................................113.2.3 Inbox .............................................................................................................................................................................123.2.4 Properties.....................................................................................................................................................................133.2.5 Basic and Advanced Search......................................................................................................................................133.2.6 VDM ..............................................................................................................................................................................143.2.7 Workflow ......................................................................................................................................................................16

3.3 OTHER FEATURES................................................................................................................................................................ 173.3.1 Configurable Content Transfer ................................................................................................................................173.3.2 Multiple Selection Support (Checkboxes) ..............................................................................................................173.3.3 Multiple eContent Repository (Docbase) Support ................................................................................................17

4.0 WEB DEVELOPMENT STANDARDS..........................................................................................................................17

4.1 JAVA DEVELOPMENT .......................................................................................................................................................... 174.1.1 JSP.................................................................................................................................................................................174.1.2 Servlets .........................................................................................................................................................................174.1.3 Java Classes ................................................................................................................................................................18

4.2 APPLICATION SERVERS....................................................................................................................................................... 184.3 INTEGRATED DEVELOPMENT ENVIRONMENTS............................................................................................................... 18

5.0 J2EE COMPLIANCE FOR WDK 4.2 ............................................................................................................................18

5.1 J2EE BLUEPRINT ................................................................................................................................................................. 18

6.0 INTERNATIONALIZATION...........................................................................................................................................19

6.1 WHAT IS INTERNATIONALIZATION? ................................................................................................................................. 196.2 WHAT IS LOCALIZATION?................................................................................................................................................... 19

6.2.1 Locales..........................................................................................................................................................................206.2.2 Language selection.....................................................................................................................................................20

6.3 FONTS, CHARACTER SETS, AND ENCODING ..................................................................................................................... 206.3.1 Fonts .............................................................................................................................................................................206.3.2 Character sets and encoding (codepage) ...........................................................................................................216.3.3 Client display limitations..........................................................................................................................................22


3

6.4 ECONTENT SERVER SUPPORT ............................................................................................................................................. 226.4.1 Supported encodings..................................................................................................................................................226.4.2 Attribute field limitation............................................................................................................................................236.4.3 DMCL initialization of client codepage .................................................................................................................236.4.4 Localized data dictionary labels..............................................................................................................................23

7.0 WDK 4.2-POWERED SAMPLE APPLICATIONS....................................................................................................23

7.1 WDKSPACE ......................................................................................................................................................................... 247.2 WDKAUCTION .................................................................................................................................................................... 25

LEVERAGING BUSINESS LOGIC......................................................................................................................................25

8.0 DOCUMENTUM FOUNDATION CLASSES (DFC).................................................................................................25

8.1 INTRODUCTION TO DFC...................................................................................................................................................... 268.2 PACKAGES............................................................................................................................................................................. 268.3 DFC PROGRAMMING.......................................................................................................................................................... 27

CUSTOMIZING THE DATA MODEL.................................................................................................................................30

9.0 DOCUMENTUM DEVELOPER STUDIO....................................................................................................................30

9.1 WHAT IS DOCUMENTUM DEVELOPER STUDIO?.............................................................................................................. 319.2 FUNCTIONALITY .................................................................................................................................................................. 319.3 DDS AND WEB CLIENT ...................................................................................................................................................... 319.4 WORKFLOW MANAGER...................................................................................................................................................... 32

SETTING UP AN XML APPLICATION.............................................................................................................................32

10.0 XML........................................................................................................................................................................................32

10.1 ROLE OF XML IN CONTENT MANAGEMENT ................................................................................................................. 3210.2 XML SUPPORT IN DOCUMENTUM .................................................................................................................................. 3210.3 NEW CLASSES IN DFC...................................................................................................................................................... 3310.4 AUTHORING AND PARSING XML IN DOCUMENTUM ................................................................................................... 3310.5 WHAT IS AN XML APPLICATION?.................................................................................................................................. 34

10.5.1 The XML Application Folder .................................................................................................................................3410.5.2 XML Application Configuration File....................................................................................................................3410.5.3 The DTD or Schema .................................................................................................................................................3510.5.4 Application Support Documents............................................................................................................................35

10.6 THE DEFAULT XML APPLICATION ................................................................................................................................ 3510.7 HOW IS AN XML APPLICATION USED? ......................................................................................................................... 35

10.7.1 Documentum XML_APP Processing Instruction................................................................................................3510.8 NEW OBJECT TYPES IN DOCUMENTUM ......................................................................................................................... 36

SUMMARY....................................................................................................................................................................................37

APPENDIX A: LIST OF WDK 4.2 COMPONENTS.......................................................................................................38


4

OVERVIEWDocumentum Foundation Classes (DFC), Documentum Developer Studio (DDS), WebDevelopment Kit (WDK), and XML are powerful options for developing Documentum-basedapplications. They can be used together or separately, depending on the application. Thisdocument will cover WDK 4.2 in the greatest detail, but will also provide information on DFC,DDS, and XML in order to provide you with a broader look into developing web applicationswith Documentum.

USER INTERFACE DEVELOPMENT

1.0 Web Development Kit (WDK)WDK 4.2 is a set of presentation components and an application framework that is highlyconfigurable. It is built on the Java platform. Together, these components and frameworkcomprise a robust, flexible, scalable toolkit for building web applications that leverage theDocumentum platform. Over 50 content management library operations are prepackaged tobuild rapid applications by gluing the components together. This includes both basiccomponents, such as checkin, checkout, and import and many advanced components, such as theWorkflow, Lifecycle, Rich Permissions, and Virtual Document Manager (VDM). In addition tothis, there are sophisticated content transfer services that can handle operations involvingmultiple document selections.

WDK 4.2, in addition to an application server, is functionally equivalent with RightSite andSmartSpace in a Java-based environment. Since WDK 4.2 is built in accordance to industrystandards (JSP 1.1 and Servlet 2.2), developers can utilize the standard Java IDEs, tools andlanguages that they are already familiar with. This means rapid application development anddeployment. The application developer can take this toolkit and produce custom webapplications that leverage the power, flexibility, and security of the Documentum platform.

The WDK architecture, at a high level, is displayed in Figure 1. In this diagram, presentationcomponents, a configurable framework, and the J2EE development environment representWDK. DFC provides the business logic.

Figure 1: Web Development Kit 4.2


5

1.1 Product GoalsWDK 4.2 provides an abundance of tools to the application developer, reducing developmenttime and increasing the scope of the Documentum platform. It also lays a strong foundation uponwhich to deliver increased value. To summarize, the goals of WDK 4.2 are as follows:

1. To clearly separate the services/business logic layer of WDK from its presentation layer2. To increase the breadth of WDK components and services to be functionally equivalent

to RightSite and SmartSpace3. To improve product deployment4. To broaden platform support in terms of web client/server operating systems,

application/web servers, web clients, and integrated development environments.5. To fix bugs not fixed in previous product releases.6. To provide a scalable run-time that can be included in custom web applications built to

leverage Documentum content management capabilities.7. Leverage the industry leader application servers like Apache Tomcat, ATG Dynamo,

BEA Weblogic, IBM Websphere, Macromedia JRun, and Sun iPlanet.

1.2 BenefitsWDK speeds deployment as a result of component flexibility and reusability, reduces thelearning curve for development teams, and provides a more immediate return on investment instandard technologies.

WDK 4.2 was designed and developed to provide approximately 80% of the functionality thatwould be needed to build web application that utilizes the power of the Documentum platform.The other 20% of the application will be up to the individual developer or development team.This percentage may also change, of course, as the complexity of the application increases. Onthe other hand, if the developer decides to take full advantage of the configuration services, theremay not be any additional programming necessary to create a custom application.

WDK is the ideal solution for developers who want to quickly engineer applications that utilizecommon Documentum functionality. And since WDK is Java-based, developers can work withina familiar environment. Reusable components, the essence of WDK, can be used for rapiddevelopment of applications that perform common operations or customized as needed toaccommodate diverse Web application requirements.

Benefits Summary:

• Rapid application development. Reuse is the cornerstone for rapid applicationdevelopment. WDK comes with over 50 pre-built components, based on JavaServer Pages(JSP), to help developers build new applications faster than ever. For more information onJSP, please go the following:

http://java.sun.com/products/jsp/.


6

• Faster deployment. Supplied WDK components allow development teams to hit the groundrunning, providing a more immediate return on investment.

• Increased customer satisfaction. Because WDK operates on J2EE (Java2 Platform,Enterprise Edition, developers can take advantage of faster, more efficient debugging andother standard development practices, yielding a high quality application that meets thestringent requirements of today’s business customers. For more information on J2EE, pleasego to the following:

http://java.sun.com/products/j2ee/

1.3 The ToolkitThe WDK consists of the following tools:

• Java classes that conduct eContent Repository (Docbase) operations. These classes include:

− Command classes that conduct eContent Repository operations.− Content transfer classes that manage checkout, checkin, import, and export of documents

and XML between clients and a eContent Repository. The content transfer classes installand use content transfer applets in the client browser.

The command classes and content transfer classes rely on the Documentum FoundationClasses (DFC) to provide basic eContent Repository functionality.

• Java classes for models and views of Documentum objects, such as models and views of thefolder hierarchy in a eContent Repository or the document hierarchy in a virtual document.

• Java classes that manage configuration, context, menus, localization, events, and exceptions.

• JavaServer Pages that provide Documentum functionality by instantiating objects based onthe Java classes and creating standard user interfaces. JSP pages can contain both server-sideJava code and client-side HTML and JavaScript code, allowing you to generate dynamiccontent on the server and control its presentation and behavior on the client. You cancustomize these JSP pages as desired for your application.

• JavaScript functions and event handlers that support the user interfaces in the JSP pages.Some JavaScript functions reside in associated JSP pages, while others reside in files thatcontain only JavaScript.

• Services that allow you to configure your application and its components with XML, whichreduces the amount of time and programming expertise required to develop your application.

• API documentation (Javadocs) for the WDK and DFC classes, and online help (Javahelp)that contains documentation for the JavaServer pages and application development tasks.


7

1.4 Software RequirementsBefore you develop a web application using WDK, you must install and configure the followingserver software:

• An HTTP server, which can reside on your development machine or on a separate machine.

• A Java application server, which communicates with the HTTP server and typically (but notalways) resides on the same machine as the HTTP server. The Java application server mustsupport both the Java Servlet Specification, version 2.2, and the JavaServer PagesSpecification, version 1.1.

• A Documentum eContent server and eContent Repository (Docbase), which is accessedthrough a Docbroker and can reside on any machine.

2.0 WDK 4.2 ArchitectureThe WDK Java classes can be used in your existing web development environment. You candeploy the WDK classes in your web server application. The WDK Architecture is built with thefollowing elements:

• Presentation components: JavaServer Pages (JSP) that present static and dynamic contentthrough WDK model and view classes and perform eContent Repository transactions throughcommand classes.

• A configurable application framework for your application• JSP 1.1 and Servlet 2.2 web application infrastructure• Business logic encapsulated in the Documentum Foundation Classes (DFC)

2.1 What is a WDK component?We define a component as being all of the 'bits' that are required to implement a single piece offunctionality.

A component has a container and may have one or more supporting files. If the component has aUI then the container will be a JSP file, otherwise it will be a servlet. The supporting files couldinclude Stylesheets; class files; config files; internationalization (I18N) resources - in fact anyfiles that the component makes use of.

The components are configurable, so they leverage the configuration of action services. Thismeans that the components also have associated configuration files. The configuration files areXML files. This configurable application framework allows the application to be contextsensitive.

Example(Note: This example component has been simplified for illustrative purposes)


8

A WDK component might implement a tree control that represents a Cabinet/Folder hierarchy.This component is deemed to be all of the 'bits' needed to implement the tree-view.

As this component has a UI, (the tree-view itself), it would be contained within a JSP page. TheJSP page would make reference to the basic DFC class files, other Java class files, a stylesheetand would get configuration information from an XML file. The component may also needinternationalization information which would also be included in the component.

Figure 2 illustrates the 'pieces' that make up this typical component.

Figure 2: WDK 4.2 Component

2.2 Configurable Application Framework

The framework is all of the pieces that the WDK components use to operate and interact. Itdetermines their behavior, look-and-feel and allows them to communicate with each other. Theframework lets you configure the component's localization (L10N), branding/style, content-sensitivity, logging, behavior (redirection, error-handling etc.), presentation etc.

Configuration is based in XML and allows components to be data-driven without the traditionalcoding that customization involves (e.g. extending a Java class). It is this approach that makesthe WDK suited to rapid, flexible and very powerful application development.


9

Figure 3: WDK Configuration "Stack

Figure 3 outlines some the services that will be discussed in the next few sections.

2.2.1 Actions and Action ServiceActions provide the ability to register handlers with the action service, so that these handlers getcalled first. Application logic gets placed here and then the commands get dispatched. This isone level of indirection that WDK provides, which means more capability to add applicationlogic.

The action service provides the ability to make the UI context sensitive. This is done by theconstruct preconditions. The preconditions are put into a configuration file. An example of aprecondition would be:

– If the role is consumer, then the action “add cabinet” will not be available.

The action service also provides:– Data Driving– Custom logic for your applications

2.2.2 Configurable Menus

Figure 4 : WDK 4.2 Menu Figure 5: WDK 4.2 Menu

WDK 4.2 has the ability to setup menus within XML configuration files. These menus are basedon actions and the action service. Therefore, separate menus can be created for different

Configuration Service

Action Service

Menus

eContentRepository

FileSystem

Components

Widgets

XML


10

eContent Repository object types. For example, Figure 4 displays a menu that was created for adm_folder object. Figure 5 displays a menu that was set up for a dm_document object.

2.2.3 Configuration ServiceThe configuration service is the infrastructure layer that all components use. This layer providesthe ability to read the configuration files that are available with the WDK components and theapplication. Then they take these files and store them in a namespace.

2.2.4 QualifiersThe easiest way to map roles will be to put them into a configuration file. The developer willstill have the flexibility of creating a new role. The configuration services will read all of thisdata and store it into a namespace. You can then use this context from within the component.This allows custom application logic. A qualifier in the WDK encapsulates a set of valuesassociated with a specific form of context.

Role and type are examples of implementations of qualifiers that are provided with WDK 4.2.For example, you can configure a UI using:

• role = contributor, coordinator, etc.• type = dm_document


11

3.0 WDK 4.2 Components

3.2 Examples of WDK 4.2 Components

3.2.1 Checkin, Checkout, Cancel Checkout

Figure 6: WDK 4.2 Checkin Component

The checkincomponentgives the userseveral usefuloptions. Forexample, asdisplayed inFigure 6, thiscomponentallows a user tocreate a versionlabel anddescription,which areoptional. Theother optionalsettingsavailable andcan be used asneeded.

3.2.2 Import

Figure 7: WDK 4.2 Import Component


12

The Import component will has been enhanced to provide the ability of importing multiple files.It also has the built in intelligence to recognize certain file types and pre-define the importsettings, which can be changed. For other file types, such as the ScreenCam movie that isdisplayed in Figure 7, the user will be able to select from a list of file formats. The XMLCategory can be selected for appropriate file types.

3.2.3 Inbox

Figure 8: WDK 4.2 Inbox Component


13

3.2.4 Properties

Figure 9: WDK 4.2 Properties Component

The Properties component has anassociated XML file that sets upattributes that are editable and those thatare for display purposes only. Forexample, Figure 9 displays the standardproperties for the type document. Thisparticular document has the editableproperties of name, title, subject,keywords, and authors. These propertiescan be edited via this component andsaved into the eContent Repository. Thenon-editable, or view only, properties arealso available to be displayed.

The XML file for this component can beedited, as all of the available options maynot be necessary or even valid for theresulting application. In addition, customtypes may have their own XMLconfiguration file for the propertiescomponent as these custom types wouldoften have unique attributes that are not apart of any other object type.

3.2.5 Basic and Advanced Search

Figure 10: WDK 4.2 Basic Search Component

There are different types of search optionsavailable in WDK 4.2. A basic search, alsoknown as one box search, is the mostsimple search option available. Theadvanced search options, as displayed inFigure 10, will also the user to refine thesearch criteria.


14

Figure 11: Advanced Search Component

3.2.6 VDM

Figure 12: WDK 4.2 VDM Component

Figure 12 displays the generic user interface of the VDM component. The user will be able toview the VDM tree, as well as have access to a menu with previously specific items. WDK 4.2


15

will provide support for several VDM operations. Some of these operations will have anassociated user interface and others will not. For example, the VDM component will support thefollowing VDM operations:

• Create New Document• Add Child• Remove Child• Levels to Show• Set Default Binding For View• Show Different Version• Set Binding Rule• Set Copy Behavior• Assign Version Label• Save Changes

Add Child

Figure 13: WDK 4.2 VDM Component - Add Child

Figure 13 displays part of the Add Child user interface.


16

3.2.7 Workflow

Start Workflow Component

Figure 14: WDK 4.2 Workflow Component – Start Workflow

This component displays aform that will allow a userto select from a list ofavailable workflows andthen additional optionalinformation that may behelpful to the next set ofrecipient(s). Once thatinformation has beenentered, the user will thenbe able to start a workflow.In this release, the user willnot be able to actuallycreate the workflow itself.

Workflow Status

In addition tosimply viewingthe status of aworkflow, userscan drill downand look at theindividual tasks.The capabilityto either halt orabort aworkflow is alsoa part of thiscomponent.

Figure 15: WDK 4.2 Workflow Component - Workflow Status


17

3.3 Other FeaturesWDK 4.2 comes with several new features. The next three sections cover some of the other newfeatures in more detail.

3.3.1 Configurable Content TransferThe content transfer services provide the ability to import, checkin, and checkout items via theweb. The first time a user logs on to the WDK-powered application, a content transfer appletwill be loaded. Even though some users may not like the idea of having an applet installed ontheir browsers, it is necessary for this set functionality. A web browser is stateless by nature andthe applet is vital to creating the vital intelligence necessary for successful and secure contenttransfer.

3.3.2 Multiple Selection Support (Checkboxes)In previous versions of WDK, users were not able to select more than one item at a time. Thisoption will continue to be available, if the developer decides it is appropriate. However, WDK4.2 will include support for multiple selections (checkboxes) as part of the folder contentscomponent. For example, a user may want to checkout two documents at the same time in orderto make necessary changes. This option is now available.

3.3.3 Multiple eContent Repository (Docbase) SupportAnother new feature of WDK 4.2 is multiple eContent Repository support. This will allow a userto log into more than one eContent Repository during their session. This will also allow thedeveloper to more easily create a federated environment.

4.0 Web Development StandardsWeb developers have a wide variety of options available to them today. There are multipledevelopment platforms, as well as development tools. WDK 4.2 has been developed to utilizethe Java platform due to its maturity in the marketplace. A Microsoft version of this product willbe developed upon the .NET platform once it is available.

4.1 Java Development

4.1.1 JSPWDK leverages the investment in Java ServerPages (JSP). JSP is a server-side scriptingenvironment that is used to create and run dynamic, interactive web applications. With JSP, youcan combine HTML pages and script commands to create interactive web pages or powerfulWeb-based applications.

4.1.2 ServletsJSP pages compile into Servlets. Therefore any standard Java compiler can be used to developwith WDK.


18

4.1.3 Java ClassesDevelopers who wish to extend the Java classes that come with WDK 4.2 can do so as long asthey use standard Java methodology. The same is true if they would like to add additionalcustom classes to their applications.

4.2 Application ServersApplication servers that are compliant with the JSP 1.1 and Servlet 2.2 specifications may beused. WDK 4.2 is designed to be compliant with these standards and there should not be anyadditional application server configuration required in order to start using the product.

4.3 Integrated Development EnvironmentsIndividual Integrated Development Environments (IDE) will not be certified as a part of WDK4.2. The developer may choose to use any IDE that is J2EE compliant. There are many IDEsthat are a Java compiler and some that also contain support for JSP. There are also IDEs that aredesigned specifically for JSP.

5.0 J2EE Compliance for WDK 4.2In an application stack, WDK serves as presentation layer and DFC serves as business logic.WDK is a set of presentation components and framework. It is written using JSP 1.1 and Servlet2.2 specifications as defined in J2EE.

5.1 J2EE BlueprintFigure 16 is a snapshot of the blueprint that Sun published regarding what a J2EE compliantapplication would look like. On the presentation side there is JSP and Servlet technology. WDKprovides that.

On the business logic side, there are EJB containers. Today, DFC provides a set of Java classes.DFC does not live in an EJB container. It does not extract into an entity bean. When DFC wasdeveloped, EJB containers were not mature. DFC was implemented as a set of Java classes thatare available to both the Java platform natively and to the Windows platform via a Java-COMbridge in the Microsoft JVM.


19

WDK DFC 4i

Figure 16: J2EE Blueprint - http://java.sun.com/j2ee/blueprints

6.0 Internationalization

6.1 What is Internationalization?Internationalization is the process of enabling the translation of a program without modificationof its executable code. An internationalized program supports user interfaces (UI) and user inputin multiple languages.

Internationalization is sometimes referred to as I18N, which represents the first and last letters ofthe word “Internationalization” and the 18 characters in between.

The user can select a locale for the web session. All pages displayed in the application will be inthe selected language, if the user has the proper display fonts installed for the browser. The usercan enter data using characters from the selected language, if the user’s system has keyboardsupport for the selected language.

6.2 What is localization?Localization is the translation of user interface and message elements into multiple languages.All visible text in WDK server pages has been externalized to simple text resource files whichcan then be translated into other languages. Localization is sometimes referred to as L10N,which represents the first and last characters and 10 characters between them.

You can add UI resource bundles, in addition to the bundles supplied with the WDK. Yourresource bundles extend standard Java internationalization classes.


20

Your application’s user interface will be displayed in one of the languages you support, but youmust also consider the fonts and encoding for those languages.

6.2.1 LocalesA locale represents a specific geographical, political, or cultural region. A locale is specified inthe WDK, and in all Java applications, by a locale code, which consists of an ISO language codeand an ISO country code. See “Java Locale Names and Country Codes” in the Internationalizingand Localizing WDK-based Applications manual for more information.

Your application specifies its supported locales in the application config.xml file. The list ofsupported languages will be displayed when the user logs in to your application.

6.2.2 Language selectionThe WDK login page detects the user’s current system locale setting (language) and by defaultuses a compatible locale for the user’s session. For example, if the user’s locale is FrenchCanadian, and your config.xml file lists French and Spanish, the default locale will be set toFrench. See “Language negotiation” in the Internationalizing and Localizing WDK-basedApplications manual for more information.

6.3 Fonts, character sets, and encoding

6.3.1 FontsApplication users select a locale for their operating system -- French, English, Spanish, Italian,German, Japanese, Korean, or other. There are dozens or even hundreds of fonts that can displayall of the characters for the selected locale. A font renders the language characters through anencoding scheme, also called a character set.

Users can select default fonts for their browsers using browser preference settings. If theirselected font does not use the encoding of your WDK application pages (XML and JSP), then thecontent will not be rendered properly.

Your localization process must specify the encoding for your pages, and optionally, specify instyle sheets the fonts that should be displayed by the browser.

WDK style sheets do not specify fonts. As a result, the HTML pages that are generated fromWDK JSP pages will be displayed in the default font of the user’s browser.

The sample application, wdkSpace, uses a style sheet that specifies font faces for Latin-1languages. If you wish to change the fonts in the sample application to display double-bytecharacters such as Japanese or Korean, specify your fonts in wdkSpace.css.


21

6.3.2 Character sets and encoding (codepage)Character sets (code sets)Languages are rendered with character sets. For example, the English alphabet is a character setthat contains 52 upper- and lowercase letters. The Japanese character set kanji contains 1945characters.

Characters sets that have assigned binary values for each character are called coded charactersets, or code sets. The most widely used character set in web pages is ASCII, which canrepresent very few languages, mainly English, Indonesian, and Swahili. The ISO 8859-1character set, known as Latin-1, supports more languages. Because character sets are renderedwith encodings, you will often see the words used interchangeably. However, some charactersets do not have assigned encodings.

EncodingA character set is encoded in binary octets. The mapping of the character to the binary sequenceis called an encoding method or scheme. Languages can often be encoded with several differentschemes, and no single encoding is used for every language.

Character set names are registered with the Internet Assigned Numbers Authority (IANA) athttp://www.isi.edu/in-notes/iana/assignments/ character-sets. Names are case-insensitive and arespecified in the HTTP and MIME Content-Type headers that are sent from the browser to theserver and from the server to the browser.

WDK default encodingThe lack of a standard encoding scheme is a problem for multilanguage web sites or intranets.The Unicode standard addresses the need for an encoding that can represent all character sets.Unicode defines a 16-bit, fixed-width character encoding scheme. The standard assigns eachcharacter a unique code point, with the capability of encoding over a million unique characters.

Unicode includes several encoding schemes:• UCS-2: double-byte encoding (default Unicode encoding)• UTF-8: 8-bit encoding

The WDK specifies UTF-8, one of the Unicode encoding schemes, in every XML and JSP page.Unicode encodings are designed to be capable of rendering every known language character.Unicode is represented by several encodings, including UTF-8, UTF-16, and UCS-2.

Some of the encodings used by current Documentum customers include Latin-1 (French andGerman), K EUC (Korean), SJIS and EUC (Japanese), none of which is a Unicode encoding.Even though Unicode can represent all characters, most of the world’s thousands of fonts do notuse a Unicode encoding.

Changing the encodingEncodings other than UTF-8 are not supported by WDK. If you change the encoding, you musttranslate form data from your encoding to the Java String encoding (UCS-16), in the same way


22

that DwFixEncoding translates form data from UTF-8 to UCS-16. Certain elements of yourapplication must be in Unicode:

• XML files must be in a Unicode encoding scheme.• Attributes stored in the eContent server must be in Unicode.• URLs must be in ASCII format. Non-ASCII characters must be in escaped hexadecimal

format.

If you change your application’s encoding scheme, you must change the encoding specificationin every WDK XML and JSP file. See “Specifying the encoding” in the Internationalizing andLocalizing WDK-based Applications manual for implementation details.

If you do not specify the encoding, client browsers will default to rendering content in the ISO8859-1 (Latin-1) encoding, which will look like gibberish to non-Latin1 language speakers.

The encoding of your web pages affects only the display and user input, not the content ofobjects that are imported into or exported from the eContent Repository. The eContent server isunaware of the encoding for documents stored in the eContent Repository.

6.3.3 Client display limitationsThere are two ways to display fonts correctly in your user’s language of choice:

• Create CSS files that specify fonts that are compatible with your encoding.

The font faces that you specify must be a set of fonts that are likely to be found on thesystems of all users of your application.

• Do not specify fonts.

Set the encoding in your JSP pages and XML files, and let users change their browser fontpreference to one that is supported by your encoding.

See “Localizing styles” in the Internationalizing and Localizing WDK-based Applicationsmanual for information on creating locale-specific style sheets.

6.4 eContent server supportVersions of the eContent server prior to 4.2 did not support data dictionary data or attributevalues in non-Latin1 languages. With the 4.2 server, attribute data and data dictionary data arestored in UTF-8, and localized versions of the data dictionary in several languages is supported.

6.4.1 Supported encodingsThe following encodings are supported by the eContent server:

• Documents stored in an eContent Repository can be encoded with any encoding scheme.


23

• Object attributes can be encoded in any encoding scheme. They are translated into UTF-8 forstorage in the eContent Repository.

• Object type names and attribute type names are limited to ASCII characters, although youcan escape non-ASCII characters using their hexadecimal representation.

• Data dictionaries can be localized to display messages, error strings, and labels for objecttypes and attribute names. Data dictionary entries must be in a UTF-8 encoding.

6.4.2 Attribute field limitationField length for attributes is an important consideration in localization. Asian languages typicallyuse three bytes in the UTF-8 encoding, which limits field length. For example, a 32-byte authorfield will hold only 10 Asian characters.

6.4.3 DMCL initialization of client codepageThe 4.2 eContent server requires a new dmcl.ini setting to enable Unicode (UTF-8) support. See“DMCL client codepage” in the Internationalizing and Localizing WDK-based Applicationsmanual for instructions on setting the client codepage for the WDK HTTP server.

6.4.4 Localized data dictionary labelsWDK has externalized all user interface strings to properties files for localization. This includeslabels for common attributes such a authors, keywords, or creation date. These labels can also belocalized in data dictionary files.

The WDK provides all strings in accessible properties files so that you can localize all strings fora given interface in one or two files. If wish to leverage data dictionary localization, however,you can remove the labels from component configuration files, and the WDK will display labelsfrom the data dictionary, passing in the user’s locale.

7.0 WDK 4.2-powered Sample ApplicationsFor the convenience of the developer, there are several WDK 4.2 Powered sample applicationsthat are available. There is an example of a library services client, an example of a customapplication, and an example of a role-based client. Each of these applications will be shipped asa WAR file, which is part of the J2EE standard.


24

7.1 WDKSpace

Figure 17: WDKSpace Sample Application

WDKSpace is a sample library services application that can be added during the installationprocess of WDK 4.2. The user interface is similar to that of the Intranet Client purely todemonstrate functional equivalence. This application will ship as a WAR file and if the userchooses to deploy this application at a later time, then that option is available. Please note thatWDKSpace is an unsupported sample. WDKSpace is also not a supported product and can notbe installed as such in a production environment. This application is only to be used foreducational purposes.


25

7.2 WDKAuction

Figure 18: WDKAuction Sample Application

WDKAuction is a sample of a customized application that will also be available as a WAR file.However, it will not be part of the WDK 4.2 installer. This application is also for educationalpurposes as it is not a supported product.

LEVERAGING BUSINESS LOGIC

8.0 Documentum Foundation Classes (DFC)Documentum applications depend heavily on the Documentum object model, which is theobject-oriented structure by which eContent Server organizes the contents and controlmechanisms of eContent Repositories (Docbases). Therefore, it is a good idea to get a generaloverview of the Documentum Foundation Classes (DFC). The following section on the DFC ismore deeply technical than the rest of the sections included in this document, but will provide thebackground necessary in order to understand how it fits in the development cycle.


26

8.1 Introduction to DFCDFC exposes the Documentum object model as an object-oriented client library. It is leveragedby both client/server architecture such as Desktop Client and web such as WDK.

DFC consists of the following:

• A set of interfaces that provide the DFC programming model. This programming modelspecifies how an application interacts with the DFC objects that implements these interfacesand the relationship between these DFC objects. The objects in this model consist ofpersistent objects stored in a docbase and non-persistent objects returning from a query orgenerated by DFC.

• A Java implementation of this model. It consists of several Java packages each contains anumber of Java classes and interfaces. These packages will run in both the Microsoft andSun’s Java virtual machine that support JDK 1.1. On-line documentation (JavaDoc) of thisclass library is provided. It also provides tracing and exception handling.

• A set of COM interfaces and wrapper classes are provided with the DFC to make its Javaimplementation available to COM components. Since the DFC appears as a set of COMcomponents, it is accessible by clients written in Visual C++ and Visual Basic.

8.2 PackagesDFC is organized into packages, that is, sets of related classes and interfaces.

• The names of DFC Java classes begin with Df (for example, DfWorkflow).• Names of interfaces begin with IDf (for example, IDfWorkflow).

Interfaces expose DFC’s public methods and constants. Each interface contains a set of relatedmethods.

Table 1 describes the purpose of the classes and interfaces of DFC packages.

Table 1: Description of DFC Packages

Java Package Name Purpose

Com.documentum.fc.client Provides basic functionality• Establishing DFC sessions• Retrieving and validating data• Managing workflows• Manipulating virtual documents• Working with document versions

Common.documentum.fc.client.qb Constructs and runs queries and Smartlists

Com.documentum.com Facilitates accessing DFC from COM.

Com.documentum.fc.common Supplies utility methods for other DFC classes


27

Com.documentum.operations Supports eContent Repository (Docbase) sessions.

Com.documentum.operations Provides high-level functionality, such as checkingdocuments or virtual documents in and out.

Com.documentum.registry Maintains Documentum information on the client’s system,using the Windows registry on Win32 platforms, and .inifiles otherwise.

8.3 DFC ProgrammingThe picture below shows a subset of the DFC interface interaction. The application developerwill first call the static method DfClient.getLocalClient() to get back an IDfClient interface.Then call the IDfClient.newSession(...) to establish a DFC session. From there, you can retrievea persistent object by calling IDfSession.getObject() and pass in an object id.

IDfQuery

IDfPersistentObject

getObject( objectId )getObjectWithType( objectId, objectType, className ) getObjectByQualification( qual)getObjectByPath( path ) newObject( typeName )

IDfCollection

IDfTypedObject

IDfType

getTypedObject()

execute( DfSession, queryType )

getType(typeName )

getId( attrName )

IDfClient

IDfSession

getSharedSession( docbase, IDfLoginInfo, key)newSession( docbase, IDfLoginInfo )findSession( dfcSessionId )adoptDMCLSession( dmclSessionId )

getLocalClient()getRemoteClient( location )

getClient()

IDfId

getSession()

getType()

IDfAttr

getAttr( index )

getSharedSession( docbase, key )newSession( docbase )

DFC exposes most of the Documentum object hierarchy as a set of interfaces. An interfacedefines a contract between an implementation class and any client that uses instances of thatclass. Interfaces do not specify implementation. They simply define a set of methods withspecific signatures and specific semantics. A class provides the implementation, but as anapplication programmer, you usually don’t need to know which class. If you hold a reference to aclass that implements a given interface, you know that objects of that class have all of the


28

functionality that the interface promises. DFC includes a default implementation for eachinterface.

In Figures 19 - 22, you can see how the interfaces that derive from the Documentum hierarchy fitinto the total DFC interface hierarchy.

Figure 19: IdfTyped Object


29

Figure 20: IdfOperation Figure 21: IDfOperation Node

Figure 22: IDfClientRegistry Object

A Small DFC ProgramThe following fragment from a Java program that uses DFC contains three blocks of code. Theyimplement the first three steps of the procedure.

IDfClient client = DfClient.getLocalClient();

IDfLoginInfo loginInfo = new DfLoginInfo(); loginInfo.setUser("Mary"); loginInfo.setPassword("ganDalF"); loginInfo.setDomain("");session = client.newSession("MyDocbase", loginInfo);

IDfDocument document = null;document = (IDfDocument) session.newObject("dm_document"); document.setObjectName("Report on Wizards"); document.setContentType("crtext"); document.setFile("C:\Temp\Wiz.txt");document.save();

The first block creates the client object, which encapsulates the Documentum client software.The second block creates and populates an object to hold login information and uses it tomanufacture an IDfSession object, which encapsulates a session for this application programwith the specified eContent Repository (Docbase).


30

The third block of code creates and populates an IDfDocument object and saves it in theeContent Repository. Notice that the newObject method of the session object manufactures theobject.

The newObject method returns an IDfPersistentObject object. The program explicitly casts it toan IDfDocument object, then uses the document object’s save method, a method thatIDfDocument inherits from IDfPersistentObject. COM does not support interface inheritance, sothe Visual Basic and C++ versions of the above code explicitly cast the document object to apersistent object before saving it.

Most DFC methods throw DfException to report errors. Java code like that in the above examplenormally appears within a try/catch/finally block, with an error handler in the catch block. VisualBasic code uses the On Error Goto statement to handle exceptions.

More information on DFC can be found in the Using DFC in Documentum Applications manual.

CUSTOMIZING THE DATA MODEL

9.0 Documentum Developer StudioDocumentum’s Developer Studio provides the application developer the ability to defineapplication specific data such as custom types, lifecycles, etc. that are utilized in buildingDocumentum applications.

Figure 23: Documentum Developer Studio


31

9.1 What is Documentum Developer Studio?DDS is the facility used by application developers to create and maintain their DocApps. ADocApp is a collection of eContent Repository objects that make up a Documentum basedapplication. DDS provides the ability to externalize the application in the form of a DocAppArchive. These archives can be installed in the customer's deployment eContent Repositoryusing the DocApp Installer (DAI). An important aspect of the DocApp is that parameters can beused for eContent Repository specific information. This makes the DocApp Archives portablefrom one eContent Repository to another. The DocApp Installer replaces the parameters withvalues that the user provides when she installs the DocApp in a deployment eContentRepository.

Before the advent of DDS, users accomplished the deployment using a combination of scriptsand eContent Repository dump and load mechanism. The successful transfer of an applicationfrom the development to a deployment eContent Repository required considerable expertise andsignificant custom development effort.

Documentum based applications consist of eContent Repository elements such as Object Types,Document Lifecycles (DLC), Workflow Templates, Methods, Jobs, Procedures, FolderHierarchies as well as business logic and presentation code. In general, DDS only deals with theeContent Repository objects and does not address the business logic or the presentation logic.However, the DocApp architecture was intended to address all aspects of applications and DDSdoes provide some facilities to organize the functional components of applications associatethem with the eContent Repository hierarchy, even distribute the components to end usermachines.

9.2 FunctionalityThe DocApp architecture introduced the notion of Functionality. A Functionality is a systemcapability that the end user uses to manipulate an object or several objects in a eContentRepository. It is implemented by a component that encapsulates the business logic and thepresentation facility that the user can use to perform the operation. Functionality can be broadlyclassified as Object Type Specific and Global. Type Specific Functionality is applicable only tothe instances of the Object Type it is defined for. For example, the 'Check In' functionality isapplicable only to instances of dm_document (objects that have content). Global Functionality isapplicable to all objects. The 'Import' Functionality is applicable to instances of all object types.Type Specific Functionality can be inherited down the type hierarchy. For example, the 'CheckIn' functionality is inherited by all the descendants of dm_document in the object hierarchy.

9.3 DDS and Web ClientThe DocApp Architecture does not assume that Functionality is implemented using a particulartechnology. It is possible that Functionality is implemented as a WDK component or even as aJSP/ASP page. However, the Documentum Intranet Client chose not to use this facility.


32

We plan to address issues in the present implementation of Functionality support and to extendthe support to WDK components. The benefit will be a uniform Object Type base customizationscheme for DTC and WDK. This will present a more coherent view of application developmentto the users and reduce their learning curve.

9.4 Workflow ManagerThe Workflow infrastructure is a vital part of the Documentum system. The eContent Repositorywould be an inanimate lump of information but for Workflow. Workflow has given us the edgein Document Management and will be an important differentiator in the Content Management.Robust Workflow will be an essential prerequisite for any B2B initiative. The Workflowinfrastructure consists of the engine that is built into the Server, client Inbox capabilities builtinto the client applications (DTC, Intranet Client, WebPublisher, WDK) and the WorkflowManager that is a part of DDS, DTC and Intranet Client.

SETTING UP AN XML APPLICATION

10.0 XMLThe Documentum platform has rich capabilities for handling XML content (chunking, assembly,zone searching, etc). This is built into our DFC layer and exposed seamlessly to both Web(WDK) and Desktop clients.

10.1 Role of XML in Content ManagementXML is rapidly becoming the standard language for e-business, including catalog creation, Webpublishing, and transactions between trading partners. XML enables businesses to create,publish, and repurpose content from one source and reuse it throughout the enterprise. An XML-based product specification, for example, can be used in a variety of different ways, publishingthis information on a company Web site, developing marketing collateral describing productfeatures, and composing catalog content distributed to customers. Within Documentum,individual pieces of documents, “chunks,” have access to all the features of a eContentRepository, includinglifecycle and workflow capabilities.

Documentum also provides standard document library services to XML content, including checkin, check out, and editing. Individual chunks of XML are treated as individual objects in theeContent Repository. A configuration file controls how XML content is processed within aeContent Repository.

10.2 XML Support in DocumentumThe XML support in Documentum allows you to:• Configure the storage, parsing, and searching XML content• Specify validation against a document type definition (DTD)


33

• Decompose XML into fragments that can be processed as individual objects with propertiesand behaviors. This is commonly called “chunking.”

• Specify, query, and extract metadata (properties) associated with XML content and chunks.• Populate Documentum attributes automatically• Manage links in an XML file• Transform XML from an eContent Repository to a schema for exchanging business

information, or to a format for publishing.• Enable searching of XML documents using Verity zone searching• Use XDQL to embed queries in an XML file. XDQL is an extension to the Document Query

Language (DQL). An XDQL query can return a DOM object, a file, or a stream. You can callXSLT from XDQL, and you can call XDQL from XSLT.

10.3 New Classes in DFCThe XML capabilities of DFC are provided by a number of new classes in DFC. For most of thebasic document processing operations within Documentum, a new step has been added forprocessing XML, apply XML application. This step uses the XML configuration file to tellDocumentum how to process and store the individual chunks within the EContent Repository.The other two operations that are specific to XML processing are transformation and validation.Transformation allows native XML content to be changed into a different format, like HTML,for example. Style sheets control how XML will be transformed into different formats.Validation requires that XML content conform to the rules of a document type definition (DTD).Documentum allows validation to be included in a lifecycle operation, for example.

Documents composed in XML are treated as virtual documents within the EContent Repository.The same rules regulating processing virtual documents apply to XML documents. Rules withinthe XML configuration file control how parent and child chunks are treated. For detailedinformation on the new classes, see the Javadocs for DFC. The Javadocs for DFC are beingshipped with the DFC.

10.4 Authoring and Parsing XML in DocumentumThe XML that you use with Documentum must be well-formed, written in accordance withXML language criteria. If your XML application requires that the XML be valid, there must be aDTD or schema associated with a particular document. The DTD is included in the XMLapplication folder within an eContent Repository. To author XML, use any text editor or XMLeditor that meets your needs. Documentum integrations with both Softquad and Arbortextprovide authoring and editing capabilities for XML. For information about third-party XMLeditor integrations, please refer to the release notes for Desktop Client. The Web Publisher Editorfrom Documentum allows you to author and edit XML in templates that enforce business rules.

To parse and transform XML, DFC uses the Xerces XML parser and the Xalan XSLT stylesheetprocessor from the Apache Software Foundation.


34

10.5 What is an XML Application?A Documentum XML application defines the rules for processing XML documents. Theinformation in an XML application defines:

• Validation rules using DTDs or schemas when the document is imported or checked in• Rules for storing the XML content as objects in the eContent Repository• Setting properties on the resulting objects• Interpreting and managing links• Processing parsed entities• Handling the XML content during standard document processing operations, including check

in, check out, export, and delete

Note: There are no limits to the number of XML applications you can have in Documentum. Theexact number depends on the different types of XML documents you have and the business rulesgoverning them.

To support XML functionality, an XML application contains these new Documentum objects:

• A folder of type dm_xml_application− Named the same as the XML application name− Stored in system/applications folder− Detects the XML application

• An object type dm_xml_configuration− Stores rules for processing an XML document

• Customer-specific DTD or schema, if desired• Cascading style sheets, XSL style sheets, and FOSIs, if desired

Note: DTDs and schemas are not required by an Documentum XML application. They areneeded only if document validation against a DTD is desired.

10.5.1 The XML Application FolderThe XML application folder holds the components included in an XML application, includingDTDs, configuration files, and supporting documents. The attributes in the folder objectdetermine which XML application is applied to any given XML document. These folderattributes must be set up before creating an XML application. For information concerning how tosetup folder attributes, refer to the section on Creating XML Applications.

10.5.2 XML Application Configuration FileEach XML application has a configuration file that describes what kind of documents theapplication can process and the rules by which the documents are processed. A configuration filespecifies:

• What objects are created in the eContent Repository for XML content


35

• The mapping between XML elements and object attribute values in the eContent Repository• The location of parent and child documents in the eContent Repository• Processing of links in the XML

The configuration file is an XML document. The DTD required for all XML applicationconfiguration files is supplied by Documentum and is named config.dtd. All XML applicationconfiguration files must conform to this config.dtd, and it must not be modified. For informationabout the config.dtd used to define the XML application, please refer to the config.htm fileprovided by Documentum on the FTP site.

10.5.3 The DTD or SchemaIf a customer-supplied DTD for an XML application is in the eContent Repository, Documentumwill use it for validating an XML document, if validation is required. Documentum downloadsthe DTD to client machines and patches the system declaration to the location of the DTD.

10.5.4 Application Support DocumentsAn XML application may require additional documents to support authoring in XML. Thesedocuments include cascading style sheets, FOSIs, and the like. If your particular applicationrequires these kinds of documents, create a subfolder in the XML application folder called“Application Support Documents.” These files are downloaded to clients during standardDocumentum document processing operations.

10.6 The Default XML ApplicationDocumentum provides a default XML application, named Default XML Application, stored insystems/applications. The default application is used whenever an XML document is notassociated with a user-defined, custom XML application.

The default application has a configuration file that is also named Default XML Application,stored in the application folder as an object of type, dm_xml_configuration. For details aboutsetting up the configuration file, see the “Creating XML Applications” section of CreatingDocumentum XML Applications. You can modify the Default XML Application to set up rulesfor processing XML content.

10.7 How is an XML Application Used?An XML application manages how XML content is processed during standard documentprocessing operations in an eContent Repository. When a user imports or checks in an XMLdocument, for example, the system first determines which XML application to use to handle thespecific XML document.

10.7.1 Documentum XML_APP Processing InstructionIf the document has an XML_APP processing instruction at the beginning of the file, theapplication named in the instruction is used. This overrides any other user selection. Theprocessing instruction is:


36

“<?dctm xml_app=“xml_application name”?>.

If processing is not desired, put the following:<?dctm xmlapp=”ignore”?>

If no matching XML application is found, the default XML application will be used to processthe content.

During the apply XML application step, the configuration rules for the given applicationdetermine subsequent processing of XML content.

If validation is required, then the document is parsed in validation mode. If there is a DTD in theapplication folder, it will be applied to the document and the XML content validated against it.

If a schema is specified, then schema validation will be performed.

If there is no processing instruction, the system extracts the following values from the prolog ofthe document:

• Root element• System identifier• Public identifier• Namespace of the root element

These values are indicated in the prolog of the XML document, as follows:

<?xml version=1.0><DOCTYPE cellphone-catalog PUBLIC '/Documentum/DTDCellPhoneInlineEntity//EN” “CellPhoneInlineEntity.dtd”><cellphone-catalog>

<?xml version=”1.0”?><!DOCTYPE cellphone-catalog SYSTEM“CellPhoneInlineEntity.dtd”><cellphone-catalog>

Then, the system queries the attributes of the XML applications in /Systems/Applications to findpotential XML applications for the document. The Documentum client presents all potentialmatches to the user. If the user fails to choose a match from the list of potential matches, thesystem chooses the first XML application returned by the query.

10.8 New Object Types in DocumentumXML applications are supported in eContent Server by five new object types:

• dm_xml_application (subtype of dm_folder)


37

• dm_xml_config (subtype of dm_document, contains configuration information for theapplication)

• dm_xml_style_sheet (subtype of dm_document)• dm_xml_custom_code (subtype of dm_document, stores custom code for XML processing)• dm_xml_zone (subtype of dm_document, stores the names of elements displayed as search

zones in a Find dialog)

For details of the attributes for these object types, refer to the eContent Server Object ReferenceManual.

SUMMARY

Documentum Foundation Classes (DFC), Documentum Developer Studio (DDS), WebDevelopment Kit (WDK), and XML are powerful options for developing Documentum-basedapplications. They can be used together or separately, depending on the needs of the application.

DFCDFC exposes the Documentum object model as an object-oriented client library. It is leveragedby both client/server architecture such as Desktop Client and web such as WDK. Documentumapplications depend heavily on this object model, which is the object-oriented structure by whicheContent Server organizes the contents and control mechanisms of eContent Repositories(Docbases).

DDSDDS provides the application developer the ability to define application specific data such ascustom types, lifecycles, etc. that are utilized in building Documentum applications. In general,DDS only deals with the eContent Repository objects and does not address the business logic orthe presentation logic.

XMLThe Documentum platform has rich capabilities for handling XML content (chunking, assembly,zone searching, etc). This is built into our DFC layer and exposed seamlessly to both Web(WDK) and Desktop clients.

WDKWDK speeds application development and deployment, reduces the learning curve fordevelopment teams, and provides a more immediate return on investment in standardtechnologies. And, WDK leverages application servers so that they benefit from XML andcontent management functionality. Reusable components, the building blocks of WDK, facilitatecustomization of applications within a familiar J2EE-compliant environment.


38

Appendix A: List of WDK 4.2 Components

• browse• browserRequirements• cancelCheckout• checkedOutObjects• checkin• checkout• choose• contents• copy• copyLinkMove• create

− import− newCabinet− newDocument− newFolder

• delete• documentLifecycle

− attach− demote− detach− doAttach− doResume− promote− resume− suspend

• edit• error• export• inbox• link• locations• login• logout• menu• move• permissions• properties• renditions• search

− basicSearch− advancedSearch


39

• transform• tree• vdm

− addChild− cancelCheckout− convertVirtual− moveChild− removeChild− saveChanges− setBindingRule

• versions• view• workflow

− abort− complete− createNote− deleteNote− editNote− halt− insertDoc− reassignForm− resume− reviewNotes− selectInsertDoc− selectNextTasks− sendTo− start− status− taskInfo− taskManager