Page History

Why I can see some DB workload even when Syncope is idle?

This happens because Syncope delegates to Quartz the handling of scheduled jobs.

Jobs take care of reporting, notification, propagation, synchronization from external resources and also user-defined actions.

I get the error "WorkflowException: ... No outgoing sequence flow..." when updating an user

When the Activiti workflow adapter is enabled, this means that the given user has a workflow state for which no update is allowed.
If you want instead to allow such transitions, you will need to update the workflow definition accordingl, through the admin console.

I get the error "An error occurred while registering a ClassTransformer with PersistenceUnitInfo..." during startup

This is harmless according to OpenJPA.

In embedded mode I get the error "Deployable http://localhost:9080/cargocpc/index.html failed to finish deploying within the timeout period 120000. The Deployable state is thus unknown"

This barely means that 2 minutes are not enough for setting up everything on the given hardware: you can configure this timeout by changing, in console/pom.xml:

      <plugin>
        <groupId>org.codehaus.cargo</groupId>
        <artifactId>cargo-maven2-plugin</artifactId>
        <inherited>true</inherited>
        <configuration>
          <container>

to

      <plugin>
        <groupId>org.codehaus.cargo</groupId>
        <artifactId>cargo-maven2-plugin</artifactId>
        <inherited>true</inherited>
        <configuration>
          <container>
            <timeout>180000</timeout>

Sync / Pull Task Execution report not generated when large number of users (e.g. 1000+) exist in MySQL

We can track the cause if we see errors in the core.log as follows:

Caused by: org.apache.openjpa.lib.jdbc.ReportingSQLException: Data truncation: Data too long for column 'message' at row 1 {prepstmnt 1398507577 INSERT INTO TaskExec (id, endDate, message, startDate, status, TASK_ID) VALUES (?, ?, ?, ?, ?, ?)} [code=1406, state=22001]

The root cause of such trouble is the JPA annotation @Lob which becomes TEXT column type in MySQL.

However, MySQL features some more textual type variants, so when changing the message column definition in the TaskExec table from TEXT to MEDIUMTEXT or LONGTEXT and then restart Syncope, permitting OpenJPA to get the change, you will overcome this limitation.

For example:

mysql> describe TaskExec;
+-----------+--------------+------+-----+---------+-------+
| Field     | Type         | Null | Key | Default | Extra |
+-----------+--------------+------+-----+---------+-------+
| id        | bigint(20)   | NO   | PRI | NULL    |       |
| endDate   | datetime     | YES  |     | NULL    |       |
| message   | text         | YES  |     | NULL    |       |
| startDate | datetime     | YES  |     | NULL    |       |
| status    | varchar(255) | NO   |     | NULL    |       |
| TASK_ID   | bigint(20)   | YES  | MUL | NULL    |       |
+-----------+--------------+------+-----+---------+-------+
6 rows in set (0.00 sec)

The following command changes the TEXT type value above to MEDIUMTEXT type.

mysql> ALTER TABLE TaskExec MODIFY message MEDIUMTEXT;

mysql> describe TaskExec;
+-----------+--------------+------+-----+---------+-------+
| Field     | Type         | Null | Key | Default | Extra |
+-----------+--------------+------+-----+---------+-------+
| id        | bigint(20)   | NO   | PRI | NULL    |       |
| endDate   | datetime     | YES  |     | NULL    |       |
| message   | mediumtext   | YES  |     | NULL    |       |
| startDate | datetime     | YES  |     | NULL    |       |
| status    | varchar(255) | NO   |     | NULL    |       |
| TASK_ID   | bigint(20)   | YES  | MUL | NULL    |       |
+-----------+--------------+------+-----+---------+-------+
6 rows in set (0.00 sec)

After sync / pull, users do not get assigned any external resource

By default, users are created in Syncope after sync / pull only with data provided by the external resource.

If you want to enrich such users, upon create or update after sync / pull, you need to provide an UserTemplate for the related Task.

Note that this mechanism allows to add various details to synchronizing / pulled users: password, attributes, resources, roles, etc.

How to clean up tasks?

The easiest way to perform this cleaning is via the admin console, by leveraging the bulk action feature (leftmost checkbox column, available in many data tables, then click on the blue gear on the bottom and choose the delete icon). 

Via REST, task removal (for any kind of task: propagation, synchronization, scheduled, notification) can be performed as 

GET /rest/task/delete/{taskId}

or

DELETE /cxf/tasks/{taskId} (1.1.X)
DELETE /rest/tasks/{taskId} (>= 1.2.X)

Consider anyway that task execution storage can be controlled by setting the trace level to NONE, FAILURES or SUMMARY instead of ALL (which is the default) on the corresponding Task or Notification.

I get the error "org.quartz.impl.StdSchedulerFactory - Couldn't generate instance Id! org.quartz.SchedulerException: Couldn't get host name!"

This is probably related to an incorrect networking configuration of the underlying system (host name not set). A simple workaround is to replace

<prop key="org.quartz.scheduler.instanceId">AUTO</prop>

with

<prop key="org.quartz.scheduler.instanceId">syncope</prop> <!-- or any other custom id -->

in core/src/main/resources/schedulingContext.xml.

How do I audit login success / failure?

Include the following information (<= 1.2.x)

[REST]:[AuthenticationController]:[]:[login]:[SUCCESS]
[REST]:[AuthenticationController]:[]:[login]:[FAILURE]

With Wildfly 10, I get the error "Unknown:ClassNotFoundException: com.sun.org.apache.xerces.internal.dom.DOMXSImplementationSourceImpl"

This issue is resolved by adding following entries to $JBOSS_HOME/modules/sun/jdk/main/modules.xml:

<path name="com/sun/org/apache/xerces/internal/dom"/>
<path name="com/sun/org/apache/xerces/internal/xni"/>
<path name="com/sun/org/apache/xerces/internal/jaxp"/>

Reference: https://stackoverflow.com/questions/15684993/class-from-rt-jar-not-found