[midPoint] tasks - fatal error

Oskar Butovič - AMI Praha a.s. oskar.butovic at ami.cz
Mon Jan 2 17:27:35 CET 2017


Thanks to Pavol I solved this problem by using paging and greaterOrEqual
filter. Follows task example:

<task xmlns="http://midpoint.evolveum.com/xml/ns/public/common/common-3"
         xmlns:c="http://midpoint.evolveum.com/xml/ns/public/common/common-3
"
         xmlns:q="http://prism.evolveum.com/xml/ns/public/query-3"
         xmlns:t="http://prism.evolveum.com/xml/ns/public/types-3"
         xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance">
        <name>Remove org</name>
<extension>
            <scext:executeScript xmlns:scext="
http://midpoint.evolveum.com/xml/ns/public/model/scripting/extension-3">
                <s:search xmlns:s="
http://midpoint.evolveum.com/xml/ns/public/model/scripting-3">
                    <s:type>c:UserType</s:type>
                    <s:query>
                        <q:filter>
                          <q:and>
                    <q:equal>
                          <q:path>activation/effectiveStatus</q:path>
                          <q:value>enabled</q:value>
                       </q:equal>
                       <q:greaterOrEqual>
                          <q:path>name</q:path>
                          <q:value>lastFailedUserLogin</q:value>
                       </q:greaterOrEqual>
                 </q:and>
                    </q:filter>
                    <q:paging>
                            <q:orderBy>name</q:orderBy>
                        </q:paging>
                    </s:query>
                    <s:action>
                        <s:type>modify</s:type>
                        <s:parameter>
                            <s:name>delta</s:name>
                            <c:value xsi:type="t:ObjectDeltaType">
                                <t:changeType>modify</t:changeType>
<!-- this is the default, can be omitted -->
                                <!-- objectType and oid are taken from the
object being modified -->

<t:itemDelta><t:modificationType>delete</t:modificationType><t:path>c:assignment</t:path><t:value
xsi:type="c:AssignmentType"><targetRef oid="org-drH2ULR8PZkhHN2Q9jODtg"
type="c:OrgType"/></t:value></t:itemDelta>
                            </c:value>
                        </s:parameter>
                    </s:action>
                </s:search>
            </scext:executeScript>
</extension>
        <ownerRef oid="00000000-0000-0000-0000-000000000002"/>
        <executionStatus>closed</executionStatus>

        <category>BulkActions</category>
        <handlerUri>
http://midpoint.evolveum.com/xml/ns/public/model/scripting/handler-3
</handlerUri>
        <recurrence>single</recurrence>
    </task>

2017-01-02 15:53 GMT+01:00 Oskar Butovič - AMI Praha a.s. <
oskar.butovic at ami.cz>:

> Hello everybody,
>
> I have returned to this problem because we now have long bulk tasks which
> end on first fatal error (usually data error). Would it be possible for the
> task to continue from user on which it ended and not go through all users
> again.
>
> Usuall scenarion is as follows:
>
> - task runs for several hours when it encounters data error and ends
> - we fix data
> - task runs for several hours again on users who are already processed
> passes user which we fixed and ends after several minutes on next data
> error (back to step 2)
>
> Could you please recommend any way around it?
>
> Best Regards
>
> Oskar Butovič
>
>
> 2016-12-23 9:19 GMT+01:00 Oskar Butovič - AMI Praha a.s. <
> oskar.butovic at ami.cz>:
>
>> Ok thanks a lot Pavol.
>>
>> I did the mistake by using bulk task ( http://midpoint.evolveum.com/x
>> ml/ns/public/model/scripting/handler-3 ) for rocompute. Which was mayor
>> problem due to its stop on first error. Ill try using
>> http://midpoint.evolveum.com/xml/ns/public/model/
>> synchronization/task/recompute/handler-3 then.
>>
>> 2016-12-22 18:19 GMT+01:00 Pavol Mederly <mederly at evolveum.com>:
>>
>>> Oskar,
>>>
>>> it depends on what kind of task you are working with. Generally, tasks
>>> like reconciliation, recomputation, live sync, import should continue even
>>> in the face of fatal errors.
>>>
>>> However, bulk actions are quite unfinished in this respect. I planned to
>>> implement some kind of configurable "on error" behaviors, but ... there was
>>> (and still is) no time to do that. So the only approach for bulk actions is
>>> "stop on first error".
>>>
>>> Pavol Mederly
>>> Software developerevolveum.com
>>>
>>> On 22.12.2016 17:42, Oskar Butovič - AMI Praha a.s. wrote:
>>>
>>> Hello everybody,
>>>
>>> is there any way in midpoint how to make task continue on another user
>>> even when experienced fatal error during execution?
>>>
>>> Best Regards
>>>
>>> Oskar Butovič
>>>
>>> --
>>>
>>> Oskar Butovič
>>> solution architect
>>>
>>> gsm: [+420] 774 480 101 <+420%20774%20480%20101>
>>> e-mail: oskar.butovic at ami.cz
>>>
>>>
>>> AMI Praha a.s.
>>> Pláničkova 11
>>> 162 00 Praha 6
>>> tel.: [+420] 274 783 239 <+420%20274%20783%20239>
>>> web: www.ami.cz
>>>
>>>
>>> [image: AMI Praha a.s.]
>>>
>>> [image: AMI Praha a.s.]
>>> <http://www.ami.cz/reseni-a-sluzby/bezpecnost-dat/identity-management>
>>>
>>> Textem tohoto e-mailu podepisující neslibuje uzavřít ani neuzavírá za
>>> společnost AMI Praha a.s.
>>> jakoukoliv smlouvu. Každá smlouva, pokud bude uzavřena, musí mít
>>> výhradně písemnou formu.
>>>
>>>
>>>
>>> _______________________________________________
>>> midPoint mailing listmidPoint at lists.evolveum.comhttp://lists.evolveum.com/mailman/listinfo/midpoint
>>>
>>>
>>>
>>> _______________________________________________
>>> midPoint mailing list
>>> midPoint at lists.evolveum.com
>>> http://lists.evolveum.com/mailman/listinfo/midpoint
>>>
>>>
>>
>>
>> --
>>
>> Oskar Butovič
>> solution architect
>>
>> gsm: [+420] 774 480 101 <+420%20774%20480%20101>
>> e-mail: oskar.butovic at ami.cz
>>
>>
>> AMI Praha a.s.
>> Pláničkova 11
>> 162 00 Praha 6
>> tel.: [+420] 274 783 239 <+420%20274%20783%20239>
>> web: www.ami.cz
>>
>>
>> [image: AMI Praha a.s.]
>>
>> [image: AMI Praha a.s.]
>> <http://www.ami.cz/reseni-a-sluzby/bezpecnost-dat/identity-management>
>>
>> Textem tohoto e-mailu podepisující neslibuje uzavřít ani neuzavírá za
>> společnost AMI Praha a.s.
>> jakoukoliv smlouvu. Každá smlouva, pokud bude uzavřena, musí mít výhradně
>> písemnou formu.
>>
>>
>
>
> --
>
> Oskar Butovič
> solution architect
>
> gsm: [+420] 774 480 101 <+420%20774%20480%20101>
> e-mail: oskar.butovic at ami.cz
>
>
> AMI Praha a.s.
> Pláničkova 11
> 162 00 Praha 6
> tel.: [+420] 274 783 239 <+420%20274%20783%20239>
> web: www.ami.cz
>
>
> [image: AMI Praha a.s.]
>
> [image: AMI Praha a.s.]
> <http://www.ami.cz/reseni-a-sluzby/bezpecnost-dat/identity-management>
>
> Textem tohoto e-mailu podepisující neslibuje uzavřít ani neuzavírá za
> společnost AMI Praha a.s.
> jakoukoliv smlouvu. Každá smlouva, pokud bude uzavřena, musí mít výhradně
> písemnou formu.
>
>


-- 

Oskar Butovič
solution architect

gsm: [+420] 774 480 101
e-mail: oskar.butovic at ami.cz


AMI Praha a.s.
Pláničkova 11
162 00 Praha 6
tel.: [+420] 274 783 239
web: www.ami.cz


[image: AMI Praha a.s.]

[image: AMI Praha a.s.]
<http://www.ami.cz/reseni-a-sluzby/bezpecnost-dat/identity-management>

Textem tohoto e-mailu podepisující neslibuje uzavřít ani neuzavírá za
společnost AMI Praha a.s.
jakoukoliv smlouvu. Každá smlouva, pokud bude uzavřena, musí mít výhradně
písemnou formu.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://lists.evolveum.com/pipermail/midpoint/attachments/20170102/c3995af0/attachment.htm>


More information about the midPoint mailing list