Object Types involved in WorkFlow

March 26, 2008October 14, 2008 ~ Ajith Vallath Prabhakar ~ 2 Comments

Below is the table with different object types that has some role in workflow (5.3) with its description from Documentum Object Reference Manual

Object Type	Short Description	Detailed Information
dm_workflow	Contains the runtime information about a workflow.	A workflow object contains the runtime information about a workflow.
dm_activity	An activity object defines a workflow activity.	The attributes in an activity object define who performs the activity and the packages and work items generated from the activity.
dm_process	A process object contains the definition of a workflow process.	A process object is created when a user creates a workflow definition in either Workflow Manager or Business Process Manager. There are three inherited attributes that are reserved for internal use for process objects: a_special_app, a_status, and a_application_type.
dmi_workitem	Stores information about a task for a human or automatic performer.	Work items are generated by Content Server from an activity object. Users cannot create work items. Users can modify only the following attributes: a_held_by, a_wq_doc_profile, a_wq_flag, a_wq_name, and a_wq_policy_id.
dmc_workqueue	Represents a work queue for work items generated from a workflow	A work queue object represents a work queue for workflow tasks. The workqueue object type is installed by a script when Content Server is installed. However, work queues (instances of the type) are created and managed using Webtop.
dmc_workqueue_category	Defines a category for a work queue.	A work queue category object represents a category of work queues. The object type has no attributes defined for it. It inherits all its attributes from its supertype, dm_folder. It uses only the object_name, acl_name, and acl_domain attributes. The object_name attribute stores the work queue category name
dmc_workqueue_policy	Defines configuration information for a work queue.	A work queue policy object defines configuration parameters for handling a task in a workqueue. The parameters control how the items are handled. Each work queue has one associated work queue policy. If a document associated with a task has a defined work queue policy, that policy overrides the work queue’s policy.
dmi_wf_timer	Records the configuration of a timer for a workflow activity.	A wf timer object describes a timer for a workflow activity. The wf timer objects are created automatically when the timer is instantiated.

Download This Study Note (PDF)

Object Relationships in Documentum

February 26, 2008October 14, 2008 ~ Ajith Vallath Prabhakar ~ Leave a comment

Objects in the Documentum repository can be associated with Relationships. Lets explore the basics of Object Relationships here. There are 2 major object types that you need to know in

1) dm_relation_typeThis defines a relation, means this object type holds the information about the relation like its name, security type, parent type, child type etc. We will get into the details of this soon. User must have SysAdmin or Super User privileges to create object of this type. All the objects of this type will have r_object_id starting with 38

2) dm_relation This defines each individual relationship between the objects. Means this type has ID’s of the both parent and child object which makes the relation, the name of the relation etc. All the objects of this type will have r_object_id starting with 37

Now lest see the attributes of each object type and understand what each attributes is meant for and how these objects are related.

Lets list the attributes of type dm_relation_type

Name	Info	Description
relation_name	Char (32) Single	Name of the relation, This must be a Unique name.
security_type	Char (10) Single	This defines who can add, delete, drop or modify a relationship. The possible values are SYSTEM PARENTCHILDNONE(I will explain this in detail below)
parent_type	Char (32) Single	The valid object type of parent in this relationship
child_type	Char (32) Single	The valid object type of child in this relationship
description	Char (250) Single	Description of the relationship (User defined)
direction_kind	Integer Single	The Direction of the relation There are 3 Possible values for it. And they are 0 – This relation is parent to child 1 – This relation is child to parent 2 – This relation is bidirectional (means these objects are siblings) The default value is always 0
integrity_kind	Integer Single	This determines the referential integrity of this relation. There are 3 Possible values for it. And they are 0 – Allow Delete 1 – Disallow delete 2 – Cascade Delete (This means when a user deletes an object participating in a relationship instance, Server will also destroy the participating partner in the relationship) The default value is always 0
parent_child_label	Char (255) Repeating	User defined name for the parent child relationship
child_parent_label	Char (255) Repeating	User defined name for the child to parent relationship
permanent_link	Boolean Single	This defines what happens to the relation when the parent is copied or versioned. If set to True relation is maintained with new parent object.If set false the relation is not maintained. The Default value is False
copy_child	Integer Single	Specifies whether to copy the child in a relationship when the parent is copied and permanent_link is True. . There are 2 Possible values for it. And they are 0 – Do not copy Child 1 – Copy Child
a_controlling_kind	Char (32) Single	This indicates whether relationships of this type are created by users or internally.

