SUP Caching by Example

SUP Caching by Example
Wim Verhelst January 2013
Agenda
Introduction
SUP Caching Basics

SUP Caching Examples On Demand Scheduled DCN
Conclusion Further Reading
2011 SAP AG. All rights reserved.
Agenda
Introduction
SUP Caching Basics

SUP Caching By Example Todays Presentation

Goal of the presentation
Illustrating the theoretical concepts of SUP caching behaviour using examples. The examples illustrate step by step the effect of different cache settings.
Target audience Beginner and Intermediate SUP Mobile Developers and Architects
Setup used for the examples SUP 2.1.3
A Native ObjectAPI Android application

Data source : Sybase Sample DB
2011 SAP AG. All rights reserved. 4
SUP Caching By Example Todays Presentation

Scope of the presentation
Back End Sybase Mobile Platform (SUP)
Caching
Sync
Focus of this webinar

This presentation covers SUP caching concepts; Cache policies Load arguments Personalization Keys Synchronization Parameters Partitioning by Requestor and Device ID Different options for synchronization will not be covered in this presentation.
SUP Caching By Example Example Concept

A series of examples will be covered. Each example starts with an overview of the different settings; caching policy, load argument, personalization key, Then a sequence of steps will illustrate what the effect of the settings is. Since timing is important, each step will have a timestamp.
timestamp
Agenda
Introduction
SUP Caching Basics

Cache Group
A Cache Group holds one or more MBOs that need to be refreshed together.
1
Back End Sybase Mobile Platform (SUP) DB
Data Update
Cache Group
MBO MBO
CDB Table A Table B
Load Cache
Mobile Databases
Different data stores are involved when synchronizing mobile data: 1. Back End 2. SUP Cache Database (CDB) 3. Device Local Database 1
DB
Data Update
2
CDB
Table A Table B
Load Argument
A Load Argument filters the data that is loaded from the back end into the CDB.
1
Filter data by LA
Cache Group
MBO
LA
CDB
10
Personalization Key
Personalization Keys can be used to set the value of a Load Argument. The Personalization Key needs to be mapped to the Load Argument for this.
PK Back End Sybase Mobile Platform (SUP)
1
DB
Cache Group
MBO
LA
CDB
11
Synchronization Parameter
A Synchronization Parameter is used to filter data that is downloaded to the device.
SP Back End Sybase Mobile Platform (SUP)
1
DB
Cache Group
Filter data
MBO
CDB
12
Synchronization Parameter
A Synchronization Parameter can be mapped to a Load Argument. This will create a separate partition in the cache table for each value of the Sync Param.
SP Back End Sybase Mobile Platform (SUP)
1
DB
Cache Group
MBO
LA
CDB
13
Partition by Requester and Device Identity

The option Partition by Requester and Device Identity creates separate cache partitions for each device-user combination.
1
Cache Group
MBO
Partition by User & Device ID
2
DB
CDB
1 2
Cache Policies
On Demand
Cache data is not refreshed until the client performs synchronization
Scheduled Cache data is refreshed periodically according to a schedule that is set
Data Change Notification (DCN) Changes in cache data are pushed by the back end when specific events occur
15
Cache Policies Comparison

Start A change is made in the back end A mobile A change is end user made in the back end synchronizes
0
CDB CDB
60 min
CDB CDB CDB
120 min
CDB
On Demand (Zero sec)

No Update No Update No Update Update No Update
Scheduled (60 min)
CDB
CDB
CDB
CDB
CDB
CDB
No Update
Update
No Update
No Update
Update
DCN
CDB
CDB
CDB
CDB
CDB
CDB
Update
No Update
Update
No Update
No Update
16
Agenda
Introduction
SUP Caching Basics

17
List of Examples 1/2

Cache Policy : On Demand
EXAMPLE
EXAMPLE
Zero Cache Interval

Zero Cache Interval with Partitioning by Requester and Device ID 1 hour Cache Interval
EXAMPLE EXAMPLE EXAMPLE EXAMPLE

EXAMPLE
1 hour Cache Interval with Partitioning by Requester and Device ID

1 hour Cache Interval with Load Argument mapped to Personalization Key 1 hour Cache Interval with Synchronization Parameter 1 hour Cache Interval with Synchronization Parameter mapped to Load Argument
18
List of Examples 2/2

Cache Policy : Scheduled
EXAMPLE EXAMPLE
1 Hour Cache Interval with Load Argument

1 Hour Cache Interval with Sync Param mapped to Load Argument
Cache Policy : Data Change Notification

