Maarten Winkels <[email protected]> ha scritto:
>Hi Fabio > >@1: How can I map it to an item? It is the result of the create method >and not available as a field in the schema of the resource. Is there a >way to map the result of the create method? Please, provide a mapping example of your configuration (or a screenshot) in order to be able to provide you a precise answer/tips. >@2: Does that mean that Syncope doesn't work with resource assigned >ids? I would need the id the resource assigned to be able to delete the >account, not the is Syncope has assigned. No it doesn't. Your issue is just a mapping problem. As per 1, please let me have your use case in order to be of your help. > >Cheers! > >-Maarten Winkels > >On Apr 16, 2013, at 4:03 PM, Fabio Martelli <[email protected]> >wrote: > >> >> Il giorno 16/apr/2013, alle ore 15.41, Maarten Winkels ha scritto: >> >>> Hi Fabio, >>> >>> Thanks for your reply. >>> >>> I think I have a number of very basic questions on how syncope works >with the connector: >>> 1. Is Uid, that is created by the connector when the Account is >created, stored by Syncope? Can I make Syncope pass it to the delete >operation when that Account is deleted? >> It have to be a mapping item. >>> 2. How does the accountLink property work with creating/deleting >Accounts? I understand that the __NAME__ attribute will be filled with >the evaluated accountLink and the __UID__ with the AccountId (which is >configured in the mapping). >> __UID__ will be used during dele and update to resolve user/group >>> 3. Should I store the Syncope ID in the resource as a separate >field, to be able to search the resource on it? >> not necessary >>> >>> Thanks! >>> >>> Maarten Winkels | IWelcome BV >>> >>> Wiersedreef 5-7 >>> 3433 ZX Nieuwegein >>> The Netherlands >>> >>> Tel: +31 (0) 30 6592254 >>> Mob. +31 (0) 6 10038878 >>> Email: [email protected] >>> Website: http://www.iwelcome.com >>> >>> <iWelcome Signature - ISO.jpg> >>> >>> >>> >>> The information in this Internet email is confidential and may be >legally privileged. It is intended solely for the addressee. Access to >this Internet email by anyone else is unauthorised. If you are not the >intended recipient, any disclosure, copying, distribution or any action >taken or omitted to be taken in reliance on it is prohibited and may be >unlawful. When addressed to our clients any opinions or advice >contained in this Internet email are subject to the terms and >conditions expressed in any applicable governing Everett terms of >business or client engagement letter. >>> >>> >>> >>> On Apr 16, 2013, at 2:38 PM, Fabio Martelli ><[email protected]> wrote: >>> >>>> >>>> Il giorno 16/apr/2013, alle ore 11.33, Maarten Winkels ha scritto: >>>> >>>>> Hello, >>>>> >>>>> We're currently developing a new connector with the connid >framework. We run into some question on how the conn if connector API >is used by Syncope. >>>>> >>>>> Implementing and integrating the create method was very simple: We >can see account being provisioned to the resource. >>>>> >>>>> Question 1: >>>>> Syncope seems (however) not to use the delete method correctly if >the connector doesn't implement the SearchOp interface: First the >current data is requested using the search operation and ONLY if this >returns a ConnectorObject the delete is executed. If the SearchOp is >not implemented or returns NULL, Syncope silently ignores the delete >operation. >>>> >>>> Hi Maarten, yes this is the current behavior: Syncope search for >user (collect profile), then remove it if exists, and search again >(collect new profile - empty if deleted). >>>> The two searches are currently used to report differences between >before and after op. >>>>> >>>>> <code >location="org.apache.syncope.core.propagation.impl.AbstractPropagationTaskExecutor:287"> >>>>> // Try to read remote object (user / group) BEFORE any >actual operation >>>>> beforeObj = getRemoteObject(task, connector, false); >>>>> </code> >>>>> >>>>> <code >location="org.apache.syncope.core.propagation.impl.AbstractPropagationTaskExecutor:234"> >>>>> if (beforeObj == null) { >>>>> LOG.debug("{} not found on external resource: ignoring >delete", task.getAccountId()); >>>>> } else {... >>>>> </code> >>>>> >>>>> Can this behaviour be configured? >>>> >>>> This behavior cannot be cunfigured. You can change it only >overriding methods. >>>> >>>>> >>>>> Question 2: >>>>> The resource assigns it's own id's, based on the location of the >account in the tree. The connector returns the created ID as a Uid to >Syncope. When deleting the account from Syncope, the assigned Uid is >not used, but only the "Syncope-ID" is provided to the connector to >delete the account. >>>>> How should the connector retrieve the assigned ID? >>>> >>>> This is a configuration error: accountLink (if not empty) or >AccountId (if accountLink is empty) will always used as __NAME__ >attribute; __UID__ attribute will be propagated with AccountId value. >>>> >>>> Regards, >>>> F. >>> >> -- Inviato dal mio cellulare Android con K-9 Mail.
