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

Reply via email to