IBM Tivoli Business Systems Manager V3.1 Advanced Implementation Topics Sg246770

Front cover
IBM Tivoli Business Systems Manager V3.1

Advanced Implementation Topics
Large-scale implementation discussion and experiences Advanced integration and implementation scenarios Extensive samples on business system building
Budi Darmawan Wayne Doughty Michael Jobe Timothy Lam
ibm.com/redbooks
International Technical Support Organization IBM Tivoli Business Systems Manager V3.1 Advanced Implementation Topics October 2005
SG24-6770-00
Note: Before using this information and the product it supports, read the information in Notices on page vii.
First Edition (October 2005) This edition applies to Version 3, Release 1 of IBM Tivoli Business Systems Manager (product number 5724-C51).
Copyright International Business Machines Corporation 2005. All rights reserved. Note to U.S. Government Users Restricted Rights -- Use, duplication or disclosure restricted by GSA ADP Schedule Contract with IBM Corp.
Contents
Notices . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . vii Trademarks . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . viii Preface . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . ix The team that wrote this redbook. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . x Become a published author . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . xi Comments welcome. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . xi Chapter 1. Business Service Management with IBM Tivoli Business Systems Manager . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1 1.1 Business Service Management. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 2 1.1.1 Concepts . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 2 1.1.2 IT Infrastructure Library (ITIL) . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 3 1.1.3 Business Service Management solution with Tivoli . . . . . . . . . . . . . . 4 1.2 IBM Tivoli Business Systems Manager overview . . . . . . . . . . . . . . . . . . . . 5 1.2.1 Objects and resources . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 5 1.2.2 Components and interaction . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 8 1.2.3 User interface . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 10 1.3 Discussion scope . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 12 1.4 Lab environment . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 13 Chapter 2. Implementation process methodology overview. . . . . . . . . . . 15 2.1 Implementation methodology . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 16 2.2 Deployment and planning considerations . . . . . . . . . . . . . . . . . . . . . . . . . 16 2.2.1 IBM Tivoli Business Systems Manager servers and connectivity . . . 16 2.2.2 Requirement gathering and solution design . . . . . . . . . . . . . . . . . . . 18 2.2.3 Solution design session . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 23 2.3 Installing IBM Tivoli Business Systems Manager . . . . . . . . . . . . . . . . . . . 26 2.3.1 Software installation . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 26 2.3.2 Event enablement interface . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 28 2.3.3 Common Listener interface . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 31 2.3.4 Upgrading or migrating from previous releases . . . . . . . . . . . . . . . . 33 2.3.5 Uninstalling IBM Tivoli Business Systems Manager . . . . . . . . . . . . . 33 2.4 Defining business systems . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 34 2.4.1 Automated business system processing overview . . . . . . . . . . . . . . 35 2.4.2 XML processing overview . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 36 Chapter 3. Building business systems: design, concepts and implementation . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 37
Copyright IBM Corp. 2005. All rights reserved.
iii
3.1 Business systems design methodology . . . . . . . . . . . . . . . . . . . . . . . . . . 38 3.1.1 Terminology and definitions . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 38 3.1.2 Methods for creating business systems . . . . . . . . . . . . . . . . . . . . . . 38 3.1.3 Important considerations. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 39 3.2 Piggybank, Inc. background . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 40 3.2.1 Data centers . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 40 3.2.2 Piggybank resources. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 41 3.2.3 Piggybank applications . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 42 3.2.4 Console users . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 43 3.2.5 Monitoring environment. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 44 3.3 Mapping enterprise to business system . . . . . . . . . . . . . . . . . . . . . . . . . . 44 3.4 Using Automated Business System . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 46 3.4.1 Before defining business system . . . . . . . . . . . . . . . . . . . . . . . . . . . 47 3.4.2 Designing Piggybank business system folders . . . . . . . . . . . . . . . . . 48 3.4.3 Defining Automated Business System configuration . . . . . . . . . . . . 52 3.4.4 Loading the ABS configuration file . . . . . . . . . . . . . . . . . . . . . . . . . . 59 3.4.5 More about functions. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 62 3.5 XML interface for business system . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 67 3.5.1 XML interface . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 68 3.5.2 Object structure . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 69 3.5.3 Defining XML file for business system . . . . . . . . . . . . . . . . . . . . . . . 71 3.5.4 Running and loading XML . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 79 Chapter 4. Presenting and using executive services and executive view 83 4.1 Executive view assignment considerations . . . . . . . . . . . . . . . . . . . . . . . . 84 4.2 Working with executive view definition . . . . . . . . . . . . . . . . . . . . . . . . . . . 86 4.2.1 Java console dialog. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 87 4.2.2 Using Command Line Interface. . . . . . . . . . . . . . . . . . . . . . . . . . . . . 88 4.2.3 Using business system creation program . . . . . . . . . . . . . . . . . . . . . 89 4.3 Developing executive API application . . . . . . . . . . . . . . . . . . . . . . . . . . . . 92 4.3.1 API overview . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 92 4.3.2 Application development . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 93 4.3.3 Application servlet development . . . . . . . . . . . . . . . . . . . . . . . . . . . 106 4.3.4 Deploying the application . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 111 Chapter 5. Policy-driven batch management . . . . . . . . . . . . . . . . . . . . . . 115 5.1 IBM Tivoli Workload Scheduler overview . . . . . . . . . . . . . . . . . . . . . . . . 116 5.1.1 Domain-based scheduling. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 116 5.1.2 Terminology . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 117 5.1.3 Scheduling resources . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 118 5.2 IBM Tivoli Service Level Advisor overview . . . . . . . . . . . . . . . . . . . . . . . 119 5.2.1 Service level management . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 119 5.2.2 IBM Tivoli Service Level Advisor architecture . . . . . . . . . . . . . . . . . 120
iv
IBM Tivoli Business Systems Manager V3.1: Advanced Implementation Topics
5.2.3 PiggyBanks IBM Tivoli Service Level Advisor setup . . . . . . . . . . . 122 5.3 Getting batch management information . . . . . . . . . . . . . . . . . . . . . . . . . 124 5.3.1 Setting up IBM Tivoli Workload Scheduler intelligent adapter . . . . 124 5.3.2 Batch management console . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 129 5.4 Service level for IBM Tivoli Workload Scheduler. . . . . . . . . . . . . . . . . . . 130 5.4.1 Batch interface to Tivoli Data Warehouse . . . . . . . . . . . . . . . . . . . . 131 5.4.2 Setting up IBM Tivoli Service Level Advisor . . . . . . . . . . . . . . . . . . 133 5.4.3 Defining Batch system in IBM Tivoli Service Level Advisor . . . . . . 135 5.5 Getting Service Level information in dashboard . . . . . . . . . . . . . . . . . . . 158 5.5.1 Data from the archiver. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 158 5.5.2 Loading data to measurement table . . . . . . . . . . . . . . . . . . . . . . . . 159 5.5.3 TEC event generated . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 159 5.5.4 Executive dashboard. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 162 Chapter 6. Using IBM Tivoli Intelligent Orchestrator to populate business systems structure . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 165 6.1 IBM Tivoli Intelligent Orchestrator overview . . . . . . . . . . . . . . . . . . . . . . 166 6.1.1 Terminologies . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 166 6.1.2 Architecture . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 169 6.1.3 New features for Version 3.1. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 172 6.2 Dynamic business system integration . . . . . . . . . . . . . . . . . . . . . . . . . . . 177 6.2.1 Data Center Model in IBM Tivoli Intelligent Orchestrator . . . . . . . . 178 6.2.2 Designing the workflow . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 180 6.2.3 Building workflow for adding a server . . . . . . . . . . . . . . . . . . . . . . . 181 6.2.4 Building workflow for removing a server . . . . . . . . . . . . . . . . . . . . . 189 6.3 Integration in action . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 191 6.3.1 Adding a Web server. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 191 6.3.2 Removing a Web server . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 195 Chapter 7. Problem management integration with the Peregrine Service Center. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 199 7.1 Peregrine Service Center overview . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 200 7.1.1 Peregrine Service Center architecture . . . . . . . . . . . . . . . . . . . . . . 200 7.1.2 Service Center and IBM Tivoli Business Systems Manager . . . . . . 201 7.1.3 Terms and definitions . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 204 7.2 Implementing SCAuto for TBSM . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 205 7.2.1 Installation requirements . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 206 7.2.2 Running the SCAuto for TBSM installer . . . . . . . . . . . . . . . . . . . . . 206 7.2.3 Adding new fields to the database dictionary . . . . . . . . . . . . . . . . . 209 7.2.4 Loading files into Peregrine Service Center . . . . . . . . . . . . . . . . . . 216 7.2.5 Adding a format control for automatic close events . . . . . . . . . . . . 218 7.2.6 Updating IBM Tivoli Business Systems Manager mappings . . . . . . 222 7.2.7 Configuring database server for SCAuto for TBSM . . . . . . . . . . . . 227
Contents
7.2.8 Configuring access to problem ticketing . . . . . . . . . . . . . . . . . . . . . 228 7.2.9 Starting the automatic close event notification service . . . . . . . . . . 229 7.3 Removing SCAuto for TBSM. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 229 7.4 Using Problem Ticketing . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 230 7.4.1 Problem ticketing. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 230 7.4.2 Automatic ticketing . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 242 7.5 Troubleshooting. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 242 Appendix A. Additional material . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 245 Locating the Web material . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 245 Using the Web material . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 245 System requirements for downloading the Web material . . . . . . . . . . . . . 246 Loading application into WebSphere Studio Application Development Integration Edition V5.1.1 . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 246 Using the ABS Java application . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 247 Abbreviations and acronyms . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 253 Related publications . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 255 IBM Redbooks . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 255 Other publications . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 255 Online resources . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 256 How to get IBM Redbooks . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 256 Help from IBM . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 256 Index . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 257
vi
Notices
This information was developed for products and services offered in the U.S.A. IBM may not offer the products, services, or features discussed in this document in other countries. Consult your local IBM representative for information on the products and services currently available in your area. Any reference to an IBM product, program, or service is not intended to state or imply that only that IBM product, program, or service may be used. Any functionally equivalent product, program, or service that does not infringe any IBM intellectual property right may be used instead. However, it is the user's responsibility to evaluate and verify the operation of any non-IBM product, program, or service. IBM may have patents or pending patent applications covering subject matter described in this document. The furnishing of this document does not give you any license to these patents. You can send license inquiries, in writing, to: IBM Director of Licensing, IBM Corporation, North Castle Drive Armonk, NY 10504-1785 U.S.A. The following paragraph does not apply to the United Kingdom or any other country where such provisions are inconsistent with local law: INTERNATIONAL BUSINESS MACHINES CORPORATION PROVIDES THIS PUBLICATION "AS IS" WITHOUT WARRANTY OF ANY KIND, EITHER EXPRESS OR IMPLIED, INCLUDING, BUT NOT LIMITED TO, THE IMPLIED WARRANTIES OF NON-INFRINGEMENT, MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE. Some states do not allow disclaimer of express or implied warranties in certain transactions, therefore, this statement may not apply to you. This information could include technical inaccuracies or typographical errors. Changes are periodically made to the information herein; these changes will be incorporated in new editions of the publication. IBM may make improvements and/or changes in the product(s) and/or the program(s) described in this publication at any time without notice. Any references in this information to non-IBM Web sites are provided for convenience only and do not in any manner serve as an endorsement of those Web sites. The materials at those Web sites are not part of the materials for this IBM product and use of those Web sites is at your own risk. IBM may use or distribute any of the information you supply in any way it believes appropriate without incurring any obligation to you. Information concerning non-IBM products was obtained from the suppliers of those products, their published announcements or other publicly available sources. IBM has not tested those products and cannot confirm the accuracy of performance, compatibility or any other claims related to non-IBM products. Questions on the capabilities of non-IBM products should be addressed to the suppliers of those products. This information contains examples of data and reports used in daily business operations. To illustrate them as completely as possible, the examples include the names of individuals, companies, brands, and products. All of these names are fictitious and any similarity to the names and addresses used by an actual business enterprise is entirely coincidental. COPYRIGHT LICENSE: This information contains sample application programs in source language, which illustrates programming techniques on various operating platforms. You may copy, modify, and distribute these sample programs in any form without payment to IBM, for the purposes of developing, using, marketing or distributing application programs conforming to the application programming interface for the operating platform for which the sample programs are written. These examples have not been thoroughly tested under all conditions. IBM, therefore, cannot guarantee or imply reliability, serviceability, or function of these programs. You may copy, modify, and distribute these sample programs in any form without payment to IBM for the purposes of developing, using, marketing, or distributing application programs conforming to IBM's application programming interfaces.
vii
Trademarks
The following terms are trademarks of the International Business Machines Corporation in the United States, other countries, or both: Redbooks Redbooks (logo) AIX DB2 Eserver z/OS IBM Lotus MVS NetView OMEGAMON PBT Tivoli Enterprise Tivoli Enterprise Console Tivoli Management Environment Tivoli TME WebSphere
The following terms are trademarks of other companies: Java and all Java-based trademarks are trademarks of Sun Microsystems, Inc. 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. 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. UNIX is a registered trademark of The Open Group in the United States and other countries. Linux is a trademark of Linus Torvalds in the United States, other countries, or both. Other company, product, or service names may be trademarks or service marks of others.
viii
Preface
This IBM Redbook discusses miscellaneous implementation topics and integration information for IBM Tivoli Business Systems Manager Version 3.1. The discussion is geared for an experienced IBM Tivoli Business Systems Manager specialist that requires an in-depth discussion for advanced implementation and integration options. This redbook does not provide basic implementation information for IBM Tivoli Business Systems Manager. That information can be found in IBM Tivoli Business Systems Manager V2.1 End-to-end Implementation, SG24-6610. Although that redbook discusses Version 2.1, most of the discussion still applies in Version 3.1. Additional information can be read from the formal IBM Tivoli Business Systems Manager Version 3.1 manuals. This redbook provides: An overview in Chapter 1, Business Service Management with IBM Tivoli Business Systems Manager on page 1. An implementation overview in Chapter 2, Implementation process methodology overview on page 15, that sets the level for the additional discussion in other chapters. A business system definition is the largest single issue in a successful IBM Tivoli Business Systems Manager implementation, and we discuss this in Chapter 3, Building business systems: design, concepts and implementation on page 37. The executive dashboard implementation is discussed in Chapter 4, Presenting and using executive services and executive view on page 83, and an advanced TBSM API programming sample is provided in this redbook. A policy based batch management using IBM Tivoli Workload Scheduler and IBM Tivoli Service Level Advisor is explained in Chapter 5, Policy-driven batch management on page 115. Orchestration with IBM Tivoli Intelligent Orchestrator creates dynamic assignment of resources based on business needs instead of naming convention, as discussed in Chapter 6, Using IBM Tivoli Intelligent Orchestrator to populate business systems structure on page 165. Problem management integration with the Peregrine Service Center is discussed in Chapter 7, Problem management integration with the Peregrine Service Center on page 199.
ix
The team that wrote this redbook

This redbook was produced by a team of specialists from around the world working at the International Technical Support Organization, Austin Center. Budi Darmawan is a Consulting IT Specialist at the International Technical Support Organization, Austin Center. He writes extensively and teaches IBM classes worldwide in all areas of Tivoli systems management. Before joining the ITSO six years ago, he worked as Lead Implementer and Solution Architect for Integrated Technology Services in IBM Indonesia. He is experienced in z/OS system programming, Web-based and Java-based programming solutions, DB2 database administration and various IBM Tivoli products. His current interest is advanced systems management, business service management, and Java programming. Wayne Doughty is a member of the National On Demand Services Team. He is certified in ITIL Foundations in IT Service Management. He has four years experience with TBSM services. Wayne has over 29 years experience in IT and over 15 years experience in Data Center automation. His roles have included computer operations, help desk support, MVS System Programming, network management in a multi-system environment, second and third level tape storage software support for robotic libraries, program management, and Business Systems Management consultant. Michael Jobe is a is a Systems Management Architect working with K4 International in California. With over 12 years experience in Systems Management, Michael is a Tivoli Certified Consultant specializing in application integration and systems availability. Michael can be reached at jobem@oroburos.com. Timothy Lam is a member of Advanced Technical Sales (ATS) team in Asia Pacific based in Beijing, China, supporting and providing assistance throughout Asia Pacific. He is an IBM Certified Advanced Deployment Professional for Tivoli Enterprise Management Solution. He has over 15 years experience in IT and 10 years experience in System Development and Enterprise System Management. He holds a degree in Computer Science from the London University, United Kingdom. Thanks to the following people for their contributions to this project: Edson Manoel, Editor International Technical Support Organization, Austin Center Christine Dewesee Peregrine Systems
Mark Masercola, Venkat Surath, Roger Turner IBM Software Group
Become a published author

Join us for a two- to six-week residency program! Help write an IBM Redbook dealing with specific products or solutions, while getting hands-on experience with leading-edge technologies. You'll team with IBM technical professionals, Business Partners and/or customers. Your efforts will help increase product acceptance and customer satisfaction. As a bonus, you'll develop a network of contacts in IBM development labs, and increase your productivity and marketability. Find out more about the residency program, browse the residency index, and apply online at:
ibm.com/redbooks/residencies.html
Comments welcome
Your comments are important to us! We want our Redbooks to be as helpful as possible. Send us your comments about this or other Redbooks in one of the following ways: Use the online Contact us review redbook form found at:
ibm.com/redbooks
Send your comments in an email to:

redbook@us.ibm.com
Mail your comments to: IBM Corporation, International Technical Support Organization Dept. 0SJB Building 905 11501 Burnet Road Austin, Texas 78758-3493
Preface
xi
xii
Chapter 1.
Business Service Management with IBM Tivoli Business Systems Manager

This chapter introduces IBM Tivoli Business Systems Manager functionality and features in the context of business service management. The information acts as the foundation for the implementation issues discussed in this book. The discussion in this chapter is divided into: 1.1, Business Service Management on page 2 1.2, IBM Tivoli Business Systems Manager overview on page 5 1.3, Discussion scope on page 12 1.4, Lab environment on page 13
1.1 Business Service Management

The philosophy of managing services in a business context is receiving more traction with IT organizations that are trying to improve relations with their customers. These same organizations are also trying to overcome historical challenges such as customer perception and the increasing complexity of technology. Understanding how shared infrastructure resources are being used by business processes significantly improves the ability of business and IT executives to negotiate, measure, and evaluate service contracts.
1.1.1 Concepts
Many IT organizations are turning to Business Service Management solutions to facilitate a business-defined view of IT-delivered services. Business Service Management solutions provide facilities and analytics that enable IT to manage service levels with the business consumer for a specific business process to ensure that the SLA associated with this process is fulfilled. Business Service Management allows IT to incorporate business knowledge into the service management process and to translate data from traditional infrastructure and application management tools into business-level representations. Business Service Management relies on IT organizations that work with business units to map resource-to-service relationships and organize them into structures that depict and visualize the components of IT infrastructure as well as automate components of the business process based on the knowledge of their relationships. Accordingly, with Business Service Management, IT management and business executives can reconcile their perspective of IT performance. This is because Business Service Management can report both real-time status and historical service-level compliance for each business function supported by IT. Business Service Management is a service management application that aligns IT operations with business processes. Therefore, it allows business functions to receive maximum leverage from IT resource management. Business Service Management solutions enable real-time management of events and service levels based on knowledge of their relationships to an IT service provided to a business entity responsible for a business process. Business Service Management provides IT with a set of algorithms and visualizations that IT must incorporate in its SLM processes. It is designed to display and report the service delivery health and business impact of IT based on performance and availability of IT resources. The visualization of Business
Service Management runs on federated event and monitoring data as well as business and IT relationship data. The four aspects of Business Service Management are: It consists of identifying the components of a business system. It involves measuring the performance and availability of those components. It ensures that the components are performing within Service Level Objectives (SLOs). It alerts to any deviation or potential deviation from SLOs. The concepts behind Business Service Management include: Resources are components of IT infrastructure. Business transaction is a group of IT resources supporting a particular IT workload. Business system is a group of resources that supports a business goal. Business process is composed of some automated (IT services based) and some manual steps. When policy data or service level information is attached to a business system, it turns into an IT service. IT service can be perceived as a collection of IT resources that make up the automated part of the business process.
1.1.2 IT Infrastructure Library (ITIL)

The ITIL is a series of documents that are used to aid the implementation of a framework for IT service management. This customizable framework defines how service management is applied within an organization. The ITIL was originally created by the Central Computing and Telecommunications Agency (CCTA), a United Kingdom government agency; now known as the Office of Government Commerce (OGC). It is now is becoming more popular and has been adopted and used across the world as the standard for best practice in the provision of IT service. Although the ITIL covers many areas, its main focus is on IT service management. The ITILs IT service management is organized into a series of sets, which are divided into two main areas: service support and service delivery. Each area contains several disciplines, which stipulate the ITIL practices or requirements. Service support is the practice of those disciplines that enable IT services to be provided effectively.
Chapter 1. Business Service Management with IBM Tivoli Business Systems Manager
Service delivery covers the management of the IT services themselves. It involves many management practices to ensure that IT services are provided as agreed upon between the service provider and the customer. Refer to the following Web sites for details about what ITIL is and what it can provide: IT systems management forum Web site
http://www.itsmf.com
Official ITIL Web site

http://www.itil.co.uk
Official OGC Web site

http://www.ogc.gov.uk
1.1.3 Business Service Management solution with Tivoli

Tivoli provides a comprehensive scale of Business Service Management. The heart of the Business Service Management solution from Tivoli is IBM Tivoli Business Systems Manager. IBM Tivoli Business Systems Manager provides the ability to represent an abstraction of IT resources and the map them to business service. IBM Tivoli Business Systems Manager also allows custom definition on how individual IT resource can affect a certain business service. This ability proves to be pivotal on the usage of IBM Tivoli Business Systems Manager. IBM Tivoli Business Systems Manager as the main component of Business Service Management, receives input of IT resource status and health from various components, such as: IBM Tivoli Monitoring for system health IBM Tivoli Workload Scheduler for batch jobs status IBM Tivoli NetView for network resources IBM Tivoli OMEGAMON family IBM Tivoli Business Systems Manager also allows dynamic definition of IT resources and business service entities. This also allows a more dynamic environment to be accommodated, such as an on-demand environment, where resources are dynamically allocated as needed.
1.2 IBM Tivoli Business Systems Manager overview

This section provides an overview of IBM Tivoli Business Systems Manager concepts, components and architecture. More information of IBM Tivoli Business Systems Manager can be read in Tivoli Business Systems Manager V2.1 End-to-end Business Impact Management, SG24-6610. Some of the features has changed in version 3.1 however the basic concept is still similar. The discussion in this section is divided into: Objects and resources on page 5 Components and interaction on page 8 User interface on page 10
1.2.1 Objects and resources

IBM Tivoli Business Systems Manager objects are individual entities that can be managed and monitored. Typically these object has a color-coded status associated with it. These are called managed object, it is shown in Figure 1-1.
cid=NREG, cname=NetworkRegion, cno=001F
id=000001 name=Austin description=Austin network state=unknown priority=Critical alertstate=Green id=000002 name=LosAngeles description=LA network state=unknown priority=Critical alertstate=Green id=000003 name=NewYork description=NY network state=unknown priority=Critical alertstate=Yellow
Figure 1-1 Managed object
A managed object has the following principal attributes: Class wide attributes Class id (cid) This is the object type that the object is associated with. The class id is represented as a 4-character string. Such as NREG.
Class name (cname) This is the long name of the object type, such as NetworkRegion. There is no spaces in the class name. Class number Static object attributes Instance id (id) This is a number that represent the specific instance in the class. This is implemented as 6-digits hexadecimal number. This is a 4-digits hexadecimal number associated with a class id. This field is only used internally.
Name Description Alert state Priority State
The display name of the object. Description of the object. This represent the color coded status of the object, it can be red, yellow or green. This represent what is the ripple effect of this object to its container parent. This represent the presumed status of the object. This only applies to mainframe objects.
Dynamic object attributes
These monitored objects resides in two different areas, typically called: All resources tree: These are when the object that is just discovered by IBM Tivoli Business Systems Manager is put. Some call this objects physical resources because it represent the status of the real object. The object in the All resources tree is defined in a tight hierarchical structure and all copies of the object is cloned directly from this. Only one instance of an object resides in this tree, each objects here represents a unique resource. Most operator does not use or manipulate or monitor these object directly. Business system tree: These are the object copies that are custom-arranged to represent the enterprise. This tree is logically structured to match the enterprise requirement and structure, It is where the customization must take place to define a meaningful structure. The objects in this tree are copies from the All resource tree; these objects may resides on several branches, representing a resource that is used by multiple business service. A resource can be shown in the IBM Tivoli Business Systems Manager Java console in Figure 1-2 on page 7.
Figure 1-2 Resource trees
Based on the role and usage of an object, a resource can be called: Physical resource This is a resource object residing in the All resources tree.
Business system resourceThis is a copy of physical resource that resides in the business system tree. Business system folder This is a folder or container that contains business system resources; typically a business system folder represents a business entity.
Business system shortcutThis is a copy of a business system folder so that it can be reused in different portion of the business system tree. A typical management or monitoring procedure for a IBM Tivoli Business Systems Manager operator is:
1. An operator watching business system folders that are assigned to him/her. 2. When a business system folder changes its alert state from green to yellow or red, the operator drill down the business system folder and finding the resources that caused the change. 3. The operator can prioritize his work by looking at the business impact for each resource; that is finding the business system folders that are affected by each resource. 4. Fixing the resources so that all the business systems should be green.
1.2.2 Components and interaction

For IBM Tivoli Business Systems Manager to be able to implement the management structure and processes business systems, it needs to have a dynamic structure consisting of multiple components. Figure 1-3 shows the overview of IBM Tivoli Business Systems Manager components.
z\OS
Source/390 Tivoli NetView for z\OS Tivoli Data Warehouse
TBSM Servers
Host Integration Server Event Handler Server Executive dashboard
History Server
Database Server
Console Server
Web Console
Console Agent Listener Common Listener Service Health Monitor Server
EIF Sender
Health Monitor Client
Tivoli Management Region

Task Server
TEC Event Enablement
Distributed Data Source. ( Netview, ITM)
Figure 1-3 IBM Tivoli Business Systems Manager components
From Figure 1-3 on page 8, the following are the components of IBM Tivoli Business Systems Manager: Base components: The following are the components that are used by both mainframe or distributed environment Database server, which is consists of: Microsoft SQL Server database, the heart and central processing of IBM Tivoli Business Systems Manager. SQL Server Agent for running SQL processes in regular intervals. Tivoli BSM Staged Event Loader to load event to the database
WebSphere Application Server Console Server that runs the console applications, for Java console, Web console and Executive dashboard Mainframe input components: These are the components that are used by mainframe environment only. It runs mostly on the Event handler server. For SNA connection the Host Integration Server is used to connect to the mainframe. Tivoli BSM MVS OS Listener Service: Receives communication from the z/OS systems Tivoli BSM MVS Listener Service: Receives bulk discovery communication from the mainframe, this component runs on the database server as it uses bulk copy facility from Microsoft SQL Server. Tivoli BSM MVS Event Handler Service: Loads events from the listener for Staged event loader Tivoli BSM MVS Upload Rule Server: Determines what replies to be send back based on the message the OS Listener receives. Tivoli BSM Enqueue Proxy Server: Receives enqueued events from the upload rule server for sending to z/OS systems. Tivoli BSM MVS Sender Service: Sends back replies for z/OS systems. Distributed input components: The following are the components that are used by distributed environment only. Tivoli BSM Event enablement: Formats and sends TEC event to IBM Tivoli Business Systems Manager. Tivoli BSM Agent Listener: Receives TEC event sends by the event enablement component. Tivoli BSM Common Listener: Receives XML formatted object discovery and events from Common Listener intelligent adapters. Tivoli BSM EIF Sender: Sends events to TEC for processing, such as state and status synchronization. Tivoli BSM Task Server: Runs Tivoli Framework task or z/OS command
1.2.3 User interface

In accessing IBM Tivoli Business Systems Manager, there are several interfaces that are available. These are the interfaces for IBM Tivoli Business Systems Manager V3.1: Java console: This is the full function interface that is suitable for administrator and most dedicated IBM Tivoli Business Systems Manager operators. It provides all administrative functions for IBM Tivoli Business Systems Manager. A sample Java console is shown in Figure 1-4.
Figure 1-4 Java console
Web console: This is the slim-down Web browser based console for the occasional operator that needs access to IBM Tivoli Business Systems Manager but does not need the Java console software loaded on the machine. It handles most functions that the Java console provides for operators. The Web console is shown in Figure 1-5 on page 11.
10
Figure 1-5 Web console
Executive dashboard: This is a status only Web-based dashboard. It is meant for display of certain business system status and no administrative interaction. The shockwave based executive dashboard is shown in Figure 1-6 on page 12.
11
Figure 1-6 Executive dashboard
Reporting system: Generates and retrieves event reports for objects in the business system or all resources tree, This is the only interface that is not served by the WebSphere Application Server in the console server. This is typically run from the History Server.
1.3 Discussion scope

This redbook discussed advanced implementation topics of IBM Tivoli Business Systems Manager V3.1. This is not meant to be a cookbook or basic installation and configuration for IBM Tivoli Business Systems Manager. Refer to TBSM Installation And Administration Guide for this information. You can also look at IBM Tivoli Business Systems Manager V2.1 End-to-end Implementation, SG24-6610. In a large IBM Tivoli Business Systems Manager implementation, a correct methodology is very important in performing a successful implementation. Some considerations and overall implementation methodology are discussed in Chapter 2, Implementation process methodology overview on page 15. The main implementation objective of IBM Tivoli Business Systems Manager is to map IT resources to reflect the enterprise business services. The mapping process is regarding the creation of business system folder structure and assigning resource objects to them. The resource objects are assigned with the appropriate attributes so the actual status of business entities are reflected in the
12
business system folder objects. The discussion on business systems is presented in Chapter 3, Building business systems: design, concepts and implementation on page 37. Executive dashboard is a significant enhancement in IBM Tivoli Business Systems Manager V3.1. It allows a simple status interface for an executive to use.Executive dashboard provides Application Programming Interface (API) for custom J2EE based application to be developed for displaying IBM Tivoli Business Systems Manager object status. We discuss all these in Chapter 4, Presenting and using executive services and executive view on page 83. Batch management and its integration with Service Level management is presented in Chapter 5, Policy-driven batch management on page 115. With new on-demand operating environment, resources can be provisioned and removed as needed. A resource from a resource pool can be assigned to any business process that needs it. As IBM Tivoli Business Systems Manager relies on naming convention to allocate an object to business systems, it is harder to do this in a totally dynamic environment. IBM Tivoli Business Systems Manager V3.1 provides XML interface to define resource assignment to business systems. Chapter 6, Using IBM Tivoli Intelligent Orchestrator to populate business systems structure on page 165 demonstrates a sample integration for dynamic provisioning using IBM Tivoli Intelligent Orchestrator with IBM Tivoli Business Systems Manager. As there is a greater drive to move to a service based environment conforming to ITIL infrastructure, a problem management environment is a key component. This chapter discusses the implementation and usage of the Peregrine Service Center with IBM Tivoli Business Systems Manager V3.1. The integration is typically performed with SC Auto for TBSM product. We present this in Chapter 7, Problem management integration with the Peregrine Service Center on page 199.
1.4 Lab environment

This section presents the management environment, in which we tested the scenarios. The overall diagram is shown in Figure 1-7 on page 14. The machines on the top part of the diagram are management servers, while the environment on the lower part are the managed environment.
13
phoenix
Tivoli Framework Tivoli Enterprise Console 3.9 ITM for Apache
laredo
pretoria
Tivoli Business Systems Manager 3.1
kingston
Tivoli Data Warehouse Tivoli Service Level Advisor DB2 Server
beijing
Peregrine ServiceCenter
Tivoli Intelligent Orchestrator 3.1
PiggyBank resources
Tivoli Endpoint Tivoli Common Agent Cygwin
TCP/IP network Tivoli Endpoint Tivoli Common Agent Cygwin Tivoli Endpoint Tivoli Common Agent Cygwin
dublin
manila
bangkok
Figure 1-7 Lab environment
14
Chapter 2.
Implementation process methodology overview

This chapter discusses the implementation methodology for IBM Tivoli Business Systems Manager. The discussion covers general planning information and some practical rules-of-thumb, including large-scale implementation choices. We also cover integration considerations with various other products. The discussion is divided into: 2.1, Implementation methodology on page 16 2.2, Deployment and planning considerations on page 16 2.3, Installing IBM Tivoli Business Systems Manager on page 26 2.4, Defining business systems on page 34
15
2.1 Implementation methodology

