Oracle Offline Persistence Toolkit — Controlling Online Replay
Coming back online. Check out this application of a previous article that demonstrates how to test the online replay functions of an application.
Join the DZone community and get the full member experience.
Join For FreeA few months ago I had a post about Oracle Offline Persistence toolkit, which integrates well with Oracle JET (JavaScript toolkit from Oracle) — Oracle JET Offline Persistence Toolkit — Offline Update Handling. I'm back to this topic with a sample application upgraded to JET 5.1 and the offline toolkit upgraded to 1.1.5. In this post, I will describe how to control online replay by filtering out some of the requests, to be excluded from the replay.
The source code is available on GitHub. Below I describe changes and functionality in the latest commit.
To test online replay, go offline and execute some actions in the sample app — change a few records and try to search by first name, and try to use page navigation buttons. You will be able to save changes in offline mode, but if this is your first time loading an app and data from other pages wasn't fetched yet, then page navigation would not bring any new results in offline mode (make sure to load more records while online and then go offline):
In the online replay manager, I'm filtering out GET requests intentionally. Once I go online, I replay only the PATCH requests. This is done mainly for testing, to learn how to control the replay process. PATCH requests are executed during replay:
Printing out in the log, each GET request was removed from the replay loop:
Replay the implementation (I would recommend reading the Offline Persistence Toolkit usage doc for more info):
This code is executed, after transitioning to online status. Calling the getSyncLog
method from Sync Manager returns a list of requests pending replay. Promise returns function with array of requests waiting for online replay. I have marked the function to be async, which allows it to implement a sequential loop, where each GET request will be removed one by one in order. This is needed, since removeRequest
from Sync Manager is executed in promise and the loop would complete too late — after we pass execute replay phase. Read more about sequential loop implementation in JS, when a promise is used — JavaScript — Method to Call Backend Logic in Sequential Loop. Once all GET requests are removed, we execute the sync method to force all remaining requests in queue to be replayed.
Published at DZone with permission of Andrejus Baranovskis, DZone MVB. See the original article here.
Opinions expressed by DZone contributors are their own.
Comments