Using Auto Refresh

The Auto refresh feature introduced in version 2.3 enables one or more Omniscope Professionals (this feature is not supported in Standard Edition or the free Viewer) to view continuously-changing data 'broadcast' from a Source .IOK file running on an always-on server or another desktop installation of Omniscope Professional. Auto-refresh can be implemented between a Source .IOK file and any number of User client installations over a local network or the open web.

The discussion below covers first the client-side Omniscope User file configuration, then discusses some of the options for configuring the server-side Source .IOK file refresh arrangements.

Client/User-side Configuration

The User .IOK files distributed to the client desktops are modified copies of their Source .IOK, and have the same auto refresh behaviour configured. This new feature tells Omniscope to watch for changes to the Source .IOK file currently open. When a change occurs to the data set in the Source.IOK file (such as another user, or the server, updating and saving it), each open, activated User Omniscope automatically reloads the latest data set from the Source .IOK file.

Using auto-refresh is not the same as delivering and re-opening an updated .IOK file. Auto refresh only loads updated data in the already open file. User views and preferences are not be reloaded to avoid interrupting the Users' current workflow in Omniscope. Whenever the Users' Omniscope becomes idle (i.e. they stop using Omniscope for a few seconds) the Users' current filtered views will be updated to show the latest data.

To set up or modify the User file settings, choose Tools > Automatic refresh. This reveals the Auto refresh drop-down menu  on the Main Toolbar and starts the polling process.

When an update is available, this button will appear highlighted with the text 'Update available pending'. If you are busy using Omniscope and an update is retrieved, clicking Display latest update will display the newest available data. Clicking the little drop-down arrow shows a menu which allows you to configure auto refresh options and which indicates status. From this menu, you can start and stop the automatic refresh checks by ticking Polling enabled. You can also turn a sound on/off when an update becomes available, and suppress error reporting.

Selecting Refresh by reload is the behaviour outlined above; alternatively, if users have access to the source database, you can use Refresh from source which will continuously hit the data source for the current data.

Timings allows you to customise the rate at which the User Omniscope instances check for updates and other timings. You can configure the interval between update checks (this is how often Omniscope looks to see if the file has changed; if so, it is immediately retrieved). You can configure the interval between a failed update/retrieval and a retry, as well as the number of retries permitted (errors are only reported if all retries fail).

You can also add a randomisation to these timings, if desired, allowing you to scatter network bandwidth and file access and reduce any congestion that might otherwise occur if all clients attempt to update at the same time.

Errors can occur when using automatic refresh if the server is in the middle of updating the file when Omniscope attempts to retrieve it. We have built in several measures to address this problem. IOK files are locked, which, for supported operating and file systems, prevents two processes accessing the file at the same time. Automatic retry-on-error is also configurable, as are randomised cycle timings.

Server-side configuration

The server side of the live data automatic refresh functionality can be configured many different ways. Below is a general approach based on Omniscope Enterprise Edition running on an always-on server with the Scheduler enabled and with direct access to the source database.

On the server are two .IOK files:

• The Source .IOK file is created by populating and then refreshing a configured template .IOK file created and edited by a person designated as the Publisher/File Administrator. This person sets up and maintains the overall look and functionality of the Template file, configures Report Pages and links, etc. Only the Publisher/File Administrator and the Omniscope server process have read/write access to this file.
• The User .IOK file is automatically produced by the Omniscope server as a copy of the Source .IOK file with some automatically applied different settings. Users (viewers) of this file have read-only access to this file alone. Users with free Viewers will be able to open and view the file, but the auto-refresh feature will not be available.

Typically, there will be scheduled processes that combine data from different sources and update a central database from which the Source file reporting views/tables are drawn. Whenever the Source database view(s)/table(s) are updated, the Omniscope server installation is invoked to update/refresh the Source .IOK file from the database.

Scheduling can be done in various ways, and at any interval...we have client installations that refresh the Source file on a 30-second cycle time. Auto-refresh to the User file clients does not have to be on the same cycle time as the refresh of the Source .IOK file.

Assuming you wish to use the Scheduler included in Omniscope Enterprise, you would start the Scheduler from the Visokio Program folder or Tools > Advanced Tools > Start Scheduler (Enterprise Edition only). More on using the Scheduler.

Using the menus available in the Scheduler, the Omniscope server task is represented as an XML Action, usually a Refresh from Source operation. This action opens the Master .IOK file and does the following:

1. Refreshes data from source database
2. Saves the Source .IOK file, so it is maintained up-to-date for the Publisher
3. Updates the file listing location, adding a time stamp to verify the process is working well.
4. Unlinks from source, as Users won't have direct access to the database
5. Saves the User .IOK file in one or more locations; e.g. a network share, or web root for HTTP access.

Faster Scheduler

The Visokio Scheduler can now be used in a 'non-forked' mode. This won't be applicable if you are using your own scheduling system; however, if you do choose to use the Scheduler, you can now choose non-forked task execution.

In the Scheduler settings dialog, Fork scheduled execution, when un-ticked, allows scheduled tasks to execute in the same Java VM process as the Omniscope scheduling loop. This avoids the JVM startup time which can save over 10 seconds. Additionally a timings option has been added to "chain action" and "file action" allowing you to analyse performance. For more information, see Using the Scheduler

Executing Non-scheduled XML actions

Warning: The Scheduler must always be running for this to work. You can now configure this as a Windows service.

In case you want to use your own external trigger, rather than the time-based Scheduler, to execute XML Actions scripts you have defined, below we describe how to author your own XML Actions file and deliver it to the Scheduler for immediate (rather than time-based) execution.

You can edit or create XML actions using Tools > Advanced tools > Edit Enterprise Action Descriptor. You can also edit the XML directly, although this is not recommended in most cases as the Visokio  user interface for editing has guidance information.

The Omniscope Scheduler now includes other processes as well as the scheduling loop. One of these is the new "watch folder" process. This process watches a folder continuously while the Scheduler is running. To execute an XML action file on demand, copy it into the watch folder, typically:

C:\Program Files\Visokio Omniscope\scheduler\watch

Assuming the Scheduler is running, this file will immediately be executed then deleted. After testing, refer to the Scheduler log to check for errors:  'http://localhost:24679'/

If you are repeatedly testing changes to a file, be careful to copy and not move the XML file to the watch folder, as it is deleted after. Also be sure to refresh the web browser showing the log frequently to check for errors.

Note: trigger files dropped into the watch folder are executed in sequence and in no specific order, using the same JVM as the Scheduler. It is not currently possible to execute multiple tasks in parallel.

Back to Integration options