Lets list the attributes of type dm_relation

Name	Info	Description
relation_name	Char (32) Single	Name of the relation that’s specified for the dm_relation_type object
parent_id	ID Single	ID of the parent object
child_id	ID Single	ID of the child object.
child_label	Char (32) Single	Optional version label of the child object. If this value is provided then I_chronicle_id of the object should be given as the id of the child in the child_id attribute.
permanent_link	Boolean Single	<Deprecated>
order_no	Integer Single	Not used, but can be used for custom purpose
effective_date	Date Single	Not used, but can be used for custom purpose
expiration_date	Date Single	Not used, but can be used for custom purpose
description	Char (255) Single	Description of the relationship (User defined)

The relation between dm_relation_type and dm_relation type objects is illustrated below

Relation Dig-1

Few bullets points about dm_relation and dm_relation_type

Niether dm_relation nor dm_relation_Tupe can be versioned
Object level security (ACL) cannot be set on these object types
You cannot delete a dm_relation_type object if any of the dm_relation with its relation_name exists.
You need super user privileges to delete a dm_relation_type object
Destroying a dm_relation object does not destroy the parent or child objects.
When you destroy an object all the dm_relation associated with that object also gets deleted.

Security and Relations

When we saw the attributes of dm_relation_type object I had mentioned about security_type. Lets see this in detail. As mentioned above security_type defines who can add, delete, drop or modify an object of dm_relation object, which has a relation name that of the relation_name in the dm_relation_type. Lets see what the individual possible values means here

SYSTEM
This means only SuperUsers and SysAdmins can create, edit or delete a relation with the relation_name in this type. This does not prevent an owner of an object from destroying an object that participates in the relationship. When a Objectis destroyed content server also destroys all relation objects associated with the object. The owner of that Object is not required to be a superuser or system administrator.
PARENT
This means create, delete or edit a Relation will depend upon the users permissions on the parent object. I.e. if the object that’s getting related is of object type dm_sysobject or its child user should at least have RELATE permission.
CHILD
This means create, delete or edit a Relation will depend upon the users permissions on the Child object. I.e. if the object that’s getting related is of object type dm_sysobject or its child user should at least have RELATE permission.
NONE
This means Any user can create, delete or edit a Relation of this type.

Download this Study Note (PDF)

Documentum Composer A boon for the Developers !!!!

February 1, 2008February 4, 2008 ~ Ajith Vallath Prabhakar ~ 6 Comments

After a long wait Documentum Composer is out. And its time to say goodbye to Application builder, Application Installer I was really excited to see the composer and believe me it was really user friendly, As expected I could see few errors happening in Error log of the Composer but its working fine. Anyways it looks like a good start. Once you download the Composer and unzip it, make sure that you go to <DocumentumComposer>\plugins\com.emc.ide.external.dfc_1.0.0\documentum.config\dfc.properties add your connection broker information to it.
I created a Aspect using it and deployed it to the Server, The UI of Composer looks pretty much intuitive and easy to use. I am adding a screenshot of the Composer for people who where waiting to see it. I will be adding more about my composer Experience soon

Renditions in Documentum

February 1, 2008March 13, 2018 ~ Ajith Vallath Prabhakar ~ Leave a comment

A couple of days ago someone had asked me about Renditions in Documentum, Let me try to explain very briefly what renditions are.

Renditions are Representations of a Document in a different format. In other ways, the only difference between a document and its rendition is only its format. When you create a document in Documentum you specify the file format for that object, this file format is the Original format of that object. The renditions of this object have the same properties of the original format object but it’s in a different format. These renditions are made either using Documentum Media Transformation Service or the supported Converters.

The Converters are basically for Transform one type of graphic image to another type (e.g.: TIFF to JPG) or one-word processing format to another word processing format (e.g.: PDF to MSWord). There are few converters that come with the Content server, you can either buy or make your own custom converters. I am not getting into details of Converters here.

When you request for a rendition that uses converters Content Server creates and manages the Renditions automatically. You can also add renditions manually.
If you wanted to add renditions manually you can create the rendition by your own means and use addRendition() IDfSysObject interface.
For removing a rendition use removeRenditon() of the same IdfSysObject interface. You have to have at least write permission to remove rendition of a Document.

