Workflow file locking - need guidance

Hi,

I have a situation where a user submits a file. The first thing that happens, is that one to many other files get automatically attached to the workflow based on the filename of the original attached file.

What is the best procedure as far as locking goes? Should all files attached to the workflow be automatically locked to prevent others from making changes before the workflow completes? Once the workflow completes (right before the End task) unlock the files?

Basically, all attached files need to be modified/approved, and ultimately submitted to Staging. File locking model is Submit.

Environments are TS6.5-Win/TS6.5-Sol.

Thanks in advance.

Find more posts tagged with

Comments

Adam Stoller

Hi,

I have a situation where a user submits a file. The first thing that happens, is that one to many other files get automatically attached to the workflow based on the filename of the original attached file.

What is the best procedure as far as locking goes? Should all files attached to the workflow be automatically locked to prevent others from making changes before the workflow completes? Once the workflow completes (right before the End task) unlock the files?

Basically, all attached files need to be modified/approved, and ultimately submitted to Staging. File locking model is Submit.

Environments are TS6.5-Win/TS6.5-Sol.

Thanks in advance.

Yes - you should ensure that the files are locked - by the workflow - after they are attached (a locktask is best, the lock="t" attribute has some issues) - you can generally have the submittask unlock the files (unlock="t") after the submit has gone through, or, if you're concerned about processes that take place after submit - do what you indicated, create an externaltask that runs just before the endtask that runs IWHOME/local/bin/unlock.ipl

ShovelFace

The lock task is working as expected, with the following exception:

If File A is submitted, and File B is picked up/attached via the external task, both are locked as expected unless File B is already locked. Then File A does not lock.

Any ideas how to get around this behaviour and ensure that all attached files are locked?

Adam Stoller

The lock task is working as expected, with the following exception:

If File A is submitted, and File B is picked up/attached via the external task, both are locked as expected unless File B is already locked. Then File A does not lock.

Any ideas how to get around this behaviour and ensure that all attached files are locked?

If I understand you correctly the scenarios are:

File_A and File_B are unlocked
- File_A is attached to the submit workflow due to having been pre-selected
- File_B is attached to the same workflow through an externaltask script process
- File_A and File_B both get locked in the locktask
File_A is unlocked, File_B is locked (from editing or whatever)
- File_A is attached to the submit workflow due to having been pre-selected
- File_B is attached to the same workflow through an externaltask script process
- The locktask does not appear to lock File_A

Is that accurate?

Is the locktask correctly failing? I.e. transitioning to the failure-successor as opposed to the succcess-sucessor?

I believe it is not a case of failure to lock File_A - but rather a failure to override the lock on File_B and then either not attempting to lock File_A or reverting the lock on File_A.

If this is the case - (although determining it can be difficult if not impossible since the diagnostics from TS in these situations are pretty bad) - then the best solution is to have the failure-successor for the locktask go to an externaltask that runs IWHOME/local/bin/iwunlock.ipl and then transitions back to the original locktask.

ShovelFace

You nailed it right on the head. I will go the external task route and do the unlock right at the start so that I can properly lock them all. Thx.

ShovelFace

Related question: if using workflow builder, can the syntax on the command line be genericized to support deployment to either a windows or unix environment? For example, in windows, one would use E:\iw-home\iw-perl\bin\iwperl.exe E:\iw-home\local\config\wft\attachfiles.ipl.

Adam Stoller

Related question: if using workflow builder, can the syntax on the command line be genericized to support deployment to either a windows or unix environment? For example, in windows, one would use E:\iw-home\iw-perl\bin\iwperl.exe E:\iw-home\local\config\wft\attachfiles.ipl.

(OPINION) If at all possible - avoid using the existing Workflow Builder - it's prone to so many problems and never really worked well to begin with.

6.7.1 (not yet released) is supposed to have the new graphical workflow development interface (not sure what the "name" is) that should be *significantly* better than the current WFB.

In the meantime - you might be able to use something like (UNTESTED):

"__VALUE__('iw-home')/iw-perl/bin/iwperl __VALUE__('iw-home')/local/config/wft/attachfiles.ipl"