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)
>
> @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
>
>
--
Steve van der Merwe
Blog : http://www.stevevandermerwe.co.za
+27 84 978 3817
