Tm3371 Stud

IBM Tivoli Business Service
IBM Training Manager 6.1.1 for

Administrators
Student Notebook
Course code TM337 ERC 1.0
November 2013
Cloud & Smarter Infrastructure

All files and material for this course (TM337, IBM Tivoli Business Service Manager 6.1.1 for Administrators) are IBM
copyright property covered by the following copyright notice.
Copyright IBM Corp. 2013. All Rights Reserved.
US Government Users Restricted Rights: Use, duplication or disclosure restricted by GSA ADP Schedule Contract with IBM Corp.
IBM, the IBM logo, and ibm.com are trademarks of International Business Machines Corp., registered in many jurisdictions worldwide.
Other product and service names might be trademarks of IBM or other companies. A current list of IBM trademarks is available on the
web at Copyright and trademark information at www.ibm.com/legal/copytrade.shtml.
Trademarks or trademarks of Adobe Systems Incorporated in the United States, and/or other countries.
IT Infrastructure Library is a registered trademark of the Central Computer and Telecommunications Agency which is now part of the
Office of Government Commerce.
Intel, Intel logo, Intel Inside, Intel Inside logo, Intel Centrino, Intel Centrino logo, Celeron, Intel Xeon, Intel SpeedStep, Itanium, and
Pentium are trademarks or registered trademarks of Intel Corporation or its subsidiaries in the United States and other countries.
Linux is a registered trademark of Linus Torvalds in the United States, other countries, or both.
Microsoft, Windows, Windows NT, and the Windows logo are trademarks of Microsoft Corporation in the United States, other countries,
or both.
ITIL is a registered trademark, and a registered community trademark of the Office of Government Commerce, and is registered in the
U.S. Patent and Trademark Office.
UNIX is a registered trademark of The Open Group in the United States and other countries.
Java and all Java-based trademarks and logos are trademarks or registered trademarks of Oracle and/or its affiliates.
Cell Broadband Engine is a trademark of Sony Computer Entertainment, Inc. in the United States, other countries, or both and is used
under license therefrom.
Linear Tape-Open, LTO, the LTO Logo, Ultrium, and the Ultrium logo are trademarks of HP, IBM Corp. and Quantum in the U.S. and
other countries.
The information contained in this publication is provided for informational purposes only. While efforts were made to verify the
completeness and accuracy of the information contained in this publication, it is provided AS IS without warranty of any kind, express or
implied. In addition, this information is based on IBMs current product plans and strategy, which are subject to change by IBM without
notice. IBM shall not be responsible for any damages arising out of the use of, or otherwise related to, this publication or any other
materials. Nothing contained in this publication is intended to, nor shall have the effect of, creating any warranties or representations
from IBM or its suppliers or licensors, or altering the terms and conditions of the applicable license agreement governing the use of IBM
software.
References in this publication to IBM products, programs, or services do not imply that they will be available in all countries in which IBM
operates. Product release dates and/or capabilities referenced in this presentation may change at any time at IBMs sole discretion
based on market opportunities or other factors, and are not intended to be a commitment to future product or feature availability in any
way. Nothing contained in these materials is intended to, nor shall have the effect of, stating or implying that any activities undertaken by
you will result in any specific sales, revenue growth, savings or other results.
Contents
About this course . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . xv

About the student . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . xvi
Learning objectives . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . xvii
Course agenda . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . xix
1 Introduction to IBM Tivoli Business Service Manager 6.1.1. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1

Objectives . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .2
Lesson 1. Business service management overview . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 3
Business service management definitions . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .5
Business service example: Online banking . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .6
Tivoli Business Service Manager functions . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .8
Tivoli Business Service Manager architecture . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .9
Dashboard visualization . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .11
Chart visualization . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .12
Report visualization . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .13
Events . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .14
Business data . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .15
Dependencies and discovery . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .16
Real-time service level agreements . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .17
Migration and upgrade tools . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .18
Business services and service status . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .19
Defining business services with service models . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .20
Service model creation . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .21
Service status and key performance indicators . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .22
Incoming status rules . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .23
Dependency rules . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .24
Numerical formula rules . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .25
Data fetchers . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .26
Summary . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .27
2 Service model basics . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 28

Objectives . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .29
Lesson 1. Starting and stopping Tivoli Business Service Manager components . . . . . . . . . . . . . . . . . . . . 30
Tivoli Business Service Manager components . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .31
Starting and stopping the ObjectServer . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .33
Starting and stopping the data server . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .34
Starting and stopping the dashboard server . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .35
Tivoli Integrated Portal server console logon . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .36
Tivoli Integrated Portal console elements . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .37
Copyright IBM Corp. 2013 Student Notebook iii

Course materials may not be reproduced in whole or in part without the prior written permission of IBM.
Contents
Instructor demonstration . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 38
Student exercises . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 39
Lesson 2. Templates and rules . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 40
Service templates . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 41
Template rules . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 42
Service template examples . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 44
Template and service relationship . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 45
Business service instances . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 46
Service model hierarchies . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 48
Example: Web application service model . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 49
Creating a template . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 50
The Service Configuration page . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 51
Opening the Template Editor . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 52
Example: Creating a template . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 53
Example: Status rule threshold criteria . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 54
Creating an incoming status rule . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 55
Selecting incoming status rule type . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 56
Incoming status rule form overview . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 57
Rule Name and Data Feed . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 58
Selecting event discriminators . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 59
Matching the service instance name . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 60
Choosing the status evaluation fields . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 61
Setting the threshold filter criteria . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 62
Metric collection . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 63
Saving the template . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 64
Service navigation view after template creation . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 65
Lesson 3. Creating template dependencies . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 68
Creating multiple-level template models . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 69
Dependency rules overview . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 70
Creating dependency rules . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 71
Creating a good, marginal, and bad aggregation dependency rule . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 72
Saving the template . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 73
Viewing the template hierarchy . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 74
Lesson 4. Creating and testing service instances . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 77
Creating service instances . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 79
Creating service instances . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 80
Example: Creating a WebServer instance . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 81
Assigning a template . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 82
Adding dependent services to a parent service . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 83
Setting the service tree list order . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 84
Service models in the Service Viewer portlet . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 85
Sending test events . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 86
Student exercise service hierarchies diagram . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 88
iv IBM Tivoli Business Service Manager 6.1.1 for Administrators Copyright IBM Corp. 2013
V7.0
Contents
Uempty Student exercises . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .89

Summary . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .90
3 Expanding service model functions . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 91

Objectives . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .92
Lesson 1. Identifying services with multiple event fields . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 93
Expanding service name identification . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .95
Example: WebServerStatusRule operation . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .96
Modifying WebServerStatusRule . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .97
Service identification fields . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .98
Example: Creating a second WebServer1 service . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .99
Configuring the service display name . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .100
Viewing the WebServer1 service instances . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .101
Instructor demonstration . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .102
Student exercises . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .103
Lesson 2. Adding service identification fields to match events . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 104
Example: Node value mismatch . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .106
Multiple service identification fields . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .107
Adding service identification fields . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .108
Lesson 3. Using output expressions to evaluate template rules . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 111
Default template rule evaluation . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .113
Example: Multiple rule evaluation requirements . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .114
Editing the template properties . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .115
Building output expressions . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .116
Final output expression . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .117
Output expression evaluation results . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .118
Service heartbeat overview . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .119
Configuring the service heartbeat . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .120
Service heartbeat results . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .121
Lesson 4. Numerical rules and key performance indicators . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 124
Numerical modeling . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .126
Showing key performance indicators . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .127
Creating a numerical incoming status rule . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .128
Setting a numerical rule filter . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .129
Assigning the numerical rule output value . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .130
Customizing a tree template to show KPIs . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .131
Tree template editor . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .132
Adding a column . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .133
Assigning a value to a column . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .134
Testing the numerical rule . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .135
Reprocessing events . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .136
Lesson 5. Aggregating numerical rules . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 139
Copyright IBM Corp. 2013 Student Notebook v

Contents
Aggregation dependency rules . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 140

Showing aggregated numerical values . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 141
Creating a numerical aggregation rule . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 142
Adding an aggregation metric to the tree template definition . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 143
Viewing the aggregation rule metric on the service tree . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 144
Instructor demonstration . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 145
Student exercises . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 146
Lesson 6. Calculating weighted averages . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 147
Using weighted averages in aggregation rules . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 149
Creating a template parameter . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 150
Using a multiplier expression with a numerical aggregation calculation . . . . . . . . . . . . . . . . . . . . . . . . 151
Modifying service parameters . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 152
Viewing the effect of a weighted average calculation . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 153
Summary . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 156
4 Service level agreements. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 157

Objectives . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 158
Lesson 1. Creating service level agreements . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 159
Service level agreement overview . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 161
SLA status: Violations and warnings . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 162
Real-time tracking of service availability . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 163
Types of service level agreements . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 164
Duration SLA violations and warnings . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 165
Cumulative duration SLA violations and warnings . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 166
Incident count SLA violations and warnings . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 167
SLAs indicators in the default service icon . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 168
Example: Duration SLA criteria . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 169
Editing SLAs in the template editor . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 170
Configuring a cumulative duration SLA . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 171
Configuring an incident count SLA . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 172
Creating multiple service levels for templates . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 173
Adding SLA definitions to a template . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 174
Configuring the second set of SLA definitions . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 175
Applying an SLA to a service . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 176
Student exercise . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 178
Lesson 2. Testing service level agreements . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 179
Testing and analyzing service level agreement operations . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 181
Viewing a cumulative duration SLA operation . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 182
Viewing incident count SLA operation . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 183
Revenue penalties . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 184
Viewing SLA penalty calculations . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 185
Clearing SLA states . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 186
Lesson 3. Creating and using maintenance schedules . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 189
vi IBM Tivoli Business Service Manager 6.1.1 for Administrators Copyright IBM Corp. 2013
V7.0
Contents
Uempty Maintenance schedules . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .191

Creating a maintenance schedule . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .192
Defining the time window . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .193
Choosing a maintenance schedule . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .194
Viewing maintenance schedule effects . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .195
Summary . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .198
5 Data fetchers. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 199

Objectives . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .200
Lesson 1. Data fetcher overview . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 201
Creating services with business data . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .203
Example: Trouble ticket data . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .204
Retrieving ticket data . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .205
Ticket data evaluation . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .206
Data fetcher creation and configuration tasks . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .207
Creating and configuring a data source . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .208
Creating and configuring a data fetcher . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .209
Steps to create and configure a data fetcher . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .210
Using the query builder . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .211
Selecting table fields . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .212
Setting a data filter . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .213
Creating metrics with retrieved data . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .214
Grouping retrieved data . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .215
Ordering retrieved data . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .216
Finishing the data fetcher definition . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .217
Testing the data fetcher . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .218
Creating a data fetcher-based numerical rule . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .219
Setting the status with the numerical value . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .220
Adding business data to the service tree . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .221
Viewing open ticket metrics on the service tree . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .222
Lesson 2. Dependency rules and data fetchers . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 225
Aggregating business data in parent templates . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .226
Developing a service model to aggregate all web servers . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .227
Defining the numerical aggregation rule . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .228
Creating the aggregation service model . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .229
Adding the open ticket aggregation KPI to the service tree . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .230
Viewing the total web server open tickets KPI . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .231
Summary . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .234
6 External Service Dependency Adapter rules . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 235

Objectives . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .236
Lesson 1. External Service Dependency Adapter overview . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 237
External Service Dependency Adapter rule basics . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .239
Copyright IBM Corp. 2013 Student Notebook vii

Contents
When to use ESDA rules . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 240

ESDA operation . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 241
Persistent and transient services . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 242
Seed services . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 243
ESDA example: Service model template . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 244
ESDA example: TBSMDEMO database data . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 245
ESDA example: Creating the ESDA rule . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 246
Understanding the ESDA rule form . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 247
Processing Child rules . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 248
ESDA example: Customer template Child rule . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 249
Triggering an ESDA rule . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 250
Viewing the child services . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 251
Lesson 2. Expanding ESDA rules . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 254
Creating a second child rule . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 256
Contract and connection relationships . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 257
Creating the Contract Child rule . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 258
Invalidating transient services . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 259
Viewing the Contract Child rule operation . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 260
Lesson 3. Using policy scripts . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 263
Creating child services with policy scripts . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 265
Example: Using a policy in a Child rule . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 266
Variables passed to the policy . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 267
Reviewing the Connection Child rule policy . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 268
Parsing the parent service name . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 269
Passing parameters . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 270
Adding attributes to child services . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 271
Saving the policy script . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 272
Testing the policy-based Child rule . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 273
Troubleshooting ESDA policies . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 274
Summary . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 277
7 Automatic service model creation . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 278

Objectives . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 279
Lesson 1. Automatic service population overview . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 280
Creating services with events and automatic population rules . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 282
Persistent and transient service review . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 283
Comparing service creation tools . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 284
Event-based automatic population . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 285
Creating an automatic population rule . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 286
Configuration form . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 287
Parent configuration . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 288
Triggering event automatic population rules . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 289
viii IBM Tivoli Business Service Manager 6.1.1 for Administrators Copyright IBM Corp. 2013
V7.0
Contents
Uempty Viewing event automatic population rule operation . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .290

Lesson 2. Data fetchers and automatic population rules . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 293
Creating services with data fetchers and automatic population rules . . . . . . . . . . . . . . . . . . . . . . . . . . .295
Data fetcher automatic population example . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .296
Viewing data fetcher automatic population rule operation . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .297
Lesson 3. form when the Creating services from discovered resources . . . . . . . . . . . . . . . . . . . . . . . . . 300
Discovered resources overview . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .302
Business service discovery architecture . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .303
Service component repository . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .304
Discovery data sample . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .305
Using the Discovery Library Toolkit . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .306
Discovery data and monitor event integration . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .307
Mapping probe events to discovered resources . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .308
Event identifiers . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .309
Incoming status rule for event mapping . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .310
Probe for Tivoli Event Integration Facility . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .311
Probe for Tivoli EIF logical architecture . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .312
z/OS event integration overview . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .313
Configuring the EIF probe . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .314
Starting and stopping the EIF probe . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .315
EIF probe troubleshooting . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .316
Application navigation: Launch-in-context . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .317
Resource context sharing . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .318
LIC service instance parameters . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .319
LIC menu availability . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .320
Tivoli Monitoring: Context launch target . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .321
Lesson 4. Building services in the Service Component Repository . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 324
Service component repository review . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .326
Service model examples . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .327
Component registry viewer tool . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .328
Example: Examing SCR classes . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .329
Business Service Composer . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .330
BSC project elements . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .331
BSC interface elements . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .332
Configuring static definitions . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .333
Configuring policy patterns . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .334
Example: Creating a service model with the BSC . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .335
Creating the static definition . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .336
Creating the policy pattern . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .337
Implementing a BSC project . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .338
BSC project file considerations . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .339
Copyright IBM Corp. 2013 Student Notebook ix

Contents

Summary . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 342
8 Security . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 343
Objectives . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 345
Lesson 1. Security overview . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 346
Authentication and authorization . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 348
Security services . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 349
Authentication overview . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 350
File-based user repository . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 351
Example: File-based user repository . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 352
File-based repository configuration . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 353
OMNIbus ObjectServer user and group repository . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 354
LDAP overview . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 355
LDAP logical architecture . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 356
Federated repository overview . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 357
Multiple repositories as a federated repository . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 358
Example of a user lookup . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 359
Lesson 2. Configuring LDAP authentication . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 360
Configuring LDAP . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 362
Starting the WebSphere administrative console . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 363
Adding an LDAP repository . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 364
LDAP configuration: Add base entry to realm . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 365
Defining the LDAP base entry . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 366
Defining the LDAP repository . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 367
Saving configuration changes . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 368
Completing the WebSphere base entry . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 369
Repository entity types . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 370
Lesson 3. Configuring SSL authentication . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 373
Configuring secure communications with an LDAP server . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 375
Tivoli Integrated Portal credential stores . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 376
Retrieving the LDAP signer certificate . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 377
Entering LDAP certificate information . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 378
Configuring the Tivoli Integrated Portal server for SSL . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 379
Lesson 4. Managing users, groups, and authorization roles . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 382
User, group, and authorization roles overview . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 384
Managing users and groups . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 385
Managing authorization roles . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 386
Assigning roles to a user or group . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 387
Student Exercises . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 389
Summary . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 390
9 Custom dashboards and page management . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 391

Objectives . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 393
x IBM Tivoli Business Service Manager 6.1.1 for Administrators Copyright IBM Corp. 2013
V7.0
Contents
Uempty Lesson 1. Dashboard tools overview . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 394

Jazz for Service Management components . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .396
Visualization services overview . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .397
Visualization Services architecture . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .398
Mobile dashboard considerations . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .399
Mobile page navigation . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .400
Lesson 2. Data connections . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 401
Getting data for dashboards: Connections . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .403
Creating connections . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .404
Configuring a connection . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .405
Connection authentication . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .406
Other application Integration . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .407
Lesson 3. Creating dashboard pages . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 410
Creating a dashboard page . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .412
Page layout styles . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .413
Dashboard workspace elements . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .414
Mobile widget overview . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .415
Scalar versus list widgets . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .416
Creating dashboards: Customizing widgets . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .417
Widget customization: Selecting a data set . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .418
Widget customization: Visualization settings . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .419
Connecting pages with events and wires . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .420
Events and wires examples . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .421
Event transformations . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .422
Lesson 4. Managing dashboards . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 425
Managing dashboards . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .427
Organizing dashboards with views and profiles . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .428
Authorization roles . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .429
Creating authorization roles . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .430
Managing views . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .431
Automatically opening pages in a view . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .432
Creating console preference profiles . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .433
Setting profile authorization and the default view . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .434
Summary . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .437
10 Command line administration . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 438

Objectives . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .439
Lesson 1. Managing services with the command line . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 440
Creating and configuring services with the command line . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .442
Accessing RAD shell commands . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .443
Partial RAD shell command list . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .444
Expanding service model creation . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .445
Copyright IBM Corp. 2013 Student Notebook xi

Contents
Example: Creating a service instance . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 446

Example: Creating an instance dependency . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 447
Lesson 2. Exporting and importing deployment customizations . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 450
Exporting and importing deployment customizations with the command line . . . . . . . . . . . . . . . . . . . . 452
Customization artifacts overview . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 453
Managing customization artifacts . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 454
Summary . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 457
11 Maintenance and troubleshooting . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 459

Objectives . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 461
Lesson 1. Deployment administration . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 462
Data server database management . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 464
Data server database backup and restore . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 465
Tivoli Business Service Manager failover . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 466
Failover logical configuration . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 467
DB2 failover considerations . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 468
ObjectServer failover considerations . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 469
Data server failover considerations . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 470
Dashboard server failover considerations . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 471
Dashboard server load balancing . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 472
Failover implementation tasks . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 473
Starting the failover servers . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 475
Lesson 2. Troubleshooting and support resources . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 476
Troubleshooting tools . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 478
Audit logging . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 479
Log file locations . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 480
Setting the data server log detail level . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 481
Enabling Impact policy logging . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 482
Setting the dashboard server logging level . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 483
Setting the change log detail levels . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 484
Setting log and trace levels . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 485
IBM developerWorks . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 486
Lesson 3. Tuning the dashboard server . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 487
Server tuning tools . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 488
IBM Support Assistant functions . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 489
Installing IBM Support Assistant add-ons . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 490
Java virtual machine overview . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 491
Performance effects of the JVM heap size . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 492
Tuning the Tivoli Integrated Portal server JVM . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 493
Tracking JVM garbage collection . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 494
Evaluating the JVM garbage collection log . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 495
Selecting optimal heap size values . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 496
xii IBM Tivoli Business Service Manager 6.1.1 for Administrators Copyright IBM Corp. 2013
V7.0
Contents
Uempty Student exercises . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .498

Summary . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .499
12 Single sign-on and application integration . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 501

Objectives . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .503
Lesson 1. Managing single sign-on . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 504
Single sign-on overview . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .506
SSO logical diagram and operation . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .507
SSO configuration tasks . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .508
Setting the SSO scope . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .509
Importing and exporting SSO software keys . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .510
Web console considerations . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .511
Configuring launch-in-context . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .512
Using launch-in-context with SSO . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .513
Summary . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .516
Copyright IBM Corp. 2013 Student Notebook xiii

Contents
xiv IBM Tivoli Business Service Manager 6.1.1 for Administrators Copyright IBM Corp. 2013
About this course
IBM Tivoli Business Service Manager

6.1.1 for Administrators
Copyright IBM Corporation 2013

Copyright IBM Corp. 2013 xv

About this course
This course is a five-day instructor-led course. The course is taught

online or in a classroom. Highlights
IBM Tivoli Business Service Manager tracks and provides Intermediate training for
visualization of the status of critical business services and System administrators
associated service level agreements (SLAs). With Tivoli Business Tivoli Support
Service Manager 6.1.1, you immediately see the impact of specialists, ISST
business service outages. You can target resources and actions Services consultants,
toward the most critical and costly IT business services. IGS consultants, and
business partners.
In this course, you learn business service management concepts, Five-day course.
develop and build business service models, create custom
Learn how to create and
dashboards with the Jazz for Service Management visualization
manage business
services, integrate with Common Data Model resources, and
services to track the
examine the Tivoli Business Service Manager architecture.
status of business health
Through hands-on exercises, learn how to use, configure, and
and the impact of
administer Tivoli Business Service Manager 6.1.1.
business outages.
The lab environment for this course uses three SUSE Linux
Enterprise 11 64-bit platform servers per student.
For information about other related Cloud & Smarter Infrastructure courses, visit the Cloud &
Smarter Infrastructure education training paths website:
ibm.com/software/software/tivoli/education/
Details
Delivery method Classroom or instructor-led online (ILO)
Course level ERC 1.0
This course is a new course.
Product and version Tivoli Business Service Manager 6.1.1
Duration 5 days
Skill level Intermediate
About the student

This course is intended for customer system administrators with responsibility for maintaining a
Tivoli Business Service Manager 6.1.1 deployment, Tivoli Support specialists, ISST Services
consultants, IGS consultants, and business partners. Before taking this course, make sure that you
have the following skills:
xvi IBM Tivoli Business Service Manager 6.1.1 for Administrators Copyright IBM Corp. 2013
V7.0
About this course
Uempty Working knowledge of, or experience with, Netcool/OMNIbus event manager
General knowledge of database and SQL language concepts

General knowledge of business information technology (IT) concepts, such as networks,
business applications, and business databases
Learning objectives
Learning objectives
After completing this course, you should be able to perform the
following tasks:
Business service management concepts
Define business service management concepts
Define IBM Tivoli Business Service Manager architectural components
Model business services
Evaluate business processes to develop service models
Build business service models using templates and template rules
Use business and monitor data to track the status of business service
models
Advanced service models
Evaluate service status using multiple rules
Track key performance indicators for using business and monitor data
Create and manage service level agreements (SLAs)
Copyright IBM Corporation 2013 2
Copyright IBM Corp. 2013 Student Notebook xvii

About this course
Learning objectives (continued)

Business services
Create and manage custom dashboards
Use key performance indicators in dashboards
Manage dashboards for multiple user types
Tivoli Business Service Manager
Manage and configure user and group repositories using Tivoli Integrated
Portal services
Manage user and group authentication
Manage access to system objects with authorization roles
Configure and manage Tivoli Business Service Manager with command
line tools
Tune server components to optimize server resources
Troubleshoot Tivoli Business Service Manager components
Configure single sign-on support for the dashboard server on the Tivoli
Integrated Portal
xviii IBM Tivoli Business Service Manager 6.1.1 for Administrators Copyright IBM Corp. 2013
V7.0
About this course
Course agenda
Uempty
Course agenda
The course contains the following units:
1. Introduction to IBM Tivoli Business Service Manager 6.1.1
This unit explores the concepts of business service management. It also provides an overview
of the tools that are provided with Tivoli Business Service Manager to create, manage, and
visualize business services.
There are no student exercises for this unit.
2. Service model basics

Templates and rules provide the foundation for the Tivoli Business Service Manager service
model. This unit explores the relationship between templates, services, and rules.
In these exercises, you learn how to create and modify the primary components of Tivoli
Business Service Manager templates, rules, and services. You create business service
hierarchies and test rule operations with simulated monitor events. The template capabilities
are extended in later exercises.
3. Expanding service model functions

Business services can receive probe events from several sources. The template rules must
respond correctly to the additional information. Templates can include multiple rules, and you
must decide how to assess the overall service status when each rule evaluates to a different
status. Also, template rules provide an important tool for calculating key performance indicators
(KPIs) of business operations. KPIs are then available for visual representations of business
services. In this unit, you learn methods of extending service templates to provide
comprehensive representations of business services.
In these exercises, you expand the capabilities of the template rules you created in the Service
model basics exercises on page 2. You modify and create rules that are more flexible in
adapting to data from multiple sources.
4. Service level agreements

A service level agreement (SLA) typically defines an agreement, between a provider and a
customer, that specifies an acceptable level of service for a resource. Tivoli Business Service
Manager provides tools to define and track SLAs for any service instance. In this unit, you learn
about the types of SLAs that are supported. You learn how to configure SLAs and apply them to
one or more services. Most SLAs include routine maintenance windows for a service. The
maintenance windows are not counted against an SLA calculation. You learn how to create and
apply maintenance windows to business service instances.
In these exercises, you configure and test the three types of Service Level Agreement (SLA)
that are available with Tivoli Business Service Manager. You also configure and test
Copyright IBM Corp. 2013 Student Notebook xix

About this course
Course agenda
maintenance windows, which provide a mechanism for temporarily removing SLA tracking on a
service.
5. Data fetchers
Business service models must be able to respond to business data and monitor events.
Templates can have multiple rules, which requires a complex evaluation of rule states. Template
rules can also calculate key performance indicators (KPIs). KPIs are then available to be
included in visual representations of business services. This unit demonstrates a function that is
called a data fetcher. Data fetchers extend service template functions to provide comprehensive
representations of business services.
In previous exercises, you created template rules that responded to incoming monitor events. In
these exercises you create template rules that evaluate business data that is retrieved from a
business database. You also create rules that calculate numerical values, known as key
performance indicators (KPIs). You modify the console interface to show the KPIs.
6. External Service Dependency Adapter rules

External Service Dependency Adapters (ESDAs) rules dynamically create service model
hierarchies with business data. ESDA rules go beyond the capabilities of data fetcher rules,
supporting multiple database queries and data enrichment. ESDA rules create parent and child
service instances at all levels of a template model.
In these exercises, you develop External Service Dependency Adapter (ESDA) rules to
automatically create service instances and service models. The ESDA evaluates business data
from an external database and dynamically builds business services. For these exercises, the
simulated data is stored in the Tivoli Business Service Manager DB2 database.
7. Automatic service model creation

In this unit, you learn several methods of automatically creating service models. You learn how
to use incoming events and data fetchers with automatic population rules. You learn how to
create services with the Discovery Library Toolkit and structured discovery data. Services that
are created with discovery data are created in the Service Component Repository (SCR)
database. Finally, you learn how to analyze the SCR and use the Business Service Composer
tool to enhance and create service models from discovered services.
In these exercises, you use several Tivoli Business Service Manager tools to automatically
create service instances and service models. You create automatic population rules that are
attached to incoming status rules. When the incoming status rule receives data, the automatic
population rule is triggered. You create a service instance using discovery data from an IBM
Tivoli Monitoring server. Last, you examine and enrich service models that are created by
processing discovery data from a Tivoli Application Dependency Discovery Manager (TADDM)
server.
8. Security
Controlling access to system resources is a critical component of monitoring system resources.
In this unit, you learn how authentication and authorization to the Tivoli Business Service
xx IBM Tivoli Business Service Manager 6.1.1 for Administrators Copyright IBM Corp. 2013
V7.0
About this course
Course agenda
Uempty Manager dashboard server is managed. The dashboard server, also known as the Tivoli
Integrated Portal, supports multiple user and group authentication repositories. You apply roles
to control authorization to data server software objects. This unit also covers how authentication
and authorization are configured to provide a comprehensive, secure environment.
User authentication and authorization are managed with the Tivoli Integrated Portal and Jazz
for Service Management security services. In these exercises, you configure an LDAP user
authentication service for the Tivoli Integrated Portal server. You then assign authorization roles
to an LDAP user group. You use authorization roles control user access to Tivoli Integrated
Portal server and Jazz for Service Management resources.
9. Custom dashboards and page management

A new feature of Tivoli Business Service Manager 6.1.1 is the addition of the Jazz for Service
Management version 1.1 technology. Jazz for Service Management includes visualization
services that are used to create and manage business dashboards. This unit includes an
overview of the Jazz for Service Management services and reviews methods for creating and
managing custom dashboards with the Jazz for Service Management visualization services.
You also learn how to use authorization roles to control user access to dashboards.
In these exercises, you customize the visualization of business service data with the Jazz for
Service Management visualization services. You create a dashboard for members of the
executiveManagementGroup group. The dashboard consists of two levels of linked pages. You
also create custom roles, views, and console preference profiles to manage access to the
dashboard pages.
10. Command line administration

The RAD shell command interpreter provides a simple approach to creating components in
Tivoli Business Service Manager. All data server functions available through the graphical user
interface are also available with the command interpreter. You can use commands with scripts
to automatically update service models that are based on dynamic data. This unit expands
service model creation with the RAD shell to create new service instances. This unit also
reviews commands to manage customization artifacts that are used to back up and restore
deployment configurations.
The console-based Tivoli Business Service Manager administrative tasks are available with
command-line tools. In this unit, you use several common command-line tools to export
business service definitions and customizations.
11. Maintenance and troubleshooting

Tivoli Business Service Manager uses DB2 to store operational and historical data. In this unit,
you review the database schema that are used in Tivoli Business Service Manager. You also
learn the high-level tasks that are required to implement backup components for the
ObjectServer, data server, and dashboard server. You learn about the files and tools that are
used to troubleshoot Tivoli Business Service Manager operations. Finally, you learn how to tune
the Java virtual machine settings for the dashboard server.
Copyright IBM Corp. 2013 Student Notebook xxi

About this course
Course agenda
A primary factor that affects the performance of the Tivoli Integrated Portal server and data
server is the Java virtual machine (JVM) configuration. This exercise demonstrates the effect of
changing server heap size on the Tivoli Integrated Portal Java virtual machine (JVM) garbage
collection cycle.
12. Single sign-on and application integration

This unit describes the major tasks that are involved in configuring Tivoli Business Service
Manager to support single sign-on. You also learn how to configure and use launch-in-context
for supported Tivoli Business Service Manager applications.
Products supporting the Tivoli Integrated Portal and IBM Tivoli Monitoring products support an
authentication infrastructure that is known as single sign-on (SSO). Products within a common
SSO domain require a single, initial, interactive user authentication to one product. Connecting
to a second SSO product console does not require extra interactive authentication. Switching to
and from one SSO-enabled product to another is done with a mechanism called launch-in-
context (LIC). Incorporating SSO with Tivoli Integrated Portal-enabled applications provides the
capability for multiple application portlets to be integrated on the same portal page. In these
exercises, you configure the Tivoli Integrated Portal to participate in an SSO realm with the
itm01 and jazz01 virtual images.
xxii IBM Tivoli Business Service Manager 6.1.1 for Administrators Copyright IBM Corp. 2013
1 Introduction to IBM Tivoli Business
Service Manager 6.1.1
1 Introduction to IBM Tivoli Business

Service Manager 6.1.1

What this unit is about This unit explores the concepts of business service
management. It also provides an overview of the tools
that are provided with Tivoli Business Service Manager to
create, manage, and visualize business services.
How you check your progress You can check your progress in the following way:
Review questions
Copyright IBM Corp. 2013 1

1 Introduction to IBM Tivoli Business Service Manager 6.1.1
References SC23-6040-09 Business Service Manager 6.1.1

Administrators Guide
Jazz for Service Management 1.1 Offering Guide
http://www.ibm.com/developerworks/servicemanagemen
t/bsm/tbsm/index.html
IBM DeveloperWorks Tivoli Business Service Manager
Community
Objectives
When you complete this unit, you can perform the following
tasks:
Define business services and business service management
Describe the IBM Tivoli Business Service Manager 6.1.1 capabilities
Describe the primary Tivoli Business Service Manager architectural
components
Describe the tools that are available in Tivoli Business Service
Manager 6.1.1 to create, track, and visualize business services
Objectives
2 IBM Tivoli Business Service Manager 6.1.1 for Administrators Copyright IBM Corp. 2013
V7.0
Lesson 1. Business service management overview
Uempty
Lesson 1. Business service management

overview
Lesson 1. Business service

management overview
What this lesson is about In this lesson, you learn the basic concepts of business
services and business service management. You learn
the architecture, functions, and tools that are provided
with Tivoli Business Service Manager 6.1.1.
Copyright IBM Corp. 2013 Student Notebook 3

What you should be able to do After completing this lesson, you should be able to
perform the following tasks:
Define business services and business service
management
Describe the IBM Tivoli Business Service Manager
6.1.1 capabilities
Describe the primary Tivoli Business Service Manager
architectural components
Describe the tools that are available in Tivoli Business
Service Manager 6.1.1 to create, track, and visualize
business services
References GI11-8056-09 Business Service Manager Version 6.1.1

Exploring TBSM
V7.0
Uempty
Business service management definitions

A business service is any combination of applications,
middleware, security, storage, networks, and other key
performance indicators that collectively support a higher level
business component.
Business service management is a method of grouping and
tracking the status and business impact of the components that
comprise a business service.
A business service model is any logical grouping of the
components that comprise a business service.
Business service management definitions
Business services are logical groupings of managed IT or software application resources that
represent a higher-level view of an application or business function. The tools that are provided with
Tivoli Business Service Manager 6.1.1 are used to create, manage, and view logical business
service models. You design the service models to track the status of a business service or key
performance indicators (KPIs). The service status and KPIs are configured with rules that react to
monitor events or business data.
Tivoli Business Service Manager provides these tools to track the status of business services:
Visualization services to show hierarchical relationships and high-level views of service models.
Real-time tracking of the status of a business service or KPIs.
Real-time tracking of service level agreements (SLAs) against a business service.

