"trying to lock files" status (again)

We're trying to test default Author_Assignment.wft (as a basis for using in creating our own wft eventually with other "external" steps downstream: generate, deploy --> but that's another story), but the workflow is hanging after the Author_Work usertask with status of "Trying to Lock Files" in the Approving editor's Task To Do list (the Review usertask)-

we've taken the lock="t" off of both tasks, so why is the workflow trying to acquire a lock?

we've also tried leaving the lock="t" attributes there and then running unlock.ipl within an intermediate task between Author_Work and Review, but run into problems when trying to attach files in a task that doesn't have a start="t" attribute set --> apparently there's an undocumented association between using the __INSERT__("<files>")..... code and the task calling it having to be a start task?

I know this is a fairly common issue, and have seen several threads in devnet discussing it, but none seem to have a resolution? also surprised to find no real hits in the support KB search regarding this-

don't think it's a permissions error, because we have 774 access on the file, and all users are in the group

we're on TS 5.0.1 on Solaris
as always, thanks in advance for any assistance

Find more posts tagged with

Comments

manju166

we had same problem but the workflow was hanging when we were trying to unlock the files while editing the job.
so i tried adding the following steps in my workflow, i know your problem is other way around, the code below might give you an idea

<externaltask lock = "f"
name = "AssignCreateTask"
owner="__TAG__('iw_user');"
description = "Assign Create/Update Task to Author">

<areavpath v="__INSERT__($area_vpath);"/>

<successors>
<successorset description = "Done">
<succ v = "Unlocking_Files"/>
</successorset>
</successors>

<command v="__INSERT__($assign_create_task_cmd);"/>

<activation>
<pred v="CopyTemplate"/>
</activation>
</externaltask>



<externaltask name="Unlocking_Files"
owner="__TAG__('iw_user');"
description="Unlock Files">

<areavpath v="__INSERT__($area_vpath);"/>
<successors>
<successorset description="Unlock">
<succ v="CreateOrEditElinkNewsOne"/>
</successorset>
</successors>
<command v='"d:\iw-home\iw-perl\bin\iwperl.exe" "d:\iw-home/local/bin/unlock.ipl"'/>
<activation>
<pred v="AssignCreateTask"/>
</activation>
</externaltask>

Adam Stoller

I hate to ask, but ... After you took the lock="t" attributes out of the wft - did you re-create a new job, or did you assume that the effect would be immediate upon the job already instantiated?

You'd have to delete the existing job and create a new instance of it to see if this made any difference.
Locks - there are at least two different kinds of locks: "TeamSite Locks" and "Workflow Locks" - if a file is already locked by someone else and it is selected to be incorporated as part of a workflow - workflow will not be able to take over that lock, and will continue to spin trying to do so if the lock='t' attribute is set.
- One solution is to use the locktask element - which provides for both a 'success' and 'failure' transition so you can get pretty much immediate feedback if something goes wrong trying to acquire locks on all the files associated with the workflow.
- Another solution is to include an externaltask that runs the command iw-home/local/bin/unlock.ipl prior to a task with the lock="t" attribute set - though if a file fails to become unlocked this takes you back to a job spinning trying to capture locks.
- So, perhaps the best solution would be to use an externaltask with unlock.ipl followed by a locktask with notification and a usertask for the failure transition
When having any kind of problem with a workflow - including locks - be sure to check the iwtrace.log and/or iwjoberrors.log as they sometime contain additional information which may help to diagnose (and fix) problems that are being experienced.
files element - the fact that the < files> element can only be used within a "start" task is documented, at least in the TeamSite Workflow Developers' Guide, Release 5.5.2 - on p. 179:

--fish
(Interwoven, Curriculum Development)

gsumers22texas

ah, so 2 "intermediate" external tasks instead of just one-

- what exactly is the first task doing? is it performing some certain prereqs to the unlock.ipl? if so, what are these? I don't see one single sub in WFtask.pm or in WFworkflow.pm (though some seem close) that corresponds to the name of your cmd ($assign_create_task_cmd) what is this cmd set up to invoke in the CGI section of your wft?
Is your $assign_create_task_cmd performing certain subs (or combination of subs) within these modules? or a custom script?

