eliminate files marked as private

Sometimes jobs will create private files and attach them to tasks. I would like to have an ExternalTask at the end of each job that deletes these files. My question is, should it be called "PrivateRemover" or "PrivateDetacher"? I prefer PrivateDetacher but PrivateRemover is probably more accurate.

But seriously, is there any way to ensure the private files associated with a job get deleted (so they don't clutter up the workarea) even if the job is cancelled with iwrmjob or through the UI? I guess I could use a trigger, but by the time it fires will the information about what files were associated with the job be available, or will the job XML have already disappeared?

Find more posts tagged with

Comments

Johnny

I'm assuming you are associating these files as temporary files.
DO they need to persist between tasks?

If you are creating temporary files in an external task, how about deleting them at the end of the task.

This may not be what you are looking for.

Which trigger would you be able to use, for trying a trick like this?....

Triggers seem a bit bare bones with TeamSite.

I would actually like to see an option to serialise triggers. I wonder if there's a feature request for that Smiley Happy

John Cuiuli
Consultant
Sydney, Australia

Migrateduser

I remember someone saying that Interwoven would respond to any unanswered devnet post. I wonder what happened to that idea. I think from now on I will just go straight to filing a support case, which inevitably becomes a feature request.

I agree with you that the documentation and implementation of triggers is pretty bad. I have always avoided them because I don't like the idea of automated processes getting kicked off without inherent logging, because there is no way to pop up a user interface, and because I heard performance could be a real problem. But I have suggested to a few people on devnet that they might help with their issues, which I now regret after trying to implement one.

I started with a line like this in iwevents.log which seemed to coincide with the completion of a job (no idea if/where all of these trigger keys are documented).

[Thu Mar 20 12:25:47 2003] DOMAIN\user master WorkflowInactivate workflow Contribution Approval 0x3665

I then tried

iwat WorkflowInactivate full/path/to/perlscript.ipl

I also tried

iwat WorkflowInactivate full/path/to/iwperl full/path/to/perlscript.ipl

But all that seems to happen is that a line such as the following is written to iwtrace.log:

Can't open perl script "[Thu Mar 20 12:29:39 2003]": No such file or directory

The private files are indeed temporary files. They do need to persist between tasks, but they need to be cleaned up when a job completes. There may be other things I want to do when a job completes (unlock, etc.) - normally I do this with an externaltask at the end of the job, but what if they do remove job in the UI? So I think I need a trigger.

If Interwoven does respond, it will be with some of the canned responses that don't deal with the issue (such as "make the job owner SYSTEM and nobody will be able to remove it."). I don't want a hack, I want a solution. The private files are already a hack.

Thanks Johnny,

-John

james1

> I also tried
>
> iwat WorkflowInactivate full/path/to/iwperl full/path/to/perlscript.ipl
>
> But all that seems to happen is that a line such as the following
> is written to iwtrace.log:
>
> Can't open perl script "[Thu Mar 20 12:29:39 2003]": No such
> file or directory

Try:

iwat WorkflowInactivate "full/path/to/iwperl full/path/to/perlscript.ipl"

-- James

--
James H Koh
Interwoven Engineering

Migrateduser

Great. So it does result in a feature request, by the time the trigger runs the Job XML is already gone. I also wonder how I would quote parameters to pass to my script, if I have to quote the script itself?

RUNNING PrivateDetacher.ipl [Mon Mar 24 10:38:02 2003] DOMAIN\User master WorkflowInactivate workflow Contribution Approval 0x3cff
WF ID : 0x3cff
Object 15615 does not exist.
ID 15615 is invalid

james1

All events are logged after the event. So, by the time the WorkflowInactivate event is logged, the workflow is complete, which means that the server no longer has any record of the workflow.

Since you want your clean-up to happen whether the job completes normally or abnormally (by aborting the job), have you considered the following:

Wherever in your job you have the opportunity to create private files (I assume this is via some external tasks?), follow up with an external task that records the existence of these private files, and associated job id. Then, you can run your clean-up program at a variety of times:

* At normal job completion (from an external task).
* Triggered by WorkflowInactivate
* As a cron job
* As a persistent daemon

Your clean-up program could examine all recorded private file entries in your private-file store, and delete any that are associated with completed jobs. This would ensure that the files would eventually get cleaned up.

Hope this helps.
-- James

--
James H Koh
Interwoven Engineering

Migrateduser

I am trying to avoid a hack such as this.

Johnny

Be nice John Smiley Happy

There cant be an out of the box solution to every possible permutation that TeamSite is used for.

We wouldnt be needed then Smiley Happy

John Cuiuli
Consultant
Sydney, Australia

Migrateduser

Johnny -

I don't think I'm being too hard on Interwoven. I feel that as professional developers we have a responsibility to make flaws in the product apparent to Interwoven, to other users and most of all to potential Interwoven customers. Interwoven is very heavy on marketing and very light on delivery. If, during product evaluations, an issue such as this had been raised, I'm sure marketing would have returned with something like "you can do that with a trigger", without any understanding of the issue. I am tired of writing hacks to work around undocumented architectural flaws in the product, though I realize that it is very lucrative for both Interwoven and myself and that to avoid it I have to work with some other product.

I think that after spending hundreds of thousands of dollars on licensing and consulting, Interwoven users, as a community, accept a pretty dodgy product. How would you feel if your enterprise database solution provided triggers only post-commit, especially when the data has already been deleted? At the very least they would be less useful and much more cumbersome to implement. How many Interwoven customers have suggested that workflow job XML remain in the system after job completion? At this point even a feature request on this issue seems hopeless.

I do not want to rewrite every ExternalTask process to log any private files it generates to some nonstandard, unsupported file system database. I realize this is not the most critical issue on my project, but what if the ExternalTask fails, not reaching the step where it updates the database? What if some other developer writes a workflow or ExternalTask that doesn't log it's private files? I want to use the core functionality of the product, not a custom solution every time I have to do anything.

Regards,

-John

Adam Stoller

At the risk of stirring up some mud here - could you explain what these temporary files contain?

You indicate that you needed to create this "hacK" of temporary files for some aspect of your workflow process - without knowing what these files are used for it is difficult to figure out if there was a better solution - one that might not require temporary files, and thus might not require trying to clean up temporary files...

--fish
(Interwoven Senior Technical Consultant)

Migrateduser

Navigation is generated dynamically by indexing the contents in each folder - each folder contains an index.xml which contains link titles, descriptions, etc. for the files and folders in that directory. When content is added, updated or removed the index for that directory has to be updated. But since there could be two users creating content in one directory and one might not be approved (so it needs to not appear on the other's index.xml), each job should have it's own index.xml (basically I always enforce a rule that any one file path can only be involved in one job at a time). So I was using private files that were specific to the job to store a copy of the data that would normally go in index.xml (for instance jobId.index.preview.xml) and attaching that to the job, then when the content is deployed it updates the real index.xml by reading from the corresponding directory in staging.

At this point I have decided not to generate the temporary files - users can preview content but can't preview navigation.