nav[aria-label="Primary Navigation"] { padding: 0; & ul { list-style: none; width: 100%; display: flex; flex-direction: row; justify-content: start; align-items: start; gap: 30px; padding: 0; & li { margin: 0; } & ul li { list-style: none; } } }

How to timeout a review task?

sgarimella

Hi,

I have a review task and I am trying to timeout the review task with say 5 minutes.

In my workflow, I have a review task with success and failure paths post review task.

Additionally review task is linked with timeout link with 5 mins relative timeout value.

This link is connecting the review task and the same task which the success link connects to.

This workflow is working if I have just 1 reviewer and it is not working for more than one reviewer.

Did someone face the issue? Kindly let me know if I am missing out on anything.

I am using Teamsite 7.4.

Find more posts tagged with

Comments

nipper

THe issue is that the timeout starts when the task is activated and a user is assigned. If it is a group task, the timeout won't start counting until someone has taken control of the task.

I am really not certain how to get aound that

sgarimella

Kindly help me understand this in detail:

1. How come it works with a single reviewer?

2. Isnt it the case for review task that the owners of the review task are assigned post instantiation screen?

Example:

If there are 2 reviewers selected on instantiation screen, internally workflow creates 2 review tasks and owners are assigned to them post instantiation screen. Right.

Why wouldnt timeout work here.?

Adam Stoller

Personally, I've never used a "ReviewTask" - partially because I had been creating such things myself for years before WFM came about and partially because I was never sure how they were implemented internally. I'd suggest taking a look at the instantiated workflow job specification - either by enabling debug mode for the workflow so that you get the yellow / green screen upon trying to instantiate the job, or by using iwgetwfobj -r jobid on the job after it has been instantiated - and then peruse the output to see how the review tasks are actually implemented and whether the timeout transition you thought you placed on it is actually associated with the tasks you think it is associated with.

sgarimella

As you suggested, I had a look at the Job Spec with one reviewer and with multiple reviewers. In the first case, the timeout link is placed at exactly same place where I added it in WFM.In the latter case, there were many tasks, transitions and gateways added internally by WFM and the timeout link, had it been in a different place, I guess it would have worked.

Having said the OOTB Reveiw task now cannot be timed out with multiple reviewers. I want to see if I can build a custom solution.

The point where I am getting stuck is - how do I create a new task each for a reviewer? In my case of concurrent reviewers, say there are 5 reviewers, then IW is creating 5 new tasks internally. If I selected 3 reviewers in the instantiation screen then IW is creating 3 tasks internally. I think it makes sense to have individual tasks for each reviewer. How do I do it if I have to build my custom review task with user authoring the number of reviewers on the instantiation screen? I tried reading through the posts here and searching how IW is doing but could not figure out how that happens. Kindly give me some direction.

sgarimella

Let me also add the different things I tried to build a custom sol.

1. I checked in WFM if there any kind of looping possible so that a flow of tasks could be repeated - but could not get anything out of this excercise.

2. I read about nested workflows. I implemented one nested workflow task. But here also How could I call the nested workflow again and again or how do I create new tasks dynamically.

Is this creation of new tasks dynamically possible in WFM? Here is where I thought I will seek help. I am not sure If I am heading in the right direction or not. Or can you guys think of any other way of implementing the sutom review task?

Adam Stoller

sgarimella wrote:
Let me also add the different things I tried to build a custom sol.

1. I checked in WFM if there any kind of looping possible so that a flow of tasks could be repeated - but could not get anything out of this excercise.

2. I read about nested workflows. I implemented one nested workflow task. But here also How could I call the nested workflow again and again or how do I create new tasks dynamically.

Is this creation of new tasks dynamically possible in WFM? Here is where I thought I will seek help. I am not sure If I am heading in the right direction or not. Or can you guys think of any other way of implementing the sutom review task?

You can create your own loop by using an external task with a job or task variable to keep track of the count - the external task would also have to take care of re-assigning the ownership of the [presumably] user task used for the review.
You could do something simile to the above with a nested workflow, though I don't think it's worth it

Both of the above are with regard to WFM, since it is definitely possible to generate multiple instances of tasks during instantiation with a WFT.

I do not believe that you can dynamically create tasks within a WFM; you could, however, dynamically "remove" tasks. In this case, you would define the maximum numer of [single-user] review tasks you might potentially need, and use configurable variables and conditional links to determine whether or not some of the taskes should not be included when the job is instantiated. E.g.: a configurable variable NUM_REVIEWS could be set to a value from 0 [or 1] to N [say 5 for example], you layout all 5 review tasks in your WFM that are transitioned to via Conditional Links - the condition for each link would be slightly different, e.g.:

if ($CV(NUM_REVIEWS) > 0) return true; return false;
----
if ($CV(NUM_REVIEWS) > 1) return true; return false;
----
if ($CV(NUM_REVIEWS) > 2) return true; return false;
----
if ($CV(NUM_REVIEWS) > 3) return true; return false;
----
if ($CV(NUM_REVIEWS) > 4) return true; return false;