- in the second task, you were able to invoke unlock.ipl, without including the __INSERT__("<files>")... etc snippet within the task? when we don't attach the files within the external task itself, it doesn't seem to actually unlock the files

many thanks for your assistance

Adam Stoller

Once the files are associated with a workflow (as already documented - explicitly within the start task, or dynamically through an active task) - the list of files is *implicitly* available to any other task.

If you tried to use an externaltask as a start task to perform the unlock.ipl script and did *not* use the <files> element - then there are no files associated with the workflow at the time that the externaltask is executed.

--fish
(Interwoven, Curriculum Development)

gsumers22texas

thanks for reply ghoti- it's very helpful- my corresponding answers to your questions:
1. yes, we did invoke a new job after making changes
2. have tried externaltask invoking unlock.ipl before Author_Work, but after a start Add_Files usertask (borrowed from Author_Assignment_with_email.wft) to allow for Job Creator to either preselect or not preselect a file to attach to the job) -have verified file is unlocked before being selected in the New Job --> Author_assignment.wft process - you suggest an <externaltask> invoking unlock.ipl BEFORE the Author_Work task? something we've uncovered that is probably related- the file we're testing with is a DCR, and we've noticed that the Save of the DCR in Templating actually changes the underlying permissions of the DCR from 774 to 664 (currently looking for solution to this issue) - this saving of DCR is occuring within the Author_Work usertask- could that also be effecting the locking process within workflow?
3. you are correct, it's on pg. 157 of the 5.0.1 manual (our version is 5.0.1) - should unlock.ipl be unlocking attached files if the externaltask is not a start task and we don't include the <files> element within the externaltask?? have tried this and it doesn't remove the locks

thanks again for help

gsumers22texas

our external task has had the following characteristics at various stages of debugging/development:
1. was second task in flow, a successor to Add_Files usertask (borrowed from Author_Assignment_with_email.wft) which did include the <files> element and which was a "start="t" task, but wasn't unlocking files
2. if it didn't include <files> element, the unlock.ipl wouldn't actually unlock the files -- if it did include the <files> element, it would error with "not a start task" error
3. if we remove the initial Add_Files start task, and make our externaltask calling unlock.ipl the start task, with <files> element, then it does work- but only if a file is preselected before the job is created- we want to use Add_Files to handle scenario where job creator hasn't preselected a file as well

Adam Stoller

Perhaps there's some information missing here - what is the ordering of the tasks, who are the owners of the tasks, and what role(s) do they have?

Is the problem on in relationship to DCRs or is it in relationship to non-templated assets too?

--fish
(Interwoven, Curriculum Development)

manju166

I am not an expert in workflow and just started building them
I have another external task before unlocking the files

this starts my workflow....



<usertask lock = "f"
name = "InitiateNewJob"
owner = "__TAG__('iw_user');"
description = "Initiate New Job"
start = "t"
readonly = "f">

<areavpath v="__INSERT__($area_vpath);"/>

<successors>
<successorset description = "Assign">
<succ v = "GetLatest"/>
</successorset>
</successors>

<template_script><![CDATA[
# insert file list if we have it
if (__ELEM__('iw_file')) {
__INSERT__("<files>");
for (my $i=0; $i < @submit_file; ++$i) {
__INSERT__("<file path='$submit_file[$i]' comment='task file'/>");
}
__INSERT__("\n\t</files>");
}
]]></template_script>
</usertask>




<updatetask lock = "f"
name = "GetLatest"
owner="__TAG__('iw_user');"
description = "Get Latest ElinkNews from Staging">

<areavpath v="__INSERT__($area_vpath);"/>

<successorset description = "Done">
<succ v = "CopyEditFile"/>
</successorset>

<srcareavpath v="__INSERT__($staging_vpath);"/>

<activation>
<pred v="InitiateNewJob"/>
</activation>
</updatetask>




<externaltask lock = "f"
name = "CopyEditFile"
owner="__TAG__('iw_user');"
description = "Copy Edit File">

<areavpath v="__INSERT__($area_vpath);"/>

<successors>
<successorset description = "Done">
<succ v = "AssignUpdateTask"/>
</successorset>
</successors>