IBM Tivoli Business Systems Manager is a complex product that must be customized for a specific environment. The customization process can vary from a moderate to a complex customization effort. This is an often overlooked fact when IBM Tivoli Business Systems Manager is acquired. This chapter is aimed to provide a framework and listing of what are the steps that need to be performed for implementing IBM Tivoli Business Systems Manager. The steps explained here should be used as a base for further research when actually implementing the product. The discussion in this chapter is primarily aimed to a distributed IBM Tivoli Business Systems Manager implementation. The methodology discussed here consists of the following: Planning is very important to have a successful implementation; we discuss these issues in 2.2, Deployment and planning considerations on page 16. Installation procedure is explained in 2.3, Installing IBM Tivoli Business Systems Manager on page 26. This includes some customization considerations. Business system design overview is provided in 2.4, Defining business systems on page 34.
2.2 Deployment and planning considerations

This section explains some important planning considerations for implementing IBM Tivoli Business Systems Manager. These planning considerations include: 2.2.1, IBM Tivoli Business Systems Manager servers and connectivity on page 16 2.2.2, Requirement gathering and solution design on page 18 2.2.3, Solution design session on page 23
2.2.1 IBM Tivoli Business Systems Manager servers and connectivity

IBM Tivoli Business Systems Manager Enterprise Edition can be configured using up to nine servers. IBM Tivoli Business Systems Manager Distributed Edition deployment can be configured using the minimum of two servers. The roles of these machines are shown in Figure 2-1 on page 17.
16
Database server
Health monitor server
Database server
History server
Event handler server
Console server
Event Handler Server
Console server
SNA server
Production servers
Test / Quality assurance servers
Figure 2-1 Server roles
Most large implementation should have a different sets of IBM Tivoli Business Systems Manager servers. The test servers are meant for testing new features and new configuration. The production servers itself consists of the following functions: Database server This is where the Microsoft SQL Server database is located. This is the heart of all IBM Tivoli Business Systems Manager processing. This server unloads the data regularly from the database server for reporting purposes. WebSphere Application Server running the IBM Tivoli Business Systems Manager console server application serving users.
History server Console server
Event handler server This server connects to z/OS systems running Source/390. SNA server or Host integration server This server provides SNA connectivity for IBM Tivoli Business Systems Manager, this server is not needed for TCP/IP communication. Health Monitor serverThis monitors the health of IBM Tivoli Business Systems Manager servers. Distributed IBM Tivoli Business Systems Manager implementation requires at least the database server and console server. These configuration serves IBM Tivoli Business Systems Manager consoles.
Chapter 2. Implementation process methodology overview
17
2.2.2 Requirement gathering and solution design

In order for the implementation to be successful, it is critical that the scope of the project, and the requirements that the solution should address should be well documented and communicated. If a statement of work (SOW) exists it will be the initial source for the requirements gathering process. The SOW may identify very high-level requirements in terms of the application or business systems that will be used for the implementation, or sources of events that need to be integrated into the IBM Tivoli Business Systems Manager solution, and so on. These high-level requirements must be validated, and further refined so that a IBM Tivoli Business Systems Manager solution design can be used to address the requirements. The requirements gathering or refinement may take place with a kick-off meeting with all of the parties involved, or discussing with individuals that are identified by the project sponsor. These individuals need to be educated on the IBM Tivoli Business Systems Manager product capabilities, and various types of user interfaces that IBM Tivoli Business Systems Manager can provide (Java Console, Web Console, and the Executive dashboard). A quick one hour product demo of IBM Tivoli Business Systems Manager is very useful in getting the parties involved in the requirements gathering phase. This will also reduce the chances of developing the false expectations or misconceptions on the functions that IBM Tivoli Business Systems Manager can provide and how the final IBM Tivoli Business Systems Manager solution will look. The requirement gathering phase should include the necessary information for designing the solution. The requirement can be summarized in Figure 2-2.
Management environment
6 4 5
Business systems End user
Monitoring sources 2 Monitoring sources Monitoring sources Monitoring sources
3
interface
IBM Tivoli Business Systems Manager
Servers configuration
Console types Roles Critical resources
Figure 2-2 Requirement summary
When gathering and documenting the requirements, keep the discussion in terms of what rather than how, and document the requirements in words rather than in pictures. As shown in Figure 2-2, the following information needs to be identified: Servers configurationThe machine specification and estimated load should determine the required server configuration
18
Monitoring sources Data sources that will feed into IBM Tivoli Business Systems Manager must be identified and inventoried for event analysis and naming conventions Interfaces The interface from the monitoring source must be identified to understand the requirement for data structure extension and possible additional operational command structures; the interface also determines the requirement for resource placement in the all resource tree The list of end users that will use IBM Tivoli Business Systems Manager must be made to identify their requirements, such as console types, roles, resource needs The end users requirements determine the needs for business system structure; this is the major design decision that must be made carefully to make a useful solution
End user
Business system
Management environment The external products that needs to be integrated with IBM Tivoli Business Systems Manager must be identified; this excludes the monitoring sources that feeds IBM Tivoli Business Systems Manager; examples are IBM Tivoli Service Level Advisor, IBM Tivoli Intelligent Orchestrator, help desk systems and so on Lets look at these requirements in more detail.
Servers configuration
The machine specification for IBM Tivoli Business Systems Manager servers should be checked against the latest specification recommendations. The configuration must also consider estimated load that will comprise the systems. Although it is quite hard to predict without the rest of the definition, some initial calculations can get the ball-park figure. The initial information required is: Number of monitoring sources Number of managed resources per monitoring source Number of events per resource Number of end users Number of aggregates (application / functions / grouping) Number of folders for each end users Number of resource copy in different folders Using this structure, we should be able to identify roughly:
19
Number of events that IBM Tivoli Business Systems Manager will process; which is derived by:
The sum of: events per resource X managed resources X monitoring sources
Number of business systems, assuming that each end user uses in average an aggregate folder and each resources can be found in up to 5 aggregate folders; the number of business systems can be derived from:
End users X aggregates X 2 + managed resources X aggregates X 5
Although the above numbers are very rough, they should be able to give an estimated load for the server configuration options.
Monitoring sources
Data sources that will feed into IBM Tivoli Business Systems Manager must be identified and inventoried for event analysis and naming conventions. These sources can have a well known interface, such as IBM Tivoli Monitoring family or any potential sources that must be fed into IBM Tivoli Business Systems Manager. These sources must be analyzed to acquires naming convention and event structure. When identifying the requirements, it is desirable to list them as granular as possible by critical business or application system, by event or monitoring sources such as: IBM Tivoli Monitoring IBM Tivoli Management for Transaction Performance IBM Tivoli NetView Logfile adapters and so on A detailed information on monitoring subsystems will be very useful in implementation stage. A good listing will allow quick initial implementation of IBM Tivoli Business Systems Manager. Naming convention will be highly beneficial to collect for definition of automated business system. Automated business system is highly dependent to naming convention, as it matched name patterns to filters resources that will be put in business system folders. Events must be analyzed to understand: Event structure, what are the important field of the event that you want to forward to IBM Tivoli Business Systems Manager and also which fields must
20
be mapped to IBM Tivoli Business Systems Manager terminology for correct propagation behavior Event pairing to understand which events are considered alert and which events are resolution; this also includes an exhaustive analysis to see whether all alerts has a resolution to provide closure and how to match up the alert with its resolution. Resource naming and event relation must be established to be able to see the exact name structure that is send in events.
Interfaces
The interface from the monitoring source must be identified to understand the requirement for data structure extension and possible additional operational command structures; the interface also determines the requirement for resource placement in the all resource tree. Distributed events feeds can be integrated into the IBM Tivoli Business Systems Manager business impact management solution using the Common Listener (CL) or the Event Enablement (EE). Common Listener supports the discovery and status information from IBM Tivoli Business Systems Manager adapters installed, configured, and running on the monitoring systems, such as IBM Tivoli NetView, IBM Tivoli Monitoring, IBM Tivoli Workload Scheduler, HP OpenView, and so on. These adapters are shipped as part of the IBM Tivoli Business Systems Manager 3.1 product. Event Enablement (EE) is installed on the IBM Tivoli Enterprise Console (TEC) and provides the APIs and services to forward TEC events to IBM Tivoli Business Systems Manager. Unlike the Common Listener interface where the information received is mapped to appropriate predefined resource types, the Event Enablement APIs provide total control over how an event can be mapped or linked to which resource type
End user
The list of end users that will use IBM Tivoli Business Systems Manager must be made to identify their requirements, such as console types, roles, resource needs. Users must be defined with appropriate role for them to perform their daily tasks. This includes the definition of an easy to navigate business system structure that both indicative to all problems that they may have and easy to drill down to see the problem. Users requirement determine the structure of the business system folders. A business system folder is created because a user has a need to get a status from that folder. User roles are defined to the appropriate level so each user will not have access to unauthorized functions or any excessive cluttered display.
21
Business system
The end users requirements determine the need for business system structure; this is the major design decision that must be made carefully to make a useful solution. Business system structure must be: Reflect an enterprise Used by end-user for monitoring Easy to maintain for changes Automated for creation As discussed, the business systems can be created in three methods: Manual drag and drop Automated business system XML interface The business system folder requirement gathering should include the following: Business or Application Systems and subsystems Number of business systems and how they will be defined, manually, Automatic Business Systems or XML interface What each business system folders purpose is, and who the potential audience or users will be As you can see, the most important aspect of IBM Tivoli Business Systems Manager implementation is the information of structure and definition of business systems. As this is a major requirement, we discuss this in detail in Chapter 3, Building business systems: design, concepts and implementation on page 37.
Management environment
There are other aspect of systems management that needs to be taken into account for IBM Tivoli Business Systems Manager deployment other than Availability management. The interfaces to other Tivoli and non-Tivoli software port folio may need to be considered. The interfaces here are interfaces that does not forwards availability events to IBM Tivoli Business Systems Manager. This includes: Configuration: Deployment of console and its preferences with software distribution solution such as IBM Tivoli Configuration Manager. Optimization: Scheduling of maintenance jobs outside of Microsoft SQL Server Agent, such as with IBM Tivoli Workload Scheduler. Provisioning: Dynamic update of system resource structure from dynamic provisioning applications such as IBM Tivoli Intelligent Orchestrator.
22
Service Level Management: Feed to and from IBM Tivoli Service Level Advisor. Service desk solution: Problem and change management, such as using the Peregrine Service Center. Security: Interaction with Web console may require an additional security from products such as IBM Tivoli Access Manager.
2.2.3 Solution design session

Depending on the scope of the deployment, the solution design effort can be anywhere from informal discussions with white board drawings that can last a half day to a day, or it can take up to 10 days. The solution design session consists of the following tasks: Design meetings Information collection Design documentation Review the design document Sign off of solution design The session can be broken down into two part: The physical design, which dictates on how events flow from the monitoring environment into IBM Tivoli Business Systems Manager. The business systems design, which lays out the business system folders structure, hierarchy with all the necessary attributes, functions or methods; a cross reference on who requires the business systems is also beneficial to be documented. We explain the design in the following sections, depicting a fictitious company called PiggyBank, Inc. that runs a Web banking operation out of three data centers located in Austin, New York and Los Angeles.
The physical design

The physical design part involves the following: Understand the existing resource monitoring environment. The information that needs to be collected here are the monitoring software that acts as event sources and what are the resource naming convention here. In PiggyBank, Inc. the monitoring are performed using the following software: IBM Tivoli NetView for monitoring network resources IBM Tivoli Monitoring for custom monitoring of application servers and databases
23
IBM Tivoli Monitoring for Transaction Performance to check response time and investigate transaction integrity IBM Tivoli Monitoring for Web Infrastructure for monitoring Apache Web servers IBM Tivoli Enterprise Console correlates and processes events from all the IBM Tivoli Monitoring and IBM Tivoli NetView environments. Interfaces from the monitoring application must be identified. This determines how resources and events being sent to IBM Tivoli Business Systems Manager. The options are Common Listener or Event Enablement. The Event Enablement approach provides a higher flexibility of managing events and performing event correlation through IBM Tivoli Enterprise Console. As in PiggyBank, Inc. the events are already sent to IBM Tivoli Enterprise Console, an event enablement interface may seems to be an obvious choice. However, looking at how IBM Tivoli NetView event mix, it seems that it requires a large data model extension, so we decided to use the Intelligent Adapter for IBM Tivoli NetView that interact through Common Listener. Note: The two approaches are not mutually exclusive. The Common Listener interface can be used for certain event sources and the Event Enablement interface can be used for others. For the events coming through IBM Tivoli Enterprise Console, we need to perform event analysis. This analysis includes: Collecting a set of sample events for a specific time period; such as a day worth of events; This is to validate the event mix and find event pairs that should be generated. Analyze the events from the sample mix to collect event classes, slots, slot values, problem events, and corresponding resolution events Understand any automation through TEC rules that is in place; this may introduce that some important events may be dropped by automation, although IBM Tivoli Business Systems Manager needs them for resolving an alert condition. Cause event analysis or event correlation may generate a new event that you may want to use instead of the original events as the final correlated event is the important root cause of the problem. Identify resource types (object types or object model) required to address the requirements. These are typically the resource types that must be created for the Event Enablement interface. The example for PiggyBank, Inc. that we use requires the following resource types to be defined: AppServer - application server Database - Microsoft SQL server database
24
UserTrans - Online Banking user transaction simulated using IBM Tivoli Monitoring for Transaction Performance robot BranchServer - Servers in branch offices TellerWorkstation - Teller workstations in branch offices Map events to resource types, we need to identify the event structure that we can send to IBM Tivoli Business Systems Manager from IBM Tivoli Enterprise Console. IBM Tivoli Monitoring is used to monitor application server health; IBM Tivoli Monitoring events with the class stats with AppServer should be mapped to product type AppServer 1.0. All events with an event class that starts with Microsoft_SQL should be mapped to resource type Database 1.0. These are the events generated by the ITM resource models that are deployed to monitor Microsoft SQL servers, for example Microsoft_SQL_Server_Allocate_Space_Failed. IBM Tivoli Monitoring for Transaction Performance events should be mapped to resource type UserTrans. These events are generated by the GenWin policies defined and deployed to monitor user transactions. As these event has the hostname of the monitoring workstation instead of the transaction server, the event mapping must be performed from the robot profile name. From the naming convention, the robot profile name starts with the hostname of the transaction server it accessed. Any event with a host name that starts with PCW should be mapped to the TellerWorkstation resource type. Any event with a host name that starts with SRV and followed by branch 3-character mnemonic should be mapped to the BranchServer resource type. Note: The event analysis and mapping is rather simple and basically based on the TEC event source, event class, or host name. Sometimes there maybe other information provided in other slot values that may need to be used in determining the mappings depending on the existing IT infrastructure architecture, naming conditions for IT resources, and Tivoli architecture such as Profile names, ITM Resource Model Names, and so on. It is critical to keep the mapping criteria or scheme as simple as possible to keep the implementation simple and flexible.
The business system design

The business system design involves the following tasks: Collect user lists and requirements, this includes user roles, user ID, authentication mechanism and user to resource mappings.
25
Business system folders structure. The solution design also identify the necessary mechanism on maintaining the definition, such as automated business system or XML toolkit. IBM Tivoli Business Systems Manager deployment at Piggybank Inc. will use a staged approach. Not all business system folders are created in the initial phase, additional business system folders can be defined once the IBM Tivoli Business Systems Manager administrator and users gain some experience with the product. Application aggregates for major application monitor eloan and ebanking system Marketing application Warehouse system Human resource application Data center view Resource type view From the above list, most of the resources are planned to be created using automated business system method. While the Web servers based Marketing application is dynamic based on the current promotion and special offers, it is decided to be covered using XML technology. More discussion on business system design is provided in Chapter 3, Building business systems: design, concepts and implementation on page 37.
2.3 Installing IBM Tivoli Business Systems Manager

The installation of IBM Tivoli Business Systems Manager is described in the following sections: 2.3.1, Software installation on page 26 2.3.2, Event enablement interface on page 28 2.3.3, Common Listener interface on page 31
2.3.1 Software installation

IBM Tivoli Business Systems Manager deployment can be configured using the minimum of two IBM Tivoli Business Systems Manager servers. This document is based on the minimum required two server configuration. The prerequisite software is listed in Table 2-1 on page 27.
26
Table 2-1 Prerequisite software Windows 2000 Windows 2000 Advanced Server Edition with Service Pack 4 Windows 2000 Support tools MKS Toolkit for System Administrators V8.6/V8.7 Microsoft SQL Server 2000 Enterprise Edition Service Pack 3a Microsoft SQL Server 2000 JDBC Driver Microsoft Internet Information Server V5.0 WebSphere Application Server V5.0.2.6 Windows 2003 Windows Server 2003 Enterprise Edition Windows 2003 Support tools MKS Toolkit for System Administrators V8.6/V8.7 Microsoft SQL Server 2000 Enterprise Edition Service Pack 3a Microsoft SQL Server 2000 JDBC Driver Microsoft Internet Information Server V6.0 WebSphere Application Server V5.0.2.6
Note: WebSphere Application Server V5.0.2.6 is shipped with IBM Tivoli Business Systems Manager and installed on the console server as part of the IBM Tivoli Business Systems Manager install. Refer to the IBM Tivoli Business Systems Manager Version 3.1 Installation and Configuration Guide, SC32-9089 for additional hardware configurations and specific hardware and software requirements. Except for Microsoft SQL Server 2000, all other prerequisite software can be installed using the default install options as long as the software gets installed and is operational. Microsoft SQL Server 2000 must be installed with Binary Sort Order and Latin1_General code page. Installation of IBM Tivoli Business Systems Manager is performed using the installation wizard. Just follow the installation wizard and select the components that you want to install. After the installation, integration of resources must be implemented. As discussed in 2.2.1, IBM Tivoli Business Systems Manager servers and connectivity on page 16, the option is to use Common Listener or Event Enablement interface. We discuss the options in the following sections.
27
2.3.2 Event enablement interface

When using the event enablement interface for defining resources through IBM Tivoli Enterprise Console. There are several steps that must be followed: 1. Defining resource types on page 28 2. Forwarding events to IBM Tivoli Business Systems Manager on page 28 3. Defining resource placement in All Resource view on page 29 4. Initial resource discovery on page 29 5. Integrating Tivoli tasks or URLs on page 30
Defining resource types

IBM Tivoli Business Systems Manager distributed deployment usually involves defining resource types to address the specific requirements. Defining resources sometimes referred to as extending the object model. There are two types of objects that can be defined depending on the types of events that will be used for the resource. The following are the object types: The distributed monitoring object type is meant for representing the resources that are monitored using IBM Tivoli Monitoring or Tivoli Distributed Monitoring and facilitates integration of IBM Tivoli Monitoring and Tivoli Distributed Monitoring events. IBM Tivoli Business Systems Manager provides some built in functions to map these events to the appropriate object based on the profile name or product name. The gemdmmap.sh command is used to define or create distributed classes associated with Tivoli Distributed Monitoring or IBM Tivoli Monitoring resources. The generic object type is meant for representing any type of resource, and any event can be mapped. The gemgenprod.sh command is used to define/create generic resource classes. Each resource type can be associated with a specific icon. The product is shipped with a limited set of icons that can be used or custom GIF files icons can be used as well, if the customer provides them. Icons are associated to resource types by using the gemimageimport.sh command.
Forwarding events to IBM Tivoli Business Systems Manager

There are two ways to send resource and resource status information to IBM Tivoli Business Systems Manager using the Common Listener (CL) and IBM Tivoli Business Systems Manager adapters, or using Event Enablement (EE). This section mainly discusses the event forwarding using EE and TEC. Event Enablement is a IBM Tivoli Business Systems Manager component that is installed on the TEC server and provides APIs to forward events to IBM Tivoli Business Systems Manager. The API commands are:
28
ihsttsla ihstttec ihstztec ihstmtec
Forwarding IBM Tivoli Service Level Advisor events Forwarding generic TEC events Forwarding Distributed Monitoring events Forwarding APM events
The most common interface for using the event enablement is the ihstttec API call. It is intended for use in the IBM Tivoli Enterprise Console rules to send generic events to IBM Tivoli Business Systems Manager through the Agent Listener Service. Understanding the ihstttec syntax is one of the key aspects of integrating distributed event sources using into the IBM Tivoli Business Systems Manager. Once the resource types or object classes are defined using gemgenprod commands, TEC events can be mapped to these resource instances and forwarded to IBM Tivoli Business Systems Manager.
Defining resource placement in All Resource view

The All Resource View is where every discovered resource is displayed. The business system folders are built using the GUI drag-and-drop method, or by defining the ABS configuration files. Minor modifications or customization can be made by modifying the default values shipped with the product or more sophisticated structures can be specified using IBM Tivoli Business Systems Manager physical placement rules. These placement rules only provide Command Line Interface (CLI). Define where the instances of these object classes will be placed in the IBM Tivoli Business Systems Manager All Resources view. This can be done by defining the physical placement rules or by updating the SQL tables. Physical placement rules provide the capability of defining a parent tree for distributed resources at initial discovery. Placement rules are used when a new distributed resource instance is discovered and created in IBM Tivoli Business Systems Manager and shown by the All Resources display on the IBM Tivoli Business Systems Manager console. Placement rules can be associated with one or more distributed resource classes or requested at the resource instance level. Generic distributed resource classes can request a specific placement rule by specifying the -r rulename parameter on the ihstttec Event Enablement command.
Initial resource discovery

An instance of any resource type is created in the IBM Tivoli Business Systems Manager database. An icon will appear on the IBM Tivoli Business Systems Manager console only when an event is received about that resources instances.
29
Unlike z/OS resources, the IBM Tivoli Business Systems Manager distributed resources should not be inserted or defined using the IBM Tivoli Business Systems Manager Java console. Either an event or common listener discovery must happen so that the resource can appear in the All Resources view. Discovery of resources can take place naturally as to when the events from resources are received at the TEC server and forwarded to IBM Tivoli Business Systems Manager. This can take some time depending on the type of monitoring, the threshold levels specified, and the health of the resources. In order to build business system folders using the GUI drag-and-drop method, you need the resources in the All Resources view to drag and drop. business system folders that are configured using the ABS feature can be formed or created automatically as to when resource instances are discovered. In most cases, you need to force discovery of resources (often referred to as initial discovery), once the IBM Tivoli Business Systems Manager is installed and configured to proceed with the business system folder definitions. A command tecstatusconfig.ksh is provided to enable, display, and set the configuration options related to IBM Tivoli Business Systems Manager and TEC event status integration. Refer to the IBM Tivoli Business Systems Manager Command Reference, SC32-1243 for additional details on the command. To configure TEC status integration: Run tecstatusconfig.ksh to enable forwarding of status to TEC at the IBM Tivoli Business Systems Manager database server. Add the event classes and the rule manually or by running the $BINDIR/TDS/Event Service/config/tbsmstatus.sh script at the TEC server. Add the TEC change rule with the appropriate ihstttec API calls to forward the event to IBM Tivoli Business Systems Manager when the event status is changed at the TEC server. You can also customize behavior of duplicate events received at the TEC server at IBM Tivoli Business Systems Manager. Refer to the IBM Tivoli Business Systems Manager Administrators Guide, SC32-9085 for additional information.
Integrating Tivoli tasks or URLs

Tasks that exist in Tivoli task libraries can be associated with IBM Tivoli Business Systems Manager object types and can be invoked from the IBM Tivoli Business Systems Manager console on a resource instance. Tasks associated with an object type appear on the IBM Tivoli Business Systems Manager console under the menu item Operational Tasks. If the tasks do not already exist in the Tivoli environment, a Task library and Tasks should be created and tested on the Tivoli Desktop.
30
The implementation of Tivoli tasks can be performed using the information in Appendix E in IBM Tivoli Business Systems Manager Administrators Guide, SC32-9085. This utilize the wtll command to extract the task information and build it using the TLLParser command into IBM Tivoli Business Systems Manager. Additional implementation notes: The TLLParser command is not defined in the path. It is stored in <TBSM_home>\xdfparser\bin. If the Tivoli task expects parameters, the IBM Tivoli Business Systems Manager GUI will prompt for them. There is no way to automatically supply context specific information. IBM Tivoli Business Systems Manager does not handle tasks that require a script to be executed at task execution time to fill in a parameter for the task. When executing a task, the Task Library and target Endpoint or Managed Node name must be known in the Event Enablement host that run IBM Tivoli Business Systems Manager task server. A task will not execute unless the host against which the task is directed is a Tivoli Managed resource (Endpoint or Managed Node). When associating tasks with generic object types, care should be ensured the hostname slot in the discovery event for the corresponding generic object instances contain a Tivoli resource name that is a legal task target. When a task is first run, a prompt for a valid Tivoli user ID and password will appear. Similar to TME tasks, URLs associated with an object type appear on the IBM Tivoli Business Systems Manager console under the menu item operational tasks.
2.3.3 Common Listener interface

The implementation of the common listener interface is defined using the following steps: 1. Defining adapter on page 31 2. Customizing resource placement on page 32
Defining adapter
The intelligent monitor adapters connects to Common Listener server with a messaging queue technology that allows an efficient transaction even for a large number of transactions. The adapter are typically supplied by IBM Tivoli Business Systems Manager in the distributed edition CD-ROM or by the
31
monitoring software. The adapter must be configured to talk with the Common Listener service as shown in Figure 2-3.
Intelligent Monitor Adapter
transport.request.address transport.request.port transport.response.address transport.response.port
transport.server.mqe.address transport.server.mqe.port
Common Listener Server
transport.local.ip.address
transport.server.ip.address
Figure 2-3 Common Listener connection
As shown in Figure 2-3, the definition is performed in the agents property file. An extract is shown in Example 2-1.
Example 2-1 Excerpt of the adapter property file transport.local.ip.address = transport.request.address = transport.request.port = transport.response.address = transport.response.port = transport.server.mqe.address transport.server.mqe.port transport.server.ip.address vbudi vbudi.BASETEST.QM+BASETEST.Q 48323 vbudi.BASETEST.QM+BASETEST.Q 48323 = ServerQM+ServerQ = 8082 = 9.3.5.90
Customizing resource placement

For the Common Listener interface, the resources structure is determined by the adapter. The structure has been predefined and cannot be changed. It also conform to the containment hierarchy of IBM Tivoli Business Systems Manager. The only placement parameter is the Enterprise name that the instrumentation will be assigned to. This assignment is based on the content of the CL_AutoPlacement table. The content of our CL_AutoPlacement is shown in Figure 2-4.
Figure 2-4 Content of CL_AutoPlacement table
32
2.3.4 Upgrading or migrating from previous releases

When you upgrade from IBM Tivoli Business Systems Manager Version 2.1.1 Fix Pack 6 and you want to upgrade the existing databases, you can select Upgrade existing 2.1.1 fixpack 6 database from the wizard. Upgrading is the only way to keep the data that is in the existing databases. The time it takes to upgrade depends on the size of the database and the feeds used. You can always redo the discovery and customization. When the databases are updated, the setup program does a brief verification to ensure that is has the service from IBM Tivoli Business Systems Manager V2.1.1 Fix Pack 6. If the check fails, the setup program alerts you. Exit the program and ensure that V2.1.1 Fix Pack 6 is installed. Important: Contact IBM software support for assistance. Do not proceed with the upgrade until the problem has been resolved. If IBM Tivoli Business Systems Manager V2.1.1 fix packs that were shipped after the availability of IBM Tivoli Business Systems Manager V3.1 were installed or if the prerequisite software hasnt been installed, the installation program notifies us with the following message: Your database is not at the prerequisite level to install Tivoli Business Systems Manager 3.1. This means fix packs have been applied that might not be compatible with the database upgrade process. You can check the list of FixPack installed using the following SQL query:
SELECT * FROM imSnapshotHistory
2.3.5 Uninstalling IBM Tivoli Business Systems Manager

To uninstall IBM Tivoli Business Systems Manager, follow the uninstall procedures documented in the IBM Tivoli Business Systems Manager Installation and Configuration Guide, SC32-9089. You need to perform the following: Uninstall the Java Console Remove or stop any event feeds, such as intelligent adapters, TEC rulebase with event enablement exit or Source/390 Uninstall the Tivoli Business Systems Manager base services You can uninstall the Event Enablement component from the TEC server, using the remove command. This command uninstalls event enablement, including the task server from the TEC server. Refer to IBM Tivoli Business Systems Manager Command Reference, SC32-1243 for more information.
33
2.4 Defining business systems

Configuration and implementation of IBM Tivoli Business Systems Manager Automated Business Systems (ABS) can be a challenging task. This section attempts to introduce the basic ABS configuration and provide simple examples that can be used in understanding the ABS feature. Refer to IBM Tivoli Business Systems Manager: Administrators Guide for additional features and explanations. Creating business system folders using the drag-and-drop or GIU is easy, can be ad hoc, and is flexible. However, the business system folders created using this method can be error prone, the contents are static, and can be labor intensive to maintain. The business system folders can address these limitations. Defining business system folders using the ABS requires design effort, understanding the resource naming conventions, and testing. When deciding whether to use the GUI drag-and-drop or the ABS API or XML toolkit to create the business system folders, consider the following: Use drag-and-drop if: A static set of resources belong in the Business System There are a lot of dependencies between resources There are no naming conventions or predictable attribute patterns Use ABS if: The Business System contains numerous similar type instances New instances will be added to the Business System on a regular basis Placement or selection criteria of resources can be determined algorithmically Hierarchical structure is simple Use XML if: Business system structure is defined in an external repository without respect to any naming convention Resource is constantly added and removed from business system folders but not deleted Program logic can be developed to derive the business system folder structure
34
2.4.1 Automated business system processing overview

Once the business system folders are identified as candidates for implementing using the ABS feature, start with a simple one before attempting a more complex business system folder. The automated business system feature involves the following steps: 1. Identify business system folders structure Understand the business system folder structure and identify the resources. Come up with the structure, groupings, hierarchy, relationships between various resources, and attributes of resources that provide information for selection criteria. 2. Identify resources and its placement in the structure Identify what resources should be placed at each level within the business system folder, what attributes are available for each resource that can be used (such as Name, Description, Data1, ...3, IP Address, hostname, and so on), whatever naming convention exists, or can be derived and used in determining selection and placement. Note: The absAllowedClassAttribute command will provide the list of attributes available for each resource type. 3. Develop the automated business system configuration file Start with the existing automated business system configuration by running the command absConfig.ksh -o output_file. Modify and fill in the definition entries. 4. Test the automated business system configuration file a. Enable IBM Tivoli Business Systems Manager SQL Server job Update ObjPathCache, and disable jobs ABS Discovery process, and ABS creation process. b. Load the ABS configuration file using the command absConfig.ksh -i <configuration file>. A successfully loaded configuration file will remove any previous configuration. Old configuration is backed up in TBSM_home\logs\abs.backup.yyyymmdd_HHMMSS.txt. c. Manually run the discovery process and test the configuration file using the command absTest.ksh -x -t <pattern_id> -r <criteria_id> -n <path_id>, and verify the responses. Note: The absTest.ksh must have at least one of the -t, -r, or -n parameters. Leaving one or two parameters out will be less restrictive and will likely require longer processing times
35
d. Once responses are verified, then issue absTest -e command to queue the discovered business system folders, and then run the creation job ABS Creation job manually. 5. Verify Business Systems creation using Java console Verify that the business system folders are created by logging into IBM Tivoli Business Systems Manager and viewing the business system folders. 6. Install automated business system configuration file in production. When the updated ABS configuration file is thoroughly tested and verified, enable the jobs ABS Discovery Process and ABS Creation Process for automatic population of resources into the business system folders at instance creation time.
2.4.2 XML processing overview

The XML processing steps can be defined as follows: 1. Load XML toolkit programs on the machine that has access to the configuration repository that the XML information will be based on. 2. Verify that Common Listener server is active. 3. Develop programs that reads from the configuration repository and writes output to text XML files. 4. Load XML file using the enqueuecl command. 5. Verify the status using the querycltran command 6. Verify the business system created using the Java console.
36
Chapter 3.
Building business systems: design, concepts and implementation

This chapter contains general considerations in building business systems for IBM Tivoli Business Systems Manager. We discuss business systems planning through to the implementation aspects. This chapter presents the following topics: 3.1, Business systems design methodology on page 38 3.2, Piggybank, Inc. background on page 40 3.4, Using Automated Business System on page 46 3.5, XML interface for business system on page 67
37
3.1 Business systems design methodology

This section describes the basic methodology for designing business systems. 3.1.1, Terminology and definitions on page 38 3.1.2, Methods for creating business systems on page 38 3.1.3, Important considerations on page 39
3.1.1 Terminology and definitions