Evaluation of multiple data sources to track the status or KPIs for a business service.
Dynamic and historical viewing of business and monitor data.

Business service example: Online banking

To completely reflect the status of a customer online banking application, the application and all
supporting infrastructure must be tracked as one logical entity.
Customer experience Application servers Firewalls
Routers Databases Web servers

Database clusters Web server farms
Business service example: Online banking
Business services logically group low-level monitored physical objects or business processes to
create higher-level logical objects that represent a business process or service. Online banking is
an example of a business service.
For this example, there are several target audience perspectives:

From a customer perspective, an online banking application is seen as a single web page or
application. Customers ultimately see the application as working or not working, depending on
the banking transactions they are trying to complete.
To a bank executive responsible for maintaining the online banking application, the customer
experience is one of many business services of which they are concerned. At a high level,
executives must know whether the components that support the online banking are working.
However, they do not need to see the status of low-level services, such as servers or routers.
A manager responsible for maintaining all networks is concerned with all of the bank network
resources. However, managers also must know which outages directly affect online banking
and which outages affect an individual bank office.
V7.0
Uempty A network administrator must be able to see the status of all networks. However,
administrators also must see the status of each router and communication link in all networks.
When an outage is detected, they must be able to quickly pinpoint the location and cause of the
outage.
Tivoli Business Service Manager provides tools to track and present appropriate business service
data to each of these user types.

Tivoli Business Service Manager functions
Tivoli Business Service Manager provides tools to support these major tasks:
Visualization of the status of business services.
Visualization of the impact of lower-level business performance on higher-level
business processes.
Tracking of business service status or key performance indicators with business
data, monitor events, and discovered resources.
Tracking of service level agreements (SLAs) in real time.
Tivoli Business Service Manager functions
Tivoli Business Service Manager provides tools to present logical views of business service data.
All available data can be evaluated to provide high-level, intermediate-level, or low-level business
service views.
Tivoli Business Service Manager relies on three main sources to track the status of business
services and KPIs:
Events: You use any type of monitor event sources to track service status and automatically
build service instances and relationships. Monitor event sources include Tivoli Monitoring, Tivoli
Composite Application Manager, and Tivoli Enterprise Console.
Business data: You use business data to provide another method of tracking service status
and creating business service instances and relationships. This evaluation is independent of
any systems management monitoring.
Dependencies and discovery: You discover business service relationship data with a product
such as Tivoli Application Dependency Discovery Manager. In addition, an application
developer can provide a software tool that is called a Discovery Library Adapter. This tool
produces relationship data within the scope of the managed application. You use the data to
build business service models.
V7.0
Uempty
Tivoli Business Service Manager architecture
Tivoli Business Service Manager architecture
The primary Tivoli Business Service Manager architectural components are as follows:
Dashboard server: This console application is a Java Platform, Enterprise Edition application
that is supported by the Tivoli Integrated Portal. The dashboard server provides business
service visualization and application administration, authentication, and authorization services.
Analysis tools and policy script facilities are provided with Tivoli Netcool/Impact technology.
Data server: The data server is the Tivoli Business Service Manager analysis and tracking
engine. Business service configuration and status information is processed with the data server.
Configuration and status information are stored in a DB2 database.
Tivoli Netcool/OMNIbus ObjectServer: This application is the Tivoli Business Service

Manager event engine. The ObjectServer receives monitor events, triggering the data server to
evaluate the event against defined business service rules. As business service status changes
are tracked, the data server generates events and stores them in the ObjectServer.
Discovery Library Toolkit: This component processes structured data to create, configure,
and modify business services. The structure conforms to the Common Data Model method for

storing infrastructure resources. This component is also used to process customizations to a

Tivoli Business Service Manager environment.
Netcool/OMNIbus Probe for Tivoli EIF: This component forwards events that are generated
outside the Tivoli Netcool/OMNIbus probe infrastructure. Examples of other event providers
include Tivoli Monitoring, Tivoli Enterprise Console, and monitoring software from businesses
that are not IBM businesses.
V7.0
Uempty
Dashboard visualization
Jazz for Service Management, which is installed with Tivoli

Business Service Manager 6.1.1, provides tools to customize
and show business data.
Dashboards are created with simple graphical tools.
You create pages for different target user groups.
You include business data from multiple application sources.
Dashboard visualization
Tivoli Business Service Manager 6.1.1 visualization services are provided with the Jazz for Service
Management 1.1 Dashboard Application Services Hub (DASH) server. The DASH server is
installed separately and is used to visualize business data from many business applications. The
Tivoli Integrated Portal 2.2 server provides the graphical administrative console services for Tivoli
Business Service Manager 6.1.1.
The dashboard visualization services are used to show service models, key performance indicators
(KPIs), and data from other applications for comprehensive views of business service health. An
administrator creates custom dashboards to present information for a specific audience and
business. More information about the visual tools is in the unit, "Custom dashboards and page
management".

Chart visualization
Business data and service model data can be shown as dynamic
charts or saved in reports.
Chart visualization
The visualization services that are used by Tivoli Business Service Manager include a charting
widget that renders business data in real time. You customize the presentation of data in various
formats, such as pie or bar charts. Use charts to enhance the information included in business
dashboards.
V7.0
Uempty
Report visualization
Reporting services are provided with the installation of the
Tivoli Common Reporting and Cognos Business Intelligence
infrastructure.
Predefined Tivoli Business Service Manager reports are
included with the installation.
You can create reports for mobile devices.
Report visualization
Tivoli Business Service Manager includes Tivoli Common Reporting services to analyze and show
business data. Tivoli Common Reporting is a separate application that is provided with the Tivoli
Business Service Manager installation media. You can generate reports from application and
business data.
Tivoli Common Reporting 3.1 is based on Cognos 10.2 Business Intelligence engine. Tivoli
Common Reporting 3.1 includes support for the Jazz for Service Management visualization
services and mobile devices.

Events
Events can drive both the creation and status of business
service models.
Event sources include: OMNIbus probes, Tivoli Enterprise Console, Tivoli

Monitoring, OMEGAMON, ITCAM transaction analysis, IBM Tivoli
Network Manager, and non-IBM monitoring sources.
Events are evaluated with business service model rules.
Events
Tivoli Business Service Manager uses the Tivoli Netcool/OMNIbus ObjectServer as an event
engine. Tivoli Business Service Manager generates and stores business service status events in
the ObjectServer. External events can come from many sources, including the following ones:
Tivoli Netcool/OMNIbus probes
Tivoli Enterprise Console Server
Tivoli Monitoring
IBM Tivoli OMEGAMON XE

IBM Tivoli Composite Application Manager products
IBM Tivoli Network Manager IP Edition
Non-IBM monitoring applications
Events can be used to automatically create business services and business service relationships.
V7.0
Uempty
Business data
Business service status can be driven with external
business data.
Business data examples include trouble tickets, transactional data,

billing records, and call center details.
Business data sources can include Tivoli Data Warehouse, customer
relationship management (CRM) sources, and locally developed
databases.
Business data
Business data can drive business service status and automatic business service creation. You can
query external data sources for the following purposes:
Evaluate business service status
Determine business service relationships
Calculate key performance indicators (KPIs).
Any available data can be used to provide a business service view into an enterprise infrastructure.

Dependencies and discovery
Use Common Data Model discovery data to create

complex business service hierarchies.
Use existing system management or application
deployment architectures.
Dependencies and discovery
Tivoli Business Service Manager integrates with the IBM Tivoli Application Dependency Discovery
Manager and other Change and Configuration Management Databases. Business service data is
cataloged with the Common Data Model standards.
The Discovery Library Toolkit uses discovery data for these purposes:
Automatically create application, system, and network business service models
Integrate change history information with business service views
Map discovered resource business services with forwarded monitor events
V7.0
Uempty
Real-time service level agreements

Create and assign minimum level of service thresholds for a
business service.
Calculate penalty costs that are associated with threshold
violations.
Use these three types of service level agreements (SLAs):
Duration
Cumulative duration
Incident count
Real-time service level agreements
Tivoli Business Service Manager includes tools to track the status of a business service against a
defined service level agreement (SLA). Internal and external customers can define a target level of
service for any modeled business service. You can also use the Jazz for Service Management
visualization services to track SLAs, in addition to service status or key performance indicators.
Historical reports and real-time SLA charts can be included with other business dashboard views.

Migration and upgrade tools
6.1 6.1.1
Customization artifacts are stored as structured data in the DB2
database and in the WebSphere instance that is installed with
the Tivoli Integrated Portal.
You have export and import tools to manage customizations for
the following purposes:
Incremental customization backups for disaster recovery.
Migration: Move customizations from one environment to another; for
example, a test environment to production.
Upgrades: Upgrade infrastructure components and incorporate
previous customizations.
Migration and upgrade tools
Customizations, including dashboards, pages, and business service configurations, are stored in
the Tivoli Business Service Manager DB2 database. The customizations can be exported and used
to back up a deployment environment or move the customizations to another Tivoli Business
Service Manager installation.
V7.0
Uempty
Business services and service status
Tivoli Business Service Manager provides two major functions:

1. Model business services:
Manually
Automatically
2. Track business service status and key performance indicators:
Monitored events
Business data
Business services and service status
The core functions provided by Tivoli Business Service Manager are as follows:
Modeling of business systems and business system relationships
Tracking the status and key performance indicators of those modeled business systems
You create business service models manually or automatically, based on available business data.
Business services are created to track physical and logical resources and processes. For example,
a service model can represent the health of a web server or the energy consumption in an office
building.

Defining business services with service models
Templates model general business service characteristics.

Services are created from templates.
Defining business services with service models
Business services are tracked with a logical device called a business service model. Tivoli
Business Service Manager service models consist of these configured items:
Templates: Business service model templates define the behavior of a modeled service. The
behavior is configured with one or more rules. Rules define how a template must react to one or
more of the following data inputs:
Monitor events
Business data
Changes in peer or child services
Instances: Instances are created to represent specific services based on one or more
templates.
Hierarchical service models are created with dependency rules in a template. Dependency rules
define a relationship between a higher-level, or parent, template and a lower-level, or child,
template. Status or key performance indicators tracked in parent levels in the model hierarchy are
dependent on values calculated for child services. This design allows the effect of changes in child
service values to be quickly propagated to higher level parent services.
V7.0
Uempty
Service model creation

Two model creation methods are manual and automatic:
Manual
Graphical console
Command line
Automatic
External service dependency adapters (ESDAs)
Data fetchers
Monitor events
Discovery data
Service model creation
Tivoli Business Service Manager provides several methods for managing business service models.
The method that is used depends on the type of data that is available to monitor the business
service and the requirements of the administrator. For example, services that correspond to
frequently changing business processes should be managed with automatic population rules. In a
test environment, manual service creation is quicker than developing complex automation rules.

Service status and key performance indicators

Service
Template
Data Rule Service status
Key performance indicator
Events Rule
Service status or key performance indicators are tracked with

one or more rules that are associated with a service template.
These types of rules are as follows:
Incoming status
Dependency
Numerical formula
Auto population
ESDA Copyright IBM Corporation 2013 19
Service status and key performance indicators
The two types of rules that are most commonly used for tracking a business service status or key
performance indicator are as follows:
Incoming status rules: Incoming status rules evaluate incoming events or business data and
set the status of the affected business service instance. Status rules evaluate a numerical value
or set the status of a child service.
Dependency rules: Dependency rules are configured for a parent service. They evaluate the
aggregated status or a numerical value that is provided by all child business services. They set
the status according to the rule definition. The evaluation sets the service status or calculates a
key performance indicator for a parent service. Numerical formula rules calculate the status or a
key performance indicator for a parent service that is based on a comparison with other parent
services.
V7.0
Uempty
Incoming status rules

Evaluate the status of a business service or calculate a key
performance indicator.
Evaluate monitor events or business data.
Example: Assign a Marginal status to any web server service with a

response time that is greater than 500 milliseconds.
Incoming status rules
Incoming status rules evaluate an incoming event or database query to determine the business
service status or calculate a key performance indicator. In this example, each WebServer service
instance evaluates an event to determine the server response time. The response time is extracted
from a field in a received monitor event. If the response time is greater than 500 milliseconds, set
the service status to Marginal.

Dependency rules
You create hierarchical service models by configuring parent-
child dependency relationships between services.
The relationships are defined with dependency rules.
Example: Calculate the average response time of a web farm with the
response times of all child web server instances.
Dependency rules
You create complex service models by defining one or more relationships between a parent service
and one or more dependent child services. An aggregation of the values that are provided by the
child services is used to set the parent status or KPI. Use dependency rules to create models that
show the business impact of status and KPI changes to child services.
V7.0
Uempty
Numerical formula rules
Determine status or a key performance indicator that is based on

a calculation or comparison with other rules in a template.
Example: Set the status of a web farm that is based on a comparison of

the average monthly response time of all other web farm services.
Numerical formula rules
A numerical formula rule combines the rule output values of different rule types within the same
service instance. For example, a template contains three rules: Region1Total, Region2Total, and
Region3Total. Each rule calculates the number of open trouble tickets for a geographic region of a
company. You use a numerical formula rule to add the value of each rule to determine the total
number of open trouble tickets for the company: CompanyTotal = Region1Total.value +
Region2Total.value + Region3Total.value. A change to the value of Region1Total, Region2Total, or
Region3Total automatically triggers a new calculation for CompanyTotal.

Data fetchers
Use data fetchers to query databases for the following purposes:
Retrieve key performance indicator data
Trigger service status evaluation
Example: Evaluate the number of open trouble tickets for a web server
and set the service status.
WebServer6
Tickets: 2
Data Fetcher
WebServer13
Tickets: 7
Rows
WebFarm3
Ticket
DB WebServer21
Tickets: 0
WebServer15
Tickets: 4
Data fetchers
Data fetchers extend the capabilities of Tivoli Business Service Manager service models. Data
fetchers provide a mechanism to query a database and use the returned data with service model
tracking. This mechanism allows service models that represent business services that are not
monitored, directly or indirectly, with traditional monitoring infrastructures. For example, you create
a service model that represents the efficiency of your customer service organization. The service
model tracks the average customer problem resolution time, which is based on data that is stored in
your customer service database.
V7.0
Uempty
Summary
Now that you have completed this unit, you can perform the
following tasks:
Define business services and business service management
Describe the IBM Tivoli Business Service Manager 6.1.1 capabilities
Describe the primary Tivoli Business Service Manager architectural
components
Describe the tools that are available in Tivoli Business Service
Manager 6.1.1 to create, track, and visualize business services
Summary

2 Service model basics

What this unit is about Templates and rules provide the foundation for the Tivoli
Business Service Manager service model. This unit
explores the relationship between templates, services,
and rules.
How you check your progress You can check your progress in the following ways:
Student exercises
References SC23-6041-09 Tivoli Business Service Manager 6.1.1
Service Configuration Guide

V7.0
Uempty
Objectives
tasks:
Start and stop the major Tivoli Business Service Manager components
Explain how templates and services are used together to build service
models
Create event-based templates and rules
Create dependency templates and rules
Create service instances
Create dependencies between services
Test service models
Objectives

Lesson 1. Starting and stopping Tivoli Business Service Manager components
Lesson 1. Starting and stopping Tivoli Business

Service Manager components
Lesson 1. Starting and stopping Tivoli

Business Service Manager components
What this lesson is about In this lesson, you learn the commands that are used to
start and stop the primary Tivoli Business Service
Manager components.
Start and stop the major Tivoli Business Service Manager
components

V7.0
Uempty
Tivoli Business Service Manager components

Primary Tivoli Business Service Manager components
Tivoli/Netcool ObjectServer
Data server
DB2 database
WebSphere Application Server
Discovery Library Toolkit
Dashboard (Tivoli Integrated Portal) server
WebSphere Application Server
Optional components
Event Integration Facility Probe
Tivoli Monitoring Agent
Tivoli Business Service Manager components
The primary and required Tivoli Business Service Manager components that must be started are as
follows:
Tivoli/Netcool ObjectServer: The event engine that is used by Tivoli Business Service
Manager. The ObjectServer receives monitor events and status events that are generated
during Tivoli Business Service Manager operation. A second ObjectServer can be installed and
configured to provide redundancy.
Tivoli Business Service Manager data server: The analysis engine for Tivoli Business
Service Manager. This Java Platform, Enterprise Edition application is installed on embedded
WebSphere (default) or base WebSphere. The internal processing technology is based on
Tivoli/Netcool Impact. A second data server can be installed and configured to provide
redundancy. Service model status and customization artifacts are stored in an installed DB2
instance.
Tivoli Business Service Manager dashboard server: The visualization and administrative
console for Tivoli Business Service Manager. This Java Platform, Enterprise Edition application
is installed and managed on embedded WebSphere (default) or base WebSphere. The

dashboard service integrates with services provided by the Tivoli Integrated Portal. Multiple
dashboard servers can be installed and configured to provide redundancy and load balancing.
Optional Tivoli Business Service Manager components are as follows:

Discovery Library Toolkit: This tool processes Common Data Model data to create service
instances and service models. The tool is also used with migration tools to interface with the
customization artifacts database stored in DB2.
Event Integration Facility Probe: A Tivoli/Netcool monitor probe that is configured to receive
monitor events and forward them to the ObjectServer. The source of the monitor events that are
received by the probe can be from sources such as Tivoli Monitoring, Tivoli Network Manager,
Tivoli Enterprise Console, and Tivoli OMEGAMON XE. The probe can also be configured to
forward events from monitor sources other than IBM applications.
Tivoli Monitoring Agent: A standard Tivoli Monitoring agent that is designed to monitor Tivoli
Business Service Manager processes and operations. Additionally, the agent can be configured
to forward operational events to a Tivoli Data Warehouse database.
V7.0
Uempty
Starting and stopping the ObjectServer
The ObjectServer can be installed on a separate computer, or

on the same computer as the data server or dashboard server.
You start the ObectServer with the following command:
$OMNIHOME/bin/nco_obj name <Server_Name>
Example: Start the ObjectServer, installed on Linux with default
parameters:
/opt/IBM/tivoli/netcool/omnibus/bin/nco_obj name NCOMS
Starting and stopping the ObjectServer
You start the Tivoli Business Service Manager ObjectServer with the following command:
/opt/IBM/tivoli/netcool/omnibus/bin/nco_obj -name <Server_Name>
The <Server_Name> value is configured during installation. The value is not necessarily the host
name on which the ObjectServer is installed. Because of the necessary interactions with the data
server, the ObjectServer must be installed as close to the data server as possible.

Starting and stopping the data server
DB2 must be available when the data server is started.

The data server must be started with the same user ID that is
used to install the application.
The data server is started in a WebSphere profile.
You start the data server with the following command:
$TIP_HOME/profiles/TBSMProfile/bin/startServer.sh server1
Example: Start a data server on Linux, installed with default parameters:
/opt/IBM/tivoli/tipv2/profiles/TBSMProfile/bin/startServer.sh
server1
Starting and stopping the data server
The data server can be installed on a separate computer, or on the same computer as the
ObjectServer or dashboard server. Database storage for Tivoli Business Service Manager
operations must be provided with a configured DB2 instance. The DB2 instance can be remote to
the data server. To optimize performance, the DB2 instance must be as close as possible to the
data server.
The data server must be started with the same user ID used to install the application. The data
server is installed in your laboratory environment on the tbsm01 virtual image. You start the data
server in the laboratory environment with the following command:
/opt/IBM/tivoli/tipv2/profiles/TBSMProfile/bin/startServer.sh server1
V7.0
Uempty
Starting and stopping the dashboard server
Tivoli Integrated Portal server components are required and

installed with the dashboard server.
The server must be started with the same user ID used to
install the application.
The dashboard server is started as a WebSphere profile.
You start the data server with the following command:
$TIP_HOME/profiles/TIPProfile/bin/startServer.sh server1
Example: Start a dashboard server on Linux, installed with default
parameters:
/opt/IBM/tivoli/tipv2/profiles/TIPProfile/bin/startServer.sh
server1
Starting and stopping the dashboard server
The dashboard server can be started before the data server or ObjectServer, but the dashboard
server has limited service.
Tivoli Integrated Portal server components are required and installed with the dashboard server.
Unless otherwise specified, the term Tivoli Integrated Portal is intended to indicate that the
dashboard server started in the Tivoli Integrated Portal profile.
The dashboard server must be started with the same user ID used to install the application. The
dashboard server is started as a WebSphere profile. The profile is installed on the tbsm01 virtual
image in your laboratory environment. You start the dashboard server in your laboratory
environment with the following command:
/opt/IBM/tivoli/tipv2/profiles/TIPProfile/bin/startServer.sh server1

Tivoli Integrated Portal server console logon
Default web address:

https://<dashboard_host_name>:16311/ibm/console
Tivoli Integrated Portal server console logon
To manually create a business service model, you must first log on to the Tivoli Business Service
Manager console. Console services are provided with the dashboard server installed in the Tivoli
Integrated Portal server.
The default console connection web address is as follows:

https://<dashboard_server_host_name>:16311/ibm/console
The default administrative user ID is tipadmin. The administrative password is set during
installation.
V7.0
Uempty
Tivoli Integrated Portal console elements
Logout link
Console
workspace
Task list, or
Task view
The console has a list of tasks on the left and a console workspace on the
right.
You close the console connection by clicking the Logout link in the upper
right.
Tivoli Integrated Portal console elements
When you log on to the Tivoli Integrated Portal server, the primary console elements that are used
in the first laboratory are highlighted in this image. The elements are as follows:
Task list or task view: This section at the left of the console is a list of folders, pages, or tasks.
Clicking a folder expands to show any contained folders, pages, or tasks. Clicking a page or
task changes the context view in the console workspace.
Console workspace: This section at the right of the console. This view changes based on
pages or tasks that are selected in the task list.
Logout link: Clicking this link disconnects the console connection. The link is in the upper right
of the console.
You learn how to modify these elements in the unit, Custom dashboards and page management
on page 391.

Instructor demonstration
V7.0
Uempty
Student exercises
Student exercises
Perform Exercise 1 for this unit.

Lesson 2. Templates and rules
What this lesson is about In this lesson, you learn how templates are used to define
general characteristics for a business service model. You learn
how template rules are used to respond to monitor events and
business data. You also learn how template dependencies are
used to create multilevel template service models.
Explain how templates and services are used together
to build service models
References SC23-6041-09 Business Service Manager Version 6.1.1

V7.0
Uempty
Service templates
Service
Template
Data Rule Service status
Key performance indicator
Event Rule
Templates define the characteristics of a business service or

process in the following ways:
How a business service responds to incoming events or data
Business service hierarchies with one or more parent-child
relationships
Service status and key performance indicators (KPIs)
Service templates
Templates are the basis for all business service definitions. You create them to model any aspect of
your business infrastructure. Templates also define the parent-child relationships between business
services. Templates define general behavior and characteristics for a business service. The
behavior and characteristics are defined with one or more template rules. The rules respond to
incoming monitor events or database data queries and assign a status value or key performance
indicator (KPI).

Template rules
Template behavior is defined with one or more rules.
Incoming status rules are triggered with monitor events or
database queries.
Multiple-level template models are created with dependency
rules.
Automatic population rules create services with an association
with a status or dependency rule.
Template rules
Template rules define a response to monitor events or a database query. One or more rules are
assigned to a template. If the template contains multiple rules, the rules can be evaluated together
to determine the overall status of the business service. The rules are grouped into the following
three general types:
Incoming status rules: These rules assign a business service status or calculate a KPI with
information that is contained in a Tivoli/Netcool ObjectServer event or a database query.
Dependency rules: These rules establish a parent-child relationship between templates.

Combinations of these relationships build multiple-level service models that propagate the
impact of changes in the status or performance of child services. Dependency rules aggregate
child service status or numerical values.
Automatic population rules: These rules automatically create business services that are
based on configured criteria. They are associated with either incoming status or dependency
rules and are triggered when the associated rule responds to an event or database query.
V7.0
Uempty
Note: A fourth type of rule icon is shown in the console. These rules are known as Internet
Service Monitor (ISM) rules. They are designed to interact with the Internet Service Monitoring
component for IBM Tivoli Composite Application Manager (ITCAM) for Transactions. This feature
is not included in future product releases and is outside the scope of this course.

Service template examples

Templates model business processes and business process
behavior.
Templates can correspond to physical resources or logical
processes within a business.
Physical resources
Web servers
Databases
Logical processes
Web applications
Supply chain performance
Service template examples
Tivoli Business Service Manager provides tools to model most business services or processes.
Creating templates and models that correspond to physical resources can be useful for many
purposes, but logical models provide more sophisticated views of business processes. For
example, a city government recently upgraded the power meters on all homes in the city limits. The
new meters provide numerous metrics that are related to power consumption. Using combinations
of templates and rules, you can create business service models that show a comprehensive view of
device and performance measures, like the following ones:
Real-time average household power consumption
Current total power consumption versus power plant capacity
Projected cost of power, per kilowatt hour, at current rate of consumption
For these examples, no single monitor event provides enough information. The templates include
rules to analyze multiple sources of data, such as the following ones:
Business data that is related to real-time power consumption and cost rates
Analysis of individual monitor events from each power meter
V7.0
Uempty
Template and service relationship
WebServer1
WebServer
Status Rule
WebServer
Status Rule
Response Rule
Response Rule
Open Tickets Rule
Open Tickets Rule
Template
Service instance
Service templates define the characteristics of a modeled

business resource
Service instances correspond to a specific business resource.
A service instance must be assigned with at least one
template.
Template and service relationship
It is important to understand the concepts of, and differences between, a service template and a
service instance. A service template is a general description of the type and properties of some
monitored object. A service instance represents a specific monitored object with the properties
defined in the template. For example, a template might be a description of a bicycle, including
properties like color, frame type, wheel size, and number of gears. A service instance is equivalent
to an actual bicycle: red, 16-inch wheels, 10 speed.

Business service instances
Example
A template is created for each class of server.
Probe events include server class identification information.
The service instances are created with the corresponding template.
One template: class1WebServer: 4 cores, 64 GB memory

Three instances, based on the class1WebServer template:
class1WebServer1
class1WebServer2
class1WebServer3
#1 #2 #3
One template: class2WebServer: 8 cores, 128 GB memory
Three instances, based on the class2WebServer template:
class2WebServer1
class2WebServer2
class2WebServer3
#1 #2 #3
Business service instances
The Tivoli Business Service Manager console provides tools to create service templates for
common business service behavior. You can create one template for a general type of service. You
then use it as the basis for multiple service instances, such as in the following examples:
Identifying service events
You must identify service events with a combination of field values from an event. The fields that
you select must be unique to the service template you want to identify. For example, if database
monitor events come from an Oracle probe, you might define the Manager field as Manager =
nco_p_oracle.
Identifying service status
You must identify the status of a service that is based on a numerical event field. Typically, you
use the Severity field, as in this example:
Severity < 3: Good
Severity > 3: Marginal

Severity = 5: Bad
V7.0
Uempty Identifying service instances
A service instance can be any hardware or software that supports a service template. An
example is something that generates OMNIbus alerts. When you analyze your events, select a
combination of event fields and values. Those field values are used to identify a service
instance. For example:
Node + AlertKey = WebServer18080

Service model hierarchies

WebFarm1
WebFarm 2. WebFarm1 state
Status Rule changes to Marginal
Average Response Rule
1. WebServer1 state Total Open Tickets Rule
changes to Bad
WebServer1 WebServer2
WebServer WebServer
Status Rule Status Rule
Response Rule Response Rule
Open Tickets Rule Open Tickets Rule
Use dependency rules to create multiple-level template models.

Dependency rules
Propagate the effects lower-level service outages on higher-level
services.
Aggregate child service key performance indicators.
Service model hierarchies
When customers connect to the application for online ordering, connectivity requires the availability
of these servers:
A web server in a web farm
A database server
An authentication server
A Domain Name Service (DNS) server
A different service level agreement (SLA) might exist for each of these services. You might set up a
service template that is called WebApplication that monitors events from each service template
that is defined in a hierarchy. By defining the dependencies of each level of the hierarchy, status
changes can quickly propagate. As the status changes propagate, the effects of outages at all
levels are immediately shown.
Each of the service templates in a model represents its own set of supporting hardware and
software. After you determine the supporting hardware and software for a service template, you can
determine the events that affect this service.
V7.0
Uempty
Example: Web application service model
Online Ordering requires web servers,

database servers, web farms, and
database clusters.
Web Application: Online Ordering
Web Farm 1 Dependent Services Database Cluster 1

Web Servers Database Servers
DB1 DB2
WS1 WS2 WS3
Example: Web application service model
In this example, the Online Ordering application is dependent on several services. These services
consist of web farms and Database servers. Each web farm contains several web servers. Each
database server might access multiple databases.
The web servers share information that is stored on the Database servers. The Database servers
can also monitor some internal components, such as processor, hard disk drive, and applications.
Tivoli Business Service Manager can monitor the status of each of these services that support the
Online Ordering application. To ease the creation of services, templates that define the general
properties of a service are created. Service instances can then be created with the templates.

Creating a template
To create a template with the Tivoli Business Service Manager
console, complete the following basic tasks:
1. Log on to the console.
2. Open the Service Configuration page.
3. Open the Template Editor.
4. Configure template behavior by creating one or more rules for the
template.
Creating a template
Use the service editor in the console to create a template and define one or more rules. Template
rules define how the template responds to monitor events or business data.
V7.0
Uempty
The Service Configuration page
Expand the Administration folder in the All tasks view, and click
Service Configuration.
The Service Configuration page
The initial console elements that are shown consist of a page with two windows. The window on the
left is a list of folders or tasks, called a view. The window on the right is a workspace that changes
based on the task that is selected from a view. Templates and services are configured from the
Service Editor portlet, found on the Service Configuration page. You open this page by selecting the
Administration > Service Configuration task in the All tasks view.

Opening the Template Editor
Select Templates in the Service Navigation portlet menu.

From the Templates section, you can delete or create a
template.
Configure templates in the Service Editor portlet.
Opening the Template Editor
Templates are created from the Templates section of the Service Navigation portlet. Click the
Templates menu in the Service Navigation portlet. From this section, you can create, delete, or edit
templates. Access the template form in the Service Editor portlet to the right of the Service
Navigation portlet.
The authorization roles that are assigned to a user control access to the Service Administration
page. Objects within the Tivoli Business Service Manager environment that the user is not
authorized to see or modify are not shown.
V7.0
Uempty
Example: Creating a template
Click the Create New Template icon to open the template form
in the Service Editor pane.
Create one or more incoming status rules.
Example: Creating a template
To create a template for the example web server, use the following steps:
1. Click the Create New Template icon in the Templates section of the Service Navigation portlet.
2. Enter WebServer in the Template Name field.
3. Select an icon for all instances that are based on the WebServer template.
4. Create a status rule. The Rules tab is where all the dependency and status rule information for
this template is stored. The configuration options available for this template are reviewed in
more detail in the section Incoming status rule form overview on page 57. For this example,
create an Incoming Status Rule for WebServer to use event data to set the service status.
5. Click the Incoming Status Rule icon.
Plan a naming convention for templates and services that are used in a production environment.

Example: Status rule threshold criteria

Each web server receives monitor events. The combination of
the AlertGroup field and Severity field values determine the web
server status
IF Severity = 5 AND AlertGroup = WebServerStatus, Service
Status = Bad
Status = Marginal
Status = Good
Example: Status rule threshold criteria
The status of a service can be based on an evaluation of one or more event fields from an
ObjectServer event. An incoming status rule can evaluate to a status of Good, Marginal, or Bad.
Note: The service status can be linked directly to the severity in an ObjectServer event. Any field
or set of fields can be used as a formula for service status.
For this example, the highest severity of each web server status event determines the overall status
of the web server. These tasks must be completed to create this service model:
Create a template for web servers. The template defines how the status of any web server is
determined.
A service instance represents each web server with the WebServer template.
V7.0
Uempty
Creating an incoming status rule

To create an incoming status rule, complete the following tasks:
1. Click the Incoming Status Rule icon.
2. Select one of the following options:
Good, Marginal, and Bad threshold
Numeric rule type
3. Assign a rule name, description, and data feed.
4. Select the input class discriminator.
5. Select the service name filter.
6. Set the service state evaluation fields.
7. Set the service state evaluation criteria.
8. (Optional) Configure the rule for metric collection.
Creating an incoming status rule
The major tasks that are required to create an incoming status rule are described in more detail in
subsequent sections of this unit. Standardizing naming conventions for rule names simplifies
managing large numbers of templates.

Selecting incoming status rule type
1. For this example, select Based on a Good, Marginal, and

Bad Threshold.
2. Click OK.
Selecting incoming status rule type
The incoming status rule evaluates a matching monitor event. The overall service status is set
based on an evaluation of specified event fields.
V7.0
Uempty
Incoming status rule form overview

The incoming status rule
form consists of the following
five primary sections:
1. Rule Name and Data Feed
2. Event discriminators
3. Instance name
4. Filter
5. Threshold filters
Incoming status rule form overview
The incoming status rule form for processing events consists of the four sections that are
highlighted in this image. Each section is described in detail in subsequent pages of this unit. If the
event matches a defined event discriminator, rule processing looks for a matching instance name. If
a matching instance name is found, the rule applies the filter and threshold definitions against the
contents of the event.

Rule Name and Data Feed

