Enportal/5.4/faq/features

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

For FAQs about AppBoard features, see the AppBoard Features FAQ

Features

What applications are supported with pre-built integration modules?

For a list of Product Integration Modules (PIMs) currently available for enPortal, see Product Integrations. Each integration module provides a link with information or installation instructions for the integration.

By installing multiple integration modules, interfaces from these applications can be presented by enPortal side-by-side in the display to the User. AppBoard can also easily combine data from multiple sources into a Data Collection for display in one or more Widgets. AppBoard allows associations to be made between data sets coming from different sources to drive more meaningful data visualizations.

What is LDAP and how is it implemented?

LDAP is Lightweight Directory Access Protocol. It provides a service for storing and managing directories of items such as Users and Roles. It also provides simple interfaces for applications to access this information. This enables an organization to store all of this information in one centralized location. Many modern applications make use of the same concepts of Users, Roles, and Domains that are used in enPortal. It is not efficient to replicate the same lists of Users, Domains, and Roles in each application. Also, such lists would be difficult to maintain and keep in sync with one another.

AppBoard and enPortal provide separate provisioning tools for managing Domains, Users, and Roles. However, some organizations already have an LDAP server in place to manage Users and Roles. In this case, AppBoard and/or enPortal can map to the existing LDAP configuration and rely on LDAP for externally managing this information.

Click the links below for detailed instructions on configuring LDAP:

• EnPortal LDAP Configuration

Is Active Directory Supported for LDAP?

Active Directory is supported and has been used in several AppBoard/enPortal installations. Detailed instructions for configuring Active Directory with enPortal is available at Active Directory with enPortal

What support is available for load balancing and scalability?

The enPortal/AppBoard server can be deployed as a single standalone instance or in a clustered pair of servers with a front-end, hardware-based IP load balancer (e.g. Citrix, Cisco, F5, etc). The clustered option allows for both failover and scalability for large, mission critical environments.

The enPortal/AppBoard system is implemented as a web application architecture. It runs as a web application inside an Apache Tomcat Server, and accesses a JDBC accessible database, or clustered database system. The enPortal/AppBoard web application server scales horizontally by replicating on additional servers/platforms.

Horizontal scaling can be accomplished by adding new enPortal/AppBoard servers to the system in order to grow the capacity of the enPortal/AppBoard cluster.

A Load Balancer can distribute sessions to one or more enPortal/AppBoard nodes using any standard load balancing algorithm (e.g. Round-Robin, smallest load, fewest sessions, etc.). The only requirement is that the session affinity is maintained such that a single user is always routed to the same enPortal/AppBoard node during the full duration of the session. enPortal/AppBoard manages the session handling for all of the Tomcat processes and integrated applications within the enPortal/AppBoard component of the solution.

AppBoard provides an advanced data integration model that reduces the number of times back-end data sources must be queried. Role-based cashing and filtering means that each user only needs to fetch the data that is relevant for his or her dashboard. Settings for data polling and refreshing allow further management and control over the scalability of the system. Because AppBoard integrates at the data layer, a single query can bring data into AppBoard for display to a large numbers of users without burdening the back-end system as would be the case if users logged into the system directly.

For instructions on configuring Load Balancing, Scaling, or Failover, see Clustering and Failover.

Can I set up for high availability so that there is no single point of failure?

The solution can be configured to have high availability and integrated application round-robin/failover across multiple physical sites.

enPortal/AppBoard support one or more decoupled web application servers accessing a common user model stored in a database. There are three general server configuration options:

• Single server setup (no redundancy)
• Primary / backup server setup (redundancy but no load balancing)
• Clustered server option (redundancy with load balancing across N servers).

When multiple clustered application servers are used, the database must be external to the system (for single application server deployments, an embedded database may be used). Licenses can allow for either active-active or active-standby clusters. The load-balancer must be configured to provide session affinity / sticky sessions. Any number of application server instances may be used, and the scaling is linear as there is no crosstalk between the instances. For full system redundancy, an external load-balancer and an external, redundant database must be provided.

What is the maximum number of client connections, data sources, or web integrations a single enPortal 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.
When exposing an enPortal system to a potentially large user base, the following considerations can help manage the number of concurrent sessions:

• To the extent possible, roll out in phases and gradually ramp up the exposure to additional users.
• The Session Manager utility and Session.log file are tools that can be used to check (in real time) how many users are logged in at any time.
• Be prepared with a tested contingency plan to bring a load balancer and extra servers online if needed.
• Perform load testing on the actual pre-deployment system to help predict expected behavior.
• Consider initially lowering the session timeout duration to minimize the number of open sessions.
• If starting with one server, try to allocate 16 GB RAM or more, if possible, during the evaluation stage.
• If the H2 database is not being used to store enPortal’s content, try to minimize the latency between the enPortal server and the database server.

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/enPortal, 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/enPortal supports multi-tenancy through the concept of Domains. When Users log in to the 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/enPortal 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 enPortal content on mobile devices?

enPortal channels are not supported in the mobile app. However, in some cases enPortal content can be displayed in an AppBoard Web Widget, which can then be viewed through AppBoard Mobile.