A business system is a logical representation of the physical and logical components that support a business process. Typically, an IBM Tivoli Business Systems Manager business system consists of: All business components that together perform a specific business function The defined relationships between business components The measures that determine whether the business system is functioning properly The following are definitions that relate to business systems: Physical resource Business system resource Business system folder This is a resource object residing in the All resources tree. This is a copy of a physical resource that resides in the business system tree. This is a folder or container that contains business system resources; typically a business system folder represents a business entity. This is a copy of a business system folder so that it can be reused in a different portion of the business system tree.
Business system shortcut
3.1.2 Methods for creating business systems

There are three methods which can be used to create IBM Tivoli Business Systems Manager business systems. Drag-and-drop This method involves manually dragging physical resources from the physical tree and dropping them into a business system folder. This method allows for easy business systems creation. Business systems created using this method are static and its maintenance remains a manual process. The drag-and-drop method is not effective for large or complex business systems.
38
Automated Business Systems (ABS) Business system structure created using this method are created and maintained using configuration file in which the business system folders, the business system resources, and their behaviors are defined using a predefined format. When an ABS configuration file is created and loaded, new and current resources can be automatically discovered and added to the business systems you defined, greatly reducing any manual maintenance. ABS does not provide any facility for removing or reassigning resources from the business systems it has created. The ABS method requires upfront design and configuration to ensure the correct business systems are created with the proper resources contained within them. It also requires that resources are created based on a certain naming convention to facilitate simple filters. XML toolkit Much like ABS, the XML toolkit provides a way to automatically create business systems. Business systems created using the XML toolkit are defined manually by XML links. XML files must be submitted in order to add or modify business systems. The XML toolkit allows removal and reassignment of business systems, or any of the resources it creates. It cannot dynamically affect business systems created using an ABS configuration file. We recommend using the XML toolkit in cases where resources may need to be dynamically reassigned between different business systems and source information exists to build the business systems XML file. Important: The use of ABS and XML toolkit cannot be used interchangeably within the context of a business system. Use ABS to maintain all of the resources within business systems created using ABS, and the XML toolkit to maintain the business systems created using the XML toolkit.
3.1.3 Important considerations

When designing a business system, it is important to consider the following: Preparation is paramount, the more prepared you are when building your ABS configuration file, and XML Toolkit transactions, the easier and more accurate your business systems will be. It is important to involve the IBM Tivoli Business Systems Manager Console users early and as often as possible. Allowing the users to participate in design sessions will help ensure the resulting business systems represent their resources intuitively. Reduce the amount of maintenance required by generating and maintaining as much as possible using the ABS, and the XML Toolkit.
Chapter 3. Building business systems: design, concepts and implementation
39
Where possible, keep your business systems as simple as possible. Simple business systems are generally more intuitive, and display better under hyperview modes. Ensure your IBM Tivoli Business Systems Manager environment is being backed up on a regular basis. It is also a good idea to take backup snapshots of the IBM Tivoli Business Systems Manager database prior to beginning any involved maintenance or configuration. Create sensible naming conventions. These should be considered carefully because Business Systems may be reused. Gathering as much data as possible regarding your environment will help ensure you are prepared to build appropriate business systems. The types of documentation you should look to collect include: Network and system documentation Identify the author(s) of the business system Identify the audience for the business system Identify the purpose of the business system Identify the scope of the business system Identify any appropriate functional experts
3.2 Piggybank, Inc. background

The business system design in this chapter uses a fictituous online banking institution called PiggyBank, Inc. This section explains the structure of PiggyBank, Inc. The description consists of: 3.2.1, Data centers on page 40 3.2.2, Piggybank resources on page 41 3.2.3, Piggybank applications on page 42
3.2.1 Data centers

Piggybank, Inc. has three main offices: Austin TX, the operational support and primary data center. Los Angles, the application support and systems backup site. New York City, the database and customer service support office. The structure is shown in Figure 3-1 on page 41.
40
New York
Los Angeles
Austin
Figure 3-1 PiggyBank inc data centers
3.2.2 Piggybank resources

We have gathered information regarding Piggybank resources, including their primary role, and their physical locations. Table 3-1 represents the servers and resources located in the Austin data center.
Table 3-1 Austin data center machines Server Name AUSFINA06 AUSFIN07 AUSHRA03 AUSWHA02 AUSAPP01 AUSAPP02 AUSAPP03 AUSAPP04 OS AIX AIX AIX AIX AIX AIX AIX AIX Resource AR01 AP01 HIR001 WHAUS01 ELAUS01 ELAUS02 EBAUS01 EBAUS02 Function Accounts Receivable Application Server Accounts Payable Application Server Human Resources Recruiting Application Server Warehouse Application Server eLoans Application Server eLoans Application Server eBanking Application Server eBanking Application Server
41
Server Name AUSFINDB05 AUSWHD01 AUSHRD04 AUSESD06
OS AIX AIX AIX AIX
Resource FINDB01 FINDB02 WHDB PAY001 HIR001 ELAUSDB01 EBAUSDB01
Function Accounts Payable/Receivable databases Data Warehouse Human Resources Payroll/Recruiting database eLoans/eBanking databases
Table 3-2 represents the servers and resources located in the Los Angles remote facility.
Table 3-2 Los Angeles office machines Server Name LAWHA01 LAMKTD02 LAMKTD03 LABKUP01 LABKUP02 LAESBKUP07 OS Win AIX AIX AIX AIX AIX Resource WHLA01 MKTLA02 MKTLADB02 MKTLA03 MKTLADB03 ELLA03 EBLA03 ELLADB02 EBLADB02 Function Warehouse system Sales and Marketing Applications/Database Server Sales and Marketing Applications/Database Server eLoans Backup Application Server eBanking Backup Application Server eBanking/eLoans Backup Database Server
Table 3-3 represents the servers and resources located in the New York remote facility.
Table 3-3 New York office machines Server Name NYWHA01 NYMKTD02 OS AIX AIX Resource WHNY01 NYMKT01 MKTNYDB Function Warehouse system Sales and Marketing Applications/Database Server
3.2.3 Piggybank applications

Piggybank Inc. has several critical applications. These applications need to have business system defined. The applications are:
42
eLoan services The eLoan Services application provides Piggybank, and potential Piggybank customers the ability to apply for loans of varying types with Piggybank. This is a critical application and must be available 24x7. eBanking services The eBanking Services application provides Piggybank account holders Internet access to their accounts. Using the eBanking Web site, current customers have the ability to perform any Piggybank transaction over the Internet. This is a critical application and must be available 24x7. Customer management The Piggybank Customer Management application provides Customer Service Representatives with up to date Customer account details. The Customer Management application must be available from 08:00am to 8:00pm Monday through Friday. Warehouse system The warehouse system must be available on primary shift to ensure that all requests can be supplied promptly. Marketing information system As marketing information frequently changes, customer services must be promptly equipped to handle this information through the marketing information system. This application must be available from 08:00am to 8:00pm Monday through Friday. Human resource application The human resource application support recruiting, personnel changes and payroll application. This application must be available from 08:00am to 8:00pm Monday through Friday.
3.2.4 Console users

The users in Table 3-4 on page 43 are identified to use IBM Tivoli Business Systems Manager console applications.
Table 3-4 Console users User role Executive Business application managers Requirement Overall status of Piggybank Inc. applications and data centers in executive view Status of Piggybank Inc. application aggregate in executive view
43
User role Application owners Data center manager Database administrator Application server administrators Help desk Network administrator Web master
Requirement Application business system folder Status of resources in data center Status of databases Aggregate status of application server Shortcuts of systems by resources and by applications Network devices Web server resources
3.2.5 Monitoring environment

In Piggybank, Inc., the following applications manage the monitoring: Application servers are monitored using an application that has interface to IBM Tivoli Enterprise Console. The newly generated class for this application server object is G02M. Database servers are monitored using Network resources are monitored using Web server are monitored using IBM Tivoli Monitoring for Web Infrastructure The interface for getting resources in IBM Tivoli Business Systems Manager is decided to use the following: Agent listener interface for managing Application Servers, Databases and Web Servers. Common listener interface for network resources.
3.3 Mapping enterprise to business system

This section discusses the transformation and mapping of Piggybank Inc. business systems. First, we look at the business systems that must be created based on the user requirement. This requirement is shown in Table 3-5.
44
Table 3-5 Business system requirement User role Executive Help desk Business application managers Application owners Business system folder Applications DataCenters eLoan eBanking CustomerManagement Warehouse HumanResource MarketingInformation Austin LosAngeles NewYork Databases ApplicationServers Network devices WebServers
Data center manager
Database administrator Application server administrators Network administrator Web master
Further refinement of the business system folders must show the resources that will be created under each business system folders. The resource list is given in Table 3-6.
Table 3-6 Resource assignment for business system folders Business system folder Applications DataCenters eLoan Appl eBanking Appl CustomerManagement Appl Warehouse Appl Contents Short cuts of application business systems Shortcuts of data centers resources Database and application server for eLoan Database and application server for eBanking Database and application server for Customer Management Database and application server for Warehouse system
45
Business system folder HumanResource Appl MarketingInformation Appl Austin Data Center LosAngeles Data Center NewYork Data Center Databases ApplicationServers Network devices WebServers
Contents Database and application server for Human Resource Database and application server for Marketing Information Servers and resources in Austin Servers and resources in Los Angeles Servers and resources in New York All databases All application servers All network interfaces and routers Web servers machines
Based on the available interfaces and the nature of the business system, we decided to use the following interfaces: Build ABS definition for most of the business systems, as these resources are mostly statically defined. This is discussed in 3.4, Using Automated Business System on page 46. Use XML interface for Network devices business system and Web servers. The usage of XML interface for network devices is discussed in 3.5, XML interface for business system on page 67. While the Web servers deployment is utilizing IBM Tivoli Intelligent Orchestrator. This is discussed in Chapter 6, Using IBM Tivoli Intelligent Orchestrator to populate business systems structure on page 165.
3.4 Using Automated Business System

The Automated Business System (ABS) configuration file is a tab delimited text file. We recommend the use of a spreadsheet application such as OpenOffice, Lotus 123, or Microsoft Excel to create and maintain this file. All of the aforementioned spreadsheet applications have the ability to import and export a tab delimited text file. 3.4.1, Before defining business system on page 47 3.4.2, Designing Piggybank business system folders on page 48 3.4.3, Defining Automated Business System configuration on page 52
46
3.4.4, Loading the ABS configuration file on page 59 3.4.5, More about functions on page 62
3.4.1 Before defining business system

The command absConfig.ksh is used to export and import ABS configuration. Running absConfig.ksh to export ABS configuration generates a tab delimited file from the active ABS configuration. The first time an export is performed, an empty ABS configuration is generated, this can be used as a template for generating ABS configuration. We run the following command to generate an ABS template called PiggybankABS.txt.
absConfig.ksh -oPiggybankABS.txt -Spretoria -Usa -Upassword
Note: We highly recommend to use the aforementioned spreadsheet applications to edit ABS configuration file. When using a spreadsheet application make sure you save, or export the file as a tab delimited text file We will need to have a list of class attributes for defining the business system selection pattern. This class attributes is retrieved using absAllowedClassAttribute.ksh command. The command is as follows:
absAllowedClassAttribute.ksh -oPiggybankClasses.txt -Spretoria -Usa -Ppassword
The output from the absAllowedClassAttribute.ksh is organized by class name. Example 3-2 on page 48 shows the class G02N attributes available for evaluation using an ABS configuration.
47
cid G02N G02N G02N G02N G02N G02N G02N G02N G02N G02N G02N G02N G02N G02N G02N G02N G02N G02N G02N G02N
a ttribute Data1 Data2 Data3 Data4 Des c E E hos t E P TTM R HeartbeatInterval Ins tanc eID Las tHbTim es tam p M anufac turer M gedS y s tem Nam e P revious Dis play Nam e P riority ID P roduc t TCP Hos t V ers ion c l_ins tid c tim e nam e
cna m e G02Nc nam e G02Nc nam e G02Nc nam e G02Nc nam e G02Nc nam e G02Nc nam e G02Nc nam e G02Nc nam e G02Nc nam e G02Nc nam e G02Nc nam e G02Nc nam e G02Nc nam e G02Nc nam e G02Nc nam e G02Nc nam e G02Nc nam e G02Nc nam e G02Nc nam e G02Nc nam e
product Databas e Databas e Databas e Databas e Databas e Databas e Databas e Databas e Databas e Databas e Databas e Databas e Databas e Databas e Databas e Databas e Databas e Databas e Databas e Databas e
ve rsion 1.0 1.0 1.0 1.0 1.0 1.0 1.0 1.0 1.0 1.0 1.0 1.0 1.0 1.0 1.0 1.0 1.0 1.0 1.0 1.0
Figure 3-2 Class attributes list sample
3.4.2 Designing Piggybank business system folders

In this section, we discuss the detail on creating the eLoan business system folder and the resource specific business system folders. Note: The simplified examples in this section are designing some of the business system folders. Similar procedure must be performed for each and every business system folders. The design that we use will use the following procedure: We choose not to implement Percentage Based Threshold (PBT) if possible as PBT is an additional processing that may not be necessary when we can configure the appropriate propagation scheme. In this example the application servers and databases has only on/off status (Green/Red), we are not considering having a degraded resource. The business system folders that we create are: The Piggybank eLoan application on page 49 Application Servers and Databases business system folders on page 52
48
The Piggybank eLoan application

The Piggybank eLoan Application uses redundant application servers located in Austin. If one of the primary application servers is unavailable the application services will continue to be available using the remaining primary application server. A backup application server located in Los Angles serves as the backup application server should both primary application servers fail in Austin. The eLoan application uses a primary database in Austin, if the primary database is unavailable the backup database located in Los Angles will serve as the primary. The illustration below represents the Piggybank eLoan application architecture.
ELAUS01 AUSAPP01
ELAUS02 AUSAPP02
ELLA03 LABKUP01
ELAUSDB01 AUSESD06
ELLADB02 LAESBKUP07
Figure 3-3 Piggybank eLoan application architecture
We can start mapping out our Path for an eLoan business system. Based on the application architecture, we can define several scheme on how to map the eLoan into business systems, such as: Have all resources mapped to a single business system folder Have two separate business system folders for the primary and backup system Splitting the application servers and databases into their respective business system folders The options are shown in Figure 3-4 on page 50.
49
eLoan Application ELAUS01 ELAUS02 ELLA03 ELAUSDB01 ELLADB02
eLoan Application ELAUS01 primary ELAUS02 ELAUSDB01
eLoan Application ELAUS01 Appl servers ELAUS02 ELLA03
ELLA03 backup ELLADB02 databases
ELAUSDB01 ELLADB02
Option 1 flat
Option 2 by function
Option 3 by resource type
Figure 3-4 Options for the eLoan business system
The actual decision on how the business system folder structure is determined by the users needs, such as: If all the resources are considered equally important, and individual resources affecting the business system similarly, we can have all resources mapped to a single business system folder If the users needs to be able to distinguish whether this problem applies to the primary set or the backup set, the separation of primary and backup set is recommended If the users want to see whether the databases or application servers that causes the problem, then separation by resource type may be desirable Combination of the approaches above may also be necessary to accommodate user needs or defining two or more business system folders to satisfy different user needs may be needed. Another requirement that arises is that the eLoan business system is meant to have a shortcut in the Applications business system folders that show the health of all PiggyBanks applications. What we decide is to have the hierarchy shown in Figure 3-5 on page 51.
50
Applications
Application-eLoan
Application-eLoan
Application-eLoan-Primary
ELAUS01
ELAUS02
ELAUSDB01
Application-eLoan-Backup
ELLA01
ELLADB02
Figure 3-5 Business system folder for eLoan application
In the hierarchy shown in Figure 3-5, the following functions must be realized: The Applications business system folders has all the shortcuts with the priority of Critical, therefore any application that is failed will make Applications Red. The eLoan business system folder goes to Red if and only if both the primary and backup are red and goes to yellow if the primary is red and the backup is green. Yellow status does not affect the primary eLoan business system folder The Primary business system folder goes to red if any of the database failed or the both the application servers are Red, if one of the application server is red it will be yellow. The Backup business system folder goes to red if any one of its components is failing.
51
Application Servers and Databases business system folders

For the business systems that is based on a selection criteria, such as all databases, we can create a simpler business system folder such as shown in Figure 3-6.
Application Servers
ELAUS01 ELAUS02 ELLA01
Databases
ELAUSDB01 ELLADB02
Figure 3-6 Application Servers and Databases folders
These folders has a single layer of resources and alerts the appropriate resource administrator when any resource is failing. As there are primary sets of application servers and databases and backup sets of them, it is appropriate that we have the resources also grouped appropriately. The rules for these folders are: We use 10% of failure to be Yellow and 25% to be Red for both primary Application Servers and Databases. Backup servers has the threshold of 50% to be Yellow and 75% to be Red A primary or backup group immediately affect the parent
3.4.3 Defining Automated Business System configuration

This section writes up the design we have in to an ABS configuration file. In this example we only use the eLoan application described in The Piggybank eLoan application on page 49. Creating Path definition on page 53 Selecting resources with Patterns on page 54 Associating patterns with paths using criteria on page 55
52
Defining functions on page 56
Creating Path definition

The most logical start on defining your configuration file is the Path section. It transform the picture design into a tree like definition. We use the business system structure shown in Figure 3-5 on page 51 and Figure 3-6 on page 52 to develop the necessary path structure. We transfer those figures to Figure 3-7.
Applications
APPL_BS
Application-eLoan
Application-eLoan ELOAN_PRIM
Application-eLoan-Primary
ELAUS01
ELOAN_BKUP
ELAUS02
ELAUSDB01
Application-eLoan-Backup
ELLA01
ELLADB02
Figure 3-7 Path definitions
As shown in Figure 3-7, a named path is a flow for the business system folder hierarchy after the Business Systems Container until it reaches a certain dynamic business system resource object. Although the business system structure allows a path to contain more than 1 level of business system resource object, we are not using it. Based on the path names that is defined in Figure 3-7, the partial path definition that we use is shown in Figure 3-8 on page 54.
53
Path Path Level Name Description # -----------------------------------------------# Aggregates # -----------------------------------------------APPL_BS 1 Applications APPL_BS 2 # -----------------------------------------------# e-Loan application # -----------------------------------------------ELOAN_PRIM 1 Application-eLoan ELOAN_PRIM 2 eLoan-Primary ELOAN_PRIM 3 ELOAN_BKUP 1 Application-eLoan ELOAN_BKUP 2 eLoan-Backup ELOAN_BKUP 3
FunctionGroup
Figure 3-8 Excerpt of path definition
Note that the path name that we use in the example follows our naming convention. The path name can be chosen arbitrarily as it is meant only for the readability of the ABS configuration file. It will not be shown in any IBM Tivoli Business Systems Manager console.
Selecting resources with Patterns

Now that we already know the paths, we assign what resources need to be at the dynamic end of the paths. Table 3-7 shows the association of path names and level to the appropriate resources.
Table 3-7 Business system resource assignment Path name APPL_BS ELOAN_PRIM ELOAN_BKUP Level 2 3 3 Content Business System Folder (LOB) AppServer;1.0 (G02M) Database;1.0 (G02N) AppServer;1.0 (G02M) Database;1.0 (G02N)
Based on Table 3-7, we can define the patterns. Patterns are condition statements or filters that we use to evaluate attributes of physical resources for matching. Patterns are identified by a number. Typically pattern numbers starts from 1. Referring to resource attributes similar to Figure 3-2 on page 48, the patterns that we create is shown in Figure 3-9 on page 55.
54
Pattern Pattern . . . . 6 . . . . 10 11 12 13 14 15
Class Attribute . . . . . . LOB name . . . . . . G02M name G02N name G02M name G02N name G02M name G02N name
When
Operator
Operand1 Application-% ELAUS0% ELAUSDB% ELLA0% ELLADB% %BKUP% %BKUP%
Operand2
Current LIKE Current Current Current Current Current Current LIKE LIKE LIKE LIKE NOT LIKE NOT LIKE
Figure 3-9 Pattern definition
Associating patterns with paths using criteria

The filtering condition that we define as patterns must now be associated to a place in the path. The association is utilizing criteria. There are two sections that criteria are defined, the CriteriaToPattern section and CriteriaToPath. The CriteriaToPattern groups multiple pattern into a single criteria in order to have an association of multiple patterns, such as related patterns (AND condition) or un-related patterns (OR condition). The CriteriaToPattern section introduces the Criteria column in the configuration file. Criteria relates patterns from the Pattern section. The CriteriaToPattern section also provides the ability to force an AND behavior between two patterns to be used in discovering resources. The CriteriaToPattern that we use is shown in Figure 3-10.
CriteriaToPattern Criteria Pattern PatternRelated 1006 6 6 1010 10 14 1010 14 14 1011 11 15 1011 15 15 1012 12 12 1012 13 13
Figure 3-10 Criteria to pattern correlation
From Figure 3-10, lets evaluate some of the criteria: Criteria 1006 only uses pattern 6. In Criteria 1010, when pattern 10 is met, pattern 14 must also be met in order to make criteria 1010 fulfilled. Therefore enforcing an AND condition. In Criteria 1012, pattern 12 and pattern 13 can be met independently of each other to fulfill criteria 1012. Therefore providing an OR relation for pattern 12 and 13.
55
Now we need to associate these criteria to a certain place in the business system structure path. This is accomplished using the CriteriaToPath section. This section provides the matched pattern and criteria to be put to a certain level of the path. Our CriteriaToPath section is shown in Figure 3-11.
CriteriaToPath Criteria Path 1006 APPL_BS 1010 ELOAN_PRIM 1011 ELOAN_PRIM 1012 ELOAN_BKUP 1012 ELOAN_BKUP
Level 2 3 3 3 3
Pattern 6 10 11 12 13
Variable name name name name name
Value <6:name> <10:name> <11:name> <12:name> <13:name>
FunctionGroup
Figure 3-11 Criteria to path section
From Figure 3-11, when criteria is matched with paths based on the primary matching pattern. The CriteriaToPath section also provides a means of mapping certain field with substituted content. Note: Substituting content without any necessary benefit of distinguishing resource should not be performed. It may create confusion as the same resource having different names. The example we have in Figure 3-11 on page 56 does not change the content of the name. Some notes on the criteria definition: The substitution field does not necessarily come from the same pattern as the pattern column, but it must be on a related pattern as defined in CriteriaToPattern section. The pattern defined in the CriteriaToPath section must has the class object the original physical object that is expected to be in the path. Related patterns may have different object class, however, for the relation to be met, they have to be in a single path. Alternatively we can define a pattern that each for G02M and relate it to an network location (NLOC) object that own the G02M resource.
Defining functions
In this redbook, we will not show all the facilities related to functions. You can read most of these functions in IBM Tivoli Business Systems Manager Administrators Guide, SC32-9085. We illustrate here the functions needed for the conditions of the folders as presented in 3.4.2, Designing Piggybank business system folders on page 48.
56
Functions are identified by its instances and applies to business system folders or business system resources by the means of function groups. There are three places that function groups can be defined, those are: Path definition: The function group defined in the path specify function group that is associated to a particular business system folder Criteria to path definition: The function group defined in the Criteria to path section specifies a function group that is associated to business system resources on that particular path entry. This also defines whether you want the same path to be used for multiple resource type or not. If you need different function set, then you must have separate path definition to allow a function group to be defined differently. Pattern definition: The function group defined in the pattern section specifies function group that is associated whenever a condition is met, regardless of the position or role of the object in the business system tree. This function group is not tied in to a path. Table 3-8 list the behavior that we wanted and summarizes the required functions to implement the behavior.
Table 3-8 Function requirement Desired behavior The Applications business system folders has all the shortcuts with the priority of Critical, therefore any application that is failed will make Applications Red. The eLoan business system folder goes to Red if and only if both the primary and backup are red and goes to yellow if the primary is red and the backup is green. Yellow status does not affect the primary eLoan business system folder The Primary business system folder goes to red if any of the database failed or the both the application servers are Red, if one of the application server is red it will be yellow. Functions needed SetBSPriority to Critical for all the shortcut DefineServicesandLinkToEvUser is assigned for the Application business system folder This must be implemented with PBT. DefineAndUsePBT to set 25% Yellow and 50% to Red SetBSPriority to Ignore for the Primary and Backup business system folders SetWeight to 150% for Primary This must be implemented with PBT. DefineAndUsePBT to set 25% Yellow and 50% to Red SetBSPriority to Ignore SetWeight to 75% for Application Servers SetWeight to 150% for Database This can be done without PBT. SetBSPriority to Critical
The Backup business system folder goes to red if any one of its components is failing.
Based on Table 3-8, the configuration file sections for CriteriaToPath and Path are modified into Figure 3-12 on page 58.
57
Path Path Level Name Description # -----------------------------------------------# Aggregates # -----------------------------------------------APPL_BS 1 Applications APPL_BS 2 # -----------------------------------------------# e-Loan application # -----------------------------------------------ELOAN_PRIM 1 Application-eLoan ELOAN_PRIM 2 eLoan-Primary ELOAN_PRIM 3 ELOAN_BKUP 1 Application-eLoan ELOAN_BKUP 2 eLoan-Backup ELOAN_BKUP 3
CriteriaToPath Criteria Path 1006 APPL_BS 1010 ELOAN_PRIM 1011 ELOAN_PRIM 1012 ELOAN_BKUP 1012 ELOAN_BKUP
FunctionGroup
APPL_BS_func
ELOAN_APPL_func ELOAN_PRIM_func
ELOAN_BKUP_func
Level 2 3 3 3 3
Pattern 6 10 11 12 13
Variable name name name name name
Value <6:name> <10:name> <11:name> <12:name> <13:name>
FunctionGroup APPL_BS_obj_func ELOAN_PRIM_AS_func ELOAN_PRIM_DB_func ELOAN_BKUP_AS_func ELOAN_BKUP_DB_func
Figure 3-12 Modification of CriteriaToPath and Path sections
The function groups defined in Figure 3-12 must be defined. Each function group contains the functions listed in Table 3-8 on page 57. The resulting function group definition is shown in Figure 3-13 on page 59. Function group names are arbitrary. We use the name to reflect which section they are defined from and use the identifier attribute of the section to be used for the name. Function names should be associated with function group name as most function names can be reused.
58
FunctionGroup FunctionGroup APPL_BS_func ELOAN_APPL_func ELOAN_APPL_func ELOAN_APPL_func ELOAN_APPL_func ELOAN_PRIM_func ELOAN_PRIM_func ELOAN_PRIM_func ELOAN_PRIM_func ELOAN_PRIM_func ELOAN_PRIM_func ELOAN_BKUP_func APPL_BS_obj_func ELOAN_PRIM_AS_func ELOAN_PRIM_DB_func ELOAN_PRIM_AS_func ELOAN_PRIM_DB_func ELOAN_BKUP_AS_func ELOAN_BKUP_DB_func
FunctionName DefineServicesandLinkToEvUser DefineAndUsePBTs DefineAndUsePBTs DefineAndUsePBTs DefineAndUsePBTs DefineAndUsePBTs DefineAndUsePBTs DefineAndUsePBTs DefineAndUsePBTs SetBSPriority SetWeights SetBSPriority SetBSPriority SetWeights SetWeights SetBSPriority SetBSPriority SetBSPriority SetBSPriority
Instance Appl_BS_ev YellowSet25 YellowClear25 RedSet50 RedClear50 YellowSet25 YellowClear25 RedSet50 RedClear50 BSIgnore Weight150 BSIgnore BSCritical Weight075 Weight150 BSIgnore BSIgnore BSCritical BSCritical
Figure 3-13 Function group definition
Individual functions are then defined in their respective section. The definition is shown in Figure 3-14.
DefineAndUsePBTs Instance PBTName
Relevance Enabled
MinAlert State 1 1 1 1 red red red red
MaxAlert State red red red red
Min Pct. 25 0 50 0
Max Pct. 100 24 100 49
Event EventName Type excp excp excp excp SetYellow25 SetYellow25 SetRed50 SetRed50
EventText
Event Event AlertState Priority Yellow Green Red Green critica l low critical low
YellowSet25 YellowClear25 RedSet50 RedClear50 SetWeights Instance Weight075 Weight150
YellowSet25 YellowClear25 RedSet50 RedClear50
50 50 100 100
Yellow 25% Yellow 25% Red 50% Red 50%
NewWeight 75 150
DefineServicesAndLinkToEvUsers Instance DisplayName ServiceID Business RedImpact Yellow Role Impact APPL_BS_ev Applications appls PiggyBank failed degraded applications
Flags 1
UserIDGroup
SetBSPriority Instance BSIgnore BSCritical
NewPriority IGNORE CRITICAL
Figure 3-14 Function definitions
3.4.4 Loading the ABS configuration file

We will loading the ABS file by accessing the IBM Tivoli Business Systems Manager database server and running the absConfig.ksh script. If an ABS
59
configuration file is loaded in error, or the business systems created are not correct the absDelete.ksh script can be executed to remove the business systems created using the active ABS configuration. Refer to the IBM Tivoli Business Systems Manager Command Reference, SC32-1243, for additional information about the absDelete.ksh script. Before we load the ABS file, we must disable the ABS Discovery, and ABS Creation jobs in SQL Server to prevent any chance of corruption. To disable these ABS jobs use the SQL Enterprise Manager. Select the Microsoft SQL Servers SQL Server Group <server name> Management SQL Server Agent Jobs. Select the jobs, right-click and select Disable job as shown in Figure 3-15.
Figure 3-15 Disabling the jobs
Once the ABS jobs are disabled, we can load the configuration text file using absConfig.ksh. Use the command:
absConfig.ksh -iPiggybankABS.txt -Spretoria -Usa -Ppassword
If the load is successful, the message Processing Complete. is shown. Once the file is loaded we enable the ABS jobs back as shown in Figure 3-16 on page 61
60
Figure 3-16 Enable ABS jobs
With the ABS file loaded and the ABS jobs enabled, the ABS jobs will now correctly discover any new resources and populate our configured eLoan business system. To force the discovery of resources that existed in our IBM Tivoli Business Systems Manager database prior to the successful load of our ABS file, we run absTest.ksh. To execute the absTest.ksh, we access the IBM Tivoli Business Systems Manager database server and from a shell prompt execute the absTest.ksh as follows:
absTest.ksh -Spretoria -Usa -Ppassword -nPB_APPL_ELOAN_AS
The execution of absTest.ksh script will select resources that matched the mentioned path. We can then run absTest.ksh script a second time to process the manual queue, and create the business system using the -e option as follows:
absTest.ksh -Spretoria -Usa -Ppassword -e
61
Note: When absTest.ksh script is run to discover resources it places the discovered resources in a manual queue. This manual queue is cleared and replaced during each execution of absTest.ksh script that discovers resources. It is important to remember to process this queue after each discovery by be executing the absTest.ksh script with the -e parameter. Refer to the IBM Tivoli Business Systems Manager Command Reference, SC32-1243. Figure 3-17 shows a window of the Piggybank eLoan business system.
Figure 3-17 Completed eLoan business system
3.4.5 More about functions

This sections discussed the functions. As we see in 3.4.3, Defining Automated Business System configuration on page 52, functions provides an important feature to manipulate the behavior of business system structure. Although, each function has its own specific behavior, we have seen that specific behaviors are needed with a combination of functions. The following manipulation behavior of business systems are typically needed: Specifying Percentage Based Threshold on page 62 Defining a specific propagation behavior on page 65 Assigning executive view behavior on page 66 Enabling state change event on page 67 We discuss each behavior in their respective sections.
Specifying Percentage Based Threshold