Enter a unique name for the rule. In this example, assign the
name WebServerStatusRule to indicate the origin and type.
Select a data source in the Data Feed menu. The default is the
Tivoli/Netcool OMNIbus ObjectServer.
Optionally, include extra information in the Description field.
If left blank, the display name that is created for the template
corresponds to the Rule Name value.
Rule Name and Data Feed
Enter a name for the rule that is both descriptive and unique. Naming standards can help
distinguish the origin and type of the object. For example, the text string StatusRule as a rule prefix
or suffix helps provide context.
If you have multiple data feeds configured, you can select them from this menu. When developing
the rule, clicking the View icon shows all events that match the rule filter definition. The filter
definition is explained later in this section.
V7.0
Uempty
Selecting event discriminators

This section applies only when the data source is the
ObjectServer.
Class(0) is the default discriminator.
The discriminator reduces unnecessary event processing.
If more than one discriminator is selected, the classes are
evaluated as a logical OR against the incoming event class.
Selecting event discriminators
The event discriminator section of the rule definition provides a prefilter of events. If an incoming
event does not match the selected discriminator, no additional processing of the event is done. The
overall load on the Tivoli Business Service Manager server is reduced.
You can select multiple discriminators. They are evaluated as a logical AND. For example, if two
discriminators are selected and either one evaluates as TRUE, rule processing continues.

Matching the service instance name

The fields that are selected in this section are used to identify
the service to which an incoming event should apply.
Services inherit the Instance Name fields through the Service

Identification Field properties.
Service properties example
Matching the service instance name
This section uses the selected fields to determine whether the service exists. Each service name
must be unique. Continuing the example, the rule evaluates the Node field from the incoming
event. The rule then matches the Node value against all defined service names. If a match is
found, rule processing continues.
V7.0
Uempty
Choosing the status evaluation fields

Select and configure the event fields that are used to evaluate
the service status.
Each selected field is added to the Filter Threshold section of
the rule form.
Choosing the status evaluation fields
In the Filter section of the rule, information in the selected filter fields evaluates the overall rule
status. You can select multiple fields. Data from the selected fields populates the Threshold Filter
section.

Setting the threshold filter criteria

The service state is evaluated against a series of threshold
conditions to determine whether the service state is Good,
Marginal, or Bad.
You can add thresholds, if needed, by clicking the New Filter
icon.
Setting the threshold filter criteria
In the final section of the rule definition, the filter field evaluation expressions are created. Because
this example is for a Good, Marginal, and Bad rule, each of the possible states must be accounted
for. This example defines the settings as:
If AlertGroup = WebServerStatus and Severity >= Critical, set the status to Bad.
If AlertGroup = WebServerStatus and Severity >= Minor, set the status to Marginal.
If AlertGroup = WebServerStatus and Severity >= Clear, set the status to Good.
V7.0
Uempty
Metric collection
Tivoli Business Service Manager includes an analysis tool that

is called the Time Window Analyzer.
You can use the Time Window Analyzer to compare
operational values from multiple services on a single time
graph.
Only rules that are selected for metric collection can be used
with the Time Window Analyzer tool.
For this rule example, no metrics are collected.
Metric collection
Operational metric values from rules can be configured for collection. The data is stored up to 14
days. The data can then be used with a tool called the Time Window Analyzer to graphically
compare a rules performance over some time. The performance can also be compared to other
rules that are selected for metric collection. By default, metric collection is not enabled for any rule.

Saving the template
After saving rule definition, click the Save icon to save the
template definition.
Save work frequently while creating templates and rules.
Saving the template
After saving the rule definition, click the Save icon to update the template. If you require more rules,
click one of the rule creation icons and continue.
V7.0
Uempty
Service navigation view after template creation
The template is shown in the Service Navigation portlet template

tree after you save the template definition.
Service navigation view after template creation
After you create new instances or templates, the view in the Services section of the Service
Navigation portlet is automatically updated.

V7.0
Uempty
Student exercises
Student exercises

Lesson 3. Creating template dependencies
Lesson 3. Creating template

dependencies
What this lesson is about In this lesson, you learn how to create aggregation
dependency rules and how to use those rules to create
multilevel service models. Dependency rules are used to
create service models that propagate the business impact
of low-level business service status changes.

Service Configuration Guide Title of Reference
V7.0
Uempty
Creating multiple-level template models

Service models typically contain a related hierarchy of service
instances.
Multiple levels in a template model are created by defining one
or more parent-child relationships
The parent-child relationships are defined with a dependency
rule within a parent template.
The dependency rule types are as follows:
Good, Marginal, Bad aggregation
Numeric aggregation
Numeric formula
Creating multiple-level template models
Service models require the creation of hierarchies to fully define complex business services.
Template hierarchies are created by defining dependency rules for each higher level of a
relationship.
The three types of dependency rules are as follows:

Good, Marginal, Bad Aggregation: These rules aggregate the status of each child service
and, based on the rule definition, assign a parent status.
Numerical Aggregation: These rules aggregate a numerical status from each child service
and, based on the rule definition, assign a parent a numerical status. Additionally, you can
assign an output status (Bad or Marginal) to the parent.
Numerical Formula: These rules use a numerical formula to be defined to evaluate numerical
child values to assign a parent a numerical status. Additionally, you can assign an output status
(Bad or Marginal) to the parent.

Dependency rules overview

Complete the following tasks to create a dependency rule:
1. Edit the template to which you want to add a dependency rule.
2. Select the appropriate dependency rule type.
3. Assign a rule name.
4. Select the child template.
5. Set the output status conditions. These conditions vary, depending
on the rule type.
Dependency rules overview
You create a parent-child relationship in a service model template by first creating the parent and
child templates separately. You create the dependency rule at the parent level, assigning the child
template in the rule definition. Subsequent pages in this unit provide more detail on each of the
major tasks in creating a dependency rule.
V7.0
Uempty
Creating dependency rules

Select one of the three dependency rules in the template
definition toolbar in the parent template.
Good, Bad, Marginal Aggregation Numerical Aggregation Numerical Formula
Creating dependency rules
Continuing the example, review the steps to create a template. Dependent templates rely on the
status of one or more subordinate templates.
Instead of populating the new template status that is based on an event rule, a dependent template
is based on some dependency, such as another template. For this example, the WebFarm template
evaluates the status of one or more web servers. To create this dependent template, use the
following steps:
1. Create a template and name it WebFarm. Select a different icon for this web farm.
2. Create a rule by clicking the Create Good, Bad, Marginal Aggregation Rule icon.

Creating a good, marginal, and bad aggregation

dependency rule
Assign a rule name

Set the parent-child
relationship with the
Child Rule/Mapping
menu
Set threshold
conditions
Optionally, configure
the template for
metric collection
Creating a good, marginal, and bad aggregation dependency rule
A dependency rule is created based on two kinds of conditions: percentage of child status and
worst case of any child.
A percentage of child status condition calculates the percentage of children in any state (Good,
Bad, or Marginal). The status of the parent is calculated, based on the selected rule. For example,
in this image, if fewer than 30% of the child services are Bad, then the parent status is Good. If
between 30% and 70% child services are Bad, then a Marginal state is assigned to the parent. If
over 70% of the child services are Bad, then the parent state is Bad.
Notice the way that this rule is defined. Only child events with a status of Bad are considered. To
consider Marginal child events, create another dependent rule to deal with this case.
The worst case of any child option propagates the worst status of any child to the parent.
V7.0
Uempty
Saving the template
Add dependency rules to parent services to increase the

template levels.
The icon in the Type column indicates that the rule is a
dependency rule.
Save the template after saving the dependency rule.
Saving the template
After you add the rule, it is listed in the lower section of the page. You can add multiple rules to the
list. Multiple rules indicate, in the case of dependency rules, that the status of a parent is dependent
on multiple types of child services. Save the template after completing the rule definition.

Viewing the template hierarchy
The WebServer template is shown as a child to the WebFarm

template.
Either template can be used with other service models, at a
child or parent level.
Viewing the template hierarchy
Notice that the Service Navigation tree shows a structure of dependent templates. You can expand
or collapse trees by clicking the plus (+) and minus () symbols at the beginning of any branch of
the template tree.
V7.0
Uempty

Student exercises
Student exercises
V7.0
Lesson 4. Creating and testing service instances
Uempty
Lesson 4. Creating and testing service

instances
Lesson 4. Creating and testing service

instances
What this lesson is about In this lesson, you learn how to create service instances
and how to apply templates to those services. You learn
how to test the template rules with simulated monitor
events. You also learn how to modify service properties to
change the order in which a service is shown in the
service tree.

Test service models

V7.0
Uempty
Creating service instances

Service instances use one or more templates to define service
behavior.
You have a choice of several ways to create business service
instances
Configure them manually in the GUI.
Use automatic population rules to automatically create instances with
monitor events or data from a database query.
Use the RAD Shell API.
Use Data Library Adapter IDML books and the Discovery Library
Toolkit.
Use a link to Tivoli Application Dependency Discovery Manager to
build service models that are based on discovered configuration items
(CIs).
After you define a template model, you can use several of the following tools to create business
services:
Event-based automatic population rules create instances while matching events are received in
the ObjectServer.
A command-line API tool can be used in scripts, based on file or other input.
Data fetcher or External Service Dependency Adapter (ESDA) rules can automatically build
service instances with external data.
Discovery data can be used with the Discovery Library Toolkit to define business service
models.


Complete the following tasks to manually create a service
instance:
1. Starting at the lowest level of the service model hierarchy, define the
business service instances by assigning a unique name and
appropriate template.
2. For each of the higher levels of the hierarchy, add appropriate
templates and dependent services.
3. (Optional) Set the order in which the services are shown in the
Service Viewer tree.
The previous lesson showed how to model business service behavior with templates. The next step
is to create the business service instances.
For the following example, the business services are defined with the Tivoli Business Service
Manager console. The major tasks of creating a service instance are described in more detail later
in this section.
V7.0
Uempty
Example: Creating a WebServer service
Select the Create New

Service icon from the
Services section of the
Service Navigation
pane.
Example: Creating a WebServer instance
The Services section in the Service Navigation portlet shows all the instances that are currently
defined in your environment. Click the Create New Service icon to create a service instance. You
configure the service in the Service Editor portlet.

Assigning a template
In the Templates section of the Service Editor, select a template to

define the service instance behavior.
Assigning a template
1. Enter a unique value in the Service Name field.

The defined name matches the value that from an actual event as defined in the service
template. For example, in a WebServer template, the Node field was set as the Service
Naming field. Creating a service instance that is called WebServer1 indicates that you expect
events for this service to be received with the Node field set to WebServer1.
2. Enter a description of the instance in the Description field.
3. Accept the default setting for Service Level, which is described in a later section.
4. For this example, leave the Display Name field blank. You can use it to show a more
descriptive or shorter name in a service tree or service viewer portlet.
5. Accept the default setting for Maintenance Schedule, which is described in a later section.
6. Under Templates, select which template to use for this instance. In this case, select
WebServer.
V7.0
Uempty
Adding dependent services to a parent service

Add one or more dependent services.
The dependent services are defined at each level below the top
of the service model hierarchy.
Adding dependent services to a parent service
To add dependent services to a parent service, use the following steps:

1. Create a parent service instance for WebFarm1. A web farm service uses only the WebFarm
template.
2. Click the Dependents tab and select the appropriate dependent WebServer instances.
3. From the Available Services list, select one or more dependent services. Save the service
definition.

Setting the service tree list order
By default, services are shown in alphanumeric order.

Modify the list order with the Order parameter.
Order affects only peer services. Dependent services are not
moved from the parent.
Setting the service tree list order
By default, the order in which the services are shown within the Service Navigation tree is based on
the alphanumeric value of the service name. You can override this order by entering values in the
Order parameter, found on the Additional tab of the service definition form.
V7.0
Uempty
Service models in the Service Viewer portlet
WebFarm1
WebServer1 and Service, which
WebServer4 is based on
Services, which WebFarm
are based on Template
WebServer
Template
Service models in the Service Viewer portlet
This example shows the service model hierarchy, as seen in the Service Viewer portlet.

Sending test events

Test status rules by sending test
events.
Right-click the service and select
Show > Send Test Event.
Only event fields that are defined in
the incoming status rule can be set
with this tool.
A unique Identifier field value is
generated each time that the tool is
used.
Sending test events
After creating the service instance, you can send test events to verify the service operation before it
actually receives monitor events. To send test events, start the Send Test Event tool.
1. Right-click a service instance, and click Show > Send Test Event. Send Test Event shows the
fields available for modification. The fields that are shown are based on the incoming status rule
that is defined for the instance. If no status rule is defined for the service, this menu option is not
available.
2. Keep the default values or modify them.

3. Click OK and the event is sent to the ObjectServer.
You can also use the script $TBSM_HOME/bin/rad_sendevent to enter an event. Be careful to
enter all values correctly to trigger events. This tool is case-sensitive.
Note: If you use the console to send a test event and an error is returned, enter this command:
$TBSM_HOME/bin/rad_discover_schema ObjectServer
V7.0
Uempty

Student exercise service hierarchies diagram
InetBanking AlliedSteel
WebFarm1 WebFarm2 DBCluster1 DBCluster2
WebServer1 WebServer4 WebServer2 WebServer3 Database1 Database2 Database3
WebServer5
Student exercise service hierarchies diagram
This diagram shows the service models that you create in Exercise 4.
V7.0
Uempty
Student exercises
Student exercises

.
Summary
following tasks:
Start and stop the major Tivoli Business Service Manager components
Explain how templates and services are used together to build service
models
Test service models
Summary
3 Expanding service model functions
Expanding service model functions
All files and material for this course (TM337, Tivoli Business Service Manager 6.1.1 for Administrators)
are IBM copyright property covered by the following copyright notice. Copyright IBM Corporation 2013
US Government Users Restricted Rights: Use, duplication or disclosure restricted by GSA ADP Schedule Contract with IBM Corp.

What this unit is about Business services can receive probe events from several
sources. The template rules must respond correctly to the
additional information. Templates can include multiple
rules, and you must decide how to assess the overall
service status when each rule evaluates to a different
status. Also, template rules provide an important tool for
calculating key performance indicators (KPIs) of business
operations. KPIs are then available for visual
representations of business services. In this unit, you
learn methods of extending service templates to provide
comprehensive representations of business services.
Student exercises
References SC23-6041-09 Business Service Manager 6.1.1 Service
Configuration Guide
Objectives
tasks:
Modify an incoming status rule to use multiple probe event fields to
identify a business service.
Create and modify business service identification fields to manage
different event formats.
Use output expressions to evaluate multiple rules in a template
Use the service heartbeat function to provide additional service
tracking
Create template rules to calculate numerical values to use as key
performance indicators (KPIs)
Show KPIs in the Service Navigation portlet
Aggregate child service KPIs with dependency rules
Calculate a weighted average with dependency rules
Objectives
V7.0
Lesson 1. Identifying services with multiple event fields
Uempty
Lesson 1. Identifying services with multiple

event fields
Identifying services with multiple

event fields
What this lesson is about Service templates use one or more rules to model
business service behavior. Template rules can respond to
business and monitor data from various sources. In this
lesson, you learn how to expand the capabilities of a
template rule so that the rule correctly identifies the
service instance to which an incoming event should be
applied.

Modify an incoming status rule to use multiple probe
event fields to identify a business service.

Configuration Guide
V7.0
Uempty
Expanding service name identification

What happens when the Node field is insufficient to identify the
service?
Example:
New company policy requires that test and quality assurance (QA)
web server instances reside on the same physical host.
All test server instances were initially created with the host name
(Node field) corresponding to the service name.
Each instance uses a different server listening port.
Node=WebServer1, Alertkey=80 Port 80
Host name = WebServer1
Node=WebServer1, Alertkey=8080 Port 8080
Expanding service name identification
In the exercises in Service model basics, the service names corresponded to the short host name,
or Node field, of the incoming event. In this example, you deploy a second web server instance on
the host name WebServer1. The first instance uses the listening port 80, and the second instance
uses 8080. The initial business service instance that is created is called WebServer1. A second
service instance, called WebServer18080, is created to track the business status. Because monitor
probes report the same Node value for each web server instance, each event is applied to each
service instance. You must modify the WebServerStatusRule rule configuration to ensure that the
events are applied to the correct service instance. The probe events also include the listening port
value for the web server instance. Adding this event field to the instance name match in the rule
solves the problem.

Example: WebServerStatusRule operation

Example:
Node = WebServer1, Service name = WebServer1
Node = WebServer1, Service name = WebServer18080
Different monitor events incorrectly match both services.
WebServer1
Status=Good
Node=WebServer1, Alertkey=8080,Severity=0
WebServer18080
Event 1 Status=Good
WebServer1
Status=Bad
Node=WebServer1, Alertkey=80,Severity=5
WebServer18080
Event 2 Status=Bad
Example: WebServerStatusRule operation
This diagram illustrates an example of the limitations of matching the service name with only the
Node field from the incoming event. Events for either web server instance match the Node field for
the incoming event, causing the service status to be identically set for both service instances.
Adding the AlertKey field to the rule evaluation provides a mechanism to correctly identify the
service instance.
V7.0
Uempty
Modifying WebServerStatusRule
Modify the WebServerStatusRule:
Use the Node and AlertKey fields to
match service names.
Add AlertKey to the Selected
Instance Name Fields column.
Saved changes are immediately
propagated to the tagged services.
Modifying WebServerStatusRule
Modify the WebServerStatusRule rule, adding the AlertKey field in the Instance Name section.
When the rule modification is saved, every service instance that is based on the WebServer
template immediately inherits the modifications.

Service identification fields

Set the matching properties for the
service in the Identification Fields
section.
By default, the new field is set to
the service name.
Edit existing WebServer service
properties to match AlertKey = 80.
Service identification fields
When the rule is modified, the additional instance name field information is tracked for each tagged
service instance. The new field is modified for each service instance in the Identification Fields
tab in the Service Editor. By default, both fields are populated with the instance name. Modify the
AlertKey field to match the default web server communication port.
V7.0
Uempty
Creating a second WebServer1 service

Example:
A second web server instance on the WebServer1 host uses the 8080
listening port.
Create a service named WebServer18080.
Use the WebServer template.
Port 80 Service name = WebServer1
Host name = WebServer1
Port 8080 Service name = WebServer18080
Example: Creating a second WebServer1 service
To support a new project, you installed a test web server. To stage the project deployment, the
Quality Assurance team uses a web server that is installed on the same computer. Probes are
deployed for both installations. The Node field reported for both instances is the same. The
listening port is the only element that differentiates the two web server installations. The web
servers are tracked as two separate service instances. However, you must visually differentiate
them in Service Tree and Service Viewer portlets.
Adding the AlertKey field to the WebServerStatusRule rule solves the problem is sufficient to
differentiate the server instances. To visually differentiate the two instances, explicitly set the
Display Name. In this example, the WebServer1 service definition was modified to set the Display
Name to the string WebServer1:80. The second instance was created with the Service Name set
to WebServer18080 and the Display Name set to WebServer1:8080.

Configuring the service display name
By default, the service name is used in the service tree or

service viewer portlets.
Use the display name service property to override the default
value.
Example:
Use WebServer1:8080 for the WebServer18080 service.
Configuring the service display name
The monitor events for both services use the same Node value. Edit the Identification Field
values for each service instance to match the different AlertKey values, as shown in the following
table.
Instance name Identification field Value

WebServer1 AlertKey 80
Node WebServer1
WebServer18080 AlertKey 8080

Node WebServer1
V7.0
Uempty
Viewing the WebServer1 service instances

Two services have been created. Both are associated with
WebServer1, but they represent separate web server
installations.
Event Details:
Identifier=abc123
AlertKey=8080
Node=WebServer1
Severity=5
AlertGroup=WebServerStatus
10
Viewing the WebServer1 service instances
This slide shows the services with the modified display name value. The WebServer1:8080 service
tree entry indicates an event was received with AlertKey=8080 and Node=WebServer1 values.
The Identification Field definitions ensure that the event is applied to the correct service instance.

V7.0
Uempty
Student exercises
Student exercises

Lesson 2. Adding service identification fields to match events
Lesson 2. Adding service identification fields to

match events
Adding service identification fields to

match events
What this lesson is about Events do not always use consistent formats for event
field values. For example, if a probe cannot connect with
a DNS server, the monitored host field is reported as the
IP address. In this exercise, you learn how to modify the
service identification properties to match multiple event
field values.
Create and modify business service identification fields to
manage different event formats.
V7.0
Uempty
Configuration Guide

Example: Node value mismatch

What happens when the Node and Alertkey fields are valid but
do not match the service name?
Example:
A probe sends an event with Node = host name = service namethat
sets the service state to Good.
The probe sends a second event with Node = IP address, not the host
name.
A second probe event does not trigger a service state change to Bad.
WebServer4
Node=WebServer4, Alertkey=80,Severity=0 Status=Good
Event 1
Rule not triggered,
Node=192.168.1.1, Alertkey=80,Severity=5 Status remains
Good
Event 2
Example: Node value mismatch
This lesson shows how you can configure the template rule to accommodate variations in the Node
value that is delivered in the monitor event. Both the host name and IP address must match the
server instance. You can solve this situation by adding a second set of identification fields.
V7.0
Uempty
Multiple service identification fields
Services can contain multiple sets of identification fields.

Modify identification fields to accommodate differences in
probe events.
Modify the service instance properties, not template properties.
Multiple service identification fields
Add a second set of identification fields by modifying the service configuration. Because of the
configuration of the WebServerStatus rule, adding another identification rule entry involves
specifying both the AlertKey and Node field values. In this example, the AlertKey entry is the
same for both events. Configure the second entry with the IP address of the service host.

Adding service identification fields

Example:
Edit the WebServer4 service properties.
Add a second set of identification fields
Node=192.168.1.1
AlertKey=80
Send test events to verify.
WebServer4
Node=WebServer4, Alertkey=80,Severity=0 Status=Good
Event 1
WebServer4
Node=192.168.1.1, Alertkey=80,Severity=5 Status=Bad
Event 2
Adding service identification fields
In this example, you add a second service identification field that matches a Node value of
192.168.1.1 and an AlertKey value of 80. When the ObjectServer receives Event 1, the status of
WebServer4 is set to a Good state. When Event 2 is received, the WebServer4 state is correctly set
to a Bad state.
V7.0
Uempty
The instructor has the option to demonstrate the creation and use of service identification fields.

Student exercises
Student exercises
V7.0
Lesson 3. Using output expressions to evaluate template rules
Uempty
Lesson 3. Using output expressions to evaluate

template rules
Using output expressions to evaluate

template rules
What this lesson is about When templates contain multiple rules, you need a
method for evaluating all of the rules to determine the
overall service status. By default, the worst rule
evaluation determines the overall service state. In this
lesson, you learn how to create output expressions to
override the default state evaluation.
perform the following task:
Use output expressions to evaluate multiple rules in a
template


V7.0
Uempty
Default template rule evaluation

By default, a template containing multiple rules uses the worst
rule status evaluation to set the overall service status.
Modeling a business service can require all rules to be
evaluated together.
How do you override the default behavior?
InetBanking InetBanking
Rule 1 = Marginal Rule 1 = Marginal
Rule 2 = Marginal Rule 2 = Marginal
Overall Status = Marginal Overall Status = Bad
Default evaluation Required evaluation
Default template rule evaluation
By default, the rules in the list are evaluated independently. You can override the behavior by
creating an output expression in the template. For this example, edit the WebApplication template
to create an output expression to evaluate the combined state of the
WebApplicationStatusDBClusterRule and WebApplicationStatusWebFarmRule rules.
For any monitored service, you must consider several factors to determine the overall performance
status. Creating more incoming status rules provide a more accurate service assessment.
However, you must evaluate the evaluated status of both rules together to determine the overall
service status. You use output expressions to logically evaluate multiple rules in the same template.

Example: Multiple rule evaluation requirements
Rule 1 Status Rule 2 Status Overall

Service
Status
Bad + Bad = Bad
Marginal + Marginal = Bad
By default, if either rule evaluates to a Bad status, the overall

service status is set to Bad.
For this example, if both rules evaluate to a Marginal or Bad
status, set the overall service status to Bad.
Define an output expression.
Example: Multiple rule evaluation requirements
In the previous example, a single rule was created because the monitor events contained enough
information. In this example, the template has multiple rules that are defined for multiple monitor
sources. The example template contains two rules, each of which can evaluate to a Good,
Marginal, or Bad status. The diagram shows the required logical outcome, depending on each
possible rule state.
V7.0
Uempty
Editing the template properties

Output expressions are configured in the template that contains
the multiple rules.
Click the Output Expressions tab in the template editor.
22
Editing the template properties
Output expressions are configured in the Output Expressions section of the template properties.
The expressions are applied only to rules in the template.

Building output expressions

Select the rule name.
Select Value or LastStateChange for rule status evaluation.

Select the operator (=, >=, <=, <, >).
Select the rule status value.
Select the logical operator to combine with other clauses.
23
Building output expressions
To build an output expression, you click the Output Expressions tab in the Service Editor portlet.
You can enter the SQL logic directly, or you can build the statement with the expression builder
tools. You must define the logic for evaluating the rules as Bad and Marginal. The down arrow icon
is used to insert the text to the left of the arrow. Using the icon to insert the selected value reduces
typographical errors.
V7.0
Uempty
Final output expression

Define the logic for Bad and Marginal states.
For this example, the Marginal Output Expression is set to
False.
The rules never evaluate to Marginal.
Final output expression
Setting the Bad or Marginal output expression to False prevents any output expression evaluation
for the corresponding service state.
For this example, the complete Bad output expression is:

(WebApplicationStatusDBClusterRule.Value = Bad AND
WebApplicationStatusWebFarmRule.Value = Marginal) OR
(WebApplicationStatusDBClusterRule.Value = Marginal AND
WebApplicationStatusWebFarmRule.Value = Bad)

Output expression evaluation results
Output expression evaluation results
This slide shows the output expression logic. By default, a WebFarm1 and DBCluster1 status of
Marginal evaluates as Marginal for the InetBanking service.
V7.0
Uempty
Service heartbeat overview

Lost connections between probes and the ObjectServer can
result in an incorrect service status.
Configure the service heartbeat function for critical services.
If no events are received after a specified period of time, the service
state changes to Unknown (severity 1).
WebServer1 WebServer1
Probe Status = Good
Down Event
Communication WebServer1
link down Status = Unknown
Service heartbeat overview
If a problem event is not received for a service instance, the assumption is that the service state is
unchanged since the last received event. But there might be situations where, for example, a server
and network are simultaneously out of service. If the last known state for the server was Good, the
service instance status remains set to Good. This example is an unusual occurrence for a fully
deployed monitor environment. However, if the critical nature of a service requires continuous
positive confirmation of availability, you can configure a service with Service Heartbeat.
In the service definition, you define a time interval within which events are always sent, regardless
of status. The service heartbeat indicates how often the service must receive a monitor status
event. If the heartbeat interval is exceeded, the service status color changes to purple, and the
service state is set to Unknown.

Configuring the service heartbeat
Modify the template properties.

Set in the Output Expressions section:
Enable the heartbeat function
Configure the time period
When enabled, heartbeat is used by all tagged services.
Configuring the service heartbeat
Configure the service heartbeat for a template by selecting the Report Unknown Severity if No
Events after the following number of seconds check box. Assign a value, in seconds, for the
heartbeat interval and save the template.
Hint: Every service instance that is based on a specific template inherits all template changes.
Set this option only if you must have every related service instance use the configured heartbeat.
Otherwise, create a duplicate template and assign the second template only to those service
instances that require heartbeat monitoring.
V7.0
Uempty
Service heartbeat results

WebServer4 and
WebServer18080 are in
an Unknown state.
A severity 1 event is
internally generated
and assigned to the
associated services.
The parent service
states do not change.
28
Service heartbeat results
This screen image shows the effect of assigning the service heartbeat function to the WebServer
template. After the heartbeat threshold duration is reached, any service in a Good state changes to
an Unknown state.

V7.0
Uempty
Student exercises
Student exercises

Lesson 4. Numerical rules and key performance indicators
Lesson 4. Numerical rules and key performance

indicators
Numerical rules and key performance

indicators
What this lesson is about In this lesson, you learn how to create numerical template rules
to track key performance indicators from incoming data. Key
performance indicators provide an additional tool in developing
service models that reflect many types of business services.
You also learn how to show the output from numerical template
rules in the service navigation tree.
V7.0
Uempty
Create template rules to calculate numerical values to
use as key performance indicators (KPIs)
Show key performance indicators (KPIs) in the Service
Navigation portlet
References IBM Tivoli Business Service Manager Version 6.1.1


Numerical modeling
In addition to service event status, performance measurements
can also be associated with a service.
Numerical calculations can be used as metrics in determining a
service status.
Calculated metrics can also be used as a key performance
indicator (KPI) in a business dashboard.
Example:
Calculate the response time for a web server service model with a
monitor event field value.
Numerical modeling
Tivoli Business Service Manager can evaluate any of the properties that are available to a service.
Key performance indicator values of a service can be shown in business dashboards.
V7.0
Uempty
Showing key performance indicators
KPIs can be viewed with service status and SLA data.
Showing key performance indicators
This screen capture displays the average response time for monitored web servers. This response
time is shown in a separate column in the Services section of the Service Navigation portlet. Key
performance indicators are another way to show business service data, in addition to the event
status.

Creating a numerical incoming status rule

Edit the template.
Click the Incoming Status Rule icon.
Select Based on a Numeric Value.
34
Creating a numerical incoming status rule
You create numerical rules by clicking the Create Incoming Status Rule icon in the template
editor. Then, you select Based on a Numerical Value for the rule type.
V7.0
Uempty
Setting a numerical rule filter

Trigger the rule when AlertGroup = WebServerResponseTime
Setting a numerical rule filter
The rule is configured similarly to the event-based incoming status rule. For this example, use the
AlertGroup field for the filter value. This rule evaluates events where AlertGroup =
WebServerResponseTime.

Assigning the numerical rule output value
Use the data from the ITMTime event field as the numerical
value.
Optionally, set a numerical threshold value for assigning
Marginal and Bad status. If the threshold is matched or
exceeded, the appropriate status is set.
36
Assigning the numerical rule output value
In this example, the value in the ITMTime field is a measurement of response time that is provided
by a monitor. You configure how the rule evaluates the numerical value. An expression is useful for
formatting or typecasting numbers to be displayed. For example, to cast a floating point field value
to an integer, use this expression:
int(fieldname)
To show this value as a floating-point number with three significant digits, use this expression:
float(int(fieldname)*1000/1000)
You can build more complex expressions with multiple fields from the ObjectServer by selecting the
Advanced Filter option. Optionally, you can assign values for the Status section. In this example,
the value of the ITMTime field is tested against a Marginal threshold of 10 and a Bad threshold of
20. If a threshold is exceeded, the overall rule status is set to the corresponding status.
V7.0
Uempty
Customizing a tree template to show KPIs
You can show numerical rule values in a column on the Service

Navigation tree.
You configure column placement with the Tree Template Editor
in the Tivoli Integrated Portal console.
Start the Tree Template Editor in the Services section of the
Service Navigation portlet.
37
Customizing a tree template to show KPIs
The Service Tree portlet can display any calculated value from a numerical rule as a column. To
change the columns that are displayed in the dashboard, modify the dashboard definition with the
Tree Template editor. The Tree Template editor icon is accessed from the Services section of the
Service Navigation portlet.

Tree template editor
You can create multiple tree definitions to provide multiple

service tree views.
The default service tree view is called ServiceInstance.
Tree template editor
You can create multiple custom service trees and apply them to modify service tree views. The
default tree template that is used in Service Availability and Service Configuration pages is labeled
ServiceInstance.
V7.0
Uempty
Adding a column
Click the Add new Tree Column icon to add columns to the
service tree.
Enter a column name.
Change the column order with the arrow icons.
39
Adding a column
To add a column to the service tree, use the following steps:

1. Click the Add new Tree Column icon.
2. Enter the column name in the empty field.
3. Optional: Use the arrow icons next to each column definition to change the order in which the
columns are shown.

Assigning a value to a column
1. Select a template.
2. Select the template in the

Active Templates list.
3. Select the template rule
that calculates the
numerical value.
4. Select the column from
the Column Display
Name menu.
Assigning a value to a column
To assign a measurement to the new column, you must associate a template with the new column.
For this example, select the WebServer template. When selected, only services with the
WebServer template show a response time value.
Use the following steps:

1. After making the template available for selection in the Active Template list, select WebServer
to configure the value to be used.
2. To use the WebServerResponseTime attribute, select the check box.
3. Show this measurement by selecting the Response Time column from the Column Display
Name menu. Response Time is the column that is created in the previous step.
4. Click OK to save the changes.
V7.0
Uempty
Testing the numerical rule

The response time shown for each WebServer instance
corresponds to the ITMTime field value supplied by the monitor
event.
41
Testing the numerical rule
To test the numerical rule, you send a test event to a service that is based on the WebServer
template. The Response Time column is updated with the supplied event value.

Reprocessing events
By default, events are processed:
When received by the ObjectServer
When the severity changes for an existing ObjectServer event.
The severity of the last received event for a service is stored in
RAD_RawInputLastValue.
If a probe event does not include a Severity value, you must
create a mechanism to trigger a reevaluation of an existing
event.
Reprocessing events
If you want the ObjectServer to process an event that is already processed, change the severity of
the event.
For example, after you send events to populate the response time for services with
Node=WebServer1, run the nco_sql commands on the ObjectServer:
update alerts.status set ITMTime=99 where Node=WebServer1;
go
update alerts.status set RAD_RawInputLastValue=6 where Node=WebServer1;
go
This change forces events to be reprocessed if they come in with a response time set in the
ITMTime field.
V7.0
Uempty

