These two attributes are updated automatically with the save API. As it turns out, any time the save API is called against an object, the r_modify_date and r_modifier are updated. And the values are from the session. It is not possible to control these two attributes in DFC:

IDfDocument obj = (IDfDocument) session.getObject(new DfId(“XXXXXX”));

obj.setString(“r_modifier”, “UKOOM”);

System.out.println(obj.getString(“r_modifier”));

obj.saveLock();

System.out.println(obj.getString(“r_modifier”));  //the owner of the DFC session is returned rather than ‘UKOOM’.

There are three ways to turn off XML validation while importing or checking in XML files:

1. To permanently turn off XML validation in your repository modify the “format_class” attribute for the “xml” dm_format object.

By default the “format_class” is set to “XML”, which is a trigger for DFC XML processing. Removing the value of “format_class” will cause DFC to ignore all XML documents.

Run the following DQL query on your repository to permanently turn off XML validation:

update dm_format object set format_class = ” where name = ‘xml’

To change this behavior back to the original state and validate XML documents on import run this DQL query:

update dm_format object set format_class = ‘XML’ where name = ‘xml’

NOTE: If your XML documents have errors you will need to change the default application that opens your XML documents. Select an application that does not parse XML such as Notepad.

Warning!! If you use Content Transformation Services you cannot use this technique to turn off XML validation. Select from option 2 or option 3 listed below.

2. If you do not want all XML documents to be ignored then change the file extension to something other than “.xml”.

3. To disable XML validation on import add the processing instruction <”dctm xml_app=”ignore”"> to the xml file. This will halt the parsing algorithm.

Every XML application configuration file requires an XML declaration, a prologue, a processing instruction (that instructs the system to exempt this file from being processed by the Default XML Application), and a root element. That is:

<”xml version=”1.0″”>

<!DOCTYPE application SYSTEM “config_5.1.dtd”>

<”dctm xml_app=”Ignore”">

<application>…</application>
Therefore the third way to bypass the parser during import or check-in is to add the following line in the XML document after the XML declaration:

<”xml version=”1.0″”>

<”dctm xml_app=”Ignore”">

And I am not sure if below issue is related to the xml validation:

It is reported that XML content file is changed (CR/LF is changed to LF) )after importing or exporting from docbase. Why XML document which has \r\n (CR/LF) is changed to ‘\n’ (LF) after being exported or imported to/from docbase using Documentum client such as Desktop client?

==> It is due to XERCES XML parser is used all Documentum products except iTeam. The XERCES XML parser uses ‘\n’ (LF) only not ‘\r\n’ (CR/LF).

Original document imported document

——————-+————————–

\r\n => \n :changed

——————-+————————–

\n => \n :not changed

Step to reproduce it

Try to export any imported XML document which has ‘\r\n’ on Windows.

Check the exported XML file. ‘\r\n’ in the XML file is changed to ‘\n’

Note: If XML document is created on Unix, the return code is “\n”. so this is not a problem on UNIX but if the XML file is created on Windows env, the return code is “\r\n”.

* To visualize \r\n, please use the following UNIX command.

% od -c <file_name>

=> You can see

original document: \r\n

imported document:\n

You can count the number of subscriptions each user has like this:

select u.user_name as user_name, count(*) as subscription_count from dm_relation r, dm_user u where r.relation_name = ‘dm_subscription’  and u.user_name = (select user_name from dm_user where r_object_id = r.child_id) group by u.user_name;

To view all objects and users involved in subscriptions, use this DQL:

select r.r_object_id as relation_id, r.relation_name as relation_name,o.object_name as object_name, u.user_name as user_name from dm_relation r, dm_user u, dm_sysobject o where r.relation_name = ‘dm_subscription’ and u.user_name = (select user_name from dm_user where r_object_id = r.child_id) and o.object_name = (select object_name from dm_sysobject where r_object_id = r.parent_id) order by u.user_name;

You can also create subscriptions using DQL, you just need to know the r_object_id of the user (dm_user) and the r_object_id of the object (notionally a dm_document but it could be anything).  That DQL looks like this:

create dm_relation object set relation_name = ‘dm_subscription’, set parent_id = (select r_object_id from dm_document where object_name = ‘<some object name>’), set child_id = (select r_object_id from dm_user where user_name = ‘<some user name>’);

There are three important things to remember about creating subscriptions:

1. The name of the subscription (relation_name) must be ‘dm_subscription’,
2. The user’s r_object_id must be assigned to the child_id attribute of the dm_relation,
3. The document’s r_object_id must be assigned to the parent_id attribute of the dm_relation.

I recently had an interesting application for subscriptions.  During the processing of a case in a workflow, each participant that contributed to the case needed to have a quick and easy way to access the case, even after the task had left their Inbox.  This was true until the final disposition of the case, at which time their access to the case was revoked.  To accomplish this, I set up an automatic workflow method that created a subscription for the user just as the task was passing from their control to the next participant’s.  At the end of the workflow I ran a query that deleted all the subscriptions for the case (i.e., where parent_id = <r_object_id of case folder>).

This article is from http://msroth.wordpress.com.

Properties set in dfcfull.properties files are the default used.

To change those value copy the property from the dfcfull.properties file and paste into the dfc.properties file. Change the property value there will take effect.

NOTE: Some settings in this file such as tracing start when the file is saved. You should restart the application server to ensure it picks up new settings.

So don’t update the dfcfull.properties. 

1. Find the server.ini.  Usually it is located under $DCTM_DBA/config/<docbase name>

2. Find those database related items in the server.ini. For example:

database_conn = ornipoint.ukoom.com
database_owner = ornipoint
database_password_file = /ukoom/dba/config/ornipoint/dbpasswd.txt
service = ornipoint