EXAMPLE EXAMPLE
DCN with Payload DCN without Payload
19
Example On Demand Zero Cache Interval
Example On Demand with Zero Cache Interval Setup

SUP Artifact
Caching Policy
Used
On Demand
Remarks
Cache Interval is zero seconds No Partition by Requester And Device ID
Load Argument
Personalization Key Synchronization parameter
No
No No
Back End
Sybase Mobile Platform (SUP)
CP On Demand
0 seconds interval Partition by Req. & Device ID
DB
21
Example On Demand with Zero Cache Interval Scenario 00:00

Back End
The developer deploys the MBO data model to the SUP

1
DB No records
CP On Demand
0 seconds interval
Partition by User & Device ID CDB

100 records
Sybase Unwired Workspace
100 records
MBO
After deployment the MBO database table in the CDB is filled up with the 100 records found in the back end. The database on the client is empty.

Back End
User 1 synchronizes
1
DB 100 records
CP On Demand
0 seconds interval

100 records
100 records
After synchronization, the local database on the device of User 1 holds the 100 records.

Back End
Now a change is made in the data in Back End.

1
DB 100 records
CP On Demand
0 seconds interval

100 records, 1 record has changed
100 records
After the change is made in the Back End, the CDB is not updated automatically. It will only be updated if one of the connected devices synchronizes.

Back End
Now User 1 synchronizes again

1
DB 100 records 1 record has changed
CP On Demand
0 seconds interval

100 records,
100 records 1 record has changed
After synchronization, the change was pulled from the Back End into the CDB. The changed record is also downloaded to the local database on the device of User 1.

Back End
Now User 2 connects to the SUP and synchronizes

1
DB 100 records
CP On Demand
0 seconds interval

100 records,
100 records
2
DB
After synchronization, the local database on the device of User 2 holds the 100 records retrieved from the CDB, including the record that was changed.
Conclusion
The CDB is only updated when one of the devices synchronizes.
Every time a device synchronizes, the SUP will look for changed data in the Back End.
All the devices that synchronize an MBO receive the same cache data for this MBO.
27
Example On Demand Zero Cache Interval with Partitioning by Requester and Device ID
Example On Demand with Zero Cache Interval, Partitioned by Requester and Device ID
SUP Artifact
Caching Policy
Used
Remarks
On Demand Cache Interval is zero seconds Partitioned by Requester And Device ID
Load Argument
No
No No
Back End
CP On Demand
0 seconds interval Partition by Req. & Device ID
DB
29
Example On Demand with Zero Cache Interval, Partitioned by Requester and Device ID 00:00
Back End

1
DB No records
CP On Demand
0 seconds interval

100 records
100 records
MBO
Back End
User 1 synchronizes
1
DB 100 records
CP On Demand
0 seconds interval

100 records
100 records
After synchronization, the local database on the device of user 1 holds the 100 records.
Back End

1
DB 100 records
CP On Demand
0 seconds interval

100 records
100 records
100 records
2
DB
100 records
After synchronization, a new partition is created in the database table in the CDB. The local database on the device of user 2 has received the 100 records retrieved from that new partition in the CDB.
Back End

1
DB 100 records
CP On Demand
0 seconds interval

100 records
100 records
2
DB
100 records
After the change is made in the back end, the CDB is not updated automatically. It will only be updated if one of the connected devices synchronizes.
Back End
Now User 2 synchronizes

1
DB 100 records
CP On Demand
0 seconds interval

100 records, 1 record has changed 100 records 1 record has changed
100 records
2
DB
After synchronization, the local database on the device of User 2 has the changed record. The change was pulled from the Back End into the CDB. The partition for user 1 (in the CDB database table) was not changed.
Back End

1
CP On Demand
0 seconds interval


2
DB
After synchronization, the partition for User 1 (in the CDB database table) has been updated with the change. The local database on device of User 1 is also updated with the change.
Conclusion
The option Partition by Requester and Device Identity causes separate partitions to be made in the CDB.
Each device/user combination gets assigned its own partition.
The caching logic is now applied for each caching partition individually.
36
Example On Demand 1 Hour Cache Interval
Example On Demand with 1 Hour Cache Interval Setup

SUP Artifact
Caching Policy
Used
Remarks
On Demand Cache Interval is 1 hour Not Partitioned by Requester And Device ID
Load Argument
No
No No
Back End
CP On Demand
1 hour interval Partition by Req. & Device ID
DB
38
Example On Demand with 1 Hour Cache Interval Scenario 00:00

Back End

1
DB No records
CP On Demand
1 hour interval

100 records
100 records
MBO

Back End
User 1 synchronizes
1
DB 100 records
CP On Demand
1 hour interval