You'd have to think about the specific case to determine whether you think the above conditional-link concept is better or worse than using an externaltask and job/task variable to track iterations (#1 or #2) - by evaluating all the work that would need to be done for either situation and how you would get the information you need (reviewer, number of reviews, etc.).

I do not believe that there is any official support for creating custom tasks (via Java), though you're certainly welcome to attempt it I'd probably think at least twice before going down that route.

sgarimella

Thanks for the detailed response.

I was looking at looping to create tasks , but since you mentioned that it is not possible with WFM, that is not an option now.

My business case is: on workfow instantiation screen, i populate a drop down with all users of that branch with a specific role as R1. These are all my reviewers.

WF User selects few reviewers say 5 of them and proceeds. WF should consider these as concurrent reviewers and enable review process. After say 20 mins (some defined interval) if still reviews are pending then the system shall consider them auto approved and proceed.

In my case, the upperlimit for number of reviewers changing. (if WF user selects more reviewers or if a new TS user is added to the system) . Otherwise I liked the approach you mentioned. But can you think of any other way to address this issue of timeout.?

Since the upperlimit of reviewers is changing, I am unable to design my custom review task with the options given in WFM.

Adam Stoller

I'll defer to anyone who knows of a way to dynamically create tasks in WFM - but I'm pretty sure that cannot be done (at least not the way that those of us used to WFT development would do)

Given that you're looking for concurrent reviews - I think your only choice would be to define 20+ such tasks and use a combination of an AND gate with a whole bunch of conditional links (as I described previously)

I'm not sure your idea of timing out the review task as-if the work had been approved is really a good design. If you have a review, it's usually there for a purpose, to have at least one extra set of eyes look over content before it gets published to the runtime servers (for proof-reading, stylelistic verification, legal compliances, etc.) - and the notion that if the user initiating the job choosed N people to review the work and if none of the N people perform that review in a timely manner you are going to assume that it is okay to push it out to your runtime system. Normally, if a review is required and it times out - you send notification to the reviewer (potentially CC'ing a manager) to remnd them that the work needs to be reviewed, and then transition back to the review task and start the clock all over again.

Perhaps you need a more thorough review of the design of the workflow - which may obviate the need for you to try doing what you are currently trying to do - and thus "resolve" the issue by implementing a different design.

sgarimella

Yes I agree to what you said. I had the same set of questions when I was given the auto approve and timeout requirement and I followed up with this question. I explained the client the risk involved of this kind of review. But it was their conscious decision to have this timeout feature on review task.

On the other side, we came up with an alternative to timeout the review task.

There would be an external task , the Java code associated with this task would start a thread. This task proceeds with the transition and the thread it started ontinues to run. The thread works as a poilling thread - it polls the review task, sleeps for a while again polls the review task.

The thread would get to know the activation time of the review task. It would also know the timeout period. (2 days). So when system time is activation time+2days, the thread forces the review task to make a success transition. (Java code using the CSSDK API). SInce review task is a user task we can make the transition happen.

Down side of this approach: the overhead of the running thread.

Any comments on this approach, please let me know.

sgarimella

Also ghoti, I had this question from quiet sometime now.

Whenever I run into issues,

1. I first try to refer to the IW documentation that we have eg : in this case "Teamsite workflow modeller 7.4.1"

2. Try out things after reading in the docs.

3. Reach out to this community or any other IW forum.

is there any other articles or documentation that augments the IW docs.

Eg: Review Task - very very limited information is provided in the workflow modeller regarding what it can and what it cannot perform. Since I used this task now from last few days, I have some more points to add to what I call the reference documentation.

I tried searching in HP site as well could not find any docs.

The reason I am asking this question is to be more efficient from next time when I run into issues and to make sure I am on the right path atleast to uncover possibilities .

Adam Stoller

sgarimella wrote:
[...]
On the other side, we came up with an alternative to timeout the review task.

There would be an external task , the Java code associated with this task would start a thread. This task proceeds with the transition and the thread it started ontinues to run. The thread works as a poilling thread - it polls the review task, sleeps for a while again polls the review task.

[...]
Any comments on this approach, please let me know.

That seems a reasonable alternative approach.

sgarimella wrote:
1. I first try to refer to the IW documentation that we have eg : in this case "Teamsite workflow modeller 7.4.1"
2. Try out things after reading in the docs.
3. Reach out to this community or any other IW forum.
[...]
The reason I am asking this question is to be more efficient from next time when I run into issues and to make sure I am on the right path atleast to uncover possibilities .

In some versions of TeamSite (like 7.2 or 7.1) you can find another document "TeamSite Legacy Workflow Reference Guide" - which contains a lot of information primarily for developing WFTs but some of the information is relevant regardless of whether your doing WFT or WFM.

Unforturnately the "Review Task" is an invention created for WFM so there isn't any additional information there.

sgarimella

Just a quick thought.

The thread approach that I mentioned, is it possible to implement with a nested workflow?

I did a quick reading and gave it a quick try but do not see that possible.

Any thoughts?

Adam Stoller

It may be possible, but I don't think your use-case needs that extra level of complexity.