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
<stevevanderme...@gmail.com <mailto:stevevanderme...@gmail.com>>
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
<stevevanderme...@gmail.com
<mailto:stevevanderme...@gmail.com>> wrote:
Perfect - thank you very much
I will try
Regards
Steve
On Mon, Nov 25, 2019 at 11:05 AM Francesco Chicchiriccò
<ilgro...@apache.org <mailto:ilgro...@apache.org>> 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ò <ilgro...@apache.org
<mailto:ilgro...@apache.org>> 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