100 records
100 records
After synchronization, the local database on the device of User 1 holds the 100 records.

Back End
Less than an hour later, a change is made in the data in the Back End.
1
DB
100 records
CP On Demand
1 hour interval

100 records
After the change is made in the back end, the CDB is not updated automatically. It will only be updated if one of the devices synchronizes and if the last update of tables in that Cache Group in the CDB was less than an hour ago.

Back End
Now User 1 synchronizes again, still within the hour.

1
DB 100 records
CP On Demand
1 hour interval

100 records
After synchronization, the local database on the device of user 1 does not have the changed line. The change was not pulled from the Back End into the CDB.

Back End
User 1 synchronizes again, after the hour.

1
CP On Demand
1 hour interval

After synchronization, the local database on the device of User 1 does have the changed record. The change was pulled from the Back End into the CDB.

Back End

1
CP On Demand
1 hour interval

100 records, 1 record has changed 100 records
2
DB
After synchronization, the local database on the device of User 2 holds the 100 records retrieved from the CDB, including the change that was made in the Back End.
Conclusion
The CDB is only updated when one of the devices synchronizes and the CDB has expired
Every time a device synchronizes, the SUP will check if the cache has expired;
If so, the SUP will look for data changes in the Back End.
If not, the SUP will not check the Back End for changes.
This is called Back End Offloading : the Back End will not be queried each time a mobile device synchronizes. This reduces the load on the Back End.
All the devices that synchronize an MBO receive the same cache data for this MBO.
Example On Demand 1 Hour Cache Interval with Partitioning by Requester and Device ID
Example On Demand with 1 Hour Cache Interval Partitioned by Requester and Device ID
SUP Artifact
Caching Policy
Used
On Demand
Remarks
Cache Interval is 1 hour Partitioned by Requester And Device ID
Load Argument
No
No No
Back End
CP On Demand
1 hour interval Partition by Req. & Device ID
DB
47
Example On Demand with 1 Hour Cache Interval Partitioned by Requester and Device ID 00:00
Back End

1
DB No records
CP On Demand
1 hour interval

100 records
100 records
MBO
After deployment the MBO database table in the CDB is filled up with the 100 records found in the back end. They all belong to the same partition. The database on the client is empty.
Back End
User 1 synchronizes
1
DB 100 records
CP On Demand
1 hour interval

100 records
100 records
After synchronization, the local database on the device of user 1 holds the 100 records.
Back End

1
DB 100 records
CP On Demand
1 hour interval

100 records
100 records
100 records
2
DB
100 records
After synchronization, a new partition is created in the database table in the CDB. The local database on the device of User 2 holds the 100 records retrieved from that new partition in the CDB.
Back End

1
DB 100 records
CP On Demand
1 hour interval

100 records
100 records
2
DB
100 records
After the change is made in the back end, the CDB cache is not updated automatically.
Back End

1
DB 100 records
CP On Demand
1 hour interval

100 records
100 records
2
DB
After synchronization, the change was not pulled from the Back End into the CDB partition because the cache partition did not expire in the meantime. As a result the local database on the devices does not have the changed record either.
Back End
User 1 synchronizes more than an hour after his initial sync.

1
CP On Demand
1 hour interval


100 records
2
DB
After synchronization, the CDB cache partition for User 1 has been updated with the change. The local database on device of User 1 is also updated with the change.
Example On Demand with 1 Hour Cache Interval Partitioned by Requester and Device ID 01:08 Now User 2 synchronizes less than an hour after his initial sync
1
DB
CP On Demand
1 hour interval


100 records
2
DB
The CDB cache partition for User 2 is not updated and neither is the local database on the device of User 2
Back End
User 2 synchronizes more than an hour after his initial sync

1
CP On Demand
1 hour interval


2
DB
The CDB cache partition for User 2 is updated and so is the local database on the device of User 2
Conclusion
The option Partition by Requester and Device Identity causes separate partitions to be made in the CDB.
Each user/device combination gets assigned its own partition.
The caching logic is now applied for each caching partition individually;
All the cache partitions have the same caching time interval (1 hour in this example).
The time on which the cache partition expires can be different for each partition; it depends on the time user/device (for this partition) last synchronized.
From this point onwards the option Partition by Requester and Device Identity will not be covered any further. Do bear in mind that it can be selected for each On Demand caching scenario.
56
Example On Demand 1 Hour Cache Interval with Load Argument mapped to Personalization Key
Example On Demand with 1 Hour Cache Interval Personalization Key mapped to Load Argument
SUP Artifact
Caching Policy
Used
On Demand
Remarks
Cache Interval is 1 hour Not partitioned by Requester And Device ID
Load Argument
Yes
Yes No
No default value is specified