Registered Tables in Documentum

January 24, 2008September 8, 2009 ~ Ajith Vallath Prabhakar ~ Leave a comment

Registered tables are the tables that are present database which are registered in Documentum, so that it can be accessed using DQL. Basically Registered tables are used when the application needs to access data from the RDBMS within the Documentum. This can be either a Table or a View. The Scenarios where I mostly used registered tables are for providing value assistance for Object attributes. I am not getting into too much of details about Value Assistance here, Value assistance is a list of values that a client program (such as Webtop or a Custom WDK Application) displays at runtime for an object attribute. A user can select a value from this list (or, if allowed, add a new one to it). You can set the Value assistance for an Attribute using DAB (Documentum Application Builder).

As I mentioned above uou can register a Table or a view as a Registered Table, The Registered tables are stored as dm_registered objects in repositories. This extends dm_sysobject. And the r_object_id of this type always starts with 19. The following table lists the attributes of dm_registered

Name	Info	Description
column_count	Integer – Single	Number of columns in the table.
column_datatype	string(64) – Repeating	List of the datatypes of the columns.
column_length.	integer R	Lengths of the columns that have a string data type
column_name.	string(64) – Repeating	List of the names of the columns in the table
group_table_permit	integer – Single	Defines the RDBMS table permit level assigned to the registered table’s group.
is_key.	Boolean Repeating	Indicates if an index is built on the column
owner_table_permit	integer – Single	Defines the RDBMS table permit level assigned to the registered table’s owner
synonym_for	string(254) – Repeating	Name of the table in the underlying RDBMS (can be an Oracle table synonym, or an MS SQL Server or Sybase table alias)
table_name	string(64) Single	Name of the table.
table_owner	string(64) Single	Name of the owner of the RDBMS table (the person who created the RDBMS table).
world_table_permit	integer – Single	Defines the RDBMS table permit level assigned to the world

You should either own the table or have super user privileges to register a table. And since this object is linked with /system cabinet you should have write permission on /system cabinet. This is applicable only if the folder security is enabled in Repository

You cannot version a dm_registered object. And also the changes made to the table are not automatically updated in dm_registered object. So if any changes has been made to the structure of the table or view you should unregister it first and register the table again with changes.

How to Register a Table?

Use the following DQL to register a table. REGISTER TABLE [owner_name.]table_name (column_def {,column_def}) [[WITH] KEY (column_list)][SYNONYM [FOR] ‘table_identification‘] This DQL will return the r_object_id of the newly created dm_registered object. In this owner_name is the name of the table owner. table_name is the name of the RDBMS table. column_def defines the columns in the registered table.

column_def arguments should have following syntax column_name datatype [(length)] the valid values for types are float, double, integer, int, char, character, string, date, time.

Length should be specified for character, char, or string data type.

column_list Identifies the columns in the table on which indexes have been built. column_list is usually separated with commas. table_ identification is the name of the table in the Database Example:

Granting Rights

You need to give the permission to the users to access the registered tables. The values for various permission levels are as follows 0 (None): No access 1 (Select): The user can retrieve data from the registered table 2 (Update): The user can update existing data in the registered table4 (Insert): The user can insert new data into the registered table8 (Delete): The user can delete rows from the registered table If a user wants update and insert permissions the value should be 2+4 = 6 , The repository owner also should have the same level of permission in the underlying database to grand those permission to those users. Granting Rights full permission to users in the above example

update dm_registered object set world_table_permit = 15 where object_name = ‘users’;

update dm_registered object set owner_table_permit = 15 where object_name = ‘users’;

update dm_registered object set group_table_permit = 15 where object_name = ‘users’;

How to Unregister a Table?

Use the following DQL to Unregister a Table.

UNREGISTER [TABLE] [owner_name.]table_name In this owner_name is the name of the table owner. table_name is the name of the RDBMS table. You should be the owner of table or super user to do this

Accessing Data from Registered Table

Just like in RDBMS you can access registered table using the following syntax

Select [ATTRIBUTES] from dm_dbo.[REGISTERED_TABLE_NAME] where [CLAUSE]

The Operations such as update/ delete also has the same RDBMS syntax that’s used for a ordinary SQL, Only difference is prefixing dm_dbo to the table name

Example:
Select first_name, last_name, emp_id from dm_dbo.users ;

Updating Data in a Registered Table