The percentage based threshold feature in IBM Tivoli Business Systems Manager V3.1 greatly enhanced the ability to influence the propagation behavior
62
of business systems. The Percentage Based Threshold definition are a set of rules that can be associated with any business system folders. The Percentage Based Threshold rule consists of a specific condition and definition of an event to be generated when the condition is fulfilled. The condition is the percentage of resources it directly manage to have a certain erroneous state (Red and/or Yellow). Looking at the PBT definition dialog from the Java console may clear this up, as shown in Figure 3-18.
Condition
Event
Figure 3-18 PBT definition dialog
Attention: To use Percentage Based Threshold, you must be familiar with the classic propagation behavior of IBM Tivoli Business Systems Manager. In order for the Percentage Based Threshold definition to be consistent, they must be defined in pair, one to generate Red or Yellow event, and the other to resolve it. The pair must: Have the same event name string Have the same event type
63
Complementary percentage number, covering the whole 1-100 range combined When Percentage Based Threshold is expected to turn the resource to Yellow or Red on specific conditions, you need two-pairs of Percentage Based Threshold definition, four rules. Three rules Percentage Based Threshold definition would not generate a consistent result. The complete Percentage Based Threshold to has threshold of 25% to Yellow and 50% to Red is depicted in Figure 3-19.
Red50Pct 49 50
100
Yellow25Pct 0 24 25 100
Figure 3-19 Overall PBT definition
Although you have defined Percentage Based Threshold to be active on a certain business system folder, traditional propagation behavior still exists. After all, it is the child events and alert state changes that trigger the Percentage Based Threshold evaluation. To ensure that the Percentage Based Threshold definition is not messed up by traditional propagation, you need to suppress the traditional propagation behavior. There are 2 ways to suppress traditional propagation, those are: Setting propagation threshold to be high so that it will never be reached. However, this only applies to non Critical child objects as Critical child events cannot be masked by threshold. This is achieved by performing SetThresholds function to the business system folder and SetBSPriority to the collected child objects. Setting child objects to have priority of Ignore. This is achieved by applying SetBSPriority function to the child objects. Further enhancement of the Percentage Based Threshold behavior can be achieved by setting different weight of the child objects to influence the specific behavior of Percentage Based Threshold calculation is achieved. Percentage Based Threshold percentage in the condition is then calculated as: (sum of weight of child objects with certain alert state) divided by (sum of weight of all child objects)
64
To summarize the Percentage Based Threshold functions, Table 3-9 shows the functions.
Table 3-9 PBT related functions Functions DefineAndUsePBTs DefineAndUsePBTs DefineAndUsePBTs DefineAndUsePBTs SetThresholds SetThresholds SetThresholds SetThresholds SetThresholds SetThresholds SetBSPriority SetWeights Applied to Business system folder Business system folder Business system folder Business system folder Business system folder Business system folder Business system folder Business system folder Business system folder Business system folder Child object Child object Argument Set Red PBT Clear Red PBT Set Yellow PBT Clear Yellow PBT Red High ChildEvent Red Medium ChildEvent Red Low ChildEvent Yellow High ChildEvent Yellow Medium ChildEvent Yellow Low ChildEvent Ignore weight number
Defining a specific propagation behavior

Traditional propagation may be use to conserve processing. Although Percentage Based Threshold is superior in providing creative propagation behavior, it consists of additional processing for resources that has Percentage Based Threshold defined. The traditional propagation is influenced by the following items: Propagation threshold Child object priority Both properties can be modified using functions. As in IBM Tivoli Business Systems Manager V3.1, threshold can be defined individually per resource basis, a lot of propagation limitation that formerly existed are removed. Most of the Percentage Based Threshold behavior that does not include weight modification can be achieved by calculating the appropriate threshold from the number of expected resource in the business system and setting the priority of child object appropriately. Different level of event can be achieved by varying the propagation threshold for different priorities.
65
In summary, traditional propagation can be affected by the functions shown in Table 3-10.
Table 3-10 Propagation related functions Functions SetThresholds SetThresholds SetThresholds SetThresholds SetThresholds SetThresholds SetBSPriority SetWeights Applied to Business system folder Business system folder Business system folder Business system folder Business system folder Business system folder Child object Child object Argument Red High ChildEvent Red Medium ChildEvent Red Low ChildEvent Yellow High ChildEvent Yellow Medium ChildEvent Yellow Low ChildEvent anything weight number
Assigning executive view behavior

One of the major enhancement in IBM Tivoli Business Systems Manager V3.1 is the executive view. A complete discussion of this is provided in Chapter 4, Presenting and using executive services and executive view on page 83. The executive view function is applies to business system folder. It allows definition of executive view, copying executive view event and assigning users to the executive view. Note: For having users assigned to an executive view using function, the users must have been defined in the Console Server. The DefineServicesAndLinkToEVUser relates a business system folder with an executive view definition. Most of other function are defined relate to the property that it defines, but this function is typically defined related directly to the object that it manipulates. The arguments for this function describes the executive view attributes of the business system folder, such as: DisplayName ServiceID BusinessRole RedImpact YellowImpact The business system name as shown in dashboard IBM Tivoli Service Level Advisor internal service identifier Description of the business system The impact when this folder turns red The impact when this folder turns yellow
66
UserIDGroup
The name of user ID group that has the list of user ID that this folder will be assigned. The user IDs are actually defined in the UserIDGroup section.
The AutoCopyEVService allows a business system shortcut to display the Executive View properties of the original business system folder. Table 3-11 summarizes the functions for executive view.
Table 3-11 Executive view functions Functions DefineServicesAndLinkTo EVUser AutoCopyEVService Applied to Business system folder Business system shortcut Argument Executive view attributes User ID group Yes
Enabling state change event

The state change event allows bi-directional communication with IBM Tivoli Enterprise Console. This ensures that event state changes for objects that are managed using Agent Listener are propagated back to IBM Tivoli Enterprise Console. This function represent the small check box in the business system objects property page. The setting default is Off, while the SetSendStateChangeEvent function will set it to On. See Table 3-12.
Table 3-12 State change functions Functions SetSendStateChange Event Applied to Business system folder Business system resource Argument On
3.5 XML interface for business system

XML interface is best to be used for dynamic configuration. Automated program or script can be written to read a configuration repository or interact with a configuration application. This program or script is then responsible to construct the necessary XML commands to define the business system resources and folders. The discussion on XML includes: 3.5.1, XML interface on page 68 3.5.2, Object structure on page 69 3.5.3, Defining XML file for business system on page 71 3.5.4, Running and loading XML on page 79
67
3.5.1 XML interface

The XML interface is implemented in XML toolkit. The XML toolkit is a set of Java programs that parses and send XML transaction to the Common Listener in IBM Tivoli Business Systems Manager server. The XML toolkit is distributed in IBM Tivoli Business Systems Manager base services CD-ROM. The XML file can be coming from the following sources: Backup of current business system tree from the backupLOBasXML command Generated from a program or script from the user The XML file is then sent using the enqueuecl command. This command reads the XML file and send it to Common Listener server. The setting of enqueuecl command is controlled in the enqueuecl.properties file. The enqueuecl command sends the XML file and ensures proper receipt of the file by Common Listener server and returns only the transaction number. However, the loading and processing of the XML file itself is performed asynchronously. To understand what is the actual result of Common Listener processing, you can use the querycltran command. It provides the status of the Common Listener processing status of the enqueuecl transaction. The querycltran command also provides detail status from CL_Status table and shows any incomplete definition of the XML file, which is indicated as orphaned resource. Overall, the XML interface is summarized in Figure 3-20 on page 69.
68
XML generating program
Common Listener server
enqueueCL
XML document
ImportLOBfromXML
ExportLOBasXML
TBSM database
queryCLtran
Figure 3-20 The XML interface summary
3.5.2 Object structure

XML interface requires definition of individual objects and links to build a complete business system structure. This requires a thorough knowledge of how IBM Tivoli Business Systems Manager data structures. It requires you to understand which link has to be created for a business system. To illustrate to illustrate the object structure elements that are needed for building an XML business system, we illustrate on the structure of building a business system folder shown in Figure 3-21 on page 70.
69
All Resources Network Location: Austin
Business Systems
LOB: Application-eLoan-Primary
Node: AUSAPP01
LOB: ELAUS01
G02M: ELAUS01
LOB: ELAUS02
Node: AUSAPP02
LOB: ELAUSDB01
G02M: ELAUS02
Topology View
Node: AUSESD06
LOB: ELAUSDB01
G02N: ELAUSDB01
LOB: ELAUS01
LOB: ELAUS02
Figure 3-21 Business system structure
From Figure 3-21, you should see that: Even as the objects in the All resources and Business systems look similar, they are actually different objects. The AppServer (G02M) ELAUS01 in the All Resources tree is not the same object as ELAUS01 in the Business Systems tree. All objects in the business systems tree are made up from the Business Systems object class or called LOB. Historically it is called a Line of business object. The arrows and lines shown in Figure 3-21 represent links defined in IBM Tivoli Business Systems Manager database. You can get the list of link type in the link_type table on the Object database. The links that glue resources in the All resources tree are of the type Physical containment link or in short called PHYC. The links that glue resources in the Business systems tree are of the type of Business systems containment or LOB containment or LOBC. The links that map the physical resources to their business system resources are the LOB logical link or LOBL. The links that shown in the topology view for business system resources are of the type of General link or GENL. Note that physical resources cannot be shown in the topology view with general links.
70
3.5.3 Defining XML file for business system

In this section, we will not discuss the structure of an XML file. We assume that you are familiar with what XML file is and what a proper XML file structure is. We discuss only the XML file command and structure related to the business system definition in IBM Tivoli Business Systems Manager. The basic of the XML file processing relates to operation of objects and links. The objects can be created, updated or deleted, while links can only be created or deleted. Links is automatically deleted, when any of the related objects is deleted. Additionally, methods can be applied to objects, similarly to the ABS function discussed in 3.4.5, More about functions on page 62. The XML directives for IBM Tivoli Business Systems Manager business system creation are shown in Table 3-13.
Table 3-13 XML directives Object type Object Directives <tbsm:addObjectInstances> <tbsm:deleteObjectInstances> <tbsm:modifyObjectInstances> <tbsm:addLinkInstances> <tbsm:deleteLinkInstances> <tbsm:methodExecution> Syntax identification [attributes]
Link
link-type source-identification target-identification
Method
Identifying object
The important first step of working with XML definition is to be able to identify the object that you are working with. This can refer to a current existing object or for a new object to be created. There are several mechanism on identifying object in XML file, those are: The preferred way for object defined through Common Listener interface, this includes the business systems defined using XML toolkit - is using the instance id. This is a unique identifier assigned at creation time; usually referring to the path in All resources tree. The instance ids are stored in the CL_IDCache table. A sample content of the CL_IDCache table is shown in Figure 3-22 on page 72.
71
Figure 3-22 Sample instance ID table
From Figure 3-22, the appropriate XML definition to identify object LOB/WebServers is shown in Example 3-1.
Example 3-1 Sample instance definition <inst> <class>LineOfBusiness</class> <instid>LOB/WebServers</instid> <name>WebServers</name> </inst>
For objects that are not created through common listener, you have to explicitly specify the object containment path. Depending on whether the object resides on the All Resources tree or Business Systems tree it can be traversing the PHYC or LOBC link. This path ensures the uniqueness of finding the object. As most of the resources for Application Server object are defined using Agent Listener interface, they do not have any instance identifier. Figure 3-23 on page 73 shows the tree for ApacheWebServer1 in manila.
72
Figure 3-23 WebServer object tree
To identify the object Web server in manila using the path shown in Figure 3-23, see Example 3-2.
Example 3-2 Example of path <id> <class>G02Ocname</class> <objpath>PiggyBank, Inc./austin/itsc.austin/manila.itsc.austin.ibm.com/ ApacheWebServer1@manila@manila.itsc.austin.ibm.com</objpath> </id>
Manipulating object
The syntax of XML statements for manipulating object are shown in the following list: Adding an object The syntax of adding an object is shown in Example 3-3.
Example 3-3 Adding an object <tbsm:addObjectInstances> <inst> <class>class_name</class>
73
<instid>assigned_instance_id</instid> <name>display_name</name> <attr> <desc>description</desc> </attr> </inst> <flags>flags</flags> </tbsm:addObjectInstances>
As shown in Example 3-3 on page 73, the object is identified and assigned at least the name. The attribute definitions are optional, you can define one or more attributes in when defining the object instance, otherwise you can add or modify the attribute using the modify directive. You can put more than one instance definition in an addObjectInstances directive. Currently the default behavior is that it only allows putting LineOfBusiness as the class_name, this means that the XML interface or the enqueuecl command only support object manipulation for business system objects. To create non business system object, enqueuecl command must be invoked using an undocumented -r option Flags are attributes that you can define for the business system resources or folders. The following are the available flags: AutoCopyEVService: Defining the folder as executive view Modifying attribute of an object When you need to modify the object, the minimal syntax is shown in Example 3-4.
Example 3-4 Modifying an object <tbsm:modifyObjectInstances> <inst> <class>class_name</class> <instid>assigned_instance_id</instid> <attr> <desc>description</desc> </attr> </inst> </tbsm:modifyObjectInstances>
Modifying the object instances requires you to identify the instance. As an option you can either define it using the instid or objpath directive. Again, you can modify multiple objects in a single modifyObjectInstances directive. Deleting an object Deleting an object is shown in Example 3-5 on page 75.
74
Example 3-5 Deleting an object <tbsm:deleteObjectInstances> <inst> <class>class_name</class> <instid>assigned_instance_id</instid> </inst> </tbsm:deleteObjectInstances>
Deleting object instance only need to identify the object.
Link manipulation
The link manipulation, either creation or deletion, follows the following syntax:
link type - source identification - target identification
or as shown in XML in Example 3-6.

Example 3-6 Link definition <tbsm:addLinkInstances> <link> <type>LOBC</type> <src> <id> <class>LineOfBusiness</class> <instid>LOB/null</instid> </id> </src> <tgt> <id> <class>LOBC</class> <instid>LOBC</instid> </id> </tgt> </link> </tbsm:addLinkInstances>
The source or target identifiers can be identified either by instid or objpath directives. Typically the objpath directive is used to link a newly created business system object using LOBL link to the physical resource in the All Resources tree.
Running method
The methods in XML is the same as functions in ABS. The functions in XML is defined using the syntax in Example 3-7.
Example 3-7 Method definition syntax <tbsm:methodExecution> <methodgroup> <instances> <inst>
75
.... </inst> </instances> <methods> ... </methods> </methodgroup> </tbsm:methodExecution>
As shown in Example 3-7 on page 75, methods are assigned to the instances of business systems. These instances are identified using the class and instid directives. Similarly to the ABS functions, these are the available methods: Executive view related methods DefineEVService
<DefineEVService> <DisplayName>string</DisplayName> <ServiceID>string</ServiceID> <BusinessRole>string</BusinessRole> <RedImpact>string</RedImpact> <YellowImpact>string</YellowImpact> <Flags>integer</Flags> </DefineEVService>
DefineServicesAndLinkToEVUsers
<DefineServicesandLinkToEVUsers> <ServiceDef> <DisplayName>string</DisplayName> <ServiceID>string</ServiceID> <BusinessRole>string</BusinessRole> <RedImpact>string</RedImpact> <YellowImpact>string</YellowImpact> <Flags>integer</Flags> </ServiceDef> <UserIDDef> <UserId>string<UserId> </UserIDDef> </DefineServicesAndLinkToEvUsers>
LinkEVUsersToServices
<LinkEVUsersToServices> <EVUsers> <UserId>string<UserId> </EVUsers> </LinkEVUsersToServices>
76
UnlinkEVServices
<UnLinkEVServices> <EVUsers> <UserID>string</UserID> </EVUsers> </UnLinkEVServices>
PBT related methods DefineAndUsePBTs

<DefineAndUsePBTs> <PBTsToDefine> <PBTID>string</PBTID> <PBTName>string</PBTName> <Relevance>integer</Relevance> <Enabled>string</Enabled> <MinAlertState>string</MinAlertState> <MaxAlertState>string</MaxAlertState> <MinPercentage>string</MinPercentage> <MaxPercentage>string</MaxPercentage> <EventType>string</EventType> <EventName>string</EventName> <EventText>string</EventText> <EventAlertState>string</EventAlertState> <EventPriority>string</EventPriority> <EventFlags>integer</EventFlags> <EventState>string</EventState> </PBTsToDefine> </DefineAndUsePBTs>
DefinePBTs
<DefinePBTs> <PBTsToDefine> <PBTID>string</PBTID> <PBTName>string</PBTName> <Relevance>integer</Relevance> <Enabled>string</Enabled> <MinAlertState>string</MinAlertState> <MaxAlertState>string</MaxAlertState> <MinPercentage>string</MinPercentage> <MaxPercentage>string</MaxPercentage> <EventType>string</EventType> <EventName>string</EventName> <EventText>string</EventText> <EventAlertState>string</EventAlertState> <EventPriority>string</EventPriority> <EventFlags>integer</EventFlags> <EventState>string</EventState>
77
</PBTsToDefine> </DefinePBTs>
DeletePBTs
<DeletePBTs> <PBTsToDelete> <PBTID>string</PBTID> <PBTName>string</PBTName> </PBTsToDelete> </DeletePBTs>
GetPBTs
<GetPBTs> <PBTs> <PBTID>string</PBTID> <PBTName>string</PBTName> </PBTs> </GetPBTs>
GetPBTStatus
<GetPBTStatus> <PBTsToStatus> <PBTID>string</PBTID> <PBTName>string</PBTName> </PBTsToStatus> </GetPBTStatus>
UsePBTs
<UsePBTs> <PBTs> <PBTID>string</PBTID> <PBTName>string</PBTName> <Action>integer</Action> </PBTs> </UsePBTs>
Other methods SetThresholds

<SetThresholds> <ThresholdObjects> <EventType>integer</EventType> <AlertState>integer</AlertState> <Priority>integer</Priority> <Value>integer</Value> </ThresholdObjects> </SetThresholds>
ResetThresholds
78
<ResetThresholds> </ResetThresholds>
SetWeights
<SetWeights> <NewWeight>integer</NewWeight> </SetWeights>
SetBSPriority
<SetBSPriority> <Value>string</Value> </SetBSPriority>
SetSendStateChangeEvent
<SetSendStateChangeEvent> <StateChange>[0|1]</StateChange> </SetSendStateChangeEvent>
3.5.4 Running and loading XML

The complete XML file for defining a business system structure should have the following structure: 1. Define new business system object instances 2. Connect object instances to its parent using LOBC links 3. Connect object instances to original resources using LOBL links, this includes connecting business system shortcut to the original business system folder. It is not permitted to create a business system shortcut from either a business system resource or another business system shortcut. 4. Optionally, connect the business system objects using GENL links to build the topology view. A very simple and complete XML definition is shown in Example 3-8.
Example 3-8 Complete simple XML definition <tbsm:addObjectInstances> <inst> <class>LineOfBusiness</class> <instid>LOBC/WebServers</instid> <name>WebServers</name> </inst> <inst> <class>LineOfBusiness</class> <instid>LOBC/WebServers/ApacheWebServer1@bangkok</instid> <name>ApacheWebServer1@bangkok</name> </inst>
79
</tbsm:addObjectInstances> <tbsm:addLinkInstances> <link> <type>LOBC</type> <src> <id> <class>LineOfBusiness</class><instid>LOBC/WebServers</instid> </id> </src> <tgt> <id> <class>LOBC</class><instid>LOBC</instid> </id> </tgt> </link> <link> <type>LOBC</type> <src> <id> <class>LineOfBusiness</class> <instid>LOBC/WebServers/ApacheWebServer1@bangkok</instid> </id> </src> <tgt> <id> <class>LineOfBusiness</class><instid>LOBC/WebServers</instid> </id> </tgt> </link> <link> <type>LOBL</type> <src> <id> <class>G02Ocname</class> <objpath>PiggyBank, Inc./austin/itsc.austin/bangkok.itsc.austin.ibm.com/ ApacheWebServer1@bangkok@bangkok.itsc.austin.ibm.com</objpath> </id> </src> <tgt> <id> <class>LineOfBusiness</class> <instid>LOBC/WebServers/ApacheWebServer1@bangkok</instid> </id> </tgt> </link> </tbsm:addLinkInstances>
Loading the XML definition shown in Example 3-8 on page 79 using the enqueuecl command is shown in Example 3-9.
Example 3-9 Loading XML file $ enqueuecl.ksh -t bulk -f C:/test1.xml -s pretoria -p 8082 -ww GTMCL5209I: Initializing transport adapter. GTMCL5210I: Transport adapter initialization complete. GTMCL5211I: Registering with TBSM. GTMCL5212I: Registration complete, sessionId: TBSM_LOCAL.XMLtoolkit-pretoria--1050481452-0000000102.
80
GTMCL5215I: Begin Discovery: bulk: TBSM_LOCAL.XMLtoolkit-pretoria--1050481452-0000000102. TBSM_LOCAL.XMLtoolkit-pretoria--1050481452-0000000102 Type: bulk GTMCL5216I: addObjectInstance TBSM_LOCAL.XMLtoolkit-pretoria--1050481452-0000000102 GTMCL5216I: addLinkInstance TBSM_LOCAL.XMLtoolkit-pretoria--1050481452-0000000102 GTMCL5216I: sendAddObjectInstance TBSM_LOCAL.XMLtoolkit-pretoria--1050481452-0000000102 GTMCL5216I: sendAddLinkInstance TBSM_LOCAL.XMLtoolkit-pretoria--1050481452-0000000102 GTMCL5216I: commitDiscovery TBSM_LOCAL.XMLtoolkit-pretoria--1050481452-0000000102 GTMCL5216I: unregistration TBSM_LOCAL.XMLtoolkit-pretoria--1050481452-0000000102 GTMCL5200I: The request for transaction "4267" has been queued to TBSM.
As shown in Example 3-9 on page 80, the load is send successfully. As we are using a very-very verbose option (-ww), we can see a lot of messages. The transaction ID is 4267 as seen in message GTMCL5200I. The status of the transaction can be retrieved using the querycltran command, as shown in Example 3-10.
Example 3-10 Checking the status of XML transaction $ querycltran.ksh -t 4267-s pretoria -p 8082 GTMCL5236I: The current state of the transaction is 5.
81
82
Chapter 4.
Presenting and using executive services and executive view

This chapter discusses the executive dashboard view. The executive dashboard view shows the status of important resources that can be shown in a simple interface. The executive dashboard is aimed for business executives to understand the business status. It also shows service level information in the executive dashboard view as the information is important in the service oriented business. Executive information can also be presented using a custom J2EE based application through the TBSM_API interface. The discussion in this chapter includes the following: 4.1, Executive view assignment considerations on page 84 4.2, Working with executive view definition on page 86 4.3, Developing executive API application on page 92
83
4.1 Executive view assignment considerations

The introduction of the executive view in the IBM Tivoli Business Systems Manager portfolio introduces a new paradigm of presenting IT information. It allows a simple color coded, dashboard like display for representation of business entities that are mapped from IT resources status. An example display of Executive view or executive dashboard is shown in Figure 4-1.
Figure 4-1 Sample executive dashboard
There are two levels of executive dashboard users, the Executive and Executive IT. Figure 4-2 on page 85 shows the different information made available to each user. The dashboard on the left is for the executive user and shows service status. The dashboard on the right is for the IT executive and shows details about the affected resource.
84
Executive User
IT Executive User
Figure 4-2 Comparison of drill-down information available to each role
This view is dubbed executive view as this is typically fitting for executives to get a glance of their business status in terms of IT. However, this interface also appealing for view only usages on business entity that serves for getting the alarm out quickly when an outage happen. This allows the use of IBM Tivoli Business Systems Manager executive view beyond the executive display. The following are some sample usages of Executive view and examples of criteria for a business system entity that can be designated as Executive view. The executive view users can be mapped with the business system folder using the executive dashboard view shown in Figure 4-3 from a Java console.
Chapter 4. Presenting and using executive services and executive view
85
Figure 4-3 Executive view assignment
The executive view allows the following: Quick at-a-glance status of entities Getting service level status of business system Creation of custom interface for displaying status
4.2 Working with executive view definition

Executive view is defined on a business system folder object. It can be defined using the following mechanism: Java console dialog Command line interface Automated business system function XML method definition
86
4.2.1 Java console dialog

In general the definitions are similar, just different mechanism are employed. From the Java console, the dialog for presenting the executive view definition must be enabled from the preferences page. Use the Console Administrator Preferences and go to the Executive dashboard tab as shown in Figure 4-4.
Figure 4-4 Executive dashboard setting
Once this has been performed, new Java console session has a new Executive dashboard configuration in the property page dialog for a business system folder object. The executive dashboard configuration page is shown in Figure 4-5 on page 88.
87
Figure 4-5 Executive dashboard setting page
In Figure 4-5, the following fields are the important parts of the definition: Name of Service: This is the service name, which is addressable for the API. The Name of Service should be unique. Service Identifier: This is the service ID field from IBM Tivoli Service Level Advisor. This should be a unique ID from IBM Tivoli Service Level Advisor that you retrieve from Svc_Offering table in DYK_CAT database. See Chapter 5, Policy-driven batch management on page 115 Business Role of Service, Business Impact for Red Alerts, Business Impact for Yellow Alerts: These are all text only field that will be displayed in the executive dashboard services menu as shown in Figure 4-2 on page 85. SLA supported: This is a flag used to identify that IBM Tivoli Service Level Advisor information is collected from the Service ID mentioned. All definition of executive view contains these fields.
4.2.2 Using Command Line Interface

There are four commands to manipulate executive view, those are: DefineEVService.ksh Assigning executive view definition for a business system folder
88
DefineServicesAndLinkToEVUsers.ksh Assigning executive view definition for a business system folder and allocating the view for users LinkEVUsersToServices.ksh Linking users with executive view UnlinkEVServices.kshUnlinking users from executive view All the above commands has the argument list of: -S -U -P -i -o SQL server machine (optional) SQL server user ID (optional) SQL server password (optional) Input XML file Output XML file
The input XML file is very similar to the XML file section described in XML definition for executive view on page 90. A sample skeleton is shown in Example 4-1.
Example 4-1 Input XML file structure <methodgroupdefinition> <methodgroup> <instances> <inst> <class>LineOfBusiness</class> <instid>LOBC\path</instid> </inst> </instances> <methods> ... </methods> </methodgroup> </methodgroupdefinition>
4.2.3 Using business system creation program

The definition of executive view using automated business systems (ABS) or XML method are covered in 3.4, Using Automated Business System on page 46 and 3.5, XML interface for business system on page 67 respectively. For reference, the ABS definition for executive view is given in the following sections.
89
ABS definition for executive view

Executive view definitions are defined in the DefineServicesAndLinkToEvUser and UserIDGroup sections. These definitions are typically assigned in FunctionGroup from the Path section. The overall definition scheme is shown in Figure 4-6.
Path
Path Level Name Description FunctionGroup
FunctionGroup
FunctionGroup FunctionName Instance
DefineServicesAndLinkToEVUsers
Instance Flags DisplayName UserIDGroup ServiceID YellowImpact BusinessRole RedImpact
UserIDGroup
Instance UserID
Figure 4-6 Executive view assignment
XML definition for executive view

The XML definition is attached directly to an LineOfBusiness object that is build. See XML information shown in 3.5, XML interface for business system on page 67. There are several methods that relates to executive view, those are: DefineEVService: Defining a new execuvtive view for a LineOfBusiness object
<DefineEVService> <DisplayName>string</DisplayName> <ServiceID>string</ServiceID> <BusinessRole>string</BusinessRole> <RedImpact>string</RedImpact> <YellowImpact>string</YellowImpact> <Flags>integer</Flags> </DefineEVService>
90
DefineServicesAndLinkToEVUsers: Defining a new executive view for a LineOfBusiness object and assign specific user Ids for accessing the service.
<DefineServicesandLinkToEVUsers> <ServiceDef> <DisplayName>string</DisplayName> <ServiceID>string</ServiceID> <BusinessRole>string</BusinessRole> <RedImpact>string</RedImpact> <YellowImpact>string</YellowImpact> <Flags>integer</Flags> </ServiceDef> <UserIDDef> <UserId>string<UserId> </UserIDDef> </DefineServicesAndLinkToEvUsers>
LinkEVUsersToServices: Linking user Ids to executive view service

<LinkEVUsersToServices> <EVUsers> <UserId>string<UserId> </EVUsers> </LinkEVUsersToServices>
UnlinkEVServices: Unlinking user Ids to executive view service

<UnLinkEVServices> <EVUsers> <UserID>string</UserID> </EVUsers> </UnLinkEVServices>
The above XML methods are defined in the context of method execution block as shown in Example 4-2.
Example 4-2 Executing methods <tbsm:methodExecution> <methodgroup> <instances> <inst> <class>LineOfBusiness</class> <instid>LOBC\path</instid> </inst> </instances> <methods> ... </methods> </methodgroup> </tbsm:methodExecution>
91
4.3 Developing executive API application

This section provides a sample application that shows the usage of IBM Tivoli Business Systems Manager application programming interface. The application is developed using WebSphere Studio Application Monitor Integrated Edition. The discussion consists of: 4.3.1, API overview on page 92 4.3.2, Application development on page 93 4.3.4, Deploying the application on page 111
4.3.1 API overview

The API is distributed as a Java archive (jar) file tbsmapi.jar and a set of Java documentation (Javadoc) files. The API distribution is in the base services CD in the tbsmapi directory. The API allow J2EE application to access IBM Tivoli Business Systems Manager executive view information. The API processing can be viewed as shown in Figure 4-7.
ITBSMConsoleServer
tbsmapi.jar remote EJB call
Executive View application (EAR)
WebSphere Application Server
WebSphere Application Server WebSphere Application Client
Figure 4-7 API concepts
The API is explained in IBM Tivoli Business Systems Manager Administrators Guide, SC32-9085 in Appendix F. The API is designed to be used in WebSphere Studio Application Development environment. We show a sample J2EE application developed. There are several object classes that are used within the API. These objects and their relationship are shown in Figure 4-8 on page 93.
92
Relationshi p View Record Managed Element View Record Relationshi p View Managed Element View
Status View Record
Status View getRelationships getManagedElement getManagedElements getStatusView
Business Role View Record
Business Role View
getBusinessImpact TbsmApi Availability Status Detail View Group getAvailabilityStatusDetails getSLAStatusDetailViewGroup getSLASummary
Event View Event View Record
SLA Status Detail View Group Note View Record Note View
SLA Status Summary View
SLA Trend View
SLA Violation View
SLA Trend View Record
SLA Violation View Record
SLA Status Summary View Record
Figure 4-8 TBSM_API objects
4.3.2 Application development

This section uses WebSphere Studio Application Development Integrated Edition V5.1. We show a step-by-step instruction on developing a custom IBM Tivoli Business Systems Manager API application. The application developed shows a
93
dynamic Web page that shows the status of data centers in a US map as shown in Figure 4-9.
Figure 4-9 Sample application Web page
Creating sample application

The following procedure develops the sample application: 1. Starting WebSphere Studio Application Development Integrated Edition (WSADIE) V5.1. Use Programs WebSphere Studio Application Development. 2. Select a new workspace from the select workspace dialog in Figure 4-10.
Figure 4-10 Select workspace
3. In the new workspace, create a new Enterprise application using File New Project as shown in Figure 4-11 on page 95.
94
Figure 4-11 Creating a new Project
4. The new project wizard opens, select to build a new Enterprise Application and click Next; choose to build a J2EE 1.3 application and click Next. See the dialogs in Figure 4-12 on page 96.
95
Figure 4-12 Creating a new J2EE enterprise application
5. For the new application, we called our application TIA507 as shown, and clicked Next.
96
Figure 4-13 Creating a new J2EE enterprise application
6. In the module selection list, click New Module and specify a new Web project. As this sample application only provides a custom status view, it does not contain any other modules. The dialogs are shown in Figure 4-14 on page 98. Click on Finish when done.
97
Figure 4-14 Defining new Web module
7. WebSphere Studio Application Developer will generate the project and build any required file system structure for the new J2EE enterprise application with the Web project. We must now import the tbsmapi.jar file from the IBM Tivoli Business Systems Manager CD-ROM. First, we import the tbsmapi.jar into the Utility jar for the enterprise application, right-click the Enterprise Applications TIA507 Utility jar and select Import, see Figure 4-15 on page 99.
98
Figure 4-15 Importing utility jar
8. Import the tbsmapi.jar from the File System and put it into the main enterprise application folder as shown in Figure 4-16.
Figure 4-16 Create Web application component
99
9. You also need to define the jar file for building the Web project. Right-click the Web project TIA507Web and select Properties. Go to the Java Build Path and click Add JARs and select the tbsmapi.jar. See the dialogs in Figure 4-17. Click OK.
Figure 4-17 Adding tbsmapi.jar into Java build path
10.Import the images that you want to use with the Web application, right-click the TIA507Web and select Import. Import the images from File System to the WebContent folder of the TIA507Web as shown in Figure 4-18 on page 101. We use the following images: ussmall.gif red.gif yellow.gif green.gif graphic file for the background image for red status image for yellow status image for green status
100
Figure 4-18 Importing images
11.Open the Deployment descriptor for the Web project, right-click the Web Modules TIA507Web and select Open With Deployment Descriptor Editor as shown in Figure 4-19 on page 102.
101
Figure 4-19 Opening deployment descriptor
12.In the Deployment Descriptor editor, select the Security tab and add a new Security role called TBSM_API as shown in Figure 4-20 on page 103.
102
Figure 4-20 New security role
13.In the Deployment Descriptor editor, select the Servlet tab and click New to build a new Servlet, see Figure 4-21 on page 104.
103
Figure 4-21 Servlet definition
14.We call our new Servlet TBSMServlet and create the doPost and doGet methods with the URL mapping to TBSMServlet as shown in Figure 4-22 on page 105.
104
Figure 4-22 Creating a servlet
15.Set the RunAs property for the TBSMServlet to the TBSM_API role. This tells the J2EE container running the client Web application that when running an EJB for this client, use the ID defined in the RunAs property. When this application is deployed to WebSphere, the administrator must set the user ID and password. See Figure 4-23 on page 106.
105
Figure 4-23 Defining the RunAs property for a Servlet
4.3.3 Application servlet development