Mapped to load argument
Back End
PK
CP On Demand
1 Hour Interval Partition by Req. & Device ID
DB
58
Example On Demand with 1 Hour Cache Interval Personalization Key mapped to Load Argument 00:00
Back End

1
DB
CP On Demand
1 hour interval

50 records 50 records 50 records
MBO
After deployment the MBO database table in the CDB is not filled up with any records of the Back End because no value for the Load Argument is specified. The database on the client is empty.
Back End
User 1 fills in a value for the Personalization Key and synchronizes

Sybase Mobile Platform (SUP) PK1
1
DB
50 records
CP On Demand
1 hour interval
Partition by User & Device ID 50 records

50 records 50 records
CDB
50 records (LA1)
After synchronization, the Back End records corresponding to the value of the Load Argument are loaded into the CDB and the same records are downloaded to the local database on the device.
Back End
A change is made in the back end. User 1 synchronizes with the same value for the Personalization Key.
1
DB
CP On Demand
1 hour interval
Partition by User & Device ID 50 records 1 record has changed

CDB
50 records (LA1) 1 record has changed
After synchronization, the changed record is loaded into the CDB cache partition and the changed record is downloaded to the local database on the device.
Back End
User 1 changes the value of the Personalization Key and synchronizes.

1
DB
50 records
CP On Demand
1 hour interval

CDB
50 records (LA1)
After synchronization, nothing changes because the cache partition has not expired yet. The data in the CDB is not updated and no changes are downloaded to the local database on the device.
Back End
User 1 changes the value of the Personalization Key again and synchronizes.
Sybase Mobile Platform (SUP) PK3 2
1
DB
CP On Demand
1 hour interval

CDB
50 records (LA1) 50 records (LA3)
After synchronization, the Back End records corresponding to the new value of the Load Argument are loaded into the CDB and the same records are downloaded to the local database on the device. The old cache records are (logically) deleted.
Back End
Now User 2 synchronizes using another value for the Personalization Key that User 1 specified.
Sybase Mobile Platform (SUP) PK3 2
1
DB
50 records
CP On Demand
1 hour interval

50 records 50 records DB
CDB
50 records (LA3)
PK2
50 records
After synchronization, the CDB is not updated because the partition has not expired yet. User 2 receives the records corresponding to the latest value of the Personalization Key with which the CDB was updated.
Back End
Now User 2 synchronizes again

PK3 2
1
DB
50 records
CP On Demand
1 hour interval

CDB
PK2
2
DB
After synchronization, the CDB is updated. User 2 receives the records corresponding to the latest value of the Personalization Key he specified.
Back End
Now User 1 synchronizes.

PK3 2
1
DB
CP On Demand
1 hour interval

50 records 50 records DB
CDB
50 records (LA2)
PK2
50 records
After synchronization, the CDB is not updated. User 1 receives the content of the CDB partition in the local database on his device.
Conclusion
Be careful when mapping a Personalization Key to a Load Argument ;

when partitions are shared between multiple users and an on demand cache interval is used, it can lead to unexpected results.
In most use cases this combination is best used with Partition by Requester and Device Identity .
This will cause cache partitions to be created for each user/device combination.
Or, as an alternative, use a synchronization parameter mapped to a Load Argument (and dont use Personalization Keys). This will cause cache partitions to be created for each value of the Load Argument.
Example On Demand 1 Hour Cache Interval with Synchronization Parameter
Example On Demand with 1 Hour Cache Interval Synchronization Parameter

SUP Artifact
Caching Policy
Used
On Demand
Remarks
Cache Interval is 1 hour Not partitioned by Requester And Device ID
Load Argument
No
No Yes No default value is specified Not mapped to Load Argument
Back End
SP
CP On Demand
DB
70
Example On Demand with 1 Hour Cache Interval Synchronization Parameter 00:00

Back End

1
DB
CP On Demand
1 hour interval

50 records
50 records
MBO
After deployment the MBO database table in the CDB is filled up with the 100 records found in the Back End. The database on the client is empty.

Back End
User 1 fills in a value for the Synchronization Parameter and synchronizes

Sybase Mobile Platform (SUP) SP1
1
DB
50 records
CP On Demand
1 hour interval

50 records
CDB 50 records
50 records
After synchronization the 50 records corresponding to the value of the Sync Param are downloaded to the local database on the device.

Back End
Now a change is made in the Back End and User 1 synchronizes again
1
DB
50 records
CP On Demand
1 hour interval

