Introduction

Almost every configurable aspect of a running Apache Syncope instance is contained into the internal storage: attribute schemas, connectors, resources, mapping, roles, synchronization tasks and other parameters.

During implementation of an Apache Syncope-based project, it might be handful to move such configuration back and forth from one Apache Syncope instance to another (say developer's laptop and production server).

An option is clearly acting at low level by empowering DBMS' dump & restore capabilities, but what if poor developer is running MySQL (or even in-memory H2) while sysadmin features Oracle?

Export

Click on the Configuration icon at top, then to the rightmost icon on the tab row: you will be prompted for downloading a file named content.xml.

You can also get this file via CLI.

Import

Basically, all you need to do is replace local content.xml with the one exported as explained above; but where is this content.xml located at?

• core/src/test/resources/content.xml for embedded mode
• core/src/main/resources/content.xml for real environments
• webapps/syncope/WEB-INF/classes/content.xml from the Apache Tomcat directory, for standalone distribution

Gotchas

Wipe existing content

When not running in-memory H2, internal storage's content must be wiped before starting Apache Syncope, otherwise content.xml will be just ignored.

Check core-persistence.log for message

Empty database found, loading default content

If the internal storage is not empty, instead, you will get

Data found in the database, leaving untouched

MySQL and lower case table names

On some platforms (namely, Mac OS X) MySQL is configured by default to be case insensitive: in such cases, you might want to edit /etc/my.cnf file and add the following line into [mysqld]:

lower_case_table_names=1

OpenJPA sequences

In exported content.xml you might find some elements like as

<OPENJPA_SEQUENCES_TABLE ID="SEQ_ConnInstance" SEQUENCE_VALUE="1100"/>

Since most tables in the internal storage feature OpenJPA's sequence id generation, this means that new rows in the ConnInstance table will get ids from 1100 upwards.