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)
@Override
public 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
@Override
public 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
delete.log
Description: Binary data
create.log
Description: Binary data