50 records
CDB 50 records
50 records
After synchronization the CDB cache partition will not be updated because it has not expired yet.

Back End
User 1 synchronizes again

SP1
1
DB
CP On Demand
1 hour interval

50 records
CDB 50 records 1 record has changed

50 records
After synchronization the CDB cache partition will be updated with the changed record. The local database on the device receives the changed record as well.

Back End

SP1
1
DB
50 records
CP On Demand
1 hour interval

50 records
CDB 50 records
50 records
SP2
2
DB
50 records
After synchronization the CDB cache records corresponding to the value User 2 entered (for the SP) are downloaded to the local database on the device of User 2.

Back End
User 1 now fills in a new value for the Synchronization Parameter

1
DB
CP On Demand
1 hour interval

50 records
CDB 50 records
50 records
SP2
2
DB
50 records
After synchronization the local database on the device of User 1 is updated with the CDB records corresponding to the new value for the SP. . By default the values entered for the SP are cumulative.
Conclusion
When working a Synchronization Parameter, only one main partition will be created in the CDB MBO database table (*). When synchronizing, the data in this partition will be filtered based on the value entered for the Synchronization Parameter. This way only the data that corresponds to the value of the Synchronization Parameter is downloaded to the device.
By default, with each synchronization with a new (added) value for the Synchronization Parameter, additional records will be downloaded to the device. This behavior can be changed by deleting the values for the Synchronization Parameter (on the device) before filling in a new value; this way only records corresponding to the latest value will be downloaded to the device.
(*) This is true when the Synchronization Parameter is not mapped to a Load Argument and if the option Partition by Requester and Device Identity is not used.
Example On Demand 1 Hour Cache Interval with Synchronization Parameter mapped to Load Argument
Example On Demand with 1 Hour Cache Interval Synchronization Parameter mapped to Load Argument
SUP Artifact
Caching Policy
Used
Remarks
On Demand Cache Interval is 1 hour Not partitioned by Requester And Device ID
Load Argument
Yes
No Yes
No default value is specified
No default value is specified Mapped to Load Argument
Back End
SP
CP On Demand
DB
79
Example On Demand with 1 Hour Cache Interval Synchronization Parameter mapped to Load Argument 00:00
Back End

1
DB
CP On Demand
1 hour interval

50 records 50 records 50 records
MBO
After deployment the MBO database table in the CDB is not filled up with any records of the Back End because no value for the Load Argument is specified. The database on the client is empty.
Back End
User 1 fills in the Synchronization Parameter and synchronizes.

SP1
1
DB
50 records
CP On Demand
1 hour interval

CDB
50 records (LA1)
After synchronization the CDB has filled up with the records corresponding to the value entered for the Sync Param (which was automatically mapped to the Load Argument)
Back End
Now a change is made in the back end and User 1 synchronizes

1
DB
50 records
CP On Demand
1 hour interval

CDB
50 records (LA1)
After synchronization the CDB cache partition is not updated with the changed record because the partition did not expire yet.
Back End
User 1 changes the value for the Synchronization Parameter and synchronizes
1
DB
CP On Demand
1 hour interval

CDB
After synchronization a new partition is made in the CDB, containing the records corresponding to the new value of the Sync Param. The new records are also downloaded to the local database on the device of User 1.
Back End
Now User 2 connects to the SUP, fills in a value for the Synchronization Parameter and synchronizes
1
DB
CP On Demand
1 hour interval

CDB
50 records (LA1) 50 records (LA3) 50 records (LA2)
SP2
2
DB
50 records
After synchronization a new partition is made in the CDB, containing the records corresponding to the new value of the Sync Param, entered by User 2. The new records are also downloaded to the local database on the device of User 2.
Back End
User 2 fills in another value for the Synchronization Parameter and synchronizes
1
DB
CP On Demand
1 hour interval

CDB
50 records (LA1) 1 record has changed 50 records (LA3) 50 records (LA2)
SP1
2
DB
After synchronization the changed record of the Back End is updated in the corresponding CDB cache partition because the partition expired. This partition is also downloaded to the local database of the device of User 2.
Conclusion
When working a Synchronization Parameter mapped to a Load Argument, a separate cache partition will be created for each value of the Synchronization Parameter that was entered on a mobile device.
When synchronizing, the data in this partition will be downloaded to the local database on the device.
86
Example Scheduled 1 Hour Cache Interval with Load Argument
Example Scheduled with 1 Hour Cache Interval With Load Argument

