I have created more complex and complete Active Data Service example, based on the one posted in the previous post - Simple Example for ADF Active Data Service. Updated sample application is using JDBC to listen for updates in the DB. Updates counter is refreshed through ADS and displayed to the user. This sample is tested with Oracle XE 10g, you only need to grant change notification to the the user connecting from the data source.
If you want to see more detail runtime output for the sample application - LongRunningTaskPushApp_v2.zip, make sure to enable following ADF logger classes:
I would like to start explaining, how Model and ADS parts communicate. There is interface defined, this acts as a bridge between DB push controller and ADS engine to push refresh changes to the UI:
ADS controller class (the one responsible for ADS push logic), implements defined interface:
Push mechanism is started automatically by ADS framework, framework method startActiveData is invoked. Inside this method, we create new instance of DB push controller and pass instance of ADS controller (the one implementing interface):
DB push controller in turn starts listener for DB change notifications. You must execute select from DB table, the one you want to listen:
ADS provides method, this method is invoked automatically when ADS is deregistered - we are stopping DB push controller from here:
Here I'm running the test now. There are two different session, I change data in the first session and save to the DB:
As this changes is saved to the DB, it is propagated across all sessions registered with ADS - we can see new change number is available:
I can click Synch Changes - to re-execute ADF BC and bring all the latest changes in the current session, you can see changes count is reset to 0. Do a change again and press Save:
You are going to see change incremented in the second browser session, as it was not synchronised previously. It means - we had two updates in the DB, and currently displayed data needs to be synched:
From the ADF log we can see that when new browser session is opened, firstly it starts new ADS thread and then registers DB change push controller with DB notification listener. DB changes notifications are logged. At the end, when browser page with ADS support is closed, ADS thread is stopped automatically, it stops DB push controller and deregisters DB notification listener:
Once user clicks on Synch Changes link, we call action listener from ADS controller bean, where we set latest synch time and reset counter by pushing this change through ADS update event:
Latest synch time variable is referenced from ADF task flow parameter:
ADF task flow is set to refresh - ifNeeded, this means it will refresh automatically each time, when parameter is changed (to synchronise changes from DB using ADF BC):
If you want to see more detail runtime output for the sample application - LongRunningTaskPushApp_v2.zip, make sure to enable following ADF logger classes:
I would like to start explaining, how Model and ADS parts communicate. There is interface defined, this acts as a bridge between DB push controller and ADS engine to push refresh changes to the UI:
ADS controller class (the one responsible for ADS push logic), implements defined interface:
Push mechanism is started automatically by ADS framework, framework method startActiveData is invoked. Inside this method, we create new instance of DB push controller and pass instance of ADS controller (the one implementing interface):
DB push controller in turn starts listener for DB change notifications. You must execute select from DB table, the one you want to listen:
ADS provides method, this method is invoked automatically when ADS is deregistered - we are stopping DB push controller from here:
Here I'm running the test now. There are two different session, I change data in the first session and save to the DB:
As this changes is saved to the DB, it is propagated across all sessions registered with ADS - we can see new change number is available:
I can click Synch Changes - to re-execute ADF BC and bring all the latest changes in the current session, you can see changes count is reset to 0. Do a change again and press Save:
You are going to see change incremented in the second browser session, as it was not synchronised previously. It means - we had two updates in the DB, and currently displayed data needs to be synched:
From the ADF log we can see that when new browser session is opened, firstly it starts new ADS thread and then registers DB change push controller with DB notification listener. DB changes notifications are logged. At the end, when browser page with ADS support is closed, ADS thread is stopped automatically, it stops DB push controller and deregisters DB notification listener:
Once user clicks on Synch Changes link, we call action listener from ADS controller bean, where we set latest synch time and reset counter by pushing this change through ADS update event:
Latest synch time variable is referenced from ADF task flow parameter:
ADF task flow is set to refresh - ifNeeded, this means it will refresh automatically each time, when parameter is changed (to synchronise changes from DB using ADF BC):
4 comments:
Good stuff. Very clear, quite useful. I like the way you have automated the refresh of the taskflow to resynch with the database.
kind regards
Lucas
Thanks Lucas :)
Really cool stuff ! Thanks, Andrejus !
Very useful!!! great post
Post a Comment