Student exercises
Student exercises
V7.0
Lesson 5. Aggregating numerical rules
Uempty
Aggregating numerical rules
What this lesson is about In this lesson, you learn how to use numerical
aggregation rules to use a child service KPI to calculate a
parent service KPI. You also learn how to show numerical
values for a parent service in a service navigation tree.
Aggregate child service KPIs with dependency rules.


Aggregation dependency rules

You can use numerical aggregation rules to calculate parent
KPIs, based on child service numerical rules.
Select one of a list of predefined aggregation calculations:
Average
Maximum, minimum
Percentile
Sum
Create customized calculations with a Tivoli/Netcool Impact
policy.
Optionally, use the aggregation calculation to set the parent
status to Good, Marginal, or Bad.
Aggregation dependency rules
In previous exercises, you created aggregation rules for dependent services that are based on child
service status. You can create the same type of aggregation rules with numerical calculations for a
service.
V7.0
Uempty
Showing aggregated numerical values

Show the average
response time for
each WebFarm
service.
Use the response
time of each
WebServer child
service for the
calculation.
47
Showing aggregated numerical values
In this slide, the WebFarm1 and WebFarm2 services show numerical values that are based on the
dependent services. The average response time for all dependent WebServer instances is
calculated and shown next to the WebFarm service. This value was obtained by adding a rule to the
WebFarm template and displaying the numerical value of the rule calculation.

Creating a numerical aggregation rule

Edit the parent
template.
Click the Create
Numerical
Aggregation Rule
icon.
Select the child
template and child rule
used with the
calculation.
Select the numerical
function.
Creating a numerical aggregation rule
In this example, you create a new numerical aggregation rule called

AverageResponseTimeMetricRule. You start the rule creation by clicking the Create Numerical
Aggregation Rule icon. This rule calculates the average of all the WebServer child services for the
parent WebFarm service. After the numerical rule is created, you can add it to the Service
Navigation tree with the Tree Template Editor.
V7.0
Uempty
Adding aggregation KPIs to a service tree
Open the Tree Template Editor.

Add the parent template to the Active Template list.
Assign the aggregation rule to the service tree column.
Adding an aggregation metric to the tree template definition
To add the new numerical aggregation measurement that is created in the WebFarm template to
the service tree, complete these steps with the Tree Template Editor:
1. Select and add the WebFarm template as a selected template.
2. Select the WebFarm template as the active template.

3. Select the @AverageResponseTimeMetricRule rule to show the calculated average in the
Response Time column.

Viewing aggregation KPIs in the service tree
The WebFarm status is set by the WebFarmStatusRule.
Viewing the aggregation rule metric on the service tree
This example shows the Services tree after modifications with the Tree Template Editor. Refresh
the Services view to apply the changes to the service tree.
V7.0
Uempty

Student exercises
Student exercises
V7.0
Lesson 6. Calculating weighted averages
Uempty
Calculating weighted averages
What this lesson is about The performance effect of some child services do not
always have an equal effect on a parent service. For
example, a web farm might include a web server that
processes three times the transaction load of the other
web servers. To calculate the aggregation effect of the
different child service capacity, you create a weighted
average. This lesson shows you how to create a weighted
average for a numerical aggregation rule.
Calculate a weighted average with a dependency rule


V7.0
Uempty
Aggregation averages and multiplier expressions

Modify aggregation averages with multiplier expressions.
A multiplier expression is a variable that is applied when
calculating an average.
Example:
Two WebFarm services, WebFarm1 and WebFarm2
WebFarm1 processes 3x the transactions of WebFarm2.
Calculate and track the relative performance of all WebFarms.
KPI: Weighted average response time for all WebFarms
WebFarm1 WebFarm2
3000 Transactions/hour 1000 Transactions/hour
Using weighted averages in aggregation rules
You can modify the average function with a multiplier expression in a template. Services inherit a
default value from the template. The default value is modified in the service properties and used in
the numerical aggregation rule definition. For this example, WebFarm1 supports three times the
work load of WebFarm2. The response time value that is provided by WebFarm1 must carry three
times the weight of the WebFarm2 average response time.

Creating a multiplier expression
Create the multiplier expression in the Additional section of the

template definition.
Set the default value in the template.
Override the default value in the Additional section of the
service definition.
Creating a template parameter
You can use a multiplier expression to weight the calculations that are provided by the child service
rules. Because the weighting factor applies to each WebFarm instance, a parameter is created in
the WebFarm template. Under the Additional tab in the template editor, click the New Parameter
icon. Create the parameter name and assign a default value of 1.
V7.0
Uempty
Modifying the default multiplier expression
Edit the service properties.

Click the Additional tab.
Change the default value
inherited from the
template.
Save the changes.
Using a multiplier expression with a numerical aggregation calculation
For this example, create a template that is called AllWebFarms. This template contains a
numerical aggregation rule, with WebFarm as the child template and the
AverageResponseTimeMetricRule as the child service rule that provides the numerical
calculation value. Select Average for the Aggregation Function and enter the name of the
multiplier expression, WeightParameter. Save the rule and the template.

Creating a weighted average aggregation rule
Use the WebFarm average response time rule as the

aggregated child metric.
Enter the name of the multiplier expression next to Average.
Modifying service parameters
Based on the WeightParameter definition in the WebFarm template, each WebFarm service
instance initially has the value of 1. To override this default value, edit the service definition. For this
example, change the WeightParameter value for WebFarm1, found under the Additional tab, to 3.
The number three represents the additional work that is provided by WebFarm1.
V7.0
Uempty
Showing the weighted average calculation
Create an AllWebFarmServices service

Assign WebFarm1 and WebFarm2 as dependents
Show the weighted average in the Response Time column.
A standard average would be 19.666.
Viewing the effect of a weighted average calculation
To view the effect of a weighted average calculation, you create a service instance that is based on
the AllWebFarms template, called AllWebFarmServices, using WebFarm1 and WebFarm2 as
child services. After you add the weighted average value to the Response Time column, the value
is closer to the WebFarm1 response time than the unweighted average of 19.666. This value
shows that the response time value for WebFarm1 has a greater effect on the overall evaluated
response time for both WebFarm instances.

V7.0
Uempty
Student exercises
Student exercises

Summary
following tasks:
Modify an incoming status rule to use multiple probe event fields to
identify a business service.
Create and modify business service identification fields to manage
different event formats.
Use output expressions to evaluate multiple rules in a template
Use the service heartbeat function to provide additional service
tracking
Create template rules to calculate numerical values to use as key
performance indicators (KPIs)
Show KPIs in the Service Navigation portlet
Aggregate child service KPIs with dependency rules
Calculate a weighted average with dependency rules
Summary
4 Service level agreements


What this unit is about A service level agreement (SLA) typically defines an
agreement, between a provider and a customer, that
specifies an acceptable level of service for a resource.
Tivoli Business Service Manager provides tools to define
and track SLAs for any service instance. In this unit, you
learn about the types of SLAs that are supported. You
learn how to configure SLAs and apply them to one or
more services. Most SLAs include routine maintenance
windows for a service. The maintenance windows are not
counted against an SLA calculation. You learn how to
create and apply maintenance windows to business
service instances.
Student exercises
Objectives
tasks:
Describe the types of service level agreements (SLAs) that are tracked
in Tivoli Business Service Manager 6.1
Create and view duration SLAs
Create and view cumulative duration SLAs
Create and view incident count SLAs
Configure SLA revenue penalty tracking
Create and use maintenance windows
Objectives
V7.0
Lesson 1. Creating service level agreements
Uempty
Lesson 1. Creating service level

agreements
What this lesson is about In this lesson, you learn the concepts of Service Level
Agreements (SLAs) in Tivoli Business Service Manager.
You learn the function of, and how to create, the three
types of supported SLAs.
Describe the types of service level agreements (SLAs)
that are tracked in Tivoli Business Service Manager
6.1.1
Create and view duration SLAs.
Create and view cumulative duration SLAs.
Create and view incident count SLAs.


V7.0
Uempty
Service level agreement overview

Tracking SLA status reduces penalties and improves customer
service.
SLA trend report shows only evidence of failures after an
incident, offering no method to correct the problem.
Users can prioritize their time and resources based on financial
and customer service costs.
Tracking SLA status helps provide metrics to set internal goals
for providing service to internal and external customers.
Service level agreement overview
Service level agreements (SLA) provide benefits to a business, such as the following ones:
Reducing the opportunities for penalties because of SLA violations
Providing an organization a better understanding of how to prioritize time and resources
Providing accurate metrics for a business to use to set internal goals for customer service

SLA status: Violations and warnings

Several criteria are used to generate visual alerts and track
service availability
Status of services
How long a service state is Bad or Marginal
How often a service state is Bad or Marginal
A Warning state and alert indicates that SLA compliance is
jeopardized and attention should be paid to service and
subordinate service status.
A Violation state and alert means that an SLA violation
threshold has been exceeded.
SLA status: Violations and warnings
Tivoli Business Service Manager generates service-related events in the ObjectServer if threshold
values in an SLA are approached or exceeded. You can use a filter with the Active Event List to
monitor service-related events. SLA Warning events provide an opportunity to take corrective
action before the SLA is compromised. SLA Violation events indicate that an SLA is in a violation
state.
V7.0
Uempty
Real-time tracking of service availability
Tivoli Business Service

Manager provides
several graphical tools to
track SLAs.
Real-time tracking of service availability
Any defined SLA continuously tracks service availability. When you set warning thresholds,
operations staff have time to determine and solve the problem before an SLA violation occurs.
When SLA violations occur, Tivoli Business Service Manager can track a predefined penalty cost.

Types of service level agreements

Tivoli Business Service Manager supports three types of service
level agreements:
Duration
Cumulative duration
Incident
Types of service level agreements
Tivoli Business Service Manager provides the following three methods for tracking service level
agreements:
Duration: Any affected service instance outage is tracked from the time a service changes to a
Bad state until the Bad state is cleared.
Cumulative duration: The total accumulated duration violations are tracked for a configured
period.
Incident: Any time a service instance status changes to a Bad state, regardless of duration, it is
counted as an incident.
V7.0
Uempty
Duration SLA violations and warnings

Service status is tracked continuously.
Multiple bad states are not accumulated.
Duration SLA violations and warnings
A duration-based SLA tracks one or more monitored services continuously. Violations and
warning values are set to track how long an outage occurs at any time. The tracked duration begins
when a service changes to a bad state.

Cumulative duration SLA violations and

warnings
Calculate the the total outage time over specified periods.

The time period is a continually moving window.
For example, assume a 1-hour window is specified, and a
1-minute outage occurs from 1:00 to 1:01 PM. At 2:01 PM, the
hour window moves past the 1:00 PM outage, and it no longer
counts in the outage calculation. At 2:01 PM, the window has
zero cumulative outage.
9
Cumulative duration SLA violations and warnings
A cumulative duration-based SLA tracks one or more services over a specified time. During that
period, any service outage durations are accumulated. Warnings or SLA violation events are also
generated if the accumulated violations exceed the value that is defined in the SLA.
V7.0
Uempty
Incident count SLA violations and warnings
Service status is tracked over a specified time period.

An incident is configured as any transition to a Bad service
state or a duration SLA violation within the defined time
window.
10
Incident count SLA violations and warnings
An incident count SLA tracks one or more services over a specified time. During that period, any
transition of a service status to a Bad state, regardless of the duration, is counted as a single
incident. Warning or violation events are generated if the incident count exceeds the value that is
defined in the SLA.

SLA indicators in the default service icon
Cumulative time SLA status
Outage incident count

Duration violation status
Total events for service
Real-time status indicator
11
SLAs indicators in the default service icon
You configure an SLA by editing the service template in the Service Editor. The status of the SLA
can then be tracked from the viewer portion of the Service Editor.
In the Service Editor, the following items are displayed:

A Time column shows the status. The three states are Clear, Warning, and Violation for any
time-based SLA defined.
Details are shown when you click the indicator or when you select a service in the Service
Navigation portlet.
A gauge shows the duration-based SLA status. Colors are used to indicate status.
Elapsed time is displayed if a real-time view is selected.
V7.0
Uempty
Example: Duration SLA criteria

Brief periods of downtime are acceptable.
Continuous unavailability exceeding two minutes is
unacceptable.
SLA status is set according to
the following criteria:
Warning after one minute
Violation after two minutes
12
Example: Duration SLA criteria
A duration-based SLA measures the outage when the service status is Bad. In the example, brief
outages are considered acceptable. However, if they exceed 1 minute, the service SLA status is set
to Marginal. If they exceed 2 minutes, the SLA status is set to Bad. A new alert is sent to the
ObjectServer, notifying the user of the specific instance and calculation. In this example, the service
is down for 2:03. The status is also seen in the navigation tree of the services, in the Time column.

Editing SLAs in the template editor
SLA definitions are defined for a template in the SLA tab in the
Service Editor portlet.
Set the outage duration thresholds.
Select the check box to enable the SLA in the template.
13
Editing SLAs in the template editor
To configure SLA settings, edit the template. This example uses the WebApplication template. Use
the form in the SLA tab to define one or more SLA types. Complete these tasks to create a
duration-based SLA:
1. Select Calculate duration based SLA violations.
2. Indicate how long the service violation must continue to cause an SLA Marginal state and what
duration causes an SLA Violation state.
3. Save the template.
V7.0
Uempty
Configuring a cumulative duration SLA

Example:
If a service is Bad > 2 minutes in a 60 minute window, SLA state =
Warning.
If a service is Bad > 5 minutes in a 60 minute window, SLA state =
Violation.
14
Configuring a cumulative duration SLA
A cumulative duration-based SLA is configured in the same manner as the single incident duration
SLA. To configure a cumulative duration-based SLA, complete these tasks:
1. Select the template to edit and select the SLA tab.
2. Select Calculate cumulative duration SLA violations.
3. Set a time duration for warnings and violations. You can define combinations of months, days,
hours, and minutes.

Configuring an incident count SLA

Example:
Two service state changes to Bad in a 30-minute window = SLA
Warning State
Four service state changes to Bad in a 30-minute window = SLA
Violation State
15
Configuring an incident count SLA
An incident count SLA is configured in the same manner as the duration SLA. To configure an
incident count SLA, complete these tasks:
1. Select the template to edit and select the SLA tab.
2. Select Calculate number of violations in given time period.
3. Select Duration violations only to consider only a duration violation as an incident. Selecting
All violations considers any time a service changes to a bad state.
4. Set a time duration for warnings and violations. You can define combinations of months, days,
hours, and minutes.
V7.0
Uempty
Creating multiple service levels for templates

Create multiple SLAs to support different customers or
business units.
Define multiple SLAs for a template.
SLA assignment is configured in the service properties.
Creating multiple service levels for templates
A network service provider charges different fees for different SLAs. An IT department or data
center can have more than one SLA, depending on the customer contract or business unit. You can
define one or more SLAs, each of which you can assign to a specific instance of a business service.

Adding SLA definitions to a template
Click the New Service Level icon to add another set of service
level definition forms.
Standard is the default SLA.
Adding SLA definitions to a template
At the top of the SLA section in the template editor, add a service level name. By providing multiple
SLA definitions at the template, you can select an appropriate SLA level when you create a service
instance.
V7.0
Uempty
Configuring the second set of SLA definitions

Initially, the new service level configuration rows are labeled
NewServiceLevel. The label is updated when the template is
saved.
Example:
Create a duration-based SLA configuration called Gold.
Set the configuration for the Gold SLA incident count and cumulative
duration sections.
Configuring the second set of SLA definitions
Add SLA definitions for a template with the template editor. Services that are based on templates
with multiple SLAs defined can select an SLA on an individual basis.

Applying an SLA to a service
By default, every service inherits the Standard SLA from the

template.
You assign SLAs during the service instance creation or by
modifying the existing service properties.
Applying an SLA to a service
When creating a service instance, you select the service level from the Service Level menu in the
Service Properties section.
V7.0
Uempty

Student exercises
Student exercise
V7.0
Lesson 2. Testing service level agreements
Uempty
Lesson 2. Testing service level

agreements
What this lesson is about In this lesson, you learn how to trigger and test SLAs for
a service. You learn to analyze the visual changes to the
service model in the console and how to verify the SLA
operation. You also learn how to configure and use the
revenue penalty feature for an SLA.


V7.0
Uempty
Testing and analyzing service level agreement

operations
Before 1 minute After 1 minute After 2 minutes
23
Testing and analyzing service level agreement operations
An outage is based on the service that is evaluated in a Bad state. A duration SLA measures the
length of the current outage. In this screen image, the change in the icon status is shown as the
SLA status changes from a Warning to a Violation state.

Viewing a cumulative duration SLA operation

Example:
InetBanking has a single duration SLA violation.
The total Bad state duration is only enough to trigger the cumulative
duration Warning.
Cumulative duration Warning

threshold exceeded
Duration Violation threshold

exceeded
24
Viewing a cumulative duration SLA operation
In this example, the top-level icon for InetBanking shows the cumulative duration violation status
with the bar next to the sigma symbol. The single, or current, incident duration violation is shown
with the red line.
V7.0
Uempty
Viewing incident count SLA operation

Example:
The InetBanking service state is currently Good.
Four recorded service outages have occurred within a 30-minute time
window.
The SLA state is set to Violation. A cumulative duration SLA is
being tracked and the
Warning threshold was
exceeded.
Service outage count within

a specified time window
generated a violation.
No single-incident duration
outage is currently being
tracked.
25
Viewing incident count SLA operation
This screen capture shows the results of an incident count-based SLA violation. The total incident
count over a specified period is displayed under the cumulative duration status bar showing a Good
status. The bar showing a Violation status represents two service status changes to a Bad state
within a 30-minute time window. No change in the duration violation bar graph is displayed because
the overall service state is set to Good.

Revenue penalties
Tivoli Business Service Manager can calculate revenue penalties
based on SLA violations.
The penalty calculation uses the HourlySLAPenalty service parameter.
The default value for the HourlySLAPenalty parameter is set in the
template properties.
The service properties setting overrides the template default.
26
Revenue penalties
You can include an hourly SLA penalty calculation in SLA calculations. You set the penalty
multiplier at the template level as either a default for all services of the template, or individually at
the service level.
V7.0
Uempty
Viewing SLA penalty calculations

SLA warnings and violations generate ObjectServer events.
The penalty calculations are shown in the RAD_WebtopTool1
event field of the SLA event.
Example:
HourlySLAPenalty = 3600
The InetBanking SLA state is in a Violation state for approximately 1.9 minutes,
or approximately 114 seconds.
Penalty = HourlySLAPenalty x length of Violation state (in seconds)
27
Viewing SLA penalty calculations
SLA penalty calculations are processed internally on the Tivoli Business Service Manager server
and shown in an attribute duration event. The number that is shown summarizes the percentage
of availability for a selected service instance. You can view the value by right-clicking a service and
selecting the SLA tab in the Services Details portlet.

Clearing SLA states
You reset the SLA time window in the template editor.

The Clear icon is at the bottom of the SLA configuration form.
Clearing the SLA time window affects all services that use the
template.
28
Clearing SLA states
You can reset the SLA state engine for a template by clicking Clear at the bottom of the SLA form.
The SLA timers for all services that are based on the template are reset.
V7.0
Uempty

Student exercises
Student exercise
V7.0
Lesson 3. Creating and using maintenance schedules
Uempty
Lesson 3. Creating and using maintenance

schedules
Lesson 3. Creating and using

maintenance schedules
What this lesson is about Services that are part of an SLA must periodically be out
of service for scheduled maintenance. Service availability
during scheduled maintenance must not count against an
SLA calculation. Tivoli Business Service Manager
provides a maintenance window tool that temporarily
suspends SLA calculations for a service. In this lesson,
you learn how to create and apply an SLA maintenance
window. You then send test events and verify that the SLA
calculation is not affected.

Create and use maintenance windows.

V7.0
Uempty
Maintenance schedules
Maintenance schedules prevent SLA calculations.
Maintenance schedules are defined with a time window. Time
windows have one of two properties:
Repeating: Time windows occurring at regular intervals.
Absolute: A single time window occurring on a specific date.
Maintenance schedules are configured and set in the Service
Editor or with command-line tools.
All maintenance schedules are available to all services.
Maintenance schedules
You cannot calculate a planned outage of a monitored service against an SLA. These time periods,
or maintenance windows, can be one or more types of time windows, such as these examples:
A combination of time windows
A recurring time window
An absolute time window
You set these window definitions at the service level. Other service instances can share them. You
can also set maintenance windows at the top of a service model hierarchy and cascade them down
to all child services.

Creating a maintenance schedule

Example: A service is stopped
for an hour, within the terms of
the service SLA.
In the Service Editor, click New
to create the maintenance
schedule.
Enter a name for the
maintenance schedule.
Click the Create New Absolute
Time Window icon.
33
Creating a maintenance schedule
In this example, you define a window for weekly backups for InetBanking servers. For this type of
maintenance, you complete these tasks:
1. Edit the service instance in the Service Editor portlet.
2. Click New, to the right of the Maintenance Schedule menu.

3. Enter the schedule for the maintenance.
V7.0
Uempty
Defining the time window

Enter start and end dates and
times.
Click OK to save the time
window definition.
Click OK to save the
maintenance schedule
definition.
Defining the time window
Continuing the example, create a time window definition. Complete these tasks:
1. Enter a schedule name.
2. Click Create New Recurring Time Window to add a schedule.
3. Enter the day and time for the window.
4. Click OK.

Choosing a maintenance schedule

You have three ways to set a maintenance schedule:
Within the service definition
From the service tree or service viewer right-click menus
Using the RAD shell command line
35
Choosing a maintenance schedule
Three ways to set SLA maintenance schedules for services are as follows:
Create a maintenance schedule while editing the service definition. After you create the
maintenance schedule, select the definition from the Maintenance Schedule menu.
From the Service Viewer, right-click a service instance and select Maintenance window tools
> Schedule maintenance. A window is displayed where you can create and apply
maintenance windows. You can set the maintenance schedule for either a single service
instance, the service and all children, or only the children.
Use RAD shell commands to create and set maintenance schedules.
V7.0
Uempty
Viewing maintenance schedule effects
Blue status icon with cone

indicates that the service is in
maintenance mode.
36
Viewing maintenance schedule effects
When you have a maintenance window in effect for a specific service, no incoming status events
are processed to evaluate the service status. The service icon turns blue to indicate that it is in
maintenance mode.

V7.0
Uempty
Student exercises
Student exercises
Perform Exercises 3 and 4 for this unit.

Summary
following tasks:
Describe the types of service level agreements (SLAs) that are tracked
in Tivoli Business Service Manager 6.1
Create and use maintenance windows
Summary
5 Data fetchers
5 Data fetchers


5 Data fetchers
What this unit is about Business service models must be able to respond to
business data and monitor events. Templates can have
multiple rules, which requires a complex evaluation of rule
states. Template rules can also calculate key
performance indicators (KPIs). KPIs are then available to
be included in visual representations of business
services. This unit demonstrates a function that is called
a data fetcher. Data fetchers extend service template
functions to provide comprehensive representations of
business services.
Student exercises
Objectives
tasks:
Create data sources
Create a data fetcher
Create data fetcher template rules to retrieve data from external
databases
Objectives
V7.0
5 Data fetchers
Lesson 1. Data fetcher overview
Uempty
What this lesson is about In this lesson, you learn how to configure business
services to query and evaluate business data in a
template rule. The function that is used to retrieve the data
is called a data fetcher. A data fetcher requires a
connection to a database. You configure a database
connection with an object called a data source. You
configure the data fetcher to retrieve specific records from
a database. You then learn how to use the retrieved data
with an incoming status rule. Last, you learn how to
modify the Service Navigation portlet tree template to
show the calculated rule KPI.

5 Data fetchers
Create data sources
Create data fetcher template rules to retrieve data
from external databases

V7.0
5 Data fetchers
Uempty
Creating services with business data

Tivoli Business Service Manager can use various types of data:
Business data from multiple sources plus monitor events.
External data to populate a numerical attribute for a particular
service template.
External data to determine threshold levels for Good, Bad, and
Marginal status, as with monitor event data.
Creating services with business data
An important use of external data with Tivoli Business Service Manager is to populate a numerical
attribute for a service template. Tivoli Business Service Manager can use this value to determine a
service status, as with a monitor event.

5 Data fetchers
Example: Trouble ticket data
Retrieve trouble ticket status information from a database and show the
number of open tickets assigned per service.
Example: Trouble ticket data
In this example, the screen capture shows the numerical value in a column labeled Open Tickets.
This column represents values for open ticket instances from an external trouble ticket system. The
value is derived from data that is taken from an external database.
V7.0
5 Data fetchers
Uempty
Retrieving ticket data

The data server uses a DB2 database to maintain service
object definitions.
Sample trouble ticket data was added to this database on a
virtual server with Tivoli Business Service Manager installed.
The following example and laboratory exercises use the DB2
database for the data fetcher data source.
Retrieving ticket data
To show external database information to evaluate service models, the DB2 database in the data
server is used. This database is configured with sample trouble ticket data.

5 Data fetchers
Ticket data evaluation

Example: The following data was retrieved from an external database.
highlevelserviceid lowlevelserviceid Customer TicketType Region Severity Status
AlliedSteel WebServer1:80 NYC Problem US 4 Open
AlliedSteel WebServer2:8080 SFO Problem US 5 Open
AlliedSteel WebServer2:8080 HSV Problem FR 4 Close
AlliedSteel WebServer1:8080 ATL Problem US 3 Open
Count the number of trouble tickets for each lowlevelserviceid entry,

where the status is Open.
Ticket data evaluation
For the previous example, a final numerical value is derived by counting the number of rows with a
class status of Open. For example, you might update a service status if the number of open
WebServer tickets exceeds 2.
V7.0
5 Data fetchers
Uempty
Data fetcher creation and configuration tasks

Create and configure a data source.
Create and configure a data fetcher.
Create a numerical incoming status rule for the WebServer
template. The template references the data fetcher.
Add a column to the Service Navigation tree for the data
fetcher data.
Data fetcher creation and configuration tasks
To configure a data fetcher, complete these tasks:

1. Create a data source, if it does not exist.
2. Create the data fetcher.
3. Create a numerical rule for the WebServer template. This template references the data fetcher.
4. Add a column to the Service Navigation tree to show the ticket data.

5 Data fetchers
Creating and configuring a data source

1. Select a data source SQL
type.
2. Assign a name.
3. Enter an authorized
database user name and
password.
4. Configure a primary host
name, database name,
and listening port.
5. Verify the configuration
by clicking Test
Connection.
Creating and configuring a data source
To create a data source, click the Create a Data Source icon in the Data section of the Service
Navigation portlet. In this example, the predefined data source that is called
troubleticketsDataSource is used. For any data source, provide this information:
SQL Type: The type of target database.
Data Source Name: A text string that represents the data source.
Username: The user name authorized to read data from the data source database.
Password: The password of the authorized user.

Host Name: The host name or IP address of the source database.
Database: The internal name of the data source database to be accessed.
Port: The TCP/IP port that the data sources uses to listen for data requests.
You can also define an optional backup database source.
V7.0
5 Data fetchers
Uempty
Creating and configuring a data fetcher

A data fetcher is a tool that is used to retrieve a set of data from
a data source.
You must configure the query to retrieve the appropriate data
and to specify when to pull and how to cache the data.
You can specify to store the data in a cache at the following
intervals:
Regular intervals
Minimum fetch rate
Maximum fetch rate
Multiplier (time of query x multiplier = interval)
Once per day
Creating and configuring a data fetcher
The simplest definition for a data fetcher is to fetch the data daily at a specified time. To define an
interval, Tivoli Business Service Manager fetches data at the multiplier x fetching time. For
example, assume 30 seconds to retrieve the data, with a multiplier of 10. In this case, the product
retrieves data every 5 minutes (30 seconds x 10 = 300 seconds, or 5 minutes). The minimum and
maximum fetch rate, if applicable, override this period.

5 Data fetchers
Steps to create and configure a data fetcher
1. Click the Create Data Fetcher icon in

the Data Fetcher section of the Service
Navigation portlet.
2. Enter a data fetcher name and type.
3. Choose how frequently data is fetched.
4. Configure the data query.
Steps to create and configure a data fetcher
To create a data fetcher, click the Create a Data Fetcher icon in the Data Fetcher section of the
Service Navigation portlet. For a recurring fetch schedule, select the appropriate section of the form
and specify these items:
Minimum Interval Between Fetches: The minimum time lapse between data fetches.
Maximum Interval Between Fetches: The maximum time lapse between data fetches.
Fetcher Interval Multiplier: The multiplied time, in seconds, that the data fetcher waits
between fetches. The actual time depends on the length of time that is needed to complete a
single fetch.
To configure a single daily data fetch, select that section of the form and specify the time of the
fetch.
V7.0
5 Data fetchers
Uempty
Using the query builder
Select a data source.

Select one or more tables. For this example, select TICKETS.
Click Next.
Using the query builder
Build the query that is used with the data source. If you know the SQL query, you can enter it
directly in the SQL query section of the data fetcher definition. Tivoli Business Service Manager
also provides a Query Builder utility. The opening page of the Query Builder wizard is shown in the
screen capture. For this example, troubleticketsDataSource is used. Select one or more
database tables. For this example, select the TBSMDEMO.TICKETS table and click Next.

5 Data fetchers
Selecting table fields
Select one or more fields from the previously selected tables.

For this example, select LOWLEVELSERVICEID and STATUS.
Click Next.
Selecting table fields
Select the fields for the query. Use only the required fields for the data calculations to reduce the
query load. For this example, select the LOWLEVELSERVICEID and STATUS fields and click
Next.
V7.0
5 Data fetchers
Uempty
Setting a data filter
Optionally, create a filter,

or WHERE clause, for the
previously selected data
set.
For this example, enter
STATUS = Open to
retrieve all open
LOWLEVELSERVICEID
ticket records.
Click Next.
Setting a data filter
Define a SQL WHERE clause to limit the data that is retrieved by the fetcher. In general, limit the
amount of data to the minimum needed. In this example, only open tickets are counted. Set the
WHERE clause to STATUS=Open, click Apply, and click Next.

5 Data fetchers
Creating metrics with retrieved data

Optionally, apply metrics
to the retrieved data.
For this example,
NUMOPENTICKETS is
derived as a total count
of open tickets for each
LOWLEVELSERVICEID
record.
Click Next.
Creating metrics with retrieved data
Define measurements to be collected, if necessary, from the Create Metrics section. For this
example, count the open tickets for each LOWLEVELSERVICEID and assign the value to
NUMOPENTICKETS.
V7.0
5 Data fetchers
Uempty
Grouping retrieved data
Optionally, group the retrieved data.

For this example, group by LOWLEVELSERVICEID and
STATUS.
Click Next.
Grouping retrieved data
After selecting a function, select the Group By fields to organize the data. You can also order the
data, but this action typically does not affect the function of the data fetcher. In this example, the
results are grouped with the LOWLEVELSERVICEID and STATUS columns. Click Next.

5 Data fetchers
Ordering retrieved data

Optionally, order the retrieved data.
For this example, use the default ordering.
Click Finish.
Ordering retrieved data
The query builder wizard optionally orders the data in ascending or descending order. Click Finish
to complete the wizard.
V7.0
5 Data fetchers
Uempty
Finishing the data fetcher definition
Verify the query and selected

data source.
Optionally, click View to review
the query results.
Save the data fetcher
definition.
Finishing the data fetcher definition
The completed query is inserted in the SQL Query field. You can preview the data set. Click View
to the right of View Data. Verify the results and save the data fetcher definition.

5 Data fetchers
Testing the data fetcher
Right-click the data fetcher and select Fetch Now.

Right-click the data fetcher and select View Log to see results.
Testing the data fetcher
After you save the data fetcher definition, it is listed in the Data Fetcher section of the Service
Navigation portlet. To override defined time constraints and immediately test the data fetcher,
right-click the data fetcher entry and click Fetch Now from the menu.
V7.0
5 Data fetchers
Uempty
Creating a data fetcher-based numerical rule
Use the
LOWLEVELSERVICEID
field value to match
service instances.
Use the
NUMOPENTICKETS
field value for the rule
metric.
Creating a data fetcher-based numerical rule
To use the fetched data, you must create a status rule. This process is like what you used in the
previous creation of incoming status rules that are based on incoming events. For the
OpenTicketsRule status rule, the data fetcher is the source of the data, rather than an incoming
event. You can preview the data to verify that it is presented as you expected.
The Instance Name field is where you match the LOWLEVELSERVICEID field from the database
to the service name. You can also place an extra filter on the data.

5 Data fetchers
Set the status with the numerical value
Optionally, set the template status with the calculated metric.

Example:
If > 3 open tickets, status = Marginal
If > 9 open tickets, status = Bad
Setting the status with the numerical value
You can use the numerical value that is provided by the rule as a KPI. You can also use the value
as part of a more complex evaluation, or the basis for setting the service status. For this example,
set threshold values for setting the Bad and Marginal status.
V7.0
5 Data fetchers
Uempty
Adding business data to the service tree
Use the Tree Template Editor

Create a column for Open Tickets.
Select the WebServer template from the Active Template list.
Assign the rule to the Open Tickets column.
Adding business data to the service tree
To add business data to the service tree, add a column to show the new measurement in the
Services section of the Service Navigation portlet. Service tree columns are added with the
Template Tree Editor.

5 Data fetchers
Viewing open ticket metrics on the service tree
The number of open tickets matching the WebServer instances are shown
on the service tree.
Viewing open ticket metrics on the service tree
The screen capture shows the calculated numerical value for each matching WebServer instance.
If the database is in a production environment, the calculation and show changes with each data
fetch.
V7.0
5 Data fetchers
Uempty

5 Data fetchers
Student exercises
Student exercises
V7.0
5 Data fetchers
Lesson 2. Dependency rules and data fetchers
Uempty
Lesson 2. Dependency rules and data

