Hello,
Intro
In this post I want to share with you some insights in working with SUP Personalization Keys.
Personalization Keys are a powerful feature of SUP, but they might sometimes lead to unexpected behavior when configured inattentively.
So, in this post I would like to discuss a use case that isn't as straightforward as it looks on first sight...
Context
The use case discussed in this blog post is applicable for;
- SUP (I used version 2.1.3 to test the use case)
- Native mobile apps developed with the ObjectAPI SDK
- On Demand Cache Groups
The Idea
The point I want to make is that you should be careful when mapping Personalization Keys to Load Arguments when you are working with cached MBO data.
Consider following setup;
- A SUP with one MBO that follows an On Demand Caching Policy.
- The Cache Interval is 1 hour.
- The MBO retrieves data from the back end using a Load Argument.
- The Load Argument is mapped to a Personalization Key.
- Some of the records in the back end correspond to the first value of the Personalization Key (PK1) and some correspond to the second value (PK2).
- 2 mobile application users are connected to the SUP; 1 user fills in PK1 for the Personalization Key and the other user fills in PK2 for the Personalization Key.
What we observe;
- Let’s say user 1 fills in the value PK1 for the Personalization Key on time t1 and then he synchronizes.
- This action refreshes the SUP cache.
- Then user 2 fills in the value PK2 for the Personalization Key on time t2 and then he synchronizes.
- If the cache did not expire in the meantime he will retrieve the data that was cached in the CDB for user 1.
- This might lead to unexpected results.
If this is not completely clear to you let me explain this step by step.
Step by Step Example
We start as follows at time 00:00;
User 1 is connected to the SUP but has not synchronized yet.
The SUP CDB Cache Database is empty at this moment.
Then User 1 fills in a value for the Personalization Key (PK1) and synchronizes.
As a result, the CDB is filled up with the corresponding Back End records and these records are downloaded to the device of User 1.
Now User 1 fills in another value for the Personalization Key and synchronizes again.
At this moment the CDB Cache has not expired yet.
As a result, the CDB is not refreshed and the data that User 1 receives is still the cached data from the previous synchronization (at 01:05).
This might be a misleading situation for User 1.
Then User 1 fills in another value for the Personalization Key and synchronizes again.
At this moment the CDB Cache did already expire.
As a result, the Back End records that correspond to the value PK3 of the Personalization Key are loaded into the CDB Cache and downloaded to the device of User 1.
(remember, this is because the Load Argument is mapped to the Personalization Key)
Now a second user (User 2) connects to the SUP.
He fills in a different value for the Personalization Key than the value User 1 last used.
After this User 2 synchronizes.
At this point the CDB Cache has not expired yet.
As a result, the records in the CDB are downloaded to the device of User 2.
This might be a misleading situation for User 2.
A while later User 2 fills in another value of the Personalization Key and synchronizes.
At this point the CDB Cache has expired.
As a result, the CDB cache is refreshed with the Back End records corresponding to value PK2 of the Personalization Key.
These records are also downloaded to the device of User 2.
Finally, User 1 synchronizes with a value for the Personalization Key that is different to the one User 2 used last.
At this moment the CDB Cache has not expired yet.
As a result, User 1 receives the data from the CDB Cache (that was last filled up for the value PK2 that User 2 entered at 04:30).
This could be a misleading situation for User 1.
I think by now you get the idea.
If you like to see more examples like these, make sure you don’t miss this webinar on SUP Caching by Example.
Have a nice day,
Wim
- SAP Managed Tags:
