Il 26/06/2013 21:27, Maarten Winkels ha scritto:
Hi Fabio,
The problem here is that the ID generated by the resource cannot be
guessed based on the values known. The resource returns the value,
after creation and this value is returned through the ConnId Connector
interface (public Uid create(ObjectClass objectClass, Set<Attribute>
attributes, OperationOptions operationOptions)). However, Syncope
seems to ignore the return value of this method. I really don't
understand why this is. Why can Syncope not retain this return value
and use it later for updates. That seems to be how the ConnId
Connector interface was intended (create returns a Uid and update
requires one as per interface definition). Can you shed some light on
this issue?
Hi Maarten, now it is clearer.
Actually your connector is the first one implementing this behavior ...
but, from my ppov, your requirement is not so strange.
Fortunately, Apache Syncope can be instrumented to take care of the
create method's returned value.
You have to develop your simple propagation action:
1. [before action] in case of update replace __UID__ value with the
value of the attribute XXX (see below)
2 [after action] in case of create take care to set XXX user attribute
with the value returned by the create operation.
Maybe, as a work around, I can store the value in some attribute that
is returned by the connector. However, I have no idea how to configure
this correctly in Syncope and it seems like a strange work around: the
return value should simply be picked up. Is this the correct approach,
you think?
This is not a strange workaround: [sync/propagation] actions give you a
great flexibility about target resources exchanged data management.
Rgds,
F.
Thanks,
-Maarten Winkels
On Jun 26, 2013, at 6:13 PM, Fabio Martelli <[email protected]
<mailto:[email protected]>> wrote:
Il 26/06/2013 18:05, Maarten Winkels ha scritto:
On Jun 26, 2013, at 5:28 PM, Fabio Martelli
<[email protected] <mailto:[email protected]>> wrote:
Il 26/06/2013 15:01, Maarten Winkels ha scritto:
Hi Fabio,
Thanks, it is much clearer now.
A few questions (see inline below).
On Jun 26, 2013, at 2:20 PM, Fabio Martelli
<[email protected] <mailto:[email protected]>> wrote:
Il 26/06/2013 12:01, Maarten Winkels ha scritto:
Hi Fabio,
Thanks for your reply!
The screenshots shows the user mapping.
<Mail Attachment.png>
As you can see, no account link is configured. I do see the
account link when I create a new user:
<Mail Attachment.png>
This is normal. If AccountLink is not specified, AccountId value
will be used in place of it.
The AccountId reported above should be the value of __UID__
attribute.
I mean, it seems that your connector is returning
__NAME__: data\identities\fabio
__UID__: fabio
This is correct
I think that your update method is expecting
"data\identities\fabio" as __UID_ parameter but you are providing
"fabio".
..or as __NAME__ parameter, or any other parameter.
Does syncope store the __NAME__ returned by the connector somehow?
It depends on the AccountId mapping: internal attribute will be the
one mapped as AccountId.
So is there a way to configure the Account Link to achieve what I want?
That would be: use the value provided by the connector (picked up by
Syncope as __NAME__) as __UID__ value?
Try to use a derived attribute mapped as AccountId.
Rgds,
F.
If I try to change this user, however, I do not get the Account
Link value in any of the attributes.
This is normal. See above.
Is there a way to configure Syncope to do this?
I think you have to change your connector: as per LDAP connector,
your update method should expect the actual uid (not the full dn).
If this is not possible, you have to define a derived attribute
(like 'data\identities\' + username) to set as AccountId.
I can see two possible ways to fix this right now:
1) Use a derived attribute (or the account link?) to construct the
id to update.
2) Do a search in the connector.update to find the correct ID and
then update it.
However, I'm still not sure why the __NAME__ value that the
connector provides is not being used to update the value. What is
the rational for this?
see the signature of ConnId connectors.
__UID__ will be used to search for entry to be modified.
Anyway, nothing prevents to you to change this behavior on
connector side: use a derived attribute to send a __UID__ valued
with a dn.
Regards,
F.
Thanks,
-Maarten Winkels
HTH,
F.
Thanks!!
-Maarten Winkels
On Jun 26, 2013, at 11:11 AM, Fabio Martelli
<[email protected] <mailto:[email protected]>> wrote:
Il 26/06/2013 10:56, Maarten Winkels ha scritto:
Dear all,
I'm trying to created a connector for an SPML interface. I
need to implement the following scenario:
- A User object is provisioned through the connector. The
resource returns a SPML PsoID as identifier for the newly
created object.
- A change to the user is provisioned through the connector.
The resource uses the PsoID to identify the User object.
Provisioning a new user using the SPML addRequest works fine
and in the syncope-console I can see the correct PsoID
mentioned as "AccountLink". *This surprises me, because I have
no account Link configured in the mapping.*
*
*
When a change is made, however, I do not get the correct
accountLink in the connector and thus cannot create a correct
modifyRequest.
How do I configure syncope to store the accountLink and
provide it to the connector on changes?
Hi Marteen,
please, post your mapping configuration (maybe a screenshot).
Provided information are insufficient to make a diagnosis.
Best regards,
F.
Thanks in advance!
Best regards,
-Maarten Winkels
