Hierarchical Multi-User Environment

Large AggreGate installations are operated by many people, including system administrators, operators, analysts digging through data and preparing reports, etc. In such a complex environment it's extremely important to ensure security and restrict access to important data.

AggreGate LinkServer may have an unlimited number of user accounts. System resources are usually owned by the user who creates them. User permissions are configured by editing a permissions table defining that user’s access level to every system resource. This lets administrators implement complex security schemes which actually reflect the user’s role in the organization. Some examples:

Allowing one users to access/view/modify devices and resources (alerts, reports…) that belong to another user.
Allowing one user (team leader) to modify permissions of some other users (team members).
Restricting a user's access to his own devices and resources, e.g. enabling read-only access to devices or reports.
Temporarily suspending a user’s account by revoking all permissions.

Every record of permissions table may define user's access level for one resource, several resources or even a subtree of dependent resources, allowing batch configuration.

Configurable user permissions also make life simpler for operators, by allowing them to view only resources that are relevant to their job. For example, the following permission schema is often used for Time and Attendance control system:

System administrator has full permissions.
Company executives have access to reports.
HR staff may view/configure employee profiles and custom shifts.
Security personnel are allowed to view real-time entry/exit events and event history.
IT engineers may edit report templates, create new reports, browse event history and modify employee database.

Every user account has a set of preferences, such as time zone, date/time format and preferred language.

User Self-Registration

User self-registration is very helpful during the first stages of system deployment. System users may create their own accounts and provide some personal information (name, e-mail, company/department, phone no., etc). Once registered, they get their own login/password pair.

Self-registration can save lots of time for the administrator during initial deployment. When system installation is over and it enters production mode, self-registration should be disabled for the sake of security.

Clients

AggreGate Client Desktop

AggreGate Client software can run under any Java-enabled platform, including Windows, Linux/Unix and Mac OS. The main screen can be easily configured for real-time monitoring and data analysis. Dockable windows allow creating custom desktop views and dashboards. Every operator has a dedicated workspace, with a persistently saved window layout.

Client connects to LinkServer via any IP network using a secure connection. In clustered and multi-server systems, Client may maintain simultaneous connections with several LinkServers. Combined with a LinkServer's capability to maintain an unlimited number of client connections, you could build a "many-to-many" distributed system with very high reliability.

Primary components of Client:

System Tree for accessing system resources
Properties Editor for viewing and changing device profiles and system objects configuration
Event Log
Different graphical widgets grouped into a dashboard
GUI Builder user interface editor
Embedded Report Editor
Favourites list for fast access to commonly used actions
Trackers view for monitoring data values in real-time

Real-Time Monitoring

Real-time event monitoring capability is critical for many industries, such as Time & Attendance, Network Monitoring and Access Control. Monitoring current events is one of a system operator’s primary tasks.

The unified data model employed in AggreGate has been designed with event processing in mind. In addition to internal system events, the system learns new event types coming from different hardware on-the-fly. These events are converted to AggreGate events thereby revealing many handling methods.

Events are subdivided into five severity levels: Notice, Info, Warning, Error and Fatal. The essential tool for event monitoring is Event Log of AggreGate Client. It is divided into two areas: Real-Time Events and Event History. The event log provides basic event handling functions, such as sorting, filtering, deleting, acknowledging, and accessing event-related actions.

There are two types of events: transient and persistent events. Transient events may be processed at the moment they are generated (for example, trigger an alert). Persistent event are stored in the server database and therefore may be used for future analysis, charting, report building, etc. All persistent events are automatically purged after a while (configurable).

LinkServer does its best to make all background activities (e.g. device communication failures or e-mail sending) visible as events.

Event Filtering

You can’t monitor events in real time, or analyze event history, without filtering. AggreGate users may create and manage event filters. A Filter is owned by whoever created it, but may be shared between users due to the flexible permissions setup.

Events may be filtered by:

Source (device, a group of devices, system resource, or a group of resources).
Event type.
Minimal level (severity).
Filtering expression used for fine-grained filtering.

Filtering by expression makes event filters extremely flexible. Here are just some examples of how it may help:

Finding events fired within a specific date/time range.
Finding Login events of a specific user (i.e. filtering by username).
Finding all events that contain a certain substring in any of their data fields.
Finding all temperature alerts raised when temperature was higher than 120 degrees.
Filtering events matching condition X and/or condition Y, or more complex combinations.

In addition to the selection criteria, filters include presentation rules:

Visibility of event's basic parameters, i.e. source, type, level and acknowledgements.
Visibility of individual event-specific fields.
Custom expression-based and level-based highlighting rules.

A filter can be made to prompt an operator for certain parameters every time it is activated.

LinkServer distribution includes a set of built-in commonly used filters for viewing all major system events, device events, etc.

Event Acknowledging

AggreGate events may be acknowledged – explicitly accepted by system operators. This is usually not a must. However, some events may be configured to require an acknowledgement.

An event may be acknowledged:

From the Event Log.
By E-mail.
From an alert popup dialog.

Every event may be acknowledged multiple times, even by different operators. The server keeps track of all of these acknowledgements.

If an event was supposed to be acknowledged but did not get acknowledged, its severity level may escalate.

Alerts

AggreGate has an extensive support for alerting, which is one of the essential tools in modern monitoring systems. Alerts notify system operators when something goes wrong in any part of a distributed system. Without alerts, an operator would have to constantly go around the system and click devices just “to make sure everything is OK”. Alerts make sure operators notice what they should notice.

Every user has their own set of alerts. Alerts can also be shared. An alert compises:

Triggers
Notification Rules
Corrective Actions

Alert Triggers

Every alert has one or more triggers defining when to raise it. These can be either event triggers or state triggers.

An event trigger is raised when an event of a certain type conforms to the trigger condition. This condition is flexibly configured by an expression, allowing complex checkings. For example, a vehicle monitoring system may generate an alert if an impact event received from a vehicle controller indicates that impact strength exceeds a threshold.

State trigger can either be raised in response to a certain state, or to any change in the state of whatever is being monitored. State trigger periodically check a device or system property (also pointed by a custom expression). They have a configurable hysteresis time, for activating the alert only if the condition lasts longer than a certain time. For example, a state trigger may raise an alert if the temperature rises over 120 degrees for more than 3 minutes.

Every trigger may check one or more devices or resources. Combined with the ability to set up multiple triggers per alert, this allows for very flexible alerts.

Notification Rules

Alert notifications inform humans about alert conditions and provide related information. Notifications can be in the form of:

Popup messages to the operator. (May also prompt for acknowledgement)
Custom sound.
E-mail notifications (also to multiple recipients). Alerts may be acknowledged by replying to e-mail notifications.
SMS notifications.

In plus, alert's corrective actions may implement any other notification schemes.

Pending Alerts And Alert Escalation

Sometimes, alerts require acknowledgements. Non-acknowledged alert instances are called pending alerts, and are highlighted in orange, to attract an operator's attention.

Alert escalation usually indicates that the situation has become critical. Escalated alerts are highlighted in red. There are two possible rules for escalating alerts:

Quantity-based escalation, when the number of non-acknowledged pending alerts exceeds a certain threshold.
Time-based escalation, when one of the pending alerts is not acknowledged within a certain timeframe.

Both escalation types may be combined for a single alert.

Alert-To-Action Bindings

When a certain error occurs, it often requires one specific remedy. For example, when the available memory on a device becomes low, its internal database must be downloaded or purged. This is always the case – it’s never another action, such as turning the device off or running a servo.

Because this is so predictable, it can be automated. Any system action that is available in the user interface may be automatically launched in response to an alert.

If no operators are on duty or the system functions in standalone mode, the corrective action launched is “non-interactive”. There are also “interactive” corrective actions, which require operator input in real-time.

