Discussions
Categories
Groups
Community Home
Categories
INTERNAL ENABLEMENT
POPULAR
PUBLIC CLOUD
PRIVATE CLOUD
Quick Links
MY LINKS
HELPFUL TIPS
Back to website
Home
Web CMS (TeamSite)
wfttask
System
I hadn't bothered messing with wfttasks since they first came out in late '02, because I thought the design was more limiting than it should have been. I recently decided to revisit them for a project where there are a lot of little sub-approval workflows that can run as nested jobs, where it has the potential to save me some maintenance headaches down the road... but, I'm finding a lot of the same annoyances as before - I've just put a little more thought into how to solve. So, anyone [particularly James Koh or Ghoti], does this seem sane.
The second to last "real" task of the job is the approval task. If the content is approved, I go to an external task to regen any templated content, then end the subworkflow. If it's rejected, I go straight to the end. So, to handle routing back in the parent workflow, it seems like I could add a wfvarfinishop to both the approval task and the generate task and set a WF variable like 'lastTask' to %task (this is assuming the same macros work for the wfvar ops as for the ea ops - the manual isn't exactly helpful on that point). I could then add an external task right before the endtask. If the approval task was the last to execute before it, then I set a WF var in the parent workflow, subWorkflowResult to 'rejected'. If the generate task sets the variable then I set subWorkflowResult to 'approved', and then add an external task in the parent workflow to handle the routing.
Alternatively, I could just put two different external tasks in the job to set the parent WF var, but that just seems lame.
Find more posts tagged with
Comments
Migrateduser
Based on some testing, it looks like wfvarfinishop does not allow macros like the ea op commands do. I can actually provide sensible hardcoded values, so I don't think that will be a big deal.
Adam Stoller
So - did you answer this for yourself then?
There are any number of ways to transfer state information from parent-to-child and/or child-to-parent jobs - ideally you want to have an error-handling task somewhere - whether it's in your parent-workflow, child-workflow, or both is a matter for you to decide.
I haven't made much use of wftask's either - so I'm not sure what other issues may be involved (I believe there are some issues with the child-job's endtask hanging around or some such - but I'm not sure).
--fish
Senior Consultant, Quotient Inc.
http://www.quotient-inc.com
Migrateduser
I've been on a different project for a few days, so I haven't had a chance to revisit it. I got about halfway through coding before I got pulled into the other thing. Hopefully, I'll be able to get back to it by the end of the week.
Migrateduser
I am a good bit down the road of coding the solution I outlined above. For the most part it seems to work pretty well. There are a couple of issues I didn't think about - one that makes total sense, and one that really doesn't.
The sensible one is that nested workflows aren't re-entrant. What I mean by that is that if you leave the wftask and then later transition back to it, you don't go back through the tasks that were created when it first became active. Instead, it creates a new child workflow. While that has potential to litter the system up a bit if you end up going back through the child workflow several times, it's a sensible design. Otherwise, it would be impossible to accomodate a situation such as one where you have some conditional routing based on metadata and the metadata changes between invocations of the child workflow.
The issue that doesn't make sense, and I'm hoping it's just a case of me having done something wrong and not having thought through it completely, is that locks don't seem to be transitioning correctly. The workflow in question is a submit workflow, so in almost every case, the file(s) will be locked by the person actually starting the workflow. In the most recent test case, that user is ****\9999
The first task generates HTML pages from any attached DCRs, and is owned by a system user (****\SiteAdministrator). It is lock='f'
Then I have a task to write the jobspec. Also, lock='f'
Then I have the wftask. lock='t'. owned by the same system user as the two previosu tasks (****\SiteAdministrator). lock = 't'
Within the workflow, the start task is an external task to send email, lock='f'
Then a usertask for the review, currently owned by (****\rhuffstedtler), lock='t' transferonly='t'
When it gets to the review task in the child workflow, the lock belongs to rhuffstedtler, as I would expect. If rhuffstedtler rejects the task, it goes to
an external task owned by ****\SiteAdministrator which sets the routing varible in the parent wf, lock='f'
Then the endtask of the nested workflow
Back in the parent workflow, the next task is an external task to route based on the wf var. It is owned by ****\SiteAdministrator, lock='t', transferonly='t'
There's probably no good reason to transition the lock at that point, but it still illustrates the problem. The lock is not ever transferring. By the time the original submitter gets the files in a usertask two tasks later (also lock='t', transferonly='t'), the lock is still held by rhuffstedtler with a comment that the lock was grabbed by the child workflow.
I would have thought it would be possible to transfer a nested workflow lock back to the parent workflow. I can just put an unlock task right before my end task (or have the task that sets the parent wf var do it), but I'm annoyed when I have to do things to handle behaviour that seems like it ought to be built in.
Adam Stoller
If you haven't yet - please open a case with support.
It may not help too much for the here-and-now, but it has a better chance of getting fixed in the then-and-later ...
--fish
Senior Consultant, Quotient Inc.
http://www.quotient-inc.com
Migrateduser
if you do an "iwgetwfobj" on the usertask that should be transferring the lock from your account to the actual user, does it show status of "tryingtolock=t" ? just want to make sure it's actually trying to :-)
also, just to clarify, the user that is the owner of the usertask trying to do the lock, they _do_ have permissions in that workarea, right? if you're using test accounts, I've found it wouldn't hurt to double-check :-)
probably won't help, but what happens if you use lock=t, but not transferonly=t? if the child workflow locks the file, I can see where transferonly could cause a locking failure, though I agree it should be working as default behaviour...
cheers,
-Rori
