By: Stephan Leuendorff named 01 Sep 2022 at 8:47 a.m. CDT

3 Responses
Stephan Leuendorff gravatar
Hi Support We Are experiencing an issue regarding the order of records being returned when communicating via SCIM . The sortOrder and sortBy works but doesn't go across all users in the DB leading to wrong results. Technical information Endpoint used (Users/.search) Additional parameters sortBY and sortOrder doesn't seem to factor in all available user, just sort within a fraction See Attached Screenshots Expected result The user with the familtyName 'Alamaza' should be listed in the 1st chunk (1st screenshot) Assuming sorting doesn't go across all users but within a provided chunk of data (startIndex & count) This seems to be an on 4.2.3 Is there a patch / fix for this already ? Cheers Stephan

By Jose Gonzalez staff 01 Sep 2022 at 9:10 a.m. CDT

Jose Gonzalez gravatar
Please provide the type of database you use

By Stephan Leuendorff named 01 Sep 2022 at 9:11 a.m. CDT

Stephan Leuendorff gravatar
Hi Jose Its LDAP

By Jose Gonzalez staff 02 Sep 2022 at 11:32 a.m. CDT

Jose Gonzalez gravatar
Hi, it turns out sorting in the case of LDAP is problematic: - According to our expert there is no ready-to-use solution to perform LDAP server side sort, however there exists something called "virtual list view" (VLV) control that in theory helps obtaining consistently sorted results across requests - OpenDJ supports VLV controls and they were tried in Gluu several years ago. In practice this led to big performance issues (server overload). It also required admins to prepare the search indexes beforehand. However in the case of SCIM, LDAP filters are dynamic and the sorting attribute is also variable so it's not a good match - The above led to retiring VLV usage in SCIM and we resorted to perform a lax sorting in the service implementation. Currently, a search with "sortBy" retrieves `count` elements using `startIndex` as offset, then the given page is sorted, not the whole result set. That is, we don't retrieve all user entries matching the criteria, sort them and retrieve the required slice. This is to avoid potential bottlenecks. The above explains why you don't observe an absolute sorting but a local one. Unlike other backends (SQL, couchbase, etc.), LDAP does not seem to be a good fit for dynamic sorting. We apologize these facts are not presented in SCIM documentation. As a way to workaround it I wonder if you could increase the value of `count` in your app so that all potential results come in a single request... or trying to minimize the number of results by requiring tighter filters. This is of course, as long as the perceived response time is not heavily impacted. Please account there is a `MAX_COUNT` parameter which can be set in oxTrust. This is in case you want to set `count` to high value. Actually when `count` is omitted, `MAX_COUNT` takes its place.