fetchers
What this lesson is about In this lesson, you learn how to aggregate child service
KPIs that are calculated from a data fetcher. You then
learn how to modify the Service Navigation portlet tree
template to show the aggregated value in the service tree.
Create data fetcher template rules to retrieve data from
external databases

5 Data fetchers
Aggregating business data in parent templates

Business data can be aggregated from child services.
Example:
Create a template and rule that calculates the number of all open tickets for all
WebServers.
Show the calculated ticket count in a service tree portlet.
Total open WebServer tickets
Aggregating business data in parent templates
All child service numerical rule values are available to parent services. The parent services can
aggregate the child data and show the numerical value in a service tree.
V7.0
5 Data fetchers
Uempty
Developing a service model to aggregate all web
servers
You can use templates and services in multiple service models.
To aggregate metrics from all web server instances, create a
template called AllWebServers.
For this task, you calculate the sum of all open WebServer
trouble tickets.
You use a numerical aggregation rule. Each WebServer
provides an individual count of open tickets with the
OpenTicketsRule.
Developing a service model to aggregate all web servers
Services and service templates can be configured in multiple service and template models. A
parent service in one model can be a child service in another model. For this example, calculate the
sum of all open trouble tickets for all defined WebServer instances. To aggregate all WebServer
instances, you must create a parent template with the WebServer template defined as the child.
You then assign all WebServer instances as dependent services. Show the sum in the Open
Tickets column of the service tree.

5 Data fetchers
Defining the numerical aggregation rule

Aggregate the
OpenTicketsRule
numerical value in the
WebServer template.
Use the Sum function.
Optionally, use the
aggregated value to
determine the part status.
Defining the numerical aggregation rule
For this example, you create a numerical aggregation rule for the AllWebServers template. You
assign the WebServer template as the child, and select OpenTicketsRule as the child metric rule.
Then, you select Sum as the aggregation function. In this case, do not assign any status threshold.
V7.0
5 Data fetchers
Uempty
Creating the aggregation service model
Create a service instance with the aggregation template.

Add all WebServer instances as dependent services.
Creating the aggregation service model
For this example, create a service instance that is called AllWebServersOpenTickets, based on
the AllWebServers template. Assign all WebServer instances as dependent services.

5 Data fetchers
Adding the open ticket aggregation KPI to the

service tree
Use the Tree Template Editor.
Add the aggregation template to the list of active templates.
Assign the aggregation rule to the Open Tickets column.
Adding the open ticket aggregation KPI to the service tree
The sum is available as a KPI when the service instance is defined. For this example, open the
Tree Template Editor and assign the AllWebServersOpenTicketsSumRule value to the Open
Tickets column.
V7.0
5 Data fetchers
Uempty
Viewing the total web server open tickets KPI
The number changes as tickets are opened or closed.

The calculated value can be used with other KPIs in a
customer-specific dashboard.
Viewing the total web server open tickets KPI
This screen image shows the sum in the Open Tickets column. The value can be used in multiple
service tree views.

5 Data fetchers
V7.0
5 Data fetchers
Uempty
Student exercises
Student exercises

5 Data fetchers
Summary
following tasks:
Create data sources
Create data fetcher template rules to retrieve data from external
databases
Summary
6 External Service Dependency Adapter
rules
6 External Service Dependency

Adapter rules

6 External Service Dependency Adapter rules
What this unit is about External Service Dependency Adapters (ESDAs) rules
dynamically create service model hierarchies with
business data. ESDA rules go beyond the capabilities of
data fetcher rules, supporting multiple database queries
and data enrichment. ESDA rules create parent and child
service instances at all levels of a template model.
Student exercises
Objectives
tasks:
Describe when to use External Service Dependency Adapters
Configure External Service Dependency Adapter rules
Use policies in External Service Dependency Adapter rules to build
child services
Demonstrate how to trigger External Service Dependency Adapters to
build a service model
Objectives
V7.0
Lesson 1. External Service Dependency Adapter overview
Uempty
Lesson 1. External Service Dependency Adapter

overview
Lesson 1. Creating services with

events and automatic population rules
What this lesson is about In this lesson, you learn how ESDA rules differ from
incoming status rules and dependency rules. You learn
how to configure an ESDA child rule and how to test the
rule. You learn about the concept of transient and
permanent service definitions.

Describe when to use External Service Dependency
Adapters
Demonstrate how to trigger External Service
Dependency Adapters to build a service model

V7.0
Uempty
External Service Dependency Adapter rule basics

External Service Dependency Adapter (ESDA) rules provide
tools to automate service model creation.
With ESDA rules, you can do the following tasks:
Use complex database queries to build service models.
Create multiple service instances for every level of a service template.
Build complete service models on demand, such as when a user views
the model or in response to monitor event reception.
Use custom policies to enrich monitor or business data when creating
service models.
External Service Dependency Adapter rule basics
ESDA rules are used when the business service model services change frequently and when the
data that is used to build the services requires complex database queries. You can use
Netcool/Impact policy scripts to enhance the service instances for every level of a service model.

When to use ESDA rules

Use ESDA rules at the following times:
Data that is required to create service models is not available from a
single database row or monitor event.
Data that is used as the basis for a service model changes frequently.
Business or monitor data must be analyzed or enriched before
creating or updating service instances.
GetThereFast
Service
Template
ESDA rule
When to use ESDA rules
Incoming status rules and dependency rules can query only a single data source and track services
for a single level of a service model. ESDA rules can query multiple data sources and can build
services dynamically at all levels of a service model. ESDA rules can use Netcool/Impact policy
scripts, which provide a tool to enrich the service model information before the creation of the
services.
V7.0
Uempty
ESDA operation
Service models are built at the following times:
When viewed in a console
When an event is received by a member service
Each ESDA rule is designed to use one service in the service
model as a seed service.
The seed service is an anchor point from which the other
service model instances are derived.
Each level of the model hierarchy is derived by multiple
database queries or with information obtained in previous
queries.
Data sources must be configured before starting the rule.
ESDA operation
Data fetchers are limited to a single database query to retrieve a data set. External Service
Dependency Adapter (ESDA) rules extend the function, supporting multiple database queries and
data enrichment. Service instances are created as needed, either by receiving a view request or in
response to a monitor event. ESDA rules are defined for all levels of a template model. ESDA rules
use a predefined seed template as a known anchor for deriving all other levels of the model.

Persistent and transient services

Service instances are created as persistent or transient.
The configuration elements of a persistent service are permanently
stored in a table in the Tivoli Business Service Manager database.
After creation, they must be explicitly modified or deleted.
The configuration elements of a transient service are stored in a
temporary table in the Tivoli Business Service Manager database.
Transient services have these characteristics:
They become invalid after 60 minutes (default) of inactivity.
They are recreated after invalidation when viewing or when service
events are received.
They are efficient for service models with frequently changing child
services.
You can invalidate them in the Service Editor portlet.
Persistent and transient services
Service instances can be created to operate in one of two modes: persistent or transient. All
service instances that are created in previous units of this course were created as persistent.
Persistent service instances are stored in the DB2 database in permanent tables. Transient
services are stored in temporary tables and are considered valid for 60 minutes (default). The
validation period is reset if a service is viewed or receives a monitor event. If a persistent child
service is redefined with a different parent, the service must be removed from the parent definition
and then associated with the new parent. For a transient service, the parent-child relationship can
be dynamically rebuilt as needed. By default, all services that are created with ESDA rules are
transient.
V7.0
Uempty
Seed services
Every ESDA needs a seed service to anchor the service
model.
The seed service should be persistent.
The seed service is used as the anchor point for deriving all
other service instances.
It can be configured for any level of the service model.
Seed services
To derive all elements of a service model on demand, one service instance is designed as a seed.
The rule configuration is designed to expect the seed service to be consistently available. The seed
is used as an anchor point for all queries and calculations throughout the rule. Any level of the
service model can be the seed. The choice is dependent on the data model used.

ESDA example: Service model template
For this example, the template model consists of four levels.

The Customer template is the seed service template.
You create the ESDA rule in the Customer template.
ESDA example: Service model template
For this example, a four-level template model is configured. The top level is designed as the seed
for the model. Develop the rule to create child services, starting at the top. A complete ESDA rule
also contains rules to create all parent services when any child service is known. You create all
parent and child rules in the seed template.
V7.0
Uempty
ESDA example: TBSMDEMO database data

TRAINESDA_CONNECTIONS table
CONTRACT CUSTOMER ANODE APORT BNODE BPORT

0001 IBM ny-rtr-1 01 sf-rtr-1 03
0002 IBM ny-rtr-1 02 ny-rtr-1 01
0032 BT lon-rtr-2 02 sf-rtr-2 01
0037 BT dal-rtr-1 01 dal-rtr-1 05
The table contains information about communication network

components for multiple customers. Each customer has multiple
contracts.
ESDA example: TBSMDEMO database data
For this example, a database contains customer and contract information for router and port
telecommunication services. Other tables contain information that is related to either the
CUSTOMER column or the CONTRACT column. For this example, the service seed instance is
directly related to the CUSTOMER field. All other services in the service model are derived from
this value.

ESDA example: Creating the ESDA rule
Edit the seed service template.

Click the Create ESDA Rule icon.
11
ESDA example: Creating the ESDA rule
ESDA rules are created in the Service Editor portlet. You create the ESDA rule in the CUSTOMER
seed template by clicking the Create ESDA rule icon in the rule toolbar.
V7.0
Uempty
Understanding the ESDA rule form
The column on the left links to Child rules.

The column on the right links to Parent rules.
The form in the center changes context, depending on the
selected Parent rule or Child rule.
Understanding the ESDA rule form
The ESDA rule form consists of multiple Child rule and Parent rule definitions for each level of the
template model. Child rules create child services for a template parent, and Parent rules create
parent services for a template child. Child rules are listed to the left of the form as a vertical stack of
tabs. Parent rules are listed to the right of the form as a vertical stack of tabs. The center section of
the form changes, depending on the Child rule or Parent rule selected.

Processing Child rules

A child rule is used by a parent service to create child services.
The following information is available to the Child rule:
Parent service name: __serviceinstancename__
Parent service display name: __displayname__
Parent service description: __description__
Parent service Additional parameters: __AdditionalParameterName__
The data set that is returned from the SQL Query is used to
create and configure child services.
Processing Child rules
For each Child rule, variable values are available for use in the data query that is used to determine
the child services. Variable names are bracketed with two underscore characters.
The following variables are available:

__serviceinstancename__
__displayname__
__description__
These variables are for the name that is defined for the parent service instance, display name, or
description. For example, for the Customer Child rule, __serviceinstancename__ is the Customer
seed instance name.
Any parameters that are defined in the Additional tab for a service are also available as variable
names. The names are passed to the rule in the form __AdditionalParameterName__. In addition
to the variable name, the data set that is returned with the SQL Query value is available for child
service creation.
V7.0
Uempty
ESDA example: Customer template Child rule

Select the data source.
Query the table
containing Customer
and Contract data.
Use CONTRACT
records associated with
each CUSTOMER for
each child service.
ESDA example: Customer template Child rule
In this example, you create the ESDA rule in the Customer template. All Child rules and Parent
rules are defined in this form. Using the previously shown database table, you query the table to
return all CONTRACT records where the CUSTOMER field matches the __serviceinstancename__
value. You create a seed service instance that is called IBM and assign it to the Customer template.

Triggering an ESDA rule

Create a Customer
seed service.
Expand the seed
service in a service
tree or service
viewer portlet.
Triggering an ESDA rule
To trigger an ESDA rule, you complete the Child rule configuration. You trigger the rule to process
data by viewing all levels of the service model, starting with the seed instance.
V7.0
Uempty
Viewing the child services

You expand the seed service to trigger the
ESDA rule, which creates the child
services.
By default, each Contract service is created
with the transient service property.
Viewing the child services
When the example IBM seed service tree entry is expanded, the Customer child rule is triggered.
The rule queries the defined data source with the following query:
Return all CONTRACT records where CUSTOMER = __serviceinstancename__ = IBM
For each record returned, you create a transient service instance with the value of the CONTRACT
record.

V7.0
Uempty
Student exercises
Student exercises

Lesson 2. Expanding ESDA rules
What this lesson is about In this lesson, you learn how to expand the scope of the
ESDA rule by configuring a child rule for the next level of
the template model. The child services at the next level of
the service model are derived from a SQL query to a
second table in the target database.
V7.0
Uempty

Creating a second child rule
Child rules are defined for every parent level of the template
model.
Parent rules are defined for every child level of the template
model.
Creating a second child rule
To continue the ESDA rule definition, define the Contract Child rule. This Child rule creates
Connection child services for every defined Contract parent service. Open the ESDA rule in the
Customer template.
V7.0
Uempty
Contract and connection relationships

CONTRACT ANODE APORT BNODE BPORT
0001 ny-rtr-1 01 sf-rtr-1 03
0002 ny-rtr-1 02 ny-rtr-1 01
0037 dal-rtr-1 01 dal-rtr-1 05
The TBSMDEMO.TRAINESDA_CONNECTIONS table

contains port and node data for contracted router connections.
Each Connection service defines a pair of connected router
nodes and ports.
The Connection service name form is
ANODE:APORT-BNODE:BPORT
Example:
ny-rtr-1:01-lon-rtr-1:01
Contract and connection relationships
For this level of the template model, you use related tables in the database to determine which child
services to create. In this example, the parent service, the contract is a key field in the
TBSMDEMO.TRAINESDA_CONNECTIONS table. You must determine a connection service for
any related contract service. A connection is a logical name that indicates the port and router pairs
for a telecommunication service. It is created by concatenating related ANODE, APORT, BNODE,
and BPORT records.

Creating the Contract Child rule
Edit the Contract Child rule in the customer customESDARule.

Query the table containing the contract and connection data:
TBSMDEMO.TRAINESDA_CONNECTION
Find ANODE, APORT, BNODE, and BPORT records that are
associated with each CONNECTION.
Create CONNECTION child service instances for each record
in the list.
Creating the Contract Child rule
To create a contract child rule, you click Contract in the Child rules column. You create the query to
determine the components of a Connection name and then create a concatenation expression for
the instance name and display name.
V7.0
Uempty
Invalidating transient services

Invalidate transient services and service model hierarchies to
force reevaluation of ESDA rules.
Invalidate the top level of the template model by using the
command line or the Service Editor portlet.
Click Invalidate in the Service Editor portlet.
Invalidating transient services
You invalidate the previous child services that are created by clicking the seed service and clicking
Invalidate in the Service Editor.

Viewing the Contract Child rule operation

Invalidate the Customer service instance.
Expand the Customer and Contract levels of the service model.
Viewing the Contract Child rule operation
To view the contract Child rule operation, you expand the Customer and Contract levels of the
service model. Each parent expansion creates corresponding child services.
V7.0
Uempty

Student exercises
Student exercises
V7.0
Lesson 3. Using policy scripts
Uempty
What this lesson is about In this lesson, you learn how to use a Netcool/Impact
policy script in an ESDA rule to build the child services.
Policy scripts provide greater flexibility when evaluating
the data used to build the child services. In this example,
the parent service name contains the information that is
required to derive the child service names. Parsing the
parent rule name for the child service names eliminates
the requirement to query a database to find the
information.

Use policies in External Service Dependency Adapter
rules to build child services

V7.0
Uempty
Creating child services with policy scripts

In the example, there must be two child Port services created
for every parent Connection service.
By default, Child rule operation creates only one child for every
parent.
One solution is to create multiple ESDA rules. The first rule
creates the first port, the second rule creates the second port.
A more efficient solution is to use a policy to create the child
services based on substrings in the parent service name.
For example, parse the Connection service instance name lon-
rtr-1:04-bei-rtr-3:01. The substrings on the left and right of the
center hyphen are the port names:
A Port: lon-rtr-1:04
B Port: bei-rtr-3:01
Creating child services with policy scripts
The example service model uses two Port child services for every Connection parent service. By
default, only one child service can be created for every parent service. Using a policy in the
Connection child rule solves the limitation. A policy can complete complex calculations, more
database queries, and data enrichment to determine child services.

Example: Using a policy in a Child rule
Create the Connection Child policy to create Port child rules.

Configure the SQL Query field to provide the data for the
policy. For this example, use the Connection parent service
name as the input to the policy. Use the variable name
__serviceinstancename__.
Select Use Policy at the bottom of the Child rule form.
The values entered for the name, display, and description
expressions are returned by the policy.
Example: Using a policy in a Child rule
You enable a policy for a Child rule by using these steps:

1. Select the Use Policy check box.
2. Click Edit Policy to define the policy operation. For this example, pass the parent service name
to the policy by entering __serviceinstancename__ in the SQL Query field. Using the parent
instance name eliminates an extra SQL query in the ESDA rule.
V7.0
Uempty
Variables passed to the policy

ExternalQueryDataType: The name of the data source selected
in the Child or Parent rule.
ExternalFilter: The query entered in the SQL Query field of the
Child or Parent rule.
Variables passed to the policy
The parent service name in the __serviceinstancename__ variable is referenced in the policy with
the name ExternalFilter. The ESDA data source name is referenced in the policy with the
ExternalQueryDataType variable name.

Reviewing the Connection Child rule policy

AInstance = newObject();
BInstance = newObject();
Elements = rextractall(ExternalFilter,"(.*\-rtr\-.*:.*)\-(.*\-rtr\-.*:.*)");
AInstance.MyInstanceName = Elements[0];
AInstance.MyDisplayName = Elements[0];
AInstance.MyDescription = "Created in ESDA Policy";
BInstance.MyInstanceName = Elements[1];
BInstance.MyDisplayName = Elements[1];
BInstance.MyDescription = "Created in ESDA Policy";
NextLevelOrgNodes = {AInstance,BInstance};
i=0;
while (NextLevelOrgNodes[i] <> NULL) {
NextLevelOrgNodes[i]._TagList = "Port";
i = i + 1; }
Reviewing the Connection Child rule policy
The policy passed the Contract service instance name from the __serviceinstancename__ variable
in the Child rule SQL Query field. The variable is assigned to the ExternalFilter array in the policy.
The value is then passed to a regular expression function. The function extracts the parts of the
parent service name that are used to create the child Port services.
V7.0
Uempty
Parsing the parent service name

The connection service name contains enough information to
create both ports and the router service.
For example, given a Connection service instance called lon-
rtr-1:04-bei-rtr-3:01, the following Port values can be extracted:
A Port: lon-rtr-1:04
B Port: bei-rtr-3:01
Use a policy regular expression to extract the text strings:
rextractall(String,"(substring1) (substring2)");
Parsing the parent service name
The Connection instance name is derived from the concatenation of data from a database query.
The policy parses the name for the Port name values, rather than creating another database query.
A policy regular expression is used to extract the text strings.

Passing parameters
NextLevelOrgNodes: This parameter is required. Each member
of this array is used by the ESDA rule to create an instance.
For each member of the array, the object attributes can be
used in the Results section of the ESDA configuration.
AttributesList: This parameter is required. It sets additional
instance parameters with the following properties:
_TagList: A list of templates to add to an instance
_PrimaryTag: The primary template for the instance
_RemoveTagList: A list of templates to remove from an instance
AttributesList and NextLevelOrgNodes are coordinated by the
index number for each array of objects.
Passing parameters
All ESDA policies must return service instance data in an array called NextLevelOrgNodes. Each
service is created as each element in the array is processed by the rule.
V7.0
Uempty
Adding attributes to child services

AttributesList = {};
i=0;
while (NextLevelOrgNodes[i] <> NULL) {
Attributes = newObject();
Attributes._TagList = "<SomeTemplateName>";
AttributesList = AttributesList + Attributes;
i = i + 1;
}
Set instance attributes for the objects in NextLevelOrgNodes.
For this example, set the child service template.
Adding attributes to child services
The last section of the policy uses a looping construct to assign the Port template to each entry in
the NextLevelOrgNodes array.

Saving the policy script

Click Check Syntax before saving.
Save the policy.
Enter a policy name when prompted.
Saving the policy script
To save the policy script, you click the Check Syntax icon before closing the policy editor. You are
prompted for a policy name when saving the file.
V7.0
Uempty
Testing the policy-based Child rule

Invalidate the top-level
service instance.
Expand the Customer,
Contract, and Connection
levels of the service model.
Testing the policy-based Child rule
Invalidate the seed service and expand all levels of the model, starting with the seed service. The
multiple Port instances are shown at the lowest level of the service model.

Troubleshooting ESDA policies

Add Log() commands to policy scripts.
Example:
Log(ExternalFilter: + ExternalFilter);
Increase the data server logging level.
Review the policy log file,
$TBSM_HOME/logs/TBSM_policylogger.log.
Sample log data:
Troubleshooting ESDA policies
The Log() command is used to print runtime values during policy processing. More logging levels
can be enabled to add processing detail.
V7.0
Uempty

Student exercises
Student exercises
V7.0
Uempty
Summary
following tasks:
Describe when to use External Service Dependency Adapters
Use policies in External Service Dependency Adapter rules to build
child services
Demonstrate how to trigger External Service Dependency Adapters to
build a service model
Summary

7 Automatic service model creation

278 Copyright IBM Corp. 2013

V7.0
Uempty
What this unit is about In this unit, you learn several methods of automatically
creating service models. You learn how to use incoming
events and data fetchers with automatic population rules.
You learn how to create services with the Discovery
Library Toolkit and structured discovery data. Services
that are created with discovery data are created in the
Service Component Repository (SCR) database. Finally,
you learn how to analyze the SCR and use the Business
Service Composer tool to enhance and create service
models from discovered services.
Student exercises
Business Service Composer Version 1.1 Users Guide
Objectives
tasks:
Describe how to use automatic service model development techniques
Create services with event-based automatic population rules
Create services with data fetcher-based automatic population rules
Create services with ESDA rules
Use the Discovery Library Toolkit to create service models with Tivoli
Monitoring discovered resources
Demonstrate launch-in-context with services in the Service
Component Repository
Use the Component Registry tool and Business Service Composer to
create service models with Service Component Repository services
Objectives

Lesson 1. Automatic service population overview
Lesson 1. Automatic service population

overview
Lesson 1. Automatic service

population overview
What this lesson is about In this lesson, you learn how to create automatic
population rules. Automatic population rules are attached
to incoming status rules. The automatic population rule is
triggered as data is received by the incoming status rule.
The incoming event fields are used with the automatic
population rule to build new business services.
V7.0
Uempty
Describe how to use automatic service model
development techniques
Create services with event-based automatic
population rules


Creating services with events and automatic

population rules
Use the following tools to create services automatically:
RAD shell: Command-line functions.
Event-based automatic population: Event data creates model into
which it can fit.
Data fetcher: Same as event-based but uses database instead of
alerts.status.
ESDA: External Service Dependency Adapters (ESDAs) use a set of
preconfigured data queries and rules to populate both child and
parent.
Discovery Library Toolkit: This utility is used to create and populate
service models. It uses IDML books or connection to a change and
configuration management database.
Creating services with events and automatic population rules
This unit explores the following methods of automatically populating service models:
Event-based: Use incoming events.
Data fetchers: Use external database values.
ESDA: Use automatic population rules.
Discovery Library Toolkit: Uses IdML books or connects with a Change and Configuration
Management Database, such as the Tivoli Application and Dependency Discovery Manager.
Note: You can also create service models with command-line tools. A review of the
command-line tools is in Command line administration on page 438.
V7.0
Uempty
Persistent and transient service review

A persistent service instance is one whose configuration data is
permanently stored in the DB2 database.
A transient service instance is created when needed and
temporarily stored in the DB2 database. An example is a
service that is created when a user views the service or when
an event must be applied to the service.
When a transient instance is created, a flag is set. This flag
indicates that the service is valid. By default, if there is no
change in the status, and no view request is received, the
service is flagged as invalid.
After a service is invalidated, any associated activity triggers
the rule that rebuilds the service.
Persistent and transient service review
Tivoli Business Service Manager supports two service model types: persistent and transient.
Persistent models remain in the internal DB2 database tables. Transient models are built when
required, such as when activated by an incoming event or shown in the Tivoli Business Service
Manager console.

Comparing service creation tools

Event Data Fetcher Discovery
Console RAD Shell Automatic Automatic ESDA Library
Population Population Toolkit
Persistent Persistent or Persistent or Persistent or Persistent or Persistent or
transient transient transient transient transient
Simpler to Scripting Automatic Automatic Easiest to Automatic
create generally build of build of maintain and build of
required services services scale services
Manual Can store Events Must fully Prerequisites: Uses service

and reload required to understand Full definition
build service data source understanding through
structure of data source Discovery
structure and Library
knowledge of Adapter
Impact Policy provider or
Language through
TADDM
Comparing service creation tools
This chart shows the tools that are available to build service models in Tivoli Business Service
Manager. Each tool supports a different method of service model creation. Choosing which tool to
use typically depends on the source of the data or events. All of these tools are described in more
detail in the remainder of this unit.
V7.0
Uempty
Event-based automatic population

Automatic population creates service instances based on
events from the ObjectServer that match certain set conditions.
This method is especially useful in large environments where
there might be tens or hundreds of service instances of a
template. It can also be useful where the actual model is
dynamic.
Example:
BobsBooks depends on WebFarm5 and WebFarm6.
WebFarm5 depends on WebServer7:80 and WebServer8:80.
WebFarm6 depends on WebServer9:80 and WebServer10:80.
The instances have these values:
The value in the Node field specifies the web server to create.
The value in the Manager field specifies the web farm to create.
The value in the Agent field specifies the web application to create.
Event-based automatic population
Automatic population rules create services that are based on events that are received by the
OMNIbus event server. You can set up the event feed so that different fields in the event are used
to define service object relationships. Tivoli Business Service Manager automatically creates the
service model with those fields and automatic population rules. For example, if the Node field
indicates the WebServer to which the event is applied, the Manager field indicates the associated
WebFarm. The Agent field determines the WebApplication for which the event is applied. These
instances are automatically created, even if they never previously existed.
In this example, you create a rule that populates web servers, web farms, and web applications.
You use the Node, Manager, and Agent field values from the incoming event to determine which
templates are used to automatically create the associated services. The Node field value is used
as the name for the web server that is created. The Manager field value is used to create or identify
the associated web farm. The Agent field value is used to create or identify the associated web
application.

Creating an automatic population rule
Automatic population rules must be tied to an incoming status rule.

The processing of the incoming status rule triggers the automatic population
rule.
To create the rule, you click the Create Auto Population rule icon.
Creating an automatic population rule
Automatic population rules must be associated with an incoming status rule. In the WebApplication
template model example, the WebServer template contains the incoming status rules.
To open the rule form, edit the WebServer template and click the Create Auto Population rule
icon.
V7.0
Uempty
Configuration form
Map the automatic population rule to an existing incoming
status rule.
Fill out the form for all levels of the template hierarchy.
The template hierarchy that is available is based on the templates that are
associated with the incoming status rule.
Configuration form
You must choose an incoming status rule from one of the rule sets in the template. This rule is the
entry point for creating the services. When the event matches an incoming status rule, the attached
automatic population rule is processed first. In this example, the WebServerStatusRule rule is
selected in the Incoming Status Rule menu.
Next, you create the Instance Name Expression. For this example, use the Node field value as
the Instance Name. Use the combination of the Node and AlertKey field values as the Display
Name. You can use any valid Tivoli Netcool/Impact regular expression in these fields.
You assign an SLA value for the created service. In this example, leave the service level agreement
as Standard.
Define the restriction filter. This value determines whether an instance is created with that section of
the auto population rule. You can use the filter to create instances only if a matching value in the
event is defined. For this example, setting the restriction filter to true creates a service instance if
the Node field is not equal to an empty string.

Parent configuration
Configure the automatic population rule to populate all levels of

the service hierarchy.
Parent configuration
If you want the service instance relationships to be automatically created, you must configure the
form for each parent level also. Each tab of the form corresponds to the parent template in the
hierarchy. The WebServer template is a child of multiple template parents. Select the parent
template from the Incoming Status Rule menu and click the Instance Name Expression field to
refresh the form.
V7.0
Uempty
Triggering event automatic population rules

Example:
Send events for four WebServer services.
Each event must have a unique Identifier field and include
AlertGroup=WebServerStatus.
Node Severity AlertKey Manager Agent
WebServer7 5 8080 WebFarm5 BobsBooks

Triggering event automatic population rules
Test the automatic population rule by generating events manually with nco_sql. The laboratory
exercise test events use script files with the nco_sql commands already configured. This table
shows the event fields to send with test events.

Viewing event automatic population rule

operation
The bad status event is
received, triggering the
automatic population rule.
The service model is created,
and then the bad status event
is applied.
By default, automatic
population rules create
persistent services.
Viewing event automatic population rule operation
This image shows the WebServer services that are created from the monitor events that are sent to
the ObjectServer. The services are also assigned the status, which is based on the incoming event
data.
V7.0
Uempty

Student exercises
Student exercises
Perform Exercise1 for this unit.
V7.0
Lesson 2. Data fetchers and automatic population rules
Uempty
Lesson 2. Data fetchers and automatic

population rules
Lesson 2. Data fetchers and automatic

population rules
What this lesson is about In this lesson, you learn how to configure automatic
population rules for incoming status rules that are
configured to respond to data that is received from a data
fetcher.
Create services with data fetcher-based automatic
population rules


V7.0
Uempty
Creating services with data fetchers and

automatic population rules
Data fetcher automatic population is functionally equivalent to
event-based automatic population.
Use a template rule that references a data fetcher, as opposed to the
ObjectServer.
Ensure that the data fetcher returns all the fields that are required to
configure the parent services.
Creating services with data fetchers and automatic population rules
Creating the automatic population rule is like the previous event-based example. However, you
select the dat fetcher as the source, rather than the ObjectServer. You must also ensure that the
data fetcher returns all the fields necessary to configure the parent services.

Data fetcher automatic population example
The fields that are available to the automatic population rule

are determined by the associated incoming status rule.
In this example, the Restriction Filter value limits the data that
is processed to only match WebServer entries.
Data fetcher automatic population example
This example populates the same hierarchy as the previous automatic population example. For this
example, the automatic population rule starts every time a data fetcher retrieves data from an
external database. When the data fetcher retrieves data from the database, new services are
created if the data does not match existing services.
V7.0
Uempty
Viewing data fetcher automatic population rule

operation
Service instances are created as
the rows retrieved by the data
fetcher are processed.
The data records include open
ticket data, which is applied to
the OpenTicketsRule rule.
The created instances are all
persistent.
Viewing data fetcher automatic population rule operation
This screen image shows the WebServer instances that are created from the fetched data. Instance
status is set with information that is included in the data.

V7.0
Uempty
Student exercises
Student exercises

Lesson 3. Creating services from discovered resources
Lesson 3. Creating services from discovered

resources
Lesson 3. Creating services from

discovered resources
What this lesson is about In this lesson, you learn how to use the Discovery Library
Toolkit to process discovery data and automatically build
business services. The Discovery Library Toolkit can
process discovery data files or discovery data from a
change and configuration management database.
Services that are created with the Discovery Library
Toolkit are stored in the service component repository.
V7.0
Uempty
Use the Discovery Library Toolkit to create service
models with Tivoli Monitoring discovered resources
Demonstrate launch-in-context with services in the
Service Component Repository


Discovered resources overview

Discovered resources are software and hardware assets that
have been cataloged by a discovery application.
Discovery data defines the type and relationships of
components comprising a software or hardware asset.
The relationship data uses the Common Data Model.
Services created from discovery data are stored in the Service
Component Repository (SCR).
Discovered resources overview
The Discovery Library Toolkit provides tools to import discovered resource information to
automatically populate business models. You can import this resource information from two
sources:
Tivoli Application Dependency Discovery Manager: This application automatically creates
and maintains application infrastructure maps. The Discovery Library Toolkit connects to a Tivoli
Application Dependency Discovery Manager server and queries the resource and dependency
information. This information then maps to templates in Tivoli Business Service Manager.
Discovery Library Adapter: The Discovery Library Adapter creates a discovery file. The
Discovery Library Toolkit can process DLA books.
The toolkit also supports a mechanism for monitor event mapping. A unique identifier, called
BSM_Identity, is created for each discovered resource that is processed by the toolkit. The
BSM_Identity is the default service identifier for each service created. You must configure monitor
probes on the physical systems that are modeled by the discovered services to send events with a
corresponding BSM_Identity field value.
V7.0
Uempty
Business service discovery architecture
Business service discovery architecture
This screen capture shows a logical view of the Discovery Library Toolkit. Discovery data is
transformed and applied against the Service Component Repository templates. These templates
are used to map imported IdML books or Tivoli Application Dependency Discovery Manager data to
business services and templates.

Service component repository

The service component repository (SCR) is a database that
contains business services. These services are created from
resource discovery data.
Services are created with the Discovery Library Toolkit.
Predefined templates and rules are installed with the toolkit.
Manually created services can be imported into the SCR.
SCR
Discovery Data Service Model
Service component repository
The services that are displayed in the Service Component Repository (SCR) section of the
Service Navigation portlet are required for the Discovery Library Toolkit to function properly. The
SCR templates are imported during the toolkit installation. The default SCR templates are used to
process discovery data with the Discovery Library Toolkit.
Important: Do not alter the services that are defined under the SCR tab, and do not alter any
service template with a prefix of SCR or BSM. Altering these services and templates can cause
the Discovery Library Toolkit to malfunction. Toolkit upgrades might overwrite customizations.
V7.0
Uempty
Discovery data sample