Example
Update dm_dbo.users set first_name=’John’ where first_name=’Smith’

Deleting from a Registered Table

Example

Delete from dm_dbo.users where first_name=’Smith’

Download this note on Registered Table (PDF)

Installation Issues of Documentum 6 SP1 Content Server on AIX

January 18, 2008January 24, 2008 ~ Ajith Vallath Prabhakar ~ Leave a comment

We had done a D6 SP1 installation few days ago and ran into some issues, I thought I will share my expereince with you all so that you know the issues that you may face during the installation of content server on AIX.

As we stared with the installation of Content Server on our AIX system (5.3) we were hit with the following error

“The /tmp filesystem needs 1GB where it has 0 GB Available” We had more than 1 GB space in both /var/tmp and /tmp.

During this I found an interesting thing that even the D6 Installer guide has lots of typos in it. It says /tmp some place then someother place it says /temp should have 1 GB free space !!!!

If you are hit with this issue there is a work around, You have to add the tmp directory location as parameter to the installer.

That means you have to run the installer with following command line

serverAixSuiteSetup.bin -is:tempdir TMP_DIR

Where TMP_DIR should point your tmp directory which has more than 1 GB Space.

Another interesting issue is Though the D6 Installer guide in page number 143 says that if you run dm_launch_server_config_program.sh it will set the environment variables such as LIBPATH etc that doesnt really do that. So if you are installing D6 CS on AIX after completing the installtion make sure sure that you edit the profile of install owner and add these paths to it

Happy Installing !!!

Aspects the new BOF type in Documentum

January 18, 2008January 24, 2008 ~ Ajith Vallath Prabhakar ~ 2 Comments

Aspects

Aspects, the new member in the BOF family is one among the new additions to the Documentum 6 (D6). This short notes are just to give you insight to the fundamentals of Aspects.

What is Aspects?

In simple words Aspects are like TBO’s but they are not associated with any object types. That means you can attach or detach an Aspect at runtime to any object type. In other words Aspects are a mechanism for adding behavior and/or attributes to a Documentum object instance without changing its type definition (From DFC Study Guide)

Aspects like any other BOF types are stored in the repository. When a DFC runtime requests for a Aspect it will be downloaded to that system and used. Aspect belongs to the type dmc_aspect_type.

Aspects are saved in /System/Modules/Aspect in the repository which has a global registry. If any changes are made to any aspects DFC runtime detects that and downloads the latest version to its local cache of BOF.

What Aspects can do?

Aspects are different from other BOF’s because it is attached to the Object instance, not to the object types. They are not a per-application customization. Any Persistent object instance can have multiple aspects attached to it if each aspect has a unique name.

Aspects define custom additional fields and it can set custom values to the fields of any object that of type persistent object. There are no restrictions for the type of and number of attributes that you can create on an aspect. It can be of any supported types and be either a single value or a repeated value attributes.

Another aspect can access the Attributes defined in one Aspect. The Fully qualified aspects attributes are aspect_name.aspect_value. When you fetch an Object all values of attributes of attached aspects are also fetched. If you destroy an object it also deletes the attributes in the attached aspect.

Where Can I use it?

Aspects are used when you have a cross type functionality to be defined. When you create a application infrastructure or a corporate platform Aspects are the best way to implement business functionality which is common between different object types. When you have some functionality that is per instance based then also Aspects is the solution.

Lets see a real time scenario where you can use Aspect.

Lets imagine a scenario where you have system, which has user base of different countries, depending upon the country where a user belongs the behavior and fields of the application changes. You can create different aspect, which has the country specific behaviors and fields, and attach it as needed. If the user changes from one country to another simply remove the old country aspect and attach the new country aspect.

To be Continued ….

DFS Data Model Explained

January 12, 2008October 14, 2008 ~ Ajith Vallath Prabhakar ~ Leave a comment

Hi All

As I am exploring the new DFS I am noting some points that I can share with you guys. I know I cannot explain everything about DFS here As like you I am also learing but I will try to give an overall picture of What DFS is all about here. Please visit this blog often as I keep updating this.

DFS Explained

