Issue with publishing process

Hi All,

I came across strange issue with the publishing process in our environment.

We are using Documentum 6.5 SP1 and also using SCS 6.5 SP1 for publishing content from Documentum to target applications. We work with image files and xml content mostly.

We have post sync script that reads attribute data from Documentum and inserts that information in to target application database(MySQL). Once it inserts attribute data for the object in target database, it updates publish_flag (custom attribute) for that object to True in Documentum. When it updates the publish flag to true using DQL and that intern changing the r_modify_date for the object.

When publish process next time, SCS picks objects that are published last time b'coz the r_modify_date is different and trying sync the objects published last time( delete, export and sync on target system). However post sync script won't pick second time b'coz the publish_flag is already set to true. Virtually we are publishing same object twice with out any reason.

After lot of analysis and effort we figured out this issue, we have lot of performance problems with publishing process and then we tried executing queries used by SCS and found though we publish few object it tries to export thousands of object b'coz of above metioned issue.

For just testing purpose, I manually updated r_modify_date for a object previous time stamp in dm_sysobject table using SQL statement and it didn't pick in the export query used by SCS. I know it is not right way of doing, just for testing, I did it.

Does any one faced this kind of issue before?

Any inputs/ideas would be really appreciated.

Thanks in advance.

- Raju

Find more posts tagged with

Comments

DCTM_Guru

So you basically are marking content that you publish to the target, b/c you dont trust that SCS will publish everything? SCS is designed to publish everything that has been modified (root cause of your observation that SCS publishes object with new r_modify_date). Just wondering if there is any other reason for the publish_flag. If there is no other reason, what is the impact if you didnt update the publish_flag?

Assuming you still want to due this, your problem of "...it updates the publish flag to true using DQL and that intern changing the r_modify_date for the object" can be avoided by update the publish_flag column by using SQL (not DQL). SQL call will not trigger content server to update the r_modify_date. This is how we normally update objects as part of the application revision without impacting r_modify_date.

araju

Thanks a lot Johnny for your response.

The reason we added publish flag attribute is to simily DQLs in post sync script to identify the objects that are published and whose attribut data needs to be inserted in target database.

We are using MySQL as database on target system and SCS doesn't have support for MySQL, we wrote post sync scripts to publish the attribute data to target database. To make the DQL's simple we add publish flag to our custom object, so in post sync script I query objects which are in publish state and publish flag is FALSE and once I insert attribute data on target database, I commit transaction and update publish flag to TRUE in Documentum.So, next time when post sync job runs it won't pick the object that already published. Hope it make sense to you.

Hope I need to use SQL to update the publish flag instead of DQL to avoid this situation.

DCTM_Guru

Your scenario makes sense. Yes, using SQL is the only way I know to get around your problem.