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

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

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

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

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.

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 .

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.

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!

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,.

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)

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

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

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="www.progress.com" 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

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

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

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

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

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