SUP Artifact
Caching Policy Load Argument Personalization Key
Used
Scheduled Yes No
Remarks
Cache Interval is 1 hour With default value
Synchronization parameter No
Back End
CP Scheduled
1 Hour Interval DB
88
Example Scheduled with 1 Hour Cache Interval With Load Argument 00:00
Back End

1
DB No records
CP Scheduled
1 Hour interval
50 records
CDB
50 records (LA1)
MBO
After deployment the MBO database table in the CDB is filled up with the 50 records found in the back end corresponding to the default value of the Load Argument. The database on the client is empty.
Back End

1
DB 50 records
CP Scheduled
1 Hour interval
50 records
CDB
50 records (LA1)
After synchronization, the local database on the device of User 1 has all the records from the CDB cache.
Back End

1
DB 50 records
CP Scheduled
1 Hour interval
50 records
CDB
50 records (LA1)
2
DB
50 records
After synchronization, the local database on the device of User 2 has all the records from the CDB cache.
Example Scheduled with 1 Hour Cache Interval With Load Argument 00:15 A change is made in the back end and User 1 synchronizes
1
DB
50 records
CP Scheduled
1 Hour interval
CDB
50 records (LA1)
2
DB
50 records
After synchronization, the CDB is not updated, because the partition has not expired yet. As a consequence, the local database on the devices of User 1 does not get updated either.
Back End
No change is made in the back end and none of the devices synchronize
1
DB
50 records
CP Scheduled
1 Hour interval
50 records
CDB
50 records (LA1) 1 record has changed
2
DB
50 records
Even though none of the devices synchronize, the CDB cache partition is updated with the changed record. This is because the scheduled cache partition expired.
Back End
User 1 and User 2 synchronize

1
CP Scheduled
1 Hour interval
50 records
CDB
50 records (LA1)
2
DB
50 records
1 record has changed
After synchronization, the changed record is downloaded to the local databases on the devices of User 1 and User 2.
Conclusion
With a Scheduled Cache Policy, the CDB will be updated with regular time intervals, irrespective of any synchronizations triggered from a mobile device.
The schedule can be specified as follows; In the Sybase Unwired Tooling
In the Sybase Control Center (SCC)

The SCC offers more options to specify the interval; days of the week to run the schedule, start time,
When using a Load Argument only a part of the Back End data will be loaded into the CDB. If no Load Arguments are used, all relevant Back End data will be loaded into the CDB.
Example Scheduled 1 Hour Cache Interval with Synchronization Parameter mapped to Load Argument
Example Scheduled with 1 Hour Cache Interval With Sync Parameter mapped to Load Argument
SUP Artifact
Used
Scheduled Yes No
Remarks
Cache Interval is 1 hour No default value
Synchronization parameter Yes
Mapped to Load Argument
Back End
SP
CP Scheduled
1 Hour Interval DB
97
Example Scheduled with 1 Hour Cache Interval With Sync Parameter mapped to Load Argument 00:00
Back End

1
DB No records
CP Scheduled
1 Hour interval
50 records
50 records
CDB
No records
MBO
After deployment the MBO database table in the CDB is not filled up with the records found in the Back End because no value for the Load Argument was specified.
Example Scheduled with 1 Hour Cache Interval With Sync Parameter mapped to Load Argument 00:05 User 1 fills in a Synchronization Parameter and synchronizes
Back End Sybase Mobile Platform (SUP) SP1
1
DB
50 records
CP Scheduled
1 Hour interval
50 records
50 records
CDB
50 records (LA1)
After synchronization, the CDB has fillled up a partition corresponding to the value of the Sync Param. The data is also downloaded to the local database on the device of User 1.
Example Scheduled with 1 Hour Cache Interval With Sync Parameter mapped to Load Argument 00:30 User 2 fills in a Synchronization Parameter and synchronizes
Back End Sybase Mobile Platform (SUP) SP1
1
DB
50 records
CP Scheduled
1 Hour interval
50 records
50 records
CDB
50 records (LA1)
SP2
2
DB
50 records
50 records (LA2)
After synchronization, the CDB has fillled up a partition corresponding to the value of the Sync Param of User 2. The data is also downloaded to the local database on the device of User 2.
Back End
Some changes are made in the Back End and User 1 synchronizes
1
DB
50 records
CP Scheduled
1 Hour interval
50 records 1 record has changed 50 records 1 record has changed
CDB
50 records (LA1)
SP2
2
DB
50 records
50 records
After synchronization, the CDB is not updated with the changed record because the partition has not expired yet. As a consequence, the local database on the device of User 1 is not updated either.
Back End
No change is made in the back end and none of the users synchronize
1
DB
50 records
CP Scheduled
1 Hour interval
50 records
50 records
CDB
50 records (LA1) 1 record has changed 50 records 1 record has changed
SP2
2
DB
50 records
The CDB is updated with the changed records because the cache has expired based on the schedule. Both partitions are updated.
Conclusion
Also with a Scheduled Cache Policy, separate cache partitions will be created when Synchronization Parameters are mapped to Load Arguments.
With Scheduled Cache Policy it is not possible to map a Personalization Key to a Load Argument directly. Also, with a Scheduled Cache Policy there is no option to partition the cache by Requester and Device Identity.
103
Example DCN With Payload
Example DCN with Payload

