Réplication pour LDAP

Le fichier ldapentry.xml permet de configurer les attributs qui doivent être synchronisés entre le serveur LDAP et la base de données HCL Commerce. Certains attributs couramment utilisés sont définis par défaut. La synchronisation réelle est effectuée lorsque des beans de synchronisation sont utilisés : UserSyncBean pour les données de profil utilisateur et OrganizationSyncBean pour les données d'organisation.

Ces beans de synchronisation sont utilisés en plusieurs endroits dans le code HCL Commerce, mais les instances les plus importantes figurent dans les scénarios suivants :

La commande d'ouverture de session : si l'utilisateur existe dans le serveur LDAP uniquement, après une authentification réussie, l'utilisateur est créé dans la base de données HCL Commerce. Si l'utilisateur existe dans la base de données HCL Commerce seule, l'utilisateur est créé dans le serveur LDAP. Si l'utilisateur existe déjà aux deux emplacements, le profil utilisateur HCL Commerce dans la base de données est mis à jour par le profil LDAP. Cette mise à jour se produit si la base de données est modifiée après la dernière synchronisation.
Une instruction d'enregistrement (telle que UserRegistrationAdd, UserRegistrationUpdate, OrgEntityAdd et OrgEntityUpdate) est utilisée.
Le bean de données UserRegistrationDataBean ou OrgEntityDataBean est utilisé.
Un jeton LTPA de connexion unique est lu.

Limitation de la synchronisation des organisations

Dans certains cas, vous ne souhaiterez peut-être pas que OrganizationSyncBean mette à jour le serveur LDAP chaque fois qu'une organisation est créée ou mette à jour HCL Commerce. Cette exclusion peut être spécifié dans le fichier ldapentry.xml à l'aide des options de flux "ldapToWcs" ou "ldapOnly".

Toutefois, si vous souhaitez qu'un sous-ensemble des organisations de HCL Commerce soit synchronisé avec votre serveur LDAP, vous ne pouvez pas utiliser les options de flux précédentes. Deux autres options sont possibles :

Si une organisation qui est un ancêtre d'utilisateurs doit exister uniquement dans la base de données HCL Commerce, vous devez l'ajouter à l'élément SyncOrganizationExclusionList dans le fichier de configuration d'instance. Par exemple :
Remarque : SyncOrganizationExclusionList n'est pas hiérarchique. Vous devez indiquer de manière explicite les sous-organisations que vous souhaitez exclure.
```
<SyncOrganizationExclusionList display="false">
     <Org DN="o=my organization,o=root organization"/>
     <Org DN="o=seller organization,o=my organization,o=root organization"/>
</SyncOrganizationExclusionList> 
```
Une organisation de type Domaine d'autorisation (AD) existe uniquement dans HCL Commerce. Cette organisation est définie dans la colonne ORGENTITYTYPE de la table ORGENTITY. Cette organisation n'est pas répliquée sur LDAP. Le domaine d'autorisation est prévu pour ne détenir que des ressources non membres, comme un magasin. Le domaine d'autorisation ne doit pas comporter d'utilisateurs ni de sous-organisations de type OU ou O. Pour spécifier qu'une organisation doit être de type "AD", vous devez étendre les instructions OrgEntityAdd et OrgEntityUpdate, ou utiliser l'utilitaire de chargement de données, l'utilitaire massload ou SQL.

Accès aux attributs qui existent uniquement dans LDAP

HCL Commerce peut accéder aux attributs qui existent uniquement dans LDAP. Dans le fichier ldapentry.xml, map -ldapAttribute - flow indique comment la lecture et l'écriture de la valeur d'attribut s'effectue sur LDAP :

ldapOnly

La valeur n'existe que sur LDAP, et non sur la base de données HCL Commerce. Ces attributs seront accessibles à partir des API suivantes :

UserSyncBean.getProperty(String propertyName)
OrganizationSyncBean.getProperty(String propertyName)

Cela les rend accessibles aux beans de données suivants :

UserRegistrationDataBean.getAttribute(String attributeName)
OrgEntityDataBean.getAttribute(String attributeName)

A leur tour, les services GetPerson et GetOrganization remplissent les objets SDO Person et Organization à l'aide des attributs suivants lors de l'utilisation du profil d'accès IBM_All :

/Person/Attributes
/Organization/Attributes

Synchronisation des attributs LDAP à valeurs multiples avec la table MBRATTRVAL

La table MBRATTRVAL est utilisée pour le stockage des attributs de membre personnalisés. Elle peut stocker plusieurs valeurs (lignes) pour un attribut et un utilisateur uniques. LDAP peut traiter les attributs à valeurs multiples.

Par exemple :


<map>
     <objectAttribute attrName="JobFunction_10001_r_n"/>
     <ldapAttribute name="telephoneNumber" operation="replace" flow="bothDirections"/>
</map>

Mappage d'origine :


<!--
<map>
     <objectAttribute attrName="phone1"/>
     <ldapAttribute name="telephoneNumber" operation="add" flow="bothDirections"/>
</map>
-->

L'attribut VMM telephoneNumber mappe vers l'attribut JobFunction_10001_r_n HCL Commerce. Cet attribut HCL Commerce, fondé sur la convention de dénomination, est un attribut de membre personnalisé dont les valeurs sont stockées dans la table MBRATTRVAL. Il est à noter que le nom d'attribut de membre se termine par _n pour indiquer qu'il comporte plusieurs valeurs.

Si la table MBRATTRVAL contient plusieurs valeurs, celles-ci sont synchronisées avec plusieurs valeurs dans LDAP. A l'inverse, si LDAP contient plusieurs valeurs, celles-ci sont synchronisées avec plusieurs lignes dans la table MBRATTRVAL.

L'URL suivante est un exemple indiquant comment ajouter ou mettre à jour deux valeurs JobFunction pour l'utilisateur en cours :

https://localhost/webapp/wcs/stores/servlet/UserRegistrationUpdate?storeId=10101&catalogId=10101&langId=-1
&editRegistration=Y&JobFunction_10101_r_1=manager&JobFunction_10101_r_2=clerk&URL=UserRegistrationForm

Notez les deux occurrences des mises à jour JobFunction dans la chaîne URL. Le premier étant JobFunction_10101_r_1 pour le gestionnaire et le second étant JobFunction_10101_r_2 pour le vendeur.