Preparing Dashboards for Deployment

Dashboard feature checklist

This section contains a checklist of capabilities that you should include in a project’s dashboards in order to ensure that the dashboards provide all standard dashboard functions. Most projects require all these capabilities, but some projects may not.

• Summary view: Displays a listing of all the instances of all the items of a DataView.
• Detail view: Provides detailed information about a selected DataView item.
• Create: Allows creation of new DataView items.
• Edit: Supports editing of existing DataView items.
• Delete: Allows deletion of DataView items.

Changing correlator definitions for deployment

When you create a dashboard in Dashboard Builder, use a development correlator. When you deploy a dashboard for use with a live correlator, change the correlator host and port so that they reference the live correlator.

This can be done in two ways:

• In the Dashboard Builder, select Tools > Options and use the Apama tab to specify the deployment correlator or correlators. You must do this before you generate a deployment package with the command line. See Specifying data sources.
• When you or another user starts a data server or display server that will serve event data to your deployed dashboard, use the -c or --correlator option to override the host and port specified in Dashboard Builder for a given correlator logical name. See Managing the dashboard data server and display server.

If a user other than you will complete the deployment, you must communicate to this other user the logical name for each correlator as well as the host name and port for each deployment correlator (if any) that you defined.

Choosing among deployment types

Apama supports two types of dashboard deployment:

• Web-based: as a simple, thin-client web page (thin-client deployment is known as display server deployment, because it uses the display server to mediate correlator access)
• Local: as a locally-installed desktop application (the Dashboard Viewer) together with dashboard-specific files that the application can open

The topics below compare web-based deployments with local deployments with regard to these factors.

Application installation

Local deployments require the use of the Dashboard Viewer desktop application (available on Windows platforms only). End users open locally-deployed dashboards in the Dashboard Viewer, which must be pre-installed locally or on a shared file system. See Building and Using Apama Dashboards for information about using the Dashboard Viewer.

With web-based deployment, the Dashboard Viewer does not need to be installed locally. Dashboards are invoked through a web browser, and are installed on demand, as web pages, so they can easily be deployed across a wide area network, including the internet.

Authentication

Web-based deployments provide web-based login functionality and use the authentication mechanism provided by your application server. They support authentication customization by allowing you to, for example, configure your application server to use the security realm and authentication service of your choice.

Local deployments include data server login functionality, and support authentication by allowing you to supply any JAAS-supported authentication module as a plug-in to the data server and to the Dashboard Viewer.

Authorization

Web-based deployments support role-based dashboard access control, which allows you to associate a role with a deployed dashboard, and to authorize use of the dashboard only for application-server users with the dashboard’s associated role.

Local deployments support dashboard access control by allowing you to use the system security mechanisms in order to restrict access to the deployed dashboard files.

Both types of deployment support DataView access control, which allows you to control who can have which type of access to which DataViews.

Data protection

With web-based deployments you can secure inter-process communication by enabling HTTPS in the application server. With local deployments you can secure inter-process communication by enabling secure sockets (SSL) in the data server or display server.

With both types of deployment you can secure inter-process communication through the use of secure channels (SSH) and virtual private networks (VPN).

Scalability

Both types of deployment are highly scalable, since both use the data server or display server to mediate access to correlators.

Choosing among web-based deployment types

• Served data
• Refresh latency

Each web-based deployment is a thin-client web page.

The topics below compare the different types of deployment with regard to the following factors.

Served data

The data server mediates correlator access for local deployments; the display server mediates correlator access for simple thin-client, web-page deployments.

The data server delivers raw data from which deployed dashboards construct the visualization objects that they display. The display server, in contrast, delivers already-constructed visualization objects in the form of image files and image maps.

Refresh latency

The display server’s minimum refresh latency (5 seconds) is greater than that of the data server. Use the data server for applications that require high-frequency screen updates.

Generating a deployment package from the command line

To deploy a dashboard, you must create a dashboard_deploy.xml file or use an existing one.