SUP Artifact
Used
DCN No No
Remarks
With Payload
Back End
CP DCN
DB
105
Example DCN with Payload 00:00

Back End

1
DB No records
CP DCN
50 records
CDB
No records
MBO
After deployment the MBO database table in the CDB is not filled up with the records found in the Back End.
Example DCN with Payload 00:05

Back End
A DCN is triggered from the Back End.

1
DB
CP DCN
50 records
CDB
DCN
In case of an :upsert DCN, the CDB is updated with a new or updated record(s). In case of a :delete DCN, an existing record is deleted from the CDB. No changes are made in the Back End (although DCNs are usually triggered from back end changes)
Conclusion
DCN is the best option to keep the CDB up to date with data changes in the Back End.
Bear in mind that once the data is updated in the CDB, this does not mean that its synchronized to the device yet. This is an additional step to consider when using DCN.
Also, the initial load of a DCN cache group in the CDB is not straightforward.
The DCN does not allow the use of Cache Partitions (*).
(*) This is true for versions of SUP up until SUP 2.2.

Example DCN Without Payload
Example DCN without Payload

SUP Artifact
Used
DCN No No
Remarks
Without Payload
Back End
CP DCN
DB
110
Example DCN without Payload 00:00

Back End

1
DB No records
CP DCN
50 records
CDB
No records
MBO
After deployment the MBO database table in the CDB is not filled up with the records found in the Back End.
Example DCN without Payload 00:05

Back End
A DCN is triggered from the back end.

1
DB
CP DCN
DCN
MBO Operation
CDB
Cache Update
The DCN triggers an MBO operation which gets executed on the Back End. Depending on the cache policy of the MBO operation, the CDB will be updated with the results of the execution of the MBO operation on the Back End (or not).
Conclusion
DCN with Payload is considered better for performance because no calls need to be made to the Back End. On the other hand, the size of the DCN message with payload can be bigger compared to DCN without payload.
113
Agenda
Introduction
SUP Caching Basics

114
Conclusion
As follows some use cases and some recommendations for Cache Policies to use.
Please note that these use cases are offered as examples and each real world scenario needs to be considered individually to determine the optimal cache policy.
Use Case
The Back End data is non-critical and does not change often. Changes in the Back End data do not need to be propagated to the cache and the mobile device right away. Customer Address Data
Example
Recommended Cache Policy Comments
Scheduled By scheduling a refresh once a day outside office hours, the load on the SUP server (and Back End) can be reduced.
115
Conclusion
Use Case
Changes in the Back End data need to be propagated to the cache and the mobile device right away. A high volume of Back End data is involved. Pricing Data
Example
Recommended Cache Policy Comments
DCN When the Back End data changes, DCNs can be sent to the SUP to update the cache. The SUP can trigger a synchronization from the device to make sure the data is also updated there.
116
Conclusion
Use Case Whenever the user synchronizes the device, its important that the latest changes in the Back End data are downloaded right away. The volume of Back End data is low to moderate. Appointment Data On Demand with Zero Cache Interval This policy ensures that the data that is downloaded to the device is always up to date with the Back End. The cache is only updated when the device synchronizes, so cache refreshes that are unnecessary (outside office hours for example) can be avoided.
Example Recommended Cache Policy Comments
117
Conclusion
Use Case Example
Recommended Cache Policy
The Back End data that is mobilized is user specific. Sales Orders
On Demand with Partitioning by Requester and Device Identity
Comments
With this policy separate cache partitions will be created in the CDB for each user (and his device).
This way of working increases parallelism and speeds up cache operations.
118
Agenda
Introduction
SUP Caching Basics

119
Further Reading
Sybase Infocenter - SUP 2.1.3 :

