The real-time data is provided either by the URL specified as dataStreamURL attribute or by the Flex API. This streaming-data format should essentially be in text format WITHOUT containing any HTML tags or carriage returns. Here, we'll explain the required format.
The real-time data format for gauges is very simple. Normally, only one value is to be passed. Just for angular and linear gauge you can have multiple dials/pointers.
The format of real-time data for gauges depends on:
Let's quickly go through the examples for each one of them.
In the simplest form, if you're looking to update the value of a gauge, you need to output the data in following format:
&value=34
Here, we're just outputting a single value 34. So, when FusionWidgets would read this value, it would update the gauge by setting its value to 34 (if the data is within range).
If you've multiple dials defined in angular gauge or multiple pointers defined in linear gauge, you can update them all in a single update by outputting the following from real-time data provider page:
&value=34|25|54
Here, we're specifying three values in the real-time update. So, assuming that we've 3 dials or pointers defined in the gauge, each one of them will take the sequential value and update itself. That is, the first dial would display 34, second one would display 25 and the third one 54. The sequence of dial is determined by its order in XML data document.
In angular gauge & linear gauge, FusionWidgets allows you define the ID for each dial or pointer as under:
In angular gauge:
<dial id='CPU1Temp' ..../>
<dial id='CPU2Temp' ..../>
In Linear gauge:
<pointer id='CPU1Temp' ...>
<pointer id='CPU2Temp' ...>
You can now update each of these named dial/pointer by outputting the following in your real-time data stream:
&CPU1Temp=23&CPU2Temp=34
This will change the value of dial 1 (with id as CPU1Temp) to 23 and dial 2 to 34.
To stop the gauge from polling the server for any more real-time updates, you need to send the following command from server to do so:
&stopUpdate=1
After stopping the update, it can be restarted either using user interaction (right click context menu) or using client side JavaScript.
The gauges can display message logger like data streaming gauges. There are various parameters, which you can specify for message logger. All of them have been explained in the section "Message Logger".
Consider a scenario where we're plotting a live CPU monitor using FusionWidgets real-time HLED gauge. In this system, we asume that the CPU Usage change is recorded in every 10 seconds. But, to efficiently consume bandwidth, we stream this data to the gauge in every 90 seconds.
To set the refresh interval, we've set the initial XML as under:
<chart dataStreamURL='Path/DataProviderPage.aspx' refreshInterval='60' ...>
Now, DataProviderPage.aspx is responsible for providing the CPU usage statistics. Each time it is invoked, it needs to provide 9 historical values (as the gauge calls this page in every 90 seconds, but data is updated in every 10 seconds in the system).
In traditional systems, DataProviderPage.aspx would have to keep a track of "What data was last sent to gauge?" using either Session variables or by storing the same in database. This can be a bit cumbersome in a stateless environment - as in server farms. Sessions won't scale well. Utilizing database for this purpose entails a lot of additional code, as you'll have to store the details for each connected user.
FusionWidgets introduces a smart feature that helps you easily overcome this - Data stamp. Data stamp is basically a token of information that is passed with each update to the gauge and back to the server, which helps in easily identifying "What data was last sent to gauge?".
Let's see it in action.
In our case, we would ideally like to do the following:
To set the initial data stamp, you need to set the following in XML:
<chart ... dataStreamURL='DataProviderPage.aspx' refreshInterval='90' dataStamp='13:43:45' ...>
As you can see above, we've added the data stamp as time, which is "13:43:45" in this example. In every 90 seconds, the gauge will call the following URL:
DataProviderPage.aspx?FCTimeIndex=35454&dataStamp=13:43:45
Here, you can notice that dataStamp is added to the URL. FCTimeIndex is a parameter that is added by gauge to avoid caching issue.
Your code in DataProviderPage.aspx can now request this datastamp and then provide the values occurring after this time. Additionally, after providing the 9 values (for last 90 seconds) your DataProviderPage.aspx needs to update the datastamp by providing the time of the last CPU reading. So, the data output by DataProviderPage.aspx would read something as:
&label=13:43:55,13:44:05,13:44:15,13:44:25,13:44:35,13:44:45,13:44:55,13:45:05,13:45:15|
value=34,23,65,34,23,65,34,45,34&dataStamp=13:45:15
In the above output, we're providing:
Once this update reaches the gauge, it will update itself to plot the 9 new values and would also update its datastamp. Next time when the gauge invokes DataProviderPage.aspx, it will invoke the following URL:
DataProviderPage.aspx?FCTimeIndex=37564&dataStamp=13:45:15
Note, how datastamp is updated to the one specifed by real-time update. This helps to update the datastamp constantly and thereby, keep a track of the last data sent to gauge.