Multiple offline OData stores limitations

[former_member605460]

Hi,

We are developing an application using SCPMS and SCP Cloud SDK 2.0, we have both online and offline scenarios that we need to accomplish.

For the offline scenario based on how the OData services are developed, we are looking at around 9 endpoints that needs to configured in SCPMS translating to 9 offline stores UDBs.

What I want to understand that are there any limitations related to performance, access (other than 4 stores opened at a time) that we should consider.

Any inputs on that would be helpful.

Regards,

Amit

[david_brandow · Accepted solution]

In terms of strict limitations, you've named the most important one (at most 4 stores opened at any given time). There are some other strict limitations (http://dcx.sap.com/sa160/en/uladmin/fo-intro-s-5236376.html), but you are very unlikely to run into any of them. That being said, performance is nevertheless an extremely important consideration to take into account in any application that uses non-trivial amounts of data and in any mobile application.

We can split performance issues into three high-level areas: the backend, the client, and everything in between, which includes the middle tier (SAP Cloud Platform for cloud, SAP Mobile Platform server for on-premise), all the various network layers, load balancers, etc.

The first place to start is to analyze is how long it is going to take the backend to respond to the requests it is being sent. The best way to find this is to isolate a time when the only requests going to the backend will be yours, then run your performance test(s) with network tracing enabled and examine the network traces. You are looking for requests which individually take a long time to be processed and also looking for the cumulative impact of all of the requests.

Mitigating performance issues on the backend typically falls into two categories: optimizing the performance of the requests and reducing the request count and payload demands. Making your backend run better is going to be entirely implementation-specific, so it's difficult to give any specific recommendations there. Reducing the number of requests being issued can be done by designing your application to issue requests less often, by striping when those requests are being uploaded by to the backend, and by merging requests, either in the backend or on the client. Client request merging can be done by the application itself or by new features introduced by the Offline OData client, where/when available. Reducing the payload demand of those requests is typically the most straightforward approach to improving backend performance, however. You need to be very strategic about the amount of data pulled down to the client, only the data that that user needs should be pulled down, nothing more. Similarly, if the initial download has already occurred and you have a non-trivial payload, you *really* want only the changes to come down from that point onward, not the entire data set, so you should determine if delta support has been implemented in your backend (or, failing that, configure Offline OData to do it for you) and if it is functioning properly.

To touch briefly on the 'everything in between' category briefly, the biggest factor, again, is the amount of data. If you are pulling down 1Gb worth of data, it's going to take about an hour to get that downloaded to your phone, whether you are downloading a file or an Offline OData client store. The smaller the payload, the quicker that download can be.

Once the data is on the mobile device, the question becomes how quickly can the Offline OData client get that data into your application. The first recommendation here is to make sure you have appropriate client-side indexes setup. The definition for which indexes will be used is, perhaps counter-intuitively, specified in the middle tier's administration cockpit. It is important to note that by default no client-side indexes are created, not even for primary keys, so you'll almost certainly want to create indexes of some kind. As with any database, determine which columns to create indexes on should be thought through carefully, ideally with testing to back up the decisions being made. The second recommendation, much like we've seen with the backend and the network, involves limiting the size of the payload. Modern mobile devices are very powerful, but users' demands for responsiveness are equally demanding, so only pull the data you need into memory, not data you might need at some point in the future. If you are showing 10 rows, retrieve just those 10 rows (or perhaps 30 rows, to give yourself a scrolling buffer), not all the rows. As an overly-general rule of thumb, if you are pulling more than 50 rows into memory at once, you are probably doing something wrong.

[former_member605460 · Accepted solution]

Thanks David for the detailed answer.