Best Practices for Loading Data From the EIS to the CDB
SCN Blog : http://scn.sap.com/community/developer-center/mobilityplatform/blog/2013/02/01/mapping-sup-personalization-keys-a-little-quiz
120
No part of this publication may be reproduced or transmitted in any form or for any purpose without the express permission of SAP AG. The information contained herein may be changed without prior notice. Some software products marketed by SAP AG and its distributors contain proprietary software components of other software vendors. Microsoft, Windows, Excel, Outlook, PowerPoint, Silverlight, and Visual Studio are registered trademarks of Microsoft Corporation. IBM, DB2, DB2 Universal Database, System i, System i5, System p, System p5, System x, System z, System z10, z10, z/VM, z/OS, OS/390, zEnterprise, PowerVM, Power Architecture, Power Systems, POWER7, POWER6+, POWER6, POWER, PowerHA, pureScale, PowerPC, BladeCenter, System Storage, Storwize, XIV, GPFS, HACMP, RETAIN, DB2 Connect, RACF, Redbooks, OS/2, AIX, Intelligent Miner, WebSphere, Tivoli, Informix, and Smarter Planet are trademarks or registered trademarks of IBM Corporation. Linux is the registered trademark of Linus Torvalds in the United States and other countries. Adobe, the Adobe logo, Acrobat, PostScript, and Reader are trademarks or registered trademarks of Adobe Systems Incorporated in the United States and other countries. Oracle and Java are registered trademarks of Oracle and its affiliates. UNIX, X/Open, OSF/1, and Motif are registered trademarks of the Open Group. Citrix, ICA, Program Neighborhood, MetaFrame, WinFrame, VideoFrame, and MultiWin are trademarks or registered trademarks of Citrix Systems Inc. HTML, XML, XHTML, and W3C are trademarks or registered trademarks of W3C, World Wide Web Consortium, Massachusetts Institute of Technology. Apple, App Store, iBooks, iPad, iPhone, iPhoto, iPod, iTunes, Multi-Touch, Objective-C, Retina, Safari, Siri, and Xcode are trademarks or registered trademarks of Apple Inc. IOS is a registered trademark of Cisco Systems Inc. RIM, BlackBerry, BBM, BlackBerry Curve, BlackBerry Bold, BlackBerry Pearl, BlackBerry Torch, BlackBerry Storm, BlackBerry Storm2, BlackBerry PlayBook, and BlackBerry App World are trademarks or registered trademarks of Research in Motion Limited.
Google App Engine, Google Apps, Google Checkout, Google Data API, Google Maps, Google Mobile Ads, Google Mobile Updater, Google Mobile, Google Store, Google Sync, Google Updater, Google Voice, Google Mail, Gmail, YouTube, Dalvik and Android are trademarks or registered trademarks of Google Inc. INTERMEC is a registered trademark of Intermec Technologies Corporation. Wi-Fi is a registered trademark of Wi-Fi Alliance. Bluetooth is a registered trademark of Bluetooth SIG Inc. Motorola is a registered trademark of Motorola Trademark Holdings LLC. Computop is a registered trademark of Computop Wirtschaftsinformatik GmbH. SAP, R/3, SAP NetWeaver, Duet, PartnerEdge, ByDesign, SAP BusinessObjects Explorer, StreamWork, SAP HANA, and other SAP products and services mentioned herein as well as their respective logos are trademarks or registered trademarks of SAP AG in Germany and other countries. Business Objects and the Business Objects logo, BusinessObjects, Crystal Reports, Crystal Decisions, Web Intelligence, Xcelsius, and other Business Objects products and services mentioned herein as well as their respective logos are trademarks or registered trademarks of Business Objects Software Ltd. Business Objects is an SAP company. Sybase and Adaptive Server, iAnywhere, Sybase 365, SQL Anywhere, and other Sybase products and services mentioned herein as well as their respective logos are trademarks or registered trademarks of Sybase Inc. Sybase is an SAP company. Crossgate, m@gic EDDY, B2B 360, and B2B 360 Services are registered trademarks of Crossgate AG in Germany and other countries. Crossgate is an SAP company. All other product and service names mentioned are the trademarks of their respective companies. Data contained in this document serves informational purposes only. National product specifications may vary. The information in this document is proprietary to SAP. No part of this document may be reproduced, copied, or transmitted in any form or for any purpose without the express prior written permission of SAP AG.

SUP Caching by Example - Webinar Slides

Uploaded by

Document Information

Original Description:

Copyright

Available Formats

Share this document

Share or Embed Document

Sharing Options

Did you find this document useful?

Is this content inappropriate?

Copyright:

Available Formats

SUP Caching by Example - Webinar Slides

Uploaded by

Copyright:

Available Formats

Wim Verhelst January 2013

SUP Caching Basics

Conclusion Further Reading

2011 SAP AG. All rights reserved.

SUP Caching Basics

Conclusion Further Reading

2011 SAP AG. All rights reserved.