You might have faced problem using Maximo APIs where Maximo is returning a huge amount of data as API call response which in turn impacting client performance because the client has to wait until a response is completely received. The solution of such problems is technique k/a Pagination or Paging supported by Maximo API(s).
In Pagination, we provide parameters in API Query String to fetch the only a limited amount of data into response while the whole mbo set will be either saved in memory or will be fetched again on request from database.
From Maximo 126.96.36.199 onwards there are 2 kinds of API available-
- Maximo REST API
- Maximo OSLC API (also k/a Next Gen REST API)
Below table explains the difference between both API(s) on the basis of Paging-
And here is the difference between Stable Paging and Normal Paging available in OSLC API of Maximo-
Stable Paging: In query parameters, we need to pass stablePaging=true for stable paging.
API fetches the data for the whole mbo set into memory in once and provide data to the client as per page size rather than making a round trip to the database for each call. But this paging has some cons as well. Once the page is loaded it is destroyed and you can’t reload the same page again which means in the mobile client if you have gone to the next page, you can’t go back to the previous page and you can always go forward. This also makes you sticky to server i.e if you are connected to one app server JVM and if JVM is down, you can’t switch it to another JVM without destroying data into memory.
Normal Paging: By Default, if you are not passing stable paging parameter API uses Normal Paging. In case of normal paging, every time in case of forwarding or backward page movement API’s request goes to DB but you can go backward and forward movement unlike only forward movement in the stable paging. In case of proper clustering if one app server JVM is down you can still get data from another JVM making your connection non-sticky to JVM.