The application itself is imbedded in the newly created servlet called TBSMServlet. The logic is embedded in the buildTBSMView method. This method is called from doPost and doGet methods. Another method is the init method that provide initialization logic. Lets look at the code more closely. The import section includes additional import that relates to the API calls. Our include section is shown in Example 4-3.
Example 4-3 Import section import import import import import import import java.io.IOException; javax.naming.*; java.util.*; javax.servlet.ServletException; com.ibm.tbsm.api.entrypoint.*; com.ibm.tbsm.api.interfaces.*; com.ibm.tbsm.api.model.*;
106
import import import import import import
com.ibm.tbsm.api.common.*; com.ibm.tbsm.api.comparators.*; com.ibm.tbsm.api.util.*; javax.servlet.http.HttpServlet; javax.servlet.http.HttpServletRequest; javax.servlet.http.HttpServletResponse;
The doPost and doGet method is the default method body that call buildTBSMView method as shown in Example 4-4.
Example 4-4 The doPost and doGet methods public void doGet(HttpServletRequest req, HttpServletResponse resp) throws ServletException, IOException { buildTBSMView(req, resp); } public void doPost(HttpServletRequest req, HttpServletResponse resp) throws ServletException, IOException { buildTBSMView(req, resp); }
Initialization method to acquire hostname and port from system property information as shown in Example 4-5. The required properties are: pigbank.host pigbank.port pigbank.tbsmejb hostname for console server IIOP port number, default is 2809 API class EJB
Example 4-5 Initialization method public String bootstrap_host; public String bootstrap_port; public String tbsm_ejb_name; public void init() throws ServletException { super.init(); bootstrap_host = System.getProperty("pigbank.host","pretoria.itsc.austin.ibm.com"); bootstrap_port = System.getProperty("pigbank.port","2809"); tbsm_ejb_name = System.getProperty("pigbank.tbsmejb", "ejb/com/ibm/tbsm/api/030100/main/ITBSMAPIMainHome"); }
As indicated, the main processing logic is contained in the buildTBSMView method. The overall pseudo-code for the method is shown in Figure 4-24 on page 108.
107
buildTBSMView Initialize context
Generate HTML headers Initialize TBSM api call Get Executive View resources
svcName= Austin/NewYork/ LosAngeles
Draw image based on the state
Close the HTML page
Figure 4-24 Logic of buildTBSMView method
From Figure 4-24, lets analyze each processing logic in the following sections. The method header is shown in Example 4-6. This is a standard processing header for a Servlet invocation. It conforms to the doPost and doGet method that calls them.
Example 4-6 Header for buildTBSMView method public void buildTBSMView(HttpServletRequest req, HttpServletResponse resp) throws ServletException, IOException {
Initialize the processing context logic as shown in Example 4-7. The initialized variables are: outText env PROVIDER_URL StringBuffer that will contain the HTML code HashTable with the context defined The URL for the IBM Tivoli Business Systems Manager Console server
Example 4-7 Initialize the context StringBuffer outText = new StringBuffer(); InitialContext ic;
108
Hashtable env = new Hashtable(); env.put(Context.INITIAL_CONTEXT_FACTORY, "com.ibm.websphere.naming.WsnInitialContextFactory"); env.put(Context.PROVIDER_URL, "corbaloc:iiop:"+bootstrap_host+":"+bootstrap_port);
Create HTML header as shown in Example 4-8. In this header, we requested an automatic refresh every 10 seconds. The background map is defined in a division.
Example 4-8 HTML header outText.append("<HTML>\n"); outText.append("<HEAD><TITLE>Sample TBSM View</TITLE></HEAD>\n"); outText.append("<BODY>\n<META http-equiv='refresh' content='10'>\n"); outText.append("<H1>PiggyBank System Report</H1></BODY>\n"); // draw USA map outText.append("<DIV id='usa' style='position:absolute; left:10;"); outText.append(" top:60; z-index:1'>"); outText.append("<IMG SRC=usasmall.gif border=1></DIV>\n");
The API processing is build within a try - catch block to anticipate any error in the processing. In the case of error, the page will show the stack trace of the exception. The code for the catch block is shown in Example 4-9.
Example 4-9 Try and catch block try { . . . } catch (Exception e) { e.printStackTrace(resp.getOutputStream()); }
The API initialization is performed according to Example 4-10.

Example 4-10 API initialization ic = new InitialContext(env); ic.lookup(""); TbsmApi api = new TbsmApi(ic, tbsm_ejb_name);
After the API has been initialized, we start to get into the statusView using the method shown in Figure 4-25 on page 110.
109
IManagedElementRecord RootInstancesEnum. SERVICES_ROOT
getRelationship
RelationshipView RelationshipCharacteristicsEnum. CHILDREN
efs etObjR getTarg
List
getManagedElement
ManagedElementView
t getS
Vie atus
StatusView
Figure 4-25 API objects relationship
The code to get to the StatusView object is shown in Example 4-11.

Example 4-11 Navigate API objects IManagedElementRecord servicesRoot; // Executive view root servicesRoot = api.getManagedElement(RootInstancesEnum.SERVICES_ROOT); RelationshipView children; // Get exec view objects children = api.getRelationships(servicesRoot, RelationshipCharacteristicsEnum.CHILDREN,1,500); List targetList = children.getTargetObjRefs(); ManagedElementView mes = api.getManagedElements(targetList); StatusView statusView = api.getStatusView(mes);
Process each managed elements and check its svcName field. If the svcName matches either Austin, NewYork or LosAngeles, an icon will be put in the output HTML code as shown in Example 4-12.
Example 4-12 Comparing and processing service names // 1: Prepare comparator item // ManagedElementComparator mecomp = new ManagedElementComparator(); statusView.prepareForIterateBy(mecomp); IManagedElementRecord curME; for (int i=0; i<mes.size(); i++) { // 2: For each element in the statusView curME = (IManagedElementRecord)mes.get(i); // // 3: Get the AlertState //
110
StatusView.Record svRecord; svRecord = statusView.getStateRecord( StatusRecordTypeEnum.AVAILABILITY_ALERTSTATE, curME); int aState = 0; if (svRecord!=null) aState = svRecord.getnormalizedState(); // // 4: Find image file name based on AlertState // String imgName; switch (aState) { case 0: imgName = new String("icon_unknown.gif");break; case 1: imgName = new String("icon_green.gif");break; case 2: imgName = new String("icon_yellow.gif");break; case 3: imgName = new String("icon_red.gif");break; default: imgName = new String("icon_unknown.gif"); } // // 5: Get the coordinates for certain services // int x = 0; int y = 0; String svcName = new String(curME.getName()); if (svcName.equals("Austin")) { x = 208; y = 174+50; } else if (svcName.equals("LosAngeles")) { x = 49; y=139+50; } else if (svcName.equals("NewYork")) { x = 382; y = 85+50; } if ((x>0) & (y >0)) { // // 6: If coordinates are filled, output the HTML code // outText.append("<DIV id='"+svcName+"' style='position:absolute;"); outText.append("left:"+x+"; top:"+y+"; z-index:5'>\n"); outText.append("<IMG SRC="+imgName+"></DIV>\n"); } }
Close the HTML code and send the HTML back is shown in Example 4-13.
Example 4-13 Close HTML and send the page back outText.append("</HTML>\n"); resp.getOutputStream().print(outText.toString());
4.3.4 Deploying the application

To deploy the newly developed application, use the following steps: 1. From WebSphere Studio Application Development Integrated Edition, export the application into an EAR file. Use File Export and then select EAR file.
111
We provide the sample EAR file as additional material, refer to Appendix A, Additional material on page 245. The EAR file that we provide contains the Java source code. 2. Open WebSphere Application Server administration console and select Application Install New Application. Note that we install the application on a separate WebSphere Application Server from the Console Server. This is to avoid running in secure mode as required by the Console Server application. 3. Follow the mapping process wizard ensure you map the application to the correct application server and virtual host. Supply any necessary RunAs user ID with a user ID that you will define in the Console server for TBSM_API role. 4. Define a new user ID at the IBM Tivoli Business Systems Manager console server user registry that have access to the TBSM_API role. a. Create a new group called TBSM_API and assign a user ID to TBSM_API group. For example apiuser. b. From the administration console of the Console Server, select Application Enterprise Application and select ITBSMConsoleServer c. Go to the Additional Property and select Security d. Put in the TBSM_API role for TBSM_API group 5. We are using a development system scheme that allocate a predefined user ID for all access. This may not fulfill the security requirement for your setting, you can define a secure application in WebSphere as indicated in the IBM Tivoli Business Systems Manager Administrators Guide, SC32-9085 but this is outside the scope of our redbook. The following is the procedure that we use: a. From the Security menu, select Configure CSIv2 Outbound Authentication b. In the configuration page, enable Identity Assertion and configure Client Certificate Authentication to be supported, see Figure 4-26 on page 113.
112
Figure 4-26 Configuring security
c. Save the configuration changes. Stop the server and restart it. 6. Now for the newly deployed application, there are several variables that must be defined in WebSphere. Go to the Environment Manage WebSphere Variables and create the following variables: pigbank.host pigbank.port Hostname of the Console Server Port number for IIOP server
7. Save the WebSphere configuration and restart the WebSphere process. 8. You can access the application using the URL:
http://host:port/TIA507Web/TBSMServlet
The Web page is shown in Figure 4-27 on page 114.
113
Figure 4-27 Finished application
114
Chapter 5.
Policy-driven batch management

This chapter discusses policy driven batch management. This represents the integration of IBM Tivoli Business Systems Manager for managing batch jobs from IBM Tivoli Workload Scheduler and Service Level information from IBM Tivoli Service Level Advisor. The discussion in this chapter includes the following: 5.1, IBM Tivoli Workload Scheduler overview on page 116 5.2, IBM Tivoli Service Level Advisor overview on page 119 5.3, Getting batch management information on page 124 5.4, Service level for IBM Tivoli Workload Scheduler on page 130 5.5, Getting Service Level information in dashboard on page 158
115
5.1 IBM Tivoli Workload Scheduler overview

IBM Tivoli Workload Scheduler provides an integrated distributed batch management. It allows a hundreds of thousands jobs to be scheduled across thousands of machines in the enterprise daily. The discussion here is divided into: 5.1.1, Domain-based scheduling on page 116 5.1.2, Terminology on page 117 5.1.3, Scheduling resources on page 118
5.1.1 Domain-based scheduling

Domain-based scheduling relies on the following features: Centralized control: All scheduling information is defined and stored in a central machine called the master domain manager. The master domain manager compiles the definition into a working plan called the Symphony file. This work plan will then be distributed into all the machines participating in the workload scheduling. The definition and control are performed using a Java based Job Scheduling Console (JSC). Distributed machine structure: Machines are organized in hierarchical domains. These domains are managed by a domain manager. A domain manager can resolve batch job dependency for machines local to the domain. This structure allows a very scalable distributed jobs scheduling. Fault tolerance: As each machine gets a distribution of the work plan, it can run jobs independently from the master domain manager. Job dependency across multiple machines can be resolved in the domain by the domain manager. Figure 5-1 on page 117 shows the domain structure of IBM Tivoli Workload Scheduler.
116
Master Domain Manager
Fault Tolerant Agent Fault Tolerant Agent
Domain Manager
Domain Manager Fault Tolerant Agent
Fault Tolerant Agent
Fault Tolerant Fault Agent Tolerant Agent
Domain Manager Domain Manager Domain Manager Fault Tolerant Agent Fault Tolerant Agent
Fault Tolerant Agent Fault Tolerant Agent
Figure 5-1 Domain structure
5.1.2 Terminology
In IBM Tivoli Workload Scheduler, there are these terms: Database Objects Files contains scheduling objects definition. Scheduling resources that are defined in the database, see the description in 5.1.3, Scheduling resources on page 118.
Chapter 5. Policy-driven batch management
117
Plan
Compiled work plan for daily jobs, it is derived from the database objects. It is sometimes called the Symphony file. The occurrence of workload from the database in the plan. The 24-hour period that covers the to-do list in the plan. The start of production day. The command or job that compiles the database objects into plan instances. This job runs at the end of production day to define the work for the next production day.
Instance Production day Start of day JNextDay
These are represented in Figure 5-2.
Resource Job Calendar JNextDay Symphony file Workstation Job stream Production day
Database
Figure 5-2 Defining workload in IBM Tivoli Workload Scheduler
5.1.3 Scheduling resources

Job scheduling in IBM Tivoli Workload Scheduler is performed using the following resources: Workstation Calendar Job This represent the machines which job will be run. It is also called CPU resources. This represent date selection for defining schedule. This represent a single executable or script that can be executed at a workstation.
118
Job stream Run cycle File Prompt Resource Parameter User
This is a collection of jobs that can be scheduled using the same scheduling rule. Also called Schedule. Scheduling rule that is used by job stream to determine when the job stream can be scheduled. This represents file resources that can be used for jobs dependency. This represents resource that held the jobs to be manually answered to run. This represents a generic resource that is used for job dependency. This represents the substitution of job commands. This represents Windows user ID and password.
5.2 IBM Tivoli Service Level Advisor overview

IBM Tivoli Service Level Advisor collects, calculates and provides Service Level management. This section provides an overview of IBM Tivoli Service Level Advisor. We discuss the following topics: 5.2.1, Service level management on page 119 5.2.2, IBM Tivoli Service Level Advisor architecture on page 120 5.2.3, PiggyBanks IBM Tivoli Service Level Advisor setup on page 122
5.2.1 Service level management

Service level management is a process and discipline to perform: Managing service level objectives lifecycle from initiating it to generating a formal Service Level Agreement (SLA). Collecting performance and availability information from system elements Comparing service level attainment against the agreed Service Level Agreement Providing service level attainment reports Over this life cycle of service level, there are several entities that relates to this process. The service level management that we discuss here relates to a Service Provider like business process. Although this can be significantly simplified for a single corporation, this shows a generic vision of service level management.
119
The following are the terms related to service level management: Customer Is the service consumer that represent the entity that the receive IT services. An example will be the eLoan department in PiggyBank, Inc. A group of customers that shares a common authentication group. A realm can consists of multiple customers, which represent different departments within a corporation. This may be the PiggyBank, Inc. A set of measurable services that are given by the provider for building service level objective. The key for offering is that the services must be measurable or quantifiable so an target number (objective) can be assigned and measured against it. The offering may be Web server number of request, or response time of the Web transaction. A set of time lapses that has a uniformed service need for a customer. The whole processing may be made of different schedules, each of which represent different processing needs, such as prime time, batch or continuous operation. This represent IT resources that can be matched to an offering. This can be the Web application server that runs the eLoad application, such as ELAUS01.
Realm
Offering
Schedule
Resource
Service level objectiveThe performance and/or availability objective for resources. This represents a set of: resource, offering, schedule and target level. An example is: response time of Web transaction on ELAUS01 under 5 seconds on prime schedule. Service Level Agreement A formalized service level objectives that has been agreed over by the service provider and service consumer. The service level management can be achieved using IBM Tivoli Service Level Advisor. In 5.2.2, IBM Tivoli Service Level Advisor architecture on page 120, we will see how IBM Tivoli Service Level Advisor works.
5.2.2 IBM Tivoli Service Level Advisor architecture

IBM Tivoli Service Level Advisor V2.1 is build upon Tivoli Data Warehouse Version 1 family. To understand IBM Tivoli Service Level Advisor, we need to understand Tivoli Data Warehouse. Figure 5-3 on page 121 shows the structure of Tivoli Data Warehouse.
120
Tivoli Data Warehouse

source database
Source ETL
Target ETL
TWH_CDW
TWH_MART
TWH_MD
Figure 5-3 Tivoli Data Warehouse
Tivoli Data Warehouse is a Tivoli extension of DB2 Data Warehouse system. There are several databases that are used by Tivoli Data Warehouse: TWH_MD Contains the processing metadata for Tivoli Data Warehouse, the database is owned by the Warehouse Server (vwkernel) process. Central data warehouse repository, in which all Tivoli systems management information are collected in this database. This database contains both the measurement metadata (what is measured, what are the resource types and their relation) and also the measurement result in the MSMT table. Reporting repository for Tivoli Data Warehouse, for which data is populated from the central data warehouse to provides specific answers for a system management questions.
TWH_CDW
TWH_MART
Tivoli Data Warehouse utilizes a processing called Extract Transform Load (ETL) to transfer data from one database to another. The ETLs are defined in the TWH_MD database. Tivoli Data Warehouse defines two sets of ETL process: The source ETL transfers data from the source database into the central data warehouse. The target ETL that extract data from the central data warehouse into the reporting database. The ETL processing are loaded and can be scheduled to run regularly. Each set of ETLs, tables and definitions for a certain system management application is grouped into a module called Warehouse Enablement Pack (WEP). Each WEP
121
has a three-characters code, which is called availability code or AVA-code. The AVA-code is used as table creator, ETL process name prefix, report identifier and database pointers. IBM Tivoli Service Level Advisor AVA-code is DYK. It uses DB2 warehouse processing based on Tivoli Data Warehouse ETLs. The processing of IBM Tivoli Service Level Advisor is shown in Figure 5-4.
IBM Tivoli Service Level Advisor

TSLA Service SLMAdmin Web application SLMReport Web application
Tivoli Data Warehouse

source database source database source database TWH_MD
Source ETL TL eE rc Sou
DYK ETL
TWH_CDW
DYK_DM
DYK_CAT
Figure 5-4 IBM Tivoli Service Level Advisor processing
IBM Tivoli Service Level Advisor extracts measurement information from Tivoli Data Warehouse central data warehouse repository and stores them in its own DYK_DM database. The IBM Tivoli Service Level Advisor service runs to compare measurement data in DYK_DM with the service level objective. The service level objectives and other administration information are stored in the DYK_CAT database. IBM Tivoli Service Level Advisor has two Web-based interface, the Administration interface and the Reporting interface. The administration interface provides the ability to manage realms, customers, offerings, schedules and Service Level Agreements. The reporting interface shows the published Service Level Agreement status and attainment.
5.2.3 PiggyBanks IBM Tivoli Service Level Advisor setup

The PiggyBank, Inc.s that is explained in 3.2, Piggybank, Inc. background on page 40 uses IBM Tivoli Service Level Advisor to manage its Service Level Agreement. The following are how the entities sets in PiggyBank, Inc.
122
So u
rc e
ET L
Customer structure We generate the following customers for PiggyBank, Inc.: Web banking Finance Human Resource Marketing Warehouse system
Schedule For PiggyBank, Inc, we define the following schedules: Work hours: 8:00 AM - 18:00 PM on workday Off hours: 18:00 PM - 8:00 AM on workday and all weekends All times: all the times Offering structure The offerings are shown in Table 5-1.
Table 5-1 Offering structure Name Web application Schedule All times Measurement Response time Transaction volume Availability Response time Transaction volume Availability Number of jobs Jobs in Error Jobs delay
Prime time application
Work hours
Batch system
Off hours
Service Level Agreement The Service Level Agreement is made by assigning offering to customer with resource and target assignment. The assignment is shown in
Table 5-2 Service Level Advisor Customer Web Services Offering Web application Resource EL* EB* Target Response time < 4 sec Transaction volume<100/min Availability>98%
123
Customer Finance
Offering Prime time appl Batch system
Resource FIN*
Target Response time < 4 sec Transaction volume<100/min Availability>98% Num of jobs<100 jobs/day Num of errors<5 errors/day Job delay<1 min delay Response time < 4 sec Transaction volume<100/min Availability>98% Num of jobs<100 jobs/day Num of errors<5 errors/day Job delay<1 min delay Response time < 4 sec Transaction volume<100/min Availability>98% Num of jobs<100 jobs/day Num of errors<5 errors/day Job delay<1 min delay Response time < 4 sec Transaction volume<100/min Availability>98% Num of jobs<100 jobs/day Num of errors<5 errors/day Job delay<1 min delay
Marketing
Prime time appl Batch system
MKT*
Human Resource
HRA*
Warehouse system
WHA*
In PiggyBank, Inc. the first implementation is to get service level for Batch job systems. This will be shown in 5.4, Service level for IBM Tivoli Workload Scheduler on page 130.
5.3 Getting batch management information

Batch management in IBM Tivoli Business Systems Manager can be collected from IBM Tivoli Workload Scheduler. The communication is using common listener adapter. The IBM Tivoli Workload Scheduler intelligent adapter also requires access to Microsoft SQL Server JDBC driver to access IBM Tivoli Business Systems Manager database directly.
5.3.1 Setting up IBM Tivoli Workload Scheduler intelligent adapter

The intelligent adapter for IBM Tivoli Workload Scheduler is provided in IBM Tivoli Business Systems Manager V3.1 interim fix 0006
124
(3.1.0.0-TIVBSM-IF0006). It also requires IBM Tivoli Workload Scheduler at Fix Pack 0005 or above. The intelligent adapter supplied with IBM Tivoli Workload Scheduler in tbsm subdirectory is obsolete and should not be used. To set up the intelligent adapter, you need to modify the following files: DB_Server.conf: This configuration file provides access information to IBM Tivoli Business Systems Manager Microsoft SQL Server. This file is a temporary file which will be encrypted using the DBServerEncryptor command that generate _DB_Server.conf file. Our sample configuration file is shown in Example 5-1.
Example 5-1 Sample DB_Server.conf [ADAPTER DRIVER] Server=pretoria User=sa Password=XXXX JdbcUrl=jdbc:microsoft:sqlserver:// JdbcClass=com.microsoft.jdbc.sqlserver.SQLServerDriver
localadapter.config: This represent the local Common Listener adapter configuration file. You need to identify both the local machine and the Common Listener server here. An excerpt of the file is shown in Example 5-2. The one in bold are the values that we customize.
Example 5-2 Sample localadapter.config adapter.type adapter.working.dir = LocalAdapter = ./log
adapter.register.timeout = 300 soap.envelope = <SOAP-ENV:Envelope xmlns:SOAP-ENV="http://schemas.xmlso ap.org/soap/envelope/" SOAP-ENV:encodingStyle="http://schemas.xmlsoap.org/soap/e ncoding/">\n\t<SOAP-ENV:Body> loggingmode.default loggingmode.filename = false = BaseTestLogging.log
trace.filename = BaseTestTrace.log trace.max.file.dim = 10240 trace.max.files.number = 3 adapter.trace.enable = false transport.trace.enable = true
125
adapter.trace.level = high transport.trace.level = high adapter.xml.validation = false # transport base properties transport.class.name = com.tivoli.commonlistener.transport.mqe.client.ClientTransportMQe transport.local.ip.address transport.request.address transport.request.port transport.response.address transport.response.port # MQe transport properties # queue store: these key can be "file", "memory" or "reduced" transport.mqe.local.queue.store = file transport.mqe.remote.queue.store = file transport.mqe.usefiller = false transport.mqe.fileregistry = com.ibm.mqe.registry.MQeFileSession transport.mqe.maxchannels = 1 # Time interval for the triggering thread. (Defalut = 10) transport.mqe.triggering.interval = 10 # server transport.server.mqe.address = ServerQM+ServerQ transport.server.mqe.port = 8082 transport.server.ip.address = pretoria = = = = = phoenix phoenix.BASETEST.QM+BASETEST.Q 9890 phoenix.BASETEST.QM+BASETEST.Q 9890
DriverPlugIns.conf: Configuration for the intelligent adapter definition, including the predefined enterprise name. See Example 5-3.
Example 5-3 Sample DriverPlugIns.conf [PLUG IN] PluginName=TWS CycleTime=120 MaxSecBack=-1 Enterprise=PiggyBank, Inc. #C1=---- COLLECTOR DATA ---CollectorMode=inline CollectorClassPath=. CollectorClassName=com.ibm.tbsmadapter.TWSCollector #C2=---- TOKENIZER DATA ----
126
TokenizerMode=inline TokenizerClassPath=. TokenizerClassName=com.ibm.tbsmadapter.TWSTokenizer #C3=---- RECOGNIZER DATA ---RecognitionMode=inline RecognitionClassPath=. RecognitionClassName=com.ibm.tbsmadapter.DefaultRecognizer
AdapterEnv.conf: Configuration on event types and property field mapping. The only item to be customized here is the IBM Tivoli Workload Scheduler instance. See Example 5-4.
Example 5-4 Sample AdapterEnv.conf [Adapter Env] ipnw_name_default=UNKNOWN sep=$(space) term=~ singlequote=_ prefix=W Hostname=phoenix TWSInstance=maestro event_receiver_port=3333 s_1=Active/Inactive s_2=BATC_Held s_3=Running s_4=Unknown s_5=Abended s_6=Completed s_7=BATC_Cancelled s_8=Pending s_9=Unknown s_10=Unknown s_11=Unknown s_12=Unknown s_13=Abended s_14=Unknown s_15=Unknown s_16=Starting s_17=Unknown s_18=Unknown s_19=Unknown s_20=Unknown s_21=Unknown s_22=Unknown s_23=Abended s_24=Pending s_25=Pending prop_1=CurrEstComplete
127
prop_2=StartTime prop_3=StopTime prop_4=Duration prop_5=TerminatingPriority prop_6=KeyStatus prop_7=Name prop_8=InitEstComplete prop_9=EstDuration prop_10=EstStartTime prop_11=InitiatingPriority prop_12=SchedStartTime prop_13=OPCWorkstationId prop_14=SchedDuration recov_1=stop recov_2=stop after recovery job recov_3=rerun recov_4=rerun after recovery job recov_5=continue recov_6=continue after recovery job recov_10=this is the rerun of the job recov_20=this is the run of the recovery job k_0=Nonkey k_1=Key
TWSConf.conf: This configuration shows there the event log file for IBM Tivoli Workload Scheduler is stored the default is under the IBM Tivoli Workload Scheduler home directory. See Example 5-5.
Example 5-5 Sample TWSConf.conf [TWSConf] eventlog=C:/win32app/TWS/maestro/event.log dumpfile=./dumpedpointer
$TWS_HOME/config/BmEvents.conf: You need to instruct batchman to write to an external event log from this file. Our sample excerpt is shown in Example 5-6.
Example 5-6 Sample BmEvents.conf OPTIONS=MASTER LOGGING=ALL FILE=C:\WIN32APP\TWS\maestro\event.log
The intelligent adapter for IBM Tivoli Workload Scheduler is now ready to be started. It should be running as a service called Tivoli BSM Intelligent Monitor for TWS.
128
5.3.2 Batch management console

In IBM Tivoli Business Systems Manager Java console, the batch jobs are represented by the Batch Schedule Set icon. The icon is represented by the master domain managers machine name. The icon is put directly under the enterprise object specified in <fn> as shown in Figure 5-5.
Figure 5-5 Batch schedule set icon
Opening the batch schedule set gives the batch management dialog shown in Figure 5-6 on page 130.
129
Figure 5-6 Batch management dialog
The dialog has three areas: List of batch engines; when you select an engine, it shows List of batch schedules or job stream, when you select a job stream, it shows List of batch jobs When a batch job is indicated to be monitored and is in the critical path the flag is shown in IBM Tivoli Business Systems Manager.
5.4 Service level for IBM Tivoli Workload Scheduler

In this section, we implement interface for IBM Tivoli Service Level Advisor integration to IBM Tivoli Business Systems Manager executive dashboard. We
130
display the Service Level information for batch processes running in our Piggybank environment. The discussion is divided into: 5.4.1, Batch interface to Tivoli Data Warehouse on page 131 5.4.2, Setting up IBM Tivoli Service Level Advisor on page 133 5.4.3, Defining Batch system in IBM Tivoli Service Level Advisor on page 135
5.4.1 Batch interface to Tivoli Data Warehouse

The batch processes are managed using IBM Tivoli Workload Scheduler. The interface for getting data warehouse data to Tivoli Data Warehouse is shown in Figure 5-7.
TWS database
archiver
TWH_CDW
Source ETL
tws_launch_archiver.pl
temp files
DB2 load
AWS.*
Figure 5-7 Batch interface for IBM Tivoli Workload Scheduler
IBM Tivoli Workload Scheduler sends batch information to IBM Tivoli Business Systems Manager using Common Listener. IBM Tivoli Workload Scheduler also feeds data into Tivoli Data Warehouse that later turns into Service Level Information. These are the steps that we need to perform for collecting IBM Tivoli Workload Scheduler data: 1. Assuming that Tivoli Data Warehouse and IBM Tivoli Service Level Advisor are correctly installed. We install the IBM Tivoli Workload Scheduler Web enablement pack. The AVA-code for IBM Tivoli Workload Scheduler is AWS. 2. We modify the tws_archiver_unload.pl to indicate the database server and its location. We schedule in IBM Tivoli Workload Scheduler to run the tws_launch_archive.pl every morning at 7:00 AM. Assuming that the
131
scheduler day starts at 6:00 AM, then at 7:00 AM, JNextDay has been successfully executed. The script load a day worth of batch information to the temporary database tables in DB2. 3. We schedule the Source ETL for IBM Tivoli Workload Scheduler to run on 8:00 AM to make sure that all archiving process has been done. The ETL can be scheduled from the Data Warehouse Center, which is invoked using the command db2cc -c dwc. Expand the tree Subject Areas to the IBM Tivoli Workload Scheduler process as shown in Figure 5-8.
Figure 5-8 AWS ETL process
The ETL schedule can only be changed when the process is in development mode. Right-click and select Mode Development. Right-click again and select Schedule to modify the schedule as shown in Figure 5-9 on page 133. Note that you only need to schedule the step: AWS_c10_s040_LoadComp, as the other process steps would be run depending on this step.
132
Figure 5-9 Scheduling ETL for 7 AM
When the ETL has been scheduled, we can set it back to production state using Mode Production. 4. We then schedule the IBM Tivoli Service Level Advisor ETL to run every morning at 10:00 AM to make sure that all the Source ETLs has been completed loading yesterdays data. This is similar to scheduling the AWS ETL.
5.4.2 Setting up IBM Tivoli Service Level Advisor

There are several items that need to be set in IBM Tivoli Service Level Advisor to be able to recognize IBM Tivoli Workload Scheduler information. 1. Enable the measurement source for IBM Tivoli Workload Scheduler. This is achieved using IBM Tivoli Service Level Advisor command line interface. The command line interface is initialize with the slmenv command. The measurement source list can be retrieved using the command scmd etl getApps. This session is shown in Example 5-7.
Example 5-7 Measurement source list C:\TSLA> scmd etl getapps
133
Measurement Source Code: BWM Application Name: Tivoli Web Services Manager Flag: N Measurement Source Code: APF Application Name: Tivoli Application Performance Management Flag: N Measurement Source Code: DMN Application Name: Distributed Monitoring Classic Edition Flag: N Measurement Source Code: GTM Application Name: Tivoli Business System Manager Flag: Y Measurement Source Code: ECO Application Name: Tivoli Enterprise Console Flag: N Measurement Source Code: MODEL1 Application Name: Tivoli Common Data Model v1 Flag: N Measurement Source Code: AMW Application Name: IBM Tivoli Monitoring Flag: Y Measurement Source Code: GWA Application Name: ITM for Web Infrastructure:Apache Flag: Y
2. You can add AWS as a new measurement source as shown in Example 5-8.
Example 5-8 Adding IBM Tivoli Workload Scheduler measurement C:\TSLA> scmd etl addApplicationData AWS "IBM Tivoli Workload Scheduler" DYKET1516I Data from IBM Tivoli Workload Scheduler with code AWS has been successfully enabled for registration into the SLM environment. C:\TSLA> scmd etl enable AWS DYKET1502I The application has been enabled.
3. Load the metadata for AWS. This is performed using the Data Warehouse Center. In Windows platform, the Data Warehouse Center is invoked using the command db2cc -c dwc. Select Warehouse Work In Progress and then Work In Progress Run new Step to run the step
134
DYK_m05_Populate_Registration_Datamart_Process, or also commonly known as registration ETL. 4. Set IBM Tivoli Enterprise Console to receive IBM Tivoli Service Level Advisor events. Load also the sample ruleset to forward SLA information to IBM Tivoli Business Systems Manager using the tbsmtsla.sh that is provided with the Event Enablement installation. 5. Enable escalation from IBM Tivoli Service Level Advisor to IBM Tivoli Enterprise Console. This is achieved by setting the IBM Tivoli Enterprise Console server name and port number using the CLI as shown in Example 5-9.
Example 5-9 Setting up TEC escalation C:\TSLA> scmd escalate enable tec -server phoenix -port 5529 Command completed successfully. C:\TSLA> scmd escalate enable applicationEvent Command completed successfully. C:\TSLA> scmd escalate TECLogging true Command completed successfully. C:\TSLA> scmd escalate test
The last command in send 4 sample events to IBM Tivoli Enterprise Console with the class of: SLM-Application-Event SLA-Trend-Event SLA-Trend-Cancel-Event SLA-Violation-Event This validates whether IBM Tivoli Enterprise Console can receive IBM Tivoli Service Level Advisor events.
5.4.3 Defining Batch system in IBM Tivoli Service Level Advisor

In IBM Tivoli Service Level Advisor, there are several items that we must define: Schedule Offering Realm Customer Service Level Agreement
135
The following procedure defines those objects using the SLM administration interface. 1. Define batch management offering using the SLM administration interface. Our IBM Tivoli Service Level Advisor server is phoenix, therefore the URL to get to the SLM administration page is:
http://phoenix:9080/SLMAdmin
The welcome window is shown in Figure 5-10.
Figure 5-10 Welcome window
2. We create a schedule to cover the whole day, as batch processes Service Level Agreement are usually does not differentiated by periods. The we choose Create Schedule from the My Work area. a. The schedule creation wizard is started. Click Next on the Welcome page. b. In the Name Schedule dialog shown in Figure 5-11 on page 137,fill in the name and click Next.
136
Figure 5-11 Giving a schedule name
c. In the Select Schedule Type, we define a new business schedule and click Next. See Figure 5-12 on page 138.
137
Figure 5-12 Selecting schedule type
d. You can include other auxiliary schedule, we do not include any so we just click Next in the Include Auxiliary Schedule dialog e. We can define new period in the Define Period dialog, click Create to invoke the period creation dialog. See Figure 5-13 on page 139.
138
Figure 5-13 Define period dialog
f. In the Create Period dialog, we specify a daily 24 hours rage as shown in Figure 5-14 on page 140. Click OK.
139
Figure 5-14 Period definition
g. Click Next from the Define Period dialog shown in Figure 5-13 on page 139, you get the Schedule Summary dialog shown in Figure 5-15 on page 141. Click Finish to save the schedule.
140
Figure 5-15 Summary dialog
3. Back in the Welcome screen, we can now create an offering. Select Create Offering from the My Work area. a. Click Next from the Welcome dialog and proceed to the Name Offering dialog shown in Figure 5-16 on page 142. Put in the name and click Next.
141
Figure 5-16 Defining a new offering
b. In Figure 5-17 on page 143, we select an external SLA and then click Next.
142
Figure 5-17 External SLA is selected
c. When asked to include other SLA, as this is the first SLA we created, we can just press Next. In Figure 5-18 on page 144, we select the business schedule we create in step 2 on page 136. Click Next.
143
Figure 5-18 Selecting schedule
d. In the include component dialog in Figure 5-19 on page 145, click Add. This will determine which metrics will be included in this offering and what are the threshold that the metric will be evaluated on.
144
Figure 5-19 Offering component
e. The components that can be added for IBM Tivoli Workload Scheduler are Workload Scheduler Job and Workload Scheduler Job Stream as shown in Figure 5-20. You need to find the appropriate branch for the Workload Scheduler resource type.
Figure 5-20 Adding component
145
f. The next screen is the metrics that you want to be included. Click on Add to include the metric from the metric list shown in Figure 5-21.
Figure 5-21 Modifying resource type
g. The job related metrics dialog series are shown in Figure 5-22 on page 146. First, we specify the metrics, then the breach value and the evaluation frequency.
Figure 5-22 Job related metric dialog
146
h. Similarly, the metrics that are available for the Job stream resource is shown in Figure 5-23.
Figure 5-23 Job stream metrics
i. After you completed specifying the resources and metrics, the offering summary as shown in Figure 5-24 allows you to save the offering. Click Finish to save.
147
Figure 5-24 Offering summary
4. Realm and customer can be created to define the PiggyBank, Inc. customer. We only create a realm called All. Use the Create Realm selection from My Work area and define the realm as shown in Figure 5-25 on page 148.
Figure 5-25 Create realm
148
5. Create a customer using the Create customer from My Work area. This give a welcome screen. Click Next to get to the Name Customer dialog shown in Figure 5-26.
Figure 5-26 Name customer dialog
Customer may belong to one ore more realm, we select the realm as shown in Figure 5-27.
149
Figure 5-27 Selecting realm
And you can save the customer from the summary dialog shown in Figure 5-28 and click Finish.
Figure 5-28 Customer summary
6. The last step is to associate an offering with a customer. This association is in the form of Service Level Agreement. The association binds an offering with a
150
customer and provides Filtering option for resource name that should be used for comparison in Service Level evaluation. Perform the following to create an SLA: a. In the MyWork area, select Create SLAs. b. In the Name SLA panel shown in Figure 5-29, name the SLA and optionally provide a description. Click Next.
Figure 5-29 Name SLA panel
c. In Figure 5-30 on page 152, select an existing customer to be associated with the SLA. Click Next.
151
Figure 5-30 Choosing a customer for the SLA
d. Assign a service for the Service Level Agreement. This is an optional property. However, this property is used for the IBM Tivoli Business Systems Manager integration to indicates which Executive View object will be associated with the event. The service selection is shown in Figure 5-31. These service objects are loaded from the IBM Tivoli Business Systems Manager ETL.
Figure 5-31 Select a service
152
e. In the Select Offering panel shown in Figure 5-32, select the offerings to be part of the SLAs definitions. Click Next.
Figure 5-32 Choosing the offering during SLA creation
f. In the Include Resources panel, click Add to add the resources. g. In the Select Resource List Type panel shown in Figure 5-33 on page 154), define the type of resources to add to the SLA. The Dynamic Resource List is used to group resources and create filter. Static resources are used for particular resources that are to be added. Click Next.
153
Figure 5-33 Selecting the resource list type
h. In the Filter Resource panel shown in Figure 5-34 on page 155, create a filter so that only relevant resources are listed. Select the attribute, condition, and value for the filter. For example, for Attribute, select Name; for Condition, select Contains; and for Value, select Trade. Click Next.
154
Figure 5-34 Creating a filter for the resources
i. The resources are displayed and you can select them to be included in the SLA definition. You can add or change resources in this panel. The resources must be defined to every metric used in the SLA. For example, our UserExperience offering has two metrics defined. In this case, resources must be assigned to both metrics. Figure 5-35 on page 156 shows the resources included for the first metric in the offering. Click Next.
155
Figure 5-35 Resources selected for the SLA
j. The Select SLA Start Data panel (Figure 5-36 on page 157) is displayed. The start date of the SLA is used to evaluate the previous monitoring data to verify the SLOs instantaneously. If there is no data, choose the default date (the current date). Optionally select the time zone for the SLA to be evaluated. Click the Recalculate the First Evaluation button to refresh the first evaluation date depending on the SLA start date. Figure 5-36 on page 157 shows the details used in the UserExperienceSLA definition.
156
Figure 5-36 Selecting the SLA start date
k. The summary of the SLA creation is displayed. Click Finish to complete the SLA creation. If the SLA start date is an earlier date, the SLA evaluates it immediately. See Figure 5-37 on page 158.
157
Figure 5-37 SLA summary
5.5 Getting Service Level information in dashboard

