Duplicación para LDAP

El archivo ldapentry.xml se utiliza para configurar qué atributos se sincronizan entre el servidor LDAP y la base de datos de HCL Commerce. Algunos atributos se especifican habitualmente de forma predeterminada. La sincronización real se efectúa siempre que se utilicen los beans de sincronización: UserSyncBean para datos de perfil de usuario y OrganizationSyncBean para datos de organización.

Estos beans de sincronización se utilizan en varios lugares en el código de HCL Commerce, pero las instancias más importantes están en los escenarios siguientes:

El mandato de inicio de sesión: Si el usuario existe solamente en el servidor LDAP, después de una autenticación satisfactoria, el usuario se crea en la base de datos de HCL Commerce. Si el usuario existe solamente en la base de datos de HCL Commerce, el usuario se crea en el servidor LDAP. Si el usuario ya existe en ambos sitios, el perfil de usuario de HCL Commerce de la base de datos se actualiza mediante el perfil de LDAP. Esta actualización se produce si la base de datos se cambia después de la última sincronización.
Se utiliza un mandato de registro (por ejemplo UserRegistrationAdd, UserRegistrationUpdate, OrgEntityAdd y OrgEntityUpdate).
Se utiliza el bean de datos UserRegistrationDataBean o OrgEntityDataBean.
Se lee una señal LTPA de inicio de sesión único.

Limitación de la sincronización de organizaciones

En algunos casos, es posible que no desee que OrganizationSyncBean actualice el servidor LDAP siempre que se crea una organización o actualice HCL Commerce. Esta exclusión se puede especificar en el archivo ldapentry.xml utilizando las opciones de flujo "ldapToWcs" o "ldapOnly".

No obstante, si desea que se sincronice un subconjunto de las organizaciones en HCL Commerce con el servidor LDAP, no puede utilizar las opciones de flujo anteriores. En lugar de ello, tiene dos opciones más:

Si una organización que es predecesora de usuarios sólo debe existir en la base de datos de HCL Commerce, debe añadirla al elemento SyncOrganizationExclusionList en el archivo de configuración de instancia. Por ejemplo:
Nota: La SyncOrganizationExclusionList no es jerárquica. Debe especificar de forma explícita todas las suborganizaciones que desea excluir.
```
<SyncOrganizationExclusionList display="false">
     <Org DN="o=my organization,o=root organization"/>
     <Org DN="o=seller organization,o=my organization,o=root organization"/>
</SyncOrganizationExclusionList> 
```
Una organización de tipo dominio de autorización, AD, sólo existe en HCL Commerce. Esta organización se define en la columna ORGENTITYTYPE de la tabla ORGENTITY. Esta organización no se replica en LDAP. El dominio de autorización está destinado a ser propietario de elementos que no sean miembros como, por ejemplo, una tienda. El dominio de autorización no debe tener ningún usuario o suborganizaciones de tipo OU u O. Para especificar que una organización sea de tipo "AD", necesitará ampliar los mandatos OrgEntityAdd y OrgEntityUpdate o utilizar el programa de utilidad de carga de datos, el programa de utilidad massload o SQL.

Acceso a atributos que sólo existen en LDAP

HCL Commerce puede acceder a atributos que solamente existen en LDAP. En el archivo ldapentry.xml, map -ldapAttribute - flow especifica cómo se lee el valor de atributo de LDAP y se escribe en LDAP:

ldapOnly

El valor sólo existe en LDAP, no en la base de datos de HCL Commerce. Estos atributos serán accesibles desde las API siguientes:

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

Esto a su vez estará a disposición de los beans de datos siguiente:

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

A su vez, los servicios GetPerson y GetOrganization llenarán los SDO de Person y Organization con estos atributos cuando utilicen el perfil de acceso IBM_All:

/Person/Attributes
/Organization/Attributes

La sincronización de atributos LDAP de varios valores en la tabla MBRATTRVAL

La tabla MBRATTRVAL se utiliza para almacenar atributos de miembros personalizados. La tabla puede almacenar varios valores (filas) para un único atributo y usuario. LDAP puede gestionar atributos de varios valores.

Por ejemplo:


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

Correlación original:


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

El atributo VMM telephoneNumber se correlaciona con el atributo JobFunction_10001_r_n HCL Commerce. Este atributo de HCL Commerce, basado en el convenio de denominación, es un atributo de miembro personalizado, cuyos valores se almacenan en la tabla MBRATTRVAL. Tenga en cuenta que el nombre de atributo de miembro finaliza en _n para indicar que tiene varios valores.

Si existen varios valores en la tabla MBRATTRVAL, se sincronizan a través de varios valores en LDAP. A la inversa, si existen varios valores en LDAP, se sincronizan con varias filas en la tabla MBRATTRVAL.

El URL siguiente es un ejemplo de cómo añadir o actualizar dos valores JobFunction para el usuario actual:

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

Observe que hay dos instancias de actualizaciones de JobFunction en la serie del URL. La primera es JobFunction_10101_r_1 para el gestor y la segunda es JobFunction_10101_r_2 para el asistente.