If you're looking for Documentum Interview Questions for Experienced or Freshers, you are at the right place. There are a lot of opportunities from many reputed companies in the world. According to research, Documentum has a market share of about 3.8%. So, You still have the opportunity to move ahead in your career in Documentum Development. Mindmajix offers Advanced Documentum Interview Questions 2020 that helps you in cracking your interview & acquire a dream career as Documentum Developer.
Documentum is an enterprise content management software that provides management of content and attributes such as check-in, check-out, workflow, and version management.
Documentum provides management capabilities for all types of content including business documents, images, video, e-mail, Web pages, fixed content, XML-tagged documents, etc.
The core of Documentum is a repository in which the content is stored securely under compliance rules.
Documentum also provides a suite of services which include document management, collaboration, search, content classification, input management, business process management (BPM), customer communication management, Web content management, digital asset management, forms processing, information rights management, compliance, and archiving, etc.
Content Server is the foundation of Documentum’s content management system. It is a multi-featured product that provides access to the data and content files that constitute a docbase. It stores content files, their indexes, and properties in the docbase.
So it controls the access to the docbase. It controls the user’s access to objects in the repository by providing ACL. It is the core functionality that allows users to create, capture, manage, deliver, and archive enterprise content.
The place where the information about a document is stored is called docbase. It’s the combination of the operating system (file system) and the database.
The actual file (content) is stored in the file system and the information or attributes of the document are stored in the Database.
DFC – Documentum Foundation Classes.
This is an object-oriented application programming interface (API) and framework for accessing, customizing, and extending Documentum functionalities, implemented as a set of Java interfaces and implementation classes.
WDK – Web Development Kit
It is a developer’s toolkit that facilitates the development of complex web-based applications that connect to Documentum content repositories and Documentum content servers. It contains a large library of reusable components and controls to perform common Documentum management functionalities.
A connection broker primarily knows as docbroker provides repository connection information to the client application. Before installing a WDK application, one needs to obtain the names of the connection brokers to which the appropriate repositories project and the port numbers on which the connection brokers listen.
The connection brokers used by WDK applications are defined in the dmcl.ini file on the application server host.
[ Related Article: Documentum Tutorial ]
Documentum Content Server requires a properly configured database. The database tables store attribute values for each object in the repository.
Documentum provides a single repository for content and metadata. It uses an extensible object-oriented model to store content and metadata in the repository. Everything in a repository is stored as objects. To retrieve metadata, Document Query Language (DQL) is used.
DQL is a superset of SQL that provides a single, unified query language for all the objects managed by the Content Server. The repository owner (database user) account is the account used by the Content Server to connect to the RDBMS.
A Docapp is nothing but a packaging unit for Documentum objects. Docapps are used to package various elements for customization (such as custom Object Types, Lifecycles, etc.) so that they can be ported from one repository to another easily.
Using Documentum Application Builder (DAB) you can create and package all your objects within a Docapp. A Docapp archive is a portable representation of a Docapp in a file on the file system. Docapps simplify developing and redeploying applications.
Connection pooling is an optional feature of a Content Server that allows a primary repository session to be recycled and used by more than one user. Implementing connection pooling provides performance benefits for applications that execute frequent connections and disconnections for multiple users.
When connection pooling is enabled in the DMCL, primary repository sessions are not closed when a user disconnects. Instead, they are held in a connection pool created by the DMCL. When another user requests a connection to the repository, the user is authenticated and given the free connection.
When a user disconnects or a new user assumes ownership of a primary repository session, all sub-connections open in that session are closed.
Documentum supports a variety of options for implementing user authentication:
Custom applications can be developed using DFC (Documentum Foundation Classes) or WDK (Web Development Kit). DFC exposes Content Server API while WDK offers a framework and model for building a web application.
However, there are numerous aspects and options when developing a custom application using Documentum. Custom workflows can model business processes and lifecycles can encapsulate business rules around documents. SBO’s (Service-based Business Objects) and TBO’s (Type-based Business Objects) can encapsulate business logic.
Documentum capabilities can also be encapsulated in Web Services opening up a vast array of possibilities. D6 (Documentum 6.0) offers DFS (Documentum Foundation Services) which includes some core services as well as tools for developing web services for Documentum.
Then there are standard interfaces such as FTP and JDBC, which allow a Documentum repository to be accessed using these protocols. Specialized connectors and portlets offer additional alternatives. PIA (Primary Interlope Assembly) allows access from the .NET platform
A component is composed of one or more JSP pages, supporting behavior classes, and an XML configuration file.
A container is a specialized component. Many components share a common UI and state. For example, dialogs have a title, content area, and a button panel. Containers provide these common layouts and states for multiple components.
Components can be used within more than one container, inheriting their UI and state from the container.
A component consists of
1. A component definition within an XML file that defines the following elements:
2. JSP pages: Layout is defined in the JSP pages, using HTML and configurable Documentum tags. The definition defined in the element of the definition XML as stated above.
3. Component behavior class: has the logic of the component. This is defined in the element of the XML file as stated above.
4. String resource file defined in the element of the XML configuration.
The major lifecycle methods of a component are listed below:
The Documentum object model is used to represent content in the repository. The object model is hierarchical as in an object-oriented programming language. Child objects inherit all attributes and behaviors of the parent object.
Access Control lists (ACL) provides the security of Documentum objects. Every sysobject is assigned an ACL that has information about the users and groups' access to that object. There are basic 7 different levels of permissions that can be assigned to a user or a group of users for an object. The following are the object level permissions:
|1||None||No access is permitted.|
|2||Browse||The user can look at attribute values but not at associated content|
|3||Read||The user can read the content but not update it.|
|4||Relate||The user can attach an annotation to the object.|
|5||Version||The user can version the object.|
|6||Write||The user can write and update the object.|
|7||Delete||The user can delete the object.|
Other than these basic object-level permissions we have extended permission levels also in Documentum. The extended permissions are described below:
The main native Object types in Documentum are:
No, a container is not mandatory when writing a component. E.g. in Webtop, the “Copy to Clipboard” feature doesn’t have a container.
A precondition can be written for an action that determines whether the context is valid for the control or not. Accordingly, it will then render an action control as enabled or disabled. They are however optional in action definition. If not mentioned the action will always execute.
Preconditions are called for each item in a list of components. If there are 10 items and 20 applicable actions, 200 preconditions will be executed before the list is rendered. So it can affect application performance if not used correctly.
Versioning is an important content management feature of Documentum which helps in managing and tracking multiple versions of a document. The check-in / check-out option provides versioning capability in Documentum.
The version label attribute is the heart of the version management system which is used by the content server to label multiple versions of the document. Each label can have an implicit label or a symbolic label. The implicit label is assigned by the server whereas the symbolic label is assigned by the user.
The i_chronicle_id attribute value is the same for all the versions of a document. Each versioned object is assigned a unique “r_object_id” value but “i_chronicle_id” is the one attribute that is the same for all versions of a document and binds all versioned objects together.
Implicit labels: The implicit version label is a numeric label. It is generally assigned by the server and is always stored in the first position of the r_version_label attribute. By default, the first time you save an object, the server sets the implicit version label to 1.0.
Each time you check out the object and check it back in, the server creates a new version of the object and increments the implicit versions label (1.1, 1.2, 1.3, and so forth).
Symbolic Labels: A symbolic version label is either system or user-defined. Using symbolic version labels, you can provide labels that are meaningful to your application and work environment. Symbolic labels are stored starting in the second position (r_version_label ) in the r_version_label attribute.
A rendition is a representation of a document that differs from the original document only in its format or some aspect of the format. It is an alternate copy of a file or an additional file that can be included with an object. For example, it may be a copy of an image in a different format or in a different resolution.
[Check Out: Documentum Blogs]
App.xml: The app.xml is an application configuration file wherein one can configure the application-wide behavior. In Documentum, each application layer (webtop, wdk, webcomponent, etc…) has an app.xml file. It is made of application elements tag such as failover, content_transfer, authentications, formats, plug-in, listeners, etc.
To inherit and override settings in another application layer, the application definition can extend an application definition in another layer.
Web.xml: The web.xml file is a Web Application Deployment Descriptor for a web application. The web.xml file provides configuration and deployment information for the Web components that comprise a Web application.
Examples of Web components are servlet parameters, servlet and Java Server Pages (JSP) definitions, and Uniform Resource Locators (URL) mappings.
A workflow is a process that electronically passes documents and instructions from user to user. A workflow automates the process, ensuring that the right file goes to the right people in the right order.
Workflow tools: used to create the workflow definition called the workflow template are:
A document lifecycle is a sequence of states a file goes through between its creation and expiration. When you create a file, the system assigns a document lifecycle to the file and puts the file into the first state in the lifecycle.
Typical lifecycle states include WIP (Work In Progress), indicating a document is in its draft phase, and Staging, indicating a document is complete and ready for approvals.
Lifecycles and workflows are tools for enforcing business rules within Documentum.
A lifecycle is a sequence of a file going between its creation and expiration states.
Typical lifecycle states include Draft, Work in Progress, Approved, released, etc. Thus the focus of the lifecycle is an object.
A workflow represents a network of activities that electronically passes documents and instructions from user to user.
It automates the process ensuring the correct flow of work in a system. For example, an approval workflow can take a document from the author who created the document to an editor for review and lastly a manager for approval. Thus the workflow process may result in changing the lifecycle states of the document.
The third-party data from an external table can be accessed from the Documentum database with the help of Register tables. One can register any external table in Documentum and can thereby access the data residing in it as simply as it is residing in a Documentum docbase.
To register an external table in Documentum we use the following DQL:
DQL> “Register table dm_dbo.table_name (columname datatype)”
The above query registers the table in the Documentum database and as known this will create an object of type “dm_registered”.
A group in Documentum is a convenient way of collecting all users with the same permission level. A group can thereby facilitate managing permissions (assigning ACLs), assigning a task in a group work basket in a workflow, as an owner allowing all members of a group to have ownership for the document.
Thus groups are mainly used for Object-level permissions. Roles are mainly used for providing function permissions. They are basically a special type of group. It is created by setting the group_class attribute to the role and the group_name attribute to the role name.
UCF – Unified Content Facilities
It is a lightweight applet that is responsible for transferring content between the content server, application server, and the client machine during operations such as check-in, checkout, import, etc. UCF is a Java-based client application that is installed at run-time.
Since the WDK application uses UCF content transfer it downloads a lightweight applet to the browser when the client uses the Documentum operations for the first time.
A virtual document is a document that contains components or children's documents. It is composed of other components, each component being an individual object. The dmr_containtment object stores information about each individual component of a virtual document.
Virtual documents are used mainly for the following scenarios:
Following are some of the major features introduced in Documentum 6.x that were not present in 5.3
A document named JohnCoverLetter.doc is linked to two folders: /Letters/Candidates/Johnand /HR/Communications. An HR admin uses Webtop to delete the folder/Letters/Candidates/John and chooses to delete all the subfolders and objects. When this operation completes what happens to /HR/Communications/JohnCoverLetter.doc?
The document will still be there. The document is only unlinked from /Letters/Candidates/Johnbefore that folder is deleted.
Ravindra Savaram is a Content Lead at Mindmajix.com. His passion lies in writing articles on the most popular IT platforms including Machine learning, DevOps, Data Science, Artificial Intelligence, RPA, Deep Learning, and so on. You can stay up to date on all these technologies by following him on LinkedIn and Twitter.