This section explains getting IBM Tivoli Service Level Advisor information in IBM Tivoli Business Systems Manager. Now at this stage, everything has been setup. To be able to see the overall integration, we will trace the processing of each components: Data from the archiver on page 158 Loading data to measurement table on page 159 TEC event generated on page 159 Executive dashboard on page 162
5.5.1 Data from the archiver

When tws_launch_archiver.pl is run, it generates a set of files in TEDW sub directory of the IBM Tivoli Workload Scheduler installation directory. The content of the directory is shown in Example 5-10 on page 159.
158
Example 5-10 Content of TEDW C:\win32app\TWS\maestro\TEDW>dir Volume in drive C has no label. Volume Serial Number is 3089-3BAD Directory of C:\win32app\TWS\maestro\TEDW 08/15/2005 08/15/2005 08/15/2005 08/15/2005 08/15/2005 10:07a <DIR> . 10:07a <DIR> .. 12:18p 1,056 Cpus 12:18p 1,568 Jobs 12:18p 198 Scheds 3 File(s) 2,822 bytes 2 Dir(s) 27,976,634,368 bytes free
The file is formatted to be load to a relational database. The tws_launch_archiver.pl save the data into TWH_CDW database with the creator of AWS. The list of tables is shown in Figure 5-38.
Figure 5-38 AWS tables in TWH_CDW
5.5.2 Loading data to measurement table

Data from the AWS tables are loaded using the ETL called AWS_c10_ETL_Process. When the ETL is run, it populates the TWG.MSMT table. Running the ETL can be is seen in the Work In Progress window, use Warehouse Work In Progress. The data is primarily collected in the TWG.MSMT table. We can now load the data into IBM Tivoli Service Level Advisor. This is achieved by running the ETL process: DYK_m10_Populate_Measurement_Datamart_Process The resulting data is stored in the DYK.MSMT table similar to the TWH.MSMT.
5.5.3 TEC event generated

After the collection, the data is evaluated. TEC trend or violation event can be generated. A sample generated TEC event is shown in Figure 5-39 on page 160.
159
Figure 5-39 TEC event
This TEC event is forwarded using the Agent Listener interface to IBM Tivoli Business Systems Manager. As IBM Tivoli Business Systems Manager identify the Service ID to correspond with an Executive View entry, it processes and stores the event for displaying in the dashboard. The event detail is shown in Figure 5-40 on page 161.
160
Figure 5-40 Event detail
161
5.5.4 Executive dashboard

From the executive dash board shown in Figure 5-41, we can see that IBM Tivoli Service Level Advisor is known from the small blue or red arrow-like icon. The blue icon indicates that the last event received is the SLA-Trend-Event, while the red icon indicates that the last event received is the SLA-Violation-Event.
Figure 5-41 Executive dashboard
Displaying the Service Level information is shown in Figure 5-42 on page 163.
162
Figure 5-42 Service Level information
To confirm this information, we can check the SLM report Web page at:
http://kingston:9080/SLMReport
The report is shown in Figure 5-43 on page 164.
163
Figure 5-43 Service level display
164
Chapter 6.
Using IBM Tivoli Intelligent Orchestrator to populate business systems structure

This chapter describes the possible integration scenario between IBM Tivoli Business Systems Manager and IBM Tivoli Intelligent Orchestrator. As IBM Tivoli Intelligent Orchestrator provides data center automation for configuration changes based on resource requirement, IBM Tivoli Business Systems Manager needs to be notified to update its business system information accordingly. This chapter provides a simple integration scenario that can easily be extended to include more complex integration scenarios. The discussion consists of: 6.1, IBM Tivoli Intelligent Orchestrator overview on page 166 6.2, Dynamic business system integration on page 177 6.2.3, Building workflow for adding a server on page 181
165
6.1 IBM Tivoli Intelligent Orchestrator overview

Many IT shops today purchase and dedicate separate test servers for each software development project. Often, these servers sit idle or under utilized during a large portion of the development cycle. One way to increase test server utilization is to create a common pool of servers to support multiple application development efforts. Servers can be provisioned for a specific application test when needed. Once the testing phrase is completed, servers are returned to the pool for other use. IBM Tivoli Intelligent Orchestrator and Tivoli Provisioning Manager is an excellent tool for managing test environment with shared resources. Workflows can be built to automate the configuration changes required when servers are repurposed from one project to another. Integrating with Remote Deployment Manager and Tivoli Configuration Manager, IBM Tivoli Intelligent Orchestrator can provision a server from the bare-metal state to a fully populated configuration with base operating system and customized software stack based on a customer defined reference model. IBM Tivoli Intelligent Orchestrator configures resources among applications in a multiapplication environment to balance end-user traffic demands, excess capacity, and service level targets. Once a deployment decision is made, IBM Tivoli Intelligent Orchestrator runs workflows to automatically make the required configuration and allocation changes. Some sample changes that can be accomplished using workflows are: Modifications to data center infrastructure (route changes, VLAN assignments) Configuration and allocation of servers (software installation, configuration) Specific command actions (reboot server, power off device, install image) In this redbook, we are using IBM Tivoli Intelligent Orchestrator Version 3.1.
6.1.1 Terminologies
These key terms are introduced to give a context and common vocabulary: Workflow A series of steps that are sequentially executed to accomplish a particular task. A step in a workflow is called a transition. Each workflow has a single compensating workflow that is executed if any transition fails. Also referred to as TC driver, device driver, or simply driver, an automation package is a collection (or a container) of commands, shell scripts, workflows,
Automation package
166
logical operations, and Java plug-ins that applies to the operation of one specific type of software component or a physical device. It contains a grouping of tasks that corresponds to a physical or logical device. These tasks typically implement logical operations. A device could be a specific piece of hardware, an operating system, a service, or a cluster.
Logical operation A task that is abstracted from its implementation. Logical operations are implemented using Enterprise Java Beans (EJB). They provide a common interface and can perform logic. An example is a data center task of adding an IP address. It is a logical operation in that it makes no assumptions about the implementation. A step in a workflow. This could be another workflow, a logical operation, a simple command, or a Java plug-in. A representation of all of the physical and logical assets under IBM Tivoli Intelligent Orchestrator management.
Transition
Data Center Model
Figure 6-1 on page 168 illustrates the relationships between workflows, the Data Center Model, transitions, device models, and more.
Chapter 6. Using IBM Tivoli Intelligent Orchestrator to populate business systems structure
167
Data Center Model
The DCM contains assets and resources.

Assets and Resource
An asset uses a device model to gain a set of capabilities.

Device Models
Device models implement Logical Operations.

Logical Operations
Logical Operation are implemented by workflows.

Workflow
A transition can be a workflow
Workflows are made up of transitions.
Transition
Figure 6-1 Data center relationship model
Customer Application Application cluster
A customer owns applications. Customers can be unique corporations or departments within a single corporation. A grouping of one or more clusters. Service level priority (Silver, Gold, Platinum) is assigned at this level. A grouping or container for like resources or servers that support an application. Automated resource allocation and deallocation occurs at the cluster level. A container of available (deallocated) servers that support one or more application clusters. Also referred to as a spare pool. Data Center Model objects that represent physical servers. They belong to or are assigned to pools and clusters.
Resource pool
Servers
Figure 6-2 on page 169 illustrates the relationship between customers, applications, clusters, pools, and servers.
168
Customer
Customers have applications.

Applications
Applications are made up of one or more clusters.

Clusters
Clusters acquire resources from pools. (Note: clusters can have servers, too.)
Pools
Pools are made up of servers.

Servers
Figure 6-2 Customer relationship model
6.1.2 Architecture
This section introduces components of the IBM Tivoli Intelligent Orchestrator architecture. Figure 6-3 on page 170 depicts a more detailed view of the IBM Tivoli Intelligent Orchestrator component architecture.
169
Policy Engine s compone nts
GLOBAL RESOURCE MANAGER

Optimizer
Optim al requests
Stabilizer
Stable requests
Resource Pool Manager

Best Server
Queries
Resource Managers
W orkloa Classifi Predicto d Model er r APPLICATION CONTROLLER W orkloa Classifi Predicto d M odel er r W orkload Predictor Classifier M ode l
Filtered App1 Perf Data
Deployment
APPLICATION CONTROLLER APPLICATION CONTROLLER
JDBC
Requests
DEPLOY MENT ENGINE

W orkflow
DATA ACQUISITION ENGINE

FIR Digital Filter
C DB
DATA CENTER MODEL

J
JDBC Step 1 Step 2 Step n
JMX Driver
SNM P Driver
SNM P Driver
SSH Driver
MP
DATA CENTER
Figure 6-3 IBM Tivoli Intelligent Orchestrator Architecture
IBM Tivoli Intelligent Orchestrators architecture includes the following main components: The Data Acquisition Engine is responsible for acquiring and preprocessing performance metric data from each managed application environment. Data can be captured and filtered from the operating system and infrastructure layers. This component can also distribute signals to other components of the IBM Tivoli Intelligent Orchestrator. This component participates in the information-gathering task.
170
SN
SS H
Resource Allocations
Note : This inc ludes a Br e ach Pr obability Dis tr ibution Function of the number of s erv ers alloc ated and time into the f uture
Distributions
Recommendations
Infrastructure Needed
B JD C
SN
JM X
M P
An instance of the Application Controller component is created for each application environment under management. Based on the applications workload model and predictions, as well as on real-time performance data (acquired from the Data Acquisition Engine), this component determines the resource requirements of the application. This component provides information to the decision-making task. The Deployment Engine component is responsible for the creation, storage, and execution of repeatable workflows that automate the configuration and allocation of assets. A workflow can represent either an entire reconfiguration process affecting multiple servers or a single step in a larger reconfiguration process. The data center model component represents all of the physical and logical assets under IBM Tivoli Intelligent Orchestrator management, such as servers, switches, load balancers, application software, VLANs, security policies, and service level agreements. It keeps track of data center assets and associated allocations to customer applications. This component participates in cluster visualizing and configuring. The Global Resource Manager receives requirements for servers or network devices from all Application Controllers and manages the overall optimization of data center assets. It has two primary responsibilities: It makes optimal resource allocation decisions. It ensures a stable control over the application infrastructure. This component participates in the decision-making task. Considering the different server requirements for each application environment, it determines where the servers are to be allocated. The management interface provides an overview of the state of all physical and logical assets in the data center infrastructure, offering information about the servers and their allocation, and generating configurations and allocations. It can also be used to create application environments. It includes two user interfaces: a Web-based interface and a command-line interface. To access the Web UI, the following URL syntax is used:
http://<host>.<domain>:<port>/tcWebUI
Figure 6-4 on page 172 shows the Web-based interface.
171
Figure 6-4 IBM Tivoli Intelligent Orchestrator Web Management Interface
6.1.3 New features for Version 3.1

In IBM Tivoli Intelligent Orchestrator Version 31, there are the following updated features that we will discuss as the implementation is dependent to these features: Job Distribution Services on page 172 Tivoli Common Agent on page 173
Job Distribution Services

Job Description Services is a job agnostic system that allows to define structured jobs that get executed on the endpoints asynchronously. Being job agnostic makes it easy to define new jobs to be executed on the endpoints. The endpoints agents are the only entities that interpret the jobs and execute them.
172
Jobs can be dispatched to many thousands of endpoint targets. The target group composition can be heterogeneous. Figure 6-5 shows a conceptual role of Job Distribution Service.
IBM Tivoli Intelligent Orchestrator WebSphere Application Server

Job distribution service Data Center Model
Web Services SOAP/HTTP/SSL
Event Framework
Event Consumer
Agent Manager
Tivoli Common Agent
Connector Bundle
Service Management Framework
Job Management Service Job Distribution Service Bundle
Inventory Scan Service Inventory Service Bundle
Local Command Execution Service Command Execute Bundle
Figure 6-5 Job Distribution Service
Tivoli Common Agent

Also in IBM Tivoli Intelligent Orchestrator Version 3.1, a new concept of Tivoli Common Agent is used for its agent infrastructure. IBM Tivoli Intelligent Orchestrator Version 3.1 provides agent installation using the Web user interface or with a CD. As soon as the agent is installed using the Web interface, the Data Center Model can be populated with the inventory data. The agent have a timer service to perform periodic tasks such as inventory scans. Figure 6-6 on page 174 shows components and architecture of Tivoli Common Agent.
173
Orchestrator Server Agent Manager
Sub-agent Store
Agent Registration Service
Resource ResourceManager Manager
Resource Manager
Common Agent
Common Agent
Common Agent
Common Agent
Common Agent
Figure 6-6 Tivoli Common Agent
The Common Agent Services consists of: Tivoli Common Agent The common agent consists of a number of services and is a common container for all the subagents to run within. The services are defined in the following sections of this document. Agent Manager The agent manager provides functions that allow clients to get information about agents and resource managers. It also includes the Agent Registration Service, which handles security (certificates), registration and tracking of common agents (and groups of common agents), and status collection and forwarding. The Agent Manager is deployed in a WebSphere Application Server The Subagent Bundle Store The subagent bundle store is a URL or accessible filesystem where you place subagent bundles so they can be installed by the common agents as needed. The groups of subagent bundles are depicted by the subagent store in the above figure. The Common agent provides the following: Provides an extensible platform on which to build functionality based on OSGi.
174
Includes common services (such as, security, and communications) to other services running under the framework. Factoring out common services helps keep the agent footprint small. Security services take care of wire level security, authentication and peer-verification. Peer verification prevents man-in-the-middle attacks, so there are no rogue processes impersonating management systems and taking over agents. Communication services facilitate Web services for agent services. Also handles socket level communications over secure connections In addition to the components provided by the Common Agent Services, the products will each have their own managers (called resource managers) and agents (called subagent bundles) (Green): Resource manager are the Tivoli products manager or server components. Subagent bundles are the Tivoli products agent components. Subagents will be shipped for various Tivoli products. The Tivoli Common Agent installation is provided from the Web interface using the Tasks view, and select Discovery Discovered Servers Install Common Agent as shown in Figure 6-7.
Figure 6-7 Common agent installation
175
Tip: If you want to use Tivoli Common Agent together with Tivoli Endpoint on a Windows 2000 machine, you need to install Tivoli Endpoint first. You can then install Cygwin and then install Tivoli Common Agent.
Automation Package Development Environment

Tivoli Intelligent Orchestrator contains the Workflow Composer Web interface to create workflows, but the recommended approach for developing and managing workflows and automation packages is to use the Automation Package Development Environment (APDE). APDE is an Eclipse-based plug-in environment used for building workflows and automation packages that can be used in IBM Tivoli Intelligent Orchestrator to manage data centres. The automation package specifically consists of the scripts, workflows, documentation and Java plug-in files for the device or software package. An automation package will have a .tcdriver extension they are located in the $TIO_HOME/drivers directory of the Tivoli Intelligent Orchestrator server. APDE interacts with IBM Tivoli Intelligent Orchestrator database for runtime information including available automation packages, workflows and device drivers (device model) It submits workflow execution request to IBM Tivoli Intelligent Orchestrator using SOAP and talks to Database for workflow execution results. Figure 6-8 on page 177 shows the concept of workflow development with APDE.
176
Development workstation
Intelligent Orchestrator
Automation Package Development Environment APDE
IBM Tivoli Intelligent Orchestrator
JDBC type 2
DB2 Client
DB2 Database
Figure 6-8 Automation Package Development Environment
6.2 Dynamic business system integration

This scenario is designed to demonstrate how IBM Tivoli Business Systems Manager shows dynamic resource assignment using capacity on demand orchestration provided by IBM Tivoli Intelligent Orchestrator. IBM Tivoli Business Systems Manager business view should reflect the changes of resource pools in its business system view. With a typical workload, this HTTP based application is adequately supported by a dedicated Web server running in Dublin. During the peak hours when demand increases, IBM Tivoli Intelligent Orchestrator can monitor server utilization and arrival rate to determine whether an imminent breach of service level may occur. IBM Tivoli Intelligent Orchestrator can dynamically deploy additional HTTP Web servers from its resource pools to the application cluster to support the increasing demand, and at the same time able to reflect the resource addition to IBM Tivoli Business Systems Manager business views. When workload diminishes, excess servers are returned to the resource pool for potential use by other applications and also will be able to delete the resource from IBM Tivoli Business Systems Manager. As this provisioning and decommissioning operations are performed automatically, IBM Tivoli Business Systems Manager must understand which business system will receive the allocated resource.
177
Being able to provision servers among resource pool allows customers to align their IT resources to the changing business objectives and priorities. It provides an automated and unattended method to prepare hardware systems to assume new functions. Since the provisioning method is automated, it is less prone to errors and requires operators with lesser skills to implement. This scenario demonstrates policy-based orchestration where IBM Tivoli Intelligent Orchestrator server can sense and respond automatically to changing Web based HTTP application demand.
6.2.1 Data Center Model in IBM Tivoli Intelligent Orchestrator

Data center model includes a representation of all of the physical and logical assets under IBM Tivoli Intelligent Orchestrators management such as servers, switches, load balancers, applications software, and so on. It keeps track of the data center hardware and their associated allocations to applications. IBM Tivoli Intelligent Orchestrator provides a Web-based graphical user interface. The GUI provides an overview of the state of all physical and logical assets in the data center infrastructure, offering information about the servers and their allocation, and generating configurations and allocations. The IBM Tivoli Intelligent Orchestrator Data Center Model can be built in one of the two ways: Defining each component using the Web management GUI Importing the DCM definitions using one or more XML files The advantage of the Web Management GUI are that it is easy but time consuming but the main disadvantage is that the center model cannot be re-used on any other projects as there is no export facility in IBM Tivoli Intelligent Orchestrator 3.1 Building the DCM using XML files on the other hand can be quite complex, time consuming and prone to errors. The main advantage of this method is that it can be re-used, copied and extended more easily at any time in the future. The orchestration environment is shown in Figure 6-9 on page 179
178
Figure 6-9 Orchestration environment
Within our data center model, we have defined one customer called PiggyBanking. Under this customer, we have one application defined the WebBanking application with one server cluster called HttpTiers. We also define 2 resources pools called SpareWinPool and W2kPool. SpareWinPool contains pristine systems with just the OS installed. W2kPool contains window OS system with Tivoli Endpoint and the Tivoli Common Agent pre-installed. It is the overflow pool defined for the HttpTiers cluster. Server bangkok is in this pool and is ready to provision and de-provision. As shown in Figure 6-9, dublin is a dedicated resource to the HttpTiers cluster, while bangkok is ready for provisioning and de-provisioning. The status for servers for a particular customer can be seen in the customer display as shown in Figure 6-10 on page 180.
179
Figure 6-10 Servers view
6.2.2 Designing the workflow

We decide that there are two workflows that will be developed in this scenario. Although is a simplification of a real environment, the example is quite generic that can be expanded to include other possibilities. These are the workflows that we will build: Adding a server workflow Removing a server workflow
Adding a server
We assume that the machines in the resource pool already runs Windows Operating Systems, with Tivoli endpoint and Tivoli Common Agent running. To add a server, we need to perform the following tasks: 1. Install IBM HTTP Server. 2. Define the HTTP Server object to Tivoli Framework and start monitoring it. This can be performed using one of the following approaches: Put Tivoli Common Agent on a ManagedNode to be able to issue Framework command. Send a TEC event so TEC can automatically runs the necessary commands. 3. Discover the HTTP Server resource in IBM Tivoli Business Systems Manager. The discovery can be performed using the standard discovery mechanism in IBM Tivoli Monitoring, or using an XML file through Common Listener.
180
4. Allocate the HTTP Server object to a business system view in IBM Tivoli Business Systems Manager. This is performed using XML file creation and sending it through the XML toolkits enqueuecl command. This workflow may include additional steps to ensure that the new server meets specifications of the destination cluster, but these are not the topic of interest in this scenario.
Removing a server
The steps on removing a server is the exact reversal of the addition. With the same assumption that the resource pool still contain the Tivoli endpoint and Tivoli Common Agent, these are the steps the remove a server: 1. Remove the HTTP Server object from IBM Tivoli Business Systems Manager. This can be performed using XML file and send it using the enqueuecl command. 2. Remove the HTTP Server object in Tivoli Framework, again this can be performed either using a Common Agent to issue Framework command or sending an event to TEC to trigger an automated response. 3. Remove the physical resource from the IBM Tivoli Business Systems Manager All Resources view. Depending on the creation method, this can be performed using a discovery delete or removing it by XML interface. 4. Uninstall the IBM HTTP Server Note: Using an Automated Business Systems can allocate the resource in a Business System folder and removing the physical resource will remove the business system resource associated with it. However, as the same resource can be allocated to different pools or application, the usage of XML is more appropriate as it allows dynamic specification of the business systems that will contain the resource.
6.2.3 Building workflow for adding a server

In IBM Tivoli Intelligent Orchestrator terms, a workflow is a representation of the set of steps that must be followed in a data center environment in order to carry out a provisioning operation. A workflow is the manual tasks an IT operator would normally do to take a machine into production. The tasks could be a combination off loading an operating system, loading applications, patching both operating system and applications, and so on. The way that these tasks are outlined in IBM Tivoli Intelligent Orchestrator is using a data center model, logical devices, workflows and Java-plugins. The workflow is the steps to fulfil the logical operation and acts
181
as the vehicle to bind the operation to the specific device driver. The final step is the execution of the software code or Java-plugin that interface with the physical device.
Coding the workflow for adding server

