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? @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.
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. >> >
