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?

>> 
>>> 
>>>> 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