Documentum Foundation Services the SOA face of Documentum. The remote invocation of DFS is implemented using SOAP based web-services. The beauty of DFS is that though DFS is exposed for the remote usages as Web Services it can be called locally using DFS Client libraries. DFS allows the migration easy by allowing services to be developed on existing BOF (Documentum Business Object Framework) also.Another interesting point about this is DFS consolidates the numerous inter depended methods into a Single Service. The DFS data model is expressed in both Java client library class and also in Service XML Schemas. This provides a consistent approach to model data that will be exchanged between the various business processes. As mentioned above the DFS clients can be of two types.

Applications (Consumers) written any language that can use WSDL to interact with DFS.
Clients written on java that uses DFS Java Client library

Data Model of DFS The data passed to and from the Services are encapsulated into DFS Object Model These are the few important object types on DFS

DataPackage
DataObject
ObjectIdentity
Property
Content
Permissions
Relationship

Lets see what all these does now

DataPackage

According to the DFS Reference Guide from EMC The DataPackage class defines the fundamental unit of information that contains data passed to and returned by services operating in the DFS framework. That means DataPackage is a collection of DataObject Instances, which is passed back and forth by Object Service Operations. In other words when you call services like Create, Get, Update the Data Object Instances are passed using DataPackage class.

It’s like an Envelope for putting various DataObject Instances. Object service operations process all the DataObject instances in the DataPackage sequentially.

DataObject

A DataObject is the DFS representation of a Persistent Object in Documentum Repository. DataObject potentially has all the information related to an Object in repository. This includes the Content, properties (Both Single and Repeated), relation with other Objects in repository, Its permissions etc. Due the nature of these objects, Data Objects are very complex.
Optionally these object instances may have instructions to services about how the parts of Objects have to be processed.
The type field of DataObject class represents the underlying typed object type name that corresponds to the Object Instance. For example dm_user, dm_document etc. default type is dm_document. I.e. if no type is specified then service implicitly assign that to type dm_document

DataObject

ProperySet

Content

ObjectIdentity

Permission

Relationship

The above Figure represents a DataObject.

ObjectIdentity

As the name says this represents a Unique Object in the Repository. An instance of this class must have the repository name and a unique identifier for that object. The value that represents a repository object may be any of the following

OBJECT_ID – Contains r_object_id of the Object (Represents both Current Object and Non Current Object)
OBJECT_PATH – Contains String expression of the path of the Object in repository
[Cabinet]/[Folder]/[File_Name]
(This Represents only Current Object. Since you can create multiple objects with same name in same directory this does not guarantee uniqueness of the object)
QUALIFICATION – DQL Snippet that qualify an Object uniquely
(The DQL Snippet is the Full DQL that follows the keyword FROM. E.G. dm_document where r_object_id=’09xxxxx’)

Note: During the Creation of the object all you need to populate is only repository name.

Property

Each Property represents an Object Attribute (Property) in the Documentum Repository. Property Set is a collection, which works as a container of multiple Property Objects

As there are 2 types of Properties for an Object a property can either be a Single property (Single Value Attribute) or Array Property (Repeated Attributes). Property class has been sub classed to accommodate various data types and they are as follows.

StringProperty
NumberProperty
BooleanProperty
DateProperty
ObjectIdProperty
ArrayProperty (Abstract Class)		®
	StringArrayProperty
	NumberArrayProperty
	BooleanArrayProperty
	DateArrayProperty
	ObjectIdArrayProperty

Transient Property

These properties are not the part of persistent properties of a repository object. Transient Property can send custom data fields to a service to be used for a purpose other than setting attributes on repository objects.

Array Property and Value Action

The Repeating Attributes of an Object type is represented as Array Properties. As you can see in the above table The ArrayProperty is an array of the corresponding single property. Another Interesting aspect of Array Property is Value Action. Now lets see what value action is all about? This is an optional Action – Index mapping pair. These pair has the instruction as to what is the action to be done on a particular element of the ArrayProperty. The Index is the position in the attribute and Action is what is the action to be performed on that element of that index. The possible ActionTypeValues are

Append
When processing ValueAction[p], the value at ArrayProperty[p] is appended to the end of repeating properties list of the persistent repository object. The index of the ValueAction item is ignored.
Insert
When processing ValueAction[p], the value at ArrayProperty[p] is inserted into the repeating attribute list before position index. Note that 1, which must be accounted for in subsequent processing, offsets all items in the list to the right of the insertion point.
Delete
The item at position index of the repeating attribute is deleted. When processing ValueAction[p] the value at ArrayProperty[p] must be set to a empty value.
Set
When processing ValueAction[p], the value at ArrayProperty[p] replaces the value in the repeating attribute list at position index. (From DFS Development Guide)

