Récemment, j'ai été impliqué dans plusieurs projets de clients qui impliquent la distribution et la synchronisation de comptes d'utilisateurs entre plusieurs organisations. Ce scénario est un peu différent du scénario de synchronisation standard, qui suppose qu'il n'y a qu'une seule organisation et que les données proviennent d'une source faisant autorité, telle qu'un magasin de données RH. La figure 1 donne un exemple de cette synchronisation de base ; supposons que notre organisation compte trois domaines et que le domaine A fait autorité.
Dans ce scénario de base, la priorité des attributs n'entre pas en ligne de compte, car il n'existe qu'un seul flux d'importation pour tous les attributs de l'objet "personne" (voir figure 2).
Il est évident que les choses sont rarement aussi simples, même dans un environnement de base. En général, vous avez au moins quelques attributs dont les flux d'importation proviennent de plusieurs sources. Un exemple simple est celui de displayName. "William" est peut-être son nom officiel, mais tout le monde le connaît sous le nom de "Bill", et personne ne peut le trouver dans le carnet d'adresses. Le flux RH peut donc alimenter cet attribut dans un premier temps, mais par la suite, votre domaine AD mettra à jour l'attribut displayName en fonction des préférences de l'utilisateur.
Dans l'exemple de la figure 3 ci-dessus, vous pouvez faire en sorte que le domaine A fasse autorité pour l'attribut displayName lors du chargement initial (ou de la mise à disposition), puis faire en sorte que le domaine B fasse autorité pour cet attribut par la suite en déplaçant l ' AM de B au-dessus de A dans la configuration de la priorité de flux pour cet attribut (voir la figure 4).
Ce type de priorité d'attribut est facile à configurer tant que les attributs de l'utilisateur circulent dans une seule direction.
Avant d'aller plus loin, je pense qu'il est important de rappeler quand la priorité des attributs est déterminée dans la synchronisation FIM :
La priorité est déterminée sur le flux entrant dans le métavers FIM
Il est important de se rappeler que la priorité des attributs n'est pas déterminée lors de l'exportation depuis le Metaverse, mais lors de l'importation dans le Metaverse. Il est essentiel de comprendre cela !
Qu'en est-il de la priorité des attributs lorsque vous avez des objets utilisateur qui doivent être alimentés par la synchronisation ?
Dans la figure 5 ci-dessus, chaque domaine possède son propre ensemble d'objets utilisateur uniques qui doivent être synchronisés avec les autres domaines.
L'utilisation d'une simple préséance d'attribut ne fonctionnera plus ; chaque domaine fait autorité pour les attributs de son utilisateur. Par exemple, si vous avez configuré la priorité d'attribut simple A, B, C, un objet personne Metaverse provenant du domaine A fonctionnera parfaitement : l'objet personne sera mis à jour par le domaine A (parce qu'il est prioritaire) lors de l'importation - et ces attributs seront exportés vers les domaines B et C (voir Figure 6).
Mais que se passe-t-il lorsque vous souhaitez synchroniser un objet utilisateur unique du domaine B avec le domaine A ? Une fois l'objet connecté aux deux domaines, le domaine A devient prioritaire pour les attributs. Remarquez ci-dessous, dans la figure 7, que même si l'utilisateur provient du domaine B, le domaine A fait désormais autorité pour l'attribut displayName en raison de sa position dans la configuration de la précédence de la figure 6.
Il existe deux approches différentes pour traiter ce problème :
Flux avancés pour toutes les importations d'attributs
Une approche consiste à écrire un code d'extension pour chaque flux d'importation dans le Metaverse FIM.
L'avantage est que vous ne devez traiter qu'un seul objet (personne) dans vos flux d'exportation vers chaque AMM connectée. Cela peut être pratique si vous avez 20 ou 30 autres AM (j'ai eu récemment un client qui en avait plus de 60).
L'inconvénient est que vous devez désormais gérer des flux avancés (et le codage d'extension obligatoire) pour chaque flux d'importation. Si vous souhaitez ajouter ou modifier un flux à l'avenir, vous devrez modifier le code d'extension pour chaque MA source concerné. Il est donc difficile de confier cette tâche à votre équipe de maintenance.
Un objet Metaverse pour chaque MA
Une autre approche consiste à créer un objet "personne" pour chaque AM.
L'avantage est qu'il n'y a qu'une seule importation dans chaque objet (le domaine source) ; la priorité des attributs n'est donc pas un problème.
L'inconvénient est que vous devez maintenant définir chaque objet dans vos flux d'exportation. Là encore, il s'agit d'un véritable problème si vous avez affaire à un grand nombre d'AMM connectées (voir la figure 11).
De même, si vous souhaitez ajouter un attribut aux flux de synchronisation (disons que vous souhaitez désormais faire circuler ipPhone depuis/vers tous les domaines), vous devrez potentiellement modifier les éléments de configuration [nombre d'AMM]2.
...
Chacune de ces solutions est viable et présente des avantages et des inconvénients. Mais il existe une autre solution, un peu hybride, qui permet d'éviter à la fois le codage d'extension pour les importations directes et la nécessité de définir un objet pour chaque MA.
Si chaque source a des objets uniques qui doivent être synchronisés avec toutes les autres AMM, l'une des options ci-dessus est la seule façon de procéder. Mais si vous avez un scénario dans lequel la majorité des sources ne doivent être synchronisées qu'avec un sous-ensemble d'autres AM (ce qui est typique lors d'acquisitions et de fusions, ainsi que dans les relations avec les sociétés de tutelle), alors l'approche suivante peut vous faire gagner du temps.
Un objet Metaverse pour les AM qui ont des exportations multiples
Dans cet exemple, disons que l'entreprise "C" a acquis les entreprises "A" et "B". Dans ce cas, tous les utilisateurs doivent être rattachés au domaine C pour l'accès au courrier électronique et aux applications, et les utilisateurs du domaine C doivent avoir accès aux applications des domaines A et B (figure 12, ci-dessous).
En regardant le diagramme de la figure 12, vous créeriez un objet Metaverse "personne" pour chaque AM qui a plusieurs flèches entrantes ; donc dans ce cas, le domaine C (voir figure 13).
L'avantage est que vous pourrez.. :
- Évitez le codage d'extension pour les flux directs (rappelez-vous que même si l'objet personne a des flux d'importation en provenance de A et B, ils ne seront jamais connectés l'un à l'autre, de sorte que l'ordre de préséance n'est pas un problème).
- Il suffit de définir les flux d'exportation pour l'objet personne et les quelques AM pour lesquelles vous devez créer un objet personne Metaverse unique (dans ce cas, le domaine C).
- Réduire la complexité des changements futurs.
Comme vous pouvez le constater, si vous voulez maintenant faire circuler l'attribut ipPhone dans ce scénario, au lieu de modifier le carré des AMM concernées, il vous suffira de modifier les éléments de configuration [nombre d'objets personnes] x [nombre d'AMM] (6 éléments au lieu de 9).
Encore une fois, ce n'est probablement pas un gros problème si vous avez affaire à trois ou quatre AMM - mais si vous êtes dans une situation où vous avez affaire à plus de quelques AMM, alors cette technique pourrait vous faire gagner du temps ; si vous avez 14 AMM et que vous ajoutez un attribut à votre champ d'application, faire 28 changements est certainement mieux que d'en faire 196.
(142 = 196 , mais 14×2 ne font que 28 !)
