This guide describes the considerations you should take when deploying an Exago BI installation to a production environment. Suggested steps are listed in the order they should be taken. Best practices are recommended for each step. However, every environment is different, so recommendations should be considered in the context of your desired setup.
For personalized support, please file a support ticket.
Since Exago BI is an embedded application, it is up to you to decide which of your servers Exago is installed on. Exago BI supports nearly any type of deployment, including cloud, private servers or onsite at your clients.
It is recommended to deploy Exago BI on the same server as your application, and to deploy one or more scheduling services on separate servers to handle Remote Execution of reports. To use the .NET API, Exago BI must be accessible from the host application via a file system path. See API for more information.
The scheduling services are capable of acting as standalone report execution applications. The best way to scale Exago BI for performance is to deploy additional scheduling servers, and offload report executions to them. This method, called Remote Execution, also implements an automatic load balancing solution. The servers with the most available resources are given execution priority in order to keep an even load distribution.
A QA/Staging environment is highly recommended as well. This allows developers to test API changes, config changes, and Exago BI version updates, before moving to production.
Also consider the following:
It is critical to make the right choices in how to present your data to your users. Consider the technical level and reporting experience of your users. You may need to service different classes of users, from technical users like developers and database administrators, to non-technical business analysts and project managers.
Exago BI can manage data object permissions to many levels of precision. Permissions can be set per-user and per-group, for data objects, fields, rows, and even within field values. Data objects are easily restricted for classes of users using Roles. Within a data object, fields can be hidden, and row access can be limited by matching a linked user ID with the logged-in user. Roles can also provide filters for data values, in case some fields should be partially, but not fully hidden from view.
It is also recommended to use aliasing, descriptions, categories, and metadata to control how your data objects appear in the application. Categories are a way to separate data objects into folders, so you can group together associated data. Aliasing allows you to show more user-friendly names for data objects, instead of how they are named in the database. Descriptions provide additional information, and metadata can improve report performance.
Also consider the following:
It is critical that Exago BI is only exposed to users through the API. The API allows you to set security and permissions settings, and tailor the reporting experience by user.
.NET environments can use the .NET API, which is the most flexible and extensible API. Non-.NET environments can access a subset of API calls through either the REST or SOAP web service APIs. REST is highly recommended over SOAP, because it supports stronger security and a more modern feature set.
The most basic API implementation begins by initializing a session, then sets the "userId" and "companyId" parameters to identify the logged-in user, sets a user-specific Role to control permissions, and then launches Exago BI using the getUrlParamString() method. Developers should write the API code robustly with checks for null return values and exception handling.
Consider where you want Exago BI to appear within your application, and how users should use it to access reporting. For example, should it be placed in an iFrame container, a redirected page, or a popup window?
Also consider the following:
By default, Exago can handle the storage and retrieval of reports on a local or cloud-based file system. However, it is strongly recommend to use the Folder Management extensibility feature to customize where report definitions reside. Using folder management can allow you to store reports in a database instead of on a file server. This can make it easier to control user access permissions, helps to scale your deployment, and provides additional benefits such as soft deletes and report usage tracking.
Your custom folder management definitions are accessed from a custom assembly, so this does require some additional development. This sample code can be downloaded and used as a guide or a starting point.
Also consider the following:
Exago BI gives you full control over the CSS, icons, and language strings in the UI. You can have several different application themes if necessary, and select different ones for different classes of users. You can also build custom themes for reports and visualizations. And you can make a custom start page that users will see when they first enter the UI.
For integration, we recommend the following best practices:
Copy the ExagoHome.aspx
home page to a new page, and use that as the entry point for users going into the full UI. This copy can be styled at will.
Make a new application theme by extracting a copy of our theme template into a new folder in the ApplicationThemes
directory. Enable the theme in the Admin Console, and add any custom styling if desired.
Remove the content from the default Getting Started page, since this is only intended to be a styling example. It is recommended to add custom content, since users with access to the full UI will see this page often. Clients have used the Getting Started page to provide announcements, quick tips, helpful formulas, and links to other parts of the application.
Also consider the following:
By providing a folder of "canned" reports, you can show users Exago BI's capabilities, and some useful examples of the data that is available to them. This folder should be at the top level so it is easy to locate, and read-only so that users cannot edit the reports. If they want to make changes or see how the reports are made, they can duplicate a report and edit the copy.
Making these reports can be a good opportunity for your support, sales, and services staff to become familiar with Exago BI. The Exago BI services team can also assist your staff, either by basing your training on these reports, or by building them for you.
Also consider the following:
Once the other steps are in place, lay out a plan for moving to production. We recommend keeping detailed notes of the process so it can be replicated for future updates.
After installing in production, move the following files from your staging environment to production:
/Config/config.xml.enc
/ApplicationThemes/themeFolder
/Config/Languages/language.xml
. These also need to be added to the /Languages
directories for each scheduler installation./Config/Languages/getting-started.xml
/Config/Other/file.json
, and /appSettings.config
/NetHelp
/home.aspx
/Themes/theme
MapPolygonDataBase.sqlite
file is present in the /MapCache
folder.We also recommend adding the non-encrypted config file (/Config/config.xml
) to your version control after removing any sensitive passwords or connection strings.
Disable the Admin Console. It should not be accessible in a production environment.
Also consider the following:
WebReportsApi.dll
matches the version and build number of Exago BI. Do the same with any custom assemblies, such as Folder Management, Scheduler Queue, or Server and Action Events.IMPORTANT: Follow our Security Checklist before turning on access to your application. It is highly recommended to follow these steps to reduce the possibility of unauthorized access.