Data updates are performed using the MessageBus implementation of CDP4-COMET SDK on the following occasions:

• Refresh button in the Session group of the Home menu tab.
• Reload all data button in the Session group of the Home menu tab.
• Refresh at specific intervals using the Auto Refresh options in the Session group of the Home menu tab.
• When the user saves data to the CDP4-COMET Webserver

Refresh Button

When the user clicks on the refresh button in the Session group of the Home menu tab, the CDP4-COMET IME queries the CDP4-COMET Webserver to get all changes that were made after the last data load.

Reload All Data Button

When the user clicks on the Reload all data button, all data is queried from the CDP4-COMET Webserver and all data will be renewed

Refresh at specific intervals

When the user checks the checkbox to allow automatic refreshes for the selected Session, a timer will be created that will automatically query the CDP4-COMET webserver to retrieve data that was changed since the last time data was updated for the selected Session.

User saves data

When the user performs any data update, the CDP4-COMET Webserver will automatically retrieve all changes since the last time data was retieved from the server.

MessageBus

Data updates visually are updated in the UI based on subscriptions to specific data changes, using the CDP4-COMET SDK's CDPMessageBus. After every Write or Read notifications (events) are pushed to the MessageBus. In the CDP4-COMET IME, subscriptions to these events are created that implement logic to be performed when a Thing, or Type of thing is changed. Other, non data change notifications/events might also be subscribed to, like the SessionBeginUpdate and SessionEndUpdate events. These events could be used to bring the UI in a state where data changes can be handled to update the UI, without excessive repainting of the UI. Repainting is then only performed when all changes have been handled.

Changes outside the Begin-/EndUpdate mode

A special edge case, when updating data in Begin-/End Data Update mode, comes from the nature of handling subscriptions to CDPMessageBus events in a WPF application environment. Typically handling of Subscriptions is done on the UI thread, which has its own implementation of the order in which subscriptions are handled. In general, every CDPMessageBus event has its own pipeline where all notifications are sent to. Every first notification is handled almost immediately when the notification is sent. After the first subscription has been handled, the UI thread pauses execution of other notifications that might have been sent and therefore queued to the specific pipeline. In the case of any refresh, the following actions are performed:

• Add Session StartUpdate notification to its specific CDPMEssageBus pipeline
• Add object changed notifications for all changes to their specific CDPMEssageBus pipelines
• Add Session EndUpdate notification to its specific CDPMEssageBus pipeline

Normally in the CDP4-COMET IME, based on the StartUpdate notification, the UI is set to a special "DataUpdate" mode that optimizes repainting of the related Browser. Then refreshes based on Thing changes are handled. After this, based on the EndUpdate notification the UI is taken out of "DataUpdate" mode and the Browser will be refreshed, keeping the state of the UI (scrollbars, selected row) as it was before the data updates were performed.

If we go back to the fact that the UI thread pauses execution of every next notifications that is queued on an individual pipeline, this results in every next notification on an individual pipeline to be executed AFTER the UI was taken out of "DataUpdate" mode. This results in heavy repaints of browsers for all these "next notifications" on individual pipeline.

As creating a pipeline for a specific type of change is memory extensive (especially when a model contains a lot of data) most of the frequently used browsers implement a system that creates a pipeline on the Type of thing to subscribe to and not a pipeline for a specific Thing. That means that if in a data refresh, multiple Things of the same type have changed, multiple change notifications are pushed to a single pipeline. In that case only the first one would be handled during the "DataUpdate" mode and all subsequent notifications would be handled outside the "DataUpdate" mode. Usually this is not a big problem, but when models start growing, the extra delays will become noticeable more and more.

That is why the End DataUpdate notification is, since CDP4_COMET IME version 10.0.4, executed with a delay. The handler of the subscription is added to the Main Thread scheduler, which gives all next notifications in all pipelines the opportunity to execute their subscriptions. When all is done, the thread scheduler will execute the delayed End DataUpdate handler.