Some interactive corrective actions:

Running a database purge, asking the operator first “Are you sure?”
Rebooting a mission-critical device only after getting confirmation from the operator

Some non-interactive corrective actions:

Preparing a status report about device caused alert and sending it by e-mail.
Executing an external application that fixes the problem.

Reporting

Reporting is indispensable for applications and systems with highly developed data processing and analisys capabilities. In AggreGate, any internal system data may be used to build a report:

Data coming from hardware devices (e.g. network router interface statistics).
Properties of system resources.
Query results.
Events selected by custom criteria.
Data generated by a script.

It’s simple to build reports. You don’t have to program anything. First, you use the Expression Builder to create a source data expression (for fetching data from the system). Then LinkServer generates a report template for representing this data. Finally, you can use the Report Builder to fine-tune the report and add logos, change colors and fonts, re-format data, etc.

Reports are browsed and printed using the Report Viewer. Reports may be exported to:

PDF (Adobe Acrobat)
RTF (Rich Text Format)
ODT (Open Office)
HTML (Hypertext Markup Language)
XLS (Microsoft Excel)
CSV (Character Separated Values)
XML (Extensible Markup Language)

Report Editor

AggreGate Client has a Report Editor for modifying report templates. It's rarely necessary to create new templates from scratch, as the system generates a default template based on the data being viewed. In most cases, you just have to fine-tune it and make it your own.

The Report Editor operates in WYSIWYG (What You See If What You Get) mode, no programming required. It lets you:

Change report layout.
Modify report sections (title, summary, page header/footer, column header/footer and details).
Edit expressions used to format data (timestamp without seconds, etc.).
Preview the resulting report.

The Report Editor also has:

A set of tools for drawing rectangles, lines, ellipses, text fields, labels, charts, sub-reports, bar codes…
Built-in editor with syntax highlighting for writing expressions.
Support for Unicode and non-Latin languages (Russian, Chinese, Japanese, Korean,…)
Structure browser.
Support for charts.
Drag ‘n drop operations.
Unlimited Undo/Redo.
Suppoer for crosstabs and subreports.
Styles library.

Charting

Data within AggreGate may be used to build charts. There are three basic types of charts:

State-based time charts. These charts show changes in some property over time. Such a chart is updated whenever the property changes. An example would be a Server CPU Load chart, used for network monitoring.
Event-based time charts. Such a chart is updated when a certain event occurs, and its vertical axis shows this event's property. For example, if a Temperature Alert is activated when the temperature exceeds a certain limit, an event-based chart may show all alert temperature measurements.
Custom chart. In contrast to state-based and event-based charts, a custom chart has no time axis. It may be constructed from any data.

Here is just a few examples of custom chart data sources:

Tabular property of a hardware device
Result of a query
Historical events selected by custom criteria

State-based and event-based charts may include:

Historical values for a selected timeframe
Real-time values

Since a chart is a widget component, it can be linked to other components. For example, you can add an update period selector. You can also integrate charts into “dashboard” type HMI interfaces.

Supported chart types:

Pie / Pie 3D
Ring
Bar / Bar 3D
Stacked Bar / Stacked Bar 3D
Line

Some other charting features:

Custom colors, renderers (line, spline, step, bar, etc.), legend, tooltips, gridlines, value marks, and more.
Several data series and axes on one chart.
Configurable time units and ranges for time-based charts.
Real-time mouse zooming, panning, and guideline creation.
Chart context menu for fine-tuning, printing and exporting.

Query Language

AggreGate LinkServer has an integrated query language for retrieving and managing device and system data. It is similar to Structured Query Language (SQL). Most SQL clauses are supported, including SELECT, JOIN, FROM, WHERE, GROUP BY, HAVING, UNION, ORDER BY and LIMIT.

Queries are useful for:

Viewing/editing multiple properties of multiple resources/devices in a single aggregated table.
Finding/filtering some data and trigger and alert if data found matches some condition.
Building a report.
Exporting data to an external system or file.
Sorting and filtering existing tabular data.

LinkServer acts as a large database with many tables. Every property of a device or a system resource acts like a normal database table, and thus can be queried. AggreGate queries are processed under a strict access control model. Your query cannot select data that you’re not allowed to see. Queries may be refined using an internal debugger. A query may also prompt for some parameters before execution.

Update Queries

Unlike classic SQL, AggreGate query language has no INSERT and UPDATE statements. However, query results may be modified using the GUI. For example, if you select several properties of several devices in a single table, you can edit the cells of this query and all modified data will be written back to its original location.

Trackers

Trackers help watch mission-critical server data in real-time. All trackers are shown together in a single table to enable efficient monitoring. Each tracker is based on an expression which may refer to some server data or to data originated from hardware devices. A simple expression may be used to monitor some value directly, while a more complicated one can track a combination of several values. For example, a tracker can be easily set up to watch dew point temperature calculated by temperature and absolute humidity measurements coming from different sensors.

Tracker status lets system operators quickly check the state of a tracker by highlighting it in the trackers list. Statuses can help detect trackers that indicate warning and critical conditions of the monitored values. It is possible to associate an unlimited number of user-defined statuses with every tracker.

The value of each active tracker's expression is recalculated periodically. Stateless and disabled trackers may be optionally hidden from the list.

Job Scheduler

LinkServer’s job scheduler lets you periodically execute any device management or system task, such as:

Checking device status every two hours and running an external application in the case of problem.
Purging device internal memory every Sunday at 4:00 AM.
Sending an attendance report by e-mail on the 2nd and 17th of every month at 4:00 PM during 2009 and 2010.

Any operation available within AggreGate may be scheduled for periodic execution. If the operation is interactive and requires user input, input parameters may be pre-defined during scheduling. When the server is restarted, the scheduler can detect if any scheduled jobs were missed (not launched) while the server was down.

There are two types of schedules:

Simple schedule. According to a single simple schedule, the action is executed for a set number of times with a fixed interval. It is also possible to specify start and end of time interval when the execution may take place.
Advanced schedule. Advanced schedule allow complex execution patterns like "execute every minute starting at 2pm and ending at 2:59 PM, every day" or "execute at 10:15 AM on the last Friday of every month during the years 2009, 2011, 2013 and 2015".

Grouping And Group Operations

Groups are used to combine several similar devices or system resources (event filters, alerts, etc.) to make batch operations more convenient. It is easy to execute an operation over all objects in a group (e.g. reboot ten devices at once). Groups also provide an easy way to set similar settings to all group members or automatically replicate configuration changes between them.

Groups are also integrated with the Common Data facility. This means you can have "master" values for group member properties. Changes of master value are automatically applied to all group members.

Replication Of Configuration

AggreGate supports data cloning, copying and replication procedures:

All data cloning, moving, copying, and replication operations can be performed on any system resource (alerts, etc.), as well as on hardware device settings.

Moving/copying resources and device profiles between user accounts.
Full or partial replication of configuration between system resources and hardware devices.
One-to-many replication, i.e. copying settings from one device/resource to a group.
On-the-fly fine-tuning of the replicated settings and properties.
Support for replication of settings and properties between differing devices (different firmware versions, etc.).
Comprehensive replication status reports.
Automated replication of configuration between devices within group, i.e. any change to one device is automatically copied to the others.
Master copies of device settings. Changes to the master copy are applied to every member of the group.
Copy, move and replication by drag and drop.
Strict permission control during every operation.
Caching and delayed writing mechanism allow replication to devices that are currently offline.

Common Data

Common Data is a custom data storage facility that may be used by various AggreGate components to perform specific operations, such as data replication, data sharing and configuration management.

The common data container is like a database. You can:

Create tables
Remove tables
Define and modify table structure
Preview and edit data