<cdm:sys.ComputerSystem id="cvtwin05.ibm.com-
ComputerSystem" sourceToken="ip_address=192.167.0.1"
<cdm:Name>cvtwin05.ibm.com</cdm:Name>
<cdm:Label>cvtwin05.ibm.com</cdm:Label>
<cdm:Signature>192.167.0.1</cdm:Signature>
<cdm:Type>ComputerSystem</cdm:Type>
<cdm:Fqdn>cvtwin05.ibm.com</cdm:Fqdn>
</cdm:sys.ComputerSystem>
<cdm:sys.windows.WindowsOperatingSystem
id="cvtwin05.ibm.com WindowsOperatingSystem"
sourceToken="managed_system_name=Primary:CVTWIN05:NT&
object_id=p@Primary:CVTWIN05:NT">
Discovery data sample
A portion of the sample IdML book is shown in this screen capture. Note the XML tag
cdm:sys.ComputerSystem, which starts the node definition for a computer system. More tags
provide further information about the system. This information is then used with the SCR templates
to automatically create complicated discovered service models.

Using the Discovery Library Toolkit

The toolkit must be installed on the data server.
The Discovery Library Toolkit file system is configured during
installation.
When a DLA book is copied to the toolkit file system folder, the
toolkit automatically processes the data file.
The DLA file system folder is in the following default location:
$TBSM_HOME/discovery/dlbooks
The toolkit runs either as a service under Windows or as a
daemon under UNIX or Linux in the following default location:
$TBSM_HOME/tbsm/XMLtoolkit/bin
Using the Discovery Library Toolkit
The Discovery Library Toolkit runs as a daemon under UNIX or Linux and as a service under
Windows. If configured to read IdML books, the toolkit continuously monitors the directory that is
specified during installation. After processing, the services that are created are available in the
Service Component Repository.
V7.0
Uempty
Discovery data and monitor event integration

Status event flow is supported for both distributed and z/OS
resources.
Netcool/OMNIbus probes, Tivoli Monitoring V6, Tivoli Enterprise
Console, and Tivoli Network Manager
OMEGAMON XE (Tivoli Monitoring Services Infrastructure) and Tivoli
Enterprise Console
Event mapping rules for Tivoli Monitoring and Tivoli Enterprise
Console events provide the following functions:
Map resource identity with discovered resources, BSM_Identity
Map event severity and other key attributes
Mapping is configured with probe rules files
Discovery data and monitor event integration
All monitor events that are processed by Tivoli Business Service Manager come through a
Netcool/OMNIbus ObjectServer. Monitor events that are related to service models can come from
various Systems Management monitors. Events that are not directly sent from a Netcool probe
must be translated before the ObjectServer can process them. The Netcool Event Integration
Facility (EIF) probe provides event translation services and event processing for events that are not
sent from a Netcool probe.
The EIF probe receives events from an event source, such as Tivoli Monitoring. The event is
parsed and translated based on the tivoli_eif.rules file. The EIF probe then inserts the translated
event into the ObjectServer. The translated BSM_Identity field is applied against the discovered
services.

Mapping probe events to discovered resources
OMNIbus
Mapping probe events to discovered resources
Monitor events that originate from discovered service instances must include an event identifier
field that maps to the discovered resource. The default event identifier field is the BSM_Identity
field.
V7.0
Uempty
Event identifiers
When the Discovery Library Toolkit creates a service, it assigns
one or more event identifiers to the service.
The default event identifier for discovery data services is
BSM_Identity.
Event identifiers
Creation of a service instance includes the creation and assignment of one or more event
identifiers. Event identifiers are service attributes under the Identification Fields tab of the
Service Editor. By default, the Discovery Library Toolkit creates an event identifier that is called
BSM_Identity. This event identifier is mapped to the ComponentRawTemplateStatus rule.

Incoming status rule for event mapping
ComponentRawEventStatusRule is defined in the

SCR_ServiceComponentRawStatusTemplate.
TME10tecad (6601) is the event class used by the EIF probe.
The BSM_Identity field contains the unique identifier of the
discovered resource.
Incoming status rule for event mapping
The SCR_ServiceComponentRawStatusTemplate template contains an incoming status rule called

ComponentRawEventStatusRule. The rule is processed for all events that are received from the
EIF probe. The EIF probe event class is TME10tecad (6601). The rule processes the EIF probe
events. The event field BSM_Identity is matched with the service instance to which the event must
be applied. This rule is provided with the SCR templates that are installed with the Discovery
Library Toolkit.
V7.0
Uempty
Probe for Tivoli Event Integration Facility

Monitoring systems that do not natively use the Tivoli/Netcool
probe technology can send events to these Tivoli Business
Service Manager. Example monitoring systems:
IBM Tivoli Enterprise Console
IBM Tivoli NetView
IBM Tivoli Monitoring
Events are sent to Netcool/OMNIbus by using the probe for
Tivoli Event Integration Facility (EIF), where they are translated
and forwarded to the ObjectServer.
Probe for Tivoli Event Integration Facility
The Tivoli Event Integration Facility (EIF) probe processes monitor events from several different
event sources. The events are parsed with event rules and then sent to the ObjectServer.

Probe for Tivoli EIF logical architecture
Probe for Tivoli EIF logical architecture
This diagram shows a high-level architectural view of the Tivoli EIF probe. Depending on the event
load, one probe forwards events to Netcool/OMNIbus for multiple event sources. Event sources
include Tivoli Enterprise Console and IBM Tivoli Monitoring. The event source forwards events to
the probe. They are then translated and inserted into the ObjectServer alerts.status table. The
default port for the probe is 5530.
V7.0
Uempty
z/OS event integration overview
Mainframe subsystems write system messages to z/OS.

The Event Pump for z/OS monitors a subset of the messages,
converts them to EIF events, and forwards them to the EIF
probe.
The mainframe events map to services that are created with
mainframe discovery data.
z/OS event integration overview
Mainframe monitor events can be sent to an ObjectServer with either Tivoli NetView for z/OS or
OMEGAMON XE or ITCAM for z/OS. In this configuration, the events are centralized at a
distributed Tivoli Enterprise Monitoring Server and then forwarded to the ObjectServer.

Configuring the EIF probe

Verify the following rules file:
$OMNIHOME/probes/<platform>/tivoli_eif.rules
This file contains processing rules for all event source types, such as
Tivoli Enterprise Console or Tivoli Monitoring.
Verify the settings in the following properties file:
$OMNIHOME/probes/<platform>/tivoli_eif.props
The minimum required parameters are as follows:
PortNumber : 5530
Server : 'NCOMS'
ServerBackup : 'NCOMS'
Configuring the EIF probe
To configure the EIF probe, verify this information:

The tivoli_eif.rules files are available.
The tivoli_eif.props file has the ObjectServer host, port number, and name information.
V7.0
Uempty
Starting and stopping the EIF probe

To start the EIF probe, use the following command:
$OMNIHOME/probes/nco_p_tivoli_eif
To stop the EIF probe:
If started as a background process, locate the process ID and issue the kill
command.
If started in a command window, enter the Ctrl+C key combination.
Starting and stopping the EIF probe
To start the EIF probe, use the nco_p_tivoli_eif command that is in the
<Data_Server_Home>/netcool/omnibus/probes directory. You can also configure this probe to
start automatically with the OMNIbus process control agent.

EIF probe troubleshooting

Edit the following parameters in the tivoli_eif.props file:
StreamCapture : "false"
StreamCaptureFile : '<path>tivoli_eif.stream
$OMNIHOME/probes/<platform>/tivoli_eif.props
Stop and start the EIF probe. The probe sends event data to
the location that is specified in the StreamCaptureFile
parameter.
EIF probe troubleshooting
To verify that the EIF probe is receiving and processing events, edit the tivoli_eif.props file in the
$OMNIHOME/probes/<platform> directory. Send test events. After you stop and start the probe,
any received events are saved to the local file specified in the tivoli_eif.props file.
V7.0
Uempty
Application navigation: Launch-in-context
Discovery data can include information about the source of the

data.
Source application consoles can be started from a service
instance view with a tool referred to as launch-in-context (LIC).
The context launch menus are dependent on the CDM
properties in the service definition.
Application navigation: Launch-in-context
When the Discovery Library Toolkit creates services from discovered data, application information
is included in the service definition. The application information is stored with the service instance
as one or more attributes, which you can find in the Additional tab of the Service Editor. An
example is the IBM_Tivoli_Monitoring_Services_sourceContactInfo attribute. This attribute is a
web address that links to the Tivoli Monitoring web console. These attributes are used to provide
launch-in-context (LIC) connections from the Tivoli Integrated Portal to another application console.

Resource context sharing

Each product views a resource differently.
A Windows server is considered as one of the following items:
Business service (Tivoli Business Service Manager)
Managed system name (IBM Tivoli Monitoring)
Configuration item (Change and Configuration Management
Database)
LIC uses resource information that is supplied in the discovery
data when launching to target applications.
Resource context sharing
The source application provides context information about discovered resources. The context
information is automatically included when the Discovery Library Toolkit uses the data to create
service models. The LIC tool passes the source application information to the secondary console
when the tool creates the remote console connection.
V7.0
Uempty
LIC service instance parameters

Tivoli Business Service Manager supports LIC for those
services that use common data model references with other
products.
Tivoli Business Service Manager shows this data as one or
more service attributes.
The service attributes are listed in the Additional section of the
service property form.
LIC service instance parameters
This screen capture shows the context information for a service instance that is created from an
IdML book. Use a right-click Launch tool from the service tree or service viewer. These menus
automatically include the context information to open the remote application console with focus on
the resource.

LIC menu availability

The launch entry is not available if context reference attributes
are not available.
LIC menu availability
The LIC target is available only if context reference attributes are defined in the service instance
properties.
V7.0
Uempty
Tivoli Monitoring: Context launch target
The Tivoli Enterprise Portal client opens to the workspace that is referenced
in the monitor event.
Tivoli Monitoring: Context launch target
In this screen capture, a Tivoli Monitoring service instance is selected from the Tivoli Integrated
Portal server. Right-clicking and selecting Launch to > Show Managed System (TEP) starts a
browser connection to the Tivoli Monitoring web console. After entering the authorized Tivoli
Monitoring user name and password, the console is started, showing the ManagedSystemName
workspace.

V7.0
Uempty
Student exercises
Student exercises

Lesson 4. Building services in the Service Component Repository
Lesson 4. Building services in the Service

Lesson 4. Building services in the

Service Component Repository
What this lesson is about In this lesson, you learn how to build and enhance
business services with services that are contained in the
service component repository. You learn how to use the
component registry viewer tool to examine the common
data model classes that form the basis for the discovered
services. You then learn how to use the business service
composer tool to create business service models and
place them in the Imported Business Services section of
the service tree.
V7.0
Uempty
Use the Component Registry tool and Business Service
Composer to create service models with Service
Component Repository services


Service component repository review
Discovery data that is processed with the

Discovery Library Toolkit is stored in the
service component repository database.
The toolkit maps common data model
classes to business service templates.
Business applications are linked in the Imported Business
Services section of the service tree.
Service component repository review
The Service Component Repository contains business services that are created as discovery data
is processed by the Discovery Library Toolkit. The discovery data includes Common Data Model
classes that are mapped to business service templates that are installed with the Discovery Library
Toolkit. Discovery data that includes one of the following common data model classes are also
shown in the Imported Business Services section of the service navigation tree:
The cdm:sys.BusinessSystem class is used to create BSM_BusinessService
template-based services.
The cdm:app.Application class is used to create BSM_BusinessApplication template-based

services.
The cdm:core.Collection class is used to create BSM_AppLogicalGrouping template-based

services.
V7.0
Uempty
Service model examples

TADDM discovery data
includes business
application and supporting
component relationships.
The relationship data is
used to automatically
create complex business
models.
Service model examples
This screen image shows the top level of several business services that were created from
discovery data. The DayTrader application is expanded to show the complexity of the automatically
created business service.

Component registry viewer tool

This standalone tool is installed with the Discovery Library
Toolkit.
You browse the SCR database tables.
You understand discovery data class relationships.
You start the tool from the command line:
$TBSM_HOME/XMLtoolkit/tools/crviewer/CRC-Start.sh
Component registry viewer tool
The Component Registry viewer is a software tool that is installed with the Discovery Library Toolkit.
The tool is used to browse the tables and data in the Service Component Repository. The tool is
useful for examining the common data model classes that form the basis for the business service
models.
V7.0
Uempty
Example: Examining SCR classes
Search for a
CDM class.
Select a specific
instance.
Review instance
attributes.
Example: Examing SCR classes
In this example, the Component Registry tool is used to review common data model classes that
are used to create the DayTrader application. The complete class list is shown in the Class List
section of the tool. When you select the application class name, cdm:app.Application, the instance
list is populated with all corresponding instances. You select the DayTrader instance name to show
the attribute list for the Daytrader instance. The application name is identified with the cdm:Name
class.

Business Service Composer

Business Service Composer is a tool in the
component registry viewer.
You can create new services or

enhance existing SCR services.
Business Service Composer
The Business Service Composer is a tool in the Component Registry viewer tool. You use the
Business Service Composer to enhance service models in the Service Component Repository.
Services that are created from discovery data can be complex and include several levels of
services. You can use the Business Service Composer to create a more simplified business
service. In this example, the network bridge services that are shown are five levels below the top of
the DayTrader application. The Business Service Composer project has reconfigured the bridge
services in a NetworkBridges container that is one level down from the top of the application.
V7.0
Uempty
BSC project elements

BSC projects consist of one or more static definitions or policy
patterns.
Static definitions are container services for policy filters.
Policy patterns are predefined SCR search filter rules.
BSC project elements
A business service composer project consists of one or more static definitions and policy patterns.
Static definitions are used to contain the services that are created from the policy pattern
configuration. Static definitions can be one of three types of business templates:
BSM_BusinessService
BSM_BusinessApplication
BSM_LogicalGrouping
Policy patterns are filters that are configured to match data that is contained in the Service
Component Repository.

BSC interface elements
You can define one or more static definitions.

You can define one or more policy patterns.
Policy pattern options depend on the selected pattern.
BSC interface elements
The business service composer is composed of five sections. The Project View section shows a
summary of the defined project elements. The Static Definition section defines one or more static
definitions for the project. Static definitions are services that are created to contain business
services that match classes that are defined in the policy patterns. The policy pattern section is
used to define one or more common data model classes and attributes that match defined criteria.
The classes that match the defined policy pattern are used to create corresponding business
services. The business services that match the policy pattern are created as dependent services in
the static definition. The policy pattern section includes two more sections that are used to define
the criteria for matching the class information that is contained in the Service Component
Repository.
V7.0
Uempty
Configuring static definitions

Static definitions are services that contain the results from a
policy pattern search.
Static definitions must be derived from one of three service
common data model classes:
cdm:sys.BusinessSystem
Maps to the BSM_BusinessService template.
cdm:app.Application
Maps to the BSM_BusinessApplication template.
cdm:core.Collection
Maps to the BSM_ApplogicalGrouping template.
Configuring static definitions
You create a static definition to contain business services that match a policy pattern. Static
definitions must use one of three different common data model classes. The classes map to the
BSM_BusinessService template, the BSM_BusinessApplication template, or the
BSM_ApplogicalGrouping template.

Configuring policy patterns

Policy patterns create filters that search the service component
repository.
The filter results are used to create new service definitions.
The original services in the service component repository are
not modified.
Configuring policy patterns
Policy patterns consist of filters that are configured to search the service component repository. The
database classes that match the configured filter are used to create business services. The original
services that are created with discovery data are not modified.
V7.0
Uempty
Example: Creating a service model with the BSC

DB2 server instances are
contained in many different
service models.
You need to know how to
automatically group
application DB2 server
instances by geography.
Example: Creating a service model with the BSC
In this example, the service component repository contains several hundred DB2 database
services in the Service Component Repository. The services are spread across many different
parent services. For this example, you must organize the DB2 instances by geographical region. A
fictitious company, called GetThereFast Travel, has two data centers. One data center is in Austin,
Texas, and the second data center is in San Jose, California. You must use the Business Service
Composer to create a new service model.

Creating the static definition
Right-click the Static Definitions icon and select Add.

Select a class that corresponds to the BSM_BusinessService
template.
Create a name and display name for the business service.
Creating the static definition
To create a static definition, right-click the Static Definitions icon. You select one of the three
classes, which is mapped to a business service template. Assign a name and label for the static
definition.
V7.0
Uempty
Creating the policy pattern
Right-click the Policy Pattern icon.

Select the PlaceByLabel policy pattern.
Configure a policy pattern to match sanjose or austin in the
class label attribute.
Configure matches to be placed in the corresponding static
definition.
Creating the policy pattern
To configure a Policy Pattern, right-click the Policy Pattern icon. Select the Policy Pattern that is
used to search the Service Component Repository. For this example, the PlaceByLabel pattern is
used. This pattern searches the DB2 instance class labels. You define matches to contain either
sanjose or austin. If a match is found, place the instance in the service that is defined for the
corresponding static definition.

Implementing a BSC project

BSC project files must be applied to the service component
repository with the following commands:
$TBSM_HOME/XMLtoolkit/bin/loadBusinessComposerDefinition
s.sh \
-U <TBSM_Database_Instance_Owner_ID> \
-P <TBSM_Database_Instance_Owner_ID_Password> \
-n <BSC_Project_File_Name>
Implementing a BSC project
Business service composer project files are stored in XML format. A project file must be applied to
the Service Component Repository from the command line.
V7.0
Uempty
BSC project file considerations

All project elements might not be immediately processed for
large SCR databases.
You do not remove SCR services with the console.
You use the following command lines to remove a BSC project
from a service component repository database:
$TBSM_HOME/XMLtoolkit/bin/unloadBusinessComposerDefiniti
ons.sh \
-U <TBSM_Database_Instance_Owner_ID> \
-P <TBSM_Database_Instance_Owner_ID_Password> \
-n <BSC_Project_File_Name_and_Path>
-c <BSC_Project_Name>
BSC project file considerations
The business services that are created with the business service composer project are not
immediately processed if the Service Component Repository database is large. There can be a
several minute delay before the business services are seen in the service tree. You should not use
the console tools to remove a business service from the service component repository. To remove
the effect of a Business Service Composer project, you must use a command with the project file.

V7.0
Uempty
Student exercises
Student exercises
Perform Exercise 4 and 5 for this unit.

Summary
Now that you have completed this unit, you can perform the following
tasks:
Describe how to use automatic service model development techniques
Create services with event-based automatic population rules
Create services with data fetcher-based automatic population rules
Create services with ESDA rules
Use the Discovery Library Toolkit to create service models with Tivoli
Monitoring discovered resources
Demonstrate launch-in-context with services in the Service
Use the Component Registry tool and Business Service Composer to
create service models with Service Component Repository services
Summary
8 Security
8 Security


8 Security
What this unit is about Controlling access to system resources is a critical

component of monitoring system resources. In this unit,
you learn how authentication and authorization to the
Tivoli Business Service Manager dashboard server is
managed. The dashboard server, also known as the Tivoli
Integrated Portal, supports multiple user and group
authentication repositories. You apply roles to control
authorization to data server software objects. This unit
also covers how authentication and authorization are
configured to provide a comprehensive, secure
environment.
Student exercises
References GI11-8054-08 Business Service Manager 6.1.1
Installation Guide
SC23-6040-09 Business Service Manager 6.1.1
V7.0
8 Security
Uempty
Objectives
tasks:
Describe the user authentication and authorization services that are
used in Tivoli Business Service Manager
Configure the dashboard server to use an LDAP user and group
repository
Configure SSL communications between the dashboard server and an
LDAP server
Manage users, groups, and roles in a Tivoli Business Service Manager
deployment
Use authorization roles to control access to Tivoli Business Service
Manager 6.1.1 objects
Objectives

8 Security
Lesson 1. Security overview
What this lesson is about In this lesson, you learn the basic security concepts of
authentication and authorization that are used in the Tivoli
Business Service Manager dashboard server. The
dashboard server uses the WebSphere Application
Server security services. You learn about the different
user repositories that are supported by WebSphere. You
also learn about the concept of a federated repository.
The federated repository combines multiple physical
repositories into a single logical repository.
V7.0
8 Security
Uempty
Describe the user authentication and authorization
services that are used in Tivoli Business Service Manager

Installation Guide

8 Security
Authentication and authorization

Authentication is the process of identifying a user as both
unique and allowed within the Tivoli Business Service Manager
environment.
Authentication guarantees that users are who they claim to be or are
members of a particular Tivoli Business Service Manager group.
Authorization maps one or more roles to a user or group.
These roles are assigned to components within the Tivoli
Business Service Manager environment and determine how
much a user can view, create, delete, or modify.
Authorization, or role, maps are maintained within the Tivoli Business
Service Manager environment. They are not maintained within a user or
group repository.
Authentication and authorization
Authentication is the process of ensuring that a user name and password are valid for an
application. Authorization is the process of mapping authenticated user roles against roles that are
assigned to elements within an application. If the user roles allow access, the user can use the
application element.
V7.0
8 Security
Uempty
Security services
Tivoli Business Service Manager security provides
authentication services through one or more user and group
repositories.
Authorization to Tivoli Business Service Manager objects is
controlled through combinations of user, group, and role
assignments.
External LDAP user repositories can be managed through the
dashboard server web console.
Secure HTTP is used for communication between a browser
and the dashboard server by default.
Tivoli Business Service Manager supports single sign-on
(SSO) when connecting to or from a supported application.
Security services
The Tivoli Integrated Portal 2.2 server uses the authentication and authorization architecture that is
provided by embedded WebSphere Application Server version 7. Authentication uses one or more
supported user and group repositories. Authorization is managed with roles applied to data server
objects.
Hint: The Jazz for Service Management version 1.1 server uses WebSphere Application Server
version 8.5. The security principles that are reviewed in this unit apply to Tivoli Integrated Portal
version 2.2 and to Jazz for Service Management version 1.1.

8 Security
Authentication overview
Tivoli Business Service Manager can be configured for one of
the following user and group repositories during the initial
installation:
File-based
OMNIbus
LDAP
After installation, you can combine one or more repository
types into a single logical entity called a federated repository.
The file-based repository is always available as an internal data
store within the dashboard server.
Authentication overview
When Tivoli Business Service Manager 6.1.1 is installed with the Simple Installation option, it
uses the internal file-based repository by default. The internal repository is not intended for
production use. With the Advanced Installation option, you can specify one of the three supported
repository types. With the OMNIbus or LDAP options, the file-based option is always available. The
administrative account, tipadmin, is stored in the Tivoli Integrated Portal file-based repository. You
can combine the supported repositories to function as a single logical user and group repository.
V7.0
8 Security
Uempty
File-based user repository

Users and groups are stored in a secure file within the
dashboard server.
This repository is the default one when you use the Simple
Install option.
You do not use this repository for production environments.
The file-based user repository does not support SSO between
multiple servers.
The administrative user (default tipadmin) that you create
during installation is always stored in the file-based registry
regardless of the repository that you choose.
File-based user repository
An advantage of the file-based user repository is that it does not require configuration after
installation. It is intended for simple testing and proof-of-concept environments, but it is not useful
for production.
Disadvantages of the file-based user repository are that it does not support SSO and it is not
scalable. Tivoli Business Service Manager supports multiple dashboard servers. Sites large
enough to benefit from multiple dashboard servers use centralized user management. Each
dashboard server file-based repository is isolated to the host server and cannot span multiple
dashboard servers.

8 Security
Example: File-based user repository

Tivoli Integrated Portal Profile Tivoli Business Service Manager
Profile
Tivoli Integrated
Portal
Consoles Dashboard Server

Data Server
Consoles
Authentication/User &
Group Management
File
Repository
Has a small number of users

Supports single dashboard server only
Uses internal file-based repository
Does not support SSO between applications
Example: File-based user repository
In this diagram, the dashboard and data servers are installed on the same host. For this
environment, the file-based user repository is acceptable if the total number of users and groups
remains relatively small.
V7.0
8 Security
Uempty
File-based repository configuration
To accesss repository configuration, you click Security >

Global Security task in the WebSphere administrative
console.
The internal file repository is identified as
o=defaultWIMFileBasedRealm.
To set the repository for users and group management, you
click Security > Global Security > Federated repositories >
Supported entity types task.
File-based repository configuration
Tivoli Business Service Manager can read user and group information from multiple repositories.
However, you can configure only one repository for user and group management through the Tivoli
Integrated Portal server. The Supported Entity Types parameter determines where, within the
configured repository, you create, modify, or delete users and groups.

8 Security
OMNIbus ObjectServer user and group

repository
If you do not select OMNIbus as the repository during
installation, you must install a read-only plug-in into the
dashboard and data WebSphere servers. You use this plug-in
to authenticate users and retrieve user and group information.
You must manage OMNIbus users and groups by using
OMNIbus or Webtop administrative tools.
OMNIbus ObjectServer user and group repository
You must use the Advanced Installation option to select the ObjectServer as the default
repository. You cannot manage the ObjectServer users and groups through the Tivoli Integrated
Portal console; they are used as a read-only repository. You must manage any changes to the
users or groups with ObjectServer tools.
V7.0
8 Security
Uempty
LDAP overview
The Lightweight Directory Access Protocol (LDAP) provides
structured storage of user and group data.
LDAP also provides authentication services for user and group
entries.
LDAP is scalable for large numbers of users.
LDAP is required to support single sign-on (SSO) and console
load balancing.
LDAP overview
Lightweight Directory Access Protocol (LDAP) is a standard that provides a structured and secure
lookup service. User and group names, passwords, and other information are stored for fast
retrieval of information by any application that supports the LDAP client standard.
All supported LDAP servers support Secure Sockets Layer (SSL) encrypted communications
between the Tivoli Integrated Portal and LDAP servers. Single sign-on is only available with an
LDAP user and group repository.
If you have an LDAP product other than Tivoli Directory Server, select the Simple Install option.
After installation, configure for your LDAP server.

8 Security
LDAP logical architecture

TIP Profile
Tivoli Integrated Portal
TBSM Dashboard
TBSM Consoles Server
TBSM Profile
TBSM
Consoles
TBSM Data
Server
LDAP or
High Central User
OMNIbus
Availability Repository
Role Replication
TIP Profile Designed for large number

Tivoli Integrated Portal of users
TBSM Consoles
TBSM Dashboard Supports multiple
Server
TBSM dashboard servers
Consoles
Is a central user repository
Supports SSO between
applications
LDAP logical architecture
Two dashboard servers are shown in this diagram. The central user repository allows them both to
access the same information. Because role information is not stored in the user repository, it is
replicated in the high-availability component. The high-availability component keeps the association
of roles to both users and groups that are synchronized across multiple dashboard servers.
V7.0
8 Security
Uempty
Federated repository overview

A federated repository combines one or more physical
repositories into a single logical repository.
Each physical repository is a base entry.
Every entry in the federated repository is uniquely identified
with a distinguished name that includes the base entry
identifier.
The distinguished name consists of a string of X.500 attributes
and specifies the location in the directory tree.
Examples:
uid=jsmith, o=tipRealm
uid=whill, o=defaultWIMFileBasedRealm
uid=student1, o=netcoolObjectServerRepository
Federated repository overview
You can add an LDAP repository to the federated repository with the WebSphere command
interpreter wsadmin or the Tivoli Integrated Portal console. After entering the configuration
information, you change the Tivoli Integrated Portal Entity Type definitions. This information is
used when adding, deleting, or modifying users or groups with the Tivoli Integrated Portal console.
You can manage only one repository with the console, although it can read user and group
information from multiple repositories.

8 Security
Multiple repositories as a federated repository

Example: Three managed repositories are defined: the default
internal file repository, an LDAP server, and a Netcool/OMNIbus
ObjectServer.
The repositories are designated as follows:
File repository: o=defaultWIMFileBasedRealm
LDAP example: dc=ibm,dc=com
OMNIbus: o=netcoolObjectServerRepository
The Supported Entity Types define how you create and modify
users and groups with the Tivoli Integrated Portal console.
Multiple repositories as a federated repository
A federated repository combines multiple physical repositories into a single logical repository. When
a user authenticates, the user ID and password are tested against the users that are defined in
each physical repository. A WebSphere property that is called the Supported Entity Types
controls the physical repository that is used to manage users and groups with the console. The
Supported Entity Types also control how a user or group name entry is stored and accessed in the
managed repository.
V7.0
8 Security
Uempty
Example of a user lookup

Federated Repository
o=defaultWIMFileBasedRealm uid=tipadmin
o=tiprealm ou=tipusers uid=user1

uid=user2
o=netcoolObjectServerRepository uid=user3
When user1 logs in, the product searches the default file-based
repository. If it finds no match, it searches the LDAP repository.
When it finds a match, it compares the entered password with
the password stored with uid=user1. If the passwords match, the
user is authenticated.
Example of a user lookup
In this example, a federated repository consists of the default file-based repository, an LDAP
repository, and a Netcool/OMNIbus repository. For this example, the Entity Types are configured to
point to the internal file-based repository.
When user1 enters a user name and password, the file-based repository is searched, starting at
o=defaultWIMFileBasedRealm. Because no match is found, the LDAP repository is searched,
starting at dc=ibm, dc=com. The user name and password match. The ObjectServer repository is
searched, starting at o=netcoolObjectServerRepository, to ensure that no duplicate names exist.
The authentication passes, and the user is logged on to the Tivoli Integrated Portal console.

8 Security
Lesson 2. Configuring LDAP authentication
Lesson 2. Configuring LDAP

authentication
What this lesson is about In this lesson, you learn how to configure the dashboard
server to use an LDAP directory. You learn how to use the
WebSphere administrative console to change the
configuration of the federated repository.
Configure the dashboard server to use an LDAP user and
group repository
V7.0
8 Security
Uempty
Installation Guide

8 Security
Configuring LDAP
You configure LDAP through the WebSphere administrative
console.
You create a base entry in the federated repository realm.
The base entry must map to a physical repository.
The physical repository must minimally include the following
information:
LDAP server host name
LDAP server port
Authorized LDAP user and password, in distinguished name format
LDAP search criteria for users and groups
Configuring LDAP
To add an LDAP repository, you must know the following information:

The LDAP server host name.
The LDAP server port number.
An authorized LDAP user name and password. The user must have authorization to retrieve
user and group information from the LDAP server.
The starting point in the LDAP directory tree to search for user and group matches.
If the repository supports management through the Tivoli Integrated Portal, modify the Entity Types
to point to the LDAP server.
V7.0
8 Security
Uempty
Starting the WebSphere administrative console
Click Settings > WebSphere Administrative Console.

Click Launch WebSphere administrative console.
The console opens a second browser window.
Starting the WebSphere administrative console
The Tivoli Integrated Portal uses the WebSphere console for security and other administrative
functions.

8 Security
Adding an LDAP repository
Click Security >

Global Security.
Click Configure to
start realm and
repository
configuration.
Adding an LDAP repository
To define an LDAP repository, click the Security > Secure configuration, applications, and
infrastructure task. Click Configure.
V7.0
8 Security
Uempty
LDAP configuration: Add base entry to realm

WebSphere realms define the scope of authentication sources.
To define the realm and create and assign an LDAP repository,
you select Add Base entry to Realm.
LDAP configuration: Add base entry to realm
To add the LDAP repository, you must first create a base entry in the WebSphere security realm.
This base entry provides the pointer to the search entry point of the LDAP server.

8 Security
Defining the LDAP base entry
A realm definition must include a physical repository.

To define the LDAP server properties, you select from the list
or select Add Repository.
Defining the LDAP base entry
LDAP servers can support separate multiple directory trees. You must complete the Distinguished
name of a base entry that uniquely identifies this set of entries within the realm field to
identify the realm in the federated repository. The Distinguished name of a base entry in this
repository field is the starting point to search for users or groups in the LDAP directory.
For this example, the repository is not yet defined. Within the General Properties section of the
Configuration form, click Add Repository. After completing the connection information, add the
base entry points for the Federated and LDAP repositories.
V7.0
8 Security
Uempty
Defining the LDAP repository
Define the LDAP directory, including the directory type, host

name, port, and an account with authority to search the directory
tree. Use the fully qualified domain name.
Defining the LDAP repository
The repository identifier is a string that WebSphere uses internally to uniquely identify the LDAP
definition. After selecting the LDAP server type, enter the host name and communication port. The
default nonsecure port is 389.
In the Security section, you must enter an administrative user on the LDAP server for the Bind
distinguished name and password. This administrator must have authority to search and modify
the LDAP directory.

8 Security
Saving configuration changes
Save your changes when prompted. Changes do not take effect

until you stop and start the dashboard server.
Saving configuration changes
When prompted to save configuration changes to the WebSphere server, click the Save link. After
completing the remainder of the configuration, you must stop and start the dashboard server.
V7.0
8 Security
Uempty
Completing the WebSphere base entry
Select the repository that you created in the previous steps.

Assign a name for the federated repository base entry by using
the X.500 distinguished name format.
Assign the LDAP repository search entry point. Use the X.500
distinguished name format.
Completing the WebSphere base entry
After you define the LDAP repository, complete the realm definition by defining the starting point for
searches of the federated and LDAP repositories. This example uses the following definitions:
Distinguished name of a base entry that uniquely identifies this set of entries within the realm:
o=tiprealm
Distinguished name of a base entry in the repository: dc=ibm, dc=com
The realm entry, o=tiprealm, is a logical designation in the federated repository. The base entry,
dc=ibm, dc=com, designates the starting point of a user name search in the physical repository.

8 Security
Repository entity types
You use entity types to define the initial realm search point
when you identify users and groups.
You also use entity types to define where and how you create,
modify, and delete users or groups in the federated repository.
You cannot create, delete, or modify users in the Jazz for
Service Management console.
Repository entity types
If you plan to create, modify, and delete LDAP users from the Tivoli Integrated Portal console, you
must change the supported entity types for the LDAP repository. The values that are entered for
Group, OrgContainer, and PersonAccount are used when updating the LDAP directory.
This example uses the following information:

Group entries are created under the ou=tbsmgroups, dc=ibm, dc=com distinguished name
entry in the LDAP directory.
OrgContainer entries are below dc=ibm, dc=com.

