Agenda
Introduction
Agenda
Introduction
Target audience Beginner and Intermediate SUP Mobile Developers and Architects
Caching
Sync
Agenda
Introduction
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
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
Back End Sybase Mobile Platform (SUP)
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
Back End Sybase Mobile Platform (SUP) DB
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.
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
1
Back End Sybase Mobile Platform (SUP) DB
Cache Group
MBO
Partition by User & Device ID
2
DB
CDB
1 2
2011 SAP AG. All rights reserved. 14
Cache Policies
On Demand
Cache data is not refreshed until the client performs synchronization
Data Change Notification (DCN) Changes in cache data are pushed by the back end when specific events occur
15
0
CDB CDB
60 min
CDB CDB CDB
120 min
CDB
CDB
CDB
CDB
CDB
CDB
CDB
No Update
Update
No Update
No Update
Update
DCN
CDB
CDB
CDB
CDB
CDB
CDB
Update
2011 SAP AG. All rights reserved.
No Update
Update
No Update
No Update
16
Agenda
Introduction
17
18
19
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
CP On Demand
0 seconds interval Partition by Req. & Device ID
2011 SAP AG. All rights reserved.
DB
21
CP On Demand
0 seconds interval
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.
2011 SAP AG. All rights reserved. 22
User 1 synchronizes
1
DB 100 records
CP On Demand
0 seconds interval
100 records
After synchronization, the local database on the device of User 1 holds the 100 records.
2011 SAP AG. All rights reserved. 23
CP On Demand
0 seconds 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 connected devices synchronizes.
2011 SAP AG. All rights reserved. 24
CP On Demand
0 seconds interval
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.
2011 SAP AG. All rights reserved. 25
CP On Demand
0 seconds interval
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.
2011 SAP AG. All rights reserved. 26
Conclusion
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
Load Argument
Personalization Key Synchronization parameter
No
No No
Back End
CP On Demand
0 seconds interval Partition by Req. & Device ID
2011 SAP AG. All rights reserved.
DB
29
Example On Demand with Zero Cache Interval, Partitioned by Requester and Device ID 00:00
Back End
CP On Demand
0 seconds interval
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.
2011 SAP AG. All rights reserved. 30
Example On Demand with Zero Cache Interval, Partitioned by Requester and Device ID 00:05
Back End
User 1 synchronizes
1
DB 100 records
CP On Demand
0 seconds interval
100 records
After synchronization, the local database on the device of user 1 holds the 100 records.
2011 SAP AG. All rights reserved. 31
Example On Demand with Zero Cache Interval, Partitioned by Requester and Device ID 00:10
Back End
CP On Demand
0 seconds interval
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.
2011 SAP AG. All rights reserved. 32
Example On Demand with Zero Cache Interval, Partitioned by Requester and Device ID 00:15
Back End
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.
2011 SAP AG. All rights reserved. 33
Example On Demand with Zero Cache Interval, Partitioned by Requester and Device ID 00:20
Back End
CP On Demand
0 seconds interval
100 records
100 records 1 record has changed
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.
2011 SAP AG. All rights reserved. 34
Example On Demand with Zero Cache Interval, Partitioned by Requester and Device ID 00:25
Back End
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.
2011 SAP AG. All rights reserved. 35
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
Used
Remarks
Load Argument
Personalization Key Synchronization parameter
No
No No
Back End
CP On Demand
1 hour interval Partition by Req. & Device ID
2011 SAP AG. All rights reserved.
DB
38
CP On Demand
1 hour interval
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.
2011 SAP AG. All rights reserved. 39
User 1 synchronizes
1
DB 100 records
CP On Demand
1 hour interval
100 records
After synchronization, the local database on the device of User 1 holds the 100 records.
2011 SAP AG. All rights reserved. 40
Less than an hour later, a change is made in the data in the Back End.
Sybase Mobile Platform (SUP)
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.
2011 SAP AG. All rights reserved. 41
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.
2011 SAP AG. All rights reserved. 42
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.
2011 SAP AG. All rights reserved. 43
CP On Demand
1 hour interval
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.
2011 SAP AG. All rights reserved. 44
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.
2011 SAP AG. All rights reserved. 45
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
Personalization Key Synchronization parameter
No
No No
Back End
CP On Demand
1 hour interval Partition by Req. & Device ID
2011 SAP AG. All rights reserved.
DB
47
Example On Demand with 1 Hour Cache Interval Partitioned by Requester and Device ID 00:00
Back End
CP On Demand
1 hour interval
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.
2011 SAP AG. All rights reserved. 48
Example On Demand with 1 Hour Cache Interval Partitioned by Requester and Device ID 00:05
Back End
User 1 synchronizes
1
DB 100 records
CP On Demand
1 hour interval
100 records
After synchronization, the local database on the device of user 1 holds the 100 records.
2011 SAP AG. All rights reserved. 49
Example On Demand with 1 Hour Cache Interval Partitioned by Requester and Device ID 00:10
Back End
CP On Demand
1 hour interval
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.
2011 SAP AG. All rights reserved. 50
Example On Demand with 1 Hour Cache Interval Partitioned by Requester and Device ID 00:15
Back End
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.
2011 SAP AG. All rights reserved. 51
Example On Demand with 1 Hour Cache Interval Partitioned by Requester and Device ID 00:20
Back End
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.
2011 SAP AG. All rights reserved. 52
Example On Demand with 1 Hour Cache Interval Partitioned by Requester and Device ID 01:07
Back End
CP On Demand
1 hour interval
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.
2011 SAP AG. All rights reserved. 53
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
Back End Sybase Mobile Platform (SUP)
1
DB
CP On Demand
1 hour interval
2
DB
The CDB cache partition for User 2 is not updated and neither is the local database on the device of User 2
2011 SAP AG. All rights reserved. 54
Example On Demand with 1 Hour Cache Interval Partitioned by Requester and Device ID 01:15
Back End
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
2011 SAP AG. All rights reserved. 55
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
Personalization Key Synchronization parameter
Yes
Yes No
Back End
PK
CP On Demand
1 Hour Interval Partition by Req. & Device ID
2011 SAP AG. All rights reserved.
DB
58
Example On Demand with 1 Hour Cache Interval Personalization Key mapped to Load Argument 00:00
Back End
CP On Demand
1 hour interval
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.
2011 SAP AG. All rights reserved. 59
Example On Demand with 1 Hour Cache Interval Personalization Key mapped to Load Argument 01:05
Back End
1
DB
50 records
CP On Demand
1 hour interval
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.
2011 SAP AG. All rights reserved. 61
Example On Demand with 1 Hour Cache Interval Personalization Key mapped to Load Argument 02:10
Back End
A change is made in the back end. User 1 synchronizes with the same value for the Personalization Key.
Sybase Mobile Platform (SUP) PK1
1
DB
CP On Demand
1 hour interval
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.
2011 SAP AG. All rights reserved. 62
Example On Demand with 1 Hour Cache Interval Personalization Key mapped to Load Argument 02:30
Back End
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.
2011 SAP AG. All rights reserved. 63
Example On Demand with 1 Hour Cache Interval Personalization Key mapped to Load Argument 03:15
Back End
User 1 changes the value of the Personalization Key again and synchronizes.
Sybase Mobile Platform (SUP) PK3 2
1
DB
50 records 50 records
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.
2011 SAP AG. All rights reserved. 64
Example On Demand with 1 Hour Cache Interval Personalization Key mapped to Load Argument 03:30
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
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.
2011 SAP AG. All rights reserved. 65
Example On Demand with 1 Hour Cache Interval Personalization Key mapped to Load Argument 04:30
Back End
1
DB
50 records
CP On Demand
1 hour interval
CDB
50 records (LA3) 50 records (LA2)
PK2
2
DB
50 records 50 records
After synchronization, the CDB is updated. User 2 receives the records corresponding to the latest value of the Personalization Key he specified.
2011 SAP AG. All rights reserved. 66
Example On Demand with 1 Hour Cache Interval Personalization Key mapped to Load Argument 04:40
Back End
1
DB
50 records 50 records
CP On Demand
1 hour interval
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.
2011 SAP AG. All rights reserved. 67
Conclusion
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.
2011 SAP AG. All rights reserved. 68
Used
On Demand
Remarks
Cache Interval is 1 hour Not partitioned by Requester And Device ID
Load Argument
Personalization Key Synchronization parameter
No
No Yes No default value is specified Not mapped to Load Argument
Back End
SP
CP On Demand
1 Hour Interval Partition by Req. & Device ID
2011 SAP AG. All rights reserved.
DB
70
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.
2011 SAP AG. All rights reserved. 71
1
DB
50 records
CP On Demand
1 hour interval
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.
2011 SAP AG. All rights reserved. 72
Now a change is made in the Back End and User 1 synchronizes again
Sybase Mobile Platform (SUP) SP1
1
DB
50 records
CP On Demand
1 hour interval
CDB 50 records
50 records
After synchronization the CDB cache partition will not be updated because it has not expired yet.
2011 SAP AG. All rights reserved. 73
1
DB
CP On Demand
1 hour interval
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.
2011 SAP AG. All rights reserved. 74
1
DB
50 records
CP On Demand
1 hour interval
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.
2011 SAP AG. All rights reserved. 75
1
DB
50 records 50 records
CP On Demand
1 hour interval
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.
2011 SAP AG. All rights reserved. 76
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.
2011 SAP AG. All rights reserved. 77
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
Load Argument
Personalization Key Synchronization parameter
Yes
No Yes
Back End
SP
CP On Demand
1 Hour Interval Partition by Req. & Device ID
2011 SAP AG. All rights reserved.
DB
79
Example On Demand with 1 Hour Cache Interval Synchronization Parameter mapped to Load Argument 00:00
Back End
CP On Demand
1 hour interval
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.
2011 SAP AG. All rights reserved. 80
Example On Demand with 1 Hour Cache Interval Synchronization Parameter mapped to Load Argument 00:10
Back End
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)
2011 SAP AG. All rights reserved. 81
Example On Demand with 1 Hour Cache Interval Synchronization Parameter mapped to Load Argument 00:15
Back End
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.
2011 SAP AG. All rights reserved. 82
Example On Demand with 1 Hour Cache Interval Synchronization Parameter mapped to Load Argument 00:20
Back End
User 1 changes the value for the Synchronization Parameter and synchronizes
Sybase Mobile Platform (SUP) SP3
1
DB
50 records 50 records
CP On Demand
1 hour interval
CDB
50 records (LA1) 50 records (LA3)
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.
2011 SAP AG. All rights reserved. 83
Example On Demand with 1 Hour Cache Interval Synchronization Parameter mapped to Load Argument 00:30
Back End
Now User 2 connects to the SUP, fills in a value for the Synchronization Parameter and synchronizes
Sybase Mobile Platform (SUP) SP3
1
DB
50 records 50 records
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.
2011 SAP AG. All rights reserved. 84
Example On Demand with 1 Hour Cache Interval Synchronization Parameter mapped to Load Argument 01:35
Back End
User 2 fills in another value for the Synchronization Parameter and synchronizes
Sybase Mobile Platform (SUP) SP3
1
DB
50 records 50 records
CP On Demand
1 hour interval
CDB
50 records (LA1) 1 record has changed 50 records (LA3) 50 records (LA2)
SP1
2
DB
50 records 50 records
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.
2011 SAP AG. All rights reserved. 85
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
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
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.
2011 SAP AG. All rights reserved. 89
Example Scheduled with 1 Hour Cache Interval With Load Argument 00:05
Back End
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.
2011 SAP AG. All rights reserved. 90
Example Scheduled with 1 Hour Cache Interval With Load Argument 00:10
Back End
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.
2011 SAP AG. All rights reserved. 91
Example Scheduled with 1 Hour Cache Interval With Load Argument 00:15 A change is made in the back end and User 1 synchronizes
Back End Sybase Mobile Platform (SUP)
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.
2011 SAP AG. All rights reserved. 92
Example Scheduled with 1 Hour Cache Interval With Load Argument 01:00
Back End
No change is made in the back end and none of the devices synchronize
Sybase Mobile Platform (SUP)
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.
2011 SAP AG. All rights reserved. 93
Example Scheduled with 1 Hour Cache Interval With Load Argument 01:20
Back End
CP Scheduled
1 Hour interval
50 records
CDB
50 records (LA1)
2
DB
50 records
After synchronization, the changed record is downloaded to the local databases on the devices of User 1 and User 2.
2011 SAP AG. All rights reserved. 94
Conclusion
With a Scheduled Cache Policy, the CDB will be updated with regular time intervals, irrespective of any synchronizations triggered from a mobile device.
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.
2011 SAP AG. All rights reserved. 95
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
Caching Policy Load Argument Personalization Key
Used
Scheduled Yes No
Remarks
Cache Interval is 1 hour No default value
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
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.
2011 SAP AG. All rights reserved. 98
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.
2011 SAP AG. All rights reserved. 99
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.
2011 SAP AG. All rights reserved. 100
Example Scheduled with 1 Hour Cache Interval With Sync Parameter mapped to Load Argument 00:45
Back End
Some changes are made in the Back End and User 1 synchronizes
Sybase Mobile Platform (SUP) SP1
1
DB
50 records
CP Scheduled
1 Hour interval
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.
2011 SAP AG. All rights reserved. 101
Example Scheduled with 1 Hour Cache Interval With Sync Parameter mapped to Load Argument 01:00
Back End
No change is made in the back end and none of the users synchronize
Sybase Mobile Platform (SUP) SP1
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.
2011 SAP AG. All rights reserved. 102
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
Used
DCN No No
Remarks
With Payload
Synchronization parameter No
Back End
CP DCN
DB
105
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.
2011 SAP AG. All rights reserved. 106
CP DCN
50 records
CDB
1 record has changed
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)
2011 SAP AG. All rights reserved. 107
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 (*).
Used
DCN No No
Remarks
Without Payload
Synchronization parameter No
Back End
CP DCN
DB
110
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.
2011 SAP AG. All rights reserved. 111
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).
2011 SAP AG. All rights reserved. 112
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
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
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
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.
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
119
Further Reading
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.