Hi Mikael,
using pullUtils to get internal matches (if found) is exactly the
best-practice for preprocess() to get internal data, congrats :-)
Regards.
On 07/12/2017 09:10, Mikael Ekblom wrote:
Hi,
Thank you for the answer. Yes, I found the SyndDeltaBuilder when I was
looking around. The thing was more ,that I needed the current internal
entity information together with the syncdelta due to the fact that
the contents of the syncdelta (in our case )should be determined by
the roles currently assigned to the user at the time we retrieve the
SyncDelta through the connector. In that sense, the 2.0.6 version was
more straightforward or maybe easier to use, but I do see your point
here…J
Anyhow, I decided to use the pullutil to get the current user that
matched the syncdelta uid to get the currently assigned roles and it
seems to work. I then just as you said rebuilt the syncdelta
accordingly via the SyncDeltaBuilder.
Regards,
Mikael
*Mikael Ekblom *
System developer
Arcada, IT
Jan-Magnus Janssons plats 1,
FIN-00560 Helsingfors,
Finland
TFn: +358 207 699 467
Mobil: +358 207 699 467
*From:*Francesco Chicchiriccò [mailto:[email protected]]
*Sent:* tiistai 5. joulukuuta 2017 10.08
*To:* [email protected]
*Subject:* Re: Question regarding upcoming PullAction changes in
version 2.0.7
Hi Mikael,
the SyncDelta processing was modified by SYNCOPE-1234 [1].
The new preprocess() method is invoked before any other method of the
provided implementation, giving clear chance to alter the data coming
from underlying resource prior to any other Syncope-side consideration.
Before [1] the logic was not adequate as the internal matching logic
[3] could not be influenced by PullActions.
You have already discovered that SyncDelta instances are immutable;
what you are currently missing is that you can use SyncDeltaBuilder
[4] to generate new SyncDelta instances.
HTH
Regards.
[1] https://issues.apache.org/jira/browse/SYNCOPE-1234
[2]
https://github.com/apache/syncope/blob/2_0_X/core/provisioning-api/src/main/java/org/apache/syncope/core/provisioning/api/pushpull/PullActions.java#L40
[3]
https://github.com/apache/syncope/blob/2_0_X/core/provisioning-java/src/main/java/org/apache/syncope/core/provisioning/java/pushpull/AbstractPullResultHandler.java#L741
[4]
http://connid.tirasa.net/apidocs/1.4/org/identityconnectors/framework/common/objects/SyncDeltaBuilder.html
On 04/12/2017 16:40, Mikael Ekblom wrote:
Hi,
I have one question: in version 2.0.7 I have noticed that you have
added a preprocess function to the default pull actions class. We
would like to alter the syncdelta in certain cases ie the user
should be kept as enabled (ie. __ENABLED__ set to true) as the
user can have two different roles simultaneously and one primary
role should be kept even though if the user is seen to have lost
one primary role in the case that the user (as an example) has
graduated and has been archived within the study register
(__ENABLED__ set to false within the connector in this case) + we
get a match for the user and this archive. We get a match, but the
user should be set to active.
Arcada do not deprovision the users directly either if an entity
matches an archived version for a specific master source.
The user might still have a role as staff or employee and the
syncdelta should be set to __ENABLE__=true in this particular case
but the rest of the roles bound to the student role should be
removed.
This could be done in 2.0.6 within the beforeupdate function also,
that in version 2.0.6 returned the SyncDelta but in version 2.0.7
the same function returns void. How is this supposed to work in
the new implementation in 2.0.7 when you do not have the user
information (or entity together with role information) available
directly within the current function and syncdelta scope within
preprocess? The SyncDelta object just has an read-only map of the
current syncdelta attributes as far as I have seen if you try to
alter the attributes within beforeupdate, so it seems to be too
late for that there. You basically have to look up the user
through the __UID__ I guess within preprocess, but through which
function and through which library? What is the best option you
have in this case?
It is enough if you have a hint to give and I’ll find the rest. I
hope this text is somehow understandable!
Regards,
Mikael
--
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/ <http://home.apache.org/%7Eilgrosso/>
--
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/
