Lifecycles (Documentum Composer)

Developing…

Virtual Documents in Documentum

What is a Virtual Document?

Virtual document is a document that can contain pointers to other documents in one or more docbases(Container for component documents).

Documentum enables hierarchical content management through Virtual documents . Virtual documents allow parts of a document to be treated as independent documents. set of independent document can be combined and treated as one document. one document can be reused in multiple virtual documents and managed independently. Collaboration is another great capability where multiple people can own various components of Virtual documents. each contributor to create , update and review the individually owned content. Virtual document allows documents in various formats(pdf,doc,gif,ppt,xml….) to be combined into one virtual document.

A Virtual document and its components have a parent –child relationship. one virtual document can have many children…at the same time ,one document can be a component of multiple Virtual documents. this is how a document is reused in multiple Virtual documents.

Virtual document versions

Each component of a Virtual document can be independently managed and versioned.
Version labels can be managed for a Virtual document in one of two ways –only for the root Virtual document object or for the entire Virtual document including its components and all indirect descendents.

Since each component of Virtual document can be versioned independently, there are multiple ways for a Virtual document to pick the versions of its components. it is possible to specify a binding rule for a component that specifies a particular version of the document to be bound to a containing Virtual document.

Binding rule:
1,use the current version of the component document.(by default )
2,use a specific version number of the component document.
3,use a specific version label of the component document.
4,Do not fix a specific version and allow the component version to be determined at snapshot time.


Snapshot:

The complete state of a Virtual document at a point in time can be recorded or archived using snapshot. a snapshot of a Virtual document describes how to archive an edition of a Virtual document at a particular point in time .it records the exact structure of the Virtual document at the point in time and enables its retrieval later when the Virtual document may have to changed. it is a version of the complete Virtual document hierarchy.

Freezing and Unfreezing a Virtual Document.

Frozen Virtual Documents are virtual documents, which are immutable. Once you make a Virtual Document or a snapshot frozen you cannot change or delete any attributes of the virtual document and you can also not add or remove components of virtual document. You can explicitly make a Virtual Document immutable by calling IDfSysObject.freeze()
When you call the freeze () r_immutable_flag will be set to true by content server also r_frozen_flag will also be set to true by the content server.

Calling IDfSysObject.unfreeze() on a frozen virtual document unfreezes the Virtual Document and make it modifiable again. In that case the content server sets the above-mentioned flags to false.

Freeze
+ Cannot add or delete components from the Assembly
+ That version of the component will be frozen
- Can’t change contents or attributes
- Assembly Document will be frozen
- Can’t change contents or attributes
Unfreeze
+ May add or delete from the Assembly again
+ That version of the component is unfrozen
- r_frzn_assembly_cnt = 0
- Can change contents and attributes
+ Only works if it is not nested within another frozen Assembly




Note

• A Virtual Document cannot contain any folders or cabinets, or any sub types of these.
• A Virtual Document object may or may not have a content (dmr_content) attached to it but a folder or a cabinet will never have any content attached to it. Though most of the time a Virtual Document might not be having a Content file attached to it.
• Any Object type that extents from SysObject can be converted as a Virtual Document. The Attribute r_is_virtual_doc (integer not a Boolean) of SysObject determines whether that object is a virtual document or not. If the value is 1 then it’s a Virtual document. If its value is 0 and the property r_link_cnt value is not higher than 0 then that object is not a Virtual Document
• The Contents of the Virtual document can be of different object types.
• The Virtual Documents can be versioned and managed in the same way as you do with any other objects.
• The Virtual documents are composed of various components, each components are nothing but individual objects.
• The containment objects (dmr_containtment) stores the information about the individual components of a Virtual Document. Every time when you add a new component to a virtual document a new dmr_containtment object will be created.

DQLs

1,To find all direct components in this Virtual document
SELECT ‘object_name’ in dm_sysobject IN DOCUMENT ID (‘r_object_id_of_virtual_document’);

2,Descent is used to return all components that contained in a virtual document.
SELECT ‘object_name’ in dm_sysobject IN DOCUMENT ID (‘r_object_id_of_virtual_document’) DESCENT

3, The VERSION Keyword finds the components of a specific version of a virtual document.
SELECT ‘object_name’ in dm_sysobject IN DOCUMENT ID (‘r_object_id_of_virtual_document’) VERSION 1.1

FREE EMC Documentum Developer Edition

For the first time, EMC has released a Documentum Developer Edition Package which is available as a free download (You do need an ECN login but registration is free).

Content Server and DMCL

The poor old Documentum Client Library (DMCL) gets blamed for a lot of things. The suggestion to delete the dmcl cache to avoid a multitude of problems has now entered the realm of myth. I’m sure that for many problems this is the correct solution. However, as you will need to shutdown the application using DMCL before deleting the cache, in many cases the simple act of restarting the application may have resolved the problem anyway. Still, since you can never be sure, a quick delete of the cache is no big deal if you are going to restart an application anyway.

However the finger of blame sometimes gets pointed at the DMCL even when it is unlikely to have any connection with the problem in hand. An example is internal processing failures of the Content Server process. I have seen people (including Documentum support) suggest dmcl cache clearing even for problems that arise inside Content Server processes. One of the keys to troubleshooting is using an understanding of how applications are architected to rule out certain explanations for the error.

The figure below shows a typical Documentum technology stack. This particular example is for a web browser accessing WebPublisher but you will see a similar picture for other client applications. The key here is that DMCL is a client library. Content Server exposes all its functionality via a set of (undocumented) server functions that are accessed via a Remote Procedure Call (RPC).

The DMCL is a linked library inside the client application – a DLL in windows, shared library in Unix. The DMCL takes documented API calls made by the client application and maps them to Server RPC functions that can be executed by the Content Server. Once the call has arrived inside the Content Server process the processing is no longer affected by the DMCL environment. In fact the DMCL thread that made the call will simply be sleeping awaiting the results of the processing from the server.

The really confusing part is that DMCL is included with the Content Server installation. The reason is that much of the functionality that is associated with the Content Server is actually implemented in external methods. In these cases the external method is a client of the Content Server and will utilise DMCL (via the API) to do its work. So really you need to be clear where the error is originating from. Does it arise from the external method code or does it arise from processing inside the content server?