Posts Tagged ‘package’

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:

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 »

We are working on a demo application and we had a need to retrieve the comments on an activity in a workflow. Today morning one of my colleagues approached me regarding the same. I was not of much help to her. Few hours later she figured out that the comments were to be retrieved from the package (dmi_package). I was disappointed because I realized that I knew it but it was lost somewhere in my mind. I decided to once again explore the comments in a workflow.

I remember that the comments are stored as objects of type dm_note. I fired a simple select query on my docbase for retrieving all the objects of type dm_note.

SELECT * FROM dm_note

While scrolling through the result, I noticed that the column for a_content_type was displaying the value ‘crtext’ for all the results. The content type ‘crtext’ is used for the txt/notepad documents and I recalled immediately that the comments are stored in the file store as txt files.
Thus, in a way dm_note is similar to dm_document. I was eager to check the supertype of dm_note. I used the following query for the same.

SELECT super_name FROM dm_type WHERE name = 'dm_note'

The result was dm_sysobject. I was on the right track. Even the txt file for dm_note should be stored as dmr_content. I was happy to find that the i_contents_id of a dm_note object was of the format ’06XXXXXXXXXXXXXX’. I used the same query to get the content file path on the file system which I have mentioned in my earlier post regarding dmr_content.


I got the following file path as a result:

I navigated to the mentioned file path on my file store and as expected 3c.txt had the comments that were entered in the workflow task.

As I knew that the attached documents in a workflow are actually linked to the package which in turn is linked to workflow, it was quiet logical that even the comments (the dm_note objects) are linked to the package. I found that the dmi_package has an attribute called r_note_id and it was repeating. This is the attribute which links the comments with the package. I checked the Object Relation diagram to confirm it.



I was correct in saying that the comments are linked to package much in a similar way as attached documents are linked to it.

I realize that I have left a gap regarding the linkage of documents in a workflow (package) and workflow in general. I will try to bridge it in my next post.

Read Full Post »