Francesco:

    thank you for your response and guidance.

    My mapping is identical to the demo site.

    So, thanks to your email, I've found a few things and made some changes.

    1:  The pull task was firing repeatedly because I'd placed a timer on
it without realizing.
    2:  There was no pull policy defined.
             I created one:
                  Conflict Resolution:  Ignore
                  Group:    rule type of plain attributes, and I selected
"name".

    I ran a pull cycle, and the error was no longer there.

   But, I'm not sure if the error has been resolved because of the
resolution strategy I chose, or because it's able to match on the name.  I
looked at the default correlation, and it appears it's doing the same
attribute matching, which makes me think my problem was resolved by
choosing "ignore".  I changed the strategy to first match, and again, no
errors on pull.

  If I'm understanding this correctly, without an explicit pull policy in
place, the default is to create, rather than update.  And using first or
last match, uses the first/last in LDAP as the source of changes to update
internal DB.  But, I'm not sure how "all" is then used.

   Have I got this all sorted?


thank you !




On Mon, Apr 2, 2018 at 11:50 AM, Francesco Chicchiriccò <[email protected]
> wrote:

> Hi Adam,
> shortly: there is a problem in your LDAP mapping.
>
> The errors reported below are consequence of a Pull Task's execution,
> where Syncope attempts to *create* Groups (according to the provided
> Mapping for the External Resource for which the Pull Task is executed),
> while it should instead *update* Groups.
>
> Why does it fail, then? It fails because the matching process [1] is not
> able to correctly identify the Group in Syncope which should match the
> given Group on LDAP.
>
> Could you please report your LDAP Group mapping?
>
> Regards.
>
> [1] https://syncope.apache.org/docs/reference-guide.html#provisioning-pull
>
>
> On 02/04/2018 11:30, Adam Levine wrote:
>
> I'm coming up to speed with Syncope, so this could be a newbie mistake,
> and I'm not sure how to fully trace/debug what's happening.  Please let me
> know what extra relevant information I can provide.
>
>
> v208
> Maven
> MariaDB 10.2.11
> ApacheDS 2.0.0-M24
>
> I have the LDAP connector wired up, and a singular instance for managing
> users and groups; this is the only external resource I have.
>
> I can create groups and users with no problem.
>
> If I connect them to the LDAP resource, they populate in DS.  I can edit
> values, and they are propagated to DS.
>
> However, the core.log fills up with repeated errors about a duplicate
> entry.   If I don't connect the user/group to LDAP, there are no errors in
> the log.  If I disconnect the user/group from LDAP, the log entries stop.
>
> This happens even on the first entry, so there's no chance there's
> actually a pre-existing entry.
>
> Thank you in advance for your assistance.
>
>
> Log Snippets:
>
> 03:20:02.358 ERROR 
> org.apache.syncope.core.provisioning.api.pushpull.SyncopeResultHandler
> - Could not create GROUP 72221ad0-d819-42f3-a0bb-1d21162866b1
> org.apache.openjpa.persistence.PersistenceException: The transaction has
> been rolled back.  See the nested exceptions for details on the errors that
> occurred.
>         at 
> org.apache.openjpa.kernel.BrokerImpl.newFlushException(BrokerImpl.java:2368)
> ~[openjpa-kernel-2.4.2.jar:2.4.2]
>         at org.apache.openjpa.kernel.BrokerImpl.flush(BrokerImpl.java:2205)
> ~[openjpa-kernel-2.4.2.jar:2.4.2]
> .....
>
> Caused by: org.apache.openjpa.persistence.EntityExistsException:
> (conn=1464) Duplicate entry 'abvc' for key 'U_SYNCGRP_NAME' {prepstmnt
> 1442070129 INSERT INTO SyncopeGroup (id, creationDate, creator,
> lastChangeDate, lastModifier, status, workflowId, name, REALM_ID,
> GROUPOWNER_ID, USEROWNER_ID) VALUES (?, ?, ?, ?, ?, ?, ?, ?, ?, ?,
>      ?)} [code=1062, state=23000]
>         at 
> org.apache.openjpa.jdbc.sql.DBDictionary.narrow(DBDictionary.java:4988)
> ~[openjpa-jdbc-2.4.2.jar:2.4.2]
>         at 
> org.apache.openjpa.jdbc.sql.DBDictionary.newStoreException(DBDictionary.java:4963)
> ~[openjpa-jdbc-2.4.2.jar:2.4.2]
>         at 
> org.apache.openjpa.jdbc.sql.SQLExceptions.getStore(SQLExceptions.java:133)
> ~[openjpa-jdbc-2.4.2.jar:2.4.2]
>         at 
> org.apache.openjpa.jdbc.sql.SQLExceptions.getStore(SQLExceptions.java:75)
> ~[openjpa-jdbc-2.4.2.jar:2.4.2]
>
> ....
>
> Caused by: org.apache.openjpa.lib.jdbc.ReportingSQLException: (conn=1464)
> Duplicate entry 'abvc' for key 'U_SYNCGRP_NAME' {prepstmnt 1442070129
> INSERT INTO SyncopeGroup (id, creationDate, creator, lastChangeDate,
> lastModifier, status, workflowId, name, REALM_ID, GROUPOWNER_ID,
> USEROWNER_ID) VALUES (?, ?, ?, ?, ?, ?, ?, ?, ?, ?, ?)              }
> [code=1062, state=23000]
>         at org.apache.openjpa.lib.jdbc.LoggingConnectionDecorator.wrap(
> LoggingConnectionDecorator.java:218) ~[openjpa-lib-2.4.2.jar:2.4.2]
>         at org.apache.openjpa.lib.jdbc.LoggingConnectionDecorator.wrap(
> LoggingConnectionDecorator.java:194) ~[openjpa-lib-2.4.2.jar:2.4.2]
>         at org.apache.openjpa.lib.jdbc.LoggingConnectionDecorator.
> access$1000(LoggingConnectionDecorator.java:58)
> ~[openjpa-lib-2.4.2.jar:2.4.2]
>         at org.apache.openjpa.lib.jdbc.LoggingConnectionDecorator$
> LoggingConnection$LoggingPreparedStatement.executeUpdate(
> LoggingConnectionDecorator.java:1133) ~[openjpa-lib-2.4.2.jar:2.4.2]
>         at org.apache.openjpa.lib.jdbc.DelegatingPreparedStatement.
> executeUpdate(DelegatingPreparedStatement.java:275)
> ~[openjpa-lib-2.4.2.jar:2.4.2]
>
> --
> 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/
>
>

Reply via email to