Hi Frank, Yes, it's when changing the substitute user. We have to use the second suggestion also.
In a scenario where substitution starts in a future time(not just after changing the substitute user), we do not have the option of rejecting the substitution request. In such a scenario, we will have to make his tasks unclaimed! Regards, Vinod On Jun 16, 2016 2:28 AM, "Frank Leymann" <fr...@wso2.com> wrote: Hi Vinod, yes, that's a well-known issue :-) I suggest to adopt your first suggestion, namely checking circular dependencies when a new substitute has been specified (I guess that's what you meant - not when adding a new user, right?). Best regards, Frank 2016-06-15 13:25 GMT+02:00 Vinod Kavinda <vi...@wso2.com>: > Hi all, > I ran into an issue while implementing this. > > What if we ran into a *circular dependency between user substitutes*? We > can't calculate a transitive substitute in this scenario. No one will be > available to take up the tasks of the unavailable user. > > Here is my suggestion for this: > > *Circular dependency detected while adding a new user* > We abort this user addition and reply back to the user asking for a new > substitute. > > *Circular dependency detected while resolving transitive subs in a > scheduled event (Due to a user's substitution starting at this point )* > > Mark the transitive sub is "UNDEFINED". Future tasks that are assigning to > this user will be reverted back as unclaimed tasks (remove the assignee). > > Any suggestions? > > > > > On Thu, Jun 9, 2016 at 8:31 AM, Vinod Kavinda <vi...@wso2.com> wrote: > >> Hi Frank, >> Agreed. >> I have created Jira [1] to track this improvement after the Human Task >> integration with BPMN engine. >> >> [1] - https://wso2.org/jira/browse/BPS-1043 >> >> Regards, >> Vinod >> >> On Wed, Jun 8, 2016 at 10:03 PM, Nandika Jayawardana <nand...@wso2.com> >> wrote: >> >>> Yes, Once the task engine refactoring is complete, we can integrate our >>> own task implementation with activiti . Then we can overcome the current >>> limitations of user tasks. >>> >>> Regards >>> Nandika >>> >>> On Wed, Jun 8, 2016 at 7:18 PM, Milinda Perera <milin...@wso2.com> >>> wrote: >>> >>>> >>>> On Wed, Jun 8, 2016 at 6:49 PM, Frank Leymann <fr...@wso2.com> wrote: >>>> >>>>> Dear Vinod, >>>>> >>>>> understood. My recommendation is that we should argue as long as >>>>> possible independent from a certain implementation: if we may decide to >>>>> move from Activiti to Camunda, we should have the architecture/design >>>>> right >>>>> to port our implementation with minimal effort. That's why I argue in >>>>> terms >>>>> of the BPMN recommended state model, and when we agree on the principles >>>>> we >>>>> can map it to the underlying engine. Does this sound acceptable? >>>>> >>>>> Which brings up the following question: When we support User Tasks in >>>>> Activiti, don't we use our HumanTask implementation as User Task as BPMN >>>>> 2.0 assumes? But we use the simplified implementation that Activiti ships? >>>>> If we do the latter, what is our strategy of our HumanTask implementation? >>>>> >>>> >>>> >>>> >>>> +1, Soon or Later I think replacing Activiti User Task or introducing >>>> as a new type of user task, with our WS-HumanTask it the best option. >>>> AFAIR similar idea is in our future roadmap @Hasitha @Nandika : isn't >>>> it? >>>> >>>> -- >>>> Milinda Perera >>>> Software Engineer; >>>> WSO2 Inc. http://wso2.com , >>>> Mobile: (+94) 714 115 032 >>>> >>>> >>> >>> >>> -- >>> Nandika Jayawardana >>> WSO2 Inc ; http://wso2.com >>> lean.enterprise.middleware >>> >> >> >> >> -- >> Vinod Kavinda >> Software Engineer >> *WSO2 Inc. - lean . enterprise . middleware <http://www.wso2.com>.* >> Mobile : +94 (0) 712 415544 >> Blog : http://soatechflicks.blogspot.com/ >> >> > > > -- > Vinod Kavinda > Software Engineer > *WSO2 Inc. - lean . enterprise . middleware <http://www.wso2.com>.* > Mobile : +94 (0) 712 415544 > Blog : http://soatechflicks.blogspot.com/ > >
_______________________________________________ Architecture mailing list Architecture@wso2.org https://mail.wso2.org/cgi-bin/mailman/listinfo/architecture
