Feeds:
Posts
Comments

Posts Tagged ‘r_object_id’

Workflow represents a Business Process.

A Workflow Defination consists of multiple Activities which can be Manual or Automatic. Manual Activities are performed by a Performer or a User whereas an Auto-Activity is generally performed by a program on behalf of a user (using a User’s session). The program used for Auto-Activity has to follow certain guidelines. The class should implement IDmMethod or WorkflowMethod and accordingly it should implement execute or doTask from the corresponding interface. This program is configured as a workflow method, an instance of dm_method with its a_special_app property set to ‘Workflow’. It can be created using DAB or DA + DQL. The Manual activities are made available to the Performers in their inbox as task.

The activities are linked through flows. Flows have Packages associated with them. It’s mandatory for Flows to have at least one associated Package. The ending flow is an exception which doesn’t have any associated package. A Package specifies an object type whose objects can be attached in the package as attachments. A flow can be a Normal Flow or a Reject Flow. A Reject flow is represented by a red line in the Workflow Template. Using a Reject Flow in a Workflow Template automatically generates a Reject button in an inbox task.

Object Types:
The workflow template/definition                        : dm_process
The constituting activities                                    : dm_activity
The running instance of workflow                        : dm_workflow
The running instance of activity                           : dmi_workitem
The package associated with a workflow            : dmi_package
The representation of manual activity in inbox    : dmi_queue_item

Object Relationship:
WorkflowObjectModel1

A document attached in a Workflow:
A document is actually attached to a package which in turn is associated with a flow in a workflow. As seen in the Object Relation diagram above:

 

dm_workflow dmi_queue_item dmi_package dm_sysobject
(workflow) (inbox) (package) (document)
r_object_id = router_id = r_workflow_id
r_component_id(Rep) = r_object_id

Keeping in mind the above relation, the below mentioned DQL query can be used to find out the documents present as workflow attachment in a user’s inbox.

SELECT DOC.r_object_id, DOC.object_name
FROM dm_document DOC, dmi_package PACKAGE, dmi_queue_item INBOX
WHERE INBOX.name = 'Uttkarsh'
AND INBOX.router_id = PACKAGE.r_workflow_id
AND any PACKAGE.r_component_id = DOC.r_object_id
AND INBOX.delete_flag = 0

Vice-Versa if the document is present as a workflow attachment and its properties are known, the following DQL query can be used to find the User in whose inbox it is present.

SELECT name, task_name
FROM dmi_queue_item INBOX, dmi_package PACKAGE, dm_document DOC
WHERE DOC.object_name = 'queries.txt'
AND any PACKAGE.r_component_id = DOC.r_object_id
AND INBOX.router_id = PACKAGE.r_workflow_id
AND INBOX.delete_flag = 0

In addition to above, an Administrative Method GET_INBOX can also be used to get the details of task in a user’s inbox.

EXECUTE GET_INBOX with name = 'Uttkarsh'

Guess that’s enough for this post. Hope you enjoyed reading it. 🙂

Read Full Post »

Here is a new attempt to implement Alias Set and ACL Template in a way that can be more meaningful. The Major drawback in the previous implementation was that the Alias Set was associated with a single user. As the ACL Template was always being assigned by the same user, every time Alias was resolved to the same value unless the user was associated with a new Alias Set.

Alias Sets can be used in a much better way if the Alias can be resolved to different values at different instances. One of the easiest ways to achieve it is by associating the Alias Set directly with the Sysobject. If it was followed in previous case, different ACLs could have been applied to different Sysobjects while using only one ACL Template and multiple Alias Sets.

The attribute of dm_sysobject that is responsible for its relation with an Alias Set is r_alias_set_id. It stores the r_object_id of the Alias Set. It appeared to me that the only possible (and meaningful) way of associating a Sysobject and an Alias Set should be through DFC. I started my search for a method of IDfSysObject that can be used for the purpose. But I failed myserably in my effort. I couldn’t find a method as per my expectation. Finally I resolved to my ultimate rescuer, Google. I found a post regarding Permission Set Template by Johnny. In his comments he has mentioned, “I manually set the r_alias_set_id directly against the object that I am assigning the PST to.” I was surprised at the ease and simplicity of his statement. I was trying to achieve the same. I had an understanding that the r_ attributes are read-only with r_version_label being an exception. Still I descided to try the setString method of IDfSysObject.

The Field Setup:

Five Users created: TestUser1, TestUser2, TestUser3, TestUser4, TestUser5.
Five Alias Sets: TestUserAlias01, TestUserAlias02 …. TestUserAlias05.
An ACL Template: TestACLTemplate

Each Alias Set has a corresponding user name as the Alias Value. The process of creating the set-up was similar to that in the earlier case.

The Game:
Following is the fragment of DFC code used. Five objects of type dm_document are created, they are associated with corresponding Alias Sets and finally the ACL Template is applied on the newly created objects.

***************************************************************

