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/
>>
>>
>
_______________________________________________
Architecture mailing list
[email protected]
https://mail.wso2.org/cgi-bin/mailman/listinfo/architecture
