HCL Domino Ideas Portal
Welcome to the #dominoforever Product Ideas Forum! The place where you can submit product ideas and enhancement request. We encourage you to participate by voting on, commenting on, and creating new ideas. All new ideas will be evaluated by HCL Product Management & Engineering teams, and the next steps will be communicated. While not all submitted ideas will be executed upon, community feedback will play a key role in influencing which ideas are and when they will be implemented.
For more information and upcoming events around #dominoforever, please visit our Destination Domino Page
Thanks Thomas for your additrional contribution but, as specified in previous comments, the intent of this request/idea is to make additional calls to the LDAP leveraging existing DA pooling in an environmente where customer(s) do not wanto to replicate/import external data into Domino Directory in any way.
On the other hand these accesses are currently executed by LotusScript agents which are much less efficent than core C/C++ code requiring the set up new socket and LDAP bind operation for each call and hence impacting the server the scalaility.
Furthermore attributes to be retrieved could be passed as list/array so the number of calls could be lowered to one.
Hope this clarifies.
Thanks a lot.
For each attribute, and for each time this @function is called, the server would have to reach out to the remote LDAP. That will be causing a significant impact to performance and scalabilty of Domino. Since there already is an LDAP connection, syncronization of the data into the Domino directory is what you need to do.
Customers often do not allow external LDAP entries to be imported into domino.
Furthermore this is against the principal of Directories Federation for which DA has been used.
Why not set up DirSync and create a person document automatically?
When using @Namelookup especially in a Directory Assistance context federating external LDAP servers (e.g. using [Exhaustive] lookup-type) the third parameter (itemtoreturn)
should be able to return an arbitrary array of attributes.
@NameLookup( [ lookupType ] ; username; itemtoreturn )
In the syntax above, the "itemtoreturn" should include additional attributes like "departmentNumber":"employeeNumber":"telephoneNumber" and so on.
This will allow to leverage the Directory Assistance internal pooling mechanism without requiring to make additional LDAP calls at application level increasing execution speed and I/O.