As discussed in Adding a server on page 180, the workflow is build based on the algorithm presented there. Lets try to analyze what are necessary to build the workflow. 1. Initialize the workflow, the workflow is started by getting the request information as shown in Example 6-1.
Example 6-1 Initialize the workflow workflow ITSO_AddServer(in ClusterID, inout ServerID) implements Cluster.AddServer LocaleInsensitive var RequestID Get_Current_Deployment_Request_Id(RequestID)
2. Finding the appropriate server for installation from the appropriate pool as shown in Example 6-2.
Example 6-2 Getting the server from the pool var ClusterName = DCMQuery(/cluster[@id=$ClusterID\]/@name) var PoolID java: com.thinkdynamics.kanaha.de.javaplugin.resourcemanager.RMAllocateServer( ClusterID, PoolID, RequestID, ServerID) Get_Server_Attributes(<null>, <null>, <null>, <null>, <null>, <null>, <null>, <null>, <null>, PoolID, ServerID, <null>)
3. Install IBM HTTP Server, this can be invoked using the provided method ATS_Install_IHS as shown in Example 6-3.
Example 6-3 Installing IBM HTTP Server var DeviceName = DCMQuery(/server[@id=$ServerID\]/@name) var hostname = Jython(DeviceName + ".itsc.austin.ibm.com") ATS_Install_IHS(ServerID)
4. Define the HTTP Server object to Tivoli Framework and start monitoring it. We send an event to IBM Tivoli Enterprise Console to invoke a command. We call the event is TIO_Automation and the argument is the command to be invoked. The workflow snippet is shown in Example 6-4 on page 183.
182
Example 6-4 Sending TEC event var DeviceName = DCMQuery(/server[@id=$ServerID\]/@name) var tecClass = "TIO_Automation" array slotlist = {"msg"} var var3=Jython("'../../scripts/addnode.sh "+ DeviceName + "'") array slotvalue slotvalue[0]=var3 SendTecEvent(tecClass, slotlist , slotvalue )
The event will be processed using a TEC rule shown in Example 6-5.
Example 6-5 TEC rule for TIO_Automation rule: run_TIO_automation: ( description: 'running automation command from TIO', event: _event of_class 'TIO_Automation' where [ msg: _msg ], reception_action: run_Auto: ( exec_program(_event, _msg, '', [], 'YES') ) ).
The script for adding the node is shown in Figure 6-11.
#!/bin/sh # \\phoenix\c$\tivoli\bin\w32-ix86\scripts wapachews -c -e $1 -t ibm -f "C:/Program Files/IBM HTTP Server 2.0/conf/httpd.conf" wln @ApacheWebServer:ApacheWebServer1@$1 /Administrators/Root_phoenix-region/phoenix-region # subscribe to Apache-pm wsub @ProfileManager:Apache-pm @ApacheWebServer:ApacheWebServer1@$1 wdmdistrib -p Apache-profile @ApacheWebServer:ApacheWebServer1@$1 exit Figure 6-11 The addNode.sh
183
5. We run a Java program to discover the resource object and create the business system using XML interface. We embed the call to the interface within the Java program. This Java program is called using the code snippet shown in Example 6-6.
Example 6-6 Creating and sending XML file var hostname = Jython(DeviceName + ".itsc.austin.ibm.com") var return_val = Java[com.ibm.itso.vbd.tia507.DeltaAddAll#runWork("1", DeviceName,hostname)]
The Java code for adding server

The complete source code for the Java program can be found in Appendix A, Additional material on page 245. This section provides the illustration of the important parts of the code. The Java classes are implemented as shown in Figure 6-12.
com.ibm.vbd.tia507 XMLSend
DeltaAddAll
DeltaDelAll
Figure 6-12 Java class structure
The XMLSend class contains the basic routines that builds the XML code and sends through the XML toolkit. The following are methods available from XMLSend: getEpRegion getEpLocation sendTecEvent deleteObject defineObject defineLink defineLinkPath enqueueCl Getting the Network Region object from the location Getting the Network Location object from the hostname Sending a Tivoli Enterprise Console event Generating XML code for deleting object Generating XML code for creating new object Generating XML code for defining link using instance ID Generating XML code for defining link using an object path Running the actual enqueueCl process
184
The complete code is provided as additional material. See Appendix A, Additional material on page 245. The DeltaAddAll is invoked using the syntax shown in Example 6-7.
Example 6-7 Invocation of com.ibm.itso.vbd.tia507.DeltaAddAll DeltaAdd wsnum epname ephost where:wsnum - Web server number (most likely = 1) epname - endpoint label (output from wep ls) ephost - endpoint fully qualified hostname
The main subroutine calls directly the constructor, passing in all three arguments, the Web server number, endpoint name and endpoint hostname. The constructor validates the argument to ensure that: The Web server number is numeric Endpoint hostname starts with the endpoint name The constructor of DeltaAddAll then perform the code in Example 6-8.
Example 6-8 DeltaAddAll processing nodeName = new String("ApacheWebServer"+wsnum+"@"+epname+"@"+ephost); nodePath = new String(entname+"/"+ getEpRegion(getEpLocation(ephost))+"/"+ getEpLocation(ephost)+"/"+ephost+"/"+nodeName); nodeClass = new String(XMLSend.tbsmClass); BSVname = new String(XMLSend.bsvName); String fn = "DADD"+getTimestamp()+".xml"; createXML(fn); run(fn,"delta");
As shown in Example 6-8, the main processing is to run XML creation using the createXML subroutine and invoking enqueuecl using run subroutine. The XML file creation logic is shown in Example 6-9.
Example 6-9 XML file creation routine FileWriter ofw = new FileWriter(fn); ofw.write(defineObject("NetworkRegion", getEpRegion(getEpLocation(ephost)), "NREG/"+getEpRegion(getEpLocation(ephost)))); ofw.write(defineObject("NetworkLocation", getEpLocation(ephost),"NLOC/"+getEpLocation(ephost))); ofw.write(defineObject("NODE",ephost,"NODE/"+ephost)); ofw.write(defineObject(nodeClass,nodeName,nodeClass+"/"+nodeName));
185
ofw.write(defineLink("PHYC",nodeClass, nodeClass+"/"+nodeName, "NODE", "NODE/"+ephost)); ofw.write(defineLink("PHYC","NODE", "NODE/"+ephost, "NetworkLocation", "NLOC/"+getEpLocation(ephost))); ofw.write(defineLink("PHYC","NetworkLocation", "NLOC/"+getEpLocation(ephost), "NetworkRegion", "NREG/"+getEpRegion(getEpLocation(ephost)))); ofw.write(defineLink("PHYC","NetworkRegion", "NREG/"+getEpRegion(getEpLocation(ephost)), "ENT","")); ofw.write(defineObject("LineOfBusiness",nodeName, "LOB/"+BSVname+"/"+nodeName)); ofw.write(defineLink("LOBC","LineOfBusiness", "LOB/"+BSVname+"/"+nodeName,"LineOfBusiness","LOB/"+BSVname)); ofw.write(defineLink("LOBL",nodeClass, nodeClass+"/"+nodeName, "LineOfBusiness","LOB/"+BSVname+"/"+nodeName)); ofw.close();
Note: The XML file created using the method in Example 6-9 on page 185 defines non LOB object. This is achieved by providing undocumented flag of -k to the enqueuecl process. The resulting XML file to define the WebServer 1 in manila with the fully qualified hostname of manila.itsc.austin.ibm.com is shown.
Table 6-1 XML definition result Code snippet defineObject("NODE",ephost, "NODE/"+ephost) Resulting XML <tbsm:addObjectInstances> <inst> <class>NODE</class> <instid>NODE/manila.itsc.austin.ibm.com</instid> <name>manila.itsc.austin.ibm.com</name> </inst> </tbsm:addObjectInstances> <tbsm:addObjectInstances> <inst> <class>LineOfBusiness</class> <instid> LOB/WebServers/ApacheWebServer1@ manila@manila.itsc.austin.ibm.com </instid> <name> ApacheWebServer1@manila@manila.itsc.austin.ibm.com </name> </inst> </tbsm:addObjectInstances>
defineObject("LineOfBusiness" ,nodeName,"LOB/"+BSVname+"/"+ nodeName)
186
Code snippet defineLink("LOBL",nodeClass, nodeClass+"/"+nodeName,"LineO fBusiness","LOB/"+BSVname+"/" +nodeName)
Resulting XML <tbsm:addLinkInstances> <link> <type>LOBL</type> <src> <id> <class>G02Ocname</class> <instid>G02Ocname/ApacheWebServer1@manila @manila.itsc.austin.ibm.com</instid> </id> </src> <tgt> <id> <class>LineOfBusiness</class> <instid>LOB/WebServers/ApacheWebServer1@manila @manila.itsc.austin.ibm.com</instid> </id> </tgt> </link> </tbsm:addLinkInstances>
A sample of complete XML file is given in <app<.
Defining workflow in Orchestrator

In this scenario, we are using the Workflow Composer. The workflow composer is available from the Configuration view of the Web management interface. We create the workflow using Workflow Edit Add Workflow. The new empty workflow window is shown in Figure 6-13 on page 188.
187
Figure 6-13 Empty new workflow
We use the name ITSO_AddServer for our workflow by clicking on the workflow name as shown in Figure 6-14.
Figure 6-14 Rename the workflow
You can then put your logic in the workflow. We on the other hand export the workflow to a text file, in order for us to modify it with our own text editor. This has the advantage of getting it in plain text, but we have no assistance from the Web interface for the syntax. We use the menu Edit Export and export it as a wkf
188
file. We modify this file and putting in the logic presented in Coding the workflow for adding server on page 182. We can then import this workflow, back to the Web management interface using the menu Edit Open and select the workflow file that you edit. After the workflow has been imported, we need to compile it before running it. The compilation will save the workflow. The compile menu is shown in Figure 6-15.
Figure 6-15 Compiling a workflow
6.2.4 Building workflow for removing a server

Similar to the adding server workflow discussed in 6.2.3, Building workflow for adding a server on page 181, the ITSO_RemoveServer workflow is described here.
Coding the workflow for removing server

The workflow for removing a server follows the logic presented in Removing a server on page 181. The logic is: 1. Initializing the workflow process as shown in Example 6-10.
Example 6-10 ITSO_RemoveServer.wkf initialization workflow ITSO_RemoveServer(in ClusterID, inout ServerID) implements Cluster.RemoveServer LocaleInsensitive var RequestID Get_Current_Deployment_Request_Id(RequestID)
189
var PoolID Get_Cluster_Attributes(<null>, <null>, ClusterID, <null>, <null>, <null>, <null>, <null>, <null>, <null>, PoolID, <null>, <null>, <null>, <null>, <null>) java:com.thinkdynamics.kanaha.de.javaplugin.resourcemanager.RMChooseServerForRe moval(ClusterID, PoolID, RequestID, ServerID)
2. Removing the server from IBM Tivoli Business Systems Manager using XML interface program as shown in Example 6-11.
Example 6-11 ITSO_RemoveServer.wkf var DeviceName = DCMQuery(/server[@id=$ServerID\]/@name) var hostname = Jython(DeviceName + ".itsc.austin.ibm.com") var return_val = Java[com.ibm.itso.vbd.tia507.DeltaDelAll#runWork("1", DeviceName,hostname)]
3. Removing the server from Tivoli Management Environment using a TEC event as shown in Example 6-12.
Example 6-12 ITSO_RemoveServer.wkf var tecClass = "TIO_Automation" array slotname = {"msg"} var var3=Jython("'../../scripts/delnode.sh "+ DeviceName + "'") array slotvalue slotvalue[0]=var3 SendTecEvent(tecClass, slotname , slotvalue )
The delnode.sh contents is shown in Figure 6-16.
#!/bin/sh # \\phoenix\c$\tivoli\bin\w32-ix86\scripts wdel @ApacheWebServer:ApacheWebServer1@$1 exit 0 Figure 6-16 The delNode.sh
4. Uninstalling IBM HTTP Server and returning the server to the server pool, this is shown in Figure 6-13.
Example 6-13 ITSO_RemoveServer.wkf RM_Remove_Server(ClusterID, RequestID, ServerID) ATS_Uninstall_IHS(ServerID)
190
Java code for removing server

The Java code in DeltaDelAll is very similar to the DeltaAddAll. The main difference is in the createXML subroutine. The createXML subroutine for DeltaDelAll is shown in Example 6-14.
Example 6-14 DeltaDelAll createXML function FileWriter ofw = new FileWriter(fn); ofw.write(deleteObject(nodeClass,nodeClass+"/"+nodeName)); ofw.write(deleteObject("LineOfBusiness","LOB/"+BSVname+"/"+nodeName)); ofw.close();
6.3 Integration in action

In this section, we run the workflow and shows the result it create. We show them in the following sections: 6.3.1, Adding a Web server on page 191 6.3.2, Removing a Web server on page 195
6.3.1 Adding a Web server

From the Workflow list, run ITSO_AddServer workflow using the Run menu as shown in Figure 6-17.
Figure 6-17 Running a workflow
191
Input the parameters, which are the Cluster ID and Server ID. The cluster ID and server ID are both required parameters. These parameters are defined in the programs you need to pass. You can get these values from the Inventory view as shown in Figure 6-18.
Figure 6-18 Getting Server ID
The parameter window is shown in Figure 6-19. We run the workflow against server manila.
Figure 6-19 Parameter for the ITSO_AddServer
192
The execution log result is shown in Figure 6-20.
Figure 6-20 Execution result
The TEC event generated by the workflow can be seen in Figure 6-21 on page 194.
193
Figure 6-21 TEC event
The new Apache Web server object is created in the Tivoli desktop as shown in Figure 6-22.
Figure 6-22 New Web server created in the desktop
And the IBM Tivoli Business Systems Manager business system creation as shown in Figure 6-23 on page 195.
194
Figure 6-23 Business systems creation
6.3.2 Removing a Web server

Dynamic removing Resources from IBM Tivoli Business Systems Manager through IBM Tivoli Intelligent Orchestrator. Here is an example of the workflow ITSO_RemoveServer. Again, we simulate the execution of the workflow by running it manually as shown in Figure 6-24 on page 196.
195
Figure 6-24 Running ITSO_RemoveServer
The workflow execution log is shown in Figure 6-25 on page 197.
196
Figure 6-25 Execution log of ITSO_RemoveServer
The workflow remove IBM Tivoli Business Systems Manager related object using the XML transaction. The resulting business system is shown in Figure 6-26 on page 198.
197
Figure 6-26 Business system with removed object
198
Chapter 7.
Problem management integration with the Peregrine Service Center

Problem management and problem ticketing is critical to ensure that all incidents are properly resolved and recorded. This is to ensure that there is no lingering problem that is unknown and to be able to resolve any future similar problem quickly. Peregrine Service Center is one of the leading problem management applications, and we demonstrate the integration of Peregrine Service Center to IBM Tivoli Business Systems Manager. The discussion in this chapter is divided into: 7.1, Peregrine Service Center overview on page 200 7.2, Implementing SCAuto for TBSM on page 205 7.3, Removing SCAuto for TBSM on page 229 7.4, Using Problem Ticketing on page 230 7.5, Troubleshooting on page 242
199
7.1 Peregrine Service Center overview

Peregrine Service Center allows a single access point to various changing needs of end users and IT department by ensuring a consistent delivery and measurable IT services. Peregrine Service Center provides an integrated repository of problem tickets, change requests, and other IT entities that allow access, search, and management of these entities. With the use of IBM Tivoli Business Systems Manager to manage the business system entities from the IT perspective, it makes perfect sense to have the IT entities stored in the Peregrine Service Center to be available to be integrated to IBM Tivoli Business Systems Manager. The integration in this sense is a two-way process; it allows IBM Tivoli Business Systems Manager to access and search the Peregrine Service Center repository and also lets new problem tickets to be created into the Peregrine Service Center application. The integration allows the problem ticket created from IBM Tivoli Business Systems Manager to be managed extensively using Peregrine Service Center and also IBM Tivoli Business Systems Manager has access to the wealth of collected information already in Peregrine Service Center. This section explains the following: 7.1.1, Peregrine Service Center architecture on page 200 7.1.2, Service Center and IBM Tivoli Business Systems Manager on page 201 7.1.3, Terms and definitions on page 204
7.1.1 Peregrine Service Center architecture

Peregrine Service Center can be viewed as a multi-tiered application. The architecture is shown in Figure 7-1.
Repository
Service Center Server
` Service Center Client
Figure 7-1 Peregrine Service Center overview
200
Service Center server provides access to the repository. It performs authentication for user. It also processes the business logic or workflow of the application. The repository can be relational database system or sequential file. Production systems should consider a relational database systems, for performance, reliability and recovery. The Service Center Client is a Eclipse-based Java graphical user interface (GUI).
7.1.2 Service Center and IBM Tivoli Business Systems Manager

With regard to the integration with IBM Tivoli Business Systems Manager, the integration function is performed using a separate installable feature called IBM Tivoli Business Systems Manager. The IBM Tivoli Business Systems Manager uses IBM Tivoli Business Systems Manager problem management interface exit to perform Service Center requests to the Service Center server. IBM Tivoli Business Systems Manager allows IBM Tivoli Business Systems Manager console users to access Service Centers incident management application. IBM Tivoli Business Systems Manager allows users to perform the following problem ticket management tasks: Manual problem ticketing, problem tickets can be opened, updated or closed in Service Center from a IBM Tivoli Business Systems Manager console. Automatic problem ticketing, this allows automatically opening problem tickets in ServiceCenter based on an events and also provides automatic close event notification to remove the ownership icon from an IBM Tivoli Business Systems Manager object when all related incidents are closed in ServiceCenter. IBM Tivoli Business Systems Manager does not require a ServiceCenter client. It interacts directly to the Service Center server as shown in Figure 7-2 on page 202.
Chapter 7. Problem management integration with the Peregrine Service Center
201
Repository
` Service Center Client
TBSM problem management API
Figure 7-2 SCAuto for TBSM overview
More detail on the interaction is shown in Figure 7-3.
process.out
SCAuto for TBSM

stored procedure
SCAuto module
SYSTEM_CONFIGURATION table
process.in
Object database
` TBSM Console
Figure 7-3 Detailed SCAuto for TBSM interaction
As shown in Figure 7-3, the problem management exit processing can be explained as follows: 1. A problem management request is initiated. This can be from the following:
202
A problem management dialog from IBM Tivoli Business Systems Manager console Automated action that is invoked as a result of a certain event Timed processing to search for closed problem ticket in Service Center so that its related event in IBM Tivoli Business Systems Manager can be closed 2. IBM Tivoli Business Systems Manager generates an input file for the problem management exit. A sample input file is shown in Example 7-1.
Example 7-1 Sample input file REQUEST_TYPE|1|1|REQUEST_PROBLEM REQUEST_METHOD|1|1|REQUEST_ENUM REQUEST_CONSOLE_VERSION|1|1|NOT_V15 REQUEST_OBJECT_CID|1|1|NREG REQUEST_OBJECT_ID|1|1|12 REQUEST_OBJECT_SOURCE_CID|1|1|NREG REQUEST_OBJECT_SOURCE_ID|1|1|12 REQUEST_ENUM_NAME|1|1|REQUEST_PROBLEM_TYPE REQUEST_OBJECT_NAME|1|1|aus REQUEST_LOGIN_USER_ID|1|1|Administrator REQUEST_LOGIN_USER_PASSWORD|1|1| REQUEST_CUSTOMER_ID|1|1|TBSM AUTO_CLOSE_DEFAULT|1|1|YES DEBUG_MODE|1|1|ON DISPLAY_PROBLEM_CLOSURE|1|1|NO TIMEOUT_VALUE|1|1|300 TICKET_CREATE_DEFAULT|1|1|NO REQUEST_USER_ID|1|1| REQUEST_PASSWORD|1|1|
3. The exit based on the SystemConfiguration table invokes the appropriate module from SCAuto for TBSM to parse the input file and send the request to ServiceCenter server. 4. ServiceCenter processes the request to perform the appropriate problem management action and sends the result to SCAuto for TBSM module. The processing is stored in the log file <TBSM>\Data\*.log; there are AutoTicket.log and ProblemTicket.log files that can help in debugging problems. 5. SCAuto for TBSM writes the result to an output file and invoke IBM Tivoli Business Systems Manager problem management exit to indicate it has finished processing. A sample output file is shown in Example 7-2 on page 204.
203
Example 7-2 Sample output file REQUEST_RETURN_CODE|1|1|0 REQUEST_ERROR_MSG|1|1|Enumeration request was successful. REQUEST_ENUM_VALUE|1|1|business applications REQUEST_ENUM_VALUE|1|1|client system REQUEST_ENUM_VALUE|1|1|enquiry REQUEST_ENUM_VALUE|1|1|example REQUEST_ENUM_VALUE|1|1|network REQUEST_ENUM_VALUE|1|1|other REQUEST_ENUM_VALUE|1|1|printing REQUEST_ENUM_VALUE|1|1|security REQUEST_ENUM_VALUE|1|1|shared infrastructure REQUEST_ENUM_VALUE|1|1|tbd REQUEST_ENUM_VALUE|1|1|telecoms
6. IBM Tivoli Business Systems Manager reads the output file and return the status back to the original caller. For a console request, it displays the results in the IBM Tivoli Business Systems Manager console.
7.1.3 Terms and definitions

This section shows some comparisons of IBM Tivoli Business Systems Manager terms and Peregrine Service Center. This is to ensure that you understand the necessary differences. It is meant to help both IBM Tivoli Business Systems Manager personnel to use Peregrine Service Center manuals; or for Peregrine Service Center personnel to use IBM Tivoli Business Systems Manager manuals. Table 7-1 lists terms differences in Peregrine Service Center and IBM Tivoli Business Systems Manager.
Table 7-1 Vocabulary differences IBM Tivoli Business Systems Manager Problem ticket Severity Problem type Assignee group Status code Short description Peregrine Service Center Incident Priority Category Assignment Status Brief description
204
Furthermore, the following are the terms that we will use to describe the interface: Automated Ticketing The process by which events in the IBM Tivoli Business Systems Manager console automatically trigger the creation of Problem Tickets in IBM Tivoli Business Systems Manager and incidents in ServiceCenter Auto Ticket Request Processor IBM Tivoli Business Systems Manager application that processes incoming Auto Tickets and starts the appropriate ServiceCenter incident event Problem Ticket Request Processor IBM Tivoli Business Systems Manager application that processes incoming IBM Tivoli Business Systems Manager Problem Tickets and starts the appropriate ServiceCenter incident event Automated Close Event Notification IBM Tivoli Business Systems Manager application that creates a command line call to IBM Tivoli Business Systems Managers Problem Integration Event Notification application
7.2 Implementing SCAuto for TBSM

This section discusses the procedure to implement SCAuto for TBSM. We will not discuss the installation or configuration of Peregrine Service Center. We assume that Peregrine Service Center server is already installed and configured properly. The implementation sections are follows: 1. Review 7.2.1, Installation requirements on page 206 2. Run the Peregrine SCAuto for TBSM installer on the IBM Tivoli Business Systems Manager database server in 7.2.2, Running the SCAuto for TBSM installer on page 206. 3. Modify Peregrine Service Center to support SCAuto for TBSM: a. Add five new fields to the Peregrine Service Center problem summary dictionary in 7.2.3, Adding new fields to the database dictionary on page 209. b. Load the RAD application, event maps, and event registrations, and formats into Peregrine Service Center in 7.2.4, Loading files into Peregrine Service Center on page 216.
205
c. Add a format control to Peregrine Service Center to communicate with the automatic close event notification service. See 7.2.5, Adding a format control for automatic close events on page 218. 4. Configure the IBM Tivoli Business Systems Manager for the problem management exit with SCAuto for TBSM: a. Update the SCAuto for TBSM mapping files if you have customized the fields used by Peregrine Service Center Incident Management. See 7.2.6, Updating IBM Tivoli Business Systems Manager mappings on page 222 b. Customize problem management tables in 7.2.7, Configuring database server for SCAuto for TBSM on page 227. c. Configure the user names and passwords for SCAuto for TBSM to access Peregrine Service Center in 7.2.8, Configuring access to problem ticketing on page 228. 5. Start the automatic close event notification service. See 7.2.9, Starting the automatic close event notification service on page 229
7.2.1 Installation requirements

You must have the following to install SCAuto for TBSM: IBM Tivoli Business Systems Manager already installed and running Peregrine Service Center server already installed and running Administration access to IBM Tivoli Business Systems Manager V3.1 database server and Peregrine Service Center V6.0 server. SCAuto for TBSM license and installation CD-ROM. Before actually installing and configuring the interface, it is highly recommended that you perform a backup of: Peregrine Service Center data and database dictionary IBM Tivoli Business Systems Manager databases As the communication mechanism between SCAuto for TBSM to Peregrine Service Center is using TCP/IP. You need to have the host name and communications port for Peregrine Service Center server. The default port number is 12690.
7.2.2 Running the SCAuto for TBSM installer

The SCAuto for TBSM installer copies all the necessary files to the system running the IBM Tivoli Business Systems Manager database server. To run the SCAuto for TBSM installer:
206
1. Login to the Windows system running the IBM Tivoli Business Systems Manager database server as Administrator and run setup.exe from SCAuto for TBSM installation CD-ROM. The SCAuto for TBSM setup wizard is shown in Figure 7-4.
Figure 7-4 SCAuto for TBSM setup wizard
2. Click Next to read and accept the licensing agreement as shown in Figure 7-5.
Figure 7-5 License agreement
207
3. Select the I accept the terms in the License Agreement option and click Next to select the IBM Tivoli Business Systems Manager directory as shown in Figure 7-6. The wizard uses C:\TivoliManager as the default directory, while the default path for IBM Tivoli Business Systems Manager V3.1 is C:\Program Files\Tivoli\TBSM. Our path is C:\TBSM.
Figure 7-6 IBM Tivoli Business Systems Manager directory
4. Click Next to choose the SCAuto for TBSM installation location as shown in Figure 7-7. It must be installed under the IBM Tivoli Business Systems Manager installation directory under Data\Peregrine path.
Figure 7-7 Destination location
208
5. Click Next to type the Peregrine Service Center server address and port number as shown in Figure 7-8.
Figure 7-8 Peregrine Service Center server information
6. Click Next and then confirm installation by clicking Install. When the installer is completed, click Finish to exit the installation wizard.
7.2.3 Adding new fields to the database dictionary

SCAuto for TBSM requires five new fields to be added to the ServiceCenter problem summary database dictionary. These fields allow proper identification of Peregrine Service Center incidents created from SCAuto for TBSM. They also uniquely identify that the incidents originate from IBM Tivoli Business Systems Manager. Follow the next steps to change the Peregrine Service Center database dictionary for IBM Tivoli Business Systems Manager: 1. Run the Peregrine Service Center client, select Start Programs ServiceCenter Client. The default user ID is falcon with a blank password. The main menu is shown in Figure 7-9 on page 210.
209
Figure 7-9 ServiceCenter main menu
2. Issue dbdict in top toolbar command line of Peregrine Service Center client as shown in Figure 7-10.
Figure 7-10 ServiceCenter main menu
You need to enter probsummary in the File Name field as shown in Figure 7-11 on page 211.
210
Figure 7-11 ServiceCenter - (Dbdict) example
You are presented with the list of data dictionary for problem summary as shown in Figure 7-12 on page 212.
211
Figure 7-12 Data dictionary for problem summary
3. Click New and you get the field.window dialog shown in Figure 7-13 on page 213. Create the following new character fields: tbsm.system tbsm.component tbsm.item tbsm.module tbsm.scauto
Click the plus sign to Add each fields.
212
Figure 7-13 The field.window screen
Important: Database dictionary entries are case-sensitive. The field names must be in lower case. 4. In the Keys tab, scroll down to the first available key entry. As shown in Figure 7-14 on page 214.
213
Figure 7-14 First available key example
5. Click on the empty key field and then click New. The key.window dialog opens. From the Type field, select nulls & duplicates as shown in Figure 7-15 on page 215.
214
Figure 7-15 The key.window dialog
In the Fields array, and add the five entries that you created earlier: tbsm.system tbsm.component tbsm.item tbsm.module tbsm.scauto
Click the plus sign to add the new key to get back to the main dictionary list and click OK. We are using the default file database, not a relational database system. A different flow happens if you are using a RDBMS. 6. The Confirm Action window opens as shown in Figure 7-16 on page 216.
215
Figure 7-16 Confirm Action dialog
Select Regen all Indexes option and click OK. Peregrine Service Center regenerates the probsummary indexes.
7.2.4 Loading files into Peregrine Service Center

The SCAuto for TBSM installation CD includes a Peregrine Service Center unload file that contains all the RAD application, event maps, event registrations, and formats needed to integrate SCAuto for TBSM with Peregrine Service Center incident management. Follow the next steps to load the SCAuto for TBSM unload file into Peregrine Service Center: 1. Run the db command from the toolbar command line of Peregrine Service Center client. The Database Manager forms screen opens as shown in Figure 7-17 on page 217.
216
Figure 7-17 The format.prompt.db.g screen
2. Click down arrow on tool bar on upper right part of the screen. This will bring a pull-down menu. Click on Import/Load. As shown in Figure 7-18.
Figure 7-18 pull-down menu example
The Service Center File Load/Import screen opens as shown in Figure 7-19 on page 218.
217
Figure 7-19 The database load prompt screen
3. In the File Name field, type or browse to the scauto.tbsm.unl file in the SCUnloads subfolder of your SCAuto for TBSM installation. In our setup, it is stored in C:\TBSM\Data\Peregrine\SCUnloads\scauto.tbsm.unl. You can view the content of the unload file using the List Contents button. Note: Now is the time to verify any conflict that you may have to an existing customization you have perform on Peregrine Service Center. Ours is a new installation without any customization, therefore we have no conflict. 4. Click Load FG to load the file in foreground. Peregrine Service Center loads the file into the Peregrine Service Center system. You will get a message:
C:\TBSM\Data\Peregrine\scauto.tbsm.unl loaded.
7.2.5 Adding a format control for automatic close events

In order for IBM Tivoli Business Systems Manager to know that users have closed Trouble Tickets in Peregrine Service Center, you must add a format control subroutine to the problem template close form. Use the following steps to add a format control for Peregrine Service Center problem ticket close events: 1. Run the fc command from the toolbar command line. The format control maintenance opens as shown in Figure 7-20 on page 219.
218
Figure 7-20 The format control maintenance screen
2. In the name field, fill in problem.template.close and click Search. The Format Control screen opens as shown in Figure 7-21 on page 220.
219
Figure 7-21 The format control query screen
3. Click Subroutines, the format control subroutines screen opens as shown in Figure 7-22 on page 221.
220
Figure 7-22 The format control subroutines screen
4. Click the down arrow in the right most part of the toolbar. Select Show Expanded Form. Scroll down to the first blank subroutine. Build the new subroutine similar to Figure 7-23.
Figure 7-23 New subroutine
221
5. Click Save. Peregrine Service Center displays the message:

Format Control record updated.
7.2.6 Updating IBM Tivoli Business Systems Manager mappings

SCAuto for TBSM uses a set of mapping files and events to describe what Peregrine Service Center fields map to particular IBM Tivoli Business Systems Manager fields. You can use the default mapping files and events installed during setup if you are using an unmodified installation of Peregrine Service Center Incident Management. You only need to change the mappings if: You add custom fields to your Peregrine Service Center Incident Management installation that you want to appear in the IBM Tivoli Business Systems Manager console You want to change the Peregrine Service Center field information that displays for a particular IBM Tivoli Business Systems Manager console field You want to add a new IBM Tivoli Business Systems Manager field that maps to a Peregrine Service Center field in the IBM Tivoli Business Systems Manager console There are two sets of mapping files. One set for mapping events and fields going into Peregrine Service Center and another set of mapping files for mapping events and fields coming out from Peregrine Service Center and going to the IBM Tivoli Business Systems Manager console.
Map files to Peregrine Service Center

The map files in Table 7-2 reside in the \Data\Peregrine\EventMap\ToSC folder of your IBM Tivoli Business Systems Manager installation. These files determine what IBM Tivoli Business Systems Manager fields correspond to Peregrine Service Center fields names.
Table 7-2 Map files in ToSC folder Map File Description Mapping the counting the number of open tickets on IBM Tivoli Business Systems Manager items. Mapping for finding a specific problem ticket in ServiceCenter for the IBM Tivoli Business Systems Manager object. Mapping for closing a problem ticket in ServiceCenter for the requested IBM Tivoli Business Systems Manager object. Mapping for opening a problem ticket in ServiceCenter for the requested IBM Tivoli Business Systems Manager object.
TBSMcount.map TBSMfind.map TBSMpmc.map TBSMpmo.map
222
Map File
Description Mapping for updating a problem ticket in ServiceCenter for the requested IBM Tivoli Business Systems Manager object. Mapping for querying ServiceCenter for all open problem tickets associated with a requested IBM Tivoli Business Systems Manager object. Mapping for querying all ServiceCenter problem tickets that match a particular search criteria for a requested IBM Tivoli Business Systems Manager object.
TBSMpmu.map TBSMquery.map
TBSMreqadhoc.map
The first line in the map file determines whether IBM Tivoli Business Systems Manager creates a query string or event field.
Map files from Peregrine Service Center

The map files in Table 7-3 reside in the \Data\Peregrine\EventMap\FromSC folder of your IBM Tivoli Business Systems Manager installation. These files only need to be updated if you want to change what fields displayed in the IBM Tivoli Business Systems Manager console.
Table 7-3 Map files in FromSC folder Map File Description Mapping for querying a problem ticket in ServiceCenter with a requested IBM Tivoli Business Systems Manager object. Mapping for creating a IBM Tivoli Business Systems Manager output file for a found problem ticket. Mapping for creating a IBM Tivoli Business Systems Manager output file for a closed problem ticket. Mapping for creating a IBM Tivoli Business Systems Manager output file for an opened problem ticket. Mapping for creating a IBM Tivoli Business Systems Manager output file for an updated problem ticket. Mapping for creating a IBM Tivoli Business Systems Manager output file for all open problem tickets for a requested IBM Tivoli Business Systems Manager object. Mapping for creating a IBM Tivoli Business Systems Manager output file for all problem tickets that match a particular search criteria for a requested IBM Tivoli Business Systems Manager object.
TBSMevnotify.map TBSMfind.map TBSMpmc.map TBSMpmo.map TBSMpmu.map TBSMquery.map
TBSMreqadhoc.map
223
The FromSC mapping files use the following formatting conventions Comments are indicated with a pound sign # at the start of the line Any text that you enclose between double quotation marks is treated as a literal string You can use the plus sign to concatenate two fields or literal strings. For example:
$field1+$field2 $field1+literal string1
You can use the colon as an OR statement. To select data from more than one field, enclose the field names in parenthesis and use colons as a separator. For example, the value:
($REQUEST_SEVERITY:$REQUEST_EVENT_PRIORITY)
It selects data from the REQUEST_SEVERITY field or, if that field empty or null, from the REQUEST_EVENT_PRIORITY field.
Event maps in Peregrine Service Center

IBM Tivoli Business Systems Manager includes 86 event maps to open, update, close, and query for incidents. To view all the IBM Tivoli Business Systems Manager event maps: 1. Run the eventmap command from the toolbar command line of Peregrine Service Center client. The Event Map screen opens as shown in Figure 7-24 on page 225.
224
Figure 7-24 The event map screen
2. In the Map Name field type tbsm and click Search. The list of event map for tbsm event maps as shown in Table 7-25 on page 226.
225
Figure 7-25 The event map list screen
Modifying IBM Tivoli Business Systems Manager mappings

You can make the following changes to IBM Tivoli Business Systems Manager mapping files: Display data from custom ServiceCenter fields in the IBM Tivoli Business Systems Manager console. Change what ServiceCenter field that maps to a IBM Tivoli Business Systems Manager field. Add a new IBM Tivoli Business Systems Manager field that maps to a ServiceCenter field.
226
Attention: Making changes to map files and ServiceCenter event maps may result in mapping errors and a loss of functionality. It is strongly recommended that you consult Peregrine support for assistance when changing map files and event maps. We do not make any changes to the default mapping tables.
7.2.7 Configuring database server for SCAuto for TBSM

SCAuto for TBSM requires the following changes to the IBM Tivoli Business Systems Manager Database Server: Activating a program user exit for problem ticketing that runs the SCAuto for TBSM application ProblemTicket.exe. Activating a program user exit for automatic ticketing that runs the SCAuto for TBSM application ProblemTicket.exe. Enabling caching (enumeration) on the IBM Tivoli Business Systems Manager Database Server to save valid field values for the problem ticketing form Setting the timeout value for IBM Tivoli Business Systems Manager to complete its tasks within 300 seconds before returning an error message Enabling the automatic closing of incidents in Peregrine Service Center when a problem ticket is closed from IBM Tivoli Business Systems Manager Defining the status value Closed as the ticket status that identifies closed problem tickets The changes can be installed using the SQL commands from the file in <TBSM>\Data\Peregrine\SQLFiles\instql.txt. You can either run this using the isql command as follows:
isql /U sa /P <sa_password> /i instql.txt
Or, by running the file using SQL Query Analyzer. The instql.txt modifies the SystemConfiguration table. The changes that it makes are shown in Table 7-4 on page 228.
227
Table 7-4 Group and property information Group name REQUEST_ AUTOTICKET REQUEST_ PROBLEM API_ INTEGRATION_ OPTIONS Property name REQUEST_ PROCESSOR_ NAME REQUEST_ PROCESSOR_ NAME TABLE_BASED_ ENUMERATIONS Property value <dir>\AutoTicket.exe Data type CHAR Comments Request processor executable from SCAuto for TBSM
<dir>\ProblemTicket.exe
CHAR
YES
CHAR
Enable caching of problem ticketing field values, remove the need to ask problem management system for every requests Setting Timeout value Synchronization of closed problem from IBM Tivoli Business Systems Manager Peregrine Service Center closed status
API_ INTEGRATION_ OPTIONS API_ INTEGRATION_ OPTIONS
TIMEOUT_ VALUE AUTO_CLOSE_ DEFAULT
300
CHAR
YES
CHAR
API_ INTEGRATION_ OPTIONS
CLOSE_TICKET_ STATUS_CODE
Closed
CHAR
7.2.8 Configuring access to problem ticketing

The IBM Tivoli Business Systems Manager console requires a user name and password to access the problem ticketing request processor. IBM Tivoli Business Systems Manager provides a default user name and password that you can use to access problem ticketing or you can manually define your own list of user names and passwords. IBM Tivoli Business Systems Manager displays the problem ticketing user name in all problem tickets created from IBM Tivoli Business Systems Manager. If you want your TBSMproblem tickets to display a different user name than the default name, you can define a custom list of user names and passwords.
228
By default, IBM Tivoli Business Systems Manager uses the SCAutoTBSM user to access problem ticketing with the default password of password. This information is stored on the IBM Tivoli Business Systems Manager Database Server in the file scusers.ini. This file is a plain-text file with no encryption that only controls access to the IBM Tivoli Business Systems Manager problem ticketing applications. It does not list or require any ServiceCenter operator names or passwords. Custom problem ticketing user names and passwords can be created by editing the scusers.ini file. The user entries are added in the format of:
<user name>=<password>
7.2.9 Starting the automatic close event notification service

The automatic close event notification service periodically queries ServiceCenter for closed incidents. You must start this service for automatic problem ticketing to function properly. To start the automatic close event notification service: 1. Login to the Windows system running the IBM Tivoli Business Systems Manager database server as a user with local administrator privileges. 2. Open the Windows Control panel. 3. Open the Services application. 4. Select the SCAuto for TBSM Event Notification Service 5. Click Start. Tip: You can set this service to automatic startup if you want it to start every time Windows starts.
7.3 Removing SCAuto for TBSM

Completely removing IBM Tivoli Business Systems Manager from system requires the following basic steps: 1. Restore the ServiceCenter server from a backup to remove the contents of the scauto.tbsm.unl file. See the ServiceCenter documentation for information about restoring from a backup. 2. Remove the SCAuto for TBSM entries from the IBM Tivoli Business Systems Manager Database Server. You can remove the changes made to the IBM Tivoli Business Systems Manager database server by running SQL commands in <TBSM>\Data\Peregrine\SQLFiles\uninstql.txt using isql command, or from SQL Query Analyzer. You can also remove the entries added from Table 7-4 on page 228 manually from SystemConfiguration table.
229
3. Remove the SCAuto for TBSM software using Windows Add/Remove programs.
7.4 Using Problem Ticketing

This section contains user and troubleshooting information. Contents include: 7.4.1, Problem ticketing on page 230 7.4.2, Automatic ticketing on page 242
7.4.1 Problem ticketing

The IBM Tivoli Business Systems Manager problem ticketing interface allows you to perform Incident Management tasks from the IBM Tivoli Business Systems Manager console: Creating problem tickets on page 230 Updating problem tickets on page 233 Closing problem tickets on page 237
Creating problem tickets

You can manually create problem tickets from the IBM Tivoli Business Systems Manager console. SCAuto for TBSM automatically creates a corresponding ServiceCenter incident based on your problem ticket. 1. Login to the IBM Tivoli Business Systems Manager console and select the IBM Tivoli Business Systems Manager object that you want to create a problem ticket for. Important: Use an object from All Resources tree. A problem ticket cannot be created form a business system resource or folder. 2. Right-click the object and then click Problem Tickets Create. The create Problem Tickets screen opens as shown in Figure 7-26 on page 231.
230
Figure 7-26 Create Problem Ticket screen
3. If you have not save your password, perform the following sub-steps: a. Click Problem System Password. The Problem System Access Information window opens as shown in Figure 7-27.
Figure 7-27 Problem system Access Information screen
b. Type the user name and password you defined in the scusers.ini file.
231
c. Select the Save this information option. This option prevents you from having to type in user name and password every time you want to use problem ticketing. d. Click OK. SCAuto for TBSM uses this user name and password information whenever you access problem ticketing. 4. Type in the problem ticket details as shown in Figure 7-28.
Figure 7-28 Updated Create Problem Ticket information screen
5. Click OK. IBM Tivoli Business Systems Manager creates the problem ticket and displays a confirmation window as shown in Figure 7-29 on page 233, unless you check the Do not display this message in the future.
232
Figure 7-29 Problem ticket successfully created screen
6. Click OK.
Updating problem tickets

You can manually update problem tickets from the IBM Tivoli Business Systems Manager console and IBM Tivoli Business Systems Manager automatically updates the corresponding ServiceCenter incident. 1. Find the open problem ticket. Right-click the IBM Tivoli Business Systems Manager object, and then click Problem Tickets Find. IBM Tivoli Business Systems Manager queries ServiceCenter and displays a list of incidents that match your search criteria. The Find Problem Tickets screen opens displaying a list of all ServiceCenter incidents associated with the current IBM Tivoli Business Systems Manager object. See Figure 7-30 on page 234.
233
Figure 7-30 List of problem tickets
2. From the Results screen in Figure 7-30, double-click the problem ticket that you want to update. The Note Properties screen opens as shown in Figure 7-31 on page 235.
234
Figure 7-31 Note properties screen
3. Click Show. The Problem Ticket Properties screen opens. as shown in Figure 7-32 on page 236.
235
Figure 7-32 Problem Ticket Properties screen
4. Type the problem ticket updates. Click Add to add additional comments. The Edit Text Log screen opens as shown in Figure 7-33 on page 237.
236
Figure 7-33 Edit Text Log screen
5. Click OK. 6. IBM Tivoli Business Systems Manager updates the problem ticket information and displays a confirmation window as shown in Figure 7-34, unless you check the Do not display this message in the future. Click OK to close the confirmation window.
Figure 7-34 Ticket update successful screen
Closing problem tickets

You can manually create problem tickets from the IBM Tivoli Business Systems Manager console and IBM Tivoli Business Systems Manager automatically closes the corresponding ServiceCenter incident as well as removes the problem note icon from the IBM Tivoli Business Systems Manager object node if there are no more outstanding problem tickets for the object. To close a problem ticket:
237
1. Find the problem ticket that you want to close similar to the procedure in Updating problem tickets on page 233. 2. From the Results screen, double-click the problem ticket that you want to close. The Problem Ticket Properties screen opens. As shown in Figure 7-35.
3. From the Status Code field, select Close. The Edit Text Log screen opens as shown in Figure 7-36 on page 239. This requested you to enter the closing information.
238
Figure 7-36 Edit Text Log screen
Update Description and click OK. The Problem Ticket Properties screen opens. As shown in Figure 7-37 on page 240.
239
4. Change Status code to Closed. As shown in Figure 7-38 on page 241.
240
Note: The actual label used for closed tickets is defined in the IBM Tivoli Business Systems Manager Database Server. See 7.2.7, Configuring database server for SCAuto for TBSM on page 227 for instructions on changing the closed status label. 5. Click OK. IBM Tivoli Business Systems Manager closes the problem ticket and displays a confirmation window. As shown in Figure 7-39 on page 242.
241
Figure 7-39 Successful ticket update screen
6. Click OK to close the confirmation window. If all problem tickets for the IBM Tivoli Business Systems Manager object have been closed, IBM Tivoli Business Systems Manager removes the problem note icon from the object.
7.4.2 Automatic ticketing

Automatic ticketing does not require any manual intervention from the IBM Tivoli Business Systems Manager console. IBM Tivoli Business Systems Manager creates problem ticket automatically based on event rules defined in the IBM Tivoli Business Systems Manager Database Server and a request processor definition for IBM Tivoli Business Systems Manager. IBM Tivoli Business Systems Manager automatically configures the request processor definition when you run the isql command described in 7.2.7, Configuring database server for SCAuto for TBSM on page 227. To define the IBM Tivoli Business Systems Manager event rules, you must configure your IBM Tivoli Business Systems Manager Database Server. See the IBM Tivoli Business Systems Manager Administrators Guide, SC32-9085 for instructions on defining event rules.
7.5 Troubleshooting
This section contains some common issues and work-arounds for SCAuto for TBSM. For the most up to date troubleshooting information, see the Peregrine Customer Support Web Site and search the knowledge base. Changing the automatic close event polling interval to match the expected number of closed tickets. This interval is defined in <TBSM>\Data\Peregrine\SCTBSMEvNotify.ini.
242
You can update or add the line:

ev_notify_interval:<seconds>
Changing the automatic close event process time limit to optimize event closing throughput. This limit is defined in <TBSM>\Data\Peregrine\SCTBSMEvNotify.ini. You can update or add the line:
max_processtime:<seconds>
Changing the SCAuto for TBSM host or port values after installation. This configuration value is stored in: SCTBSMAuto.ini - configuration file for Automatic Problem Ticketing SCTBSMProb.ini - configuration file for Manual Problem Ticketing SCTBSMEvNotify.ini - configuration file for Automatic Ticket closure You need to change the server: and port: keywords in those files. Enabling debugging features. This shows the detailed information in log files and shows also Peregrine Service Center events. Edit the appropriate configuration files to add debugging parameters: SCTBSMAuto.ini - configuration file for Automatic Problem Ticketing SCTBSMProb.ini - configuration file for Manual Problem Ticketing SCTBSMEvNotify.ini - configuration file for Automatic Ticket closure You configuration lines to change or add are: Logging level: debug:<log_level>, where is 0,1, 2, or 3. Level 3 is the most verbose log level that contains all available errors, warnings, and information. Level 0 turns off debugging. Event deletion: delete_events:0. This prevents events from being deleted in eventout queue. Important: You can only set this configuration setting for the SCTBSMAuto.ini and SCTBSMProb.ini configuration files. Setting query time out value. Query time out can result from network latency or from high CPU usage on the server running ServiceCenter. If you see this error outside of these conditions, you may want to increase the time-out values and number of retry attempts for your IBM Tivoli Business Systems Manager queries. You can change these values from the IBM Tivoli Business Systems Manager configuration files: SCTBSMAuto.ini - configuration file for Automatic Problem Ticketing SCTBSMProb.ini - configuration file for Manual Problem Ticketing SCTBSMEvNotify.ini - configuration file for Automatic Ticket closure
243
You configuration lines to change or add are:

retry_interval:<seconds> query_numofretry:<attempts>
244
Appendix A.
Additional material
This redbook refers to additional material that can be downloaded from the Internet as described below.
Locating the Web material

The Web material associated with this redbook is available in softcopy on the Internet from the IBM Redbooks Web server. Point your Web browser to:
ftp://www.redbooks.ibm.com/redbooks/SG246770
Alternatively, you can go to the IBM Redbooks Web site at:

ibm.com/redbooks
Select the Additional materials and open the directory that corresponds with the redbook form number, SG246770.
Using the Web material

The additional Web material that accompanies this redbook is stored in the SG246770.zip file. This zip file contains the following files:
245
File name TIA507_TBSM.ear
TIA507_ABS.txt ABS.jar TIO.jar TIO-aux.jar
Description Enterprise archive collected with source code that can be imported into WebSphere Studio Application Development. Complete ABS file for PiggyBank, Inc. Jar file for Java based ABS file generator. Jar file for TIO automation program that generates XML file Collection of other Java classes that are needed to run enqueueCL command.
System requirements for downloading the Web material

For the WebSphere application archive, you need the following software: WebSphere Studio Application Development Integration Edition V5.1.1 WebSphere Application Server V5.0.2.6 For the IBM Tivoli Business Systems Manager automated business system sample, the following software is needed: IBM Tivoli Business Systems Manager V3.1 with Interim Fix 1, 2 and 6 For the Java-based Automated Business Systems application, the following system configuration is recommended: Java Runtime Environment v1.4 or later For the IBM Tivoli Intelligent Orchestrator automation workflow, you need: IBM Tivoli Intelligent Orchestrator V3.1 XML toolkit from IBM Tivoli Business Systems Manager 3.1
Loading application into WebSphere Studio Application Development Integration Edition V5.1.1
Open WebSphere Studio Application Development Integration Edition V5.1.1 into a new Workspace. Select File Import and select import an EAR file. Import TIA507.ear. This will open a new workspace as shown in Figure A-1 on page 247.
246
Figure A-1 WSADIE V5.1.1 workspace
Using the ABS Java application

Invoke the JAR file directly from a Windows platform or invoke it using the command java -jar ABS.jar. This brings up the main workspace shown in Figure A-2 on page 248.
Appendix A. Additional material
247
Figure A-2 ABS workspace
From the root object, you can create Business System folders. Right-click and select Add Folder as shown in Figure A-3.
Figure A-3 Adding folders
The Business System folder property dialog is shown in Figure A-4 on page 249.
248
Figure A-4 Business system folder property
You can enable or disable individual property and put in the appropriate values. After the new folder is created, you can add resource definition; right-click and select Add Resource as shown in Figure A-5.
Figure A-5 Adding resource
The resource property page is displayed, you need to add resource selection condition by clicking Add. The add condition dialog is shown in Figure A-6 on page 250.
249
Figure A-6 Adding condition
The resource selection property is shown in Figure A-7.
Figure A-7 Resource selection property
Adding functions will be indicated in the icon in the workspace and additional property will be shown in the property page. Figure A-8 on page 251 shows a folder property with sections enabled.
250
Figure A-8 Function properties
The icon in the workspace is modified to indicate the functions that are used; see Figure A-9 on page 252.
251
Figure A-9 Functions for folders
You can save the business system structure using the menu File Save for modification later. Saved business system structures can be reused using File Open menu. When you are ready to generate the ABS file, use the menu File Generate.
252
Abbreviations and acronyms

ITM ABS APDE APF API APM ATS CCTA CD CD-ROM CL CLI CPU DCM EAR EE EIF EJB ETL GUI HTML HTTP IBM IIOP IP ITIL Compact Disk Compact Disk - Read Only Memory Common Listener Command Line Interface Central Processing Unit Data Center Model Enterprise Archive Event Enablement Event Integration Facility Enterprise Java Bean Extract Transform Load Graphical User Interface Hyper Text Markup Language Hyper Text Transfer Protocol International Business Machines Corp. Internet Inter Object Protocol Internet Protocol Information Technology Infrastructure Library URL WSADIE TEC TEDW TME SOW SQL TCP/IP Automated Business Systems Automation Package Development Environment Authorized Programming Facility Application Programming Interface Application Process Monitoring Advanced Technical Support ITSO JAR JDBC JSC JVM LOB LOBC MSMT MVS PBT RDBMS SLA SLM SLO SNA SOAP IBM Tivoli Monitoring International Technical Support Organization Java Archive Java Data Base Connectivity Job Scheduling Console Java Virtual Machine Line Of Business Line Of Business Containment Measurement Multiple Virtual Storage Percentage Based Threshold Relational Database Management Systems Service Level Agreement Service Level Management Service Level Objective System Network Architecture Simple Object Access Protocol Statement Of Work Structured Query Language Transmission Control Protocol/Internet Protocol Tivoli Enterprise Console TivolI Enterprise Data Warehouse Tivoli Management Environment Uniform Resource Locator WebSphere Studio Application Development Integrated Edition
253
XML
eXtensible Markup Language
254
Related publications
The publications listed in this section are considered particularly suitable for a more detailed discussion of the topics covered in this redbook.
IBM Redbooks
For information on ordering these publications, see How to get IBM Redbooks on page 256. Note that some of the documents referenced here may be available in softcopy only. IBM Tivoli Business Systems Manager V2.1 End-to-end Business Impact Management, SG24-6610 Introducing IBM Tivoli Service Level Advisor, SG24-6611 Service Level Management Using IBM Tivoli Service Level Advisor and Tivoli Business Systems Manager, SG24-6464 End-to-End Scheduling with IBM Tivoli Workload Scheduler Version 8.2, SG24-6624 Integrating IBM Tivoli Workload Scheduler with Tivoli Products, SG24-6648
Other publications
These publications are also relevant as further information sources: IBM Tivoli Business Systems Manager Getting Started Guide, SC32-9088 IBM Tivoli Business Systems Manager Installation and Configuration Guide, SC32-9089 IBM Tivoli Business Systems Manager: Introducing the Consoles, SC32-9086 IBM Tivoli Business Systems Manager Administrators Guide, SC32-9085 IBM Tivoli Business Systems Manager Problem and Change Management Integration Guide, SC32-9130 IBM Tivoli Business Systems Manager Command Reference, SC32-1243 IBM Tivoli Business Systems Manager Message Reference, SC32-9087 IBM Tivoli Business Systems Manager Diagnosis Guide, SC32-9084 IBM Tivoli Business Systems Manager: Release Notes, GI11-4029
255
Online resources
These Web sites and URLs are also relevant as further information sources: Information about IT Infrastructure Library (ITIL)
http://www.ogc.gov.uk http://www.itsmf.com http://www.itil.co.uk
How to get IBM Redbooks

You can search for, view, or download Redbooks, Redpapers, Hints and Tips, draft publications and Additional materials, as well as order hardcopy Redbooks or CD-ROMs, at this Web site:
ibm.com/redbooks
Help from IBM

IBM Support and downloads
ibm.com/support
IBM Global Services

ibm.com/services
256
Index
Numerics
3.1.0.0-TIVBSM-IF0006 125 building business systems 37 Business Service Management 2, 4 business system 19, 22 building 37 business system folder 7, 38 business system resource 7, 38 business system shortcut 7, 38 business system tree 67 business-level representations 2 BusinessRole 66
A
ABS absAllowedClassAttribute.ksh command 47 absConfig.ksh command 35, 47, 5960 absTest.ksh command 35, 61 absTest.ksh commands 61 AdapterEnv.conf 127 addLinkInstances 75 addObjectInstances 73 Agent Manager 174 alert state 6 all resources tree 6 allocation decisions 171 APDE API API application 92 APM Application 168 Application Cluster 168 Application Controller 171 application management tools 2 Application Policy Manager, see APM Application Programming Interface, see API Auto Ticket Request Processor 205 Automated Business System, see ABS Automated Business Systems, see ABS Automated Close Event Notification 205 Automated Ticketing 205 automatic close events 218 Automation Package Development Environment, see APDE Automation Packages 166 AWS_c10_ETL_Process 159
C
calendar 118 CCTA Central Computing and Telecommunications Agency, see CCTA cid 5 CL class ID 5 class name 5 class number 5 CLI cname 5 cno 5 color-coded status 5 Command Line Interface, see CLI commands absAllowedClassAttribute.ksh 47 absConfig.ksh 35, 47, 5960 absTest.ksh 35, 61 backupLOBasXML 68 db2cc 132 DBServerEncryptor 125 DefineEVService.ksh 88 DefineServicesAndLinkToEVUsers.ksh 89 enqueuecl 36 enqueuecl.ksh 80 eventmap 224 gemdmmap.sh 28 gemgenprod.sh 28 gemimageimport.sh 28 ihstmtec 29 ihsttsla 29
B
backupLOBasXML command 68 batch management 115 bi-directional communication 67 BmEvents.conf 128
257
ihstttec 2930 ihstztec 29 isql 227, 229 java 247 LinkEVUsersToServices.ksh 89 ProblemTicket 227 querycltran 36 scmd 133 slmenv 133 tbsmtsla.sh 135 tecstatusconfig.ksh 30 tws_launch_archive.pl 131 tws_launch_archiver.pl 158 UnlinkEVServices.ksh 89 wtll 31 Common Listener, see CL console server 17 customer 120, 168
end user 19 end users 21 enqueuecl command 36 enqueuecl.ksh command 80 Enterprise Java Beans 167 ETL event analysis 1920 Event Enablement, see EE event handler server 17 event.log 128 eventmap command 224 executive dashboard 11, 85 executive view 85 eXtensible Markup Language, see XML Extract Transform Load, see ETL
F
field mapping 222 files 119 scauto.tbsm.unl. 218
D
Data Center Model 167, 171, 178 data dictionary 211 database 117 database server 17 DB_Server.conf 125 DB2 Warehouse 121 db2cc command 132 DBServerEncryptor command 125 DefineEVService.ksh command 88 DefineServicesAndLinkToEVUsers.ksh command 89 deleteObjectInstances 75 Deployment Engine 171 device driver 166 discussion scope 12 Distributed Monitoring 29 driver 166 DriverPlugIns.conf 126 DYK 122 DYK.MSMT 159 DYK_m05_Populate_Registration_Datamart_Proce ss 135 DYK_m10_Populate_Measurement_Datamart_Pro cess 159
G
gemdmmap.sh command 28 gemgenprod.sh command 28 gemimageimport.sh command 28 Global Resource Manager component 171 graphical user interface, see GUI GUI
H
Health Monitor server 17 high-level requirements 18 historical service-level 2 history server 17 host integration server 17
I
IBM Tivoli Business Systems Manager 1, 4 API 92 base components 9 business system 37 components 8 configuration 16 console 10 console server 9 executive dashboard 11, 85 implementation 16
E
EE EJB 167
258
interaction 8 interfaces 21 Java console 10 mainframe input components 9 mappings 222 methodology 16 objects 5 overview 5 problem management exit 203 reporting system 12 requirement gathering 18 resource discovery 29 resource placement 29 resources 5 servers 16 user interface 10 users 21 Web console 10 IBM Tivoli Enterprise Console 24 IBM Tivoli Intelligent Orchestrator 13 Data Center Model 178 resource pool 179 IBM Tivoli Monitoring 4 IBM Tivoli NetView 4 IBM Tivoli Service Level Advisor 29, 66, 115 IBM Tivoli Workload Scheduler 115 ihstmtec 29 ihstmtec command 29 ihsttsla 29 ihsttsla command 29 ihstttec 29 ihstttec command 2930 ihstztec 29 ihstztec command 29 implementation methodology 16 information-gathering task 170 instance 118 instance id 5 interfaces 19, 21 isql command 227, 229 IT Infrastructure Library 3 IT Infrastructure Library, see ITIL IT service management 3 ITIL 3 ITITO architecture 169
jar file 92 Java 2 Enterprise Edition 92 Java archive 92 java command 247 Javadoc 92 JNextDay 118 job 118 Job Scheduling Console, see JSC job stream 119 JSC
L
lab environment 13 link type 75 LinkEVUsersToServices.ksh command 89 localadapter.config 125 logical operation 167
M
management environment 19, 22 Management Interface component 171 mapping files 226 methodExecution 75 methodology 16 methods DefineAndUsePBTs 77 DefineEVService 76 DefinePBTs 77 DefineServicesandLinkToEVUsers 76 DeletePBTs 78 GetPBTs 78 GetPBTStatus 78 LinkEVUsersToServices 76 ResetThresholds 79 SetBSPriority 79 SetSendStateChangeEvent 79 SetThresholds 78 SetWeights 79 UnLinkEVServices 77 UsePBTs 78 Microsoft SQL Server 17 modifyObjectInstances 74 monitoring sources 1920
N J
J2EE 92 naming convention 1920
Index
259
O
object priority 6 object state 6 objects 5, 117 offering 120 Office of Government Commerce, see OGC OGC OMEGAMON 4 operational task 30 optimal allocation decisions 171 overall ITITO architecture 169
resources 5 run cycle 119 RunAs property 105 running workflow 191
S
sample application 92 SCAuto for TBSM 203 troubleshooting 230 scauto.tbsm.unl. 218 schedule 120 scheduling object calendar 118 files 119 job 118 job stream 119 parameter 119 prompt 119 resource 119 run cycle 119 user 119 workstation 118 scmd command 133 security role 102 server configuration 16, 1819 Servers definition 168 Service Center Client 201 Service Level Agreement, see SLA service level management customer 120 offering 120 realm 120 resource 120 schedule 120 service level objective 120 service level priority 168 service management 3 ServiceID 66 SLA 120 SLA-Trend-Cancel-Event 135 SLA-Trend-Event 135 SLA-Violation-Event 135 SLM report 163 SLM-Application-Event 135 slmenv command 133 SNA 17 SNA server 17 solution design 18
P
parameter 119 PBT Percentage Based Threshold, see PBT Peregrine Service Center 199 terms 204 physical resource 7, 38 plan 118 policy-driven batch management 115 priority 6 problem management exit 203 problem management mapping 222 Problem Ticket Request Processor 205 ProblemTicket command 227 production day 118 prompt 119 properties 107
Q
querycltran command 36
R
realm 120 real-time status 2 Redbooks Web site 256 Contact us xi RedImpact 66 repeatable workflows 171 reporting system 12 requirement gathering 18 resource 119120 resource discovery 29 resource placement 29 resource pool 168, 179 resource types 28
260
solution design session 23 Source/390. 17 SOW SQL Query Analyzer 227 stable application control 171 start of day 118 state 6 statement of work, see SOW Subagent Bundle Store 174 Svc_Offering table 88 symphony file 118 SystemConfiguration table 203
U
Universal Resource Locator, see URL UnlinkEVServices.ksh command 89 URL user 119 UserIDGroup 67
V
vwkernel 121
W
Warehouse Enablement Pack, see WEP Web console 10 WebSphere Application Server 17 WebSphere Studio Application Development 93 WebSphere Studio Application Development Integrated Edition, see WSADIE WebSphere variable 113 WEP Windows user 119 workflow 191 workflow definition 166 workload model 171 workload scheduler database 117 instance 118 objects 117 plan 118 production day 118 start of day 118 workstation 118 WSADIE wtll command 31
T
tables Svc_Offering 88 SystemConfiguration 203 Task Library 30 TBSM 1 TBSM_API 92 tbsmapi.jar 100 TBSMcount.map 222 TBSMevnotify.map 223 TBSMfind.map 222223 TBSMpmc.map 222223 TBSMpmo.map 222223 TBSMpmu.map 223 TBSMquery.map 223 TBSMreqadhoc.map 223 TBSMServlet 113 tbsmtsla.sh command 135 TC driver 166 tcdriver 166 TEC tecstatusconfig.ksh command 30 terms 204 test servers 17 Tivoli Common Agent 173 Tivoli Data Warehouse 120 Tivoli Enterprise Console, see TEC Transitions 167 TWG.MSMT 159 TWH_CDW 121 TWH_MART 121 TWH_MD 121 tws_launch_archive.pl command 131 tws_launch_archiver.pl command 158 TWSConf.conf 128
X
XML XML interface 68 XML toolkit 68, 184
Y
YellowImpact 66
Index
261
262
(0.5 spine) 0.475<->0.875 250 <-> 459 pages
Back cover
IBM Tivoli Business Systems Manager V3.1

Advanced Implementation Topics
Large-scale implementation discussion and experiences Advanced integration and implementation scenarios Extensive samples on business system building
This IBM Redbook discusses miscellaneous implementation topics and integration information for IBM Tivoli Business Systems Manager Version 3.1. The discussion is geared for an experienced IBM Tivoli Business Systems Manager specialist that requires an in-depth discussion for advanced implementation and integration options. This redbook does not provide basic implementation information for IBM Tivoli Business Systems Manager. That information can be found in IBM Tivoli Business Systems Manager V2.1 End-to-end Implementation, SG24-6610. Although that redbook discusses Version 2.1, most of the discussion still applies in Version 3.1. Additional information can be read from the formal IBM Tivoli Business Systems Manager Version 3.1 manuals. This redbook provides: - Overview of the redbook and IBM Tivoli Business Systems Manager - Implementation overview of IBM Tivoli Business Systems Manager - Business systems definition - Executive dashboard implementation and use - Policy based batch management - Orchestration with IBM Tivoli Intelligent Orchestrator - Problem management integration with Peregrine Service Center
INTERNATIONAL TECHNICAL SUPPORT ORGANIZATION
BUILDING TECHNICAL INFORMATION BASED ON PRACTICAL EXPERIENCE IBM Redbooks are developed by the IBM International Technical Support Organization. Experts from IBM, Customers and Partners from around the world create timely technical information based on realistic scenarios. Specific recommendations are provided to help you implement IT solutions more effectively in your environment.
For more information: ibm.com/redbooks

SG24-6770-00 ISBN 0738490164

IBM Tivoli Business Systems Manager V3.1 Advanced Implementation Topics Sg246770

Загружено:

Сведения о документе

Исходное описание:

Авторское право

Доступные форматы

Поделиться этим документом

Поделиться или встроить документ

Параметры публикации

Этот документ был вам полезен?

Это неприемлемый материал?

Авторское право:

Доступные форматы

IBM Tivoli Business Systems Manager V3.1 Advanced Implementation Topics Sg246770

Загружено:

Авторское право:

Доступные форматы

Front cover

IBM Tivoli Business Systems Manager V3.1

Budi Darmawan Wayne Doughty Michael Jobe Timothy Lam

Copyright IBM Corp. 2005. All rights reserved.

IBM Tivoli Business Systems Manager V3.1: Advanced Implementation Topics

IBM Tivoli Business Systems Manager V3.1: Advanced Implementation Topics

Copyright IBM Corp. 2005. All rights reserved.

IBM Tivoli Business Systems Manager V3.1: Advanced Implementation Topics

Copyright IBM Corp. 2005. All rights reserved.

The team that wrote this redbook

IBM Tivoli Business Systems Manager V3.1: Advanced Implementation Topics

Mark Masercola, Venkat Surath, Roger Turner IBM Software Group

Become a published author

Send your comments in an email to:

IBM Tivoli Business Systems Manager V3.1: Advanced Implementation Topics

Business Service Management with IBM Tivoli Business Systems Manager

Copyright IBM Corp. 2005. All rights reserved.

1.1 Business Service Management

IBM Tivoli Business Systems Manager V3.1: Advanced Implementation Topics

1.1.2 IT Infrastructure Library (ITIL)

Official ITIL Web site

Official OGC Web site

1.1.3 Business Service Management solution with Tivoli

IBM Tivoli Business Systems Manager V3.1: Advanced Implementation Topics

1.2 IBM Tivoli Business Systems Manager overview

1.2.1 Objects and resources

Figure 1-1 Managed object

Name Description Alert state Priority State

Dynamic object attributes

IBM Tivoli Business Systems Manager V3.1: Advanced Implementation Topics

Figure 1-2 Resource trees

1.2.2 Components and interaction

Console Agent Listener Common Listener Service Health Monitor Server

Health Monitor Client

Tivoli Management Region

TEC Event Enablement

Distributed Data Source. ( Netview, ITM)

Figure 1-3 IBM Tivoli Business Systems Manager components

IBM Tivoli Business Systems Manager V3.1: Advanced Implementation Topics

1.2.3 User interface

Figure 1-4 Java console

IBM Tivoli Business Systems Manager V3.1: Advanced Implementation Topics

Figure 1-5 Web console

Figure 1-6 Executive dashboard

1.3 Discussion scope

IBM Tivoli Business Systems Manager V3.1: Advanced Implementation Topics

1.4 Lab environment

Tivoli Intelligent Orchestrator 3.1

Tivoli Endpoint Tivoli Common Agent Cygwin

Figure 1-7 Lab environment

IBM Tivoli Business Systems Manager V3.1: Advanced Implementation Topics

Implementation process methodology overview

Copyright IBM Corp. 2005. All rights reserved.

2.1 Implementation methodology

2.2 Deployment and planning considerations

2.2.1 IBM Tivoli Business Systems Manager servers and connectivity

IBM Tivoli Business Systems Manager V3.1: Advanced Implementation Topics

Health monitor server

Event handler server

Event Handler Server

Test / Quality assurance servers

Figure 2-1 Server roles

History server Console server