PersonAccount entries are below ou=tbsmusers, dc=ibm, dc=com.
V7.0
8 Security
Uempty

8 Security
Student exercises
Student exercises
V7.0
8 Security
Lesson 3. Configuring SSL authentication
Uempty
Lesson 3. Configuring SSL

authentication
What this lesson is about In this lesson, you learn how to configure the dashboard
server to use secure sockets layer communications (SSL)
when authenticating with an LDAP server. You learn how
to add an LDAP server signer certificate to the dashboard
server truststore.
Configure SSL communications between the dashboard
server and an LDAP server

8 Security

Installation Guide
V7.0
8 Security
Uempty
Configuring secure communications with an

LDAP server
Secure Sockets Layer (SSL) communications ensures
encrypted data between two software applications.
Without SSL configured, user and password information
between Tivoli Business Service Manager and LDAP is not
secure.
For a Tivoli Business Service Manager administrator,
configuring SSL with LDAP communications requires
completing the following high-level tasks:
Add the LDAP server Certificate of Authority (CA) to the Tivoli
Business Service Manager truststore.
Configure the Tivoli Business Service Manager LDAP repository to
communicate with the LDAP server SSL port.
Configuring secure communications with an LDAP server
If the LDAP repository is not configured to use Secure Sockets Layer (SSL) protocols, any user and
password information that is sent between the Tivoli Integrated Portal and an LDAP server is not
encrypted. This situation presents a security risk. To secure communications, Tivoli Business
Service Manager supports SSL protocols.
The minimum configuration to establish SSL communications with an LDAP server requires
receiving a certificate authority (CA) from the LDAP server. This certificate is then stored in the
Tivoli Integrated Portal keystores. After importing the CA, the LDAP repository definition is modified
to use SSL. This type of configuration is known as client authentication, where the Tivoli
Integrated Portal server acts as a client to LDAP.
Another type of configuration, which is known as server authentication, is also supported. With
server authentication, a Tivoli Integrated Portal CA is imported into the LDAP truststore. You then
configure the Tivoli Integrated Portal and LDAP to establish server-to-server trust before
transferring data.
CAs are self-signed or provided by a known trust authority. Self-signed certificates are inherently
less secure.

8 Security
Tivoli Integrated Portal credential stores
WebSphere security supports client (one-way) or server (two-way) secure

sockets layer (SSL) communications.
A keystore provides secure storage of the Tivoli Integrated Portal server
credentials. The Tivoli Integrated Portal server credential is used if the
LDAP server requires two-way secure communications.
A truststore provides secure storage of remote server credentials. The
LDAP server credential is used if the Tivoli Integrated Portal server requires
one-way secure communications.
To configure one-way SSL trust, add the LDAP signer certificate to the Tivoli
Integrated Portal NodeDefaultTrustStore.
Tivoli Integrated Portal credential stores
Both NodeDefaultKeyStore and NodeDefaultTrustStore are software objects that securely store
cryptographic key information. This information is stored in a standardized way so that one
computer can establish a secure trust relationship to safely encrypt communications. Importing the
LDAP CA into the truststore provides the mechanism that ensures the Tivoli Integrated Portal can
trust the LDAP server identity. If the LDAP server configuration requires trusted connections with
clients, you create a CA for the Tivoli Integrated Portal server. The Tivoli Integrated Portal server
CA is stored in the keystore. The LDAP server must import the CA into the LDAP truststore. After
the target server trust is established, all communications between LDAP and the Tivoli Integrated
Portal server are then encrypted according to the SSL protocols.
V7.0
8 Security
Uempty
Retrieving the LDAP signer certificate
Retrieve and store the LDAP server certificate in the Tivoli

Integrated Portal truststore.
Configure the truststore by clicking SSL certificate and key
management > Keystores and certificates >
NodeDefaultTrustStore.
Click Retrieve from port in the truststore configuration form.
Retrieving the LDAP signer certificate
You can use the SSL certificate and key management > Key stores and certificates task to
retrieve the LDAP certificate authority. To implement client trust with the LDAP server, import the
LDAP CA into the Tivoli Integrated Portal truststore, select the Signer certificates link. From this
form, click Retrieve from port.

8 Security
Entering LDAP certificate information
Enter the LDAP host, SSL port, and internal identification

string, and click Retrieve signer information.
Review the retrieved certificate and click OK to accept it.
Entering LDAP certificate information
After clicking Retrieve from port, you are prompted for the LDAP server configuration information,
including the server name and communication port. Enter a text string in the Alias field to uniquely
identify the LDAP server. Click Retrieve signer information to complete the CA retrieval.
V7.0
8 Security
Uempty
Configuring the Tivoli Integrated Portal server

for SSL
On the LDAP repository

configuration page, complete
these tasks:
Change the LDAP port.
Enable SSL communications.
Select the SSL configuration
method.
Configuring the Tivoli Integrated Portal server for SSL
After the LDAP certificate of authority is stored in the Tivoli Integrated Portal truststore, edit the
LDAP repository configuration to require SSL communications. Change the communication port to
the secure listening port of the LDAP server.

8 Security
V7.0
8 Security
Uempty
Student exercises
Student exercise

8 Security
Lesson 4. Managing users, groups, and authorization roles
Lesson 4. Managing users, groups, and

authorization roles
Lesson 4. Managing users, groups,

and authorization roles
What this lesson is about In this lesson, you learn how to use the Tivoli Integrated
Portal server console to create Tivoli Business Service
Manager users and groups. You learn how authorization
roles are assigned and how they control access to Tivoli
Business Service Manager objects and resources.
V7.0
8 Security
Uempty
Manage users, groups, and roles in a Tivoli Business
Service Manager deployment
Use authorization roles to control access to Tivoli
Business Service Manager 6.1.1 objects

Installation Guide

8 Security
User, group, and authorization roles overview
Users or groups are assigned authorization roles to control

access to Tivoli Business Service Manager resources.
If roles are assigned to a group, and a user is assigned to that
group, the user inherits the roles of the group.
Managing authorization with groups simplifies authorization
management.
User, group, and authorization roles overview
Authorization roles control the Tivoli Business Service Manager functions that are available to a
user. You should manage the assignment of authorization roles with groups. The organization of
groups simplifies user and group administration. You assign roles to groups according to job
function and then assign users to appropriate groups.
V7.0
8 Security
Uempty
Managing users and groups
You locate, create, or modify users or groups with the tasks in

the Users and Groups folder.
User and group administration is controlled by the Supported
Entity Types configuration.
User and group modifications are not supported with the Jazz
for Service Management console.
Managing users and groups
Tivoli Business Service Manager supports the creation of users and groups directly from the
administrative console. A WebSphere property that is called the Supported Entity Types controls
the repository that is used to modify users and groups. Jazz for Service Management does not
support direct modification of users and groups. The creation of users and groups must be
managed with the repository administration tools. You use the Jazz for Service Management
console to manage authorization roles for users and groups that are defined in a repository.
If you use federated repositories, you must assign a user to a group that is in the same repository.
For example, you cannot define a user in a file-based repository and assign that user to a group
that is defined in an LDAP or ObjectServer repository.

8 Security
Managing authorization roles

You manage authorization for a Tivoli Business Service
Manager object by assigning roles to the object and to a user
or group.
Group members inherit roles that are assigned to the group.
Roles are cumulative.
To simplify role administration, you assign appropriate roles to
groups, and add or remove users as necessary.
Managing authorization roles
You select the Users and Groups > Group Roles task to modify the roles that are assigned to a
group. Users that are assigned to a group inherit the roles that are assigned to the group. Roles are
cumulative. For example, a user is assigned to two groups, Group 1 and Group 2. Group 1 is
assigned the tbsmReadOnlyUser role. Group 2 is assigned the tbsmAdminUser role. If a Tivoli
Business Service Manager object is only available to users with the tbsmAdminUser role, the
Group 2 role takes precedence over the more restrictive Group 1 role.
V7.0
8 Security
Uempty
Assigning roles to a user or group
Search for a user or group.

Click the user or group name and
select one or more roles.
Click Save.
Assigning roles to a user or group
Click the Users and Groups > Group Roles task. Search for the name of the group. Select the
check box to the left of one or more role names and click Save.

8 Security
V7.0
8 Security
Uempty
Student exercises
Student Exercises

8 Security
Summary
following tasks:
Describe the user authentication and authorization services that are
used in Tivoli Business Service Manager
Configure the dashboard server to use an LDAP user and group
repository
Configure SSL communications between the dashboard server and an
LDAP server
Manage users, groups, and roles in a Tivoli Business Service Manager
deployment
Use authorization roles to control access to Tivoli Business Service
Manager 6.1.1 objects
Summary
9 Custom dashboards and page
management
9 Custom dashboards and page

management


9 Custom dashboards and page management
What this unit is about A new feature of Tivoli Business Service Manager 6.1.1 is
the addition of the Jazz for Service Management version
1.1 technology. Jazz for Service Management includes
visualization services that are used to create and manage
business dashboards. This unit includes an overview of
the Jazz for Service Management services and reviews
methods for creating and managing custom dashboards
with the Jazz for Service Management visualization
services. You also learn how to use authorization roles to
control user access to dashboards.
Student exercises
Jazz for Service Management Version 1.1 Administration
Guide
Jazz for Service Management Version 1.1 Users Guide
https://www.ibm.com/developerworks/servicemanageme
nt/jazzsm/index.html
Jazz for Service Management developerWorks
community
V7.0
Uempty
Objectives
tasks:
Describe the major functions of the Jazz for Service Management
visualization services
Describe how dashboard widgets access business data
Use Jazz for Service Management DASH server processes and tools
to build custom dashboards
Use Jazz for Service Management DASH server tools to manage
dashboards
Objectives

Lesson 1. Dashboard tools overview
What this lesson is about In this lesson, you learn about the services that are
provided with Jazz for Service Management version 1.1.
You learn how dashboard widgets use the registry
services and Open Services for Lifecycle Collaboration
(OSLC) data to retrieve data from an application. You also
learn how dashboard widgets are configured on a
business dashboard to provide a targeted business view.
Describe the major functions of the Jazz for Service
Management visualization services
Describe how dashboard widgets use business data
V7.0
Uempty
Guide

Jazz for Service Management components
Registry Services: Centralized data resource locator.
Visualization Services: Tools to show data from multiple

sources.
Administrative Services: Tools to automate application
management.
Reporting Services: Common reporting infrastructure.
Security Services: Authentication and single sign-on (SSO)

support.
Jazz for Service Management components
Jazz for Service Management contains five major components. The registry services provide a
centralized data resource locator database. This database contains an indexed set of pointers to
application data. The visualization services are a set of tools that are used to organize and show
data from multiple applications. The primary visualization components, called widgets, are
combined on a dashboard page to present customized data views. The administrative services
provide the means to automate application management from the Jazz for Service Management
console. The reporting services provide a common reporting infrastructure to create reports from
multiple data sources. The security services provide the authentication mechanism for user access
to application data. A major component of the security services is support for a concept that is
known as single sign-on, or SSO. With SSO, a user authenticates to an application by entering a
user name and password. If the user links to a subsequent application, the connection to the
second application console is automatically authenticated.
V7.0
Uempty
Visualization services overview
The Jazz for Service Management visualization services supports these

items:
A common widget library that is used to create custom dashboards
with content from multiple products
Interactive dashboard pages with widget event connectors
Customization by systems-integrators, administrators, users, and
application creators
User and application single sign-on (SSO) and a unified security
model
Visualization services overview
The common widget library that is provided with the Jazz for Service Management visualization
services is the core mechanism that is used to build dashboard pages. Widgets that are placed on
a dashboard page are connected with other widgets and other pages to create interactive
dashboard pages. The dashboard pages can be created, configured, and customized by any
authorized Jazz for Service Management user. WebSphere Application Server security and single
sign-on create a unified security model for dashboard user and data authentication.

Visualization Services architecture
Widgets for desktop Widgets for mobile
DASH Server
Jazz for Service

Management
JDBC
Service provider Service provider Service provider
Lotus
Tivoli Directory
Application Application
Integrator/Impact
CSV
Visualization Services architecture
This diagram shows a high-level view of the main components of the visualization services
architecture. Data applications that support Jazz for Service Management include a software
component that is known as a service provider. The service provider provides the standardized
interface between the dashboard server and the application data. The widgets on a dashboard are
configured to retrieve application data through data connections and service providers. Dashboard
pages are created for mobile and desktop clients with the same development tools.
V7.0
Uempty
Mobile dashboard considerations

Home Page Title
No images are on the login Navigation Back
page.
No taskbar is available.
Navigation icon is available
instead of taskbar.
The only views that are
available are the ones that are
selected for mobile.
Default page in default view is
used as home page.
Support is available for
Android, iPhone, and iPad.
Mobile dashboard considerations
Dashboard pages that are designed for mobile devices are viewed and used differently from
desktop dashboards. Mobile dashboards cannot contain images on the login page. To maximize
the screen space that is available for the dashboard, the taskbar is replaced with a navigation icon.
On mobile devices, you can view only the dashboard pages that are designated for mobile devices.
The default page that is configured for the default view for a user is used as the dashboard home
page. Mobile dashboards are currently supported for Android, iPhone, and iPad devices.

Mobile page navigation

Navigation on a mobile device is based on
drill down with page launches.
Clicking the Back icon closes the current
page.
Mobile page navigation
Navigation from one dashboard page to another with mobile devices is done by closing the current
page and replacing it with the selected page. Selecting the back arrow from the navigation icon
replaces the current page with the previous page contained in the browser history.
V7.0
Lesson 2. Data connections
Uempty
What this lesson is about In this lesson, you learn how to configure data
connections between the Jazz for Service Management
registry services and an application. The connections
provide a standardized method for locating and retrieving
application data.


Guide
V7.0
Uempty
Getting data for dashboards: Connections
DASH server Connections are reusable data sources

for widgets.
Connections communicate with an
application service provider.
Application service providers must be
registered with the Jazz for Service
Connection
Management registry service.
Service provider
Application
Getting data for dashboards: Connections
This diagram shows the function of a Jazz for Service Management connection object. A
connection establishes how dashboard widgets communicate with an application to retrieve data.
Jazz for Service Management connection objects can be created only with applications that include
an OSLC service provider.
Dashboard widgets are used with data from various application data sources. Widgets retrieve data
through a Jazz for Service Management tool that is known as a data connection. Data connections
are software objects that define a link between the dashboard server the service provider on the
remote application. The service provider must be registered with the Jazz for Service Management
registry services.

Creating connections
Use the Connections management widget in the Console
Settings folder.
Existing connections are managed in the console workspace.
Click the Create new remote provider icon to create a new
connection.
Creating connections
To create a data connection, you click the connections widget icon. The icon is in the Console
Settings folder in the taskbar on the left of the console. When the connections widget starts,
existing connections are listed in the console workspace. Click the Create new remote provider
icon to start the connection creation process.
V7.0
Uempty
Configuring a connection
Enter the service provider target connection information.
Click Search to see available service providers.
Select the connection authentication method.
Configuring a connection
Enter the host name of the target application, communication port, and the type of protocol that is
used by the service provider. Choose either HTTP or secure socket HTTP. The user must be
authorized to interact with the remote application. Applications can include more than one service
provider. Clicking the search icon returns a list of available service providers. You then choose how
to manage authentication credentials when a user interacts with the application through the data
connection.

Connection authentication
Configure service provider authentication in one of two ways:
Use the configured connection credentials for every dashboard user.
Use SSO:
The LTPA authentication cookie for the console user is sent with every data
provider request for authentication.
The data provider must be part of the same WebSphere Application Server
SSO domain for the LTPA credentials to be accepted.
Connection authentication
There are two ways to configure how a widget interacts with the remote application service
provider. By default, the user name and password that are entered in the connection configuration
is used for every data request with the remote application. If you select the option to use the
credentials of the user, the remote application must be configured to interact with the dashboard
server with single sign-on. Single sign-on is a standard method for passing encrypted user
authentication credentials between servers.
V7.0
Uempty
Other application integration

Tivoli Directory Integrator is used to build OSLC service
providers for non-IBM applications.
The non-IBM application data is then available for use by
dashboard widgets.
The Tivoli Directory Integrator data provider is automatically installed
with the visualization services.
DASH TDI JDBC

Files
TDI REST/SOAP
TDI connector Email
Data provider LDAP
Domino
JMX
AssemblyLine(s)
CURI
Tasks Non-IBM
CURI Maximo/Tpae
Events Applications TSRM
Styles
SAP
Columns
MQ/JMS
RelatedItems
Java API
Widget
(others or custom)
Other application Integration
Tivoli Directory Integrator, which is included with Jazz for Service Management, is used to create a
service provider for applications that do not include a service provider component. When the
application service provider is created with Tivoli Directory Integrator, data is then available for
interaction with dashboard widgets.

V7.0
Uempty
Student exercises
Student exercises

Lesson 3. Creating dashboard pages
What this lesson is about In this lesson, you learn how to use the visualization
services to create a multipage linked business
dashboard. You learn how to add and configure widgets
on a page and how to link pages with dashboard wires.
You learn how to retrieve and show business service data
from the Tivoli Business Service Manager server.
Use Jazz for Service Management DASH server
processes and tools to build custom dashboards
V7.0
Uempty
Guide

Creating a dashboard page

You have three options for opening the dashboard workspace:
1. Click the Pages widget in the Console Settings menu and click New
Page.
2. Click the plus symbol in the upper right of the

console.
3. Hover the cursor over the arrow in the console

Welcome page. Click build a page.
Creating a dashboard page
There are three methods for creating dashboard pages. The first method uses the Pages task in
the Console Settings folder. You click the Pages task and then click New Page. The second
method is to click the plus symbol, which is located in the upper right of the console. The third
method uses a link in the console Welcome page. Position the cursor over the Get started Arrow
and select build a page.
V7.0
Uempty
Page layout styles

Before building a page, you must select a page layout style.
You choose from three styles to arrange the page elements.
Fluid
Proportional
Freeform
Page layout styles
Before you add widgets to a dashboard page, you must select the page layout style. The layout
style controls how widgets and elements are added to a page. The three available layout styles are
proportional, freeform, and fluid.
The proportional layout style allows widgets to be placed anywhere on the dashboard page and
overlaid with other widgets. If the page is resized, the widgets proportionally change size to adapt to
the new page size.
The freeform layout style also allows widgets to be placed anywhere on the page and overlaid with
other widgets. However, if the page is resized, the widgets are not proportionally adjusted.
The fluid layout style is designed primarily for creating mobile dashboards. Widgets that are placed
on the page cannot be overlaid with other widgets. The widgets are automatically arranged in a tiled
pattern when added to the page.

Dashboard workspace elements
Page and
} widget
controls
} Palette
} Canvas
Click a widget in the palette and drag it to the canvas.

You can arrange widgets in freeform or framed configuration,
depending on the selected page layout type.
A grid is shown on the canvas to help you arrange widgets.
Dashboard workspace elements
You use the dashboard workspace to create dashboards. The workspace consists of three
sections. The top section contains a menu bar that you use to control page and widget functions.
The middle section contains an object palette that shows a list of available widgets. The bottom
section is the page canvas, where you place and configure the widgets. A grid is shown on the
canvas to help adjust the arrangement of the widgets.
V7.0
Uempty
Mobile widget overview

The following widgets are supported on mobile devices:
Text
Refresh timer
List
Topology
Table
Tree table
Gauges
Status gauge
Value Status gauge
Volume bar
Analog gauge
Mobile widget overview
Not all widgets are designed to work with mobile devices. To see the list of widgets that are
designed for mobile devices, click the Mobile option next to the search field above the palette. Click
Search to filter mobile-supported devices. The mobile-supported widgets are text, refresh timer, list,
topology, table, tree table, and four gauge types. The gauge widgets that are available for mobile
devices are status, value status, volume bar, and analog.

Scalar versus list widgets

Scalar widgets show data for one row of a data set
Gauges
Status gauge
Value Status gauge
Volume bar
Analog gauge
List widgets show data for multiple rows of a data set
List
Topology
Table
Tree Table
The Text and Refresh widgets do not show data from a data
set
Scalar versus list widgets
Each data widget is designed to show either scalar or list values. Scalar widgets show columns
from only one row of the retrieved data set from a data connection. Examples of scalar widgets are
the status gauge, value status gauge, volume bar, and analog gauge widgets. List widgets are
designed to show data for multiple rows that are returned in the data set. List widgets include the
list, topology, table, and tree table widgets. The text and refresh widgets are not designed to show
data from the data set. They are not scalar or list widgets.
V7.0
Uempty
Creating dashboards: Customizing widgets

Select a data set for each widget.
Configure how the data set is shown.
Creating dashboards: Customizing widgets
When you place a widget onto the dashboard canvas, you configure the widget to show data from a
data connection. Depending on the widget, the configuration fields vary. The data configuration
choices also vary depending on the source of the data set. This slide shows an example of the
configuration of an analog gauge widget. The analog gauge is a scalar widget, which is designed to
show data from a single row of a data set. Each widget includes a menu icon in the upper right of
each widget. When you click the menu icon and select the Edit menu, the configuration window
opens.

Widget customization: Selecting a data set

Search for a specific data set or show all available data sets.
The results are grouped by provider and data source.
Select a data set to continue widget configuration.
Search errors are shown at the bottom of the data set selection window.
Widget customization: Selecting a data set
The first step in configuring a widget on a dashboard page requires selecting the data to be shown
in that widget. The data that is selected is referred to as a data set. To see a list of all available data
sets from all service providers, click Search or click Show All. You can also enter filter strings in the
Search field. Then, you select a data set from the returned list.
V7.0
Uempty
Widget customization: Visualization settings

Map data set columns to widget attributes.
Configure more options if they are available (optional).
Visualization settings differ based on the widget and selected data set.
Widget customization: Visualization settings
The data that is returned in the data set includes information about the type of data in the list. You
customize how the widget shows the selected data by configuring the visualization settings. You
then select how to map the data to the available attributes in the widget. Some widgets provide
extra visualization properties that can be shown in the widget. If the data set contains multiple rows
of data, and the widget type is scalar, you create filter criteria to specify which row of data to use. If
you do not specify a filter, scalar widgets use the first row in the data set.

Connecting dashboard pages with events and

wires
Events are state change notifications that are

sent by console objects.
Events are sent to other widgets on the same page, to
another page, or to a widget on another page.
Wires are software communication connections
between widgets and pages.
Using events and wires, you configure
dashboard navigation and visualization context.
For example, clicking a widget opens another page
and changes the data that is shown in another widget.
Connecting pages with events and wires
To create interactive dashboards, you create software objects referred to as wires. Wires define
communication connections between widgets and pages. Widgets generate and respond to events
that indicate a state change in the data. For example, clicking a widget generates an event that can
be sent to another page or widget in another page. The source event includes contextual
information that is used to update a target page or widget, which is based on the supplied context.
V7.0
Uempty
Events and wires examples

3
Send Event Page Sample Page A Sample Page B
2
Any widget D E F G
1
A B C
Example with three wires

A NodeClickedOn event is wired to widget C.
A NodeClickedOn event is wired to widget D, with switchpage=true.
A NodeClickedOn event is wired to page Sample Page B, with switchpage=true.
Result of emitting event
Widget C receives NodeClickedOn event.
Sample Page A is started, D receives the NodeClickedOn event.
Sample Page B is started and is active, F and G receive the NodeClickedOn
event. Copyright IBM Corporation 2013 27
Events and wires examples
This diagram shows three examples of the effect of different types of wires. In the first example, a
wire is configured to send a NodeClickedOn event from a source widget to widget C. Widget C is on
the same dashboard page. When the source widget is clicked, widget C is updated based on the
context that is transmitted from the source. The state of widgets A and B are unchanged.
In the second example, a wire is configured between the source widget and widget D, in Sample
Page A. The wire is also configured to open and switch to Sample Page A. When the source widget
is clicked, Sample Page A is opened, with the data shown in widget D based on the context that is
sent from the source widget. Widget E on Sample Page A is unchanged.
In the third example, a wire is configured between the source widget and Sample Page B. The wire
is also configured to open and switch to Sample Page B. When the source widget is clicked,
Sample Page B is opened, with the data shown in widget F and widget G, based on the context that
is sent from the source widget.

Event transformations
Event transformations provide a tool to intercept and modify a source
event. This tool changes the event that is delivered to a target.
For example, clicking a source widget generates a NodeClickedOn event.
The target widget is a Web widget.
The Web widget requires a DisplayURL event.
An event transformation can be configured to change the NodeClickedOn event
to an equivalent DisplayURL event before deliver to the Web widget.
Transformations require customization of an XML and JavaScript file.
Source event Transformation Transformed event
Event transformations
Wires can be configured to include a transformation of the source event before delivery to the
target. For example, a NodeClickedOn event does not include information in a format that is used
by a web widget. The transformation reformats the NodeClickedOn event to a DisplayURL event.
The DisplayURL event is used by the web widget to open an HTML connection. A Jazz for Service
Management administrator must create the transformation and customization of an XML file and a
corresponding JavaScript file.
V7.0
Uempty

Student exercises
Student exercises
Perform Exercises 2, 3, and 4 for this unit.
V7.0
Lesson 4. Managing dashboards
Uempty
What this lesson is about In this lesson, you learn how to manage user access to
custom dashboards with views and custom profile
preferences. Views contain links to one or more pages.
Console preference profiles control the views that are
available to a console user.
Use Jazz for Service Management DASH server tools to
manage dashboards


Guide
V7.0
Uempty
Managing dashboards
The interaction of authorization roles that are assigned to users
and Jazz for Service Management objects control user access
Resources
Users
Widgets
Widget
Roles
Managing dashboards
Users interact with dashboard pages based on authorization roles that are assigned to the user and
assigned to the Jazz for Service Management console objects. If the user has the appropriate
authorization role, they are allowed access to the object. Access to widgets, pages, views, and
preference profiles are controlled with authorization roles. If the user does not have an appropriate
authorization role, they do not see the object or are not able to interact with the object.

Organizing dashboards with views and profiles

Views: Collections of pages
Enable view for mobile devices.
Control which pages are available for
navigation.
Console preference profiles:
Control console navigation elements.
Configure authorization and default view.
Use two console themes: IBM Design
Signature or Tivoli Dark.
Organizing dashboards with views and profiles
Dashboard pages are organized into related collections by assigning the pages to a view. If a user
connects to the Jazz for Service Management environment from a mobile device, a view must be
configured to accept mobile device connections. Console preference profiles control how the user
uses pages and views when connected to the Jazz for Service Management console. You use
console preference profiles to define a default view, which is based on an assigned authorization
role. You also use console preference profiles to select the color theme that is used in the console
connection. There are currently two available themes. The IBM design signature uses white page
backgrounds and dark text, and Tivoli Dark consists of dark page backgrounds and white text.
V7.0
Uempty
Authorization roles
Every widget, page, view, and preference profile must be assigned one or
more authorization roles.
You can create custom roles to simplify page and view management.
Access levels provide additional access control for a role.
RoleA
Desktop users
RoleA
RoleA
Mobile users RoleB

RoleB
Authorization roles
Every widget, page, view, and preference profile must be assigned one or more authorization roles.
The authorization settings that are assigned to a user control the objects that the user sees.

Creating authorization roles

Click Console Settings > Roles.
Enter a name for the role.
Assign the role to users, groups, pages, or views.
Expand a section and click the plus symbol (+) to select the
target object from a list.
Creating authorization roles
You create custom roles with the Roles task in the Console Settings folder. Provide a name for the
role and assign the role to existing users, groups, pages, or views.
To assign the role to an object, expand the appropriate section, and then click the plus icon and
select the corresponding user, group, page, or view. Select the target role object from the returned
list.
V7.0
Uempty
Managing views
You use views to define a list of folders and page links.
You create views with the Console Settings > Views task.
Mobile devices can use only views with the Enable for
Mobile option selected.
You can add pages and assign view authorization.
Managing views
Views are collections of pages. They are used to organize the pages into related collections. To
create a view, select the Views task in the Console Settings folder. Assign a name to the view. If
mobile devices use the page, select to enable the view for mobile device connections.

Automatically opening pages in a view

Expand the Pages in This View section after adding pages.
Select one or more pages to open (launch) when the view is
opened.
Each selected page opens in a tabbed window in the console.
For views with more than one page, select the top page.
Automatically opening pages in a view
To automatically open pages in a view, you expand the Pages in This View section of the form and
select the pages for the view. After assigning pages to the view, you select which pages in the view
must automatically open when the user opens the view. If there is more than one page in the view,
you can select one of the pages to be the default page that is shown when the view is opened. If the
view contains multiple pages that are set to automatically open, each page opens in tabbed window
in the console.
V7.0
Uempty
Creating console preference profiles

Use Console Preference Profiles to control navigation elements that a user
sees when logged on to the console.
Create profiles with the Settings > Console Preference Profiles task.
Assign the console theme.
Creating console preference profiles
Console preference profiles are used to control user navigation and the page color theme. To
create a console preference profile, select the Console Preference Profiles task in the Console
Settings folder. You configure the views that are available to a user.

Setting profile authorization and the default

view
Specify the default view.
Restrict profile access with authorization roles.
Setting profile authorization and the default view
The console preference profile controls the views and pages the user sees when they connect with
the console. The users that are affected by a console preference profile are controlled by assigning
a role to the console preference profile. When a user authenticates to the console, the roles that are
assigned to the user are checked against the roles that are assigned to a console preference
profile. The user is assigned the first console preference profile that matches the configured
authorization role. The views that are assigned in the console preference profile determine the
pages that are available to the user.
V7.0
Uempty

Student exercises
Student exercises
Perform Exercises 5, 6, and 7 for this unit.
V7.0
Uempty
Summary
following tasks:
Describe the major functions of the Jazz for Service Management
visualization services
Use Jazz for Service Management DASH server processes and tools
to build custom dashboards
Use Jazz for Service Management DASH server tools to manage
dashboards
Summary

10 Command line administration

438 Copyright IBM Corp. 2013

V7.0
Uempty
What this unit is about The RAD shell command interpreter provides a simple
approach to creating components in Tivoli Business
Service Manager. All data server functions available
through the graphical user interface are also available
with the command interpreter. You can use commands
with scripts to automatically update service models that
are based on dynamic data. This unit expands service
model creation with the RAD shell to create new service
instances. This unit also reviews commands to manage
customization artifacts that are used to back up and
restore deployment configurations.
Student exercises
Objectives
tasks:
Describe and use the RAD shell API features
Build and manage service models with the RAD shell API
Describe the command-line tools that are used to manage deployment
customizations
Objectives

Lesson 1. Managing services with the command line
Lesson 1. Managing services with the command

line
Lesson 1. Managing services with the

command line
What this lesson is about In this lesson, you learn how to start and use the RAD
shell command-line interface. You learn how to combine
RAD shell commands to create and configure business
services.
Build and manage service models with the RAD shell
API
V7.0
Uempty

Creating and configuring services with the

command line
RAD shell provides a set of tools for creating and managing
data server objects from the command line.
Most of the capabilities are available in the GUI.
RAD shell can automatically update service models based on
dynamic data.
RAD shell can create a service model based on external
system data.
Creating and configuring services with the command line
You can use the RAD shell to create and configure service models with a command-line prompt,
rather than a Tivoli Integrated Portal configuration page. The RAD shell provides a complete
solution to creating elements with a command line. This solution can be useful in these
circumstances:
When you build large models
When you build interfaces from another system
When you import information from another system
The RAD shell commands issue SOAP calls to the data server. The RAD shell can create and
update service instances with data not available through a database or from monitor events. An
example of such data is data from a log file.
V7.0
Uempty
Accessing RAD shell commands

To start the RAD shell command interpreter, run the following
command on the data server:
<DATA_SERVER_HOME>/tbsm/bin/rad_radshell
The RAD shell prompt is shown:
> radshell>
To get information about various commands, type this
command:
> help();
To end the RAD shell session, enter one of the following
commands:
> Ctrl-D, Ctrl-C, or exit();
Accessing RAD shell commands
To start the RAD shell command-line interpreter, run this command:

<DATA_SERVER_HOME>/tbsm/bin/rad_radshell
When the RAD shell is started, this prompt is displayed:

radshell>
Enter this command at the prompt to see the list of available commands:
help();

Partial RAD shell command list

grantObjectPrivilege
revokeObjectPrivilege
addServiceInstance
deleteServiceInstance
createTemplate
deleteTemplate
createSlaForTemplate
addRawEventAttribute
addScheduleToInstance
createRecurringTimeWindow
Partial RAD shell command list
A list of some of the commands that are available with RAD shell is shown on the slide. Detailed
information about these commands is in the Reference unit of the Tivoli Business Service
Manager 6.1.1 Administrators Guide.
V7.0
Uempty
Expanding service model creation

Use RAD shell to create and configure new service instances.
Example:
Use data from an inventory database to provide information about available
hardware.
Use a scripting language and RAD shell to automate service model creation.
Expanding service model creation
The combination of scripting languages and the RAD shell command interpreter provides a useful
tool to manipulate data from various sources. You can then use that information to create complete
service models and templates.

Example: Creating a service instance

The following command creates a new WebServer service
instance called WebServer99:
addServiceInstance(WebServer, WebServer99,
A new WebServer instance, Standard);
This instance is based on the WebServer template, and it is
assigned the Standard SLA definition.
Example: Creating a service instance
The general form of the RAD shell command to create a service instance is as follows:
addServiceInstance(templateName, instanceName,Description,slaName);
The example on the slide, is a command that creates a WebServer99 service instance. This
command tags the instance with the WebServer template. The slaName in this example is set to
Standard, but you can modify it with other SLA definitions. To create a new model, you create the
following instances for the new objects at all levels:
WebServers
WebFarms
WebApplications
V7.0
Uempty
Example: Creating an instance dependency

