References
CPS-1963 - Getting issue details... STATUS
https://ldap.com/ldap-dns-and-rdns/
Issues & Decisions
| Issue | Notes | Decision | |
|---|---|---|---|
| 1 | Is FDN optional? | Is it possible to register a cmHandle without an FDN? | Toine Siebelink Yes it is optional as not everyone will use it |
| 2 | In Hazelcast what is the key? | Is it the FDN or the cmHandleId? | Toine Siebelink create 2 maps:
|
Alternate identifiers during registration
The first use case which should be handled is the storing of the new identifier ( called FDN or Fully Distinguished Name).
A fully distinguished name uniquely identifies an entry and describes its position.
To achieve this NCMP's CmHandle registration endpoint must be changed to accept a new String parameter which proposed name is alternateId.
Extending RestInputCmHandle object
During registration an object called RestInputCmHandle contains all the information to register new entities in the database.
The object should be extended at the top level with the new property:
RestInputCmHandle | |
|---|---|
| Field name | Type |
| cmHandle | String |
cmHandleProperties | Object |
| publicCmHandleProperties | Object |
| moduleSetTag | String |
| trustLevel | String |
| alternateId | String |
Save the cmHandleId and the alternateId cache
During registration the new identifier must be saved to a cache. Because it could be reused later for queries.
The new cache must implement two maps (Map<String, String>).
The first map should be structured in a way where the original CM Handle ID is the key and the alternate ID is the value.
The second map should be the other way around.
Like this we will be able to map entities back and forth during queries quickly based on what value we have in the queries.