Application Lifecycle Manager Deployment Guide

Application Lifecycle Manager Deployment Guide Version 3.0

Application Lifecycle Manager June 2011 Copyright 2008-2011 Alcatel-Lucent [http://www.alcatel-lucent.com]. All rights reserved. Important Notice to Users No part of this document may be reproduced or transmitted in any form or by any means, electronic, mechanical, photocopying, recording, or otherwise, without the express permission of Motive, Inc. ( Motive ) and/or Alcatel-Lucent. This document and the related software may only be used pursuant to a Software License Agreement or other similar written agreement in place between you and either Motive or Alcatel-Lucent. Furthermore, Motive and Alcatel-Lucent expressly disclaim any and all warranties regarding the information contained in, and the products and systems described in, this document, whether express, implied, or statutory, including without limitation implied warranties of merchantability or fitness for a particular purpose. Furthermore, this document is subject to change without notice. There may exist in this document references to using this product and the systems described herein in connection with products and/or systems owned by third parties. Please note that this information is provided as a courtesy to assist you. Such references are not intended to imply the granting of a license to use such products and/or systems. Such licenses shall result only from separately executed agreements between you and the owner of such products and/or systems. Neither Motive nor Alcatel-Lucent assume any responsibility or liability for incorrect or incomplete information provided about such third-party products. Alcatel, Lucent, Alcatel-Lucent, the Alcatel-Lucent logo, Motive and the Motive logo are trademarks of Alcatel-Lucent. All other trademarks are the property of their respective owners. The products and systems described herein may be covered by the various patents that have been issued to Motive and/or Alcatel-Lucent. Disclaimers This product is intended for commercial uses. Without the prior written consent of either Motive or Alcatel-Lucent it must not be used, sold, licensed or otherwise distributed for use in any hazardous environments requiring fail-safe performance, such as in the operation of nuclear facilities, aircraft navigation or communication systems, air traffic control, direct life-support machines, or weapons systems, in which the failure of products could lead directly to death, personal injury, or severe physical or environmental damage. You hereby agree that the use, sale, license or other distribution of the products for any such application without the prior written consent of either Motive or Alcatel-Lucent, shall be entirely at your sole risk. You hereby agree to defend and hold Motive and Alcatel-Lucent harmless from any claims for loss, cost, damage, expense or liability that may arise out of or in connection with the use, sale, license or other distribution of the products in such applications. This document was originally written in English. If there is any conflict or inconsistency between the English version and any other version of a document, the English version shall prevail. 3JB-00068-AAAC-TPZZA

Contents Introduction... vii Audience... viii Conventions... viii Support and contact information... viii 1 Installation... 1 Previewing the ALM installation process... 2 Conducting the required pre-installation tasks... 3 Understanding the ALM deployment scenarios... 3 Understanding the ALM pre-requisites... 4 Understanding the required ports... 6 Creating an Oracle user manually (optional)... 7 Creating backups for the installation environment... 8 Installing ALM... 8 Understanding answer files... 8 Understanding the ALM sample answer file... 9 Understanding the unique answer variables... 11 Invoking answer file for ALM installation... 20 Conducting the post-installation and deployment tasks... 23 Configuring the ALM license... 23 Setting properties for using MDM with ALM (if applicable)... 24 Completing post-deployment tasks for using HDM with ALM (if applicable)... 24 Uninstalling and undeploying the ALM application... 29 2 Administration and Configuration... 31 Locating and logging onto the ALM Management Console... 32 Managing users and user authentication... 32 Understanding ALM groups... 33 Understanding the ALM users... 34 Understanding ALM licenses... 34 iii

Understanding the ALM interfaces... 36 Understanding the ALM Management Console... 36 Understanding the ALM Northbound Interface (NBI)... 36 Finding and configuring application trace logging... 36 Trace logging levels... 37 Understanding the default ALM logging and top-level Java packages... 37 Configuring ALM application trace log levels... 38 Configuring an MDM installation to send notifications to ALM... 39 Setting up additional search profiles for policies... 43 Flavor examples... 43 Policy examples... 44 Policies to manage applications... 44 Policies to manage device health... 45 Configuring OSGi security... 45 Configuring system settings... 46 3 Administering the Dashboard Console... 47 Finding Dashboard resources... 48 Installing the Dashboard Console... 48 Licensing the Dashboard Console... 49 Logging into Dashboard Console... 50 Dashboard Console GUI... 50 Understanding a Dashboard Console deployment... 51 Understanding the dashboard-config.xml file... 52 Sample XML Configuration File... 53 Threshold Configuration... 72 Uploading and downloading the configuration file... 73 Understanding Dashboard counters and graphs... 73 Configuring counters and graphs... 74 Dashboard Console administration... 76 4 SMP Data Source... 79 Understanding the ALM SMP data source... 80 Requirements for deploying the ALM data source... 81 Installing and configuring the ALM data source... 81 Installing the ALM Synchronous REST Service... 81 Installing the ALM data source in SMP applications... 82 Setting up SSL for the ALM data source... 82 iv

ALM data source reference... 84 Connection parameters... 85 Best practices... 85 Data types... 85 Methods... 86 5 Troubleshooting... 93 Glossary... 95 Index... 113 v

vi

Introduction An offering in the portfolio of Alcatel-Lucent digital life management solutions, Application Lifecycle Manager enables broadband providers to remotely deploy and manage applications and services on devices. ALM supports dynamic installation and upgrading of application components and provides configuration and event notification services. A flexible northbound interface supports integration into business networks. Application Lifecycle Manager management capabilities include: Device Management. Supports the necessary functions to inspect and update software on devices. Application Creation Framework. Offers service providers a framework to assemble software components into added-value home services and applications. It helps to relieve your team of manual checks for component dependencies and compatibility. Application Lifecycle Management. Coordinates the installation and deployment of end-user services on managed devices. Application Lifecycle Manager functionality includes application, deployment unit, and individual device life cycle management, as well as the ability to apply policies on multiple devices. ALM enables you to upload deployment units (software components) to a File Server or specify the URL of a File Server where the deployment units already reside, in preparation for download to a service device. It also features deployment unit management through the use of applications, which can be flagged for testing, for production, or for deprecation, the latter preventing them from being installed on the device in the future. Applications are defined using flavorss, which allow each application to store variant sets of deployment units and configuration information for devices with different requirements, and which allow the system to automatically choose the appropriate flavor to install on a particular device. The system supports maintenance of configuration files and managed objects for applications. ALM is installed on top of one or more device managers, through which it communicates with clients using the TR-069 protocol or the DM (device management) protocol. Its interfaces include the ALM Management Console and the Application Lifecycle Manager Northbound Interface (NBI). The ALM Management Agent provides a client-side interface that enables communication between the device and Application Lifecycle Manager through Home Device Manager. This guide contains installation, administration, and configuration information for Application Lifecycle Manager. For detailed information about the ALM Management Console, see the ALM Management Console Help. For details about the ALM Northbound Interface (NBI), see the Application Lifecycle Manager Programming Guide and the Application Lifecycle Manager: WSDL Reference. vii

Audience The Application Lifecycle Manager Deployment Guide describes how to install, administer, and configure the product. This guide assumes that you understand how to use the device manager(s) you have selected for you deployment and the applicable northbound interfaces (NBI). In addition, you should understand the OSGi framework and the architecture, terminology, and supported device protocols for your device manager.. Conventions This document uses the following typographic conventions: Bold Identifies the names of graphical user interface buttons, options, commands, fields, and labels. Italic Identifies variable placeholders such as function or method parameters representing information that must be provided by the implementation or user. Also identifies documentation titles and certain terms to emphasize meaning. Monospace Identifies information that you are required to type exactly as shown. This convention also identifies code and command samples, screen prompts, messages, and filenames. Monospace italic Identifies parameters whose actual names or values you must provide at a screen prompt or in a text field. UPPERCASE Identifies the names of keys on the keyboard. In multi-line code listings, the symbol indicates that the text was wrapped for typographical reasons. Support and contact information If you encounter issues with this product, visit the Online Customer Support (OLCS) [https://support.alcatel-lucent.com] website. After registering and logging on, you can access troubleshooting information. In addition, you can contact Alcatel-Lucent Motive Support by phone, fax, or email, as follows: Toll-free phone (within U.S.) Outside U.S. Fax Email 1-866-582-3688, option 1 +1 613 784 6100 (United States) 1-512-339-9040 <support@motive.com> The Motive Product Group and its parent company, Alcatel-Lucent, are interested in feedback about your experience with this product and its documentation. If you have comments or suggestions, send email to <pubs@motive.com>. viii Introduction

This chapter covers: 1 Installation Previewing the ALM installation process Conducting the required pre-installation tasks Installing ALM Conducting the post-installation and deployment tasks Uninstalling and undeploying the ALM application 1

Previewing the ALM installation process Installing Application Lifecycle Manager involves the following tasks: Conduct the required pre-installation tasks: Understand the ALM deployment scenarios Understand the ALM prerequisites Understand the required ports Create an Oracle database user manually (optional) Create backups for the installation environment Use the ALM installer: To create a standalone WebLogic Domain, Administration Server and a cluster with n number of Managed Servers for ALM This deployment scenario is recommended, and it is required for deployments in which ALM is only using MDM without also using HDM. See ALM deployed in its own WebLogic domain (recommended) on page 3 and the applicable procedure, To install ALM in its own domain on a host slated for the Administration Server and/or a Managed Server on page 20. Or To install and deploy ALM on Managed Servers in a HDM installation This deployment scenario is not recommended; however, it is supported for deployments in which ALM is using HDM. See ALM deployed in same domain as HDM on page 3 and the applicable procedure, To install ALM on a Managed Server in a HDM domain on page 21. Conduct the post-installation and post-deployment tasks: Configure the ALM license unless configuring it with the LICENSE_STRING variable during ALM installation. For related information, see SSL and License answer variables on page 20. Set the properties for using MDM with ALM (if applicable) Complete the post-deployment tasks for using HDM with ALM (if applicable) 2 Installation

Conducting the required pre-installation tasks Understanding the ALM deployment scenarios The recommended deployment scenario involves creating a WebLogic domain for ALM, including an Administration Server and a cluster of one or more Managed Servers on which to install and deploy the product. If the ALM deployment is to use HDM, other scenarios are supported. For information, see ALM deployed in same domain as HDM on page 3. ALM deployed in its own WebLogic domain (recommended) In the recommended deployment scenario, your team invokes the ALM installer on the host slated for the Administration Server in addition to one or more hosts slated for Managed Server instances. ALM is installed and deployed on each of the latter instances. The installer creates a domain named ALMDomain for the system, and the managed servers become part of an ALMCluster. For instructions, see To install ALM in its own domain on a host slated for the Administration Server and/or a Managed Server on page 20. ALM deployed in same domain as HDM If using ALM with HDM, it is supported to install and deploy ALM on Managed Servers created in the same domain as HDM. In the following table, compare the types of Managed Servers on which you can install and deploy ALM. For instructions, see To install ALM on a Managed Server in a HDM domain on page 21. Comparison: Managed Server types for the ALM application Type Characteristics Dedicated Managed Server Instance created by the ALM installer as a part of the ALM installation/deployment processes Installed as an instance either: On the HDM Administration Server host Or Conducting the required pre-installation tasks 3

Comparison: Managed Server types for the ALM application (continued) Type Characteristics A remote host on which an instance of the HDM Managed Server is installed Added to the HDMDomain but not added to the HDMCluster; instead, it is added to a cluster created for one or more ALM Managed Servers. HDM Managed Server (not recommended) Runs a JMS Server and the ALM application Instance created by HDM installer Installed on any host in the Home Device Manager environment Added to both the HDMDomain and the HDMCluster Runs both the HDM applications and the ALM application Understanding the ALM pre-requisites For minimum system requirements and known issues, see the Application Lifecycle Manager Release Notes. Home Device Manager and/or Mobile Device Manager Before installing Application Lifecycle Manager (ALM), at least one of the following products must be installed, configured, and functioning correctly. Home Device Manager 3.1. For Home Device Manager installation or upgrade instructions, see the Home Device Manager Installation Guide, version 3.0.3. For system requirements, see the Home Device Manager Release Notes, version 3.1. Mobile Device Manager 3.1. For Mobile Device Manager installation or upgrade instructions, see the Mobile Device Manager Deployment Guide, version 3.1. For system requirements, see the Mobile Device Manager Release Notes, version 3.1. Database Server ALM requires a database instance running on one of the following Oracle Enterprise Edition server packages: 10g R2 version 10.2.0.4 Or 4 Installation

11g version 11.2.0.2 The Oracle client version installed on the Administration Server should match the version of the Oracle server installed for the database. For related information, see Creating an Oracle user manually (optional) on page 7 and Database answer variables on page 14. Note If using ALM with HDM, it is recommended to create the ALM database user on the same database instance in which the HDM database user is created. Oracle BEA WebLogic Server ALM requires Oracle BEA WebLogic 11g PS2 (10.3.3 or 10.3.4). Before installing ALM, you can install WebLogic on the target machines. Alternatively, you can use the ALM installer to silently install WebLogic with an applicable installer (for example, wls1034_generic.jar). For related information, see the answer variables in WebLogic Installer answer variables on page 11. Java Development Kit (JDK) ALM requires Java Development Kit (JDK) 1.6. Before installing ALM, you can install the JDK on the target machines. Alternatively, you can use the ALM installer to silently install the JDK with an applicable installer (for example, jdk-6u24-solaris-sparc.sh). For related information, see the entries for the Java variables in WebLogic and Java Installation answer variables on page 12. File Server for deployment units (bundles) Application Lifecycle Manager depends on a File Server to store deployment units for download by devices in the customer base. The File Server includes a component server for deployment unit uploading and a component server for deployment unit downloading. Most standard FTP and HTTP server components work with ALM, as long as the components support user name/password authentication or no authentication. Typically, the components are installed on the same host. For more information, see the File server requirements section in the Application Lifecycle Manager Release Notes. Supported protocols. Beginning with ALM 3.0, SFTP servers are supported for uploading bundles. Typically, SFTP servers are available on UNIX systems when the SSH daemon is installed. Uploading bundles. FTP and SFTP Downloading bundles. FTP, HTTP, and HTTPS Understanding the ALM pre-requisites 5

Before continuing, install a File Server with the FTP and HTTP components. In advance of each ALM installation, you need to define the applicable variables. For details, see File Server answer variables on page 19. Understanding the required ports The following table lists the ports that must be open for an ALM deployment. It does not include ports required by Home Device Manager. ALM required ports Port Number Protocol Destination Source Purpose 7006 HTTPS ALM Application server Management Access to the ALM Application Tier: Management Console NBI 9004 T3S ALM Application server BEA WebLogic administrator tools Used by BEA WebLogic tools to administer and monitor the server. This port is not required for normal operation. 1521 JDBC Oracle server ALM Application server Database access. 22 SFTP ALM repository ALM Application server Upload of deployment units and configuration files. 443 HTTPS CPE (service gateway) ALM repository Download of deployment units and configuration files. SOAP port HTTP(S) ALM NBI system ALM Application Server An NBI system can register a SOAP endpoint in ALM to received asynchronous notifications. To make this work, the appropriate port must be accessible. If the NBI system uses JMS 6 Installation

ALM required ports (continued) Port Number Protocol Destination Source Purpose for notifications, this is not required. Creating an Oracle user manually (optional) Application Lifecycle Manager depends on a database user to persist ALM data in an existing Oracle database instance. For related information, see Database Server on page 4. Note If using ALM with HDM, it is recommended to create the ALM database user on the same database instance in which the HDM database user is created. The following table outlines the two ways to handle creation of the ALM database user. Comparison: Creation methods for ALM database user Method Manually using a database tool such as SQL*Plus The user created must include the connect and resource privileges (for example, grant connect, resource to username) Characteristics Enables configuring the ALM database user in a custom manner (for example, with dedicated tablespaces) Eliminates requirement to define the Database Administrator (DBA) credentials while installing ALM; this is only required when the installer is to create the ALM database user Requires setting the DROP_USER=n variable in the answer files for ALM installations. In turn, the ALM installer: Does not issue a drop user command for the specified database user Automatically using the ALM installer Does not attempt creating the specified database user Requires person who invokes the ALM installer and defines the answer files to know the Database Administrator (DBA) credentials Requires setting the DROP_USER=y variable in the answer file used for installing the ALM Administration Server or only the first Managed Server foralm deployments in a HDM installation. In turn, the ALM installer: Drops the specified user (if the user exists in the specified database instance). For example, this is useful in a re-installation scenario. Creating an Oracle user manually (optional) 7

Comparison: Creation methods for ALM database user (continued) Method Characteristics Creates or re-creates the specified database user, whichever applicable. Important For each ALM installation occurring after the database user for ALM is created, set the DROP_USER=n variable in the answer file. For example, DROP_USER=n is applicable when: The DBA manually created the user before your team began installing ALM on target hosts. Or Installing ALM subsequently after the user was created during the first ALM installation process, either for an Administration Server and Managed Server or for the first Managed Server in a HDM installation. If the manual option is preferable, create the user now before continuing. For related information, see the DB_USER=ALM_DB and DB_USER_PW=ALM_DB entry in Database answer variables on page 14. Creating backups for the installation environment It is highly recommended to create backups of the following components before installing Application Lifecycle Manager: Oracle database instance slated for ALM data File system of all target hosts slated for ALM installations Installing ALM The primary method for installing and deploying ALM is invoking the provided ALM installer with an answer file. Understanding answer files You can use answer.txt files to install ALM. Answer files define variables and deployment-specific values for installations. There are two ways to use answer files: 1. Include all the deployment-specific values required to install. 8 Installation

In this case, the installer does not prompt you for any values. 2. Include some of the required values to install. In this case, the installer pre-populates the prompts with the values defined in your answer file, and it prompts for any required values not defined there. Managed Server installations. For a cluster, you run the ALM installer once for each Managed Server instance; some configuration values must be unique per instance. As a result, edit your answer file before each installation. Alternatively, leave the Managed Server-specific values undefined in the answer file, and then provide them when prompted. For example, pay special attention to the following answer variables. The MANAGED_SERVER_NAME property requires a unique value for each server instance. Similar to value for INSTALL_DIR, the port values must be unique for server instances on the same host. For related guidance, see ALM File System answer variables on page 13 and Managed Server answer variables on page 16. # # Managed Server # MANAGED_SERVER_CREATE=y MANAGED_SERVER_NAME=ALM-Server MANAGED_SERVER_PORT=7005 MANAGED_SERVER_SSL_PORT=7006 MANAGED_SERVER_ADMIN_PORT=9004 MANAGED_SERVER_MACHINE=M_host DEPLOY_APPLICATION=y # Important For each ALM installation occurring after the database user for ALM is created, set the DROP_USER=n variable in the answer file. For example, DROP_USER=n is applicable when: The DBA manually created the user before your team began installing ALM on target hosts. Or Installing ALM subsequently after the user was created during the first ALM installation process, either for an Administration Server and Managed Server or for the first Managed Server in a HDM installation. Understanding the ALM sample answer file This section provides a sample answer file for installing ALM. For guidance on setting the values, see the applicable sections in Understanding the unique answer variables on page 11. # # WebLogic Installer # BEA_INSTALL_FILE=/opt/installers/wls1034_generic.jar PROXY_HOST=proxy.mycompany.com PROXY_PORT=8080 # Understanding the ALM sample answer file 9

# WebLogic and Java Installation # WL_HOME=/opt/alm30/wlserver_10.3 JAVA_INSTALLER=/opt/installers/jdk-6u24-solaris-sparc.sh #JAVA_HOME=/opt/alm30/jdk160_24 CREATE_SEPARATE_BEA_DOMAIN=y # # ALM File System # INSTALL_DIR=/data/alm/install_3.0_separate/ALM-Server INSTALL_OVERWRITE=y # # Administration Server # BEA_ADMIN_HOST=admin.mycompany.com BEA_ADMIN_PORT=9002 BEA_ADMIN_SERVER_SSL_PORT=9001 BEA_ADMIN_USER=weblogic BEA_ADMIN_PW=w3blog!c AUTH_TYPE=default # # Cluster # CLUSTER_NAME=ALMCluster CLUSTER_MULTICAST_ADDRESS=224.22.22.22 CLUSTER_MULTICAST_PORT=3456 # # Database # DROP_USER=y DB_EXE=/opt/oracle/product/10.2.0.4/bin/sqlplus DB_SERVER=dbhost.mycompany.com DB_PORT=1521 DB_SERVICE=serviceName DB_DBA=system DB_DBA_PW=password DB_USER=ALM_DB DB_USER_PW=ALM_DB # # Node Manager # NODEMGR_PORT=5560 # # Managed Server # MANAGED_SERVER_CREATE=y MANAGED_SERVER_NAME=ALM-Server MANAGED_SERVER_PORT=7005 MANAGED_SERVER_SSL_PORT=7006 MANAGED_SERVER_ADMIN_PORT=9004 MANAGED_SERVER_MACHINE=M_host DEPLOY_APPLICATION=y # # HDM Applications # HNM_MANAGED_SERVER_NAME=hdm_7004 HNM_JNDI_URL=t3s://hdm.mycompany.com:7004 HNM_NBI_URL=https://hdm.mycompany.com:7004/remotehdm/NBIService 10 Installation

HNM_NBI_USER=nbi_user HNM_NBI_USER_PW=password # # File Server # REPOSITORY_DOWNLOAD_SERVER=repository.mycompany.com REPOSITORY_DOWNLOAD_ROOT=/download REPOSITORY_DOWNLOAD_PORT=443 REPOSITORY_DOWNLOAD_PROTOCOL=ftp REPOSITORY_DOWNLOAD_USER=anonymous REPOSITORY_DOWNLOAD_PASSWORD=password REPOSITORY_UPLOAD_SERVER=repository.mycompany.com REPOSITORY_UPLOAD_ROOT=/upload REPOSITORY_UPLOAD_PORT=22 REPOSITORY_UPLOAD_PROTOCOL=ftp REPOSITORY_UPLOAD_USER=anonymous REPOSITORY_UPLOAD_PASSWORD=password # # SSL and License # # If installing into environment with # demonstration certificates, you must # remove the pound sign (#) to uncomment # and apply the FAKE_SSL_TRUST=y answer # variable. # #FAKE_SSL_TRUST=y # LICENSE_STRING=125hwyuguabacwjfs Understanding the unique answer variables WebLogic Installer answer variables BEA_INSTALL_FILE=/opt/installers/wls1034_generic.jar Only applicable if Oracle BEA WebLogic 11g PS2 (10.3.3 or 10.3.4) is not yet installed on the host. To have the ALM installer silently install WebLogic, specify the path up to and including the WebLogic installer. If the WebLogic installer is generic (a.jar file), Java starts the silent installation process. Note that the parent directory set in the WL_HOME variable is implemented for BEA_HOME. The parent directory is everything in the string value except for wlserver_10.3 (for example, /opt/alm30/). PROXY_HOST=proxy.mycompany.com and PROXY_PORT=8080 Only applicable when setting BEA_INSTALL_FILE to silently install WebLogic. Optionally, specify the fully qualified host name and port configured for an available Proxy Server. This helps overcome waiting times when the installation host is on a system with blocked Internet access. Instead, you can apply empty values for these variables. Understanding the unique answer variables 11

WebLogic and Java Installation answer variables WL_HOME=/opt/alm30/wlserver_10.3 Specify the absolute path for the Oracle BEA WebLogic Server on the host. For example: /opt/alm30/wlserver_10.3 where: /opt/alm30/ is the root directory in which WebLogic is either to be installed or is installed on the host. JAVA_INSTALLER=/opt/installers/jdk-6u24-solaris-sparc.sh Only applicable when JDK 1.6 is not yet installed on the host; otherwise, the JAVA_HOME variable is applicable. Specify the path to the JDK1.6 installer, which can be downloaded from the Oracle site. In turn, the JDK is installed in the BEA_HOME/jdk160 directory. At the same time, the JAVA_HOME variable is automatically set to BEA_HOME/jdk160. where BEA_HOME is the parent directory set in the WL_HOME variable. The parent directory is everything in the string value except for wlserver_10.3 (for example, /opt/alm30/). For subsequent Managed Server installations on the same host, comment out the JAVA_INSTALLER variable by inserting a pound sign in front of it (for example, #JAVA_INSTALLER). #JAVA_HOME=/opt/alm30/jdk160_24 Only applicable when JDK 1.6 is already installed; otherwise, the JAVA_INSTALLER variable is applicable. To specify the path to an existing JDK installation on the host, uncomment the variable by removing the pound sign (#), and then configure the value as applicable. CREATE_SEPARATE_BEA_DOMAIN=y Specify whether to create a separate domain for ALM. y to create a separate domain for the ALM deployment The CREATE_SEPARATE_BEA_DOMAIN variable must be set to y if ALM is installed only for MDM. That is because ALM is installed on a JBoss application server. The ALM installer does not support installing ALM on JBoss. Or n to install ALM in the domain for an existing HDM installation. 12 Installation

ALM File System answer variables INSTALL_DIR=data/alm/install_3.0_separate/ALM-Server Specify the path for the ALM file system. The installer creates the directory and copies various ALM files including an uninstall script there. Note For cluster installations with multiple Managed Servers on the same physical host, the value must be unique per Managed Server. That way, each Managed Server on the host has its own file system. INSTALL_OVERWRITE=y Specify whether to overwrite the directory specified with INSTALL_DIR variable given the directory exists. y to overwrite the existing installation Or n to stop the installation process without overwriting the existing installation Administration Server answer variables BEA_ADMIN_HOST=almadmin.mycompany.com Specify the fully qualified host name for the Administration Server. BEA_ADMIN_PORT=9002 Specify the administrative port number for domain-wide administration on the Administration Server. If the default port number (9002) is in use on the Administration Server host, change the value; otherwise, leave the setting unchanged. BEA_ADMIN_SERVER_SSL_PORT=9001 Specify the SSL port number for the Administration Server. If the default port number (9001) is in use on the Administration Server host, change the value; otherwise, leave the setting unchanged. BEA_ADMIN_USER=weblogic Specify the user name for the Application Server Administrator account. BEA_ADMIN_PW=w3blog!c Specify the password for the Application Server Administrator account. AUTH_TYPE=default Specify the set of password requirements to implement: default to implement fewer password constraints. The default configuration only permits authentication for account passwords that include eight or more characters, including at least two lowercase characters (for example, f and l). Understanding the unique answer variables 13

Or advanced to implement additional password constraints. The advanced configuration only permits authentication for account passwords with eight or more characters, including at least: Two lowercase characters (for example, f and l) Two uppercase characters (for example, F and L) Two integers (for example, 0 and 9) Two special characters (for example, & and!) Cluster answer variables CLUSTER_NAME=ALMCluster Specify the name of the cluster. CLUSTER_MULTICAST_ADDRESS=224.22.22.22 Specify the IP address configured or to configure for multicasting. The address is for messages used by Managed Servers within the cluster for server-to-server communications. CLUSTER_MULTICAST_PORT=3456 Specify the port number configured or to configure for multicasting. Database answer variables For related information, see also Database Server on page 4 and Creating an Oracle user manually (optional) on page 7. Note If using ALM with HDM, it is recommended to create the ALM database user on the same database instance in which the HDM database user is created. DROP_USER=y Specify whether to create the specified database user or to use an existing user for ALM data. y to drop the specified database user and then to create or re-create the specified database user, whichever applicable Or n to configure installation with the specified database user. The user must already exist in the specified database instance. 14 Installation

Important For each ALM installation occurring after the database user for ALM is created, set the DROP_USER=n variable in the answer file. For example, DROP_USER=n is applicable when: The DBA manually created the user before your team began installing ALM on target hosts. Or Installing ALM subsequently after the user was created during the first ALM installation process, either for an Administration Server and Managed Server or for the first Managed Server in a HDM installation. DB_EXE=/opt/oracle/product/10.2.0.4/bin/sqlplus (conditionally required) Specify the absolute path to the Oracle client on the host. If DROP_USER=y is specified, the DB_EXE variable must be specified with the applicable value. DB_SERVER=dbhost.mycompany.com Specify the fully qualified name of the host on which the Oracle database instance is installed (that is, the instance slated for ALM tables and data). DB_PORT=1521 Specify the port number for communication with the database instance. The default Oracle port value is: 1521. DB_SERVICE=serviceName Specify the Oracle database service name. The service name is used to uniquely identify the Oracle instance running on the Oracle database. Sometimes this value is referred to as the SID. DB_DBA=system and DB_DBA_PW=password (conditionally required) If a database user was created according to Creating an Oracle user manually (optional) on page 7, you do not need to specify the DBA credentials. For DB_DBA, specify the user name for the Database Administrator (DBA) account. This account has permissions for creating the ALM tables. For DB_DBA_PW, specify the password for the Database Administrator (DBA) account. If DROP_USER=y is specified, the DB_EXE variable must be specified with the applicable value. DB_USER=ALM_DB and DB_USER_PW=ALM_DB Specify the user name and password for the database user, either: A database user that the installer is to create with default tablespaces in the specified database instance To have the installer create the user, you must also specify the DBA credentials for the database instance with the DB_DBA and DB_DBA_PW variables. Or An existing database user in the specified database instance Understanding the unique answer variables 15

In this case, you do not need to specify the DBA credentials. Node Manager answer variable NODEMGR_PORT=5560 Specify the node manager port number configured or to configure for the Managed Server instance. If the default port number (5556) is in use on the host, change the default value; otherwise, leave it unchanged. Managed Server answer variables MANAGED_SERVER_CREATE=y (conditionally required) Specify whether to have the installer proceed with creating a Dedicated Managed Server: y to create a Managed Server on the host from which the ALM installer is run. Or n to skip the installation process and configure an existing Managed Server in the HDMDomain. If you specify the name for an existing Managed Server in the ALMDomain or the HDMDomain (with MANAGED_SERVER_NAME), the installer does not apply this answer variable. MANAGED_SERVER_NAME=ALM-Server Specify the name of the Managed Server. The name is either the name: For a Managed Server that the installer is to create on the host from which the ALM installer is run. In this case, use the default value (ALM-Server) or a similar value. When creating multiple Managed Servers for a cluster, this value must be unique for each server instance. Or For an existing Managed Server in the ALMDomain or the HDMDomain. In this case, the value must be defined exactly as configured for the applicable server instance. By default, the HDM installer creates Managed Server instances with the host_7004 name format, where: host is the short name for the Managed Server host 7004 is the SSL port configured for the Managed Server MANAGED_SERVER_PORT=7005 (conditionally required) Specify the clear port number to configure for the Dedicated Managed Server. For example, the default value is: 7005 If you specify the name for an existing Managed Server in the ALMDomain or the HDMDomain (with MANAGED_SERVER_NAME), the installer does not apply this answer variable. 16 Installation

MANAGED_SERVER_SSL_PORT=7006 (conditionally required) Specifies the SSL port number to configure for the Dedicated Managed Server. For example, the default value is: 7006 If you specify the name for an existing Managed Server in the ALMDomain or the HDMDomain (with MANAGED_SERVER_NAME), the installer does not apply this answer variable. MANAGED_SERVER_ADMIN_PORT=9004 (conditionally required) Specifies the administration port number to configure for the Dedicated Managed Server. For example, the default value is: 9004 The administration port is used for communication with the Administration Server. If you specify the name for an existing Managed Server in the ALMDomain or the HDMDomain (with MANAGED_SERVER_NAME), the installer does not apply this answer variable. MANAGED_SERVER_MACHINE=M_host Host computer (machine) on which the Dedicated Managed Server is to run. The default value is created dynamically. For example: M_host where: host is the short name for the host on which to create the Dedicated Managed Server and from which the ALM installer is run. If you specify the name for an existing Managed Server in the ALMDomain or the HDMDomain (with MANAGED_SERVER_NAME), the installer does not apply this answer variable. DEPLOY_APPLICATION=y Specify whether to deploy the ALM application to the Managed Server during installation. y: Deploys the ALM application. For deployments with a cluster, it is typical only to deploy on the first Managed Server instance. WebLogic automatically deploys applications on subsequent instances in the cluster. Or n: Does not deploy the ALM application. HDM Applications answer variables If using ALM only with MDM (without HDM), the variables in this section are not applicable. In that case, apply empty values for them. HNM_MANAGED_SERVER_NAME=hdm_7004 Specify the exact name configured in the HDMDomain for the Managed Server on which the HDM applications are deployed. For example: hdm_7004 Understanding the unique answer variables 17

where: hdm is the short name for the Managed Server host 7004 is the SSL port configured for the Managed Server HNM_JNDI_URL=t3s://hdm.mycompany.com:7004 Specify the JNDI URL over which JMS communication between ALM and HDM will occur. For example: t3s:hdm.mycompany.com:7004/remotehdm/nbiservice Or t3:hdm.mycompany.com:7003/remotehdm/nbiservice where: hdm.mycompany.com is the fully qualified address for one of the following: Northbound load balancer that fronts the HDMCluster Instance of the application tier Managed Server 7004 is the SSL port 7003 is the clear port HNM_NBI_URL=https://hdm.mycompany.com:7004/remotehdm/NBIService Specify the URL for access to the Home Device Manager NBI. For example: https:hdm.mycompany.com:7004/remotehdm/nbiservice Or http:hdm.mycompany.com:7003/remotehdm/nbiservice where: hdm.mycompany.com is the fully qualified address for one of the following: Northbound load balancer that fronts the HDMCluster Instance of the application tier Managed Server 7004 is the SSL port 7003 is the clear port 18 Installation

HNM_NBI_USER=nbi_user Specify the user name for an account that includes the permissions necessary for using the HDM NBI. By default, the HDM installer creates the nbi_user with these permissions. HNM_NBI_USER_PW=password Specifies the password for the Home Device Manager NBI user. File Server answer variables REPOSITORY_DOWNLOAD_SERVER=repository.mycompany.com Specify the fully qualified address of the File Server host for bundle downloading. REPOSITORY_DOWNLOAD_ROOT=/download Specifies the root directory from which bundles are downloaded. REPOSITORY_DOWNLOAD_PORT=443 Specifies the port for downloading bundles from the File Server. REPOSITORY_DOWNLOAD_PROTOCOL=ftp Specify the protocol for downloading bundles from the File Server. REPOSITORY_DOWNLOAD_USER=anonymous Specifies the user name for downloading bundles from the File Server. REPOSITORY_DOWNLOAD_PASSWORD=password Specifies the password of the user for downloading bundles from the File Server. REPOSITORY_UPLOAD_SERVER=repository.mycompany.com Specify the fully qualified address of the File Server host for bundle uploading. REPOSITORY_UPLOAD_ROOT=/upload Specifies the root directory in which bundles are uploaded. REPOSITORY_UPLOAD_PORT=22 Specifies the port for uploading bundles to the File Server. REPOSITORY_UPLOAD_PROTOCOL=ftp Specifies the protocol for uploading bundles to the File Server. REPOSITORY_UPLOAD_USER=anonymous Specifies the user name for uploading bundles to the File Server. REPOSITORY_UPLOAD_PASSWORD=password Specifies the password of the user for uploading bundles to the File Server. Understanding the unique answer variables 19

SSL and License answer variables #FAKE_SSL_TRUST=y (conditionally required) Uncomment by removing the pound sign (#) to specify this only for a test environment in which the applicable WebLogic Server domain is not configured with production SSL certificates. In that case, the installation is dependent on demonstration certificates, and the FAKE_SSL_TRUST=y variable is required. LICENSE_STRING=125hwyuguabacwjfs Specify the license string for the application. For subsequent ALM installations, it is unnecessary to set the variable. Alternatively, your team can configure the license after installation. For instructions, see Configuring the ALM license on page 23. Invoking answer file for ALM installation To install ALM with an answer file, use the applicable procedure below: To install ALM in its own domain on a host slated for the Administration Server and/or a Managed Server on page 20 Or To install ALM on a Managed Server in a HDM domain on page 21 To install ALM in its own domain on a host slated for the Administration Server and/or a Managed Server 1. Confirm that you have completed the tasks under Conducting the required pre-installation tasks on page 3. 2. On the host on which you are installing, perform the following commands to add a UNIX group and user: groupadd almusers useradd -m -d /opt/alm30 -g almusers almadmin where: /opt/alm30 is the ALM installation directory. almusers is the new group. almadmin is the new user. 3. On the command line, enter the following prompt to change the almadmin user password, and then type the new password at the prompts: passwd almadmin 4. As the user created in Step 2, complete the following steps: 20 Installation

a. Create a staging directory for the ALM installer, and then extract the alm-3.0-dist.tar file from the product CD into the directory. For example: mkdir /opt/staging/alm30 cd /opt/staging/alm30 tar -xvf /dev/cdrom/alm-3.0-dist.tar where: /opt/staging/alm30 is the staging directory for the ALM installer. /dev/cdrom/ is the location of the mounted ALM CD. b. Create a text file with the installation-specific values for this ALM installation. For guidance, see the following resources: Understanding answer files on page 8 Understanding the ALM sample answer file on page 9 Understanding the unique answer variables on page 11 Important If installing into a test environment configured with demonstration certificates instead of production SSL certificates, you must set the FAKE_SSL_TRUST=y property in the answer file. c. Run the installer: cd /opt/staging/alm30 sh./alm-server-3.0.bin /full_path_to/answers.txt where: /opt/staging/alm30 is the staging directory created in Step 4.a. /full_path_to/answer.txt is the path up to and including the name of the answer file created in Step 4.b. The installer prompts for any invalid or missing values in the answer file. If successful, the following line appears in output: Installation ok. 5. After a successful installation, continue with Conducting the post-installation and deployment tasks on page 23. If unsuccessful, try re-running the installer with careful attention to the values you type. To install ALM on a Managed Server in a HDM domain 1. Confirm that you have completed the tasks under Conducting the required pre-installation tasks on page 3. 2. Open a shell and connect to the host in the Home Device Manager environment on which to install ALM. For related information, see ALM deployed in same domain as HDM on page 3. Invoking answer file for ALM installation 21

3. In the shell opened in Step 2, conduct the following steps: a. Switch to the Solaris user that is configured to run the Home Device Manager processes on the host. b. Create a staging directory for the ALM installer, and then extract the alm-3.0-dist.tar file from the product CD into the directory. For example: mkdir /opt/staging/alm30 cd /opt/staging/alm30 tar -xvf /dev/cdrom/alm-3.0-dist.tar where: /opt/staging/alm30 is the staging directory for the ALM installer. /dev/cdrom/ is the location of the mounted ALM CD. c. Create a text file with the installation-specific values for this ALM installation. For guidance, see the following resources: Understanding answer files on page 8 Understanding the ALM sample answer file on page 9 Understanding the unique answer variables on page 11 Important If installing into a test environment configured with demonstration certificates instead of production SSL certificates, you must set the FAKE_SSL_TRUST=y property in the answer file. d. Run the installer: cd /opt/staging/alm30 sh./alm-server-3.0.bin /full_path_to/answers.txt where: /opt/staging/alm30 is the staging directory created in Step 3.b. /full_path_to/answer.txt is the path up to and including the name of the answer file created in Step 3.c. The answer file defines the installation-specific values for installing and deploying the ALM on a single Managed Server instance. The installer prompts for any invalid or missing values in the answer file. If successful, the following line appears in output: Installation ok. 4. After a successful installation, continue with Conducting the post-installation and deployment tasks on page 23. If unsuccessful, try re-running the installer with careful attention to the values you type. 22 Installation

Conducting the post-installation and deployment tasks Configuring the ALM license If the ALM license was not configured during installation using LICENSE_STRING variable, use the following procedure; otherwise, skip to the next section. To configure the ALM license For more information on license options, see Understanding ALM licenses on page 34. 1. Acquire your license string from the Motive Product Group (if you do not already have it). 2. Log into the ALM Management Console: a. In a browser, go to the following URL: https://alm.mycompany.com:7006/alm or http://alm.mycompany.com:7005/alm where: alm.mycompany.com is the fully qualified address for one of the following: Load balancer that fronts the ALM cluster. One of the Managed Servers that hosts the ALM application. 7006 is the SSL port for the Managed Server. 7005 is the clear port Managed Server. The login page appears. b. In the Username field, type: almopmgr c. In the Password field, type: password Note The almopmgr/password credentials are for the default user created during the ALM installation. You can reset the almopmgr password through the WebLogic Server Console. For guidance, see Modify users [http://e-docs.bea.com/wls/docs92/consolehelp/taskhelp/security/modifyusers.html] in Oracle's online BEA WebLogic Server documentation. Conducting the post-installation and deployment tasks 23

d. Click the Log On button. Until configuring the valid license string in the next step, the console is displayed with access to limited functionality. 3. Configure the ALM license: a. Click the System Settings tab. b. On the row with the License property, paste your license string in the Value field. Important The string must be pasted into the field as a single concatenated line. c. Click the Save Changes button. The change is applied immediately. 4. Confirm that additional tabs are displayed in the interface now. With a valid license, more tabs should display, depending on the privileges configured for the logged-in user. By default and until otherwise changed, the almopmgr user includes all privileges for the ALM Management Console. You can also select About->About, then select the License tab in the About dialog box to display details about the installed license, such as the expiration date and capacity of the license. Setting properties for using MDM with ALM (if applicable) If the ALM deployment is not using Mobile Device Manager (MDM), skip this section and continue with Completing post-deployment tasks for using HDM with ALM (if applicable) on page 24. In the ALM Management Console, use the System Settings tab to set appropriate values for Mobile Device Manager by editing values on the MDM page in the Connectors folder of the System Settings. For instructions, see MDM in ALM Management Console Help. Completing post-deployment tasks for using HDM with ALM (if applicable) If the ALM deployment is not using Home Device Manager (HDM), skip the following tasks; otherwise, complete them. Enabling trust between separate ALM and HDM domains (if applicable) For ALM deployments using HDM and for which the two products are installed in separate WebLogic domains (recommended scenario), you must enable trust between the domains. This applies even if the two domains are named identically. 24 Installation

For instructions, see Enable trust between domains [http://download.oracle.com/docs/cd/e13222_01/wls/docs92/ ConsoleHelp/taskhelp/security/http://download.oracle.com/docs/cd/E14571_01/apirefs.1111/e13952/taskhelp/security/ EnableGlobalTrustBetweenDomains.html] in the WebLogic documentation. Creating the minimum ALM data objects in HDM To use Application Lifecycle Manager with HDM, you need to create or import some data objects in the Home Device Manager environment. To do so, create the data objects referenced in the table below. ALM data objects to create through the HDM Management Console Data object OSGi framework device type Action for enabling active notifications Requirements Use the ALM-provided device type XML file on the product CD: acs/hdm/devicetype/osgi1.0.xml Depending on what the deployment requires, configure the device type for zero touch activation or pre-provisioned. Name: Enable active notifications Action type: Set Parameter Attributes Parameter: InternetGatewayDevice. Services.OSGi.BundleNumberOfEntities with: Associated topic in HDM Management Console Help Adding device types Adding actions Attribute Name: Notification Policy for forcing active notifications Attribute Value: Active Name: Force active notifications Protocol: TR069v1 Action: Enable active notifications Configure policy to be event-based and triggered on Activation event Set Initiate Connection on Request device Adding policies Completing post-deployment tasks for using HDM with ALM (if applicable) 25

ALM data objects to create through the HDM Management Console (continued) Data object Criteria template for enabling ALM to reinvoke policies on failed devices Requirements Name: Find failed or aborted devices for ALM policy 1. From the staging directory in which the ALM installer was extracted (alm-3.0-dist.tar), open the following file in a text editor: Associated topic in HDM Management Console Help Managing criteria templates acs/hdm/criteriatemplates/ finddevbyalmbulkoperation IdAndOperationState.xml 2. In the file, replace all instances of ALM_USER with the exact database user name configured for the ALM deployment (for example, ALM_DB). That name was defined with the DB_USER variable in the answer file used for installation or by the DBA who manually created the user before ALM was installed on target hosts. For related information, see the Database answer variables on page 14. 3. As the ALM database user (for example, ALM_DB), use SQL*Plus to log into the database instance that includes the ALM tables; then, execute the following commands. GRANT SELECT ON GATEWAY to HDM_DB; GRANT SELECT ON COMMAND_HISTORY TO HDM_DB; where HDM_DB is the name of the database user originally defined during HDM installation. 26 Installation

ALM data objects to create through the HDM Management Console (continued) Data object Requirements Note The ALM and HDM database tables must be created with users on the same Oracle database instance. Associated topic in HDM Management Console Help 4. Upload the updated finddevbyalm BulkOperationIdAnd OperationState.xml file through the HDM Management Console. As referenced in next column, see the Managing criteria templates section in the HDM Management Console Help for guidance. Configuring the JMS event notification settings in HDM Application Lifecycle Manager depends on some JMS notification events of Home Device Manager. By default, the HDM installer sets the associated system settings to true, which is the configuration required for ALM. Even so, it is important to validate that the properties have not been configured from their default values. As a result, complete the To validate that the HDM JMS event notification properties are set to true on page 27 procedure. To identify the properties that are a factor, see HDM JMS event properties that must be set to true on page 27 within the procedure. To validate that the HDM JMS event notification properties are set to true 1. Log into the Server Configuration Console in the HDMDomain. For guidance, see the Server Configuration Console entry in the Finding the HDM user interfaces topic of the Home Device Manager Deployment Guide. 2. For the applicable server instances and/or globally, double-check that the properties in the following list are set to true; if not, change the values from false to true. HDM JMS event properties that must be set to true nbi.notification.send.deviceactionresultevent nbi.notification.send.eventtriggeredpolicyresultevent Completing post-deployment tasks for using HDM with ALM (if applicable) 27

nbi.notification.send.single.device.action.result For guidance on editing property values, see the Server Configuration Console Help. Confirming Java Messaging Service (JMS) communication Once devices are active in your customer base and/or test environment, you can determine whether the associated JMS communication between ALM and HDM is occurring. When a JMS connection is not established, server warning messages about failed JMS connections get written to the application trace log (every 5 seconds). If you are unsure of the log file location, see Finding and configuring application trace logging on page 36. Log messages indicating a successful connection appear similar to the following: 14:59:55,270 INFO [DefaultMessageListenerContainer] Successfully refreshed JMS Connection Error messages look similar to the following: 14:59:02,318 INFO [DefaultMessageListenerContainer] Could not refresh JMS Connection - retrying in 5000 ms: org.springframework.jndi.jndilookupfailureexception: JndiObjectTargetSource failed to obtain new target object; nested exception is javax.naming.communicationexception [Root exception is java.net.connectexception: t3://172.31.110.224:7003: Destination unreachable; nested exception is: java.net.connectexception: Connection refused: connect; No available router to destination] Filtering JMS messages The following properties are available for filtering or blocking JMS messages in HDM: nbi.notification.blocked.inform.eventcodes nbi.notification.jms.blocked.events nbi.notification.jms.blocked.registrations nbi.notification.jms.blocked.results nbi.notification.send.deviceactionresultevent nbi.notification.send.deviceevent nbi.notification.send.eventtriggeredpolicyresultevent nbi.notification.send.single.device.action.result nbi.notification.send.unknowngatewayevent Note For details on these properties, see the Home Device Manager Deployment Guide. Because ALM relies on JMS notifications, the following properties must be set to true: 28 Installation

nbi.notification.send.deviceevent If this property is set to false, the following conditions occur: Activation events are not sent to ALM. Thus, a device that is registered in HDM will not be registered in ALM. Value Change Inform events are not sent. These events are generated by the Management Agent when the command line of the device is used to make a manual state change of a bundle or property of an application. Thus, the ALM database will not be synchronized automatically with the state change of the device. nbi.notification.send.deviceactionresultevent If this property set to false, policies are not invoked on the devices. Policies are specified in the ALM Management Console. Policies in ALM schedule the instant triggered policy with a simple CR action. As a result, every device that is targeted by the policy generates an NBI notification with the object NBIDeviceActionResult. ALM listens for these messages, and based on the device ID and operation ID (which is the policy ID in ALM), ALM schedules an application operation per device. nbi.notification.send.single.device.action.result If this property set to false, policies are not invoked on the devices. Certain notifications should not be specified in the following properties: nbi.notification.jms.blocked.results This property should not contain NBIOperationResult, NBIBulkOperationResult, or NBIDeviceActionResult. nbi.notification.jms.blocked.events This property should not contain NBIDeviceInformEvent or NBIDeviceActivationNotification. nbi.notification.blocked.inform.eventcodes This property should not contain 2 PERIODIC if you want ALM s event-triggered policies to be able to receive the NEXTCONNECTION. ALM is not dependent on the following properties: nbi.notification.jms.blocked.registrations nbi.notification.send.eventtriggeredpolicyresultevent nbi.notification.send.unknowngatewayevent Uninstalling and undeploying the ALM application Use the following procedure to uninstall Application Lifecycle Manager and undeploy the application from the applicable Managed Server without uninstalling Home Device Manager or other applications in the environment. Uninstalling and undeploying the ALM application 29

To uninstall and undeploy the ALM application 1. Before uninstalling components on the Solaris host: Back up the data in the OLTP database. Take a backup image of the host on which ALM is installed. Note If reinstalling components after removing some or all of them, it is important to have the backups of the OLTP database and all local files and directories. That way, if necessary, you can restore the backup data in future software versions. 2. As the Solaris user configured to run the ALM applications on the host, run the following commands: cd /data/alm/install_3.0_separate/ sh./alm-server/uninstall.sh where: /data/alm/install_3.0_separate/ is the path to the top-level directory in which the ALM file system is located. If you do not run the uninstaller from the top-level directory, the process cannot complete the last step of removing the ALM-Server directory. install_3.0_separate is the root directory of the ALM file system for a Managed Server instance. If successful, the following line appears in output: Uninstallation ended successfully 3. Drop the ALM database user from the applicable Oracle database instance. 4. If the ALM application was deployed on a HDM Managed Server instead of a Dedicated Managed Server created by the ALM installer, restart that server; otherwise, skip this step. To do so, stop the Managed Server instance, and then start it again. For step-by-step instructions, see the stop and start procedures in the Restarting application tier servers section of the Home Device Manager Deployment Guide. 30 Installation

This chapter covers: 2 Administration and Configuration Locating and logging onto the ALM Management Console Managing users and user authentication Understanding ALM licenses Understanding the ALM interfaces Finding and configuring application trace logging Configuring an MDM installation to send notifications to ALM Setting up additional search profiles for policies Flavor examples Policy examples Configuring OSGi security Configuring system settings 31

Locating and logging onto the ALM Management Console Use the information in the following table to log onto the ALM Management Console. ALM Management Console Description The ALM Management Console is a secure, web-based user interface that enables remote management of applications), deployment units, and the execution environments that run on devices in the home environment. URL https://alm.mycompany.com:7006/alm or http://alm.mycompany.com:7005/alm where: alm.mycompany.com is the fully qualified address for one of the following: Load balancer that fronts the ALM cluster. One of the Managed Servers that hosts the ALM application. 7006 is the SSL port for the Managed Server. Default user name Default password almopmgr password 7005 is the clear port Managed Server. Managing users and user authentication User management involves configuring what constitutes a valid user name and password and what privileges (roles) groups and users have. The ALMDomain includes several default users and groups typically needed for a deployment. Each product installation process adds applicable minimum users, groups, and roles for using associated new functionality. Roles can be assigned to users and groups. Users can be members of groups, and groups can be members of other groups. Role assignment is additive. If a user is a member of more than one group, that user has the roles of all the groups: 32 Administration and Configuration

Users, groups, and roles Roles Users Groups In an Application Lifecycle Manager environment, you perform all user, group, and role management through the WebLogic Server Console. The console is accessible at: https://adminhost.yourcompany.com:9002/console where: adminhost.yourhost is the address of the host on which the Administration Server for the ALMDomain (or thehdmdomain, if installed along with HDM) is installed. 9002 is the domain-wide administration port of the Administration Server. For information on the default users, groups, and roles for HDM, see the Home Device Manager Deployment Guide. Understanding ALM groups In installing ALM, several default users, groups, and roles are added to the ALMDomain (or the HDMDomain, when installed along with HDM). Membership in a particular group adds to the roles (privileges) a user has. Users can also be added to individual roles for a more granular control of privileges. In the following table, see the default group and role associations configured for ALM. ALM groups Group ALM_SYSTEM_MANAGER Associated privileges Configure ALM system settings Understanding ALM groups 33

ALM groups (continued) Group ALM_DEVICE_MANAGER ALM_DU_LIFECYCLE_MANAGER ALM_APPLICATION_MANAGER ALM_DRAFT_APPLICATION_MANAGER ALM_POLICY_MANAGER ALM_NBI_MANAGER Associated privileges Filter and delete devices Install, start, stop and uninstall deployment units Create, update and delete applications Install draft applications Create, start, stop and delete policies Perform NBI operations To view and modify group configuration, log onto the WebLogic Server Console and navigate to YourDomainName->Security Realms->myrealm->Users and Groups->Groups. For complete guidance on configuring groups, see Modify Groups [http://edocs.bea.com/wls/docs92/consolehelp/taskhelp/security/ ModifyGroups.html] in BEA's 9.2 version of Administration Console Online Help. Understanding the ALM users ALM adds the following users to the ALMDomain or the HDMDomain: almopmgr user: Assigned to the ALM_SYSTEM_MANAGER, ALM_DEVICE_MANAGER, ALM_DU_LIFECYCLE_MANAGER, ALM_APPLICATION_MANAGER, and ALM_POLICY_MANAGER groups. alm_nbi_user user: Assigned to ALM_NBI_MANAGER group. Before any post-installation configuration occurs, the default users include group memberships, which in turn are associated with roles. For more information, see Understanding ALM groups on page 33. To view user configuration from the WebLogic Server Console, navigate to YourDomainName->Security Realms->myrealm->Users and Groups->Users. For complete guidance on configuring users, see Modify Users [http://edocs.bea.com/wls/docs92/consolehelp/taskhelp/security/modifyusers.html] in BEA's 9.2 version of Administration Console Online Help. Understanding ALM licenses The ALM Management Console requires a license to access tabs in the user interface. Until a valid license has been applied, all tabs except the System Settings tab are deactivated. To install an ALM license, log on to the ALM Management Console, click the System Settings tab, and paste the license string into the ALM license field. For more information, see Configuring the ALM license on page 23. 34 Administration and Configuration

License status. To view the status of the license of an ALM server, select the About link in the ALM console, and then click the License tab. License options. An ALM license provides the right to use the software on specific servers. License tab fields The License tab displays the following fields to describe your options. License Message Indicates whether the license is valid or not. License Expiration Date The date when the license expires. Licensed Host IDs A list of host IDs that are allowed for this host. Actual Host ID The ID of the current host, for comparison with the Licensed Host IDs field. Number of Active Devices The total number of devices that the system has communicated with. A device is considered active if the system has received an activation event (from the relevant device manager) for that device, and the device has not been removed from the device manager. Number of Licensed Devices The number of devices that the server is licensed to communicate with. Number of Locked Devices The number of devices that have been activated, but can't be used because they exceed your license and have been locked. For example, if your license supports 100 devices, all devices activated after the first 100 will be in the locked state, and ALM will not perform operations on them. Plugins This section lists the available execution environment plugins and indicates, for each plugin, whether your license allows you to use it (indicated with true or false. The available plugins are android, linux, and osgi. Dashboard license. The Dashboard Console requires its own license, an HDM Dashboard License. Consult your sales representative to get a license, in the form of a text file. Understanding ALM licenses 35

Understanding the ALM interfaces Application Lifecycle Manager communicates with Home Device Manager through the Home Device Manager Northbound Interface (NBI) (web services) and through the JMS channel of HDM NBI notifications. Using the ALM Management Console, you can configure the HDM NBI URL, the HDM NBI user name and password, and the connection settings to HDM JMS topics. Understanding the ALM Management Console The ALM Management Console is a secure, web-based user interface that enables remote management of applications), deployment units, and the execution environments that run on devices in the home environment. For log on instructions, see Locating and logging onto the ALM Management Console on page 32. For complete instructions on using the console, see the ALM Management Console Help. Understanding the ALM Northbound Interface (NBI) The ALM Northbound Interface (NBI)provides methods that allow you to manage the life cycle of applications on devices. An application is something that can be started, stopped, installed, and uninstalled on a device. The applications that you manage with the NBI are referred to as applications in the ALM Management Console. The reason for this inconsistency is that the ALM NBI is intended for other technologies (non-osgi) as well, and those may not include the notion of deployment units. For more information, see the Application Lifecycle Manager Programming Guide and the Application Lifecycle Manager: WSDL Reference. Finding and configuring application trace logging ALM writes its log entries to the Home Device Manager application trace on the Managed Server host on which it is installed: /opt/alm/domains/almdomain/servers/managedserver_port/logs/trace_managedserver_port.log where: /opt/alm/ is the root installation directory. managedserver is the name of the application tier Managed Server on which ALM is deployed. port is the SSL port number of the Managed Server. 36 Administration and Configuration

Trace logging levels The installation process does not configure particular settings for ALM application logging. By default, ALM defaults to the error level, which is the root log level for all Java packages set in the log4j.xml file on each Managed Server, including the Managed Server on which ALM is installed. You can override the root log level for particular Java packages by configuring log levels in the log4j log file on a Managed Server, and then restarting the Managed Server. The supported log levels are: debug Writes all trace messages to the applicable log file, including debugging, informational, warning, error, and critical failure messages. Debug messages are intended to provide detailed information about events useful for debugging an application. info Writes informational, warning, error, and critical failure messages to the applicable log file. Info messages are intended to summarize the status of the application. warn Writes warning, error, and critical failure messages to the applicable log file. Warn messages are intended to document potentially harmful events. error Writes error and critical failure messages to the applicable log file. Error messages are intended to document events that are problematic yet may allow an application to continue running. fatal Writes only critical failure messages to the applicable log file. Fatal messages are intended to document events that cause the application to stop running. Understanding the default ALM logging and top-level Java packages At installation, the root logging level is set to error. As a result, ALM system activity is logged at the error level until the global setting is changed or otherwise overridden for some of the log activity with a more granular log level property. The top-level ALM Java packages for which you can set a logging level are: com.alcatel_lucent Trace logging levels 37

com.alcatel com.alu Configuring ALM application trace log levels Configure application trace log levels through the log4j.xml file on the Managed Server host on which ALM is deployed. The log4j.xml file is located as follows: On a dedicated Managed Server. alm_install_dir/log4j.xml. For more information about the dedicated Managed Server deployment scenario, see Understanding the ALM deployment scenarios on page 3. On an HDM Managed Server in a fresh HDM 3.0.0 installation. /opt/hdm/domains/hdmdomain/servers/managedserver_port/logconfig/log4j.xml On an HDM Managed Server in an installation upgraded to HDM 3.0.0. During an upgrade to 3.0.0, the location of the file is changed to /opt/hdm/domains/hdmdomain/servers/managedserver_port/ logconfig/log4j.xml unless its location was changed from the default in 2.3.0. If the location was changed from the default in the 2.3.0 installation, that location is still used in 3.0.0. where: alm_install_dir is the root installation directory on a Managed Server in a dedicated Managed Server deployment scenario (for details, see Understanding the ALM deployment scenarios on page 3). /opt/hdm/ is the root installation directory on an HDM Managed Server. managedserver is the name of the Managed Server. port is the SSL port number of the Managed Server. Configure the level in this section of the file: <category name="motive"> <level value="error"/> </category> For example, you might insert the following entries to change the logging level for the top-level ALM Java packages to debug: <category name="com.alcatel"> <priority value="debug"/> </category> <category name="com.alcatel_lucent"> <priority value="debug"/> </category 38 Administration and Configuration

<category name="com.alu"> <priority value="debug"/> </category> For a description of valid <level/> values, see Trace logging levels in this section. To identify more specific ALM packages for which to change the logging level, see the Java package hierarchy in the.jar file in the WEB-INF/lib directory of the deployed application (webgui.war). The.war file is on a Managed Server in the HDMDomain in the following directory: path_to/domains/hdmdomain/servers/mgdname_port/stage/hsmapplication where: path_to is the path to the HDM installation on the Managed Server host on which ALM is installed. mgdname is the name of the Managed Server. port is the SSL port configured for the Managed Server. Configuring an MDM installation to send notifications to ALM When ALM is used with Mobile Device Manager (MDM), you must configure MDM to send notifications to ALM, by updating the MDM system's Apache Camel configuration file and updating some of MDM's Server Configuration Console properties. You must also create a device type in the ALM console. The steps in this topic can also serve as a guide to the configuration required for any device manager, as similar steps would be required for a different device manager. To configure MDM to send notifications to ALM 1. Determine if you need to install security certificates. If you are using production certificates, install the appropriate certificate to allow your managed server(s) to communicate with MDM. If you are using a demo certificate in your WebLogic Application Server installation, and want to use it to communicate with MDM, then complete the following steps to configure it: a. Copy the file DemoTrust.jks from the WebLogic installation (in the $BEA_HOME/wlserver_10.3/server/lib/DemoTrust.jks) to the MDM machine. b. Add the following property to the runjboss.sh file (in the $MDM_JBOSS_HOME/bin directory): -Djavax.net.ssl.trustStore=/full_path_to/DemoTrust.jks c. Restart the MDM server. See the MDM Server Deployment Guide for instructions. Configuring an MDM installation to send notifications to ALM 39

2. Add elements to your Apache Camel configuration file (camelcontext.xml). For instructions, see Configuring notifications through the Camel XML file in the MDM Server NBI Guide. The following sample file defines an endpoint with the id alm and creates routes that send specific events to it. <?xml version="1.0" encoding="utf-8"?> <beans xmlns="http://www.springframework.org/schema/beans" xmlns:xsi="http://www.w3.org/2001/xmlschema-instance" xsi:schemalocation=" http://www.springframework.org/schema/beans http://www.springframework.org/ schema/beans/spring-beans-3.0.xsd http://camel.apache.org/schema/spring http://camel.apache.org/schema/spring/ camel-spring.xsd"> <bean id="createsoapmessageprocessor" class="com.alu.mdm.notification.processor. CreateSoapMessageProcessor" /> <bean id="jbossresolver" class="com.alu.mdm.resolver.jbosspackagescanclassresolver"/ > <camelcontext id="camel" xmlns="http://camel.apache.org/schema/spring"> <properties> <property key="http.proxyhost" value="bluecoat-be01.alcatel.fr"/> <property key="http.proxyport" value="1080"/> </properties> <template id="cameltemplate"/> <endpoint id="alm" uri="https://172.31.140.33:8088/soap"/> <onexception> <exception>java.lang.exception</exception> <!-- tell Camel to handle and continue when this exception was thrown --> <redeliverypolicy maximumredeliveries="3"/> <continued> <constant>true</constant> </continued> </onexception> <!-- Routes for notifying events --> <route> <from uri="direct:devicedeleted" /> <process ref="createsoapmessageprocessor" /> <multicast> <to ref="alm"/> </multicast> </route> 40 Administration and Configuration

<route> <from uri="direct:bulkjobresult" /> <process ref="createsoapmessageprocessor" /> </route> <multicast> <to ref="alm"/> </multicast> <route> <from uri="direct:devicejobresult" /> <process ref="createsoapmessageprocessor" /> </route> <multicast> <to ref="alm"/> </multicast> <route> <from uri="direct:devicemissinginfo" /> <process ref="createsoapmessageprocessor" /> <multicast> <to ref="alm"/> </multicast> </route> <route> <from uri="direct:genericalert" /> <process ref="createsoapmessageprocessor" /> <multicast> <to ref="alm"/> </multicast> </route> <route> <from uri="direct:deviceinuse" /> <process ref="createsoapmessageprocessor" /> </route> <multicast> <to ref="alm"/> </multicast> <route> <from uri="direct:devicebootstrapped" /> <process ref="createsoapmessageprocessor" /> Configuring an MDM installation to send notifications to ALM 41

</route> <route> <multicast> <to ref="alm"/> </multicast> <from uri="direct:deviceunauthenticated" /> <process ref="createsoapmessageprocessor" /> </route> <multicast> <to ref="alm"/> </multicast> <route> <from uri="direct:deviceregistration" /> <process ref="createsoapmessageprocessor" /> </route> </camelcontext> </beans> <multicast> <to ref="alm"/> </multicast> 3. Update MDM Server Configuration Console properties as described in the following table. For more information, see Setting server properties in the MDM Server Deployment Guide. Property nbi.send.devicebootstrapped.event nbi.send.devicejobresult.event nbi.send.devicedeleted.event camel.file.reload New value true true true The folder containing the updated camel configuration file. 4. In the MDM Console, create an action that executes a DM Bootstrap command. For instructions, see Adding actions in the MDM Console Help. 5. As a final step, configure ALM to receive notifications. In the ALM Management Console, create at least one device type for devices managed through MDM: a. Select the Device Types tab, then click the Add Device Types button. 42 Administration and Configuration

b. For a device type, you can specify three values. For an MDM device, select IMEI in the Address Class field, then enter a Make and Model (for example, Nokia and E61. c. Click the Ok button. Setting up additional search profiles for policies Search profiles determine the initial list of devices that are addressed by an instant-triggered policy; this list is then filtered by the constraints you establish for the policy. The list of search profiles that is available in ALM is derived from the criteria templates loaded in Home Device Manager. To add a new search profile, create a new criteria template (or import one) in the Home Device Manager console, then refresh the list of search profiles as described in the ALM Management Console Help. One criteria template, FindDevicesByServiceTag, is required to enable ALM to reinvoke policies on devices where the policy failed initially. The template is provided with Home Device Manager, but must be imported. See Creating the minimum ALM data objects in HDM on page 25 for more information. Flavor examples Each application contains one or more flavors. A flavor defines a set of deployment units and configuration information that are appropriate for some set of devices. Each flavor also contains constraints that can limit which devices it is installed on. When more than one flavor is defined, the system compares the properties of a target device with the constraints and execution environments defined for each flavor until it finds the appropriate flavor to install on that device. Flavors allow you to target the installation of a particular application version to multiple devices, and have the system determine which flavor is appropriate for each device. The following examples may help provide ideas of how to use flavors in a deployment: An OSGi application which has a native software environment driver. For this use case, each native environment would require a different flavor. Each flavor would have constraints related to the native environment (such as a particular version of Linux), and each flavor's set of deployment units would include the same OSGi deployment units, but would use a different driver. Flavors allow these variations to be defined as a single application, with the ALM system automatically installing the correct version for each device. An application which has separate flavors for OSGi and Linux. Setting up additional search profiles for policies 43

Suppose your deployment includes some devices that support OSGi and some that do not. You create deployment units for both, and configure them into one application with two or more flavors, one flavor for each execution environment. An application which has different flavors for different device types. Devices may require vendor-specific configuration files. An application may require several flavors which use the same deployment units but have different configuration files defined. Policy examples Policies are a powerful feature of the ALM system for managing devices without direct interaction. Policies are rules which cause the system to perform actions on devices either as a group or by reacting to events on the device. This section provides some examples of how you can use policies in a deployment. Policies to manage applications When you plan to roll out an application to machines, you can use policies to both install the application on multiple machines, and maintain the application by repairing it when it has problems. The ALM system automatically generates an INCONSISTENTAPPLICATIONS event whenever a deployment unit associated with an application is stopped or uninstalled. By creating an event-triggered policy based on this event, you can initiate repair actions to bring an application back into operation. The INCONSISTENTAPPLICATIONS event provides the system with a list of problem applications; a policy based on it can attempt repairs on any applications with problems. The following table provides a sample set of policies to implement these use cases. Sample policies for deploying and repairing applications Name Type Actions Other settings Description InstallClock Instant-triggered Install Application Constraints set to a subset of available devices Installs clock application on appropriate devices. Initiated by support personnel when the application is deployed. UpdateClock Instant-triggered Update Application Updates clock application. Initiated by support personnel when the update has 44 Administration and Configuration

Sample policies for deploying and repairing applications (continued) Name Type Actions Other settings Description been tested and is ready for deployment. RepairApplications Event-triggered Repair Policy trigger: INCONSISTENT APPLICATIONS When a deployment unit required by an application is stopped or uninstalled, the system runs this policy and initiates a Repair action on the device. Policies to manage device health The following table provides an example of how to implement policies to monitor devices and reboot them when their free memory values are low. Sample policies to manage device load Name Type Actions Other settings Description EnableHealthCheck Instant-triggered enable health check Schedule settings to prevent the system load from becoming too high. Search Profile as broad as possible. Enables health checking on selected devices. RebootLowMemoryDevices Event-triggered Reboot Policy trigger: STATISTICSRECEIVED Memory Free (Kb) < 5000 Triggers the reboot action on devices whose free memory is less than 5 mb. Configuring OSGi security The ALM Management Console allows you to manage OSGi security rules through the OSGi Security tab. Motive anticipates that for a deployment, you will want to configure additional or different rules in the following cases: To support OSGi frameworks other than Prosyst. Policies to manage device health 45

To provide finer-grained security To use bundle signing rather than bundle location to assign permissions. Important The best practice for security is to sign all bundles and use bundle signing to assign permissions. Other resources. For more information on using OSGi security with ALM: See the ALM Management Console Help for information on using the OSGi Security tab to define security rules and apply them to devices. See the OSGi specifications for information on OSGi permissions and standards. For example, see OSGi Package Permission [http://www.osgi.org/javadoc/r4v42/org/osgi/framework/packagepermission.html]. Configuring system settings After installing Application Lifecycle Manager, your team configured the required settings in the System Settings tab of the ALM Management Console. As needed, you can configure them differently. For instructions, see the following resources: Locating and logging onto the ALM Management Console on page 32 System Settings in the ALM Management Console Help 46 Administration and Configuration

This chapter covers: 3 Administering the Dashboard Console Finding Dashboard resources Installing the Dashboard Console Licensing the Dashboard Console Logging into Dashboard Console Dashboard Console GUI Understanding a Dashboard Console deployment Understanding the dashboard-config.xml file Understanding Dashboard counters and graphs 47

The Dashboard Console is a web-based application that enables users to monitor the health metrics on each ALM server, as well as globally on the entire ALM Cluster. Users can also view graphs of current performance data, and analyze this data against historical data. Monitoring results are stored in a local database that handles time-series data, from which the dashboard generates graphs. The graphs, whose data you can export, show views of Managed Server health data over the past hour, day, or week from JDBC, Northbound Interface (NBI), Southbound Interface (SBI), and server-related sources. During installation or upgrade, an option is provided to install the Dashboard Console. If the Dashboard Console is not installed at that time, it can be installed later. Usage of the console requires an HDM Dashboard license. For more information, see Understanding ALM licenses on page 34. Finding Dashboard resources In ALM distribution tar files, Dashboard files and resources can be found in the /support/alm-server-3.0-generic.tar.gz file. When that file is decompressed, a dashboard folder is revealed. That folder contains the dashboard-config.xml file and other Dashboard resources. Installing the Dashboard Console The method for installing the Dashboard varies depending on the type of ALM deployment. ALM deployed in same domain as HDM. When ALM is installed in the same domain as HDM, install the Dashboard according to the HDM Dashboard installation instructions. See the HDM Dashboard Deployment Guide for more information. ALM deployed in its own WebLogic domain. For an ALM Cluster installation, installed on WebLogic 11g, you modify the standard HDM Dashboard installer by overwriting some of its files with files provided with ALM, and by editing some of its properties and values. To install the Dashboard Console in an ALM cluster 1. Get the HDM Dashboard installer and copy it to a temporary directory. 2. Copy the files found in /support/alm-server-3.0-generic.tar.gz/dashboard over the corresponding HDM Dashboard files, overwriting them. 3. Search the Dashboard installation files for references to alm_db_user, and replace them with the actual ALM database username you used during installation. 4. Using the HDM Dashboard Deployment Guide for guidance, edit the values in install_params_dashboard.txt to appropriate values for your deployment. 48 Administering the Dashboard Console

5. If the Dashboard database user is different from the ALM database user, then issue the following SQL grant commands to grant appropriate permissions to the Dashboard user. Using an SQL tool, connect to the Oracle database as the ALM database user and then execute these commands: GRANT SELECT ON GATEWAY TO dashboard_db_user; GRANT SELECT ON APPLICATION_INSTANCE TO dashboard_db_user; GRANT SELECT ON COMMAND_HISTORY TO dashboard_db_user 6. Run the Dashboard installer using the command: install_dashboard.sh The installer prepares the database and WebLogic for the Dashboard. 7. Using the WebLogic Administration Console, deploy the dashboard.ear file to all the managed servers in the ALMCluster. 8. Install the Dashboard license. See Licensing the Dashboard Console on page 49. 9. Upload the Dashboard configuration file for ALM (/support/alm-server-3.0-generic.tar.gz/dashboard) as described in Uploading and downloading the configuration file on page 73. Licensing the Dashboard Console Complete the following steps to acquire and install a license for the Dashboard Console. To license the Dashboard Console. 1. Get a license from your sales representative, in the form of a license.txt file. 2. Using a browser, connect to the Dashboard Configuration Editor and log in. http://mgdhost.mycompany.com:8001/dashboard-sce Use the ALM user almopmgr to log in. See Logging into Dashboard Console on page 50 for more information on the precise URL to use for connecting. 3. Paste the contents of your license.txt file in as the value of the Dashboard Configuration Editor's License.licenseString parameter. Licensing the Dashboard Console 49

Logging into Dashboard Console Logging into the Dashboard Console URL http://mgdhost.mycompany.com:8001/dashboard Or https://mgdhost.mycompany.com:8002/dashboard a Default user credentials (user name/password) dashmgr/password; the almopmgr/password user is also added to the UI_DASHBOARD_APPLICATION_MANAGER group at installation, which provides access to the Dashboard. The dashmgr account is created during Dashboard installation. Post-installation and before moving a deployment into production, it is recommended to reset the passwords for all default users. a where: mgdhost.mycompany.com is the hostname of the load balancer that fronts the ALM cluster. Dashboard Console GUI The Dashboard Console GUI makes accessing the needed information for counters and graphs easy and efficient: Dashboard Console is divided into the following main sections: Application Dashboard. Displays the counters related to application health. System Monitoring. Displays the counters that are related to server health, such as JVM heapsize. Manage Configuration. Supports uploading and downloading the XML configuration file for the Dashboard Console. Cluster Data. Enables viewing which servers are running and which servers are down. Whether or not to display each counter can be controlled based on a user's role. The ROLE attribute for the counter in the configuration file determines if the current user can view the counter or not. If the ROLE attribute is not specified, then the counter is visible to all users. If the ROLE attribute is specified, then the current user must have that role to view the counter. For more information on the default roles added for the Dashboard Console see Dashboard Console administration on page 76. You can generate a filtered counter status view with dynamic graphs using the server, counter, and time filter, or view pre-configured graphs. You can take a snapshot of the collected data on demand. 50 Administering the Dashboard Console

It is not allowed to take a snapshot for a range that exceeds the value of the server property dashboard.statistics.leveltwo.data.limit.days. You can export the snapshot data. You can use the analysis feature to compare snapshots, or to compare a snapshot with current data. For example, you can compare the current situation to one when the system was operating under perfect conditions. Notes When comparing snapshot data, the data to be compared must have been taken at the same resolution. For example, snapshot data taken at a resolution of 1 minute cannot be compared to data that was taken at a 60 minute resolution. Three resolutions for snapshot data are supported: 1 minute, 60 minutes (1 hour), and 1440 minutes (24 hours). These resolutions can be configured by setting the values of the following server properties, respectively: dashboard.statistics.collection.levelzero.interval.mins, dashboard.statistics.collection.levelone.interval.mins, and dashboard.statistics.collection.leveltwo.interval.hours. The data to be compared can be from different buckets, regardless of their size. For example, a 1 month data bucket and 5 month data bucket can be compared, as long as the resolutions are the same. The resolutions are handled automatically by Dashboard Console. When you are comparing two snapshots in the GUI, after you select the first snapshot, Dashboard only offers you choices for the second snapshot that have the same resolution as the first. Understanding a Dashboard Console deployment A relational database stores Dashboard Console data. Monitoring results and configuration information are stored in a relational database so that Dashboard Console can be configured at runtime without restarting servers. Dashboard-agent module stores statistics data. The dashboard-agent module is responsible for storing the statistics data in the relational database. The agent periodically retrieves statistics from the JMX resource of BEA/Oracle WebLogic. The agent then posts this data into the database. Once data is inserted into the database, more flexible and detailed graphs can be generated. Dashboard Console is deployed to all Managed Servers. Dashboard Console is deployed to each Managed Server that is to be monitored instead of only the Administration Server in the BEA/Oracle WebLogic environment. Each Managed Server is responsible for collecting and storing statistics data for itself. For cluster-level counters like JDBC counters, one Managed Server is selected automatically Understanding a Dashboard Console deployment 51

as the Master Managed Server to perform cluster-level statistics tasks. If the Master Managed Server crashes, one of the other Managed Servers automatically takes on this responsibility. Counters are defined and configured by editing an XML configuration file. Counters are defined and configured by editing an XML configuration file, which can then be imported into Dashboard Console using the GUI. The Dashboard Console GUI also supports exporting the XML configuration file. A large set of useful counters is defined for you in the default configuration file that is loaded during Dashboard Console installation. Table spaces of the Dashboard Console tables can be placed in separate disk storage. Table spaces of the Dashboard Console tables can be placed in separate disk storage to avoid disk full errors. As a result, Dashboard Console should be able to write the logs into the database even if there are high loads on the application servers. Dashboard Console is packaged as an.ear file. As a separate application with sophisticated infrastructure such as timer task execution, Dashboard Console is packaged as an.ear file rather than a.war file. Understanding the dashboard-config.xml file This section explains the elements of the dashboard-config.xml file and the details for each element. All configuration information is stored in the relational database. This has several advantages: There is no need to restart the server to read the new information if the configuration settings are changed. Counters and graphs can be easily configured and modified by exporting (downloading), editing, and then importing (uploading) an XML configuration file via the Manage Configuration button provided in the Welcome page. Then click the respective button for the desired operation. All configuration is performed by editing the dashboard-config.xml configuration file, which is installed automatically with the Dashboard Console. Download the installed dashboard-config.xml configuration file to a local directory on your system, and then edit the configuration file using an ASCII text editor such as Notepad or emacs. After editing and saving the configuration file, upload the configuration file. The configuration is read and takes effect immediately. In the Dashboard Console configuration, the entities that provide the data are the datasources. A datasource is a concept that defines: The statistics data location How it is connected/disconnected How its value is fetched 52 Administering the Dashboard Console

All counters are derived from their respective data source definitions. Dashboard Console provides the most important counters out of the box. When you enable monitoring through Dashboard Console, Dashboard Console collects counters for each Managed Server using JMX and re-discovers the servers at an interval that you can configure. The data is collected in counters that are configured using the dashboard-config.xml file. The dashboard-config.xml file specifies which counters are kept and which graphs are made using them. Sample XML Configuration File <DashboardConfig> <datasources> <datasource name="hsmjdbcdatasource" class="com.alcatel.dashboard.datasources. JDBCDataSource" target="cluster"> <property name="datasource" value="alm/jdbc/datasource"/> </datasource> <datasource name="hdmdatasource" class="com.alcatel.dashboard.datasources. HdmDataSource" target="server"/> <datasource name="jmxdatasource" class="com.alcatel.dashboard.datasources. JMXDataSource" target="server" /> <datasource name="jmxadmindatasource" class="com.alcatel.dashboard.datasources. JMXDataSource" target="cluster"> <property name="jmxserviceurl" value="service:jmx:t3://targetremoteserver:7003/ jndi/weblogic.management.mbeanservers.runtime"/> <property name="username" value="nbi_user"/> <property name="password" value="password"/> <property name="protocolproviderpackage" value="weblogic.management.remote"/> </datasource> <datasource name="osdatasource" class="com.alcatel.dashboard.datasources. OperatingSystemDataSource" target="server"/> <datasource name="javaplatformdatasource" class="com.alcatel.dashboard.datasources. JavaPlatformDataSource" target="server"/> <datasource name="expressiondatasource" class="com.alcatel.dashboard.datasources. ExpressionDataSource" target="server"/> </datasources> <counters> <!-- JDBC Counters--> <counter datasource="hsmjdbcdatasource" name="alm.device.count" displayname="alm Device Count" aggregationtype="gauge" datatype="integer" cluster="true" description="number of devices defined in ALM"> Sample XML Configuration File 53

<property name="sqlstatement" value="select count(*) from alm_db_user.gateway"/> <counter datasource="hsmjdbcdatasource" name="alm.device.active.count" displayname= "ALM active device Count" aggregationtype="gauge" datatype="integer" cluster="true" description="number of active devices in ALM"> <property name="sqlstatement" value="select count(*) from alm_db_user.gateway where state=1"/> <counter datasource="hsmjdbcdatasource" name="alm.device.active.count.rate" displayname="alm device activation rate" aggregationtype="counter" datatype="integer" clustercalculation="sum" unit="devices/sec" cluster="true" description="speed of device activation in ALM"> <property name="sqlstatement" value="select count(*) from alm_db_user.gateway where state=1"/> <counter datasource="hsmjdbcdatasource" name="alm.device.count.rate" displayname= "ALM Device Count Rate" aggregationtype="counter" clustercalculation="sum" cluster="true" description="speed of device creation in ALM" unit="devices/sec"> <property name="sqlstatement" value="select count(id) from alm_db_user.gateway"/ > <counter datasource="hsmjdbcdatasource" name="alm.application.count" displayname= "ALM Installed application Count" aggregationtype="gauge" datatype="integer" cluster="true" description="number of applications installed in ALM"> <property name="sqlstatement" value="select count(*) from alm_db_user. application_instance"/> <counter datasource="hsmjdbcdatasource" name="alm.application.count.rate" displayname= "ALM Installed applications Count Rate" aggregationtype="counter" clustercalculation= "sum" cluster="true" description="speed of application installation in ALM" unit="apps/ sec"> <property name="sqlstatement" value="select count(*) from alm_db_user. application_instance"/> <counter datasource="hsmjdbcdatasource" name="alm.application.started.count" displayname="alm Started application Count" aggregationtype="gauge" datatype="integer" cluster="true" description="number of applications started in ALM"> <property name="sqlstatement" value="select count(*) from alm_db_user. application_instance where state=1"/> <counter datasource="hsmjdbcdatasource" name="alm.application.started.rate" displayname="alm Started applications Count Rate" aggregationtype="counter" clustercalculation="sum" cluster="true" description="speed of application startup in ALM" unit="apps/sec"> <property name="sqlstatement" value="select count(*) from alm_db_user. application_instance where state=1"/> <counter datasource="hsmjdbcdatasource" name="alm.application.updated.count" displayname="alm Updated application Count" aggregationtype="gauge" datatype="integer" cluster="true" description="number of applications updated in ALM"> <property name="sqlstatement" value="select count(*) from alm_db_user. 54 Administering the Dashboard Console

command_history where Operation = 'Update' and composite=1 and state=7"/> <counter datasource="hsmjdbcdatasource" name="alm.application.updated.rate" displayname="alm Updated applications Count Rate" aggregationtype="counter" clustercalculation="sum" cluster="true" description="speed of application update in ALM" unit="apps/sec"> <property name="sqlstatement" value="select count(*) from alm_db_user. command_history where Operation = 'Update' and composite=1 and state=7"/> <counter datasource="hsmjdbcdatasource" name="alm.application.uninstalled.count" displayname="alm Uninstalled application Count" aggregationtype="gauge" datatype= "integer" cluster="true" description="number of applications uninstalled in ALM"> <property name="sqlstatement" value="select count(*) from alm_db_user. command_history where Operation = 'Uninstall' and composite=1 and state=7"/> <counter datasource="hsmjdbcdatasource" name="alm.application.uninstalled.rate" displayname="alm Uninstalled applications Count Rate" aggregationtype="counter" clustercalculation="sum" cluster="true" description="speed of application uninstallation in ALM" unit="apps/ sec"> <property name="sqlstatement" value="select count(*) from alm_db_user. command_history where Operation = 'Uninstall' and composite=1 and state=7"/> <!-- end jdbc counters--> <!-- JMX Counters--> <!-- Invalid Logins and User Lock Out JMX counters--> <counter datasource="jmxdatasource" name="invalid.login.attempts.total.count" displayname="invalid Login Attempts Total Count" aggregationtype="gauge" datatype= "integer" clustercalculation="sum" cluster="true" description="invalid login attempt occured on the current server"> <property name="objectname" value="com.bea:serverruntime=${managedservername},name= UserLockoutManager,Type=UserLockoutManagerRuntime,RealmRuntime=myrealm, ServerSecurityRuntime=${managedServerName}"/> <property name="attribute" value="invalidloginattemptstotalcount"/> <counter datasource="jmxdatasource" name="user.lockout.total.count" displayname="user Lock out Total Count" aggregationtype="gauge" datatype="integer" clustercalculation= "sum" cluster="true" description="indicates how many user locking out process is executed on the current server" > <property name="objectname" value="com.bea:serverruntime=${managedservername},name= UserLockoutManager,Type=UserLockoutManagerRuntime,RealmRuntime=myrealm, ServerSecurityRuntime=${managedServerName}"/> <property name="attribute" value="userlockouttotalcount"/> <!-- end Invalid Logins and User Lock Out JMX counters--> Sample XML Configuration File 55

<!-- Multicast JMX counters--> <counter datasource="jmxdatasource" name="multicast.pending.requests" displayname= "Multicast Pending Requests" aggregationtype="gauge" datatype="integer" clustercalculation="sum" cluster="true" warningthreshold="500" criticalthreshold="1000" description="multicast pending request count"> <property name="objectname" value="com.bea:serverruntime=${managedservername},name= Multicast,Type=WorkManagerRuntime"/> <property name="attribute" value="pendingrequests"/> <counter datasource="jmxdatasource" name="multicast.completed.requests" displayname= "Multicast Completed Requests" aggregationtype="counter" clustercalculation="sum" cluster="true" unit="request/sec" description="multicast completed request count"> <property name="objectname" value="com.bea:serverruntime=${managedservername},name= Multicast,Type=WorkManagerRuntime"/> <property name="attribute" value="completedrequests"/> <counter datasource="jmxdatasource" name="multicast.cluster.messages.lost.count" displayname="cluster Multicast Lost Messages Rate" aggregationtype="counter" clustercalculation="avg" cluster="true" unit="request/inform" description="cluster Multicast lost message rate"> <property name="objectname" value="com.bea:serverruntime=${managedservername},name= HDMCluster,Type=ClusterRuntime"/> <property name="attribute" value="multicastmessageslostcount"/> <!-- end Multicast JMX counters--> <!-- JMS JMX counters--> <!--counter datasource="jmxdatasource" name="jms.inform.events.pending.count" displayname="pending Inform Event Count" aggregationtype="gauge" clustercalculation= "sum" datatype="integer" cluster="true" warningthreshold="500" criticalthreshold="1000" description="the current number of messages pending (unacknowledged or uncommitted) stored on deviceeventqueue JMS destination for the current server"> <property name="objectname" value="com.bea:jmsserverruntime=${managedservername}_jms, Name=hdm-jms-module!${managedServerName}_jms@motive/jms/deviceEventQueue,ServerRuntime= ${managedservername},type=jmsdestinationruntime"/> <property name="attribute" value="messagespendingcount"/> <counter datasource="jmxdatasource" name="jms.inform.events.current.count" displayname= "Current Stored Inform Event Count" aggregationtype="gauge" clustercalculation="sum" datatype="integer" cluster="true" warningthreshold="1000" criticalthreshold="5000" description="the current number of messages stored on deviceeventqueue JMS destination for the current server"> <property name="objectname" value="com.bea:jmsserverruntime=${managedservername}_jms, Name=hdm-jms-module!${managedServerName}_jms@motive/jms/deviceEventQueue,ServerRuntime= ${managedservername},type=jmsdestinationruntime"/> <property name="attribute" value="messagescurrentcount"/> </counter--> 56 Administering the Dashboard Console

<!-- end JMS JMX counters--> <!-- JTA JMX counters--> <counter datasource="jmxdatasource" name="jta.active.tx.count" displayname="active Transaction Total Count" aggregationtype="gauge" clustercalculation="sum" datatype= "integer" cluster="true" description="the total number of active transacions on the server"> <property name="objectname" value="com.bea:name=jtaruntime,serverruntime= ${managedservername},type=jtaruntime"/> <property name="attribute" value="activetransactionstotalcount"/> <counter datasource="jmxdatasource" name="jta.committed.tx.rate" displayname= "Committed Transaction Rate" aggregationtype="counter" clustercalculation="sum" cluster= "true" description="total number of transactions committed by this server"> <property name="objectname" value="com.bea:name=jtaruntime,serverruntime= ${managedservername},type=jtaruntime"/> <property name="attribute" value="transactioncommittedtotalcount"/> <counter datasource="jmxdatasource" name="jta.rolledback.tx.rate" displayname="rolled Back Transaction Rate" aggregationtype="counter" clustercalculation="sum" cluster= "true" description="total number of transactions rolled back by this server"> <property name="objectname" value="com.bea:name=jtaruntime,serverruntime= ${managedservername},type=jtaruntime"/> <property name="attribute" value="transactionrolledbacktotalcount"/> <!-- end JTA JMX counters--> <!-- JDBC JMX counters--> <!--counter datasource="jmxdatasource" name="jdbc.active.current.connections.count" displayname="current Active JDBC Connection Count" datatype="integer" aggregationtype= "gauge" clustercalculation="sum" description="the number of connections currently in use by applications"> <property name="objectname" value="com.bea:applicationruntime=hdmjdbcpool,name= HDMJDBCPool,ServerRuntime=${managedServerName},Type=JDBCDataSourceRuntime"/> <property name="attribute" value="activeconnectionscurrentcount"/> <counter datasource="jmxdatasource" name="jdbc.active.high.connections.count" displayname="highest Active JDBC Connection Count" aggregationtype="gauge" datatype= "integer" description="highest number of active database connections in this instance of the data source since the data source was instantiated"> <property name="objectname" value="com.bea:applicationruntime=hdmjdbcpool,name= HDMJDBCPool,ServerRuntime=${managedServerName},Type=JDBCDataSourceRuntime"/> <property name="attribute" value="activeconnectionshighcount"/> </counter--> <!-- end JDBC JMX counters--> Sample XML Configuration File 57

<!-- JVM JMX counters--> <counter datasource="jmxdatasource" name="jvm.free.heap.size" displayname="jvm Heap Free Size" aggregationtype="gauge" expression="round(${jvm.free.heap.size}/1048576)" unit="mb" cluster="true" description="current JVM heap free size"> <property name="objectname" value="com.bea:name=${managedservername},serverruntime= ${managedservername},type=jvmruntime"/> <property name="attribute" value="heapfreecurrent"/> <counter datasource="jmxdatasource" name="jvm.heap.size" displayname="jvm Heap Size" aggregationtype="gauge" expression="round(${jvm.heap.size}/1048576)" unit="mb" cluster= "true" description="current JVM heap size"> <property name="objectname" value="com.bea:name=${managedservername},serverruntime= ${managedservername},type=jvmruntime"/> <property name="attribute" value="heapsizecurrent"/> <counter datasource="jmxdatasource" name="jvm.max.heap.size" displayname="jvm Heap Size Max" aggregationtype="gauge" expression="round(${jvm.max.heap.size}/1048576)" unit="mb" cluster="true" description="jvm heap maximum size"> <property name="objectname" value="com.bea:name=${managedservername},serverruntime= ${managedservername},type=jvmruntime"/> <property name="attribute" value="heapsizemax"/> <counter datasource="jmxdatasource" name="jvm.heap.free.percent" displayname="jvm Heap Free Percent" aggregationtype="gauge" expression="round(${jvm.heap.free.percent}) " unit="%" cluster="true" description="jvm heap free percentage" warningthreshold="25" criticalthreshold="5"> <property name="objectname" value="com.bea:name=${managedservername},serverruntime= ${managedservername},type=jvmruntime"/> <property name="attribute" value="heapfreepercent"/> <!-- end JVM JMX counters--> <!-- Thread JMX counters--> <counter datasource="jmxdatasource" name="thread.idle.count" displayname="thread Idle Count" aggregationtype="gauge" datatype="integer" clustercalculation="sum" cluster= "true" description="thread idle count"> <property name="objectname" value="com.bea:name=threadpoolruntime,serverruntime= ${managedservername},type=threadpoolruntime"/> <property name="attribute" value="executethreadidlecount"/> <counter datasource="jmxdatasource" name="thread.total.count" displayname="thread Total Count" aggregationtype="gauge" clustercalculation="sum" datatype="integer" cluster= "true" description="thread total count"> <property name="objectname" value="com.bea:name=threadpoolruntime,serverruntime= ${managedservername},type=threadpoolruntime"/> 58 Administering the Dashboard Console

<property name="attribute" value="executethreadtotalcount"/> <counter datasource="jmxdatasource" name="thread.pending.request.count" displayname= "Thread Pending Request Count" aggregationtype="gauge" datatype="integer" cluster= "true" warningthreshold="500" criticalthreshold="1000" description="thread pending request count"> <property name="objectname" value="com.bea:name=threadpoolruntime,serverruntime= ${managedservername},type=threadpoolruntime"/> <property name="attribute" value="pendinguserrequestcount"/> <counter datasource="jmxdatasource" name="thread.queue.length" displayname="thread Queue Length" aggregationtype="gauge" cluster="true" warningthreshold="500" criticalthreshold="1000" description="thread queue length"> <property name="objectname" value="com.bea:name=threadpoolruntime,serverruntime= ${managedservername},type=threadpoolruntime"/> <property name="attribute" value="queuelength"/> <counter datasource="jmxdatasource" name="thread.standby.count" displayname="stand By Thread Rate" aggregationtype="counter" clustercalculation="sum" cluster="true" unit= "thread/sec" description="stand by Thread rate"> <property name="objectname" value="com.bea:name=threadpoolruntime,serverruntime= ${managedservername},type=threadpoolruntime"/> <property name="attribute" value="standbythreadcount"/> <counter datasource="jmxdatasource" name="thread.throughput" displayname="thread Throughput" aggregationtype="gauge" cluster="true" description="thread throughput"> <property name="objectname" value="com.bea:name=threadpoolruntime,serverruntime= ${managedservername},type=threadpoolruntime"/> <property name="attribute" value="throughput"/> <!-- <counter datasource="jmxdatasource" name="thread.completed.request.rate" displayname="thread Completed Request Count" aggregationtype="counter" clustercalculation="sum" cluster="true"> <property name="objectname" value="com.bea:name=threadpoolruntime,serverruntime= ${managedservername},type=threadpoolruntime"/> <property name="attribute" value="completedrequestcount"/> <counter datasource="jmxdatasource" name="thread.min.constraints.completed.rate" displayname="thread Min Constraints Completed Rate" aggregationtype="counter" cluster= "true"> <property name="objectname" value="com.bea:name=threadpoolruntime,serverruntime= ${managedservername},type=threadpoolruntime"/> <property name="attribute" value="minthreadsconstraintscompleted"/> <counter datasource="jmxdatasource" name="thread.min.constraints.pending.count" displayname="thread Min Constraints Pending Count" aggregationtype="gauge" datatype= "integer" cluster="true"> <property name="objectname" value="com.bea:name=threadpoolruntime,serverruntime= Sample XML Configuration File 59

${managedservername},type=threadpoolruntime"/> <property name="attribute" value="minthreadsconstraintspending"/> --> <!-- end Thread JMX counters--> <!-- Channel (http / https) JMX counters--> <counter datasource="jmxdatasource" name="http.accept.count" displayname="http Accept Count" aggregationtype="gauge" datatype="integer" cluster="true" description="accepted http request count"> <property name="objectname" value="com.bea:name=default[http],serverruntime= ${managedservername},type=serverchannelruntime"/> <property name="attribute" value="acceptcount"/> <counter datasource="jmxdatasource" name="http.connections.count" displayname="http Connection Count" aggregationtype="gauge" datatype="integer" cluster="true" description="http request count"> <property name="objectname" value="com.bea:name=default[http],serverruntime= ${managedservername},type=serverchannelruntime"/> <property name="attribute" value="connectionscount"/> <counter datasource="jmxdatasource" name="http.received.messages.rate" displayname= "Http Received Message Rate" aggregationtype="counter" clustercalculation="sum" cluster= "true" unit="message/sec" description="http received message rate"> <property name="objectname" value="com.bea:name=default[http],serverruntime= ${managedservername},type=serverchannelruntime"/> <property name="attribute" value="messagesreceivedcount"/> <counter datasource="jmxdatasource" name="http.messages.sent.rate" displayname="http Sent Message Rate" aggregationtype="counter" clustercalculation="sum" cluster="true" unit="message/sec" description="http sent message rate"> <property name="objectname" value="com.bea:name=default[http],serverruntime= ${managedservername},type=serverchannelruntime"/> <property name="attribute" value="messagessentcount"/> <counter datasource="jmxdatasource" name="https.accept.count" displayname="https Accept Count" aggregationtype="gauge" datatype="integer" cluster="true" description="https message accept count"> <property name="objectname" value="com.bea:name=defaultsecure[https],serverruntime= ${managedservername},type=serverchannelruntime"/> <property name="attribute" value="acceptcount"/> <counter datasource="jmxdatasource" name="https.connections.count" displayname="https Connection Count" aggregationtype="gauge" datatype="integer" cluster="true" description="https connection count"> <property name="objectname" value="com.bea:name=defaultsecure[https],serverruntime= ${managedservername},type=serverchannelruntime"/> <property name="attribute" value="connectionscount"/> 60 Administering the Dashboard Console

<counter datasource="jmxdatasource" name="https.received.messages.rate" displayname= "Https Received Message Rate" aggregationtype="counter" clustercalculation="sum" cluster= "true" description="https received message rate"> <property name="objectname" value="com.bea:name=defaultsecure[https],serverruntime= ${managedservername},type=serverchannelruntime"/> <property name="attribute" value="messagesreceivedcount"/> <counter datasource="jmxdatasource" name="https.messages.sent.rate" displayname= "Https Sent Message Rate" aggregationtype="counter" clustercalculation="sum" cluster= "true" description="https sent message rate"> <property name="objectname" value="com.bea:name=defaultsecure[https],serverruntime= ${managedservername},type=serverchannelruntime"/> <property name="attribute" value="messagessentcount"/> <!-- end Channel JMX counters--> <!-- Socket JMX counters--> <counter datasource="jmxdatasource" name="socket.count" displayname="current Open Socket Count" aggregationtype="gauge" clustercalculation="sum" datatype="integer" warningthreshold="5000" criticalthreshold="10000" cluster="true" description="current open socket count"> <property name="objectname" value="com.bea:name=${managedservername},type= ServerRuntime"/> <property name="attribute" value="opensocketscurrentcount"/> <!-- end Socket JMX counters--> <!-- GC JMX counters--> <!-- <counter datasource="jmxdatasource" name="gc.count" displayname="jvm Garbage Collection Count" aggregationtype="gauge" datatype="integer" cluster="true"> <property name="objectname" value="java.lang:name=copy,type=garbagecollector"/> <property name="attribute" value="collectioncount"/> <counter datasource="jmxdatasource" name="gc.collection.time.avg" displayname="jvm Garbage Collection Average Time" aggregationtype="gauge" cluster="true"> <property name="objectname" value="java.lang:name=copy,type=garbagecollector"/> <property name="attribute" value="collectiontime"/> <counter datasource="jmxdatasource" name="gc.full.count" displayname="jvm Full Garbage Collection Count" aggregationtype="gauge" datatype="integer" cluster="true"> <property name="objectname" value="java.lang:name=marksweepcompact,type= GarbageCollector"/> <property name="attribute" value="collectioncount"/> <counter datasource="jmxdatasource" name="gc.full.collection.time.avg" displayname= "JVM Full Garbage Collection Average Time" aggregationtype="gauge" cluster="true"> <property name="objectname" value="java.lang:name=marksweepcompact,type= GarbageCollector"/> <property name="attribute" value="collectiontime"/> --> Sample XML Configuration File 61

<!-- end GC JMX counters--> <!-- end JMX Counters--> <!-- HDM Counters--> <!-- Java Platform Counters--> <!-- GC Platform Counterss--> <counter datasource="javaplatformdatasource" name="gc.count" displayname="jvm Garbage Collection Count" aggregationtype="gauge" datatype="integer" cluster="true" description="jvm garbage collection count"> <property name="objectname" value="java.lang:name=copy,type=garbagecollector"/> <property name="attribute" value="collectioncount"/> <counter datasource="javaplatformdatasource" name="gc.collection.time.avg" displayname= "JVM Garbage Collection Average Time" aggregationtype="gauge" cluster="true" unit="ms" description="jvm garbage collection average time"> <property name="objectname" value="java.lang:name=copy,type=garbagecollector"/> <property name="attribute" value="collectiontime"/> <counter datasource="javaplatformdatasource" name="gc.full.count" displayname="jvm Full Garbage Collection Count" aggregationtype="gauge" datatype="integer" cluster= "true" description="jvm garbage full collection count"> <property name="objectname" value="java.lang:name=marksweepcompact,type= GarbageCollector"/> <property name="attribute" value="collectioncount"/> <counter datasource="javaplatformdatasource" name="gc.full.collection.time.avg" displayname="jvm Full Garbage Collection Average Time" aggregationtype="gauge" cluster= "true" unit="ms" description="jvm full garbage collection average time"> <property name="objectname" value="java.lang:name=marksweepcompact,type= GarbageCollector"/> <property name="attribute" value="collectiontime"/> <!-- end GC Platform Counters--> <!-- OS Platform Counters--> <counter datasource="javaplatformdatasource" name="os.available.processer.count" displayname="os Available Processer Count" aggregationtype="gauge" datatype="integer" cluster="true" description="processour count of current machine where Dashboard is running"> <property name="objectname" value="java.lang:type=operatingsystem"/> <property name="attribute" value="availableprocessors"/> <counter datasource="javaplatformdatasource" name="os.committed.virtual.memory" displayname="os Committed Virtual Memory Size" aggregationtype="gauge" datatype= "integer" cluster="true" unit="mb" expression="round(${os.committed.virtual.memory}/ 1048576)" description="the amount of virtual memory guaranteed to be available to the running process"> 62 Administering the Dashboard Console

<property name="objectname" value="java.lang:type=operatingsystem"/> <property name="attribute" value="committedvirtualmemorysize"/> <counter datasource="javaplatformdatasource" name="os.free.physical.memory" displayname="os Free Physical Memory Size" aggregationtype="gauge" datatype="integer" warningthreshold="1024" criticalthreshold="512" cluster="true" unit="mb" expression= "round(${os.free.physical.memory}/1048576)" description="amount of free physical memory"> <property name="objectname" value="java.lang:type=operatingsystem"/> <property name="attribute" value="freephysicalmemorysize"/> <counter datasource="javaplatformdatasource" name="os.total.physical.memory" displayname="os Total Physical Memory Size" aggregationtype="gauge" datatype="integer" cluster="true" unit="gb" expression="round(${os.total.physical.memory}/1073741824)" description="amount of total physical memory"> <property name="objectname" value="java.lang:type=operatingsystem"/> <property name="attribute" value="totalphysicalmemorysize"/> <counter datasource="javaplatformdatasource" name="os.free.swap.space" displayname= "OS Free Swap Space Size" aggregationtype="gauge" datatype="integer" cluster="true" unit="mb" expression="round(${os.free.swap.space}/1048576)" description="amount of free swap space"> <property name="objectname" value="java.lang:type=operatingsystem"/> <property name="attribute" value="freeswapspacesize"/> <counter datasource="javaplatformdatasource" name="os.total.swap.space" displayname= "OS Total Swap Space Size" aggregationtype="gauge" datatype="integer" cluster="true" unit="mb" expression="round(${os.total.swap.space}/1048576)" description="amount of total swap space"> <property name="objectname" value="java.lang:type=operatingsystem"/> <property name="attribute" value="totalswapspacesize"/> <counter datasource="javaplatformdatasource" name="os.max.file.descriptor" displayname= "OS Max File Descriptor Count" aggregationtype="gauge" datatype="integer" cluster="true" description="number of maximum file descriptors allowed"> <property name="objectname" value="java.lang:type=operatingsystem"/> <property name="attribute" value="maxfiledescriptorcount"/> <counter datasource="javaplatformdatasource" name="os.open.file.descriptor" displayname="os Open File Descriptor Count" aggregationtype="gauge" datatype="integer" cluster="true" description="number of open file descriptors"> <property name="objectname" value="java.lang:type=operatingsystem"/> <property name="attribute" value="openfiledescriptorcount"/> <counter datasource="javaplatformdatasource" name="os.process.cpu.time" displayname= "Total CPU Consumed Time By Current Server Process" aggregationtype="gauge" datatype= "integer" cluster="true" expression="round(${os.process.cpu.time}/1000000000)" unit="sec" description="total amount of time that current server process has actively used CPU( Sample XML Configuration File 63

s)"> <property name="objectname" value="java.lang:type=operatingsystem"/> <property name="attribute" value="processcputime"/> <!-- end OS Platform Counters--> <!-- end Java Platform Counters--> <!-- OS Counters--> <!-- commented out since the counters consume memory to be executed. <counter datasource="osdatasource" name="os.disk.busy" displayname="os Disk Busy" aggregationtype="gauge" unit="%" > <property name="bash" value="/usr/bin/iostat -xd sd3 1 2 /usr/bin/tail -1 awk '{print $10}'"/> <counter datasource="osdatasource" name="os.disk.service.time" displayname="os Disk Service Time" aggregationtype="gauge" unit="ms" > <property name="bash" value="/usr/bin/iostat -xd sd3 1 2 /usr/bin/tail -1 awk '{print $8}' awk -F"." '{print $1}'"/> <counter datasource="osdatasource" name="os.load.average.1" displayname="os Load Average [1 min]" aggregationtype="gauge" expression="${os.load.average.1}/100" > <property name="bash" value="/usr/bin/prstat 1 2 /usr/bin/tail -1 awk '{print $8}' awk -F"," '{print $1}' awk '{print expr $1*100}'"/> <counter datasource="osdatasource" name="os.load.average.5" displayname="os Load Average [5 min]" aggregationtype="gauge" expression="${os.load.average.5}/100" > <property name="bash" value="/usr/bin/prstat 1 2 /usr/bin/tail -1 awk '{print $9}' awk -F"," '{print $1}' awk '{print expr $1*100}'"/> <counter datasource="osdatasource" name="os.load.average.15" displayname="os Load Average [15 min]" aggregationtype="gauge" expression="${os.load.average.15}/100" > <property name="bash" value="/usr/bin/prstat 1 2 /usr/bin/tail -1 awk '{print $10}' awk -F"," '{print $1}' awk '{print expr $1*100}'"/> <counter datasource="osdatasource" name="os.nlwp" displayname="the number of light weight processes (threads) of Server Process " aggregationtype="gauge" role= "DASHBOARD_SYSTEM_INFO"> <property name="bash" value="/usr/bin/ps -p $PPID -fo nlwp /usr/bin/egrep -v NLWP awk '{print $1}'"/> <counter datasource="osdatasource" name="os.rss" displayname="the resident set size of Server Process" aggregationtype="gauge" unit="mb" expression="round(${os.rss}/1048576) " role="dashboard_system_info"> <property name="sh" value="/usr/bin/ps -p ${processid} -fo rss /usr/bin/egrep -v RSS awk '{print $1}'"/> <counter datasource="osdatasource" name="os.vsz" displayname="the virtual set size of Server Process" aggregationtype="gauge" unit="mb" expression="round(${os.vsz}/1048576) " role="dashboard_system_info"> <property name="bash" value="/usr/bin/ps -p $PPID -fo vsz /usr/bin/egrep -v VSZ awk '{print $1}'"/> <counter datasource="osdatasource" name="os.pmem" displayname="the percentage of memory of Server Process" aggregationtype="gauge" unit="%" > 64 Administering the Dashboard Console

<property name="bash" value="/usr/bin/ps -p $PPID -fo pmem /usr/bin/egrep -v PMEM awk '{print $1}'"/> <counter datasource="osdatasource" name="os.pcpu" displayname="the percentage of CPU time of Server Process" aggregationtype="gauge" unit="%" > <property name="bash" value="/usr/bin/ps -p $PPID -fo pcpu /usr/bin/grep -v PCPU awk '{print $1}'"/> <counter datasource="osdatasource" name="os.cpu.user" displayname="os CPU User" aggregationtype="gauge" > <property name="bash" value="/usr/bin/vmstat 1 2 /usr/bin/tail -1 awk '{print $20}'"/> <counter datasource="osdatasource" name="os.cpu.system" displayname="os CPU System" aggregationtype="gauge" > <property name="bash" value="/usr/bin/vmstat 1 2 /usr/bin/tail -1 awk '{print $21}'"/> <counter datasource="osdatasource" name="os.open.files" displayname="open files" aggregationtype="gauge" > <property name="bash" value="/usr/bin/netstat -an wc -l"/> --> <!-- end OS Counters--> <!-- Expression Counters Counters--> <!-- end Expression Counters Counters--> <!-- CWMP Traffic Manager counters --> <!-- <counter datasource="trafficmgrdatasource" name="trafficmgr.bootstrap.deflected" displayname="trafficmanager Deflected Rate [Bootstrap]" aggregationtype= "counter" cluster="true"> <property name="regex" value="bootstrap=([\d \.]+)[:]*([\d \.]*)"/> <property name="field" value="1"/> <counter datasource="trafficmgrdatasource" name="trafficmgr.boot.deflected" displayname="trafficmanager Deflected Rate [Boot]" aggregationtype="counter" cluster="true"> <property name="regex" value="boot=([\d \.]+)[:]*([\d \.]*)"/> <property name="field" value="1"/> <counter datasource="trafficmgrdatasource" name="trafficmgr.cr.deflected" displayname="trafficmanager Deflected Rate [ConnectionRequest]" aggregationtype="counter" cluster="true"> <property name="regex" value="connection Requests=([\d \.]+)[:]*([\d \.]*)"/> <property name="field" value="1"/> <counter datasource="trafficmgrdatasource" name="trafficmgr.tc.deflected" displayname="trafficmanager Deflected Rate [TransferComplete]" aggregationtype= "counter" cluster="true"> <property name="regex" value="transfer Complete=([\d \.]+)[:]*([\d \.]*)"/> <property name="field" value="1"/> Sample XML Configuration File 65

<counter datasource="trafficmgrdatasource" name="trafficmgr.dc.deflected" displayname="trafficmanager Deflected Rate [DiagnosticsComplete]" aggregationtype="counter" cluster="true"> <property name="regex" value="diagnostics Complete=([\d \.]+)[:]*([\d \.]*)"/> <property name="field" value="1"/> <counter datasource="trafficmgrdatasource" name="trafficmgr.si.deflected" displayname="trafficmanager Deflected Rate [ScheduledInform]" aggregationtype= "counter" cluster="true"> <property name="regex" value="scheduled Inform=([\d \.]+)[:]*([\d \.]*)"/> <property name="field" value="1"/> <counter datasource="trafficmgrdatasource" name="trafficmgr.ki.deflected" displayname="trafficmanager Deflected Rate [KickedInform]" aggregationtype= "counter" cluster="true"> <property name="regex" value="kicked Inform=([\d \.]+)[:]*([\d \.]*)"/> <property name="field" value="1"/> <counter datasource="trafficmgrdatasource" name="trafficmgr.pvc.deflected" displayname="trafficmanager Deflected Rate [Prioritized ValueChange]" aggregationtype="counter" cluster="true"> <property name="regex" value="prioritized Value Change=([\d \.]+)[:]*([\d \. ]*)"/> <property name="field" value="1"/> <counter datasource="trafficmgrdatasource" name="trafficmgr.vc.deflected" displayname="trafficmanager Deflected Rate [ValueChange]" aggregationtype= "counter" cluster="true"> <property name="regex" value="value Change=([\d \.]+)[:]*([\d \.]*)"/> <property name="field" value="1"/> <counter datasource="trafficmgrdatasource" name="trafficmgr.periodic.deflected" displayname="trafficmanager Deflected Rate [Periodic]" aggregationtype= "counter" cluster="true"> <property name="regex" value="periodic Inform=([\d \.]+)[:]*([\d \.]*)"/> <property name="field" value="1"/> <counter datasource="trafficmgrdatasource" name="trafficmgr.atc.deflected" displayname="trafficmanager Deflected Rate [AutonomousTransferComplete]" aggregationtype="counter" cluster="true"> <property name="regex" value="autonomous Transfer Complete=([\d \.]+)[:]*([\ d \.]*)"/> <property name="field" value="1"/> <counter datasource="trafficmgrdatasource" name="trafficmgr.total.deflected" displayname="trafficmanager Deflected Rate [Total]" aggregationtype="counter" cluster="true"> <property name="regex" value="total=([\d \.]+)[:]*([\d \.]*)"/> <property name="field" value="1"/> <counter datasource="trafficmgrdatasource" name="trafficmgr.bootstrap.tunnelled" displayname="trafficmanager Tunnelled Rate [Bootstrap]" aggregationtype= "counter" cluster="true"> <property name="regex" value="bootstrap=([\d \.]+)[:]*([\d \.]*)"/> <property name="field" value="2"/> 66 Administering the Dashboard Console

<counter datasource="trafficmgrdatasource" name="trafficmgr.boot.tunnelled" displayname="trafficmanager Tunnelled Rate [Boot]" aggregationtype= "counter" cluster="true"> <property name="regex" value="boot=([\d \.]+)[:]*([\d \.]*)"/> <property name="field" value="2"/> <counter datasource="trafficmgrdatasource" name="trafficmgr.cr.tunnelled" displayname="trafficmanager Tunnelled Rate [ConnectionRequest]" aggregationtype="counter" cluster="true"> <property name="regex" value="connection Requests=([\d \.]+)[:]*([\d \.]*)"/> <property name="field" value="2"/> <counter datasource="trafficmgrdatasource" name="trafficmgr.tc.tunnelled" displayname="trafficmanager Tunnelled Rate [TransferComplete]" aggregationtype="counter" cluster="true"> <property name="regex" value="transfer Complete=([\d \.]+)[:]*([\d \.]*)"/> <property name="field" value="2"/> <counter datasource="trafficmgrdatasource" name="trafficmgr.dc.tunnelled" displayname="trafficmanager Tunnelled Rate [DiagnosticsComplete]" aggregationtype="counter" cluster="true"> <property name="regex" value="diagnostics Complete=([\d \.]+)[:]*([\d \.]*)"/> <property name="field" value="2"/> <counter datasource="trafficmgrdatasource" name="trafficmgr.si.tunnelled" displayname="trafficmanager Tunnelled Rate [ScheduledInform]" aggregationtype="counter" cluster="true"> <property name="regex" value="scheduled Inform=([\d \.]+)[:]*([\d \.]*)"/> <property name="field" value="2"/> <counter datasource="trafficmgrdatasource" name="trafficmgr.ki.tunnelled" displayname="trafficmanager Tunnelled Rate [KickedInform]" aggregationtype= "counter" cluster="true"> <property name="regex" value="kicked Inform=([\d \.]+)[:]*([\d \.]*)"/> <property name="field" value="2"/> <counter datasource="trafficmgrdatasource" name="trafficmgr.pvc.tunnelled" displayname="trafficmanager Tunnelled Rate [Prioritized ValueChange]" aggregationtype="counter" cluster="true"> <property name="regex" value="prioritized Value Change=([\d \.]+)[:]*([\d \. ]*)"/> <property name="field" value="2"/> <counter datasource="trafficmgrdatasource" name="trafficmgr.vc.tunnelled" displayname="trafficmanager Tunnelled Rate [ValueChange]" aggregationtype= "counter" cluster="true"> <property name="regex" value="value Change=([\d \.]+)[:]*([\d \.]*)"/> <property name="field" value="2"/> <counter datasource="trafficmgrdatasource" name="trafficmgr.periodic.tunnelled" displayname="trafficmanager Tunnelled Rate [Periodic]" aggregationtype= "counter" cluster="true"> <property name="regex" value="periodic Inform=([\d \.]+)[:]*([\d \.]*)"/> <property name="field" value="2"/> <counter datasource="trafficmgrdatasource" name="trafficmgr.atc.tunnelled" displayname="trafficmanager Tunnelled Rate [AutonomousTransferComplete]" aggregationtype="counter" cluster="true"> Sample XML Configuration File 67

<property name="regex" value="autonomous Transfer Complete=([\d \.]+)[:]*([\ d \.]*)"/> <property name="field" value="2"/> <counter datasource="trafficmgrdatasource" name="trafficmgr.total.tunnelled" displayname="trafficmanager Tunnelled Rate [Total]" aggregationtype= "counter" cluster="true"> <property name="regex" value="total=([\d \.]+)[:]*([\d \.]*)"/> <property name="field" value="2"/> <counter datasource="trafficmgrdatasource" name="trafficmgr.current.connections" displayname="trafficmanager Current Connections" aggregationtype="gauge" cluster="true"> <property name="regex" value="currentconnections=([\d \.]+)"/> <property name="field" value="1"/> <counter datasource="trafficmgrdatasource" name="trafficmgr.max.connections" displayname="trafficmanager Max Connections" aggregationtype="gauge" cluster= "true"> <property name="regex" value="maxconnections=([\d \.]+)"/> <property name="field" value="1"/> <counter datasource="trafficmgrdatasource" name="trafficmgr.average.sessiontime" unit="sec" displayname="trafficmanager Average HDM Response Time" aggregationtype="gauge" cluster="true"> <property name="regex" value="average Session Time=([\d \. \d]+)"/> <property name="field" value="1"/> <counter datasource="trafficmgrdatasource" name="trafficmgr.session.errors" displayname="trafficmanager HDM Session Error Rate" aggregationtype="counter" cluster="true"> <property name="regex" value="session Errors=([\d \.]+)"/> <property name="field" value="1"/> --> <!-- WL Proxy module counters --> <!-- <counter datasource="wlproxydatasource" name="wlproxy.requests" displayname="weblogic Proxy Total Requests Rate" aggregationtype="counter" cluster="true"> <property name="regex" value="<li>requests: <b>([\d \.]+)"/> <property name="field" value="1"/> <counter datasource="wlproxydatasource" name="wlproxy.requests.successful" displayname="weblogic Proxy Successful Requests Rate" aggregationtype= "counter" cluster="true"> <property name="regex" value="<li>successful requests: <b>([\d \. ]+)"/> <property name="field" value="1"/> --> <!-- Apache server counters --> 68 Administering the Dashboard Console

<!-- <counter datasource="apachedatasource" name="apache.requests" displayname="apache HTTP Request Rate" aggregationtype="gauge" cluster= "true"> <property name="regex" value="reqpersec: ([\d \. \d]+)"/> <property name="field" value="1"/> <counter datasource="apachedatasource" name="apache.bytespersec" unit="kb/s" displayname="apache Bandwidth Usage" aggregationtype="gauge" cluster="true" expression="${apache.bytespersec}/1024.0"> <property name="regex" value="bytespersec: ([\d \. \d]+)"/> <property name="field" value="1"/> --> </counters> <displayinfoes> <displayinfo context="application"> <groups> <group displayname="invalid Logins and User Lock outs "> <counter name="invalid.login.attempts.total.count" /> <counter name="user.lockout.total.count"/> </group> <group displayname="multicast"> <counter name="multicast.pending.requests" /> <counter name="multicast.completed.requests"/> <counter name="multicast.cluster.messages.lost.count"/> </group> <group displayname="alm"> <counter name="alm.device.count" summary="true"/> <counter name="alm.device.count.rate"/> <counter name="alm.device.active.count"/> <counter name="alm.device.active.count.rate"/> </group> <group displayname="alm Applications"> <counter name="alm.application.count" summary="true"/> <counter name="alm.application.count.rate"/> <counter name="alm.application.started.count"/> <counter name="alm.application.started.rate"/> <counter name="alm.application.updated.count"/> <counter name="alm.application.updated.rate"/> <counter name="alm.application.uninstalled.count"/> <counter name="alm.application.uninstalled.rate"/> </group> <group displayname="jta"> <counter name="jta.committed.tx.rate"/> <counter name="jta.rolledback.tx.rate"/> </group> </groups> <graphs> <graph displayname="alm device graphs" summary="true" type="line"> <counter name="alm.device.count"/> <counter name="alm.device.active.count"/> </graph> Sample XML Configuration File 69

<graph displayname="alm device rates graphs" summary="true" type="line"> <counter name="alm.device.count.rate"/> <counter name="alm.device.active.count.rate"/> </graph> <graph displayname="alm application graphs" summary="true" type="line"> <counter name="alm.application.count"/> <counter name="alm.application.started.count"/> <counter name="alm.application.updated.count"/> <counter name="alm.application.uninstalled.count"/> </graph> <graph displayname="alm application rates graphs" summary="true" type="line"> <counter name="alm.application.count.rate"/> <counter name="alm.application.started.rate"/> <counter name="alm.application.updated.rate"/> <counter name="alm.application.uninstalled.rate"/> </graph> <graph displayname="invalid Logins and User LockOuts" type="line"> <counter name="invalid.login.attempts.total.count" /> <counter name="user.lockout.total.count"/> </graph> <graph displayname="multicast" type="line"> <counter name="multicast.pending.requests" /> <counter name="multicast.completed.requests"/> <counter name="multicast.cluster.messages.lost.count"/> </graph> </graphs> </displayinfo> <displayinfo context="system"> <groups> <group displayname="os Counters"> <counter name="os.committed.virtual.memory" summary="true"/> <counter name="os.free.physical.memory"/> <counter name="os.total.physical.memory"/> <counter name="os.free.swap.space"/> <counter name="os.total.swap.space"/> <counter name="os.max.file.descriptor"/> <counter name="os.open.file.descriptor" summary="true"/> <counter name="os.process.cpu.time" summary="true"/> </group> <group displayname="thread"> <counter name="thread.idle.count"/> <counter name="thread.total.count" summary="true"/> <counter name="thread.queue.length"/> <counter name="thread.throughput"/> <counter name="thread.pending.request.count"/> 70 Administering the Dashboard Console

<counter name="thread.standby.count"/> </group> <group displayname="channel (http / https)"> <counter name="http.accept.count" summary="true"/> <counter name="http.connections.count"/> <counter name="http.received.messages.rate"/> <counter name="http.messages.sent.rate"/> <counter name="https.accept.count" summary="true"/> <counter name="https.connections.count"/> <counter name="https.received.messages.rate"/> <counter name="https.messages.sent.rate"/> </group> <group displayname="jvm"> <counter name="jvm.free.heap.size" summary="true"/> <counter name="jvm.heap.size" summary="true"/> <counter name="jvm.max.heap.size"/> <counter name="jvm.heap.free.percent"/> <counter name="gc.count"/> <counter name="gc.collection.time.avg"/> <counter name="gc.full.count"/> <counter name="gc.full.collection.time.avg"/> </group> </groups> <graphs> <graph displayname="http Channel" summary="true" predefined="true"> <counter name="http.accept.count"/> <counter name="http.connections.count"/> <counter name="http.received.messages.rate"/> <counter name="http.messages.sent.rate"/> </graph> <graph displayname="https Channel" summary="true" predefined="true"> <counter name="https.accept.count"/> <counter name="https.connections.count"/> <counter name="https.received.messages.rate"/> <counter name="https.messages.sent.rate"/> </graph> <graph displayname="thread" summary="true" predefined="true"> <counter name="thread.idle.count"/> <counter name="thread.total.count"/> <counter name="thread.queue.length"/> </graph> <graph displayname="jvm" summary="true" predefined="true"> <counter name="jvm.free.heap.size"/> <counter name="jvm.heap.size"/> <counter name="jvm.max.heap.size"/> <counter name="jvm.heap.free.percent"/> </graph> <graph displayname="os graphs" predefined="true" type="line"> <counter name="os.process.cpu.time"/> </graph> </graphs> </displayinfo> </displayinfoes> </DashboardConfig> Sample XML Configuration File 71

Threshold Configuration In Dashboard Console, when a counter displays as red, it is considered to be in a critical state, with a negative connotation. Green is considered a healthy state, with a positive connotation. Orange is a cautionary state, between red and green. Blue is used when no thresholds are specified for a counter. And gray is used for counters without values. The dashboard-config.xml file specifies optional critical (criticalthreshold) and warning (warningthreshold) thresholds that determine which color is assigned to a counter as follows: Counter color Threshold value Indicates the counter value has triggered the critical threshold, it displays as red. Indicates the counter value is between the warning and the critical thresholds, it displays as orange. Indicates the counter value has not triggered the warning threshold, it displays as green. In the dashboard-config.xml file, either both thresholds must be defined for a counter, or no thresholds. In addition, the values for the critical and warning thresholds for a counter cannot be the same. If either of these conditions is violated, importing the configuration file will fail with a validation error for the condition. These thresholds define the state, or severity, of a metric. The severity hierarchy depends on whether the critical threshold is greater than the warning threshold, or vice-versa, as follows: criticalthreshold is greater than the warningthreshold Red --- Critical threshold --- Orange --- Warning threshold --- Green warningthreshold is greater than the criticalthreshold Green --- Warning threshold --- Orange --- Critical threshold --- Red Consider the following example counter definition where both thresholds are defined: <counter datasource="jdbcdatasource" name="device.count" displayname="device Count" aggregationtype="gauge" datatype="integer" warningthreshold="300" criticalthreshold="3000" expression="${device. count}*10" cluster="true"> <property name="sqlstatement" value="select count(*) from device where deleted 72 Administering the Dashboard Console

= 0"/> The counter device.count defines both thresholds (warningthreshold="300" criticalthreshold="3000"). The critical threshold is greater than the warning threshold, so the counter displays as follows, depending on the counter metric: > 3000. The counter displays as red given the value has triggered the critical threshold (3000). 301-3000. The counter displays as orange given the value is between the warning and the critical thresholds (300-3000). <= 300. The counter displays as green given the value has not triggered the warning threshold (300). Uploading and downloading the configuration file To upload the configuration file 1. Open the Dashboard Console. 2. On the Welcome tab, click Manage Configuration. 3. In the Upload and Download Configuration dialog box, enter the path and file name of the configuration file or click Browse to navigate to the configuration file. 4. Click Upload to upload the configuration file to the Managed Server. The counters and graphs are displayed based on the uploaded file. Restarting the servers is unnecessary. To download the configuration file 1. On the Welcome tab, click Manage Configuration. 2. In the Upload and Download Configuration dialog box, click the Download button. 3. Click Save to save the dashboard-config.xml file in the selected folder. This configuration file can be edited and then uploaded to the server. Understanding Dashboard counters and graphs This sections describes how to configure counters and graphs. It also describes the SMP counters and the roles applicable to Dashboard Console administration. Uploading and downloading the configuration file 73

Configuring counters and graphs The dashboard-config.xml file that is automatically installed with Dashboard Console contains the configuration information for the counters and graphs that are displayed by Dashboard Console. A set of predefined counters and graphs is provided, and several of the counter groups and graphs are commented out by default. You can easily restore these, if required, by removing the comments. You can also add or remove counters and graphs as needed. Counters and graphs can be easily configured and modified by exporting (downloading), editing, and then importing (uploading) an XML configuration file via the Manage Configuration button provided in the Welcome page. Then click the respective button for the desired operation. For more information on uploading and downloading the configuration file, see Uploading and downloading the configuration file on page 73. To configure Dashboard Console counters and graphs 1. Download the installed dashboard-config.xml configuration file to a local directory on your system. 2. Edit the dashboard-config.xml file using an ASCII text editor such as Notepad or emacs. 3. Add any needed counters that are not already present in the dashboard-config.xml file. 4. Remove any counters that are not needed in the dashboard-config.xml file. 5. Adjust the thresholds for all counters as desired. 6. Perform the following for the displayinfo for each context (application and system contexts): a. Add each desired group of counters to display to the groups element, for example: <groups> <group displayname="sbi"> <counter name="inform.all" summary="true"/> <counter name="inform.latency" summary="true"/> <counter name="inform.periodic"/> <counter name="periodic.inform.percentage" summary="true"/> </group> <group displayname="policy"> <counter name="policy.testpolicy.criteriaevaluation"/> <counter name="policy.testpolicy.actionqueued"/> <counter name="policy.testpolicy.success"/> <counter name="policy.testpolicy.failure"/> </group>... </groups> This example defines the two groups SBI and Policy. Three of the counters for the SBI group are displayed in the Summary page, because they have the summary="true" attribute. b. For each group, ensure that each desired counter name to be displayed in the group is specified. 74 Administering the Dashboard Console

c. Add each desired graph to display to the graphs element, for example: <graphs> <graph displayname="inform graphs" summary="true" type="line"> <counter name="inform.all"/> <counter name="inform.periodic"/> <counter name="inform.latency"/> </graph> <graph displayname="jta" summary="true" predefined="true"> <counter name="jta.committed.tx.rate"/> <counter name="jta.rolledback.tx.rate"/> </graph>... </graphs> This example defines the two graphs: Inform graphs (line graph) and JTA (pie graph, which is the default). The Inform graphs appear in the Summary page (given summary="true"). The JTA graph appears both on the Summary and Status pages given summary="true" and predefined="true"). Counters and graphs on the Summary page are configured using the dashboard-config.xml file. Note that if a counter has an attribute summary="true", the counter is displayed on the Summary page. And if a counter has an attribute predefined="true", the counter is displayed on the Status page. d. For each graph, ensure that each desired counter name to be displayed in the graph is specified. 7. For each displayinfo (application and system contexts), confirm that the groups and graphs that are listed specify the counters and graphs for display in the Dashboard. For example: <displayinfo context="application"> <groups> <group displayname="sbi"> <counter name="inform.all" summary="true"/> <counter name="inform.latency" summary="true"/> <counter name="inform.periodic"/> <counter name="periodic.inform.percentage" summary="true"/> </group> <group displayname="policy"> <counter name="policy.testpolicy.criteriaevaluation"/> <counter name="policy.testpolicy.actionqueued"/> <counter name="policy.testpolicy.success"/> <counter name="policy.testpolicy.failure"/> </group> </groups> <graphs> <graph displayname="inform graphs" summary="true" type="line"> <counter name="inform.all"/> <counter name="inform.periodic"/> <counter name="inform.latency"/> </graph> <graph displayname="jta" summary="true" predefined="true"> <counter name="jta.committed.tx.rate"/> <counter name="jta.rolledback.tx.rate"/> Configuring counters and graphs 75

</graph> </graphs> </displayinfo> 8. After you have finished making your updates, save the changes to the dashboard-config.xml file. 9. Upload the modified dashboard-config.xml file. The configuration information is read from the XML file, and then immediately applied to Dashboard Console. The dashboard configuration file is stored in the CONFIGURATION column of the DASHBOARD_CONFIGURATION database table. The UPDATED column of this table is updated whenever the configuration is changed. To make future changes to the Dashboard Console configuration, download the dashboard-config.xml file. Edit the file to make your configuration changes, as described in steps 2-8 of the procedure above, and save your changes. Then upload the modified dashboard-config.xml file. The configuration is read and takes effect immediately. For more information on uploading and downloading the configuration file, see Understanding the dashboard-config.xml file on page 52. Dashboard Console administration The following table provides the default roles added for Dashboard Console application. User access to the various parts of the interface depends on the roles to which users are assigned. The roles are grouped to provide access to the features of the Application Dashboard, System Monitoring, Manage Configuration, and Cluster Data sections of the interface, as shown in the following table: Role Name Application Dashboard UI_DASHBOARD_APPLICATION_MANAGER UI_DASHBOARD_APPLICATION_SUMMARY_READ UI_DASHBOARD_APPLICATION_STATUS_READ UI_DASHBOARD_APPLICATION_GRAPH_READ UI_DASHBOARD_APPLICATION_SNAPSHOT_READ UI_DASHBOARD_APPLICATION_ANALYSIS_READ System Monitoring Description Users assigned this role can access the Application Dashboard section. Users assigned this role can access the Summary tab in the Application Dashboard section. Users assigned this role can access the Status tab in the Application Dashboard section. Users assigned this role can access the Graph tab in the Application Dashboard section. Users assigned this role can access the Snapshot tab in the Application Dashboard section. Users assigned this role can access the Analysis tab in the Application Dashboard section. 76 Administering the Dashboard Console

Role Name UI_DASHBOARD_SYSTEM_MANAGER UI_DASHBOARD_SYSTEM_SUMMARY_READ UI_DASHBOARD_SYSTEM_STATUS_READ UI_DASHBOARD_SYSTEM_GRAPH_READ UI_DASHBOARD_SYSTEM_SNAPSHOT_READ UI_DASHBOARD_SYSTEM_ANALYSIS_READ Manage Configuration UI_DASHBOARD_CONFIG_EXPORT UI_DASHBOARD_CONFIG_IMPORT Cluster Data UI_DASHBOARD_CLUSTERINFO_READ Description Users assigned this role can access the System Monitoring page. Users assigned this role can access the Summary tab in System Monitoring section. Users assigned this role can access the Status tab in System Monitoring section. Users assigned this role can access the Graph Tab in System Monitoring section. Users assigned this role can access the Snapshot tab in System Monitoring section. Users assigned this role can access the Analysis Tab in System Monitoring section. Users assigned this role can access the Download Configuration button. Users assigned this role can access the Upload Configuration button. Users assigned this role can view the Cluster Data section of the Welcome page Counter Level Roles Roles can be added to individual counters in order to control who can access that counter. In order to add a role to a counter, simply add the role=<userrole> attribute to the counter in the dashboard-config.xml configuration file. Then upload the updated configuration file. If the user does not have the specified role, then the user will not be able to access the counter. For example, assume that a counter that is defined with the role="dashboard_user_system_admin" attribute is not visible in the console. This is because the user who is logged in does not have this WebLogic role. To correct this situation, log in to the WebLogic Administration Console, create the role DASHBOARD_USER_SYSTEM_ADMIN, and assign it to the Dashboard user. The user will now be able to see this counter in the Dashboard. If the role= attribute is not specified for a counter in the dashboard-config.xml configuration file, then the counter is visible to everybody. Dashboard Console administration 77

78 Administering the Dashboard Console

This chapter covers: 4 SMP Data Source Understanding the ALM SMP data source Requirements for deploying the ALM data source Installing and configuring the ALM data source ALM data source reference 79

The ALM SMP data source is a software component of Application Lifecycle Manager that is intended to be used with the Service Management Platform (SMP). It abstracts communication with ALM to make authoring SMP models easier: rather than having to write a web service client to communicate with the ALM NBI, you create a model that uses the ALM data source. This chapter describes how to install and use the data source, including its connection parameters and methods. Understanding the ALM SMP data source To facilitate the use of the asynchronous ALM life cycle operations with the SMP data source API, the ALM functions have been wrapped with an external service so that you can make synchronous calls to the service, which then handles the asynchronous calls to ALM. The service uses the Representational State Transfer (REST) architecture and is called the ALM Synchronous REST Service. Thus, the ALM SMP data source makes calls to the ALM Synchronous REST Service, which then calls the ALM server. The ALM SMP data source is a REST client to the ALM Synchronous REST Service; this architecture allows for other systems to potentially use ALM Synchronous REST Service to access ALM, by writing an additional REST client. The ALM Synchronous REST Service has the following components: NBI caller. Makes calls to the ALM Northbound Interface (NBI). Notification receiver. A JMS listener on the internal ALM Notification topic. Then notification is received it will notify waiting HTTP call and it will continue and return result of asynchronous operation. The ALM Synchronous REST Service makes calls to the ALM server as requested by the ALM SMP data source, and when the calls are asynchronous, waits for results, for a defined timeout period. When the timeout is set to 0, the service responds immediately (returning an operation ID), just as for an asynchronous call, and the calling system must make a callback to get the results. The ALM SMP data source implements the SMP data source API, and makes HTTP JAX-RS requests to the ALM Synchronous REST Service. ALM SMP Data Source Design 80 SMP Data Source

Requirements for deploying the ALM data source The following is a list of requirements when deploying the ALM SMP data source. The ALM application must be installed, deployed and running. For more information, see Chapter 1, Installation on page 1. The ALM Synchronous REST Service must be installed, deployed, and running. For instructions, see Installing the ALM Synchronous REST Service on page 81. The SMP application must be installed, deployed and running. For more information, see the Installation and Deployment section of the SMP Deployment Guide. The version of the SMP servers must be 4.0.0 or later. SMP's Model Builder and Overlay Builder are installed on the systems where users author models and overlays. All mandatory ALM connection parameters must be configured (see Connection parameters on page 85 ). Installing and configuring the ALM data source To install the ALM data source, you must complete these steps: 1. Install the ALM Synchronous REST Service on all the managed servers in the ALM cluster. 2. Install the data source.jar files in Model Builder and/or Overlay Builder. 3. Configure the various servers for SSL communication with each other. Installing the ALM Synchronous REST Service The ALM Synchronous REST Service accepts calls from the ALM SMP data source and passes them to the ALM server. It allows all calls from the ALM SMP data source to be treated as synchronous calls, because it waits for responses and returns them to the data source. The service is a.war file which should be installed on all the managed servers in the ALM cluster. To install the service 1. Create a properties file for the service and make it available to all of the managed servers in the ALM cluster. Create a file alm.properties with values for the following properties. The following values are sample values: alm.nbi.url=https://<myserver>:<myport>/alm/soap/alm.wsdl alm.nbi.user=alm_nbi_user alm.nbi.password=password Requirements for deploying the ALM data source 81

Store this file in a location accessible to your managed servers, and put the location in the classpath of the managed servers. For example, for every ALM managed server there is a special directory created where the alm-jaas.conf file is placed. See the Server Start field in the managed server configuration. You can put the alm.properties file in the same directory, because this directory is added to the ALM managed server classpath. 2. Get the.tar file distribution for the ALM SMP data source (alm-smp-dist-<versioninfo-dist.tar). 3. Using the Weblogic Administration Console, install the service's rest-<versioninfo>.war file (found in the /rest folder in the.tar file) as an application in the ALM domain; target all the servers in the ALM cluster. 4. Access the server to verify installation. Use the alm_nbi user to access the server, via the following URL: https://almserver:port/almrest/alm/devices/oui/productclass/serialnum/ (The.war file uses the basic authentication scheme and requires users with the same roles as the ALM NBI service.) Installing the ALM data source in SMP applications To install the ALM data source in the SMP and in the Model Builder and Overlay Builder applications, see the instructions in Pre-loading additional Motive modeling data sources in the SMP Deployment Guide. Two.jar files for the data source that are required for the installation are provided in the /datasource directory in the data source's distribution.tar file (alm-smp-dist-<versioninfo>-dist.tar). Setting up SSL for the ALM data source SSL (Secure Sockets Layer) must be used for communication between ALM and the ALM data source running on SMP servers and/or in Model Builder and Overlay Builder installations. If the WebLogic servers where thealm application is deployed are configured to use an SSL certificate signed by a commonly used certificate authority, you may not need to perform the following steps. WebLogic, Model Builder and Overlay Builder are pre-configured to trust the commonly used certificate authority. But if the WebLogic servers where the HDM application is deployed are using a custom SSL certificate (such as self-signed certificates, then you need to configure the Model Builder, Overlay Builder or SMP to trust the certificate that the WebLogic server on the ALM domain presents. 82 SMP Data Source

Setting up SSL for Model Builder and Overlay Builder Follow these instructions if the certificate that is installed on the ALM server is not signed by a commonly used certificate authority, or if you are getting a no trusted certificate found error during connection with the ALM server. To set up SSL within Model Builder and Overlay builder 1. Get the public key certificate (CertGenCA.der) that is installed on the ALM server. This file is usually installed under <install dir>/wlserver_10.3/server/lib directory. 2. Generate a server keystore using the above file as input: keytool -import -file CertGenCA.der -alias servercert -keystore server.keystore When prompted for password, enter a password for this keystore. For example: Enter keystore password: smphdm When prompted to trust the certificate, enter yes. For example: Trust this certificate? [no]: yes This will generate a server.keystore file in the current directory. 3. Copy the server.keystore file to the directory where you installed the Model Builder and Overlay Builder. You need to copy this file twice, once in each builder. 4. Edit the launcher.ini file located under <builder install dir>/model Builder and add the string -Djavax.net.ssl.trustStore=<path_to>/server.keystore to the JavaOptions property. The resulting property value should look like this: JavaOptions=-Xms128m -Xmx512m -XX:SoftRefLRUPolicyMSPerMB=1000000 -Dswing.defaultlaf= com.jgoodies.plaf.plastic.plasticlookandfeel -DsaveDir=examples\models -Djava. library.path=.\instrumentation\bin -Xdebug -Xrunjdwp:transport=dt_socket,address= 18080,server=y,suspend=n -Djavax.net.ssl.trustStore="c:\Program Files\Motive\Model Builder\cert\server.keystore" 5. Repeat the previous step for the Overlay Builder. 6. Restart Model Builder and Overlay Builder. Setting up SSL for the Service Management Platform (SMP) Follow these instructions if the certificate that is installed on the ALM server is not signed by a commonly used certificate authority, or if you are getting a no trusted certificate found error during connection with the ALM server. Setting up SSL for the ALM data source 83

To set up SSL for ALM data source executed within SMP.ear 1. Get the public key certificate that is installed on the ALM server. This file is usually installed under <install dir>/wlserver_10.3/server/lib directory. 2. Generate a server keystore using the above file as input: keytool -import -file CertGenCA.der -alias servercert -keystore server.keystore When prompted for password, enter a password for this keystore. For example: Enter keystore password: smpalm When prompted to trust the certificate, enter yes. For example: Trust this certificate? [no]: yes This will generate a server.keystore file in the current directory. 3. Copy the server.keystore file to a directory on the hosts where SMP.ear is installed. This directory has to be the same on all servers in the SMP cluster. 4. Log in to the WebLogic Administration Console for you ALM installation. 5. Go to ALMDomain > Environment > Servers. Perform the following for all Managed Servers in the SMP cluster. a. Click a link to a Managed Server. b. Click Lock & Edit. c. Click Configuration > Server Start. d. Edit the Arguments property and insert the string -Djavax.net.ssl.trustStore=<path to the above server.keystore> to the input text after the -server option. The property should look like this: -server -Djavax.net.ssl.trustStore=<path to the above server.keystore>... e. Click Save. f. Click Activate Changes. ALM data source reference This section describes the connection parameters used with this data source, provides a best practices section, and describes the methods. 84 SMP Data Source

Connection parameters The ALM SMP data source requires the following connection parameters to be set up in the Service Management Platform (SMP) using the Modeling tools. Each connection parameter must be associated with a property. You can name these properties with the default names, choose your own property name, or associate the parameter with an existing property. almresturl Mandatory. Describes the hostname of the REST service, or the load balancer that sits in front of the it. It must start with either http:// or https://. For example: http://almrestservice.mycompany.com:7003 username Mandatory. Describes the username to be used to make web service calls to the REST service. The user has to have the NBI-related roles that are required of each operation. For example: alm_nbi_user password Mandatory. Specifies the password for the above user. For example: password Best practices When configuring your systems to use the ALM SMP data source, keep the following in mind: Although wrapped in the synchronous ALM service module, most operations are actually asynchronous within ALM, so they should only be invoked against devices that are online. If not, there is a risk of creating too many waiting threads in the ALM service module. Make sure timeout values are not too high; Motive recommends 60000 milliseconds (60 seconds). Try to use the SMP's workflow scenarios; these prevent waiting calls. Data types The following table describes the data types that you can use with the data source methods. Note that complex data types include subtypes of any one data type. In other words, only one data type can be used for the subtypes within a particular instance of a complex data type. For example, a List data type might include String subtypes; a Map data type might include Boolean subtypes. Connection parameters 85

Data Type Boolean Character Date Float Integer List Map MapList Object Password Properties ResultSet Set String Subtypes Support? Yes Yes Yes Yes Yes Description A java.lang.boolean object, which is either true or false. A java.lang.character object. A java.util.date object. A java.lang.float object, which is a non-integer number. A java.lang.integer object. A java.util.list object, which is a list that contains objects of other data types (such as String). The StringToList method converts a String data type to a List data type. A java.util.map object, which is a list that contains objects of other data types (such as String). A java.util.list object containing objects of type java.util.map. A java.lang.object object, which is a catchall that could contain anything. A masked string that represents a password. A java.util.properties object, which is a map of strings to other strings. A java.util.list object containing objects of type java.util.map. A ResultSet is a list of maps that all have the same keys; usually a ResultSet is used for databases or other systems that return a set of data. A java.util.set object, which is an unordered list. A java.lang.string object. Methods Method list getinstalledapplications on page 88 installstartapplication on page 89 Returns a list of the application instances installed on the specified device. Synchronous. Installs an application on a device, and optionally starts it (if the parameter startapplication is set to true ). Operation is asynchronous; responsetimeout defines the time to wait for operation end notification. If after that timeout operation is not finished successfully, the system returns an operation execution exception. 86 SMP Data Source

uninstallapplication on page 91 updateapplication on page 91 startapplication on page 90 stopapplication on page 90 waitdeviceactivation on page 92 getoperationbyid on page 88 getdynamicvariables on page 88 setdynamicvariable on page 89 deletedynamicvariable on page 87 Uninstalls an application from a device. Operation is asynchronous; responsetimeoutdefines the time to wait for operation end notification. If after that timeout operation is not finished successfully, the system returns an operation execution exception. Updates an application on a device. The operation first checks to see if the device has an application with the specified name and a different version installed; the update happens only if an application with the same name is already installed on the device. Operation is asynchronous; the responsetimeout parameter defines the time to wait for operation end notification. If after that timeout operation is not finished successfully, the system returns an operation execution exception. Starts an application on a device. Operation is asynchronous; responsetimeoutdefines the time to wait for operation end notification. If after that timeout operation is not finished successfully, the system returns an operation execution exception. Stops an application on a device. Operation is asynchronous; responsetimeoutdefines the time to wait for operation end notification. If after that timeout operation is not finished successfully, the system returns an operation execution exception. This method waits until the specified device is activated in ALM, for a time specified by the responsetimeout parameter. Returns the status of an operation for a specific device, when supplied with the operation ID. Returns an object with detailed information. Asynchronous. Returns a list of the dynamic variables on the device. Synchronous. Sets or updates the value of a dynamic variable on a device. Removes a dynamic variable from a device. Synchronous. deletedynamicvariable Boolean deletedynamicvariable(string productclass, String oui, String serialnumber, String variablename) Removes a dynamic variable from a device. Synchronous. Methods 87

Parameters. productclass - String indicating the product class of the device. oui - String value of the OUI of the device. serialnumber - String containing the serial number of the device. variablename - String containing the name of the variable to be deleted. Returns. Boolean indicating whether the operation succeeded (true) or failed (false). getdynamicvariables Map getdynamicvariables(string productclass, String oui, String serialnumber) Returns a list of the dynamic variables on the device. Synchronous. Parameters. productclass - String indicating the product class of the device. oui - String value of the OUI of the device. serialnumber - String containing the serial number of the device. Returns. Map containing the list of dynamic variables and their values. getinstalledapplications List getinstalledapplications(string productclass, String oui, String serialnumber) Returns a list of the application instances installed on the specified device. Synchronous. Parameters. productclass - String indicating the product class of the device. oui - String value of the OUI of the device. serialnumber - String containing the serial number of the device. Returns. List containing the list of application instances. getoperationbyid Any getoperationbyid(string productclass, String oui, String serialnumber, String operationid) Returns the status of an operation for a specific device, when supplied with the operation ID. Returns an object with detailed information. Asynchronous. 88 SMP Data Source

Use this method after running one of the methods that returns an operation ID. Parameters. productclass - String indicating the product class of the device. oui - String value of the OUI of the device. serialnumber - String containing the serial number of the device. operationid - String containing the ID for the operation to report on. Returns. An operation object containing status, start/stop dates, error messages, and command information. installstartapplication Integer installstartapplication(string productclass, String oui, String serialnumber, String applicationname, String applicationversion, String responsetimeout, String startapplication) Installs an application on a device, and optionally starts it (if the parameter startapplication is set to true ). Operation is asynchronous; responsetimeout defines the time to wait for operation end notification. If after that timeout operation is not finished successfully, the system returns an operation execution exception. Parameters. productclass - String indicating the product class of the device. oui - String value of the OUI of the device. serialnumber - String containing the serial number of the device. applicationname - String containing the name of the application to install. applicationversion - String containing the version of the application. responsetimeout - String containing the timeout value in milliseconds. startapplication - String indicating whether or not to start the application after installing it; set the value to true to have the system start the application. Returns. An operation ID as an integer. setdynamicvariable Boolean setdynamicvariable(string productclass, String oui, String serialnumber, String variablename, String variablevalue, String variableissecret) Sets or updates the value of a dynamic variable on a device. Parameters. productclass - String indicating the product class of the device. Methods 89

oui - String value of the OUI of the device. serialnumber - String containing the serial number of the device. variablename - String containing the name of the variable to be set. variablevalue - String containing the value. variableissecret - String indicating whether the variable's value should be hidden; set it to true to hide the value. Returns. Boolean indicating whether or not the value was set successfully. startapplication Integer startapplication(string productclass, String oui, String serialnumber, String applicationname, String applicationversion, String responsetimeout) Starts an application on a device. Operation is asynchronous; responsetimeoutdefines the time to wait for operation end notification. If after that timeout operation is not finished successfully, the system returns an operation execution exception. Parameters. productclass - String indicating the product class of the device. oui - String value of the OUI of the device. serialnumber - String containing the serial number of the device. applicationname - String containing the name of the application to start. applicationversion - String containing the version of the application. responsetimeout - String containing the timeout value, in milliseconds. Returns. An operation ID as an integer. stopapplication Integer stopapplication(string productclass, String oui, String serialnumber, String applicationname, String applicationversion, String responsetimeout) Stops an application on a device. Operation is asynchronous; responsetimeoutdefines the time to wait for operation end notification. If after that timeout operation is not finished successfully, the system returns an operation execution exception. Parameters. productclass - String indicating the product class of the device. oui - String value of the OUI of the device. 90 SMP Data Source

serialnumber - String containing the serial number of the device. applicationname - String containing the name of the application to stop. applicationversion - String containing the version of the application. responsetimeout - String containing the timeout value, in milliseconds. Returns. An operation ID as an integer. uninstallapplication Integer uninstallapplication(string productclass, String oui, String serialnumber, String applicationname, String applicationversion, String responsetimeout) Uninstalls an application from a device. Operation is asynchronous; responsetimeoutdefines the time to wait for operation end notification. If after that timeout operation is not finished successfully, the system returns an operation execution exception. Parameters. productclass - String indicating the product class of the device. oui - String value of the OUI of the device. serialnumber - String containing the serial number of the device. applicationname - String containing the name of the application to stop. applicationversion - String containing the version of the application. responsetimeout - String containing the timeout value, in milliseconds. Returns. An operation ID as an integer. updateapplication Integer updateapplication(string productclass, String oui, String serialnumber, String applicationname, String applicationversion, String responsetimeout) Updates an application on a device. The operation first checks to see if the device has an application with the specified name and a different version installed; the update happens only if an application with the same name is already installed on the device. Operation is asynchronous; the responsetimeout parameter defines the time to wait for operation end notification. If after that timeout operation is not finished successfully, the system returns an operation execution exception. Parameters. productclass - String indicating the product class of the device. oui - String value of the OUI of the device. Methods 91

serialnumber - String containing the serial number of the device. applicationname - String containing the name of the application to stop. applicationversion - String containing the version of the application. responsetimeout - String containing the timeout value, in milliseconds. Returns. An operation ID as an integer. waitdeviceactivation Any waitdeviceactivation(string productclass, String oui, String serialnumber, String responsetimeout) This method waits until the specified device is activated in ALM, for a time specified by the responsetimeout parameter. The method begins by verifying that the device has not already been activated; if the device has been activated, the method returns immediately. If the specified device is not found, the method waits for a period specified by the responsetimeout parameter for activation notification. The operation is asynchronous; if it does not complete by the timeout, the system returns an operation execution exception. Parameters. productclass - String indicating the product class of the device. oui - String value of the OUI of the device. serialnumber - String containing the serial number of the device. responsetimeout - String containing the timeout value, in milliseconds. Returns. Any. 92 SMP Data Source

5 Troubleshooting 93

Troubleshooting problems and answers General problems... 94 Q: Can't get information from devices in the ALM Management Console.... 94 Policy problems... 94 Q: The Reinvoke policy for failed or aborted devices button for policies is not enabled in my Management Console.... 94 5.1. General problems Q: Can't get information from devices in the ALM Management Console. A: The system depends on JMS notifications from HDM. Make sure the notifications are configured as described in Configuring the JMS event notification settings in HDM on page 27. Test your configuration by clicking the Test Settings button in the console for more information. 5.2. Policy problems Q: The Reinvoke policy for failed or aborted devices button for policies is not enabled in my Management Console. A: This feature depends on the FindDevicesByServiceTag criteria template in Home Device Manager. Make sure this criteria template is loaded in your Home Device Manager console; see Creating the minimum ALM data objects in HDM on page 25. 94 Troubleshooting

Glossary 802.11 802.11 refers to a family of standards for WLAN (wireless local area network) communication developed by the IEEE [http://www.ieee.com/portal/index.jsp]. Commonly referred to as Wi-Fi, 802.11 includes 802.11a, 802.11b, and 802.11g. 802.11a provides up to 54 Mbps on the 5 GHz band with a range of 60 feet. 802.11b provides 11 Mbps in the 2.4 GHz band with a range of 300 feet and is backward-compatible with 802.11. 802.11g, provides 54 Mbps on the 2.4 GHz band with a range of 300 feet, and is interoperable with 802.11b. action The wrapper for a protocol-specific function run on a device. All actions contain protocol-specific functions, and all policies contain actions. Administration Server Single-instance server that provides a contact point for the Managed Server instances and system administration tools in the WebLogic Server domain. See also Managed Server. ALM Management Console The Application Lifecycle Manager user interface that enables remote management of applications, deployment units, and the execution environments that run on managed devices. ALM NBI An NBI that provides methods that allow you to manage the life cycle of applications on managed devices. application Within Application Lifecycle Manager, an application is a logical grouping of deployment units that corresponds to a subscriber-oriented application. application configuration A versioned configuration that defines the settings and content instructions the server is to apply in the runtime environment of a SMP-based deployment, including its application properties and any role-based properties; user input definitions; result analyses; test modules; endpoint operations; workflow modules; test groups; startup test groups; and service policies. The active version of the application configuration is in effect. In the Configuration Manager, you can create, load for editing, or make active other versions from the Application Configuration tab. Alternatively, you can use the Command Line Configuration Importer. See also environment configuration. 95

Application Lifecycle Manager Product that enables broadband providers to remotely manage applications on devices. Functionality includes application, deployment unit, and device management, as well as the ability to implement policies on devices. A configuration page enables you to set parameters such as FTP and HTTP locations and ports. application property A name and value pair that defines either a built-in property that has system-wide effects or a custom property on which deployment-specific content depends. Application properties are defined in the application configuration. See also environment property. application tier The Home Device Manager application servers and OLTP database installed in a trusted network. The application tier is common to all deployments including standard deployments and distributed domain deployments. The application servers make up the HDMDomain with an Administration Server and the HDMCluster. Compare to protocol tier. See also Web proxy tier. assisted service Type of service in which a CSR assists a subscriber with problem resolution. Auto-configuration Server (ACS) The protocol server component installed on each Managed Server. The ACS processes messages to and from devices in subscriber environments. It handles all device communication from the protocol tier in a distributed domain deployment and from the application tier in a standard deployment. TR-069 devices send the ACS Inform messages regularly, receive commands called from the ACS, and respond to the ACS with results. The ACS can send TR-069 devices unsolicited messages (connection requests) requesting them to initiate a new session with the server. By contrast, SNMP devices and the ACS use a push model to interact: The ACS sends requests to SNMP devices, and the devices respond. Unlike TR-069 devices, SNMP devices do not continually send Inform messages to the ACS, and an Inform message is not required to run actions from the action queue on them. Bastion Web Server Standard web server software such as Sun One Web Server or Apache. Optionally, Bastion Web Server packages are installed on hosts in the DMZ to receive and redirect incoming subscriber system requests to application servers. Boot Inform message On devices that support the TR-069 protocol, a message that is sent whenever the CPE is booted up or reset. The message does not provide information about how long the CPE has been attached to the current network environment, or whether or not the CPE has ever been activated. Bootstrap Inform message On devices that support the TR-069 protocol, a message that is sent the first time the device is installed, after the device is factory reset, or after the device's management server URL has been changed. Whenever a device contacts the Home Device Manager server with this message, the HDM server evaluates the activation status of the device. If the device uses the Bootstrap Server during activation, and the Auto-configuration Server (ACS) URL has been changed on the device to contact the Device Management (DM) Server, HDM waits for the device to send a Bootstrap Inform 96 Glossary

message indicating that the ACS URL was changed, and then HDM activates the device. If the device does not use the Bootstrap Server during activation, HDM immediately activates the device. Bootstrap Inform messages are sent continuously until Home Device Manager successfully acknowledges and processes them. If a device is activated already, a Bootstrap Inform message deactivates the device, and the device must go through the activation process again. HDM treats this as a factory reset. Bootstrap Server Type of Managed Server, in the HDMCluster or HDMDistributedCluster, that not fully-provisioned CPE communicate with initially. After authenticating, CPE in the walled garden are redirected to a Device Management (DM) Server. Bootstrap Servers authenticate incoming CPE requests with a default user name and password for the associated device type. If the Bootstrap Server is configured for pass-through authentication, CPE can authenticate without credentials. The Bootstrap Server is also referred to as the Walled Garden Server. Compare to Device Management (DM) Server. bundle A module consisting of a.jar file that delivers and deploys code and resources (for example, images and libraries) and contains a bundle manifest file that supplies code dependencies and other information about the bundle. Bundles hide their internal implementations, communicate through services, and are managed by the OSGi framework. A more general term for a bundle is a deployment unit. client A caller application that communicates with the SMP. For example, clients send operation invocation requests for a named endpoint operation to SMP's Endpoint Operations API. A CSR application deployed on the same WebLogic Server domain as the SMP can be written to use the API methods directly, while a northbound interface installed outside of the domain can use the API's web service to call the methods. Command Line Configuration Importer Utility for uploading, downloading, and making activate a version of the application configuration from the command line. Configuration Manager Browser-based tool for defining the deployment's active version of the application configuration, one or more other versions of the application configuration, and the environment configuration. Connection Request Inform message On devices that support the TR-069 protocol, an Inform message that occurs based on a request (ConnectionRequestURL method call) from the Auto-configuration Server (ACS). Connection Request Proxy Server Web server that passes connection requests from the Auto-configuration Server (ACS) to a TR-069 device. In turn, the device sends an Inform message to the ACS. See also TCP Connection Request Proxy Server, UDP (User Datagram Protocol) Connection Request Proxy Server. 97

CPE (customer premises equipment) Rented or purchased equipment that is physically located at the residence or office of a subscriber. Examples include cable or DSL modem, residential gateways, IP set-top boxes, VoIP terminal adapters, and femtocell base stations. CPE WAN Management protocol (CWMP) An industry standard for WAN-side configuration and management of devices such as gateways and modems. The CWMP, also referred to as TR-069, provides a framework for communication between CPEs and Auto-configuration Servers (ACSs) such as the ACS in Home Device Manager. The framework includes a mechanism for secure auto-configuration of a CPE and incorporates other CPE management functions. TR-069 establishes rules for how a CPE device communicates with and is managed by a remote management system. criteria template See search criteria template. CSR (customer support representative) A person who provides subscribers assisted service. CSRs use Motive software to diagnose and resolve service issues while communicating with subscribers. CSRs are sometimes referred to as analysts or agents. Customer Service Manager Motive product that helps CSRs (customer support representative) pinpoint the cause of and resolution for service issues on behalf of high-speed data subscribers. The product gathers service data referred to as telemetry from multiple sources to present CSRs with a complete representation of a service as it exists in a subscriber s environment. Also, the product presents CSRs the results of a comparison between the subscriber information and managed settings that model the optimal working state. The overall process empowers CSRs to automatically perform root cause analysis and to drive rapid and accurate resolution. custom function A function that coordinates the execution of one or more primitive functions, which wrap TR-069 RPC methods. Home Device Manager provides several reference custom functions and a toolkit that enables you to create your own. Custom functions can be run in the same way built-in functions are run that is, as part of actions or on their own. Also known as: multi-rpc function Java Custom Function dashboard A web page that provides a quick and accurate measure of certain statistics to help understand how one or more Motive software solutions are being used. See also service metrics. Dashboard Console Browser-based application the provides members of your application and IT teams health metrics on each Managed Server, as well as globally over the entire cluster. Monitoring results are stored in an OLTP database that handles time-series data, from which the Dashboard Console generates graphs. The graphs, whose data you can export, show 98 Glossary

views of Managed Server and cluster health data over the past hour, day, or week. The Dashboard Console is a separately-licensed additional feature. data mart A database optimized for reporting and querying rather than for transaction processing. Reporting databases or schemas are sometimes referred to as OLAP (Online Analytical Processing) databases, in contrast to OLTP (Online Transaction Processing) databases. Data marts are designed with fewer tables, more indexes, and de-normalization. Typically data is moved at regular intervals but at off-peak times from the OLTP transaction database to the data mart by means of an ETL tool. A data mart or OLAP database reduces the load on the transactional database and facilitates faster, more accurate reporting for a subdivision of a larger organization. Data warehouses, in contrast, pull together data from multiple databases and multiple departments. Data warehouses are sometimes made from multiple data marts. Data marts and data warehouses are often designed with a star schema or snowflake schema. data model The group of entities, their attributes, the relationships among these entities, and integrity rules that make the abstraction from the real world of those properties relevant to a given application. datasource connection For a specific modeling data source installed, the specific set of values required for establishing communication between it and the server. Datasource connections are defined in the environment configuration. data warehouse A database optimized for reporting and querying rather than transaction processing. Reporting databases or schemas are sometimes referred to OLAP (Online Analytical Processing) databases, in contrast to OLTP (Online Transaction Processing) databases. Data warehouses are designed with fewer tables, more indexes, and de-normalization. Typically data is moved at regular intervals but at off-peak times from the OLTP transaction database to the data warehouse by means of an ETL tool. A data warehouse or OLAP database reduces the load on the transactional database and facilitates faster, more accurate reporting. Data marts are similar to data warehouses, except that they focus on one department of the organization and often only pull data from a single transactional database. Data warehouses are sometimes made from multiple data marts. deployment unit A deployable module of code and/or data. A deployment unit may contain one or more execution units. On the OSGi framework, deployment units correspond to bundles. device A system capable of running the ALM client/platform, and therefore manageable by ALM. Device Management (DM) Server Type of Managed Server, in the HDMCluster or HDMDistributedCluster, that communicates with CPEs configured for activation. The DM Server instances run policies on the CPE to complete the activation process. On an ongoing basis, they implement policies on CPEs to keep them updated. Authenticating to a DM Server requires strict authentication including the device-specific credentials. 99

The DM Server is also referred to as the Public Server. Compare to Bootstrap Server. Diagnostic Complete Inform message On devices that support the TR-069 protocol, an Inform message that occurs to re-establish connection to the server after completing a diagnostic test initiated by the Auto-configuration Server (ACS). dimension table In a data mart or data warehouse, dimension tables model the attributes that provide the context in which events occur. The events are modeled in fact tables with foreign key references to records in dimension tables. For example, dimensions such as time, customer, and operating system provide part of the context in which some event, such as the creation of a service request, occurs. Dimensions can be one of three types, based on how change is managed: Type 1: When an attribute changes, the existing attribute is updated with the new information, discarding the old information. This is the simplest method, but makes no attempt to preserve the historical information. Type 2: When an attribute changes, a new record is created with the new attribute value. This solution preserves the history of the attribute, but complicates the ETL process and can greatly increase the amount of space that is consumed. Type 3: When an attribute changes, a limited amount of historical information is preserved by saving the current value and the original value in separate attributes, sometimes also storing a timestamp of the change in a third attribute. This technique does not have the space or complexity problems of Type 2, but only allows you to keep a limited amount of the historical information. These techniques are well documented in discussions of data warehousing. Search for slowly changing dimensions in your favorite search engine for more information. distributed domain deployment Home Device Manager architecture that includes two distinct WebLogic Server domains, the HDMDistributedDomain in the DMZ and the HDMDomain in the trusted network. The domains each include a cluster of application servers. In a distributed domain deployment, the initial CPE communication redirects from the application servers in DMZ to the ones in the trusted network. Compare to standard deployment. DM (device management) Management of device configuration, updates, and other managed objects of mobile devices as defined by OMA (Open Mobile Alliance). Generically, DM refers to all methods and activities associated with mobile device management. endpoint An individual device or system targeted for management. The management may include retrieving data from, configuring an update on, or running other specific functions. Examples of endpoints are a mobile phone, DSL modem, and other individual systems such as an operator OSS. 100 Glossary

endpoint operation A data configuration stored in the SMP Repository. The configuration defines the manner in which SMP is to handle a client request for executing the corresponding operation. The operation is the function or group of procedures that the applicable manager instructs a given endpoint to execute on itself. Deployment teams configure an endpoint operation through the Configuration Manager after developing the associated operation implementation. Endpoint Operations API A web service API that allows exposing normalized operations for execution on individual endpoints. With a normalized operation, the client does not need to expose the full APIs of the applicable managers or to invoke multiple managers. In general, the API is used to do the following: determine whether a named endpoint operation is available for a given endpoint; validate the client's request based on the configuration of the corresponding endpoint operation; and to pass the client's validated request to the test module that implements the operation invocation. environment configuration The configuration that defines the following for an SMP-based deployment: datasource connections; environment properties; execution auditing settings; licenses for SMP and SMP-based products; policies for southbound throttling, northbound throttling, and test module throttling; and system alerts. In the Configuration Manager, you define these from the Environment Configuration tab, and the settings take effect immediately. See also application configuration. environment property A name and value pair that varies from one database to another. Environment properties allow maintaining differences between two databases when testing changes in one database and then moving them to another database when they are ready for use. Environment properties are defined in the environment configuration; they are not tied to the application configuration in any way. See also application property. ETL (extract, transform, load) A database management programming tool that incorporates three functions. The extract function reads data from a specific database and extracts a subset of data. Next, the transform function converts the extracted data into the intended format. Lastly, the load function writes the extracted and transformed data to a target database. execution auditing Settings that enable reporting on the duration and outcome of specific tasks in troubleshooting application and performance issues. The execution auditing settings are defined in the environment configuration. execution environment A framework on a managed device which provides APIs for managing deployment units, including installing, starting, and stopping them. execution unit An executable component of a deployment unit. fact table In a data mart or data warehouse, fact tables model the key events that occur in the domain being modeled, such as an individual sale, a service request, or content being accessed by the subscriber. Fact tables include fields that describe aspects of the fact being modeled and fields that contain foreign key references to relevant dimensions to provide context for the fact being modeled. Data in fact tables is often a candidate for aggregation. 101

file server A computer or storage device on a network that makes files available to other computers on the same network. See also file sharing. file sharing To make files and folders available to other computers on a network. File sharing provides multiple users read, write, or read and write access to a set of files configured for sharing. See also printer sharing. flavor A component of an application definition in Application Lifecycle Manager. A flavor specifies a set of deployment units and configuration information along with criteria for applying them. Flavors allow you to deploy an application differently for different circumstances. FMC (fixed mobile convergence) Fixed and mobile telephony service from a single phone with the handset configured to switch between mobile and Wi-Fi (Wireless Fidelity) networks. For example, British Telecom offers an FMC service called BT Fusion [http:// www.btbusinessshop.com/icat/btfusion_hub]. function An operation that implements protocol-specific RPC (Remote Procedure Call) methods and can be run on a device. A function can be run as part of an action in bulk policies, or it can be applied to single devices on its own or as part of an action. Functions can be built-in or custom. See also custom function. HDMCluster The n number of Managed Servers in the application tier. The software and functionality on each Managed Server in the HDMCluster is identical, and the number of instances depends on the load the deployment must support. HDMDomain A WebLogic Server domain created by the application tier installer. The HDMDomain is made up of an Administration Server and the HDMCluster. Home Device Manager Product that allows broadband providers to remotely manage CPE that support the TR-069 and SNMP (Simple Network Management Protocol) protocols. Functionality includes policy-based tools to automate device configuration and management, ability to perform single as well as large-scale bulk device configuration, troubleshooting, firmware upgrades, event management, user management, communications logging, reporting, device alarm management, and device alarm monitoring. The Home Device Manager can be integrated with an existing OSS infrastructure and with Motive s Service Activation Manager, Self-Service Manager, and Customer Service Manager. Home Device Manager environment The aggregate hardware and software dedicated to configuring and managing the CPE in subscriber homes and businesses across your network. 102 Glossary

Inform message A message sent from a TR-069 device to establish communications with the Auto-configuration Server (ACS). This message serves to initiate the set of transactions requested and to communicate the limitations of the device with regard to message encoding. See also Bootstrap Inform message, Boot Inform message, Diagnostic Complete Inform message, Connection Request Inform message, Periodic Inform message, Scheduled Inform message, Transfer Complete Inform message, Value Change Inform message. LAN (local area network) A network of interconnected computers and other devices within a relatively small geographic area. The computers on a LAN can interact with each other. managed object An object such as a service that is defined by a bundle running in an OSGi framework and that can be managed and configured by Application Lifecycle Manager. Managed Server Server instance that runs identical applications to its peer instances in a WebLogic Server domain. See also Administration Server. ManagementServerURL URL for a CPE device to connect to an Auto-configuration Server (ACS) server using the CPE WAN management protocol (TR-69). manager Software application that communicates with and manages a set of endpoints such as computers, mobile devices, broadband devices, or other systems such as CRMs and application middleware. Examples of managers include Home Device Manager (HDM) and Mobile Device Manager (MDM). model A model is an abstract representation that defines an application configuration, which is the IT infrastructure (including hardware and software components, relationships and dependencies) of a mission-critical application or business process. Models establish general information about an application configuration and provide a reusable structure on which many business operations can be performed. Model Builder Model Builder is a Motive desktop application which enables you to create models that capture the hardware and software components and dependencies of the IT infrastructure of a mission-critical application or business process. Models created in Model Builder are consumed by Overlay Builder users and by Motive model-based web application users (who use models and overlays to resolve application environment issues). network A group of computers and other devices, such as printers, interconnected through communication links. 103

northbound load balancer A load balancer that fronts the Managed Servers in the HDMCluster of the application tier and offloads SSL activity initiated by HDM Management Console, Server Configuration Console, and/or OSS (operations support systems) users. See also southbound load balancer. northbound throttling Mechanism for controlling the load that northbound interface (NBI) requests generate on SMP. The NBI requests are calls to SMP NBI APIs and web services (for example, the Endpoint Operations Web Service). The mechanism is implemented through northbound throttling policies defined in the environment configuration. OAMP Stands for operations, administration, maintenance, and provisioning. OMA (Open Mobile Alliance) Organization that develops open specifications designed to facilitate interoperability in the mobile industry based on market requirements. For more information, see the OMA [http://www.openmobilealliance.org] site. operation implementation The model, overlay, and test module created for executing the operation for a given endpoint operation. After validating a client request based on the configuration of the applicable endpoint operation, SMP executes the operation implementation. OSGi framework A Java-based specification for service platforms that can be managed remotely. The OSGi [http://www.osgi.org/] framework specification provides a standard for modularizing applications into smaller bundles whose external dependencies, if any, are explicitly declared. It also defines an API-based application life cycle management model for installing, starting, stopping, updating and uninstalling bundles; a service registry that detects when new services are added; an execution environment that defines the methods and classes available on a specific platform; and a security layer that restricts bundle functionality to predefined capabilities. The OSGi framework is part of the OSGi Service Platform, which can reside on every device in the home network, on a centrally placed service gateway in the home network, or both simultaneously. Also known generically as the framework. OSS (operations support systems) The back-end systems used by service providers to manage, monitor, provision, and guarantee the quality of network services (for example, order processing, line testing, and billing). overlay An overlay evaluates a snapshot (a representation of the state of an application environment at a given time) using a set of checks (conditions about a business issue) that determine the cause of problems and configuration issues for a particular application environment. The overlay then enables users of Motive model-based web applications to apply actions that address those issues. An overlay is built on top of an application model that defines the hardware and software components, relationships, and dependencies of an application configuration. Each overlay consists of one or more checks that evaluate an application issue. Each check is associated with one or more actions that work to address the issue. 104 Glossary

Overlays help users determine if the current configuration of an environment is conforming to the specifications outlined in the policy. Overlay Builder Overlay Builder is a Motive desktop application which enables you to create overlays that help users address issues within their application environment. Overlays are available within the Motive model-based web applications to users who support application environments. Periodic Inform message On devices that support the TR-069 protocol, an Inform message that occurs based on a periodic inform interval configured for the CPE device. For example, a device may be configured to send a message to an Auto-configuration Server (ACS) once every 24 hours. policy A rule that defines a set of conditions (such as selection criteria or device groups) and associated actions. If a device meets these conditions, then the specified actions for that rule are run on the device. Within Home Device Manager, policies are used to manage devices. A policy continues to run against targeted devices unless it expires or reaches a failure threshold or retry count configured in the policy. Policies run only on devices that are currently enabled and not locked by an operator for manual operation. policy Policies allow you to perform operations on sets of devices, or perform operations automatically in response to certain events. For each policy, you can define criteria that determine which devices the system should apply the policy to, and actions that describe the operations to perform. printer sharing To make a printer available to multiple computers on a network. The printer can be attached to another computer, a print server, or directly to the network. See also file sharing. protocol A set of standardized rules designed to enable computers to exchange information. protocol The high-level categorization of CPE that describes the basic capabilities of a class of devices. A protocol represents the underlying communications protocol as well as object model paradigm for a device. Examples of device protocols include TR-069 and SNMP (Simple Network Management Protocol). protocol tier The Home Device Manager application servers installed in the DMZ of a distributed domain deployment. The protocol tier is dedicated to handling incoming communication from CPE; its servers make up the HDMDistributedDomain with an Administration Server and one or more Managed Servers. When the protocol tier Managed Servers are clustered (optional), they are members of the HDMDistributedCluster. The applicable protocol Managed Server uses RMI over IIOP to load balance and direct CPE communication to an available Managed Server in the application tier. Unlike the application tier servers, the protocol tier servers do not communicate with the Home Device Manager OLTP database. 105

Compare to application tier. See also Web proxy tier. Public Server See Device Management (DM) Server. role-based property A configuration that provides the mechanism for using SMP to determine permissions on an external entity not created and managed within the platform. Each role-based property includes assignment of one or more user roles. Only those users with accounts including at least one of the assigned roles are permitted to use the resources associated with the role-based property. Role-based properties are defined in the application configuration. Scheduled Inform message On devices that support the TR-069 protocol, a one-time Inform message that occurs based on a request (M ScheduleInform method call) from the Auto-configuration Server (ACS). search criteria template The definition of a collection of search parameters that can be used to locate devices. The HDM Management Console provides a set of default search criteria templates. Users can add custom templates from the HDM Management Console. Also known as: criteria template search criteria selection criteria self-service Type of service in which a subscriber uses Motive software to resolve a problem without interacting with a CSR. Self Service Manager Motive product that automates problem diagnosis, resolution, and service management capabilities across each of the primary support channels electronic, phone, and email. With Motive software, subscribers can easily self-manage their IP-based services without engaging a CSR (customer support representative) or requiring a technician visit. Server Configuration Console Browser-based interface for configuring server properties. From the Server Configuration Console, application administrators can configure global properties and host-specific properties. service In the context of OSGi, an interface of a Java object which is registered in the OSGi service registry, allowing other bundles to use it. A single bundle can register multiple services. A service consists of a Java class or interface (the service interface), along with a variable number of attributes (the service properties) that are name-value pairs. 106 Glossary

Service Activation Manager Motive product that automates service activation for broadband subscribers. The Service Activation Manager software enables subscribers to turn up high-speed data and IP-based services without having to call a customer service representative (CSR) or request an onsite technician visit. The software can offer and fulfill IP-based services during activation events and increase adoption rates for existing and new services. Motive configures all necessary elements of an IP-based service through multiple fulfillment models, including web-only (or CD-less ), CD-only, or a combination CD and web solution. service gateway A physical or logical device running an execution environment that allows ALM to manage the device. Service Management Platform (SMP) The Motive Product Group software infrastructure for modeling services along with the management operations associated with endpoints on which the services depend. Example services include broadband, mobile, and FMC (fixed mobile convergence). In particular, operators use SMP to execute single endpoint operations (retrieve/configure) and to run end-to-end service diagnostic tests and automated actions for a given service subscription. The Service Management Platform includes a server runtime environment, several design-time tools and web services, and a reporting console. Depending on licensing, the platform product may also include the Motive Workflow Engine and Dashboard Console. service metrics Statistics generated from the Motive Data Mart that provide a high level view of the provider's ROI from Motive solutions. See also dashboard. Service Operations Console A secure, web-based user interface used by the service provider to provision and maintain service management entities stored in the Service Repository, such as services, subscription groups, and subscriptions, as well as initiate OAMP operations against managed services and devices using service profiles as high-level abstractions. Service Operations Module A key component within Motive Product Group s Service Management product portfolio that enables operators with OAMP capabilities using a single, integrated solution that provides a consistent user experience for all multi-play subscriber services. The Service Operations Module consists of the Service Repository, the Service Operations Console, and the Service Operations Northbound Interface (NBI). Service Operations Northbound Interface (NBI) In the Service Operations Module, a web services interface used by northbound systems such as OSS/BSS used to provision and maintain service management entities stored in the Service Repository, such as services and subscriptions, as well as initiate OAMP operations against managed services and devices using service profiles as high-level abstractions. Also known as: Service Repository Northbound Interface (NBI) service platform The combination of the managed device and the OSGi framework. 107

service policy A defined behavior to execute as a result of a given event. Service policies are defined in the application configuration. service profile An object that is exposed as a high-level OAMP operation (for example, provisioning, diagnostic, alarming, or monitoring) for a specific service which can be applied to or associated with an existing subscription using the Service Operations Console or the Service Operations Northbound Interface (NBI). The service profile acts as an abstraction for a set (one or more) of device management actions known as service profile operations. service profile operation An object that represents an abstraction for a lower-level device management action that exists within an element manager. A set (one or more) of operations is associated with a specific service profile. Service Repository In the Service Operations Module, an operational database for storage and maintenance of service management entities including services, accounts, subscription groups, subscriptions, service profiles, and service profile operations. service request A subscriber's attempt to resolve an issue using through self-service or assisted service using Motive software. SMP Repository An operational database for storage and maintenance of the operation implementations and corresponding endpoint operations. The Endpoint Operations API gathers information from the SMP Repository in response to client requests. SNMP (Simple Network Management Protocol) The protocol that governs network management and the monitoring of network devices and their functions. SNMP is not limited to TCP/IP networks. southbound load balancer A load balancer that CPE contact for redirection. Depending on the deployment, the southbound load balancer redirects CPE to a Bastion Web Server in the Web proxy tier, to a protocol tier Managed Server, or to an application tier Managed Server. Typically, the southbound load balancer is configured to offload the SSL requests from CPE such that they are forwarded over HTTP. See also northbound load balancer. southbound throttling Mechanism for controlling the load that SMP generates on southbound systems. Southbound systems refer to data sources on which the deployment's modeling content depends (for example, a manager like HDM). Often the southbound systems handle requests from multiple consumers in addition to SMP. As a result, throttling may become critical to prevent system overloads. The mechanism is implemented through southbound throttling policies defined in the environment configuration. SSL (Secure Sockets Layer) A secure Internet communication protocol. standard deployment The Home Device Manager architecture that includes a single WebLogic Server domain in the trusted network. The domain (HDMDomain) includes an Administration Server and a cluster of application servers (HDMCluster). 108 Glossary

Typically, the standard deployment also includes one or more Bastion Web Servers in a DMZ. A Bastion Web Server redirects device communication from the DMZ to the trusted network. Compare to distributed domain deployment. star schema A data model organized into dimension tables that relate to one or more central fact tables to facilitate reporting. A snowflake schema is similar to a star schema except that the dimension tables are subdivided into separate tables. This increases the normalization, but increases the complexity of the design and can affect performance. startup test group A test group slated for automatic execution at session creation in a SMP-based console (for example, the Customer Service Console). Startup test groups are defined in the application configuration. STUN (Simple Traversal of User Datagram Protocol (UDP) Through Network Address Translators (NATs)) Server An Internet-facing server that implements the STUN protocol to set up UDP communication with a device behind a NAT in the subscriber environment. The STUN Server creates the binding by informing a device (STUN client) of the type of NAT with which it is associated, along with the public IP address and port number for the NAT. The binding enables the Auto-configuration Server (ACS) to send connection requests for Inform messages to the STUN client through a UDP (User Datagram Protocol) Connection Request Proxy Server. subscriber In industry usage, an individual who pays for Internet access or other services from a provider. In Motive usage, an end-user who uses Motive software as a result of purchasing services from a provider. system alert A message with important service information that is intended for CSRs who are logged into a client with one or more particular roles. For example, an alert might announce upcoming system downtime. Each alert has a title; a message; a priority level; one or more CSR role associations; activation date and time; and expiration date and time. TCP Connection Request Proxy Server A Connection Request Proxy Server that passes connection requests from the Auto-configuration Server (ACS) to a TR-069 WAN-connected device. In turn, the device sends an Inform message to the ACS. telemetry Diagnostic data gathered from a subscriber system or backend system. For example, the amount of disk space is telemetry collected from the subscriber system, and outage status is telemetry collected from a backend system. Telemetry is the primary data source used to solve problems in the self-service and assisted service models. test group A set of one or more test modules. Test groups are defined in the application configuration; they are available for execution by a client or an SMP API. 109

test module A configuration that a client or an SMP API runs to execute a particular overlay and the model on which it is built. The test module defines the configuration that determines the manner in which the modeling process is executed. Test modules are defined in the application configuration. test module throttling Mechanism for controlling the invocations of specific test modules. This control also determines whether the associated NBI and southbound system requests are initiated; as a result, test module throttling provides for a middle ground between northbound throttling and southbound throttling. The mechanism is implemented through test module throttling policies defined in the environment configuration. TR-069 The CWMP protocol defined by the Broadband Forum. See the Broadband Forum [http://www.broadband-forum.org/] for the TR-069 report that documents the protocol. TR-111 An extension of the Broadband Forum's TR-069 protocol for remotely managing devices connected to LANs through NATs. Examples of such devices include VoIP phones, media set-top boxes, and gaming systems. See the Broadband Forum [http://www.broadband-forum.org/] for the TR-111 report that documents the extension. Transfer Complete Inform message On devices that support the TR-069 protocol, an Inform message that occurs when a previously requested download or upload (successful, or unsuccessful) completes. UDP (User Datagram Protocol) Connection Request Proxy Server A Connection Request Proxy Server that implements the UDP protocol to pass connection requests from the Auto-configuration Server (ACS) to a TR-111 device. In turn, the device sends an Inform message to the ACS. The communication is possible as a result of the binding that a STUN Server creates on the device. user input definition For a model input common to one or many test modules, metadata to return to a client such as its label, type, default value, whether optional, validation expression and message, and a help URL. User input definitions are defined in the application configuration. Value Change Inform message On devices that support the TR-069 protocol, an Inform message that occurs based on a change to one of the parameter values included in the Inform message. The values included in the Inform message are described in the Broadband Forum TR-069 protocol specification. WAN (wide area network) A computer network that spans a relatively large geographical area. Typically, a WAN consists of two or more local area networks (LANs). WebLogic Administration Server See Administration Server. WebLogic Managed Server See Managed Server. 110 Glossary

WebLogic Server domain A logically related group of WebLogic Servers for management as a unit. The domain always includes a WebLogic Administration Server and additional WebLogic Server instances called Managed Servers. Web proxy tier Collective reference to any Bastion Web Servers and Connection Request Proxy Servers in a DMZ of a Home Device Manager deployment. See also application tier, protocol tier. web service Software that supports interoperable machine-to-machine interaction over a network. Other systems interact with the Web service's interface typically using XML over HTTP and other web standards. Applications written in different languages and running on various platforms can use web services to exchange data over networks like the Internet. Wi-Fi (Wireless Fidelity) High-frequency WLAN. Wi-Fi is specified in the 802.11b specification from the IEEE [http://www.ieee.com] and is part of a series of wireless specifications together with 802.11, 802.11a, 802.11b, and 802.11g. All four standards use the Ethernet protocol and CSMA/CA (carrier sense multiple access with collision avoidance) for path sharing. WLAN (wireless local area network) A LAN that sends and receives data through radio, infrared optical signals, or other technology. WLANs do not require a physical connection between the wireless device and the hub. workflow A series of automated steps and/or user-guided tasks for solving a given business problem (for example, to restart a subscription). Workflows are authored and published to the server using the Workflow Builder. Workflow Builder Browser-based tool for creating, updating, and publishing workflows. Published workflows are available to the Workflow Engine and for assignment to individual workflow modules. Workflow Engine The server application that generates the web application screens for a published workflow based on executing a workflow module defined for the workflow. The look and feel of a workflow is based on one of the provided templates stored in the engine application. The Workflow Engine is a separately-licensed additional feature. workflow module A configuration that defines for the Workflow Engine which workflow to execute and the manner in which to execute it on behalf of a web client. Workflow modules are defined in the application configuration using the Configuration Manager. 111

112 Glossary

Index A ALM database user creating manually, 7 ALM licenses, 34 ALM Management Console, 36 URL, 32 ALM Northbound Interface (NBI), 36 ALM SMP data source (see SMP data source) almresturl, 85 answer files invoking to install, 20 understanding, 8 applications deploying, repairing, updating, 44 audience, viii B backups, 8 best practices, 85 builders SMP, 81 C configuration data source requirements, 81 configuring log levels, 36 server properties, 46 system settings, 46 connection parameters, 85 almresturl, 85 configuring mandatory, 81 password, 85 username, 85 conventions documentation, viii counter level roles, 77 criteria templates, 25, 43 D dashboard administering, 48 configuring, 52, 73 deploying, 51 logging into, 50 using, 50 dashboard-config.xml uploading (importing) and downloading (exporting), 76 data source (see SMP data source) data types, 85 default ALM users, 34 groups for ALM, 33 deletedynamicvariable method, 87 deploying applications, 44 deployment scenarios, 3 device type for ALM, 25 devices, 28 domains, enabling trust between, 24 F File Server setting up, 5 finding ALM Management Console URL, 32 G getdynamicvariables method, 88 getinstalledapplications method, 88 getoperationbyid method, 88 groups, default default, 33 H HDM configuration, 25, 43 HDMDomain default ALM users, 33 113

I INCONSISTENTAPPLICATIONS policy event trigger, 44 installation answer files, 8 creating an Oracle user manually, 7 creating backups, 8 deployment scenarios, 3 prerequisites, 4 previewing process, 2 required ports, 6 separate domains, 24 setting up the File Server, 5 silent, 8 installstartapplication method, 89 J JMS message filtering, 28 L license configuration, 23 licenses, 34 log levels configuring, 36 M Manage Configuration, 76 managing users, 32 monitoring dashboard (see dashboard) N Northbound Interface (NBI), 36 P parameters connection, 85 password, 85 policies examples, 44 ports, 6 post-installation configuring the ALM device type, 25 configuring the ALM license, 23 HDM configuration, 25 prerequisites, 4 properties, 46 R rebooting devices because of memory low, 45 repairing applications, 44 required ports, 6 requirements data source configuration, 81 roles counter level, 77 S search profiles, 25, 43 separate domains, enabling trust between, 24 Server Configuration Console configuring log levels, 36 server properties, 46 Service Repository log levels, 36 setdynamicvariable method, 89 silent installations, 8 SMP builders, 81 SMP data source about, 80 best practices, 85 connection parameters, 85 data types, 85 installing, 81 methods, 86 requirements, 81 SSL, 82 understanding, 80 startapplication method, 90 STATISTICSRECEIVED policy event trigger, 45 stopapplication method, 90 system requirements, 4 T troubleshooting, 94 U understanding ALM interfaces, 36 ALM Management Console, 36 ALM Northbound Interface (NBI), 36 licenses, 34 114 Index

uninstallapplication method, 91 uninstalling, 29 updateapplication method, 91 updating applications, 44 Upload (configuration file), 76 username, 85 users managing, 32 W waitdeviceactivation method, 92 WebLogic installing, 5 WebLogic Server Console managing users, 32 115

116 Index