FusionCharts for Flex > Creating Widgets > Real-Time Capabilities > Streaming Data Format

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.

Real-time data format for gauges

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:

  • Whether you've multiple pointers on the gauge (in angular/linear) or a single value (cylinder/thermometer/bulb/LEDs)?
  • If you've multiple pointers, whether you want to provide data by pointer numerical index or by their defined IDs?
  • Whether you're using Message Logger for the gauge?
  • Commands for the gauge - like stop update

Let's quickly go through the examples for each one of them.

Simple Example

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).

Updating multiple pointers

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.

Updating using named ID of the dial/pointer

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.

Stopping real-time updates from server

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.

Sending messages pertinent to Message logger

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".

 

Adding data-stamp

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.

Motives

In our case, we would ideally like to do the following:

  1. When the gauge is first rendered, we would like to provide the initial date/time as data stamp in XML, so that the gauge can pass this to data stream URL page (DataProviderPage.aspx) as querystring.
  2. The data stream URL page (DataProviderPage.aspx) will now request this stamp (date/time in this case) from querystring and provide any CPU data recorded after that time as output data. After building the data string, it will also append the updated data stamp, which is the date/time of the last data provided.
  3. The entire data and stamp is now being sent to gauge as real-time update.
  4. The gauge will now read this data, update the view and then update its own data stamp.
  5. Again when the gauge polls for real-time data, it will now append the updated data stamp to dataStreamURL and request data. Steps 2,3 and 4 will now recursively occur.

Setting it up

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:

  • Label for the 9 values
  • Value for the same
  • Updated data stamp, which is date/time of the last value provided in this update

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.