Data containers may either be global, shared between all system users, or personal – owned by a certain user account. Users may share personal containers by setting up proper access permissions.

Common Table Fields

Uses of common data:

Custom Data Storage. In this case, common tables are created by the system administrator manually, from scratch, to contain some custom data that is not automatically generated or used by LinkServer components. This can be, for example, an inventory of equipment belonging to the company. This table may contain the description and location of each piece of equipment, the person responsible for it, etc. The administrator could allow users to view or edit it. It could then be referred to from different parts of the system. For example, you could create a query showing which pieces of equipment are under the responsibility of every system user.
Integration With Groups. In this case, the common table contains a "master value" for a certain property of all group members. The group monitors the common table for changes. When a change is detected, the related property is updated for all group members.
Integration With Devices. Like in the previous scenario, the common table contains a "master value" for a certain property of several hardware devices. LinkServer monitors changes in the common table and when these changes are detected it takes the "master" common table and copies it to several devices.

Favourites

Favourites allow system operators to execute commonly-used operations with a single mouse click. You don't have to "dig" in through the system tree – you can have instant access to whatever you use the most via the favourites, which work like "shortcuts" or "quick links" leading to various resources and devices.

In the AggreGate Client, when a workspace contains several server connections, the favourites are collected from all server connections and displayed in one unified table. This lets you use just one a single Favourites table to navigate all over your entire "AggreGate Universe".

Favourites support grouping. This means one click on a single favourite may launch the same operation for several devices/resources at once.

Auto-Run

The Auto Run feature allows operations to be executed automatically when an operator logs into a LinkServer User Interface, such as AggreGate Client. They’re useful for creating dashboards, which are sets of widgets automatically displayed in pre-set positions as soon as a user launches client application. Another use would be an automatic checking of the status of a particular mission critical device.

Auto-Run operations are executed in the user-defined order. They can be suspended (without being removed).

Interactive Guides

AggreGate isn’t always trivial to master. You have to understand how the system works, grasp the terminology and gradually figure things out.

In other words, you will probably have to read at least some of the manual before you can reap some of the benefits of this unique system.

Alas, not everyone enjoys reading in-depth technical documentation (how surprising!). Some people like to learn by simply running the program and clicking around until something happens.

With such people in mind, we created the AggreGate Interactive Guides. This is a fairly unique feature: When the Interactive Guide is on, you get a small window with some instructions and explanation. The guide then “watches” what you do, and when it detects you’ve performed the step described, it moves on to the next step automatically, showing you what to do next.

You can think of the Interactive Guide as a tech supporter, looking over your shoulder and making helpful comments as you work. It's not an animated paperclip, though, and we promise it won't try to make friends with you.

Link Service

Under normal circumstances, on a WAN, communicating with another node (host) on the network can be difficult due to the following factors:

Scarcity of Static IP Addresses

IP addresses on many networks (especially, the Internet) are now in short supply. This gave rise to several technologies that allow you to use available IP addresses more economically. Some examples of these technologies include:

Dynamic IP addresses, whereby IP addresses of the hosts change from time to time,
NAT (Network Address Translation) whereby several hosts communicate with the outside world through a single "external" IP address on a gateway.

These technologies allow for each host to make outgoing connections (for example, to visit a website). However, it may be difficult (or actually impossible) to establish an incoming connection to such a host -- you either don't know its current address (because it's dynamic), or it doesn't even have an external address of its own.

The only standard solution to this problem is to assign a static IP address to each host you need to connect to. These static IP addresses have to be obtained first. For example, you might need to lease them from your ISP. A single IP-address wouldn't cost much but when a given system is to have many nodes you end up spending considerable amounts of money. Even when the WAN is private and IP addresses are free, there are administration costs related to allocation of static IP addresses.

Firewalls blocking inbound traffic