Content

Content Class or its Subclass instance represents the actual File Content associated with a DataObject. DataObject can have zero or more Content objects. It can hold Renditions also. Content class object can be configured to hold following

The Whole Document
Page of a Document
Pages (One or More) which has been represented by the characteristic

Permissions

A DataObject has list of Permission Objects, which decides the permission of the object that’s represented by the DataObject. The permission list provides read access to the permission on an object in repository by the user who has been logged in currently.

Also have to note an interesting point here that You Cannot change permissions on a repository object by changing the Permission list and saving the DataObject.

For changing permissions of a repository object the real ACL of that object has to be edited or replaced. As mentioned above multiple Permission Objects creates Permission List. The Permission Object has a field named permission Type that sets what type of permission is set. The values possible for these fields are BASIC, EXTENDED or CUSTOM Another important thing about permissions are if you assign one particular permission for one user to one object, all the lower lever permissions below the assigned permissions will be granted to that user. This is known as Compound or Hierarchical Permissions PermissionType Enum Constants (From DFS Guide)

PermissionType	Permission	Description
Basic	NONE	No access is permitted
	BROWSE	The user can view attribute values of content
	READ	The user can read content but not update.
	RELATE	The user can attach an annotation to object.
	VERSION	The user can version the object.
	WRITE	The user can write and update the object.
	DELETE	The user can delete the object.
Extended	X_CHANGE_LOCATION	The user can change move an object from one folder to another. All users having at least Browse permission on an object are granted Change Location permission by default for that object.
	X_CHANGE_OWNER	The user can change the owner of the object
	X_CHANGE_PERMIT	The user can change the basic permissions on the object.
	X_CHANGE_STATE	The user can change the document lifecycle state of the object.
	X_DELETE_OBJECT	The user can delete the object. The delete object extended permission is not equivalent to the base Delete permission. Delete Object extended permission does not grant Browse, Read, Relate, Version, or Write permission
	X_EXECUTE_PROC	The user can run the external procedure associated with the object. All users having at least Browse permission on an object are granted Execute Procedure permission by default for that object.

Relations

Relationship allows creating a Single DataObject that specifies all the relations that it has with other objects existing and new. This also allows single service call to get, update or create the whole set of objects and its relationships. Relationship has two subclasses
Object Relationship &
Reference Relationship
These classes define all the relationships that a (any) object in repository can have. This represents existing relations, also can add new relations, which can be updated in the repository using service calls.

According to DFS Developer guide The repository defines object relationships using different constructs, including generic relationship types represented by hardcoded strings (folder and virtual_document); dm_relation objects, which contain references to dm_relation_type objects; and dmc_relationship_def objects, a representation provides more sophistication in Documentum 6. The DFS Relationship object provides an abstraction for dealing with various metadata representations in a uniform manner

ObjectRelationship

ObjectRelationship represents relationship to a new or existing repository object. It can be used by the update operation to either update or create Content objects. This when called with update operation modify/ create the target objects

ReferenceRelationship

A ReferenceRelationship represents a relationship to an existing repository object and is specified using an ObjectIdentity. This object can (only) be used to create a relationship between two objects. This will not create or update the target objects.

Download this study note (PDF)

Changing the Repository Owner Password in Documentum

December 17, 2007October 14, 2008 ~ Ajith Vallath Prabhakar ~ Leave a comment

Follow thse steps to change the Repository owner password in Documentum Content Server

Stop the Repository
Go to $DM_HOME/dba/config/<repository name>/
Create a copy of the file with name dbpasswd.txt
In the DB change the password of Repository Owner
Edit the dbpasswd.txt( The file backed up in Step 3) and replace the new password as plain text
Save dbpasswd.txt
Go to $DM_HOME/bin run the following
dm_encrypt_password -docbase <docbase name> -rdbms -encrypt <database password>
Restart the Repository

What is the significance of i_vstamp and i_is_replica

November 16, 2007October 14, 2008 ~ Ajith Vallath Prabhakar

These are the properties defined in Persistent Object Type and inherited to all its subtypes

i_vstamp
This property is basically used for versioning, each time you save changes to the object the value of this property increases by 1 and this also helps to check the concurrent modification of object.

i_is_replica
this property of object that indicates whether that object is replica of an object in a remote repository