Afin que cette fonction soit totalement effective, elle va nécessiter une mise à niveau des applications métiers connectées à CapDémat pour qu'elles puissent impacter les fusions de compte réalisées dans le Back Office de CapDémat.
Ainsi, l'interface de service implémentée par les connecteurs métiers (IExternalProviderService) a été étendue et un schéma XML d'échange dédié a été défini (cf
http://capdemat.capwebct.fr/attachment/ticket/697/HomeFolderMerge.xsd). Si vous avez des retours à faire sur ce schéma, c'est le moment !
Plus concrètement, voici comment sont gérés les mappings des 2 comptes (celui d'origine et celui cible de la fusion) au cours d'une fusion :
* Aucun des deux comptes n’a de mapping
-> Rien à faire
* Le compte fusionné a un mapping mais le compte cible n’en a pas
-> Création d’un mapping pour le compte cible avec l’ancien externalCapDematId
-> Pour chacun des individus ayant un mapping, création d’un nouveau mapping avec l’ancien externalCapDematId
-> Conservation du mapping du compte archivé, pour historique
-> Normalement transparent pour les services externes s’ils travaillent bien sur l’UUID et pas sur l’id interne CapDémat (merci de confirmer / infirmer ce point)
* Le compte fusionné n’a pas de mapping mais le compte cible en a un
-> Rien à faire
* Les deux comptes ont un mapping
-> Conservation des deux mappings (y compris celui sur le compte archivé, pour historique)
-> Création d’un mapping avec l’ancien externalCapDematId pour les individus n’en ayant pas sur le compte cible (les déplacés + sous ensemble des fusionnés)
-> Transmission aux services externes des modifications (ancien externalCapDematId / nouveau externalCapDematId pour le compte d'origine et tous ses individus)
* La confirmation / infirmation d'utilisation systématique des externalCapDematId par les applications métiers