Edge Documentation

This page answers Frequently Asked Questions (FAQ) about AppBoard features.

For FAQs about enPortal features, see the enPortal Features FAQ

AppBoard Features

Can AppBoard associate aggregated data queried from multiple data sources in a single widget?

Most or all AppBoard Widgets are capable of displaying data that comes from multiple Data Sources. Here are just a few examples:

• A Widget uses data from a Database Query Data Source where the SQL statement in the query configuration is pulling data from multiple associated tables in the raw source data.
• A Table Widget displays columns of data from one source and a sparkline column with data from another associated source.
• A Topology Widget shows data from multiple Data Sources, linked by associations between the Data Sources.
• A Stacked Widget cycles between display of several Widgets, each coming from separate Data Sources.

Note that many of the above examples include the use of associations, which are fully configurable on the Associations screen in the Data Source wizard. How you make use of these associations does vary depending on the type of widget and the capability that you are making use of. For the cases where an association cannot provide the aggregation you need, you can create Data Processing Scripts that aggregate the data as it is coming in to AppBoard.

In many cases, there are multiple ways to achieve the above type of results. Some will be more efficient or easier to configure than others. If you have specific requirements you are looking to achieve, Edge's Solutions team can review them and work with you to implement them.

What is the maximum number of client connections, data sources, or web integrations a single AppBoard server can reasonably manage?

The scalability of AppBoard is related to the number of queries per second and the total size of the cached records from all sources, while the scalability of enPortal is related to number of page views per second. AppBoard is able to cache data for any data source that is shared between multiple users (e.g. does not require user-specific credentials or parameters to query), and this greatly reduces the load on the AppBoard server and on the backend resources. For a 4GB Xeon server, a typical configuration for AppBoard having five shared data sources and five user-specific data sources updating once per minute, and a total size of 1 MB of data per user, AppBoard would scale to at least 150 concurrent users before memory or CPU utilization create bottlenecks. With the ability to share most or all data sources (which is typical of most deployment), this number can be much larger. enPortal is responsible for the web integrations, and the scalability of these are more variable and dependent on the complexity of the specific integrations used. Typical integrations allow between 5 and 25 integration page requests per second before CPU utilization becomes a choke point. With a typical user making three page views per minute and a conservative estimate of 5 integration requests per second, enPortal should handle 150 or more concurrent users on the configuration specified. The core user model supporting both enPortal and AppBoard can support effectively unlimited users who are not logged in.

Can I configure a "kiosk mode" where AppBoard will automatically rotate between Boards without any user interaction?

"Kiosk mode" or "Auto-rotation" is a common feature for AppBoard deployments on big screens in Network Command Centers.

For detailed instructions on implementing this customization, see Kiosk Mode.

Can I export dashboards for use outside of AppBoard?

There may be value in re-using an existing Stack for another project, to save the effort of re-creating the Stack from scratch. The Import/Export feature allows the AppBoard administrator to save any or all of the Boards, Widgets, and other settings to an external file so that they can be imported directly into another project.

For instructions on using this feature, see Import/Export.

Is multi-tenancy supported?

Multi-tenancy is the concept of supporting data for multiple customers in the same system. It is an important feature of AppBoard, because it allows a company such as a Managed Service Provider to create a single solution to apply across an entire customer base. This is more efficient than creating a separate system for each customer.

AppBoard supports multi-tenancy through the concept of Domains. When Users log in to view dashboards, in addition to providing their username and password, they also supply a value for the Domain variable, which can be used for securely segmenting the data by Domain. This ensures that users are only seeing data they are authorized to see within that Domain. AppBoard applies multi-tenant support to underlying systems that do not natively support it, and provides the ability to show secure, segmented views of information from the same application to different users.

Can I view my dashboards on mobile devices?

AppBoard provides support for Apple iOS and Android mobile devices through native applications. These native apps provide mobile-centric views of the same content that is available through the desktop web interface. The mobile client uses the very same configuration and data as the desktop client and therefore requires no extra configuration, but creating a mobile-specific view of data can provide extra benefits. The mobile clients support a wide range of the widgets in AppBoard, but some are not available due to device, screen size, and licensing limitations.

More detail on mobile features and configuration is available at AppBoard Mobile.

Can AppBoard run across multiple monitors, where one Board is shown on Screen A, another Board on screen B?

It may be desirable to have Boards spanning across multiple large monitors, while running under one AppBoard installation. Ideally, the Boards would interact with one another, but reside on separate monitors. Example: Law enforcement solution where one screen shows a map, an adjacent screen shows a drill-down table, etc.

A browser-based application has some limitations in accessing screen positioning, especially with regards to knowing location on specific monitors. It is possible to access the effective desktop size and make some guesses about positioning, but nothing specific. It could be possible to achieve some multi-screen support by requiring multiple browser windows be opened and manually maximized on each monitor. This is not supported now by AppBoard, and support for this is not currently scheduled in an upcoming release.

The best that can be done now is to configure a single browser window to span the multiple monitors and manually position the widgets so the boundaries align with screen boundaries. It would probably be necessary to create specific stack configurations for each distinct multi-monitor layout.