Embedding Business Intelligence within Applications
InterSystems IRIS® data platform Business Intelligence enables you to embed business intelligence (BI) within your applications so that your users can ask and answer sophisticated questions of their data. This page provides an overview of the features you can add, the overall process, and the tools you use.
Be sure to consult InterSystems Supported Platforms for information on system requirements for Business Intelligence.
Business Intelligence Features
Your application can include dashboards, which contain graphical widgets. The widgets display data and are driven by pivot tables and KPIs (key performance indicators). For a pivot table, a user can display a listing, which displays source values.
Pivot tables, KPIs, and listings are queries and are executed at runtime:
A pivot table can respond to runtime input such as filter selections made by the user. Internally it uses an MDX (MultiDimensional eXpressions) query that communicates with a cube.
A cube consists of a fact table and its indexes. A fact table consists of a set of facts (rows), and each fact corresponds to a base record. For example, the facts could represent patients or departments. The system also generates a set of level tables. All the tables are maintained dynamically.
Depending on your configuration and implementation, the system detects changes in your transactional tables and propagates them to the fact tables as appropriate.
The system generates an MDX query automatically when a user creates the pivot table in the Analyzer.
A KPI can also respond to runtime user input. Internally, it uses either an MDX query (with a cube) or an SQL query (with any table or tables).
In either case, you create the query manually or copy it from elsewhere.
A listing displays selected values from the source records used for the rows of the pivot table that the user has selected. Internally, a listing is an SQL query.
You can specify the fields to use and let the system generate the actual query. Or you can specify the entire query.
Dashboards can include buttons and other controls that launch actions. Actions can apply or set filters, refresh the dashboard, open other dashboards or other URLs, run custom code, and so on. The system provides a set of standard actions, and you can define custom actions.
Business Intelligence Components to Add to Your Application
To add Business Intelligence to an application, you add some or all of the following components:
Data connector classes. A data connector enables you to use an arbitrary SQL query as the source of a cube or a listing.
Cube definition classes. A cube defines the elements used within Business Intelligence pivot tables, and controls the structure and contents of the corresponding fact table and indexes.
A cube definition points to the transactional class (or the data connector) that it uses as its basis.
You can have any number of cubes, and you can use a given class as the basis of multiple cubes.
For each cube, the system generates and populates a fact table class and other classes.
Subject area classes.
A subject area is primarily a filtered cube. (It includes a filter and overrides for different parts of the cube definition, as wanted.) You can use cubes and subject areas interchangeably in Business Intelligence.
KPI definition classes.
You define KPIs when you need custom queries, particularly queries that are determined at runtime based on user input.
You also define KPIs when you need custom actions, because actions are contained in KPI classes.
Pivot tables, which you create by drag and drop. The system generates the underlying MDX queries.
Dashboards, which display pivot tables and KPIs by running the underlying queries and displaying the results.
The User Portal, which displays pivot tables and dashboards.
As noted in the High Availability Guide, InterSystems generally recommends that you use mirroring as part of your high availability strategy. For any large-scale application, InterSystems recommends a mirror involving a failover pair, an async reporting member, and at least one async disaster recovery member.
Analytics applications can consume all available processing power on an instance during their run time; by providing Analytics functionality through a reporting async member, the failover members of the mirror are better able to maintain high transaction volume.
Define your application so that the code and the data are in separate databases. This is not required, but is a typical architecture.
Set up mirroring so that the application data is mirrored to the async reporting member.
So that the system can access the application data, copy some or all of the application classes and other code to the reporting async member as well.
It is not generally necessary to mirror the application code.
On the reporting async member, create a database to contain the cube definitions and (optionally) data.
Optionally create another database to store the Business Intelligence fact table and other large-volume Business Intelligence data. Performing the Initial Setup provides information on the globals that the system uses.
On the async reporting member, define a namespace in which to run Business Intelligence. In this namespace, define mappings to access the application data, application code, cube definitions, and Business Intelligence data on this server.
Note that for small-scale applications or demos, all the code and data can be in the same database.
For recommendations on Business Intelligence disaster recovery, see Business Intelligence and Disaster Recovery.
Also be sure to consult InterSystems Supported Platforms for information on system requirements for Business Intelligence.
Main Implementation Steps
The implementation process includes the following steps:
If the namespace in which you want to use Business Intelligence does not yet define a web application, define a web application for it. See Performing the Initial Setup.
Optionally map the Business Intelligence globals from other databases, for performance. See Performing the Initial Setup.
Create the cubes and optional subject areas. This process includes the following steps, which you iterate as needed:
Define one or more cubes. In this step, you use either the Architect, Studio, or both.
Build the cubes. Here you use the Architect or the Terminal.
Use the Analyzer to view the cubes and validate them.
After the cubes are defined, define any subject areas based on those cubes.
For information on creating cubes and subject areas, see Defining Models for InterSystems Business Intelligence.
For information on using the Analyzer, see Using the Analyzer.
Optionally create KPIs. See Advanced Modeling for InterSystems Business Intelligence.
Optionally create custom actions. See Defining Custom Actions.
Make changes as needed to keep the cubes current. The way that you do this depends on how current the data must be, as well as any performance considerations.
See Keeping the Cubes Current.
Create pivot tables and dashboards. See Using the Analyzer and Creating Dashboards.
Package the pivot tables and dashboards into InterSystems IRIS classes for easier deployment.
See Packaging Business Intelligence Elements into Classes.
Create links from your application to dashboards. See Accessing Dashboards from Your Application.
At the appropriate points during this process, you may also have to do the following: