Hi Andrea Thank you very much - You are spot on.
It was the fact that it was expecting an array but I was accidentally passing back an array of arrays It seems that it is all working now and propagating correctly. Thank you all very much for your help, it is very much appreciated Regards Steve On Thu, Nov 28, 2019 at 12:02 PM Andrea Patricelli < [email protected]> wrote: > Hi Steven, > > the error that you are experiencing is quite generic. But usually means > that the key that you passed from Syncope is not matching the key of the > object that the connector framework retrieved with the query method. As > "not matching" I mean that the EqualsFilter [1] (or EqualsIgnoreCaseFilter > [2]) is not accepting the two objects passed, i.e. the equals of the two > objects in accept method returns false. > > Usually this depends on the mapping in Syncope or on the type of the key > returned by the connector, that is not matching the key passed from Syncope. > > Best regards, > Andrea > > [1] > https://github.com/Tirasa/ConnId/blob/connid-1.5.0.1/java/connector-framework/src/main/java/org/identityconnectors/framework/common/objects/filter/EqualsFilter.java > [2] > https://github.com/Tirasa/ConnId/blob/connid-1.5.0.1/java/connector-framework/src/main/java/org/identityconnectors/framework/common/objects/filter/EqualsIgnoreCaseFilter.java > Il 26/11/19 16:19, Steven van der Merwe ha scritto: > > Hi > > I managed to work out why it was not propagating the __UID__ - It turns > out I had the config for the "mapping" the wrong way around. > > I have now moved a bit further forward but I am stuck on the following > > java.lang.IllegalStateException: Object {Uid=Attribute: {Name=__UID__, > Value=[[db1c50ed-5224-46e7-8bf1-89934c50852c]]}, ObjectClass=ObjectClass: > __GROUP__, Attributes=[Attribute: {Name=__NAME__, Value=[KinesisName]}, > Attribute: {Name=__UID__, Value=[[db1c50ed-5224-46e7-8bf1-89934c50852c]]}, > Attribute: {Name=realm, Value=[/]}, Attribute: {Name=name, Value=[name]}], > Name=Attribute: {Name=__NAME__, Value=[KinesisName]}} was returned by the > connector but failed to pass the framework filter. This seems like wrong > implementation of the filter in the connector. > at > org.identityconnectors.framework.impl.api.local.operations.FilteredResultsHandler.handle(FilteredResultsHandler.java:82) > ~[connector-framework-internal-1.5.0.1.jar:?] > > I found someone else on the forums with the same issue and I have ensured > that all of the attributes are there however it doesnt seem to work > > Regards > Steve > > > On Tue, Nov 26, 2019 at 9:01 AM Steven van der Merwe < > [email protected]> wrote: > >> Hi >> >> I am still a little confused for the following reason. In my search >> method there is no __UID__ anywhere am I missing something? >> >> For context my executeQuery looks like this (my log function uses >> recursion to print out all of the values) >> >> @Overridepublic void executeQuery( final ObjectClass objectClass, >> final Filter filter, final ResultsHandler handler, final >> OperationOptions options) { PropagationDto propagationDto = new >> PropagationDto.Builder() .objectClass(objectClass) >> .query(filter) .options(options) >> .operation(PropagationDto.Operation.QUERY) .build(); >> sendDetails("executeQuery", propagationDto, true); try { Attribute >> key = getKeyFromFilter(filter); log("Key = ", key); >> ConnectorObjectBuilder bld = new ConnectorObjectBuilder(); >> bld.setUid(key.getValue().toString()); bld.setName(key.getName()); >> ConnectorObject ret = bld.build(); handler.handle(ret); }catch >> (UnsupportedOperationException uoe){ log("Search operation problem :" >> + uoe.getMessage()); } log("Search parameters: ObjectClass -", >> objectClass); log("Search parameters: Options -", options); >> log("Search parameters: Results -", handler); log("Search parameters: >> query -", filter);}Attribute getKeyFromFilter(Filter filter) { Attribute >> key = null; if (filter instanceof EqualsFilter) { key = >> ((EqualsFilter) filter).getAttribute(); if (key instanceof Uid) { >> log("Key is Uid"); } }else { throw new >> UnsupportedOperationException("Not yet supported"); } return key;} >> >> >> >> And my FilterTranslator like so >> >> @Overridepublic FilterTranslator<Filter> createFilterTranslator(final >> ObjectClass objectClass, final OperationOptions options) { return new >> FilterTranslator<Filter>() { @Override public List<Filter> >> translate(Filter filter) {//Just log for now log("Filter >> ObjectClass -", objectClass); log("Filter options -", options); >> log("Filter filter -", filter); return >> CollectionUtil.newList(filter); } };} >> >> >> As you can see they dont do much >> >> >> Attached are the logs for create and delete (the key is the key that I >> send back from the create not the __UID__) >> >> >> >> Thanks in advance >> >> Regards >> Steve >> >> On Mon, Nov 25, 2019 at 11:29 AM Steven van der Merwe < >> [email protected]> wrote: >> >>> Perfect - thank you very much >>> >>> I will try >>> >>> Regards >>> Steve >>> >>> On Mon, Nov 25, 2019 at 11:05 AM Francesco Chicchiriccò < >>> [email protected]> wrote: >>> >>>> On 25/11/19 09:47, Steven van der Merwe wrote: >>>> >>>> Hi Francesco >>>> >>>> Thank you very much for your reply - I think you have hit on the >>>> problem. >>>> >>>> Based on your response I think it is definitely the read logic that is >>>> the problem since CREATE -> Creates, UPDATE -> Creates, DELETE -> >>>> NOT_ATTEMPTED. >>>> >>>> My problem is that I do not want to read from the downstream source as >>>> I want to put deltas (UPDATE,DELETE,CREATE) onto a queue. In other words I >>>> think I want to make the search return a fake "FOUND" on UPDATE and DELETE >>>> operations in the SEARCH. Is that possible? >>>> >>>> I think you have two options here: >>>> >>>> 1. (simpler) make your connector's READ code returning an almost empty >>>> object - I say "almost" because __UID__ and the querying attribute shall be >>>> anyway populated >>>> >>>> 2. (more difficult) provide your own implementation of Task Executor >>>> (possibly extending PriorityPropagationTaskExecutor as indicated in the >>>> docs) with purpose of skipping READ before (and after) CREATE / UPDATE / >>>> DELETE. >>>> >>>> Regards. >>>> >>>> On Mon, Nov 25, 2019 at 9:58 AM Francesco Chicchiriccò < >>>> [email protected]> wrote: >>>> >>>>> Hi Steve, >>>>> first of all, thanks for your words, they're highly appreciated. >>>>> >>>>> Coming to your issue below, I believe the problem is either related to >>>>> your mapping configuration or Connector's READ implementation. >>>>> Having [1] as background, propagation to an External Resource works as >>>>> follows: >>>>> >>>>> CREATE requested: >>>>> 1. READ >>>>> 2. CREATE (if READ was unsuccessful) or UPDATE (if READ was successful) >>>>> >>>>> UPDATE requested: >>>>> 1. READ >>>>> 2. CREATE (if READ was unsuccessful) or UPDATE (if READ was successful) >>>>> >>>>> DELETE requested: >>>>> 1. READ >>>>> 2. NOT_ATTEMPTED (if READ was unsuccessful) OR DELETE (if READ was >>>>> successful) >>>>> >>>>> So, it seems your current troubles lie in the last case: when DELETE >>>>> is requested, the preliminary READ operation does not find any matching >>>>> object onto the External Resource. >>>>> This can happen because either (1) the Remote Key value as indicated >>>>> in the mapping is not enough to uniquely identify an object onto the >>>>> External Resource or (2) the READ operation implemented by the Connector >>>>> code is not working as expected. >>>>> >>>>> I invite you to carefully examine the core-connid.log content to >>>>> investigate the actual reason of such behavior. >>>>> >>>>> FYI there is some change coming in this area with Syncope 2.1.6 [2]- >>>>> an addition to the current feature set where matching the remote object >>>>> can >>>>> be performed either by Remote Key (as currently) or via Push Correlation >>>>> Rule [3]. >>>>> >>>>> HTH >>>>> Regards. >>>>> >>>>> [1] >>>>> http://syncope.apache.org/docs/2.1/reference-guide.html#propagation >>>>> [2] https://issues.apache.org/jira/browse/SYNCOPE-1499 >>>>> [3] >>>>> http://syncope.apache.org/docs/2.1/reference-guide.html#push-correlation-rules >>>>> >>>>> On 24/11/19 12:36, Steven van der Merwe wrote: >>>>> >>>>> Hi >>>>> >>>>> Firstly, thank you very much for a great piece of software. >>>>> >>>>> I wonder if any kind soul could help me with an issue I am having (it >>>>> is probably my understanding that is lacking) and I have been struggling >>>>> with it for about 4 day now. >>>>> >>>>> I have written my own connector to push data from Syncope to a graph >>>>> database (It is a one way push only). Now the issue I am having is that >>>>> CREATE works fine and call the appropriate method in my connector and does >>>>> what is expected however both DELETE and UPDATE are not being called at >>>>> all. I have created a search method (But I do not have anything to search >>>>> on the other side), however it does not seem to pass any information to >>>>> the >>>>> search. >>>>> >>>>> I have set up the following: >>>>> - Connector (with Sync,Search,create,authenticate,update,delete >>>>> selected) >>>>> - Resource on connector (with above selected) >>>>> - Account policy set >>>>> - Push policy set (IGNORE conflict resolution set) >>>>> - I have created a provisioning rule >>>>> - __GROUP__ >>>>> - Set up mapping with keys etc () >>>>> - no object link >>>>> >>>>> When I test it does the following: >>>>> - Create group : works and calls my connector >>>>> - Delete group : does not call my connector (In the propagation task >>>>> log it says NOT_ATTEMPTED) -> I have implemented all of the needed methods >>>>> in my connector I think? >>>>> >>>>> Please could someone point me in the right direction as this is >>>>> driving me crazy >>>>> >>>>> Regards >>>>> Steve >>>>> >>>>> -- >>>> Francesco Chicchiriccò >>>> >>>> Tirasa - Open Source Excellencehttp://www.tirasa.net/ >>>> >>>> Member at The Apache Software Foundation >>>> Syncope, Cocoon, Olingo, CXF, OpenJPA, >>>> PonyMailhttp://home.apache.org/~ilgrosso/ >>>> >>>> >>> >>> -- >>> Steve van der Merwe >>> Blog : http://www.stevevandermerwe.co.za >>> +27 84 978 3817 >>> >>> >> >> -- >> Steve van der Merwe >> Blog : http://www.stevevandermerwe.co.za >> +27 84 978 3817 >> >> > > -- > Steve van der Merwe > Blog : http://www.stevevandermerwe.co.za > +27 84 978 3817 > > -- > Dott. Andrea Patricelli > Tel. +39 3204524292 > > Engineer @ Tirasa S.r.l. > Viale Vittoria Colonna 97 - 65127 Pescara > Tel +39 0859116307 / FAX +39 0859111173http://www.tirasa.net > > Apache Syncope PMC Member > > -- Steve van der Merwe Blog : http://www.stevevandermerwe.co.za +27 84 978 3817
