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?

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?

Thanks,
-Maarten Winkels

On Jun 26, 2013, at 6:13 PM, Fabio Martelli <[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]> 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]> 
>>>> 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]> 
>>>>>> 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
>>>>>>>> 
>>>>>>>> 
>>>>>>> 
>>>>>> 
>>>>> 
>>>> 
>>> 
>> 
> 

Reply via email to