... | ... | @@ -6,14 +6,31 @@ Le but est de synchroniser les utilisateurs et leurs informations de FD vers Zim |
|
|
|
|
|
La source déclarée dans LSC peut être soit FD via son API REST, soit directement le LDAP.
|
|
|
|
|
|
La destination sera probablement l’API REST de Zimbra: https://wiki.zimbra.com/wiki/Zimbra_REST_API_Reference
|
|
|
La destination sera soit l’API REST de Zimbra: https://wiki.zimbra.com/wiki/Zimbra_REST_API_Reference
|
|
|
Soit L’API SOAP: https://files.zimbra.com/docs/soap_api/8.6.0/api-reference/index.html
|
|
|
Soit le serveur LDAP de Zimbra directement
|
|
|
|
|
|
Ce message semble conseiller de mettre le serveur LDAP de zimbra en destination: https://lists.lsc-project.org/pipermail/lsc-users/2013-May/001473.html
|
|
|
|
|
|
## Déclenchement de la synchronisation
|
|
|
|
|
|
Le déclenchement peut se faire des manières suivantes:
|
|
|
* par hook
|
|
|
* synchrone
|
|
|
* asynchrone
|
|
|
* par surveillance LDAP
|
|
|
* par code spécifique
|
|
|
|
|
|
## Le retour d'erreur
|
|
|
|
|
|
Dans le cas d’un appel synchrone par un hook, il est possible de retourner l’erreur directement à l’utilisateur qui a fait la modification.
|
|
|
|
|
|
Dans les autres cas on peut imaginer stocker l’historique des synchronisations et leurs éventuelles erreurs dans le LDAP.
|
|
|
|
|
|
LSC stock les erreurs dans un log, et propose des commandes pour lister les erreurs rencontrées.
|
|
|
|
|
|
Il semble possible de spécifier à logback une classe Java qui implémente l’interface Appender et qui stock les informations dans le LDAP: https://logback.qos.ch/manual/appenders.html
|
|
|
|
|
|
## Ce qui doit être développé pour ce cas précis
|
|
|
|
|
|
Si on passe par le webservice FD pour la source, il faudra développer soit un plugin LSC pour ça, soit utiliser le plugin external et développer des scripts pour ça.
|
... | ... | |