3. Decrypt the encoded password in the ‘database_password_file’ (e.g. dbpasswd.txt’) using below command:

decrypttext, c,DM_ENCR_ TEXT=<Encrypted password here>

4. Using those information to connect to the database. Usually you can connect it in the TNS way.

Any questions please let us know.

Thanks,

UKoom

What happened??

That’s the ant version from Documentum Application Builder (DAB)!!!!  The path – ‘C:\Program Files\Documentum\Shared’ will be added into system variable – ‘PATH’ when installing DAB. And there are ant*.jar files in that folder.

Conflict!!!

So just move those ant*.jar files out or change the PATH setting temporarily.

Good luck.

BTW, it throws the exception :

java.lang.NoSuchMethodError: org.apache.tools.ant.util.FileUtils.getFileUtils()Lorg/apache/tools/ant/util/FileUtils;

If  this is not corrected when using ANT to execute build xml file.

Just a simple DQL is needed:  select r_workflow_id from dmi_package where any r_component_id=’<document id>’

Enjoy yourself please.

Of course we can set the immutable to false back and update the document and  set immutable to true again, we usually do this if we want to update an immutable document.

And When will the document become immutable in Documentum?

Below is the excerpts from one documentum developer’s note (his blog: http://ajithp.com). Hope it helps.

1. Versioning an Object (Sys object or any sub type of Sys object)
   When an Object is versioned (made a new version by check in) the old version of the versioned object becomes immutable
2. Branching an Object
   When you branch an Object the parent of the new Branched object becomes Immutable.In both the cases mentioned above Immutability of an object is controlled by an attribute with Boolean value called r_immutable_flag, which is part of dm_sysobject . Content server sets the r_immutable_flag to true on the old version of the object in both these cases.
3. Retention Policy
   If the Object is governed by a retention policy that makes its immutable then also the r_immutable_flag to true making the Object immutable.
4. Freezing a Document by calling freeze()
   Freeze method is used to explicitly set a object as immutable. When you call freeze method it sets r_immutable_flag to true and also sets r_frozen_flag to true.
   Setting r_frozen_flag to true indicates that freeze method is called on that object. In other words r_frozen_flag is set to true only if freeze method is called on that object, not by versioning branching etc.
   Unfreezing a Document
   Unfreeze method sets the value of r_frozen_flag to false and also r_immutable_flag to false and hence makes that object mutable again

Freezing and Unfreezing a Virtual Document
If you chose to freeze an associated snapshot in a Virtual Document, the r_has_frzn_assembly attribute is also set to TRUE on that Virtual Document object.

When you freeze a snapshot r_immutable_flag attributes for each component in the snapshot is set to true and also value of r_frzn_assembly_cnt is incremented. The r_frzn_assembly count attribute contains a count of the number of frozen snapshots that contain this component.

If value of r_frzn_assembly_cnt is greater than zero, you cannot delete or modify the object.

Calling a Freeze method to freeze a snapshot automatically freezes the document with which the snapshot is associated. To freeze only the snapshot and not the document, first execute a Freeze method and include the argument to freeze the snapshot then execute an Unfreeze method to unfreeze only the document.

Exceptions

Even though if an Objects is set to immutable there are some attributes of that object that can be changed, lets see what all are those attributes are

These are the attributes that content server can change on a immutable Objects

• a_archive
• i_isdeleted
• i_reference_cnt
• i_vstamp
• r_access_date
• r_alias_set_id
• r_current_state
• r_resume_stat
• r_frozen_flag
• r_frzn_assembly_cnt
• r_immutable_flag
• r_policy_id

There are few attributes that an application or a DQL can change on a Frozen Object

• i_folder_id
• a_special_app
• a_compound_architecture
• a_full_text
• a_storage_type
• Version label (r_version_label) Symbolic labels only
• acl_domain
• acl_name
• owner_name
• group_name
• owner_permit
• group_permit
• world_permit

Changing i_folder_id means you can link or unlink a Frozen document with any folders or cabinets)

I came across one strange issue today (actually I found this last Friday, but you know weekend coming, hehehe).

When using the update DQL to fill up one new column in the registered table, there are always lots of blanks appended.

The root cause after doing some investigation, what I found:

We are adding the column in type – char rather than varchar2 which is the normal one.

CHAR should be used for storing fix length character strings. String values will be space/blank padded before stored on disk.

Baiqing, one of my colleges , wrote the DQL to add the new column. I believe that:

1. He should be more careful

2. The DQL used to register table in Documentum are defining the type as ‘char’. Documentum is using ‘char’ type to define variable length character strings. there is no type to define fix length strings. That make developer confused.

Anyway, the cause was found. Happy Monday!!!!

Reference:

http://www.orafaq.com/faq/what_is_the_difference_between_varchar_varchar2_and_char_data_types

Webtop lets you check in a document as the same (existing) version. However, when you do this the Content Server never sees a checkin call or event. Webtop simply sets the new file as content, updates any changed attributes, and saves the object. So a dm_save event occurs rather than dm_checkin.

It becomes more obvious if we look at the corresponding API call descriptions.

• checkin – creates a new version of an object in the repository and removes the lock from the previous version.
• save – writes the object to the repository without creating a new version of the object.

Both of these methods have an optional argument to retain lock on the resulting object (new version for checkin and existing version for save). This argument defaults to FALSE – the lock is gone after the operation.

So why do we care? Normally we don’t need to. However, if we turn notification on for a document we need to remember this difference between checkin and save. By default, notifications are sent only for checkin event occurrences. So we won’t get a notification if the document was “checked in as same version”.

Similarly, other behavior (such as auditing) tied to events may be affected.

This article is from http://doquent.wordpress.com/2008/08/20/check-in-as-same-version/