How to recognize (programmatically) situation ‘property value has changed in object’?

I am beginner in Documentum yet (all I have now is Documentum Developer Edition); so advice from an experienced Documentum developer will be very helpful. I need to create a program (on .NET) that will be monitoring specified Documentum Content Server looking for situation ‘property **** in an object of certain type has changed its value to YYY’.

More detailed example: my program monitors dm_document objects to detect situation ‘a_status has changed its value to ToBeExportedOutside’. After this the program retrieves the document and then exports it to another document management system.

Another example: my program monitors dm_document objects to detect situation ‘the document has been promoted to state ToBeExportedOutside in lifecycle it is attached to’. After this the program retrieves the document and then exports it to another document management system.

The question is: how it is better to do it using DFS?

Find more posts tagged with

Comments

gcampos

I think that DFS is complicated to consume because of its data structure, even if you use a proxy or productivity layer, and it's not very performatic, it could take a while depending on how many documents you will be searching/exporting.

I would take another approach writing a Java/DFC job that queries for the information and does the export, using the ootb scheduling/job mechanism.

Regards

lastnitescurry

agreed with Gustavo... DFS does not make sense for this solution.... odds are you have been directed to this technology because your app will run on the destination DMS.....

My solution choice would be a TBO or Aspect on your documents. The TBO/Aspect would check if the status attribute for export flag... if item is marked to be exported then send a note to a queue or web serivce... Your .Net program can poll the queue or react to web service call and handle the content export via DFS & UCF

TBO/Aspect would be written in Java, and would fire on the doSave event.

IF working with a pre 5.3 content server, then TBOs are not avaible, do as Gustavo suggested and write a method & job combo

If you can not make changes to the Documentum setup, then get your DBA gurus to create a READ ONLY view of the dm_sysobject_s table, filtered by a_status = 'ToBeExportedOutside' and r_object_type = 'dm_document'... polling that with your .Net program you can locate new items to be exported

bacham2

I don't see why it does not make sense to use DFS. If you need/want to use .NET, then DFS is definitely the way to go. Performance-wise, there shouldn't be any issues either.

GlenLantz

I have just started reading about Documentum's 'events'. Is not the following approach will work:

my program uses DFS to periodically scan events that took place. If I see (for lifecycles case) event dm_bp_promote, I understand that an object has been promoted; and I test it - has it been promoted to state ToBeExportedOutside?

aflowers001

You could look to do this with a TBO that generates events when it finds changes that require one.

For example the TBO could override onSave() [if memory serves] and if it finds that it is saving a document with a_status == 'ToBeExportedOutside' then it can take an action such as writing this to an 'event queue' such that a job or some other process can pick it up and act upon it. You could also asynchronously execute a method to di it is pseudo realtime as well or kick off a workflow passing in the document id and have the workflow do the export externally.

GlenLantz

Looks good..but such TBO has to be written on Java, correct? I am asking this because of my main knowledge is .NET. TBO cannot be written on .NET?

aflowers001

You are correct. TBO is a Java based technology.

If .NET is the only technology that you can work with then you are limited to either DFS and polling.

GlenLantz

Thank you.

One more question. You said ‘to either DFS and polling’:

Using DFS I can periodically issue DQL queries like the following:

select * from dm_document where a_status='ToBeExported' and r_modify_date > TimeOfPreviousScan

Such query will bring all objects dm_document (and its subtypes) that have 'ToBeExported' in its Status - ones where the Status became 'ToBeExported' after previous scan.

Also:

I can periodically scan table dmi_queue_item – this is where ‘events’ are registered. When a document will be changed, dm_save event will be added into table. So I can query list of dm_save events that have happened since previous scan; then for each of the events look: does it relate to a document, and does the document has 'ToBeExported' in its Status. Usage of dmi_queue_item will allow me not to re-scan whole documents set every time.

Am I correct; or I am missing something important

Could you please explain what you mean as ‘polling’ here?

GlenLantz

"If you can not make changes to the Documentum setup, then get your DBA gurus to create a READ ONLY view of the dm_sysobject_s table, filtered by a_status = 'ToBeExportedOutside' and r_object_type = 'dm_document'... polling that with your .Net program you can locate new items to be exported"

yes, thsi is what I initially planned to do: issue queries like select r_object_id from dm_document where a_status='ToBeExported' and r_modify_date > '2011-02-18'

The 'view' you mentioned will do the same, but also accelerate execution of the DQL queries, correct?

DavidHaveman

One great addition would be to update the a_status feild to be a value like "Exported" after the export has taken place (assuming the business logic allows this change ), then your query wouldn't have to care about r_modified_date.