You are viewing a plain text version of this content. The canonical link for it is here.
Posted to user@syncope.apache.org by Lionel SCHWARZ <li...@in2p3.fr> on 2024/04/11 08:30:30 UTC
Re: Propagation failure on update
----- Le 28 Mar 24, à 9:38, Lionel SCHWARZ lionel.schwarz@in2p3.fr a écrit :
> ----- Le 27 Mar 24, à 8:19, Francesco Chicchiriccò ilgrosso@apache.org a écrit :
>
>> On 26/03/24 13:30, Lionel SCHWARZ wrote:
>>> Dear all,
>>>
>>> After reading https://syncope.apache.org/docs/reference-guide.html#propagation,
>>> I ask myself a question: is there a way to avoid a User (or AnyObject) to be
>>> modified in case the propagation task fails?
>>
>> Hi Lionel,
>> that's exactly the purpose of setting a non-null priority onto an External
>> Resource:
>>
>> > the execution of a given set of tasks is halted (and global failure is reported)
>> > whenever the first sequential task fails
>>
>> would mean exactly that.
> Thanks Francesco, I'll try this.
Hi Francesco and all,
After investigations and tests, I could indeed check that the sequence of tasks stops when the first task fails.
But there is a remaining question: the attribute on the Entity itself (the USER), the one which triggered the propagation, keeps changed. So we are in the situation where the User has an attribute different than values in the remote repos.
Is there a way to do kind of rollback on the USER update in this case?
Lionel
Re: Propagation failure on update
Posted by Lionel SCHWARZ <li...@in2p3.fr>.
----- Le 16 Avr 24, à 8:39, Francesco Chicchiriccò ilgrosso@apache.org a écrit :
> On 11/04/24 10:30, Lionel SCHWARZ wrote:
>> ----- Le 28 Mar 24, à 9:38, Lionel SCHWARZ lionel.schwarz@in2p3.fr a écrit :
>>> ----- Le 27 Mar 24, à 8:19, Francesco Chicchiriccò ilgrosso@apache.org a écrit :
>>>
>>>> On 26/03/24 13:30, Lionel SCHWARZ wrote:
>>>>> Dear all,
>>>>>
>>>>> After reading https://syncope.apache.org/docs/reference-guide.html#propagation,
>>>>> I ask myself a question: is there a way to avoid a User (or AnyObject) to be
>>>>> modified in case the propagation task fails?
>>>> Hi Lionel,
>>>> that's exactly the purpose of setting a non-null priority onto an External
>>>> Resource:
>>>>
>>>>> the execution of a given set of tasks is halted (and global failure is reported)
>>>>> whenever the first sequential task fails
>>>> would mean exactly that.
>>> Thanks Francesco, I'll try this.
>> Hi Francesco and all,
>>
>> After investigations and tests, I could indeed check that the sequence of tasks
>> stops when the first task fails.
>> But there is a remaining question: the attribute on the Entity itself (the
>> USER), the one which triggered the propagation, keeps changed. So we are in the
>> situation where the User has an attribute different than values in the remote
>> repos.
>
> Yes, this happens by design: over time, we observed that refusing to upgrade
> Syncope because of a propagation error, even on priority resource, was too
> tight.
Good to know, thanks for your answer
Regards
Lionel
Re: Propagation failure on update
Posted by Francesco Chicchiriccò <il...@apache.org>.
On 11/04/24 10:30, Lionel SCHWARZ wrote:
> ----- Le 28 Mar 24, à 9:38, Lionel SCHWARZ lionel.schwarz@in2p3.fr a écrit :
>> ----- Le 27 Mar 24, à 8:19, Francesco Chicchiriccò ilgrosso@apache.org a écrit :
>>
>>> On 26/03/24 13:30, Lionel SCHWARZ wrote:
>>>> Dear all,
>>>>
>>>> After reading https://syncope.apache.org/docs/reference-guide.html#propagation,
>>>> I ask myself a question: is there a way to avoid a User (or AnyObject) to be
>>>> modified in case the propagation task fails?
>>> Hi Lionel,
>>> that's exactly the purpose of setting a non-null priority onto an External
>>> Resource:
>>>
>>>> the execution of a given set of tasks is halted (and global failure is reported)
>>>> whenever the first sequential task fails
>>> would mean exactly that.
>> Thanks Francesco, I'll try this.
> Hi Francesco and all,
>
> After investigations and tests, I could indeed check that the sequence of tasks stops when the first task fails.
> But there is a remaining question: the attribute on the Entity itself (the USER), the one which triggered the propagation, keeps changed. So we are in the situation where the User has an attribute different than values in the remote repos.
Yes, this happens by design: over time, we observed that refusing to upgrade Syncope because of a propagation error, even on priority resource, was too tight.
> Is there a way to do kind of rollback on the USER update in this case?
You will need to override a few components in order to do that, starting from UserLogic#update and following the flow.
Regards.
--
Francesco Chicchiriccò
Tirasa - Open Source Excellence
http://www.tirasa.net/
Member at The Apache Software Foundation
Syncope, Cocoon, Olingo, CXF, OpenJPA, PonyMail
http://home.apache.org/~ilgrosso/