Even assuming one has obtained necessary number of static IP addresses, there is still one more challenge: you have to actually connect to the Device Server. This may mean passing through firewalls. Firewalls usually restrict inbound traffic, so you will need to arrange opening ports, etc. This requires more work and increases the chances for possible security breaches (the more internal IP addresses or ports accessible from the outside, the greater the risk).

One possible solution to this is to configure all of the Device Servers for outbound connections, and have them connect to one specific network host. This could save leasing multiple IP addresses, so you would just need a single IP address for this host. Unfortunately, this also means that just this single host would be able to communicate with your Device Servers, as it would be configured as their destination. As you can see, this solution, too, is not an ideal one.

So, what is the best way to interconnect Device Servers and their "client" hosts, when they are on different network segments, located behind firewalls, and have no static IP addresses? It is called Link Service.

Link Service

It is usually much easier for a network host to connect out than to accept an incoming connection. Unfortunately, with a normal link, at least one side must accept an incoming connection.

Tibbo LinkServer provides a workaround for this problem by letting both sides of the link to communicate through a "middle-man" (Link Service), to which they both can establish outbound connections.

When you and your friend use ICQ or MSN, you both connect to a central server. Neither of you typically has a static IP address, but the server has a static IP -- and this is what lets the "magic" happen. Both parties make outbound connections, so no firewalls have to be configured and neither side needs a static IP.

The Link Service is a very similar solution, only it is tailor-made for Tibbo Device Servers! Your Device Servers in the field connect to the Link Service (make outbound connections). Hosts that wish to communicate with Device Servers also connect to the LinkServer using outbound connections. Both sides meet 'at' the LinkServer and can thereby communicate through it.

Dynamic DNS Service

The downside of the Link Server is that it is slower than direct connection, because all the data must go through the LinkServer.

This isn't critical for systems that do not produce a lot of traffic per each node. Still, there are times where you might want to create a direct connection to a device (for the sake of speed), but the IP address of this device changes from time to time (as is the case with most ADSL connections).

You need a way to track the device down -- a way to overcome this and connect to one 'stable' address. You need to know that this address belongs to the Device Server you want, and be able to rely on it.

This is where the dDNS Service comes in. With dDNS Service each of your Device Servers gets a "host name", which looks something like dev1.abccorp.dev.srv1.com (in this example the domain name of your server is srv1.com). You can always connect to your device using this hostname. This URL stays the same even when the IP address of the Device Server changes.

Since the actual connection is established directly to the Device Server you would have to be able to reach it -- i.e, if it has a firewall protecting it, the firewall must be appropriately configured. Configuration would be more complex than with the Link Service, but you would gain an increase in communications speed.

In Dynamic DNS mode, Device Servers connect to the LinkServer on startup only, after obtaining IP address from DHCP server. After their registration in DNS they break connection with the LinkServer and act exactly as "normal" Device Servers, having no relations with LinkServer and other parts of AggreGate. In contrast to Link Service mode, no connection between Device Server and LinkServer is maintained. No data is transferred through the server.

HTTP Proxy Service

Let's say you have hundreds of Device Servers with embedded web servers, with each such Device Server providing access to a number of web pages. It is very easy to access every embedded Web Server when all of them have real static IP addresses. However, in real life, most Device Servers are installed in local networks protected by firewalls, and static IP addresses cost money. In this case, there is no way to access these Device Servers directly. The HTTP Proxy service solves this problem by providing a generic way to access all embedded web servers through LinkServer. It works like this:

A Device Server with an embedded web server connects to the LinkServer. Its account should be configured to use HTTP Proxy mode.
Someone wants to see the web pages from this particular Device Server, so they start a web browser and surf to a URL such as http://linkserver.bigcompany.com/dev/admin/dev1/data.html.
The HTTP request sent by a browser is received and processed by the LinkServer.
LinkServer redirects the HTTP request to the admin.dev1 Device Server, to which it is currently connected.
The Device Server processes the request and sends the data.html page to the LinkServer.
LinkServer forwards this page to the browser.