Sorting and paging

You can sort collection resources by using the ‘oslc.orderBy’ query parameter in the following format:

The attributes that are prefixed with the minus sign (-) are sorted in descending order and the attributes with the plus (+) sign are sorted in ascending order. All attributes that are listed must be prefixed with a + or - sign. There is no default sort order. Additionally, only persistent attributes from the main object are supported. Related attributes are not supported.

The + sign needs to be URL encoded. This is a common mistake made by developers when trying this one out.

You can apply paging data by using the oslc.pageSize query parameter. The parameter value specifies the maximum number of records to fetch for a page. A sample URI shown earlier describes how to achieve paging.

As discussed before, this causes the responseInfo object to have the nextPage, previousPage, pagenum, totalCount (optional) and totalPages (optional) properties to describe page navigation information.

Auto-initiated paging is primarily needed if requesting a large data set, which can cause resource starvation or OOM errors in the Maximo server. To prevent these issues, you can set the auto-paging threshold in the Object Structure application. For example, if auto-paging is set to 1000 for the MXAPIASSET object structure, and you request GET /oslc/os/mxapiasset and not define the oslc.pageSize, the system starts paging the request if the asset count exceeds the 1000 limit.

It is also possible that while querying a client set the page size to be too high, which can also cause an OOM error. To handle this scenario, you can set a positive value for the page size to the mxe.oslc.maxpagesize property. This applies to all Maximo object structures. You can also set the property to a specific object structure by setting the mxe.oslc.<os name in lower case>.maxpagesize property. This value change overrides the global value set by the mxe.oslc.maxpagesize property. If the request page size exceeds this value, an error occurs and the request fails.

Stable paging is a variation of the basic paging. In stable paging the MboSet in memory is loaded (note the MboSet contains 0 MBOs at this point as the MBOs are loaded on demand), and a reference to the MboSet is retained throughout the paging process. As the paging for the MboSet is processed, the MBOs are discarded. Effectively, at any given point in the paging, only one MBO is live. Note, the basic paging also discards the MBOs as they are serialized and there would never be more than one MBO in memory for the life of the paging. However, in basic paging the MboSet is loaded for every page request, that is the SQL query is applied every time. With stable paging, the MboSet reference is retained and does not need to process the SQL for every page but the pages expire as they are delivered because the MBOs are discarded and the MboSet is never refreshed. The following API example initiates stable paging:

This API creates a stable ID, which is embedded as part of the nextPage URI (stableId=<some id>). The URI is used to page forward. The same page cannot be reloaded because the page expires. Also, there is no backward paging because the pages including the current page also expire.

The stored MboSet expires if the set is not accessed after five minutes or if the set is paged to the end. You can changed the idle expiry time of five minutes by updating the mxe.oslc.idleexiry value, which is measured in seconds.