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] <mailto:[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); } AttributegetKeyFromFilter(Filter filter) { Attribute key =null; if (filterinstanceof EqualsFilter) { key =((EqualsFilter)
filter).getAttribute(); if (keyinstanceof 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] <mailto:[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] <mailto:[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] <mailto:[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 Excellence
http://www.tirasa.net/
Member at The Apache Software Foundation
Syncope, Cocoon, Olingo, CXF, OpenJPA, PonyMail
http://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