<command v="__INSERT__($copy_edit_file_cmd);"/>

<activation>
<pred v="GetLatest"/>
</activation>
</externaltask>




<externaltask lock = "f"
name = "AssignUpdateTask"
owner="__TAG__('iw_user');"
description = "Assign Update Task to Author">

<areavpath v="__INSERT__($area_vpath);"/>

<successors>
<successorset description = "Done">
<succ v = "Unlocking_Files"/>
</successorset>
</successors>

<command v="__INSERT__($assign_update_task_cmd);"/>

<activation>
<pred v="CopyEditFile"/>
</activation>
</externaltask>



<externaltask name="Unlocking_Files"
owner="__TAG__('iw_user');"
description="Unlock Files">

<areavpath v="__INSERT__($area_vpath);"/>
<successors>
<successorset description="Unlock">
<succ v = "UpdateElinkNewsOne"/>
</successorset>
</successors>
<command v='"d:\iw-home\iw-perl\bin\iwperl.exe" "d:\iw-home/local/bin/unlock.ipl"'/>
<activation>
<pred v="AssignUpdateTask"/>
</activation>
</externaltask>

rest of my workflow goes on after this.

*************************
unlock.ipl code for your refrence
***************
#!d:\iw-home/iw-perl/bin/iwperl

use TeamSite::WFtask;
use TeamSite::Config;

my $iwhome = TeamSite::Config::iwgethome();
my $area = $ARGV[2];
my $task = new TeamSite::WFtask($ARGV[1]);
my @files;

if ($task->IsValid())
{
@files = $task->GetFiles();
for (my $i = 0; $i < @files; $i++)
{
if ($^O eq "MSWin32")
{
`$iwhome\\bin\\iwunlock $area\\$files[$i]`;
}
else
{
system("$iwhome/bin/iwunlock", $area . "/" . $files[$i]);
}
}
$task->CallBack(0, "Unlocked files.");
}

note-- i am on windows NT
hope this helps you

gsumers22texas

I think you've helped us make some progress, but first, the info you asked for:
The sequence of tasks is as follows:
1. Add_Files (from author_assignment_with_email) user task with start ="t" with <files> element
2. Unlock external task calling unlock.ipl
3. Author_Work usertask - file testing with is a DCR editted throught DCT -save of DCR relocks the file
4. Review usertask
5. Generate externaltask (still to be developed)
5. Submit submittask
6. Unlock2 externaltask calling unlock.ipl to unlock
7. Deploy externaltask (still to be developed)
8. End endtask
(with some Email externaltasks to be added in at several points later)

the progress we've made (through step 4 above) was doing combination of following (thanks to your suggestions):
I went back in and: 1) added the 2nd task, the external call to unlock.ipl (without start="t" attribute and without <files> element, 2) took off lock="t" off of Add_Files, Author_Work and Review usertasks --> this combination removes the "Trying to lock files" status message on the Review Task (Yes!) --> however, now on Review Task, editor cannot edit file if he/she wishes (they do) because the AuthorWork tasks involves editting the DCR (and changing permissions from 774 to 664, but not sure yet if this is relevant), so I think the resolution to this is to add another Unlock externaltaks between AuthorWork and Review to counteract the locks being placed on file with DCR save

will update thread if this resolves issue, and will provide code snippet (once it's working of course)

thanks for help and alerting us to the combination of attributes and elements (start, lock, and <files>) that come into play with unlocking files throughout a workflow job

Adam Stoller

Having lock='t' on Author_Work (after the Unlock task) should be fine, and probably good to do.

Yes - editing a DCR always creates a lock on the DCR - so if the Reviewer needs to *edit* the DCR, the file would have to have the Author's lock removed first - however, the reviewer should be able to *view* the DCR even if it is locked by the Author. If the Review task is not meant to include modifications to the assets, try adding readonly="t" for it and see if that helps any.

Otherwise - yes, you would need to insert another Unlock task before the Review task.

You shouldn't need the Unlock2 task (step 6) because the submittask has an unlock="t" attribute (defaults to "f")

--fish
(Interwoven, Curriculum Development)