Display server deployment

The following is an example of a dashboard_deploy.xml file for display server deployment. You must update the values as required.

<?xml version="1.0" encoding="UTF-8" standalone="yes"?>
<dashboardDeployConfigs>
    <deploy>
        <property name="apama.rtv.main" value="Weather.rtv"/>
        <property name="apama.deployment.location" value="APAMA_WORK\dashboards"/>
        <property name="apama.displayserver.refresh" value="10"/>
        <property name="apama.displayserver.port" value="3279"/>
        <property name="apama.rtv.desc" value=""/>
        <property name="apama.rtv.panel" value=""/>
        <property name="apama.rtv.location" value="C:\workspace\dashboardProject\dashboards"/>
        <property name="apama.displayserver.host" value="localhost"/>
        <property name="apama.displayserver.hiddenmenuitems" value=""/>
        <property name="apama.rtv.name" value="DemoWeather"/>
        <property name="apama.deployment" value="DISPSERVER"/>
        <property name="apama.deployment.configName" value="DemoWeatherDispServer"/>
        <property name="apama.rtv.usePanel" value="false"/>
    </deploy>
</dashboardDeployConfigs>

When you have updated the dashboard_deploy.xml file, use a command prompt where the Apama environment is set and run the dashboard_management tool to create a .war file which then can be deployed to any web server. Use the following syntax (see also the property descriptions in the table below):

dashboard_management.exe --deploy <config_file_location> --config <config_name> --rtvPath <dashboards_location>

For example:

dashboard_management.exe --deploy C:\dev\dashboard_deploy.xml --config DemoWeatherDispServer --rtvPath C:\workspace\dashboardProject\dashboards

For detailed information on the dashboard_management tool, see Managing and stopping the data server and display server.

See also Generating the dashboard.war file.

Local deployment

The following is an example of a dashboard_deploy.xml file for local deployment. You must update the values as required.

<?xml version="1.0" encoding="UTF-8" standalone="yes"?>
<dashboardDeployConfigs>
    <deploy>
        <property name="apama.rtv.name" value="DemoWeather"/>
        <property name="apama.deployment" value="LOCAL"/>
        <property name="apama.deployment.configName" value="DemoWeatherLocal"/>
    </deploy>
</dashboardDeployConfigs>

With a local deployment, the dashboard files are packaged into a .zip file. You have to use the following syntax:

dashboard_management.exe --deploy <config_file_location> --config <config_name> --rtvPath <dashboards_location> --deployLocation <deployment_location>

For example:

dashboard_management.exe --deploy C:\dev\dashboard_deploy_local.xml --config DemoWeatherLocal --rtvPath C:\workspace\dashboardProject\dashboards --deployLocation C:\dev

Properties

You can set the following properties in the dashboard_deploy.xml file:

Sharing information with the dashboard administrator

There are two types of activity involved in making dashboards available to end users:

• Dashboard development, which requires the use of the Apama Dashboard Builder as well as the use of the command line to generate a deployment package.
• Dashboard deployment, which requires installing and configuring the deployment package, as well as administering the data server or display server and managing dashboard security.

Sometimes these activities are performed by different individuals. In such a case, the dashboard developer must be sure to communicate the following information to the dashboard administrator regarding the dashboard to be deployed:

• Location and file name of the .war file or .zip file that was generated when the developer prepared the dashboard for deployment.
• For display server deployments, the location of the dashboard project directory (the directory that contains the project’s .rtv files).
• For web-based deployments, the data server or display server host, port, and update rate.
• Logical name for each correlator as well as the host name and port for each deployment correlator (if any) that was specified by the dashboard developer in the Apama tab of the Tools > Options dialog prior to the generation of the deployment package. See Changing correlator definitions for deployment.
• Trend-data caching requirements for the deployed dashboards. See Configuring trend-data caching.
• Whether SQL-based instance tables are used by the dashboard for data attachments. See Attaching dashboards to correlator data.