Replication for LDAP

The ldapentry.xml file is used to configure which attributes are synchronized between the LDAP server and the WebSphere Commerce database. Some commonly used attributes are specified by default. The actual synchronization is done whenever the synchronization beans are used: UserSyncBean for user profile data, and OrganizationSyncBean for organization data.

These synchronization beans are used in several places throughout the WebSphere Commerce code, but the most important instances are in the following scenarios:

The Logon command: If the user exists in the LDAP server alone, after a successful authentication, the user is created in the WebSphere Commerce database. If the user exists in WebSphere Commerce database alone, the user is created in the LDAP server. If the user exists in both places already, the WebSphere Commerce user profile in the database is updated by the LDAP profile. This update occurs if the database is changed after the last synchronization.
A registration command (such as UserRegistrationAdd, UserRegistrationUpdate, OrgEntityAdd, and OrgEntityUpdate) is used.
The UserRegistrationDataBean or OrgEntityDataBean data bean is used.
A single sign-on LTPA token is read.

Limiting synchronization of organizations

In some cases, you might not want the OrganizationSyncBean to update the LDAP server whenever an organization is created or update WebSphere Commerce. This exclusion can be specified in the ldapentry.xml file by using the "ldapToWcs" or "ldapOnly" flow options.

However, if you want a subset of the organizations in WebSphere Commerce to be synchronized to your LDAP server, you cannot use the preceding flow options. Instead, you have two other options:

If an organization that is an ancestor of users must exist only in the WebSphere Commerce database, you must add it to the SyncOrganizationExclusionList element in the instance configuration file. For example:
Note: The SyncOrganizationExclusionList is not hierarchical. You must explicitly specify any suborganizations that you want to be excluded.
```
<SyncOrganizationExclusionList display="false">
     <Org DN="o=my organization,o=root organization"/>
     <Org DN="o=seller organization,o=my organization,o=root organization"/>
</SyncOrganizationExclusionList> 
```
An organization of type authorization domain, AD, exists only in WebSphere Commerce. This organization is defined in the ORGENTITYTYPE column of the ORGENTITY table. This organization is not replicated to LDAP. The authorization domain is intended to own non-member assets such as a store. The authorization domain might not have any users or suborganizations of type OU or O. To specify an organization to be of type "AD", you would need to either extend the OrgEntityAdd and OrgEntityUpdate commands, use the Data Load utility, massload utility, or SQL.
The massload utility is deprecated for WebSphere Commerce Version 7 Feature Pack 6. The Data Load utility is the recommended command-line loading utility. If you are currently using the mass load utility, you are recommended to switch to the Data Load utility to load your CSV and XML input files into your target database. If your system contains scheduled and automated processes that use massload, it is recommended that you update these processes to use the Data Load utility. Other WebSphere Commerce utilities that use the massload utility, such as the acpload utility, continue to use the massload utility in WebSphere Commerce Version 7 Feature Pack 6. If you have business reasons to continue using the massload utility, you can continue to use this utility. For more information about the Data Load utility, see Overview of the Data Load utility. You can switch to the Data Load utility by using the TableObjectMediator to load your data when no business object mediator exists for the data that you are loading. For more about the TableObjectMediator formation, see Data Load utility table-based mediator and builder.

Accessing attributes that exist only in LDAP

WebSphere Commerce can access attributes that exist only in LDAP. In the ldapentry.xml file,

map
-ldapAttribute - flow

specifies how the attribute value is read from and written to LDAP:

ldapOnly

The value exists only on LDAP, not the WebSphere Commerce database. These attributes will be accessible from the following APIs:

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

That will in turn make it available to the following data beans:

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

In turn, the GetPerson and GetOrganization services will populate the Person and Organization SDOs with these attributes when using the IBM_All access profile:

/Person/Attributes
/Organization/Attributes

Synchronization of multi-valued LDAP attributes to the MBRATTRVAL table

The MBRATTRVAL table is used for storing custom member attributes. The table can store multiple values (rows) for a single attribute and user. LDAP can handle multivalued attributes.

For example:


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

Original mapping:


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

The telephoneNumber VMM attribute maps to the JobFunction_10001_r_n WebSphere Commerce attribute. This WebSphere Commerce attribute, based on the naming convention, is a custom member attribute, whose values are stored in the MBRATTRVAL table. Note that the member attribute name ends with _n to indicate that it is multivalued.

If there are multiple values in the MBRATTRVAL table, they are synchronized over to multiple values in LDAP. Conversely, if there are multiple values in LDAP, they are synchronized to multiple rows in the MBRATTRVAL table.

The following URL is an example of how to add or update two JobFunction values for the current user:

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

Note the two occurrences of JobFunction updates in the URL string. The first being JobFunction_10101_r_1 for manager and the second being JobFunction_10101_r_2 for clerk.