Great: we are in agreement :-))
Best regards, Frank 2016-06-20 9:05 GMT+02:00 Vinod Kavinda <[email protected]>: > Hi Frank, > Agreed for the both suggestions. > > As Nandika mentioned "Not accepting a change in the substitute" is the > option we also decided, whenever we have the ability to do so. But there > are situations that we cannot do this when the cyclic situation arisen due > to a time event. Theoratically, we don't have anyone to assign this task at > this point, so it has to go back to Business Administrator as you suggested. > > However, in Activiti the corresponding role is "Task Owner". We will have > to assign to task owner in this situation. One issue is the task owner is > optional. Only in such a situation(no owner), we will have to make the task > Claimable/Unreserved. > > Regards, > Vinod > > On Mon, Jun 20, 2016 at 10:48 AM, Nandika Jayawardana <[email protected]> > wrote: > >> Hi Frank, >> >> Not accepting a change in the substitute when there is a cyclic situation >> is the options we decided as well. >> >> Regards >> Nandika >> >> On Fri, Jun 17, 2016 at 11:26 PM, Frank Leymann <[email protected]> wrote: >> >>> Hi Vinod, >>> >>> Whenever a user changes his/her substitute, we check for a circular >>> dependency. This check happens independent of the fact whether substitutes >>> are defined when the user are created ("modeling time") or when the >>> substitute of a user is changed during "runtime". Is that your >>> understanding too? >>> >>> If a circular dependency is detected, the request for the new substitute >>> is not accepted. And, yes, that's problematic because it may become quite >>> cumbersome or even impossible to find a possible substitute (i.e. one that >>> our cycle checker will accept). For example, in case of n users U1, >>> U2,...,Un user Ui has substitute Si and Si = U(i+1) with U(n+1)=U1 - we >>> have a problem. During modeling time their may be time to fix the problem, >>> but during runtime that may be critical. Setting the Reserved or >>> inProgress tasks of the user just defining his new substitute in state >>> Ready doesn't help because there may be no potential owners who may get >>> aware about the task. >>> >>> For this purpose, the key principle of Human Task is that the engine >>> must do everything to push tasks to (at least) Reserve status. This is done >>> by corresponding deadline processing, or by nomination: i.e. the engine >>> informs the Business Administrator of the task who then assigns the task to >>> an owner. But this may result in a burden of the Business Administrator in >>> case he will get many tasks to nominate. >>> >>> So, let's discuss. My current preference is to *not accept* a change in >>> the substitute definition in case a cyclic structure would result. WDYT? >>> >>> >>> >>> Best regards, >>> Frank >>> >>> 2016-06-16 3:31 GMT+02:00 Vinod Kavinda <[email protected]>: >>> >>>> 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" <[email protected]> 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 <[email protected]>: >>>> >>>>> 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 <[email protected]> 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 < >>>>>> [email protected]> 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 <[email protected]> >>>>>>> wrote: >>>>>>> >>>>>>>> >>>>>>>> On Wed, Jun 8, 2016 at 6:49 PM, Frank Leymann <[email protected]> >>>>>>>> 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/ >>>>> >>>>> >>>> >>> >> >> >> -- >> 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/ > >
_______________________________________________ Architecture mailing list [email protected] https://mail.wso2.org/cgi-bin/mailman/listinfo/architecture