for(int i=1; i<= 5; i++){
IDfDocument document = (IDfDocument) dfSession
.newObject("dm_document");
if (document != null) {
document.setObjectName("TestAliasObject_00"+i);
document.setContentType("pdf");
document.setFile("C:Test.pdf");
document.link("/dmadmin");
// can be a business logic
document.setString("r_alias_set_id",
dfSession.getObjectByQualification
("dm_alias_set where object_name = "
+"'TestUserAlias0"+i+"'")
.getObjectId().toString());
document.setACLName("TestACLTemplate");
document.setACLDomain("ASSAPArchive");
document.save();
}
}

***************************************************************

The main concern was the highlighted statement. Before reading Johnny’s post there was no reason to believe that it can ever work.

It was established that the understanding regarding r_ attributes was a misconception. At the least there is one more attribute which is an exception to the rule. Updating r_alias_set_id through DQL was also successful.

Anyway, my part in the game was over and it was time to verify the results.

Result:

testaliasobjects

Benefit:
Consider a case where the permission of all the users has to be changed from Write to Version. In the current set-up it can be achieved by updating only the Template Permission Set. If instead ACLs were used, all of them would have to be updated individually.

Related Articles:

Read Full Post »

Where are the documents (contents) stored in repository? Is it possible to find the documents by navigating to them in the file system? The question has been bothering me for quiet some time. I have heard lot many answers regarding this but I was never convinced. Till few weeks ago, in my earlier organization I was loaded with so much of work that I could never explore it myself.

Couple of weeks ago in an interview one of my colleagues asked the candidate about dmr_content. Later when I asked him he told me that the contents of renditions are stored as dmr_content. In an another incident that happened yesterday another colleague asked me about dmr_content while I was making a presentation on Object and Types. I recalled that a friend had told me once that the content of a deleted document can be retrieved using dmr_content. She was not satisfied with the response.

These incidents had developed enough curiosity in me about dmr_content. It was now my turn to explore it myself.

I checked the Object Relational Model. The i_contents_id of dm_sysobject (or it’s subtypes such as dm_document) is linked to the r_object_id of dmr_content. dmr_content also has a repeating attribute called parent_id which is linked to the r_object_id of dm_sysobject.

I was able to establish the relation between dm_document and dmr_content. The actual document or the content is stored as dmr_content and it is linked to dm_document which stores the metadata. In fact all the contents are stored as objects of dmr_content. That is the reason for creation of a new dmr_content object when we create a rendition.

But why is the parent_id a repeating attribute? It should mean that many dm_document objects can be linked to a single dmr_content object. Does that make sense? I performed the following operations on a document in order to check that.

  1. Check out a document and check it back in as a new version without making any changes to it.

  2. Create a copy of a document.

In both the cases a new object of dmr_content was created and the new document/version got linked to it. Interestingly even when I checked in the document as the same version, a new dmr_content object was created. The deletion of dm_document did not delete the associated dmr_content object either. Both of the above mentioned operations had resulted in the creation of orphan dmr_content objects. I read on a forum that the dm_clean job removes all such orphan objects. So, until the dm_clean job runs, it is possible to retrieve the content of a deleted document. Further the content files on the host file system which doesn’t have a referring dmr_content object are deleted by dm_filescan job.

Here is the most interesting part and the answer to the introductory question: I found this DQL query in the discussion forum of powerlink.
EXECUTE GET_PATH FOR ‘06XXXXXXXXXXXXXX’

This was the thing I was looking for. In order to verify it I imported an image file named object_type.jpg in my repository using DA. I used the following query to find the r_object_id of the dmr_content it was associated with.

SELECT r_object_id
FROM dmr_content
WHERE any parent_id in
(SELECT r_object_id
FROM dm_document
WHERE object_name = 'object_type.jpg')

Alternatively, the following query can also be used.

SELECT i_contents_id AS DMR_CONTENT_ID
FROM dm_document
WHERE object_name = 'object_type.jpg'

The return value of the query was ‘060003f08000c93e’. This value was used as input for the second query.

EXECUTE GET_PATH
FOR '060003f08000c93e'

Any guesses? The query returned me the following content path.

C:/Documentum/data/ASSAPArchive/content_storage_01/000003f0/80/00/59/e2.jpg

The e2.jpg was same as the object_type.jpg which I had imported. In other words, the file was stored in the host file system but it was renamed. GET_PATH is an Administration method and can be found under Administration >> Job Management >> Administration Method node in Documentum Administrator.

I am sorry but I don’t want to indulge in any more puzzles now. You can get some help in Robin’s Post if you want to understand the logic of resolving the content path of dmr_content. As per Object Relational Diagram, the storage_id and data_ticket attributes are used to refer to the content stored in the host file system.

In the end I got the answer for the long standing question. But one question remained unanswered. Why is parent_id a repeating attribute? Any thoughts on that?

Related Articles:

Read Full Post »