1. Progress Apama Fundamentals
Deploying Apama Dashboards
Presenter’s Name
Presenter’s Job Title and Association
Date

2. Objectives Identify the various dashboard deployment options
Learn how to deploy a set of dashboards as a Java WebStart application

3. Topics Dashboard Deployment Options Dashboard Servers Panel Layouts
Deploying a Dashboard
Here is a list of the topics we will cover in this module.

4. Overview of Apama Components and Tools
An Apama Dashboard is ONE way of allowing users to control and visualize the execution of scenarios that were created with Apama Event Modeler and DataViews written in MonitorScript
External software you want to integrate
Apama Development Tools
Apama Studio
Dashboard Builder
MonitorScript
Java
Scenario
Event Modeler
Integration Adapter Framework
Management and Monitoring (EMM)
Event Correlator
GUIs and Container Processes using Client APIs
Dashboard GUI
Playback and Analysis
Dashboard Server

5. Dashboard Deployment Options
A dashboard can be deployed as:
A Windows GUI object
A simple Web page, applet, or Web Start application
A deployed dashboard connects to one or more correlators via a Dashboard Data Server or Display Server
As the scenarios in a correlator run and their variables change, or as a DataView item’s fields are updated, update events are sent to all connected dashboards
When a dashboard receives an update event, it updates its display in real-time to show the behavior of the scenarios or DataViews
Deploying Dashboards
During deployment, view dashboards as a Windows GUI object.
Dashboards can also be deployed as simple Web pages, applets, or WebStart applications.
Deployed dashboards connect to one or more correlators via a Dashboard Data Server or Display Server.
As the scenarios in a correlator run and their variables change, or as a DataView item’s fields are updated, update events are sent to all connected dashboards.
When a dashboard receives an update event, it updates its display in real time to show the behavior of the scenarios or DataViews.

6. Choosing a Dashboard Deployment Option
For a small operation that resides within a single network (very few clients)
Desktop application deployment
Requires a software install of the Dashboard Viewer on each client
Dashboard viewer can connect directly to the correlator, no dashboard server required
Looks and behaves as it does in Dashboard Builder
When a dashboard is modified, it must then be re-deployed on each client machine
Good performance but difficult to maintain
Not for a large operation with many clients
These three deployment types are NOT mutually exclusive.  You don’t have to pick just one.  They can peacefully coexist!
A desktop client (dashboard_viewer) is the most intrusive, requiring an actual software installation on the client.  When a dashboard is modified, the new files must also be deployed on each client.  It is also the most responsive and predictable though – ie, everything looks and behaves exactly as it did in the builder.  The same can't be said about the other two types.  The viewer also has the advantage that it can connect directly to the correlator (no dashboard_server required).  You would only do this however if there is only going to be one or two clients.  The viewer is best suited to a small operation (very few clients) that all reside within a single trusted sub-net.  Large installations will quickly become a problem for IT .

7. Choosing a Dashboard Deployment Option
For most operations (most common type of deployment used)
“Fat-client” web application deployment
Requires download of a java applet on each client
Java must already be installed on each client
Requires dashboard server and application server (Tomcat) on one machine
When a dashboard is modified, only need to update on the application server machine
Good trade-off between maintenance and performance
A fat client (IE based, dashboard_server) is less intrusive, requiring only the download of a java applet (and java 1.6+ must be already installed).  Dashboard_server and Tomcat must be running somewhere as well.  Deployment is easy, requiring only an update to the dashboard on the Tomcat server.  This is probably the most common deployment used.  It's a good tradeoff between maintainability and performance.

8. Choosing a Dashboard Deployment Option
For access from any machine with an Internet browser
“Thin-client” web application deployment
No download of java requirement on client machines
Good for casual observance of an application’s process
Easy to maintain but performance slower than other deployment options
You can use all three deployment options to suit your needs . . .
You do not have to pick just one
A thin client (IE based, display_server) is similar to the fat client, but there is no download or java requirement.  It can therefore be run on any computer with access to the Tomcat server.  It is, however, the least performant.  Updates are generated at best, every five seconds.  This method lends itself best to the trader who has set up his strategies and just wants to casually watch their progress.  It is NOT for the trader who is staring intently at the screen with a finger poised over the "enter" key.
These three deployment types are NOT mutually exclusive.  You don’t have to pick just one.  They can peacefully coexist!

9. Why Use a Dashboard Server?
Acts as a gateway through which dashboards access applications running on the correlator
Provides security
Correlator is not exposed directly to clients
Security mechanisms built-in to the Dashboard Server
Provides scalability
Handles client management on the part of the correlator
Can scale further via multiple Dashboard Servers
The Dashboard Data Server is the gateway through which Dashboards can access your applications running on the Correlator. Use of the Data Server provides scalability by obviating client management on the part of the Correlator, and provides security by not exposing the Correlator directly to clients. Managing the Data Server is covered in Chapter 3, Managing the Dashboard Data Server,.

10. Types of Dashboard Servers
Data server (dashboard_server.exe)
Desktop applications - communicates directly with dashboard viewer
“Fat client” web applications (applet or Java Web Start) - communicates through dashboard servlet in Tomcat
Display server deployments (display_server.exe)
“Thin client” web applications - communicates through dashboard servlet in Tomcat (which is installed with Apama)

11. Deploying with a Dashboard Server
Web-deployed Dashboard
Local Client Dashboard
Define a scenario in Event Modeler or a DataView in MonitorScript
Apama Studio
http
tcp
Application Server
Dashboard Server
Scenario or DataView Logic
Event Correlator

12. Deploying with a Display Server
Web-deployed Dashboard
Define a scenario in Event Modeler or a DataView in MonitorScript
Apama Studio
http
Application Server
Display Server
html and images
Scenario or DataView Logic
Event Correlator

13. Panel Layouts
To specify a panel layout for multiple dashboard displays:
Create an XML file, a panels-configuration file
Must have the .ini extension
Must start : <?xml version="1.0" ?> <panels xmlns=" version="1.0">
Must end with: </panels>
Supply the location of this file to the Dashboard Viewer executable
In Dashboard Deployment Wizard
Use the -C or --panelConfig option
Types of panels:
Border panel – Multiple displays
Card panel – Multiple, stacked displays
Grid panel – Show displays in a grid
Tabbed panel – Arrange displays in tabs
Tree panel – Navigate other displays in the same border panel

14. Exercise: Deploy a Dashboard
Objective
Learn how to deploy a set of dashboards via Java WebStart
Instructions
See the “Exercise: Deploy a Set of Dashboards ” handout (file name: 2-145_DeployDashboard.pdf)
Lab Exercise

15. Summary of Apama Dashboards
Designed for deployment flexibility
Run as a local process
Download using Java Web Start
Access as a Java Applet via a Web browser
Designed for scalability
A dashboard can access data from multiple correlator nodes
A dashboard server process acts as intermediary between clients and correlators
Removes client- related load from the correlator process
Designed for simplicity
You do not need to write any code
You develop against a live correlator
Allows you to see what the live GUI looks like now

16. Summary of Apama Dashboards
Designed for Apama
Commands to send events, create, edit and delete scenario instances
Tables to expose Scenario/DataView definition data
Tables to expose Scenario/DataView instance data
Designed for security
JAAS for authentication
Can add custom java for authentication

17. Where to Get More Information
Apama 4 Documentation
Deploying and Managing Apama Applications
Tutorials
In Apama Studio: Welcome  Tutorials

18. Apama Fundamentals Training
Deploying an Apama Dashboard
Presenter’s Name
Presenter’s Job Title and Association
Date