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; } } }

Advice on workflow design

Huan

Using T.S. 6.7.1

I have the following scenario (the graph is in the attachment)

One group task has two transitions, that is, two buttons on the T.S. interface. What I want to implement is when a user take the group task and click on transition2, it will do whatever defined in Another External Task, after that, it will return to the Group Task again and the user can still click transition1 to continue the workflow. Anybody has any idea on how to implement it?

Thanks a lot.

Find more posts tagged with

Comments

kaalraa

Using T.S. 6.7.1

I have the following scenario (the graph is in the attachment)

One group task has two transitions, that is, two buttons on the T.S. interface. What I want to implement is when a user take the group task and click on transition2, it will do whatever defined in Another External Task, after that, it will return to the Group Task again and the user can still click transition1 to continue the workflow. Anybody has any idea on how to implement it?

Thanks a lot.

That should not be anyway complex. Did you tried it as a usual workflow? Getting any issue or error??

OR is the issue is about maintaining the user id, who has clicked for transition2 at the first time???

12220_Sampledatabase.rptdesign

Plz+look+on+the+URL.doc

Adam Stoller

Using T.S. 6.7.1

I have the following scenario (the graph is in the attachment)

One group task has two transitions, that is, two buttons on the T.S. interface. What I want to implement is when a user take the group task and click on transition2, it will do whatever defined in Another External Task, after that, it will return to the Group Task again and the user can still click transition1 to continue the workflow. Anybody has any idea on how to implement it?

Thanks a lot.

Basic implementation is trivial, the second externaltask declares the grouptask as its successor.
If you want the grouptask to have the same owner who claimed it the first time through, you need to set retainowner="t" in the definition of the grouptask, that way it will behave exactly like a usertask once claimed the first time.
If you want the task to only present the choice not taken the first time - that's more difficult - and we can discuss ways of trying to accomplish that if that is really your issue.

If I haven't covered the issue you're trying to deal with - please elaborate on what you're having problems with.

Huan

Thanks fish!

The retainowner attributes seems not working.

kaalraa

Thanks fish!

The retainowner attributes seems not working.

Could you please attach your code?

moonkhanna

are you using WF modeler or are you using wfts to do this?

Huan

I set the retainowner = "t" on the ReviewContent Group Task. For example editor1 took the ownership of this group task. If he clicks on the Deploy button, after Deploy2WebServer is done, it goes back to ReviewContent and the editor1 is still the owner.

The weird thing is if he clicks on the Revise button, then EmailAuthor, then the author revise the content, then EmailEditor, finally goes back to ReviewContent, however, the owner is not editor1 but no user.

It seems that the retainowner = "t" is not consistent. Anybody has any idea on this?

moonkhanna

are you using WF modeler or are you using wfts to do this?

DynamicSort.rptdesign

Huan

I used WorkFlow builder before. After we moved to T.S. 6.7.1, I update the .wft file by hand.

kaalraa

I set the retainowner = "t" on the ReviewContent Group Task. For example editor1 took the ownership of this group task. If he clicks on the Deploy button, after Deploy2WebServer is done, it goes back to ReviewContent and the editor1 is still the owner.

The weird thing is if he clicks on the Revise button, then EmailAuthor, then the author revise the content, then EmailEditor, finally goes back to ReviewContent, however, the owner is not editor1 but no user.

It seems that the retainowner = "t" is not consistent. Anybody has any idea on this?

Could you please check as what is the activation status of your GroupTask at the time when your UserTask is activated. You can get this info by running iwgetwfobj {taskid_of_grouptask}.

Supress.zip

Huan

Could you please check as what is the activation status of your GroupTask at the time when your UserTask is activated. You can get this info by running iwgetwfobj {taskid_of_grouptask}.

After I run the command, it displays an xml-format information. The only place shows this group task id is the comments parts.

kaalraa

It seems that the retainowner = "t" is not consistent. Anybody has any idea on this?

What i know, it is consistent, but only for the next successor task. I may be wrong.

birt.png

Huan

What i know, it is consistent, but only for the next successor task. I may be wrong.

I think you are right.
Thanks!

Adam Stoller

I set the retainowner = "t" on the ReviewContent Group Task. For example editor1 took the ownership of this group task. If he clicks on the Deploy button, after Deploy2WebServer is done, it goes back to ReviewContent and the editor1 is still the owner.

The weird thing is if he clicks on the Revise button, then EmailAuthor, then the author revise the content, then EmailEditor, finally goes back to ReviewContent, however, the owner is not editor1 but no user.

It seems that the retainowner = "t" is not consistent. Anybody has any idea on this?

If retainowner="t" is not retaining the owner throughout the lifetime of the workflow (once the grouptask has been claimed the first time) then it is either a bug in the system (which should be reported to Support) or it is a bug in custom code being used by the workflow in question in which some code might be explicitly re-setting the grouptask to remove its owner.

A simple 2-or-3 step WFT could be created to test this out (I don't have the time right now - sorry):

        +-----------------------------+
        v                             |
[grouptask]-- test -->[externaltask] -+
           \- end  -->[endtask]

The grouptask is the start tasks and should have retainowner="t" on it.
The externalask script would simply get the taskid, create the task object and do a callback to transition back to the original grouptask.
The first time through you should have to claim ownership, but that's the only time.
Run it through multiple times - the first time (loop) with you (the job owner) claiming ownership, the next time (loop) with someone other than the job owner claiming ownership.

If the grouptask maintains it's ownership the problem is somewhere else in your WFT and associated code.

If the grouptask does not maintain its ownership - the problem is in the product and should be reported to Support

moonkhanna

yes, I would agree to ghoti. The retainowner should retain the owner of the grouptask through out the workflow. Can you attach the wft you are using together with your script for Enternal Tasks involved?