The first command creates a new WebFarm instance,
WebFarm3. The second command adds an instance
dependency, WebServer99.
addServiceInstance(WebFarm, WebFarm3, A new
WebFarm instance, Standard);
addServiceInstanceDependency(WebFarm3,
WebServer99);
Example: Creating an instance dependency
The following command format is used to create a parent-child service dependency:

addServiceInstanceDependency(parentInstanceName, childInstanceName);
This example creates a WebFarm instance and assigns a WebServer service instance.

V7.0
Uempty
Student exercises
Student exercises

Lesson 2. Exporting and importing deployment customizations
Lesson 2. Exporting and importing deployment

customizations
Lesson 2. Exporting and importing

deployment customizations
What this lesson is about In this lesson, you learn about the artifacts database that
is installed on the data server. The artifacts database
stores information about Tivoli Business Service Manager
customizations. The database is used to back up or
migrate customizations from one environment to another.
You also learn how to use commands to export
configuration information from a Tivoli Business Service
Manager deployment.
V7.0
Uempty
Describe the command-line tools that are used to manage
deployment customizations


Exporting and importing deployment

customizations with the command line
RAD shell provides commands to import and export entire
service model definitions.
The following export commands are available:
export
exportCSV
exportFromStartingInstance
Exported definitions are created in the $TBSM_HOME/export
directory.
Importing service definitions is done with the following
command syntax:
cat export_filename | $TBSM_HOME/bin/rad_radshell
Exporting and importing deployment customizations with the command line
You can use the RAD shell interface to save complex service configurations in a text format. You
can use this information to restore a service definition or move service definitions from one Tivoli
Business Service Manager environment to another. You can use variations of the export command
to complete several actions:
The export command sends definition information to a file called
<DATA_SERVER_HOME>/tbsm/export/export.radsh. Multiple invocations of the command
append information to this file.
The exportCSV command creates the definition information in comma-separated value (CSV)
format to the following two files:
<DATA_SERVER_HOME>/tbsm/export/radexport_instances.csv
<DATA_SERVER_HOME>/tbsm/export/radexport_dependencies.csv
The exportFromStartingInstance command generates definition information for the starting

instance and all dependent service information. The information is written to the
<DATA_SERVER_HOME>/tbsm/export/export.radsh file.
V7.0
Uempty
Customization artifacts overview

Tivoli Integrated Portal customizations are maintained in a
customization artifacts database.
The following categories of stored customization are included:
chart
customcanvas
maintenance
menuactions
sla
treetemplate
viewdefinition
The Discovery Library Toolkit also stores customization
artifacts that are related to the Service Component Repository.
Management tools use the Discovery Library Toolkit to import
and export artifacts. Copyright IBM Corporation 2013 14
Customization artifacts overview
Many customizations that are not controlled by the RAD shell API are managed from the artifacts
database. This database is maintained in the same DB2 environment that is used to store service
and template data. The artifacts are imported and exported with the Discovery Library Toolkit.

Managing customization artifacts
To manage the artifacts, you export an artifact, modify the

output file, and then import the modification.
Artifact tools are in the $TBSM_HOME/XMLtoolkit/bin directory:
listArtifact.sh
getArtifact.sh
putArtifact.sh
tbsm_export.sh
tbsm_import.sh
Managing customization artifacts
Artifacts are used as runtime values for the data server. To manage customization artifacts, you
export the artifacts, edit the exported file, and import the modifications into the database. You use
the putArtifact command to import modifications to the database. This command designates the
artifact as a customization, to differentiate artifacts that are stored as part of a standard installation.
V7.0
Uempty

Student exercises
Student exercises
Perform Exercises 2 and 3 for this unit.
V7.0
Uempty
Summary
following tasks:
Build and manage service models with the RAD shell API
Describe the command-line tools that are used to manage deployment
customizations
Summary

11 Maintenance and troubleshooting


What this unit is about Tivoli Business Service Manager uses DB2 to store
operational and historical data. In this unit, you review the
database schema that are used in Tivoli Business Service
Manager. You also learn the high-level tasks that are
required to implement backup components for the
ObjectServer, data server, and dashboard server. You
learn about the files and tools that are used to
troubleshoot Tivoli Business Service Manager operations.
Finally, you learn how to tune the Java virtual machine
settings for the dashboard server.
Student exercises
Installation Guide
GI11-8057-09 Business Service Manager 6.1.1
Troubleshooting Guide
http://www.ibm.com/developerworks/servicemanagemen
t/bsm/tbsm/index.html
DeveloperWorks-Tivoli Business Service Manager
V7.0
Uempty
Objectives
tasks:
Describe the backup and restoration principles for the DB2 data server
database
Describe the Tivoli Business Service Manager server failover
configuration
Describe the support resources that are available to troubleshoot
deployment problems
Describe the Tivoli Business Service Manager application server log
files that are used to troubleshoot server problems
Tune the Tivoli Integrated Portal server Java Virtual Machine
parameters
Objectives

Lesson 1. Deployment administration
What this lesson is about In this lesson, you learn how to do the high-level tasks that
are required to maintain the Tivoli Business Service
Manager DB2 database. You also learn the high-level
tasks that are required to provide redundancy for the
major components of a Tivoli Business Service Manager
deployment.
Describe the backup and restoration principles for the
DB2 data server database
Describe the Tivoli Business Service Manager server
failover configuration
V7.0
Uempty

Data server database management

DB2 supports the operational and historical data services for
the data and dashboard servers.
The following schemas are used by Tivoli Business Service
Manager:
TBSMBASE: Contains template, service, and rule data.
TBSMSCR: Contains data that is related to the Service Component Repository.
TBSMUDF: Has user-defined functions that are specific to Tivoli Business Service
Manager.
TBSMS: Has one or more schemas to stage data during SCR imports.
TBSMCONFIG: Contains customization artifacts and configuration data.
TBSMHISTORY: Contains history metrics used by the Time Window Analyzer.
TWAMARKER: Contains marker data used by the Time Window Analyzer.
EVENTRULES: Contains rule data used by the Tivoli Impact Event Isolation and
Correlation service.
TBSMDEMO: Includes sample data for product education material.
Data server database management
Tivoli Business Service Manager uses DB2 to support management and storage of operational
service, template, historical, and customization data. Backing up all data regularly is critical.
V7.0
Uempty
Data server database backup and restore

Back up all Tivoli Business Service Manager databases and
instances regularly.
Monitor the table usage in the TBSMBASE and TBSMSCR
schemas for table fragmentation or periodically reorganize
them by using the DB2 REORG function.
Review the DB2 documentation in the IBM DB2 Database for
Linux, UNIX, and Windows information center on the Internet.
Use documented procedures for database and instance
restoration.
If possible, implement High Availability Disaster Recovery
(HADR) for critical production deployments. HADR provides
redundancy if a primary server failure occurs.
Data server database backup and restore
For a production environment, follow documented backup and restoration guidelines. DB2 supports
high availability tools for critical databases.

Tivoli Business Service Manager failover

Tivoli Business Service Manager supports redundancy and
automatic failover of all components.
The following components can be configured to support
failover:
Dashboard server, with optional load balancing
Data server
Netcool/OMNIbus ObjectServer
You can optionally configure the following components for
failover:
EIF probe
Monitor probes
Tivoli Business Service Manager failover
You can implement failover for Tivoli Business Service Manager by running a primary and backup
data server in parallel. If the primary server stops, the backup server resumes as the primary
server. Additionally, you can configure the dashboard server to operate with multiple dashboard
servers for redundancy and load balancing.
V7.0
Uempty
Failover logical configuration

These data server
components support
redundancy:
DB2 server
Data server
ObjectServer
The dashboard server
supports redundancy and
load balancing.
Load balancing requires
additional components.
Failover logical configuration
Shown here is a logical diagram for a Tivoli Business Service Manager 6.1 failover configuration.
After you configure it, primary data server failover to the backup data server is automatic. Also
shown in this diagram is redundancy for the ObjectServer. Any probes that provide monitoring
events to the ObjectServer can also be configured to send events to a backup ObjectServer.

DB2 failover considerations

DB2 failover is implemented independently of other component
redundancy.
If other components are configured for redundancy, they must
all initially use the primary DB2 server.
If only DB2 redundancy is implemented, you configure the data
server to fail over to the backup.
DB2 failover considerations
V7.0
Uempty
ObjectServer failover considerations

You must configure a bidirectional communication gateway
between the primary and backup ObjectServers.
If you use ObjectServer authentication, you must replicate the
security information to the backup.
You can implement redundancy independently of other
components.
ObjectServer failover considerations
You can configure redundancy for the Netcool/OMNIbus ObjectServer independently of

redundancy for other Tivoli Business Service Manager components. ObjectServer redundancy
requires an ObjectServer gateway between the primary and backup ObjectServers.

Data server failover considerations

The designated backup data server must be installed as a
backup.
If JVM out-of-memory issues are possible, configure the JVM to
start a shutdown script when an out-of-memory event is
received.
Data server failover considerations
The backup data server must be installed as a backup server. You cannot convert a primary data
server installation to be used as a backup data server.
V7.0
Uempty
Dashboard server failover considerations

The dashboard server supports redundancy with or without
load balancing.
Configuration is independent of the data server and
ObjectServer failover.
Dashboard server redundancy requires a common
authentication repository.
Dashboard server failover considerations
Redundant dashboard servers can be installed independently of other components. Dashboard

servers can be configured to be used with a load balancer. You must have a common user
repository, such as LDAP, to implement dashboard server redundancy. You must also install and
configure a common DB2 database. The database is used to coordinate server customizations.

Dashboard server load balancing

Load balancing extends the client connection capacity.
Each dashboard server must have server-to-server trust
configured.
Load balancing requires the following elements:
A common WebSphere cell name.
A common database to coordinate changes in dashboard server
objects; for example, deleting or adding a page or view.
A network dispatcher, such as the IBM HTTP server.
Dashboard server load balancing
You can configure two or more dashboard servers to provide redundancy. The addition of a
specially configured instance of DB2 9.7 and IBM HTTP Server can provide automatic load
balancing. All dashboard servers must exchange Certificates of Authority to implement
server-to-server trust for security.
The dashboard servers must efficiently switch to a backup data server if a failure occurs. Both data
servers must use identical keystores. The default internal file-based user and group repository is
local to each dashboard server. The internal repository cannot be used in a failover configuration.
You use the IBM HTTP Server to provide a load-balancing front end to multiple dashboard servers.
You must configure all participating dashboard servers for trust and connection information. The
HTTP Server plug-in that is provided with the Tivoli Business Service Manager 6.1 installation
media provides the load-balancing software.
V7.0
Uempty
Failover implementation tasks

Complete the following tasks to configure failover:
Install primary and backup components.
Stop primary and backup servers.
Prepare a configuration file with the fo_config utility.
Configure ObjectServer communications for failover.
Configure the data and dashboard servers with the fo_config utility.
Start all servers.
Verify the failover configuration.
Failover implementation tasks
You must configure the data server for failover during installation. The installation program prompts
you to choose whether to configure the server as part of a failover scheme. The primary and
backup can be installed separately, but you must initially configure them during installation. The
database administrative user name and password must be identical for both the primary and
backup servers.
To configure the primary server, provide this information when prompted:

Name or IP address of the backup server host.
Control port (RMI port) of the backup server. This port must match the control port that is
configured on the backup server.
Database port of backup server. This port must match the port that is configured on the backup
server.
To configure the backup server, provide this information when prompted:

Name or IP address of the primary server host.

Control port (RMI port) of the primary server. This port must match the control port that is
configured on the primary server.
Database port of the primary server. This port must match the database port that is configured
on the primary server.
The failover configuration file automates the final setup of your failover environment. Record the
configuration information for each server in your failover environment. Then, use the file with the
fo_config command to complete failover setup. To create a sample configuration file that lists all
required settings, run fo_config with no options and redirect the output to a file, like the following
one:
$TBSM_HOME/bin/fo_config > failoverconfig.txt
V7.0
Uempty
Starting the failover servers

Start the failover components in the following order:
Primary ObjectServer
Backup ObjectServer
Backup OMNIbus gateway
Primary data server
Backup data server
One or more dashboard servers
Starting the failover servers
When configuration data or the service state is changed, changes must be replicated in the
database and critical XML files of the primary and backup servers. When you start the servers for
the first time, you must start the primary data server first. When the backup data server starts, it
checks to see whether the primary data server is started. The backup data server quits the start
process if the primary server is not started. When the primary server starts, it sends a message that
the backup must be started so that the primary can complete its own startup. When the backup
starts, it then directs synchronizing of databases with the primary server.
When synchronization is complete, the backup instructs the primary to enter operational mode. The
primary server then loads its configuration, processes, and events that occurred offline. It begins
processing in real time. When the primary server starts real-time processing, the backup server
finishes its startup and goes into standby mode.
If both servers are running and the acting primary server stops, the backup detects this event. The
backup server then enters primary mode. The backup server loads its state from the database,
starts all services, and begins real-time processing.

Lesson 2. Troubleshooting and support resources
Lesson 2. Troubleshooting and support

resources
Lesson 2. Troubleshooting and

support resources
What this lesson is about In this lesson, you learn about different support tools that
are available to troubleshoot Tivoli Business Service
Manager problems. Some tools provide general
reference information, and some tools provide analysis of
your deployment. You also learn which log files are
produced by the major Tivoli Business Service Manager
components.
V7.0
Uempty
Describe the support resources that are available to
troubleshoot deployment problems
Describe the Tivoli Business Service Manager
application server log files that are used to
troubleshoot server problems


Troubleshooting tools
All Tivoli Business Service Manager components generate log
files. These files are essential for investigating and analyzing
problems.
In addition to log file review, several software tools are
available:
IBM Support Assistant
Tivoli Business Service Manager Information Center
Tivoli Business Service Manager wiki
IBM developerWorks
Tivoli software user communities
Troubleshooting tools
System logs for key areas of the software track operational aspects of Tivoli Business Service
Manager 6.1. Consult these files when troubleshooting a problem with system operation.
V7.0
Uempty
Audit logging
Audit logs provide records of service configuration changes,

including the startup and shutdown of the data server.
You use the audit logs to assist with problem analysis.
You use the console to review audit log data.
Audit logging
Audit logging is enabled by default. This data is useful for generating change reports and locating
system problems. The data is stored in the DB2 database.

Log file locations

Data server and Impact policy log files:
$TBSM_HOME/logs
Data server embedded WebSphere log files:
$TIP_HOME/profiles/TBSMProfile/logs/server1
Tivoli Integrated Portal server log files:
$TIP_HOME/profiles/TIPProfile/logs/server1
OMNIbus log file:
$OMNIHOME/log
Discovery Library Toolkit:
$TBSM_HOME/XMLtoolkit/log
EIF probe:
$OMNIHOME/log/tivoli_eif.log
Log file locations
Log files that are related to the data server operation are in these directories:
$TIP_HOME/profiles/TBSMProfile/logs/tbsm
$TIP_HOME/profiles/TBSMProfile/logs/server1
Log files that are related to the Tivoli Integrated Portal, or dashboard, server operation are in this
directory:
$TIP_HOME/profiles/TIPProfile/logs/server1
More component log files are in these directories:

Netcool/OMNIbus: $OMNIHOME/log
Discovery Library Toolkit: $TBSM_HOME/XMLtoolkit/log
EIF probe: $OMNIHOME/log/tivoli_eif.log
V7.0
Uempty
Setting the data server log detail level

Two levels of logging detail are available:
Normal
Detailed
To increase the log level from Normal to Detailed, you use
these steps:
1. Edit the $TBSM_HOME/etc/impact.sla.verbose file.
2. Add the following line to the file:
impact.sla.verbose=true
3. Restart the data server.
Verbose log generation impacts data server performance. Set
the parameter to False after troubleshooting the problem.
Setting the data server log detail level
For any problem under investigation, the log files might not contain sufficient information to pinpoint
the problem. You can set the logging detail to contain increased logging information.
This screen capture shows the procedure for increasing the log level from Normal to Detailed.
Increase this level only during the troubleshooting phase of problem resolution. After the problem is
resolved, return the logging level detail to Normal to reduce the load on the server.

Enabling Impact policy logging

Edit the following file:
$TBSM_HOME/etc/TBSM_policylogger.props
Set the following parameter as shown:
impact.policylogger.logtofile=true
Restart the data server.
Note: Always disable the policy log after you finish the troubleshooting.
Enabling Impact policy logging
When you troubleshoot Impact policies that are related to Tivoli Business Service Manager 4.2.1,
you must increase the logging detail specifically for Impact policies. The screen capture shows the
procedure. You must disable the additional log information when the problem is identified.
V7.0
Uempty
Setting the dashboard server logging level
Use the Troubleshooting > Logs and

Trace task in the WebSphere
administrative console.
Click server1 to configure.
Setting the dashboard server logging level
Configure the Tivoli Integrated Portal logs with the administrative console. Click the
Troubleshooting > Logs and Trace task. Click server1 to configure trace and message log detail.

Setting the change log detail levels
Click Change Log Detail Levels.

Click the Runtime tab for a list of components, packages, and
groups that are currently registered on the application server.
Available log levels are Off, Fatal, Severe, Warning, Audit, Info,
Config, and Detail.
If tracing is enabled, a trace level of Fine, Finer, or Finest is set.
Setting the change log detail levels
To set the change log detail levels, you use these steps:
1. Click Change Log Detail Levels.
2. Click the Runtime tab.
3. Expand the tree of components under All Components.
V7.0
Uempty
Selecting log and trace levels

Right-click a
component or group.
Select the log or trace
level.
Enabling tracing
requires a server
restart.
Save the runtime
changes to the
configuration to retain
settings across server
restart.
Setting log and trace levels
For each of the elements that require a change in the log level, complete the following tasks:
1. Right-click the name of the element.
2. Click Message and Trace Levels and choose the required minimum severity level to write to
the log files.
3. Click OK.

IBM developerWorks
The IBM developerWorks website provides access to

application development resources and communities
You can participate in public beta programs.
You must have an IBM user ID.
http://www.ibm.com/developerworks/
IBM developerWorks
To use some of the tools in IBM developerWorks, use the following options:
Click Business service management in the Tivoli Solutions section to review solution white
papers.
Click Submit an article or idea in the Community section to share a solution, white papers, or
other ideas.
V7.0
Lesson 3. Tuning the dashboard server
Uempty
Lesson 3. Tuning the dashboard

server
What this lesson is about In this lesson, you learn the procedure to test and
configure the Java Virtual Machine garbage heap
parameters. You learn the impact of the memory
configuration on server performance.
Tune the Tivoli Integrated Portal server Java Virtual
Machine parameters


Server tuning tools

The IBM Support Assistant is a software client workbench that
provides troubleshooting and problem tracking tools.
The IBM Support Assistant is enhanced by installing plug-in
modules for one or more IBM products.
Several tools are available to use to tune your Tivoli Business
Service Manager components.
Server tuning tools
The IBM Support Assistant (ISA) provides a software framework to support troubleshooting multiple
IBM software products. Application-specific plug-in modules are designed to gather log and
operational data and bundle the information in a format that can be electronically submitted to IBM
Support. Through the Internet, the ISA provides links to product and support data.
V7.0
Uempty
IBM Support Assistant functions
Search for product

information.
Use plug-in analysis
tools to troubleshoot
problems.
Create, submit, and
track problem
submissions with
technical support.
IBM Support Assistant functions
The ISA client provides three major functions to support troubleshooting software problems:
Find Information: Provides a centralized way to search the Internet for product information and
training.
Analyze Problem: Provides several tools to automate data collection and analysis.
Collect and Send Data: Provides tools to gather system data and automate the creation of an
electronic service request with IBM Support. Tools are also provided to track and update any
submitted electronic service request.

Installing IBM Support Assistant add-ons

To install the add-ons, start
the workbench:
<Install_Dir>/rcp/rcplauncher
Install add-ons:
Click Update > Find new >
Product Add-ons.
Expand the product software
list.
Select one or more products
and follow the installation
wizard instructions.
Add-on search and
installation requires Internet
connectivity.
Installing IBM Support Assistant add-ons
After installing the workbench client, enter this command to start:

<ISA_Workbench_Installation_Dir>/rcp/rcplauncher
After the client is started, click Update > Find new > Product Add-ons to see a list of available
product plug-in modules. If provided with the plug-ins, you might also be prompted to select one or
more analysis tools. After you select the products, complete the installation wizard to finish the
installation.
V7.0
Uempty
Java virtual machine overview

The data server and dashboard servers each run in Java
Virtual Machines (JVM) in WebSphere.
The JVM uses a portion of memory to support programs and
store variables and runtime data. The memory storage area is
called the garbage heap, or just heap.
To optimize programs in the JVM, the heap is periodically
cleared of unused memory space. This process is called
garbage collection.
Each JVM includes two operational parameters that directly
effect the garbage collection process:
initialHeapSize: The initial memory assigned to the JVM.
maximumHeapSize: The maximum memory available to the JVM.
Java virtual machine overview
The data and dashboard servers use the Java virtual machine (JVM) environment in the
WebSphere Application Server. Tuning is critical to server performance. Too little memory that is
allocated to JVM garbage collection can cause application failure. Too much memory wastes
system resources and reduces performance.

Performance effects of the JVM heap size

All data server or dashboard operations are stopped during
JVM garbage collection.
The general operating constraints on JVM heap size are as
follows:
Less memory causes more frequent garbage collections.
More memory reduces the garbage collection frequency, but increases
the collection duration.
Setting equivalent initialHeapSize and maximumHeapSize values can
increase performance, but at the cost of reduced application startup
time.
The performance tuning process tries to find an optimal
balance between these issues.
Performance effects of the JVM heap size
JVM tuning requires controlled trials with different initialHeapSize and maximumHeapSize values
for the server JVM. Analysis of the garbage collection log files is required to determine the optimal
configuration.
V7.0
Uempty
Tuning the Tivoli Integrated Portal server JVM
You can use the following method for evaluating the tuning configuration:
Turn on verbose garbage collection for the JVM.
Use a tool to create a repeatable, representative workload on the server.
Evaluate the log data to find the optimal operating values.
Use the IBM Support Assistant diagnostic tools.
Tuning the Tivoli Integrated Portal server JVM
The IBM Support Assistant provides several tools for analyzing general log files and JVM log files.

Tracking JVM garbage collection

Turn on verbose garbage collection logging for the Tivoli
Integrated Portal server. Shut down the server.
Edit the server.xml file (always back up first), in the following
directory:
$TIP_HOME/profiles/TIPProfile/config/cells/TIPCell/nodes/TIPNode/serv
ers/server1
Garbage collection logging is controlled with the
verboseModeGarbageCollection attribute in the <jvmEntries>
element.
The default initialHeapSize was set to 512 (MB) and the
maximumHeapSize was set to 1024 (MB).
Log data is in the following file:
$TIP_HOME/profiles/TIPProfile/logs/server1/native_stderr.log
Tracking JVM garbage collection
The server must be configured to generate JVM garbage collection logs for analysis. Setting the
initialHeapSize and maximumHeapSize to the same values is more efficient for testing.
V7.0
Uempty
Evaluating the JVM garbage collection log
You can use the IBM Support Assistant tool to see multiple
views of the garbage collection log data.
The summary data indicates relatively short, but frequent,
garbage collection cycles.
Evaluating the JVM garbage collection log
The tools that are provided with the IBM Support Assistant workbench provide graphical and
tabular analysis tools. This screen image shows a graphical view of the heap size versus the
amount that is used before and after garbage collection.

Selecting optimal heap size values

Use a simulation tool, such as IBM Rational Performance
Tester.
Evaluate the effects of increasing and decreasing the heap
size.
Find a point where adding memory decreases the number of
collection cycles, but increases the collection duration.
Repeat the tuning process, if the operating environment
changes significantly.
Selecting optimal heap size values
To create consistent tests, you should use a tool that can consistently simulate a server workload
that represents typical server load for your environment. To test the load, run tests with default
values, increase and decrease operational values, and evaluate the effects on server performance.
V7.0
Uempty

Student exercises
Student exercises
V7.0
Uempty
Summary
Now that you have finished this unit, you can perform the
following tasks:
Describe the backup and restoration principles for the DB2 data server
database
Describe the Tivoli Business Service Manager server failover
configuration
Describe the support resources that are available to troubleshoot
deployment problems
Describe the Tivoli Business Service Manager application server log
files that are used to troubleshoot server problems
Tune the Tivoli Integrated Portal server Java Virtual Machine
parameters
Summary

12 Single sign-on and application
integration
12 Single sign-on and application

integration


12 Single sign-on and application integration
What this unit is about This unit describes the major tasks that are involved in
configuring Tivoli Business Service Manager to support
single sign-on. You also learn how to configure and use
launch-in-context for supported Tivoli Business Service
Manager applications.
Student exercises
http://pic.dhe.ibm.com/infocenter/tivihelp/v15r1/index.jsp
?topic=/com.ibm.tip.doc/ttip_install_sso.html
Configuring Single Sign-on for Tivoli Integrated Portal 2.2
http://www.ibmsystemsmag.com/ibmi/administrator/secu
rity/A-Single-Sign-On-Primer/
A Single Sign-on Primer
V7.0
Uempty
Objectives
tasks:
Describe the major tasks involved in configuring Tivoli Business
Service Manager to support single sign-on (SSO)
Describe how the federated repository in the dashboard server
supports user and group authentication
Describe how launch-in-context (LIC) is used to connect to
applications that support SSO
Configure the dashboard server to participate in an SSO domain
Objectives

Lesson 1. Managing single sign-on
What this lesson is about In this lesson, you learn the technical principles of single
sign-on security between applications. You learn how to
configure single sign-on in the dashboard server. You also
learn how launch-in-context is implemented from one
application to another.
V7.0
Uempty
Describe the major tasks that are involved in
configuring Tivoli Business Service Manager to
support single sign-on (SSO)
Describe how the federated repository in the
dashboard server supports user and group
authentication
Describe how launch-in-context (LIC) is used to
connect to applications that support SSO
Configure the dashboard server to participate in an
SSO domain

Installation Guide
Jazz for Service Management Version 1.1 Configuration
Guide

Single sign-on overview

Production applications generally require manual user
authentication.
Single sign-on (SSO) requires a single manual authentication.
Subsequent application authentication is automatic and
transparent.
When a user logs on, an authentication token is generated and
stored as a browser cookie.
The authentication token is valid for all supported connections
for a time period that is configured at each server.
Single sign-on overview
Single sign-on supports a mechanism for automatic authentication to a second application.

Applications that support lightweight third-party authentication (LTPA) tokens can be integrated with
SSO.
V7.0
Uempty
SSO logical diagram and operation

SSO application 1
4
2
LTPA token is
generated and SSO application 2
1 stored in user
browser.
LTPA token
LTPA token is
User logs on to https://localhost:16311/ibm/console evaluated. If
Tivoli Business valid, user is
Service Manager automatically
3 LTPA token
console. authenticated.
1. A user logs on to SSO Application 1 after entering a user ID and

password.
2. An LTPA token is generated on the SSO Application 1 server and stored
as a cookie in the user browser.
3. The user uses LIC from SSO Application 1 to SSO Application 2.
4. The authentication token is sent and processed on SSO Application 2,
automatically authenticating the user on the second application.
SSO logical diagram and operation
This diagram shows a high-level view of the SSO process. A user authenticates to the first
application by supplying a user name and password. An LTPA authentication token is encrypted
and stored as a cookie in the user browser. A second console connection request passes the token
to the second application. The token is decrypted, and the user is authenticated without manually
providing the user name and password.

SSO configuration tasks

Complete the following tasks to set up Tivoli Business Service
Manager for SSO:
Configure a central LDAP repository to be used by all SSO-enabled
applications.
All application servers must be in the same domain or subdomain; for example,
serverA.tivoli.edu and serverB.tivlabs.tivoli.edu.
Configure all applications to support SSO.
Generate SSO software keys for each server and import all keys into
all participating servers.
Verify that all application web consoles are configured to support SSO.
Log in to the first application. Use launch-in-context (LIC) to connect to
a second application without requiring a second authentication.
SSO configuration tasks
This slide shows the tasks that must be completed to configure SSO for Tivoli Business Service
Manager. All applications must share a common user and group repository, such as an LDAP
server.
V7.0
Uempty
Setting the SSO scope
Select the WebSphere Security >

Global Security page.
Click Web security > single sign-
on (SSO).
Enable SSO and set the domain
name to determine the scope of
the SSO environment.
Setting the SSO scope
SSO is configured with the WebSphere administration console. First, you click the Security >
Global Security task in the console. Then, you click the Web security > Single sign-on (SSO)
link to enable and configure the SSO IP domain scope. Only server connections in the same IP
domain can use SSO.

Importing and exporting SSO software keys
Every application server must import a common software key.

Any server in the SSO domain can generate the key.
You select the authentication mechanisms and expiration link
in the Authentication section of the Security > Global Security
page.
The password is used to verify the key when the key is
imported by another server.
Importing and exporting SSO software keys
Each participating SSO application must generate and share a server key. The key is used to
securely decrypt a user LTPA token.
V7.0
Uempty
Web console considerations
You must configure your browser to accept and store cookies.

Tivoli Integrated Portal and Jazz for Service Management are
installed with SSO enabled.
No domain scope is configured.
Web console considerations
When a user completes a console connection, both console sessions are validated with the LTPA
token. Logging off the second connection invalidates the initial console connection. The user is
required to authenticate to the initial console.

Configuring launch-in-context
Right-click a service instance to see a list of context menus .
The LIC menus depend on the properties that are assigned to
the service instance.
For example, service instances that are created with IBM Tivoli
Monitoring DLA include the following service parameters:
IBM_Tivoli_Monitoring_Services_sourceContactInfo
IBM_Tivoli_Monitoring_Service_sourceToken
Configuring launch-in-context
Right-click action menus are configured for several service objects in Tivoli Business Service
Manager. Information that is supplied in the service instance configuration is used to connect to
another application console. The connection is made with the context information in the service
object.
V7.0
Uempty
Using launch-in-context with SSO

Select Launch to > Show Managed System (TEP) and open the
Tivoli Monitoring console without requiring user interaction.
Using launch-in-context with SSO
This screen image shows a launch menu that is available with a service instance, which is created
with the Discovery Library Toolkit. The remote console and service instance information are passed
to the application with service instance context information.

V7.0
Uempty
Student exercises
Student exercises

Summary
Now that you have finished this unit, you can perform the
following tasks:
Describe the major tasks involved in configuring Tivoli Business
Service Manager to support single sign-on (SSO)
Describe how the federated repository in the dashboard server
supports user and group authentication
Describe how launch-in-context (LIC) is used to connect to
applications that support SSO
Configure the dashboard server to participate in an SSO domain
Summary
Back pa
Authorized
Training
ibm.com/training

Printed in Ireland
CT4QDEN
CT4QDEN

Tm3371 Stud

Caricato da

Informazioni sul documento

Copyright

Formati disponibili

Condividi questo documento

Condividi o incorpora il documento

Opzioni di condivisione

Hai trovato utile questo documento?

Questo contenuto è inappropriato?

Copyright:

Formati disponibili

Tm3371 Stud

Caricato da

Copyright:

Formati disponibili

IBM Tivoli Business Service

IBM Training Manager 6.1.1 for

Cloud & Smarter Infrastructure

Copyright IBM Corp. 2013. All Rights Reserved.

About this course . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . xv

1 Introduction to IBM Tivoli Business Service Manager 6.1.1. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1

2 Service model basics . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 28

Copyright IBM Corp. 2013 Student Notebook iii

Uempty Student exercises . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .89

3 Expanding service model functions . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 91

Copyright IBM Corp. 2013 Student Notebook v

Aggregation dependency rules . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 140

4 Service level agreements. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 157

Uempty Maintenance schedules . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .191

5 Data fetchers. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 199

6 External Service Dependency Adapter rules . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 235

Copyright IBM Corp. 2013 Student Notebook vii

When to use ESDA rules . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 240

7 Automatic service model creation . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 278

Uempty Viewing event automatic population rule operation . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .290

Copyright IBM Corp. 2013 Student Notebook ix

Student exercises . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 341

9 Custom dashboards and page management . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 391

Uempty Lesson 1. Dashboard tools overview . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 394

10 Command line administration . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 438

Copyright IBM Corp. 2013 Student Notebook xi

Example: Creating a service instance . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 446

11 Maintenance and troubleshooting . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 459

Uempty Student exercises . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .498

12 Single sign-on and application integration . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 501

Copyright IBM Corp. 2013 Student Notebook xiii

IBM Tivoli Business Service Manager

Copyright IBM Corporation 2013

Copyright IBM Corp. 2013 xv

This course is a five-day instructor-led course. The course is taught

About the student

Uempty Working knowledge of, or experience with, Netcool/OMNIbus event manager

General knowledge of database and SQL language concepts

Copyright IBM Corp. 2013 Student Notebook xvii

Learning objectives (continued)

There are no student exercises for this unit.

2. Service model basics

3. Expanding service model functions

4. Service level agreements

Copyright IBM Corp. 2013 Student Notebook xix

6. External Service Dependency Adapter rules

7. Automatic service model creation

9. Custom dashboards and page management

10. Command line administration

11. Maintenance and troubleshooting

Copyright IBM Corp. 2013 Student Notebook xxi

12. Single sign-on and application integration

1 Introduction to IBM Tivoli Business

Copyright IBM Corporation 2013

Copyright IBM Corp. 2013 1

References SC23-6040-09 Business Service Manager 6.1.1

Copyright IBM Corporation 2013 2

Lesson 1. Business service management

Lesson 1. Business service

Copyright IBM Corporation 2013

Copyright IBM Corp. 2013 Student Notebook 3

References GI11-8056-09 Business Service Manager Version 6.1.1

Business service management definitions

Copyright IBM Corporation 2013 4