proactivenet service modeling and publishing guide

www.bmc.com

BMC ProactiveNetService Modeling and Publishing Guide

Supporting

BMC ProactiveNet version 8.6BMC Impact Model Designer version 1.0

July 2011

Contacting BMC Software

You can access the BMC Software website at http://www.bmc.com. From this website, you can obtain information about the company, its products, corporate offices, special events, and career opportunities.

United States and Canada

Address BMC SOFTWARE INC2101 CITYWEST BLVDHOUSTON TX 77042-2827 USA

Telephone 713 918 8800 or800 841 2031

Fax 713 918 8000

Outside United States and Canada

Telephone (01) 713 918 8800 Fax (01) 713 918 8000

© Copyright 2011 BMC Software, Inc.

BMC, BMC Software, and the BMC Software logo are the exclusive properties of BMC Software, Inc., are registered with the U.S. Patent and Trademark Office, and may be registered or pending registration in other countries. All other BMC trademarks, service marks, and logos may be registered or pending registration in the U.S. or in other countries. All other trademarks or registered trademarks are the property of their respective owners.

Oracle and Java are registered trademarks of Oracle and/or its affiliates. Other names may be trademarks of their respective owners.

All other trademarks belong to their respective companies.

BMC Software considers information included in this documentation to be proprietary and confidential. Your use of this information is subject to the terms and conditions of the applicable End User License Agreement for the product and the proprietary and restricted rights notices included in this documentation.

Restricted rights legendU.S. Government Restricted Rights to Computer Software. UNPUBLISHED -- RIGHTS RESERVED UNDER THE COPYRIGHT LAWS OF THE UNITED STATES. Use, duplication, or disclosure of any data and computer software by the U.S. Government is subject to restrictions, as applicable, set forth in FAR Section 52.227-14, DFARS 252.227-7013, DFARS 252.227-7014, DFARS 252.227-7015, and DFARS 252.227-7025, as amended from time to time. Contractor/Manufacturer is BMC SOFTWARE INC, 2101 CITYWEST BLVD, HOUSTON TX 77042-2827, USA. Any contract notices should be sent to this address.

http://www.bmc.com

3

Customer support

You can obtain technical support by using the BMC Software Customer Support website or by contacting Customer Support by telephone or e-mail. To expedite your inquiry, see “Before contacting BMC.”

Support website

You can obtain technical support from BMC 24 hours a day, 7 days a week at http://www.bmc.com/support. From this website, you can

■ read overviews about support services and programs that BMC offers■ find the most current information about BMC products■ search a database for issues similar to yours and possible solutions■ order or download product documentation■ download products and maintenance■ report an issue or ask a question■ subscribe to receive proactive e-mail alerts when new product notices are released■ find worldwide BMC support center locations and contact information, including e-mail addresses, fax numbers, and

telephone numbers

Support by telephone or e-mail

In the United States and Canada, if you need technical support and do not have access to the web, call 800 537 1813 or send an e-mail message to [email protected]. (In the subject line, enter SupID:<yourSupportContractID>, such as SupID:12345). Outside the United States and Canada, contact your local support center for assistance.

Before contacting BMC

Have the following information available so that Customer Support can begin working on your issue immediately:

■ product information

— product name— product version (release number)— license number and password (trial or permanent)

■ operating system and environment information

— machine type— operating system type, version, and service pack or other maintenance level such as PUT or PTF— system hardware configuration— serial numbers— related software (database, application, and communication) including type, version, and service pack or

maintenance level

■ sequence of events leading to the issue

■ commands and options that you used

■ messages received (and the time and date that you received them)

— product error messages— messages from the operating system, such as file system full— messages from related software

http://www.bmc.com/support

mailto:[email protected]

4 BMC ProactiveNet Service Modeling and Publishing Guide

BMC ProactiveNet Service Modeling and Publishing Guide 5

ContentsChapter 1 Overview 15

About this guide. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 15About BMC Impact Model Designer. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 16After upgrading to BMC ProactiveNet version 8.5. . . . . . . . . . . . . . . . . . . . . . . . . . . . . 16Before you begin using BMC Impact Model Designer . . . . . . . . . . . . . . . . . . . . . . . . . . 16Other documents you may need . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 17

Chapter 2 BMC Impact Model Designer user interface 19

Installing BMC Impact Model Designer . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 19Prerequisites to using BMC Impact Model Designer . . . . . . . . . . . . . . . . . . . . . . . . . . . 19Launching BMC Impact Model Designer. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 20BMC Atrium Explorer and BMC Impact Model Designer. . . . . . . . . . . . . . . . . . . . . . . 20

Who should use BMC Atrium Explorer? . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 20BMC Impact Model Designer features . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 21BMC Impact Model Designer menu bar. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 21

Chapter 3 Designing a service model 23

Service model design process. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 23Defining business goals for the service model . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 25Decomposing a business service . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 26Defining the service catalog . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 27Defining the service model . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 28

Defining a configuration item . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 29Defining a new component class for a component type . . . . . . . . . . . . . . . . . . . . . 29Analyzing a component’s critical failures . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 30Determining a component’s relationship and dependencies . . . . . . . . . . . . . . . . . 31Determining the organization of the modeled relationships . . . . . . . . . . . . . . . . . 32Identifying a component’s critical events and their sources. . . . . . . . . . . . . . . . . . 32Displaying business key performance indicators (KPIs) . . . . . . . . . . . . . . . . . . . . . 34

Service model design considerations . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 35Determining cell topology for the service model . . . . . . . . . . . . . . . . . . . . . . . . . . . 35Component property updates . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 36

Chapter 4 Understanding a service model 37

Sources of service model objects . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 37Rules for service model data modification and deletion . . . . . . . . . . . . . . . . . . . . . 39Using the BMC Atrium CMDB as a source of service model data. . . . . . . . . . . . . 40

Contents 6

Using Direct Feed . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 40Precedences . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 40

Service components . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 41Component classes and types . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 41Service configuration items . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 42Component status and substatus . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 42Component status computation . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 43

Service model component types . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 44Component relationships . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 51

Service consumers and providers . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 51Status propagation in relationships . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 53Relationship states. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 53Relationship control . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 54

Service schedules . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 55Timeframes . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 55Service schedules example with exceptions . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 56

Chapter 5 Understanding a service model created in BMC Impact Model Designer57

Role of the BMC Atrium CMDB in service modeling. . . . . . . . . . . . . . . . . . . . . . . . . . . 57Service model and the Common Data Model . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 58

Sandboxes . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 62Datasets . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 63Promotion . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 63Service model publishing . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 64Service model execution on cells . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 64

Chapter 6 Building a service model in BMC Impact Model Designer 65

Service model creation process . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 65Launching BMC Impact Model Designer. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 65Working with service configuration items. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 66

Creating service configuration items in BMC Impact Model Designer . . . . . . . . 66Switching sandbox view modes . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 71Editing configuration items . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 71Hiding configuration items . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 72Deleting configuration items . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 72Finding configuration items. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 73

Defining relationships between configuration items . . . . . . . . . . . . . . . . . . . . . . . . . . . 74Creating and editing component relationships . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 74Associating events with a configuration item . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 75Working with timeframes and service schedules . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 75

Icons used in the service schedule and timeframes dialog box . . . . . . . . . . . . . . . 75Working with timeframes . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 76Working with service schedules . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 78Assigning components to service schedules . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 81

Granting permissions to individual service model objects . . . . . . . . . . . . . . . . . . . . . . 82Promoting the service model . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 82

About the publishing process . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 82

Contents 7

Before you promote. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 83Submitting a promotion . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 83Verifying promotion status . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 84

Modifying and deleting service model data . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 85Exporting class definitions from the BMC Atrium CMDB to cells. . . . . . . . . . . . . . . . 85

Chapter 7 Component and relationship status propagation 87

About component and relationship status . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 87How component status computation works . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 87

Status computation functions . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 88Status computation algorithms . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 89How status computation algorithms work . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 89About status computation models . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 90Anatomy of a status computation model. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 91The internal status NONE . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 91Quorum algorithm examples. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 91

Relationship status propagation concepts . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 93How status propagation works . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 94Status propagation models. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 95Default status propagation models. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 95What is a valid status propagation model? . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 96

Important service components. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 97Dynamic prioritization . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 98

Self priority . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 99Impacts priority . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 108Determination of final priority . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 109How cost impact is calculated . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 111How SLA impact is calculated. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 111

Chapter 8 Managing BMC Impact Model Designer 113

Adding new classes to BMC Atrium CMDB . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 113Making your changes visible to applications . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 113Creating a new service model component class in the BMC Atrium CMDB. . . 115

Chapter 9 Managing the BMC ProactiveNet Publishing Server 117

BMC ProactiveNet Publishing Server overview . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 117BMC ProactiveNet Publishing Server architecture . . . . . . . . . . . . . . . . . . . . . . . . 118BMC Atrium CMDB . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 119Non-Atrium CMDB sources for service model objects . . . . . . . . . . . . . . . . . . . . . 119

Publishing server optional configurations . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 120Specifying a port for Service Model Manager. . . . . . . . . . . . . . . . . . . . . . . . . . . . . 120High availability cell server and BMC ProactiveNet Publishing Server. . . . . . . 120

Monitoring BMC ProactiveNet Publishing Server with cell events . . . . . . . . . . . . . . 123Modifying the generation of events . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 123Understanding classes and slots for BMC ProactiveNet Publishing Server events

125About impact management data . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 133


Understanding publishing environments. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 134About publishing environments . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 134About home cell, home cell alias, and cell alias. . . . . . . . . . . . . . . . . . . . . . . . . . . . 135

Publishing from the BMC Atrium CMDB. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 136Enabling AtriumCMDB Publish publishing . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 137Using BMC Impact Model Designer . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 137Creating advanced publishing environments . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 139Examples of advanced environments . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 140Defining BMC Atrium CMDB classes for BMC ProactiveNet . . . . . . . . . . . . . . . 142Defining BMC Atrium CMDB attributes for BMC ProactiveNet . . . . . . . . . . . . . 142Initializing the BMC Atrium CMDB with BMC ProactiveNet data . . . . . . . . . . . 143Initializing a cell . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 144Example—creating BMC ProactiveNet data in BMC Atrium CMDB from BAROC

files. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 145Purging and deleting service model objects . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 146Publishing in automated or manual mode. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 147

Publishing from a Direct Publish source. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 149About home cell and cell alias . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 150About the enterprise mode. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 152About class and slot data . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 152Enabling Direct Publish publishing . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 153Sending BMC ProactiveNet data to the cell . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 153Modifying home cell and cell aliases . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 153Initializing a cell from a Direct Publish environment. . . . . . . . . . . . . . . . . . . . . . . 154Examples—using cell aliases for Direct Publish publishing . . . . . . . . . . . . . . . . . 154

Securing publishing environments . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 156pserver.conf file and parameters . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 158Configuring the Notify ARDBC plug-in . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 164Configuring the Notify plug-in for AR server groups . . . . . . . . . . . . . . . . . . . . . . . . . 165Viewing publication history . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 166Diagnosing publication issues . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 166

Appendix A Troubleshooting 169

Publishing Server . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 169Verifying that the publishing server is running . . . . . . . . . . . . . . . . . . . . . . . . . . . 169Using trace files . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 170Stopping the publishing server when JMS is not running. . . . . . . . . . . . . . . . . . . 170Publishing large service models . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 170Publishing failures and reattempts . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 172The publishing server service or daemon fails to start. . . . . . . . . . . . . . . . . . . . . . 172No publication after successful promotion . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 173Reconciliation jobs hang . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 173The publishing server does not reply to requests . . . . . . . . . . . . . . . . . . . . . . . . . . 174Diagnosing publication failures. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 174Another publish request is ongoing . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 179Using dynamic ports with the ARDBC Notify plug-in . . . . . . . . . . . . . . . . . . . . . 179

Frequently Asked Questions. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 179I cannot launch BMC Impact Model Designer successfully . . . . . . . . . . . . . . . . . 180

Contents 9

I cannot see the BMC Impact Model Designer menu bar in spite of installing BMC Impact Model Designer successfully . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 180

I cannot see the changes I made to the CIs . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 181The service model I try to create appears as yellow blocks . . . . . . . . . . . . . . . . . 181

Troubleshooting BMC Impact Model Designer . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 182

Appendix B Default service model data classes 183

Service model data structures . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 183Service model data class overview . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 183Service model data class files. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 184

Service model component data classes . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 184BMC_BaseElement data class . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 185BMC_Impact data class. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 190BMC_DOWNTIME_STATUS_CONFIG data class . . . . . . . . . . . . . . . . . . . . . . . . 193BMC_STATUS_COMPUTATION data class . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 194BMC_STATUS_PROPAGATION data class . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 196BMC_PROPAGATION_MAP data class . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 197

BMC ProactiveNet data class descriptions. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 199BMC_SEVERITY_TO_STATUS data class . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 199BMC_SLOT_FORMULAS data class . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 199BMC_TIME_SCHEDULE data class . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 200BMC_TIME_FRAME_TO_SCHEDULE data class . . . . . . . . . . . . . . . . . . . . . . . . . 200BMC_SELF_PRIORITY_MAPPING data class . . . . . . . . . . . . . . . . . . . . . . . . . . . . 201BMC_SERVICE_SCHEDULE_CONFIG data class . . . . . . . . . . . . . . . . . . . . . . . . 201BMC_STATUS_TO_SEVERITY data class . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 202SIM_TIME_FRAME class . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 202SIM_CellAlias class . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 202SIM_CellInformation class . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 203BMC_PROMOTION_LOG class . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 203

Service model event classes . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 203CORE_EVENT base class . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 203Root event class . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 205History event class. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 205Impact event class . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 206

Appendix C Upgrading a service model to BMC Atrium CMDB 207

Upgrading from non-Atrium-CMDB SIM to BMC Atrium CMDB SIM . . . . . . . . . . 207Upgrading SIM data that originates from third-party source . . . . . . . . . . . . . . . 208

Recommended upgrade steps . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 208Understanding how the upgrade works . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 209Ensuring quality data in BMC Atrium CMDB . . . . . . . . . . . . . . . . . . . . . . . . . . . . 210Identifying components and data reconciliation . . . . . . . . . . . . . . . . . . . . . . . . . . 211Data imported into BMC.SIM . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 214sim2cmdb CLI command . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 215Running the upgrade . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 218Reviewing the output files for sim2cmdb . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 222Upgrade commitment. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 225CI identification . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 226


Dataset cleanup . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 227sim2cmdb return codes . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 227

Index 231

Tables 11

TablesThen and now . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 16Useful BMC documentation . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 17Example business service model spreadsheet . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 27BMC Impact Model Designer values for IT service Sales Logix . . . . . . . . . . . . . . . . . 28Severity level index . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 30Occurrence level index . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 30How service model objects get to a cell . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 38Advantages and disadvantages of different object sources . . . . . . . . . . . . . . . . . . . . . 39Service model component types . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 44Main relationship classes . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 51Global and Local timeframe differences . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 56BMC ProactiveNet-qualified subclasses of BMC_Collection . . . . . . . . . . . . . . . . . . . . 58BMC ProactiveNet-qualified subclasses of BMC_LogicalEntity . . . . . . . . . . . . . . . . . 59BMC ProactiveNet-qualified subclasses of BMC_System . . . . . . . . . . . . . . . . . . . . . . . 59BMC ProactiveNet-qualified subclasses of BMC_SystemComponent . . . . . . . . . . . . 59BMC ProactiveNet-qualified subclasses of BMC_Software . . . . . . . . . . . . . . . . . . . . . 60BMC ProactiveNet-qualified subclass of BMC_SystemService . . . . . . . . . . . . . . . . . . 60BMC ProactiveNet Performance Management-qualified attributes . . . . . . . . . . . . . . 61Fields on the Other tab . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 70View mode switch icons . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 71Schedules and timeframes icons . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 75Timeframe Edit field descriptions . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 77Edit Schedule field descriptions . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 79Icons in Objects-to-be-Published pane . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 84Status computation functions and computed component statuses . . . . . . . . . . . . . . . 88What a function returns when using an available algorithm . . . . . . . . . . . . . . . . . . . . 89Description of predefined status computation models . . . . . . . . . . . . . . . . . . . . . . . . . 90How status propagation models work in relationships . . . . . . . . . . . . . . . . . . . . . . . . 96BMC ProactiveNet Publishing Server event generation . . . . . . . . . . . . . . . . . . . . . . . 123Common Event Model (CEM) slots . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 125IPS_START slots . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 127IPS_STOP slots . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 127IPS_CONFIG slots . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 128IPS_CONNECT slots . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 129IPS_IM_CONNECT slots . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 129IPS_REQUEST slots . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 130IPS_PUBLISH slots . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 132IPS_CLASSINFO slots . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 132IPS_ERROR slots . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 133IPS_ENV slots . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 133


Basic steps to create advanced test environments . . . . . . . . . . . . . . . . . . . . . . . . . . . . 139Basic process of publishing from a Direct Publish source . . . . . . . . . . . . . . . . . . . . . . 149Valid parameters for a Direct Publish environment . . . . . . . . . . . . . . . . . . . . . . . . . . 150pserver.conf file . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 159ar.cfg file parameter descriptions . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 165Publishing server request failure messages . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 175Error Messages . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 182Service management data class files . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 184Slots that define CIs . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 187BMC_Impact slot definitions in alphabetical order . . . . . . . . . . . . . . . . . . . . . . . . . . . 192BMC_DOWNTIME_STATUS_CONFIG slot . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 194BMC_STATUS_COMPUTATION slots in alphabetical order . . . . . . . . . . . . . . . . . . 195Status propagation slots in alphabetical order . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 197BMC_PROPAGATION_MAP slot definitions . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 198Identifying components in the BMC Atrium CMDB . . . . . . . . . . . . . . . . . . . . . . . . . . 212Key slots in reconciliation rules for management data . . . . . . . . . . . . . . . . . . . . . . . . 213Possible import results . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 215sim2cmdb.conf file . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 216sim2cmdb command options . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 219error exit codes for sim2cmdb CLI command . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 227

Figures 13

FiguresBMC Impact Model Designer features in the BMC Atrium Core Console menu bar . .

21Example of a service model . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 24Inserting KPI data into the business_slot with an action . . . . . . . . . . . . . . . . . . . . . . . 35Updating KPI data with a rule . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 35Impact (status) propagation in relationships . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 52Classes accordion . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 67Edit Timeframe dialog box . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 76Edit Schedule dialog box . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 79Propagation paths between root cause and important components . . . . . . . . . . . . . . 98Self priority determination . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 99Cost priority method of priority determination . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 103Worst SLA method of priority determination . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 107Impacts priority determination . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 108Final priority determination . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 110BMC ProactiveNet Publishing Server architecture . . . . . . . . . . . . . . . . . . . . . . . . . . . 118BMC Atrium Explorer and BMC Impact Model Designer icons . . . . . . . . . . . . . . . . 181BMC_BaseElement definitions . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 185MC_SM_COMPONENT definition . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 186MC_SM_DATA definition . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 187CORE_DATA definition . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 187BMC_Impact definition . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 191MC_SM_RELATIONSHIP definition . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 191MC_SM_DATA definition . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 191CORE_DATA definition . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 192BMC_DOWNTIME_STATUS_CONFIG definition . . . . . . . . . . . . . . . . . . . . . . . . . . . 194BMC_SIM_DATA definition . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 194BMC_STATUS_COMPUTATION definition . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 195BMC_SIM_DATA definition . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 195BMC_STATUS_PROPAGATION definition . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 196BMC_SIM_DATA definition . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 197BMC_PROPAGATION_MAP definition . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 198BMC_SIM_DATA definition . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 198SEVERITY_TO_STATUS definition . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 199BMC_SLOT_FORMULAS definition . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 200BMC_TIME_SCHEDULE definition . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 200BMC_TIME_FRAME_TO_SCHEDULE definition . . . . . . . . . . . . . . . . . . . . . . . . . . . . 201BMC_SELF_PRIORITY_MAPPING definition . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 201BMC_SERVICE_SCHEDULE_CONFIG definition . . . . . . . . . . . . . . . . . . . . . . . . . . . 201BMC_STATUS_TO_SEVERITY definition . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 202


SIM_TIME_FRAME definition . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 202Partial CORE_EVENT definition . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 204MC_SMC_ROOT definition . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 205SMC_STATE_CHANGE definition . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 206MC_SMC_EVENT definition . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 206Example output file without commit . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 223Example verify.log file . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 224Example output file with commit . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 225

Chapter 1 Overview 15

C h a p t e r 11 Overview

A service model is a representation of a service (business or IT) and the relationship of the infrastructure components (that is, configuration items or CIs) required to support/provide that service.

A CI is any component that needs to be managed in order to deliver an IT service. Information about each CI is recorded in a configuration record within BMC Atrium Configuration Management Database (CMDB) and is maintained throughout its lifecycle by Configuration Management. CIs are under the control of Change Management. CIs typically include hardware, software, buildings, people, and formal documentation, such as process documentation and SLAs. A CI must be uniquely identifiable, have some characteristic that can change, be manageable, have certain attributes that are associated to it, and be recorded in BMC Atrium CMDB.

Service models can be created using the following BMC products:

■ BMC Atrium Explorer

■ BMC Impact Model Designer

■ The Administration Console of BMC ProactiveNet Performance Management

About this guideThis book provides detailed information about designing, developing, publishing, and maintaining service models that enable you to manage your IT resources from the perspective of the business services that they provide.

In addition to explaining the concepts of service modeling and designing, this guide also contains information on using BMC Impact Model Designer to create and publish service models.

About BMC Impact Model Designer


About BMC Impact Model DesignerBMC Impact Model Designer is a plug-in integrated into BMC Atrium Core Console. BMC Impact Model Designer is aimed at BMC ProactiveNet version 8.5 and later users who want to create, design, and publish service models. It is also aimed at BMC Service Impact Manager users who are upgrading to BMC ProactiveNet version 8.5 or later.

If you are a Service Impact Manager (SIM) user that used Service Model Editor to design and create service models, and you are upgrading to version 8.5 or later of BMC ProactiveNet Performance Management, you need to use BMC Impact Model Designer. BMC Impact Model Designer offers the functionality of Service Model Editor in an Atrium environment.

After upgrading to BMC ProactiveNet version 8.5 or later

Table 1 lists the products that are not shipped with BMC ProactiveNet Performance Management version 8.5 and later. You cannot use these products with BMC ProactiveNet Performance Management and BMC Impact Model Designer. You must use the corresponding products listed in the table.

Before you begin using BMC Impact Model Designer

Ensure that you have the following software installed in the order mentioned below before using BMC Impact Model Designer:

■ BMC ARSystem Datastore

■ BMC Remedy Action Request System

Table 1 Then and now

What you were using earlier What you will use now

BMC Service Model Editor BMC Impact Model Designer

BMC Impact Portal BMC Atrium Core Console

BMC Service Impact Manager BMC ProactiveNet Performance Management

Other documents you may need

Chapter 1 Overview 17

BMC Remedy Action Request System is the software through which you can access the BMC Impact Model Designer UI. For information about installing BMC Remedy Action Request System, see BMC Remedy Action Request System Installation Guide.

■ BMC Atrium CMDB suite

BMC Atrium CMDB is the database in which CIs are recorded and maintained throughout their lifecycle. For information about installing BMC Atrium CMDB suite, see BMC Atrium Core Installation Guide.

■ BMC ProactiveNet Performance Management

BMC ProactiveNet Performance Management using which you can view the service models created and published through BMC Impact Model Designer. For information about installing BMC ProactiveNet Performance Management, see BMC ProactiveNet Getting Started Guide.

Other documents you may needIn addition to this guide, you may need the guides mentioned in Table 2. These guides contain information about BMC Atrium CMDB and BMC ProactiveNet Performance Management. All these guides are available on the BMC Support website at http://www.bmc.com/support/product-documentation

You need to register to the BMC Support website to access the documents.

Table 2 Useful BMC documentation

Guide name Description

BMC ProactiveNet Getting Started Guide

Contains information on installing BMC ProactiveNet Performance Management and BMC ProactiveNet CMDB Extensions which is a part of the installation.

BMC ProactiveNet User Guide Contains information on using BMC ProactiveNet Performance Management.

BMC ProactiveNet Administrator Guide Contains information on using the Administration Console of MC ProactiveNet Performance Management.

BMC ProactiveNet Upgrade Guide Contains information for SIEM customers to upgrade to BMC ProactiveNet Performance Management.

The BMC ProactiveNet guides mentioned above are available at http://webapps.bmc.com/support/faces/prodallversions.jsp?seqid=172810

BMC Atrium Core Installation Guide Contains information on installing, upgrading, and troubleshooting BMC Atrium Core features such as BMC Atrium CMDB, BMC Atrium Integration Engine, Product Catalog, Atrium Web Services components, and BMC Atrium Impact Explorer.

Other documents you may need


BMC Atrium CMDB User's Guide Contains information on working with CIs and relationships using BMC Atrium Explorer of the BMC Atrium Configuration Management Database (CMDB) product.

BMC Atrium CMDB Administrator’s Guide

Contains information about setting permissions, configuring federation, modifying the data model, configuring an impact model, and other administrative tasks in BMC Atrium CMDB.

The BMC Atrium guides mentioned above are available at http://webapps.bmc.com/support/faces/prodversion.jsp?prodverseqid=176447

BMC Remedy Action Request System Installation Guide

Contains instructions for installing BMC Remedy Action Request System.

BMC Remedy Action Request System guides are available at http://webapps.bmc.com/support/faces/prodallversions.jsp?seqid=108018

BMC Impact Solutions Knowledge Base Development Reference Guide

Contains reference information pertaining to specific event and data classes, the MRL language, syntax for policies, rules, and rule sets.

The BMC Impact Solutions Knowledge Base Development Reference Guide is available at http://webapps.bmc.com/support/faces/prodallversions.jsp?seqid=8741

Table 2 Useful BMC documentation

Guide name Description


C h a p t e r 22 BMC Impact Model Designer user interface

This chapter provides information on installing and accessing BMC Impact Model Designer. It also gives an overview of the BMC Impact Model Designer user interface (UI).

Installing BMC Impact Model Designer BMC Impact Model Designer is a part of the installation of BMC ProactiveNet CMDB Extensions and is automatically installed when you install BMC ProactiveNet CMDB Extensions. For information on installing these extensions, see the BMC ProactiveNet Getting Started Guide. See the “Other documents you may need” section for the location of this guide.

Prerequisites to using BMC Impact Model Designer

■ Ensure that you restart BMC Remedy AR System mid-tier after installing BMC ProactiveNet CMDB Extensions.

■ You must be a user with administrator privileges. If you are not an administrator, you will not be able to view the Impact Model Designer icon the BMC Atrium Core Console page, and create service models using BMC Impact Model Designer.

Launching BMC Impact Model Designer


Launching BMC Impact Model DesignerYou can open BMC Impact Model Designer from the BMC Remedy AR System UI:

1. Open a browser and enter the URL in the format http://<AR server mid-tier hostname>:<mid-tier port>/arsys where:

■ AR server mid-tier hostname represents the system on which BMC Remedy AR System mid-tier is installed

■ mid-tier port is the HTTP port number that the BMC Remedy AR System listens at

2. Log on to BMC Remedy AR System.

3. In the Home page, click the Atrium Core Console link on the left side.

4. In the BMC Atrium Core Console page, click Impact Model Designer.

BMC Atrium Core Console is displayed. BMC Impact Model Designer is part of BMC Atrium Core Console.

BMC Atrium Explorer and BMC Impact Model Designer

BMC Impact Model Designer is leveraged from BMC Atrium Explorer and uses the same UI as that of BMC Atrium Explorer. You can use both of these products to create service models. However, BMC Impact Model Designer contains some unique functionality not available in BMC Atrium Explorer. BMC Impact Model Designer = BMC Atrium Explorer + unique features listed in the “BMC Impact Model Designer features” section.

Who should use BMC Atrium Explorer?

Use BMC Atrium Explorer if you want to create and design service models in a complete BMC Atrium environment. In this case, you do not need BMC ProactiveNet Performance Management to view and publish service models.

If you use BMC Atrium Explorer, you will not be able to use the BMC Impact Model Designer GUI to edit properties of the configuration items (CIs), or create schedules and timeframes for the CIs.

BMC Impact Model Designer features


BMC Impact Model Designer featuresThe following features are unique to BMC Impact Model Designer and are not present in BMC Atrium Explorer:

■ Creating schedules and timeframes

■ Editing impact management attributes of CIs using the GUI

BMC Impact Model Designer menu barFigure 1 illustrates the BMC Atrium Core Console menu bar that contains BMC Impact Model Designer. The features of BMC Impact Model Designer visible in the menu bar are highlighted in the figure. All BMC Impact Model Designer users can view this menu bar. BMC Atrium Core Console users that do not have BMC Impact Model Designer installed will not be able to view BMC Impact Model Designer features.

Features not highlighted in the figure below are BMC Atrium Explorer features. For information about BMC Atrium Explorer features, see the BMC Atrium CMDB User's Guide.

Figure 1 BMC Impact Model Designer features in the BMC Atrium Core Console menu bar

NOTE The Promote Sandbox Changes icon is visible to both BMC Impact Model Designer and BMC Atrium Core Console users.

Schedules and timeframes

Promote Sandbox Changes

BMC Impact Model Designer menu bar



C h a p t e r 33 Designing a service model

This book provides detailed information about designing, developing, publishing, and maintaining service models that enable you to manage your IT resources from the perspective of the business services that they provide.

Service model design processThe best service models are enterprise-specific, achieving the organization’s business availability goals. The IT environment, its organization, and its operational constraints vary significantly among enterprises.

A cost-effective strategy when you begin the process of building a service model is to select one critical business process/service, decompose it to identify all aspects of the service, and build a complete service model for that part of your enterprise.

Figure 2 shows an example of a generic service model as it appears in BMC Impact Model Designer with business users, services, and IT structure layers. The lines between the configuration items (CIs) represent provider/consumer relationships.

Service model design process


Figure 2 Example of a service model

The following factors determine how a service impact management solution should be designed and implemented:

■ diversity of IT resources and how they are monitored■ location of resources and how the management responsibilities for them are

distributed within and among IT or information services (IS) groups ■ relative importance of various resources in the delivery of business services■ need for change management■ maintenance of the service model over time

business consumers

service layer

IT infrastructure

Defining business goals for the service model


The service modeling process involves:

■ identifying sources of event information■ gaining familiarity with the structure and content of events■ identifying core competencies within the organization■ identifying critical business processes■ identifying IT services and their components■ finding relationships and dependencies between IT services■ building the necessary database of information (asset inventory, service catalog,

and so on)■ building the service model

Defining business goals for the service modelThe most basic step involved in defining a service model is defining the specific business goals you hope to achieve with the model.

To do so, the IT or IS group must engage the business managers in defining short-term, mid-term, and long-term goals for service impact management for the enterprise. These goals guide the design and development of deliverables for all service model development phases and define the amount of time and effort required for development and implementation.

Some possible goals for service impact management are:

■ operational efficiency—This type of implementation is run by and for the IT or IS group. It consists of a thin layer of logical groups on top of a large number of IT resources, ranging from applications and systems to hard disks and other hardware components. Services are just logical groupings that provide a convenient way of classifying the technical resources.

■ business-focused operational efficiency—This type of implementation is likely to involve various populations and centers of management in the enterprise. It consists of a balanced representation of the operational environment, encompassing the IT components, such as systems and applications, and the logical components, such as services, user groups, and other business objects.

■ business continuity and service availability—This type of implementation is driven from the top and ensures that IT or IS is delivering their services as agreed. It consists of a business-centric model in which business processes, services, and SLAs rely on a small number of vital IT components that measure the pulse of the underlying environment.

Decomposing a business service


Decomposing a business serviceThe purpose of decomposing a business service is to identify and document business processes, identify the IT services that support them, and identify IT components and assets that provide the IT services. For example, a hardware manufacturing organization may identify a business function as microprocessor procurement, a supporting IT service as procurement information storage, and the supporting IT assets as servers, databases, and related hardware and software systems.

On a high level, a service model is a collection of components that represent a business service. A business service can have one or more business processes. Each business process can contain several functional applications, each of which can have multiple IT components. A service model will contain the processes, show how the components are interconnected, and show how component failures propagate and impact the upstream services.

The following steps facilitate the process of creating a service model.

1 Identify business services.

Sources of information include business unit managers, business process managers, and staff personnel knowledgeable about the business services. Company organization charts might be helpful in identifying the relevant people.

The process involves interviewing the managers and identifying the following information:

■ business processes—Identify key business processes such as Market Research, Product Planning, Response Management, or Case Management. There can be multiple levels of business processes, starting with higher level core competencies and business functions, to specific sub-business processes.

■ functional applications—Identify the business applications that support the business processes. Map the business processes to the functional apps.

Map the functional applications to IT service components to create business service models.

2 Identify IT services.

Sources of information include IT managers and staff. Disaster recovery plans, help desk documents, and purchase orders might be useful in identifying IT components and the business processes that they support.

Defining the service catalog


The process involves identifying the list of IT assets (components). Interview the IT management and staff, or utilize an asset/configuration management database as resources:

■ Create a list of IT services (service catalog); discover what IT services are offered to business units through use of IT assets. Examples of IT services include customer support and customer call monitoring.

■ For each IT service, identify the IT assets that support the service. ■ Identify the interdependencies among the IT components and formulate a

topology map. Consider the relationships and dependencies between IT components.

3 Build a business service model, and link the business processes to the IT services you have identified.

Defining the service catalogA service catalog is a list of IT services, logical assets, and physical assets that support business processes for a company.

The service catalog should list all of the IT services with a summary of their characteristics, including values for the fields shown in Table 4.

Table 3 Example business service model spreadsheet

Core competenciesBusiness functions

Business processes IT services IT component

Plan and develop products

Marketing Market research

Research and development

product planning

Manager customer relations

Front office sales

Response management

Customer support

Support service requests

FTP Server: FTP

Sprint Server: Walrus

Sales Logix Database: SALLOGApplications: Sales LogixUser group: Tech Support deptServers: Antelope

Defining the service model


For the Sales Logix IT service example shown in Table 3 on page 27, the detailed IT component information required by BMC Impact Model Designer is shown in Table 4.

Defining the service modelAfter you have decided on a business goal for service impact management, decomposed your business processes, and created a service catalog, you are ready to define the actual service model.

Defining the service model involves establishing a list of all the IT resources that should be represented in the service model. This information should include:

■ each resource’s name or component identification pattern ■ its location or site

Table 4 BMC Impact Model Designer values for IT service Sales Logix

Component type

Component name

Component description

Cell name

In/out model

Status computation model

Relationship Policy

Provider instancesthat impact

Consumer instances depending on

business process


Business function is Customer support

bogart in direct Tech Support Analysts

user community

Tech Support Analysts

Techs supporting service requests

bogart in standard direct Sales Logix v6.01


application

Sales Logix v6.01

Sales Logix application, v 6.01

bogart in standard increasing Sales Logix server

Tech Support Analysts

application server

Sales Logix server

Sales Logix server

bogart in standard increasing Sales Logix DB software

Sales Logix v6.01Tech Support Analysts

database Sales Logix DB software

Sales Logic database software v6.0

bogart in standard direct SALLOG Sales Logix applicationTech Support Analysts

database server

SALLOG Sales Logix database server

bogart in standard direct Sales Logix db softwareTech Support Analysts

Defining a configuration item


You use this information later in the design phase and when creating service model components.

The first step in developing a service model is to design its logical architecture. To do this, you must analyze the IT environment to

■ identify the resources that make up the service model■ identify the event sources for the resources and their characteristics■ determine the functional relationships and dependencies between various

resources that can affect services

Defining a configuration item

In decomposing your business services, you have identified the basic building blocks of a service model—its assets or components. In the BMC service model, each individual resource is represented by a CI.

CIs are created as a single instance of a class type that is defined in the BMC Atrium CMDB. Classes may identify physical components such as servers or databases, and logical components such as user groups. CIs are created through BMC Impact Model Designer.

The order in which you create related physical components is unimportant. You can create an IT system component before or after an application component that runs on it.

Defining a new component class for a component type

CIs represent an individual occurrence of a component type, or class. Component classes are displayed in BMC Impact Model Designer as templates from which you can create new component types. They are created and maintained in the BMC Atrium CMDB.

In order to maintain service model consistency, when you make a change to the BMC ProactiveNet classes in the BMC Atrium CMDB, you must distribute the changes to all of the BMC ProactiveNet instances (cells) and recompile them. Use the pclassinfo command to distribute the changes. For information about this command, see “Exporting class definitions from the BMC Atrium CMDB to cells”.

Analyzing a component’s critical failures


Analyzing a component’s critical failures

After service components and associated functions are identified, you need to monitor their status to analyze their effects and watch for failures. To do so:

■ identify the cause of failures and degraded performances for the service component

■ categorize the failures into availability, performance, capacity■ identify the effects of the failures■ assign a severity level to each failure

Severity level values are listed in Table 5.

■ assign a frequency or occurrence level to each failure

Occurrence level index values are listed in Table 6.

Table 5 Severity level index

Severity level Definition

severe Permanently disabling

significant critical end user dissatisfaction

moderate causes degradation of service

minor causes inconvenience to end user

slight caused annoyance for customer

minimal not noticeable by end user

Table 6 Occurrence level index

Occurrence level Definition

high high change of occurrence and needs immediate attention

frequent frequent change to happen and needs attention

moderate moderate change to consider prevention

occasional occasionally might happen

slight slight chance to happen

remote unlikely to happen

Determining a component’s relationship and dependencies


Sample of failure modes effects and analysis

■ Component—Message Transfer Agent (MTA)■ Function—routes and convert messages■ Point of failure—queue length size growing■ Issue type—performance■ Cause of failure—network connection failure, receiving MTA failure, problem on

sending or receiving machine■ Effect of failure—remote recipients will not receive e-mail while MTA down■ Severity—significant■ Occurrence—slight■ Prevention—monitoring of the system, network, and exchange services■ Detection—PATROL NT and Exchange parameters related to the issue

Determining a component’s relationship and dependencies

To understand the impact of different components and their status on a service, you identify the underlying dependencies and relationships within the IT Systems.

■ consider relationships and dependencies within the IT service; for example, within email service, or call support’s dependency on email

■ consider dependencies on other services; for example, web services and email services

■ consider how the same IT components might support more than one service; for example, one server hosting multiple applications

■ consider the dependencies of several business processes on the same service; for example, email used by all

■ consider the relationship between IT services and business processes (the link called business service)

Map business processes to each system. The grouping of IT systems becomes the IT services, so that only one IT service would exist for each business process.

Identify the relationships and dependencies among the IT components and the logical components to one another. The direction of the relationship is important. If a system component is to be linked to a hardware component, the hardware component must be the provider and the system component the consumer.

Examine how the various resources combine to deliver a service on a particular host. Define the resources that are providers and the resources that consume their services in the service delivery stream.

Determining the organization of the modeled relationships


Determining the organization of the modeled relationships

How you organize service model components depends on the goals that your organization wants to attain through service impact management. You can organize your service model components using one of these basic organizational strategies:

■ The IT resource management strategy is to create a thin layer of logical groupings on top of a large number of IT resources, ranging from applications and systems to hard disks and other hardware components. This type of implementation is run by and for the IT or IS group. Services are just logical groupings that provide convenient way of classifying the technical resources. The driving force behind this model is operational efficiency.

■ The business-focused operational efficiency strategy is to create a balanced representation of the operational environment, encompassing the IT components, such as systems and applications, and the logical components, such as services, user groups, and other business objects. This type of implementation is likely to involve various populations and loci of management in the enterprise. The driving force is operational efficiency, but with a balanced business perspective.

■ The business continuity and service availability strategy is to implement a business-centric model in which business processes and services rely on a small number of vital IT components to give a status overview of the underlying environment. This type of implementation is driven from the top, ensuring that IT or IS is delivering their services as agreed. The driving force is business continuity and availability. This strategy is similar to BMC Software’s BSM Strategy that is called a Business Service Impact Model.

Although these strategies are only briefly outlined here, they are helpful in understanding that each implementation probably has a different focus, favoring some types of components and having more or less granularity in some branches of the component hierarchy. The strategy that you choose also affects the amount of time and effort required for its development and implementation.

Identifying a component’s critical events and their sources

Even the most complete service model provides little value if there is not a consistent flow of events into the model to maintain the real-time status of its components. Event associations provide the mechanism for a component’s real-time status to reflect the health of the actual resource that it represents.

Identifying a component’s critical events and their sources


To create the event associations for a component, you must

■ identify the event classes that will be associated with the component ■ establish a naming convention for the logical ID (a key value) so that the same

identification string can be derived from each event class to be associated with the component

You perform event analysis to achieve these goals.

Assuming that there is enough event data consistently available to understand the state of IT resources, perform the following actions:

1 Analyze the event flow of each real IT resource or group of resources that are instrumented in the same way to identify:

■ events that provide no value to the service model

Not all events received by a cell provide valuable information to the service model. Identify the events that are of no value and should be ignored, either by not sending them to a cell or by filtering them out when they reach the first cell.

■ events that provide valuable information about the service environment and must be retained by the cell, such as:

— events that must be changed or adapted either at the source or in the event adapter that collects them to be usable by the model

— events that must be enriched by the cell so that they contain the required information; events can be enriched using Refine and New rules

— events that must be processed (using a Regulate rule) so that only the appropriate occurrences reach the service model

— events that should be combined through abstraction, correlation, or through New rule updates before entering the service model

This includes events that are best represented by a single higher-order event that represents their net effect or represented by event pairs, such as UP/DOWN.

■ missing events or events that cannot be processed

Some situations that you may want to include in your model are not traced by events in the real environment, or the events produced cannot be associated with the IT resource.

2 For each significant event, determine whether the event should be associated only with a component or whether it should also participate in the status computation.

Displaying business key performance indicators (KPIs)


For example, a cause event E1 is associated with the component C1, and a consequence event E2 is associated with the component C2. While it may appear reasonable to elect E1 so that its severity value contributes to the status of C1, electing E2 may be of no use if a relationship propagates the impact of event E1 from component C1 to component C2.

3 Consider how the monitoring tool, such as an agent, adapter, or script, reports the state of the service’s IT resources.

■ Does the monitoring tool send alerts only when something goes wrong?

If so, does it close the alerts automatically?

If the monitoring tool does not close alerts automatically, you may need to automate their closure through rules containing the appropriate cycle and conditions.

■ Does the monitoring tool send status-type events, such as ok or not ok, at regular intervals?

■ Does the monitoring tool handle component availability with some form of heartbeat?

■ When does the IT component representing the resource transition from AVAILABLE to UNKNOWN or from AVAILABLE to UNAVAILABLE, and back again?

■ What is the reliability of the event flow?

Even the most complete service model is of little value if a consistent flow of events into the model cannot be maintained. When creating new event propagation paths, you should take care to consider whether you can improve or, at least, not affect event flow.

Displaying business key performance indicators (KPIs)

When an external source sends an event with a business metric to the cell, after the event is associated to a component, you use a rule to transfer the value and the unit to the component in the business_data slot in the MC_SM_COMPONENT class.

To insert data into the business_data slot, you use the action sim_operations.set_business_data. (For a published CI, you cannot directly modify the business_data slot in BMC Atrium CMDB.) Figure 3 shows an example of the action.

Service model design considerations


To update the business_data slot, you create a rule or a policy. Figure 4 shows an example rule (in the mc_smc_associate.mrl file).

Service model design considerationsThis section contains information to keep in mind when designing your service model, including information on cell topology, component property updates, and component deletions.

Determining cell topology for the service model

There are three basic approaches to cell topology:

■ centralized■ domain-based■ layered

The centralized (default implementation) approach is to implement the service model on one cell, with all the service management objects created and maintained in that cell. Then, use distributed cells to collect and process the raw events of interest before they enter the model.

Figure 3 Inserting KPI data into the business_slot with an action

action sim_operations.set_business_data:{

[‘Service Administrators’,’Service Operators - Senior’,’Service Operators’]

} [‘business_data’: STRING($business_data)] :MC_SM_COMPONENT ($A){

$A.business_class=$business_data;}

END

Figure 4 Updating KPI data with a rule

new associate_kpi:<EVENT_CLASS_NAME ($EV) where [$EV.mc_smc_id != ‘’]

using {MC_SM_COMPONENT ($COMP) where [$COMP.mc_udid == $EV.mc_smc_id]} triggers

{$COMP.business_data = <an expression that builds kpi from $EV>;

# uncomment the following if you want to drop these events# if ($EV.mc_sm_impact = != 1) then# {# drop_new;# }

}END

Component property updates


The domain-based approach separates the service model into two or more parts that correspond to clearly established entities or domains in the organization. Each part is run on a different cell, and users connect to the cells on which the components that they manage reside. Lines of business and independently operated sites are good candidates for this approach. With this approach, you can represent some resources in more than one cell, provided that the event flow is directed or propagated correctly.

The layered approach separates the service model into two or more stratified management layers, such as IT components and logical components. Each layer is contained in a different cell, or possibly distributed among several cells if geography is a factor.

Component property updates

The cell updates the status of a component as new events are received or when an impact from other components occurs.

However, other component properties that can change over time are not maintained by the cell. You can update these properties automatically only if the new values arrive in an event or are added in a data table. You must create a few simple rules to implement this mechanism.


C h a p t e r 44 Understanding a service model

A BMC service model is made up of

■ data classes that describe the various types of physical and logical IT resources that make up an enterprise’s business

■ corresponding data classes in the BMC ProactiveNet KB of cells

■ event classes associated with specific resources

■ configuration items (CIs) that represent the unique physical and the logical CIs that deliver business services

■ impact relationships

■ management data instances

Sources of service model objectsThe cell can receive service model objects (components and relationships) from several different sources:

■ BMC Atrium CMDB using BMC Impact Model Designer■ BMC ProactiveNet Administration Console■ pposter and mposter CLI commands■ Master Rule Language (MRL)■ third-party repository

Data that you send from any given environment must be updated and deleted in the context of that environment. You can determine the source of a selected or specified service model object in the cell in one of the following ways:

Sources of service model objects


■ BMC ProactiveNet Administration Console—on the Services Editor tab, select a component and click the General subtab. The source of the object is displayed by the Master Repository property.

■ mquery command— the command returns the publish_env_id slot with the slot value PublishOriginID.PublishEnvID, where PublishOriginID is the source of the object (for example AtriumCMDB.PROD).

The source of the service model data determines the method of delivery into the cell, as described in Table 7.

Table 8 describes some of the advantages and disadvantages of the different sources for service model data.

Table 7 How service model objects get to a cell

Source for service model objects How objects are delivered to a cell Delivery method name

BMC Atrium CMDB objects are discovered using discovery tools or you create them using BMC Impact Model Designer; they are reconciled by the BMC Atrium CMDB Reconciliation Engine, and then automatically published to the cell using the publishing server

Atrium Publish Feed

BAROC source file you create a BAROC source file of object data and send it to the cell using the pposter CLI command, which publishes the data to the cell using the publishing server

Direct Publish Feed

you create a BAROC source file of object data and send it to the cell using the mposter CLI command

source Direct Feed

MRL rule you create a rule that adds objects to the cell on receipt of a trigger event

tool direct feed

BMC ProactiveNet Administration Console

you create service models using the Administration Console of BMC ProactiveNet Performance Management

source direct feed

Rules for service model data modification and deletion


Rules for service model data modification and deletion

For published service model data, changes and deletions are restricted to the original source of the data. Objects delivered to the cell from BMC Atrium CMDB must be edited and deleted in BMC Impact Model Designer (or BMC Atrium CMDB) and objects from the pposter CLI command must be changed and deleted using a BAROC source file and pposter.

Published data is protected from modification or deletion by any form of Direct Feed. In other words, while published components are visible in BMC ProactiveNet Performance Management.

If you first create a CI using pposter and later publish that CI (same ComponentAlias) from BMC Atrium CMDB, then the DirectPublish CI is replaced by a AtriumCMDB CI. If you first create a CI from publish from BMC Atrium CMDB then try to modify it via pposter, this fails because the DirectPublish environment is not the source of the CI.

Table 8 Advantages and disadvantages of different object sources

Object source Advantages Disadvantages

BMC Atrium CMDB ■ handles large, complex service models

■ accepts objects from discovery tools

■ sophisticated GUI to create, edit, and delete objects, and dynamic prioritization

■ data is protected from uncontrolled edits

■ customizable permissions are available

■ complex to implement■ time factor to discover or

create, reconcile, and publish objects

BAROC file with the pposter CLI command

■ easy to set up a simple service model quickly

■ managed by the publishing server, so data is protected from uncontrolled edits

■ useful only for small, simple models

■ BAROC file must be created to exact standards

■ requires knowledge of CLIs

MRL rule ■ handles highly dynamic changes

■ only practical for special circumstances

■ may not build complete model

■ no primary copy in external datastore

Direct Publish Feed ■ validation of the service model is off-loaded from the cell, preventing cell processing performance degradation

Using the BMC Atrium CMDB as a source of service model data


Using the BMC Atrium CMDB as a source of service model data

When service model component and relationship data is stored in BMC Atrium CMDB, you can use BMC Impact Model Designer to create and manage service models.

Using BMC Impact Model Designer, you can build and maintain a service model with component objects, and manage your service model environment. You can then use the publishing server to publish service model data to the cells and manage publish environments.

Your service model can come solely from BMC Atrium CMDB or you can add objects to it from other sources.

For more information about creating service models using BMC Atrium CMDB, see the BMC Atrium CMDB User's Guide.

Using Direct Feed

A direct feed source of service model data is any application, executable, script, or rule that sends service model data directly to the cell.

Sending service model data to the cell from the mposter CLI command, or MRL rules is enabled by default. This is controlled in the mcell.conf configuration file by the ServiceModelDirectFeed parameter, which is set to Y (yes) by default. To disable Direct Feed, change this parameter setting to N (no).

Since Direct Feed is enabled by default, when a cell starts, the service management data is loaded.

Management data that comes from DirectFeed cannot be referred to by a service model that is published. Publication fails if the referred management data is not published.

Precedences

Data published from BMC Atrium CMDB automatically overwrites Direct Feed data. Between Direct Publish and Direct Feed data, Direct Publish data has a higher precedence and hence overwrites Direct Feed data. Events that are attached to lower precedence CIs are automatically reattached to overwriting CIs of higher precedence.

Service components


Data overrides other data with a lower precedence if

■ it has the same key slots or ■ in the case of a MC_SM_COMPONENT, when it has the same alias

Different system sources like pposter, BMC Performance Manager, and BMC Atrium CMDB must not create data with the same mc_udid.

Overriding rules

When data X, for example, has precedence pX with key slot values that collide with existing data Y with precedence pY, such that pY < pX, then Y is deleted; otherwise the addition of X fails.

These key slot collision rules apply to BMC ProactiveNet data and relationships (the keys of a relationships are the provider_id and consumer_id). Do not modify key slots.

Data modification or deletion is allowed only when the publish environment ID of the requester matches the publish_env_id of the data. In addition to these rules, extra operations are performed when overriding, modifying, or deleting CIs to ensure the uniqueness of each alias and to avoid (local) relationships with dangling ends.

Service componentsThis section contains overview information about components classes and types, types of service CIs, and component statuses.

Component classes and types

A class is the definition or metadata that describes an object type. The class includes information about the object type, such as attributes, primary key, and so on. You can view a list of subclasses or child classes that are associated with a class.

A service component class is a CDM class that is available for inclusion in a service model. These are the only classes visible in BMC Impact Model Designer. Some classes of objects are not visible because they do not make sense in a service model (for example, BMC_Keyboard).

Service configuration items


A service component type is a data class that defines a logical or physical asset that participates in the delivery of a business service. Service components can represent a hardware component, an application, a service, customer groups, or any aspect of business for which you want to employ service impact management.

Service components are organized in a hierarchy of classes in which each class represents a component type. The farther down the hierarchy a particular class occurs, the more specific its type.

When you define a new service model component, you must create it using a subclass of the BMC_BaseElement class. Select the most appropriate subclass for each component that you want to create. If an appropriate subclass does not exist or is too generic, you can extend the class hierarchy by adding a new subclass definition to the BMC Atrium CMDB Class Manager. You can also extend an existing class definition by adding one or more slots to store component-specific information.

Classes and their creation are covered in detail in the BMC Atrium CMDB Installation and Configuration Guide.

Service configuration items

In BMC Impact Model Designer, a configuration item is a specific, unique occurrence of a component type. A component type is the generic object: for example, server. The CI is the specific, unique version of the type: for example, JBoxxServer 123. You select one of the component types from the Templates dockable window and modify that template to create a CI that defines a specific logical or physical asset.

All service model classes and related slots are stored in the server/etc/default/SIM/kb directory. For a description of data class definitions that support the service model, see Appendix B, “Default service model data classes.”

Component status and substatus

A service CI is characterized by its status, which is indicated by the color of the component’s icon in the Operations Console of BMC ProactiveNet Performance Management.

Information about the status of a CI is stored in the cell in the instance’s status slot. The initial status of a service CI, just after its creation, is determined by the default value of its class-level status slot (usually this value is green or OK). For more information about the default service component status values, see the BMC ProactiveNet User Guide.

Component status computation


Component status computation

The status of a CI is computed automatically by the cell when new conditions occur, such as

■ a new event is received that has a direct impact on the component■ the severity of an event impacting a component changes■ another component’s status change is propagated to the component

Whether the status of a component is influenced directly by events, by other components’ status changes, or both, depends on the component’s type and its relative position in a particular service infrastructure. For example, the status of an IT component usually reflects the associated resource events that directly impact its status. In contrast, logical components such as applications or business groups rely on their relationships to IT components to provide their current status.

The cell computes a component’s status using a status computation model that you assign to the CI in the StatusModel attribute. Based on the specific status computation model, the cell uses an algorithm to calculate the

■ status values propagated by inbound relationships■ severities of direct events associated with the service CI■ impact status and service component self-status

The predefined status computation models available are Standard, Cluster, Weighted Cluster, and Self-Preferred.

The Weighted Cluster status computation model uses the Status Weight attribute of the BMC_Impact object. Status Weight is used in impact relationships to determine how much importance (numerically weighted) to give to each provider relationship that impacts a consumer instance. The higher the number, the greater the importance.

You can select the status computation model for each CI in the Edit Component Properties dialog box, on the Status and Alias tab, in the Status Computation list. BMC Impact Model Designer ensures that each CI is associated with a valid status computation model. For information about the Edit Component Properties dialog box, see “To specify attributes for configuration items”.

For more information about component status computation and status computation models, see Chapter 7, “Component and relationship status propagation”.

NOTE Whether and how the status of a provider component is propagated through a relationship is controlled by the relationship policy assigned to the CI.

Service model component types


Service model component typesTable 9 lists the component types, the superclass of the component, the icon that represents the component, and the class of the component as defined in the data model. These classes are derived from the class BMC_BaseElement.

Table 9 Service model component types (part 1 of 7)

Component superclass Icon Component type Component class

Logical Entity BMC_LogicalEntity

Activity BMC_Activity

Activity Decision BMC_ActivityActivityType=ActivityDecision

Activity End BMC_ActivityActivityType=ActivityEnd

Activity Interaction BMC_ActivityActivityType=ActivityInteraction

Activity Manual BMC_ActivityActivityType=ActivityManual

Activity Start BMC_ActivityActivityType=ActivityStart

Business Process BMC_BusinessProcess

Business Service BMC_BusinessService

Database BMC_DataBase



Collection BMC_Collection

User Community BMC_UserCommunity

Connectivity Collection BMC_ConnectivityCollection

IP Connectivity Subnet BMC_IPConnectivitySubnet

IPX Connectivity Network BMC_IPXConnectivityNetwork

BMC_LNsCollection BMC_LNsCollection

LAN Network BMC_LAN

WAN Network BMC_WAN

Organization BMC_Organization

System BMC_System

Access Server BMC_ComputerSystem PrimaryCapability=Access Server

Application BMC_Application

Application Infrastructure BMC_ApplicationInfrastructure

Application System BMC_ApplicationSystem

Cluster BMC_Cluster





System BMC_System

Communication Server BMC_SoftwareServer SoftwareServerType=Communication Server

Computer System BMC_ComputerSystem

Configuration Management Agent

BMC_SoftwareServer SoftwareServerType=ConfigMgmtAgent

Database Server BMC_SoftwareServer SoftwareServerType=DataBaseServer

DNS Server BMC_SoftwareServer SoftwareServerType=DNSServer

File Server BMC_ComputerSystem PrimaryCapability=File Server

Firewall BMC_ComputerSystem PrimaryCapability=Firewall

FTP Server BMC_SoftwareServer SoftwareServerType=FTPServer

Gateway BMC_ComputerSystem PrimaryCapability=Gateway

Hub BMC_ComputerSystem PrimaryCapability=Hub

Input/Output Device BMC_ComputerSystem PrimaryCapability

JBOD (Just a Bunch Of Disks) BMC_ComputerSystem PrimaryCapability=JBOD

Layer 3 Switch BMC_ComputerSystem PrimaryCapability=Layer 3 Switch



p

mp



System BMC_System

LDAP Server BMC_SoftwareServer SoftwareServerType=LDAPServer

Load Balancer BMC_ComputerSystem PrimaryCapability=LoadBalancer

Mail Server BMC_SoftwareServer SoftwareServerType=MailServer

Mainframe BMC_Mainframe

Message Server BMC_SoftwareServer SoftwareServerType=MessageServer

Mobile User Device (a hand-held personal data assistant (PDA))

BMC_ComputerSystem PrimaryCapability=Mobile User Device

Monitor BMC_Monitor

Print Server BMC_ComputerSystem PrimaryCapability=Print

Print Server BMC_SoftwareServer SoftwareServerType=PrintServer

RAID Storage Device BMC_ComputerSystem PrimaryCapability=RAIDStorageDevice

Resource Server BMC_SoftwareServer SoftwareServerType=ResourceServer

Router BMC_ComputerSystem PrimaryCapability=Router

SAN Bridge BMC_ComputerSystem PrimaryCapability=SANBridge





System BMC_System

SAN Director BMC_ComputerSystem PrimaryCapability=SANDirector

SAN Hub BMC_ComputerSystem PrimaryCapability=SANHub

SAN Router BMC_ComputerSystem PrimaryCapability=SANRouter

SAN Switch BMC_ComputerSystem PrimaryCapability=SANSwitch

Security Server BMC_SoftwareServer SoftwareServerType=SecurityServer

Server BMC_ComputerSystem PrimaryCapability=Server

Software Server BMC_SoftwareServer

Storage BMC_ComputerSystem PrimaryCapability=Storage

Switch BMC_ComputerSystem PrimaryCapability=Switch

Tape Library BMC_ComputerSystem PrimaryCapability=TapeLibrary

Telnet Server BMC_SoftwareServer SoftwareServerType=TelnetServer

Transaction Server BMC_SoftwareServer SoftwareServerType=TransactionServer

UDDI Server BMC_SoftwareServer SoftwareServerType=UDDIServer



p



System BMC_System

Virtual System BMC_VirtualSystem (deprecated as of BMC Atrium CMDB version 7.5.00)

Web Cache BMC_ComputerSystem PrimaryCapability=Web Caching

Web Server BMC_SoftwareServer SoftwareServerType=WebServer

System Service BMC_SystemService

Application Service BMC_ApplicationService

System Component BMC_SystemComponent

Hardware System Component BMC_HardwareSystemComponent

Media BMC_Media

CD ROM Drive BMC_CDROMDrive

Disk Drive BMC_DiskDrive

Floppy Drive BMC_FloppyDrive

Tape Drive BMC_TapeDrive

Uninterruptible Power Supply (UPS)

BMC_UPS





System Component BMC_SystemComponent

Logical System Component BMC_LogicalSystemComponent

File System BMC_FileSystem

Database Storage BMC_DataBaseStorage

Local File System BMC_LocalFileSystem

Remote File System BMC_RemoteFileSystem

Disk Partition BMC_DiskPartition

Software BMC_Software

System Software BMC_SystemSoftware

Operating System BMC_OperatingSystem

Virtual System Enabler BMC_VirtualSystemEnabler

VMware BMC_VMWare (deprecated as of BMC Atrium CMDB version 7.5.00)

System Resource BMC_SystemResource



Component relationships


Component relationshipsService management relationships are impact relationships.

Table 10 lists the main relationship classes derived from BMC_BaseRelationship, of which only BMC_Impact defines impact relationships for a service model.

Service consumers and providers

A service model relationship is a link between a component that provides a service and the components that consume that service. In a provider/consumer relationship, the provider status naturally impacts the consumer status. When you define relationships in a service model, you make it possible to know, for example, which business services are affected if Router C fails.

NOTE Only BMC_Impact relationships are considered, or used, by the BMC ProactiveNet cell.

Table 10 Main relationship classes

Class name Class description

BMC_Impact The BMC_Impact relationship, and the subclasses that derive from this class are used to define service impact relationships between CIs.

BMC_Dependency BMC_Dependency describes component relationships that are dependent on each other. This is different from impact relationships in that a dependency can be at a lower direct level, while an impact is often at a higher, more indirect level.

BMC_Component BMC_Component is used to define composite objects. One key component relationship in the CMD is between the system and system component classes. This relationship defines a composite computer system, which is made up of a computer system instance, and subinstances of disk drives, monitors, software, network cards, and so on.

BMC_MemberOfCollection BMC_MemberOfCollection is used to define groupings of instances in a logical manner. It is used to define the network topology, or to define the set of CIs that make up a business process or service.

BMC_ElementLocation BMC_ElementLocation ElementLocation associates a ManagedElement with a Location for positioning, inventory, maintenance and similar purposes.

Service consumers and providers


The concepts of provider and consumer are relative to the relationship being considered. In Figure 5, Component B is a provider in one relationship and a consumer in another.

Figure 5 Impact (status) propagation in relationships

The service model enables a CI to be related to another CI by defining the relationship in the BMC_Impact class. Such a relationship states that a CI is impacted if something happens to the CIs to which it is related. For example, a group of people responsible for accounting will be impacted when the accounting database server is down.

Service model relationships are organized in a hierarchy of data classes in which each class represents a relationship type.

The parent class for component relationships is BMC_Relationship. All service model relationship classes are defined in the BMC Atrium CMDB as a subclass of BMC_Relationship.

NOTE From version 7.6.03 of BMC Atrium CMDB onwards, BMC_Impact is an attribute of all relationship classes.

Status propagation in relationships


Important components

Some components can be considered “important” components and can be set to propagate their priority back to their provider. For more information about priority propagators, see Chapter 7, “Component and relationship status propagation”.

Status propagation in relationships

Status propagation is the passing of a status or a modified status from one CI to another through a relationship. Depending on the status propagation model assigned to the relationship, the cell can automatically propagate the status of a provider component through its outbound impact relationships as new conditions occur, such as

■ the component’s status changes■ the state of an outbound impact relationship changes, altering the status

propagation from the provider component

This status can then be propagated to subsequent components within the service model.

The service model ensures that each impact relationship instance is associated to a valid status propagation model.

For more information about status propagation and status propagation models, see Chapter 7, “Component and relationship status propagation”.

Relationship states

Just as a component is characterized by its status, a relationship is characterized by its state. Relationship state values are defined internally in the cell as the enumeration MC_SM_RELATIONSHIP_STATE.

A relationship can be either active or inactive, as shown in the following table:

Relationship state value Meaning

ACTIVE The consumer component depends on its provider. An impact relationship exists.

INACTIVE The consumer does not have a dependency, or the dependency is unimportant. No impact relationship exists.

Relationship control


In status propagation models, the state of a relationship determines whether the provider’s status or a modification of it is passed to the consumer service component.

Status propagation models

A propagation model defines how the status of a provider component must be propagated in an impact relationship, based on

■ the current state of the relationship (active or inactive)■ the current value of the provider’s status

Status propagation models are used only by impact relationships. The role of the BMC_STATUS_PROPAGATION class instance is to restrict the use of a propagation model to consumer and provider relationships.

Status propagation models serve these purposes:

■ relationship control—Propagation models enforce logical rules in new component relationships so that only valid relationships are created.

dynamic status mapping—Propagation models translate the computed status of the provider component into a propagated status for input into the impact_function slot of the related consumer component.

Relationship control

Relationship control is the enforcement of logical rules in creating new service model relationships. The BMC_STATUS_PROPAGATION table defines the valid pairs of component types whose instances can participate in a specific type of relationship.

Each time an impact relationship instance is submitted for creation, the cell seeks an BMC_STATUS_PROPAGATION instance that matches

■ the name of the propagation model used by the component relationship■ the component type of the provider in the relationship■ the component type of the consumer in the relationship

During this process, the cell uses the component’s class hierarchy to interpret the component types in the BMC_STATUS_PROPAGATION instances. If there is a matching BMC_STATUS_PROPAGATION instance, the relationship is valid. Otherwise, the creation process is blocked.

Service schedules


Service schedulesService schedules are a combination of a defined schedule with a specific service model component that indicates when the component must meet availability or performance goals. Each component is assigned a service schedule (but it can be a schedule shared with other components).

■ Periods when a CI is in high demand, or when it must meet its availability and performance goals, are called During Schedule (During High Demand Timeframes).

■ Periods when a CI is in low demand, or when the component’s s availability and performance are less important, are called Off Schedule (During Low Demand Timeframes). Also, any undefined time is considered Off Schedule.

■ Periods within During Schedule in which a component is considered to be Off Schedule are called Exceptions Within During Schedule.

Component attributes such as cost or base priority might have different values depending on whether the component is in high demand (a During Schedule period) or in low demand (an Off Schedule period). These priority changes are discussed in more detail in the “Dynamic prioritization” section.

Timeframes

Service schedules are built of timeframes. Timeframes are blocks of time that specify the times that are During Schedule or Exceptions Within During Schedule. Two types of timeframes exist: Global and Local.

■ Global timeframes are created in the BMC Impact Model Designer, stored in the BMC Atrium CMDB and are available to all cells within an environment. You create global timeframes and use them in both BMC Impact Model Designer and the BMC ProactiveNet Performance Management.

■ Local timeframes are stored in a single cell and are only available to the event management policies within that cell. You create local timeframes and use them only in the BMC ProactiveNet Performance Management schedules editor.

Service schedules example with exceptions


Table 11 illustrates the differences between global timeframes and local timeframes.

Service schedules example with exceptions

Consider a component that is expected to meet its performance goals from 8 A.M. to 5 P.M. each day. This period is would be considered During Schedule. The same component, if not needed from 5 P.M. to 8 A.M. each day, would be Off Schedule during that time.

Within the During Schedule period, if the component is scheduled to be taken offline every day from noon to 1 P.M., instead of creating two different During Schedule timeframes (one for 8 A.M. to noon, and another from 1 P.M. to 5 P.M.), you could create an Exceptions Within During Schedule timeframe.

Table 11 Global and Local timeframe differences

Timeframe type Created in Stored in Available to

Global BMC Impact Model Designer

BMC Atrium CMDB all cells

Local BMC ProactiveNet Performance Management

a single cell event management policies within a single cell

Chapter 5 Understanding a service model created in BMC Impact Model Designer 57

C h a p t e r 55 Understanding a service model created in BMC Impact Model Designer

Role of the BMC Atrium CMDB in service modeling

The BMC Atrium Configuration Management Database (BMC Atrium CMDB) is a multi-component database that enables applications to store and share data. Service model developers and administrators use the BMC Atrium CMDB Configuration Console and BMC Atrium CMDB Class manager APIs to build and modify the Common Data Model (CDM).

With the BMC Atrium CMDB you can divide your configuration data into partitions called datasets, each containing configuration items (CIs) and relationships for a given purpose. This makes it possible for the same component or relationship instances to exist in more than one dataset.

Datasets provide a mechanism for storing raw data from multiple resources in discrete locations. Then the reconciliation process takes that data and merges it appropriately to create a composite set of unique data instances that includes information from each source, based on what each source is proficient at obtaining. The ability to capture the raw data from various sources and reconcile it to a controlled dataset enables the interaction between various automation tools.

Service model and the Common Data Model



The Common Data Model (CDM) is an extensible class schema that represents CIs and their relationships to each other in an IT enterprise. It is designed to store asset data (as hardware, service management, and user information) and to provide a mechanism for linking that information to provide a complete view of how all elements of a company are connected and can affect each other.

All service component types (classes) are defined in the BMC Atrium CMDB as part of the CDM. A class is the definition or metadata that describes an object type. The class includes information about the object type, such as attributes, primary key, and so on.

BMC ProactiveNet Performance Management classes

BMC ProactiveNet Performance Management extends the BMC Atrium CMDB CDM with a predefined set of BMC ProactiveNet Performance Management-enabled classes. The asset information you use to define the service model is a subset of all of the configuration data in the CDM. The BMC ProactiveNet CMDB Extensions also define attributes that are used only for BMC ProactiveNet Performance Management, such as StatusModel and ImpactCostPerSec.

All components in the data model derive from a single subclass, BMC_BaseElement and all relationships derive from the BMC_BaseRelationship subclass. All impact relationships are instances of BMC_Impact. The BMC_Impact subclass of BMC_BaseRelationship is available out-of-the-box as part of the core CDM classes for version 7.5 of the BMC Atrium CMDB CDM.

The following tables list the main data subclasses to BMC_BaseElement that are associated with service impact management. For a graphical representation of the hierarchy of the Common Data Model, see the Common Data Model Diagram included with BMC Atrium CMDB documentation.

Table 12 lists the BMC ProactiveNet Performance Management-qualified subclasses for BMC_Collection, which provides mechanisms for grouping components together into logical elements, including business processes and services.

Table 12 BMC ProactiveNet-qualified subclasses of BMC_Collection

Second Level Third Level Fourth Level

BMC_ConcreteCollection

BMC_ConnectivityCollection BMC_ConnectivitySegmentBMC_IPConnectivitySubnetBMC_IPXConnectivityNetwork

BMC_LNsCollection BMC_LANBMC_WAN



Table 13 lists the BMC ProactiveNet Performance Management-qualified classes for BMC_LogicalEntity, which tracks other logical elements of a system, including people, physical plants, and location information.

Table 13 BMC ProactiveNet-qualified subclasses of BMC_LogicalEntity

Table 14 lists the BMC ProactiveNet Performance Management_qualified classes for BMC_System, which contains the definition of computer systems, mainframes, application systems, and virtual systems.

Table 14 BMC ProactiveNet-qualified subclasses of BMC_System

Table 15 lists the BMC ProactiveNet Performance Management-qualified classes for BMC_SystemComponent, which stores information on the components that comprise the system. This includes physical components like disk drives and monitors; applications like Microsoft Word; and other soft elements like network drives and file shares. The attributes for BMC_SystemComponent are SystemClassId and SystemName.

Table 15 BMC ProactiveNet-qualified subclasses of BMC_SystemComponent

BMC_Organization

BMC_UserCommunity

Second Level Third Level

BMC_Activity BMC_BusinessProcess

BMC_BusinessServiceBMC_Database

Second Level Third Level

BMC_ApplicationSystem BMC_ApplicationBMC_ApplicationInfrastructureBMC_SoftwareServer

BMC_Cluster

BMC_ComputerSystem BMC_MainframePrinterBMC_VirtualSystem


LogicalSystemComponent BMC_ Software BMC_SystemSoftware

BMC_DiskPartitionBMC_SystemResource

BMC_FileSystem BMC_DataBaseStorageBMC_LocalFileSystemBMC_RemoteFileSystem




Table 16 lists the BMC ProactiveNet Performance Management-qualified classes for BMC_SystemSoftware, a continuation of the BMC_SystemSoftware entry in Table 15.

Table 16 BMC ProactiveNet-qualified subclasses of BMC_Software

Table 17 lists the BMC ProactiveNet Performance Management-qualified class for BMC_SystemService, which tracks the services used by systems. The most common services are those used by J2EE application systems, such as J2EE modules. The data model also provides a set of classes for defining relationships among CIs. The attributes for BMC_SystemService are SystemClassId and SystemName.

HardwareSystemComponent BMC_UPS

BMC_Media BMC_CDROMDriveBMC_DiskDriveBMC_FloppyDriveBMC_TapeDrive

Fifth Level Sixth Level Seventh Level

BMC_SystemSoftware BMC_OperatingSystemBMC_VirtualSystemEnabler

BMC_VMWare

Table 17 BMC ProactiveNet-qualified subclass of BMC_SystemService

Second Level

BMC_ApplicationService




BMC ProactiveNet Performance Management attributes

BMC ProactiveNet Performance Management qualifiers have been added to the attributes listed in Table 18.

Table 18 BMC ProactiveNet Performance Management-qualified attributes

Class Namespace Attributes

BMC_BaseElement BMC.CORE AccountID [SIM]Category [SIM, SME_Read, SME_ReadWrite]ClassId [SME_Read, SME_ReadWrite]CMDBRowLevelSecurity [SME_Read, SME_ReadWrite]CMDBWriteSecurity [SME_Read, SME_ReadWrite]DatasetId [SIM, SME_Read, SME_ReadWrite]Description [SIM, SME_Read, SME_ReadWrite]InstanceId [SIM, SME_Read, SME_ReadWrite]Item [SIM, SME_Read, SME_ReadWrite]ManufacturerName [SIM, SME_Read, SME_ReadWrite]MarkAsDeleted [SME_Read, SME_ReadWrite]Model [SIM, SME_Read, SME_ReadWrite]Name [SIM, SME_Read, SME_ReadWrite]Notes [SIM, SME_Read, SME_ReadWrite]OwnerContact [SIM, SME_Read, SME_ReadWrite]OwnerName [SIM, SME_Read, SME_ReadWrite]Priority [SIM, SME_Read, SME_ReadWrite]ReconciliationIdentity [SME_Read, SME_ReadWrite]ShortDescription [SIM, SME_Read, SME_ReadWrite]Type [SIM, SME_Read, SME_ReadWrite]VersionNumber [SIM, SME_Read, SME_ReadWrite]

BMC.AM Site [SIM, SME_ReadWrite]Company [SIM, SME_ReadWrite]Department [SIM, SME_ReadWrite]Floor [SIM, SME_ReadWrite]Region [SIM, SME_ReadWrite]Room [SIM, SME_ReadWrite]SiteGroup [SIM, SME_ReadWrite]

BMC.SIM ReadSecurity [SIM]WriteSecurity [SIM]ComponentAliases [SIM, SME_ReadWrite]ImpactCostPerSec [SIM, SME_ReadWrite]ImpactCostUnit [SIM, SME_ReadWrite]ImpactCostPerSecOut [SIM, SME_ReadWrite]HomeCellAlias [SME_ReadWrite]PriorityWatchdog [SIM, SME_ReadWrite]PriorityOut [SIM, SME_ReadWrite]ScheduleId [SIM, SME_ReadWrite]StatusModel [SIM, SME_ReadWrite]

Sandboxes


The definitions of the BMC ProactiveNet Performance Management qualifiers are

■ SIM: 300050■ SIM_Internal: 300060■ SIM_ReadWrite: 300070

SandboxesA sandbox is a personal work area for designing and developing a service model. You can make changes to objects and their relationships, and save these changes between work sessions, without affecting the production environment until you are ready to move the changes into the production dataset.

BMC_Cluster BMC.CORE ClusterType [SIM, SME_Read, SME_ReadWrite]Interconnect [SIM, SME_Read, SME_ReadWrite]InterconnectAddress [SIM, SME_Read, SME_ReadWrite]MaxNumberOfNodes [SIM, SME_Read, SME_ReadWrite]Types [SIM, SME_Read, SME_ReadWrite]

BMC_ConnectivitySegment

BMC.CORE ConnectivityType [SIM, SME_Read, SME_ReadWrite]

BMC_OperatingSystem BMC.CORE OSType [SIM, SME_Read, SME_ReadWrite]

BMC_VirtualSystem BMC.CORE VirtualSystemType [SIM, SME_Read, SME_ReadWrite]

BMC_WAN BMC.CORE WANType [SIM, SME_Read, SME_ReadWrite]

BMC_ComputerSystem BMC.CORE CapabilityList [SIM, SME_Read, SME_ReadWrite]DomainName [SIM, SME_Read, SME_ReadWrite] Hostname [SIM, SME_Read, SME_ReadWrite]PrimaryCapability [SIM, SME_Read, SME_ReadWrite]SystemType [SIM, SME_Read, SME_ReadWrite]

BMC_SystemComponent

BMC.CORE SystemClassId [SIM, SME_Read, SME_ReadWrite]SystemName [SIM, SME_Read, SME_ReadWrite]

BMC_Media BMC.CORE MaxMediaSize [SIM, SME_Read, SME_ReadWrite]MediaType [SIM, SME_Read, SME_ReadWrite]

BMC_SystemService BMC.CORE SystemClassId [SIM, SME_Read, SME_ReadWrite]SystemName [SIM, SME_Read, SME_ReadWrite]

Table 18 BMC ProactiveNet Performance Management-qualified attributes

Class Namespace Attributes

Datasets


BMC Impact Model Designer users have their own unique, dedicated sandbox, and sandboxes persist between user sessions, allowing you to make multiple edits to the sandbox model until you promote the changes to the production dataset. Each user has one sandbox associated with the user account. Changes to your sandbox do not affect sandboxes of other users if those changes are not promoted.

DatasetsThe production dataset is the reference dataset, or logical partition of data in the BMC Atrium CMDB, shared by service model applications. Objects contained in the production dataset are components, relationships, and management data.

When working with objects in a sandbox, users are making changes to an overlay dataset, a dataset which is related to and masks the production dataset. The overlay dataset provides a view of the underlying production dataset masked by changes made by the user in the overlay dataset.

PromotionYou move changes that you make in a sandbox (on the overlay dataset) to the production dataset in a controlled process called promotion.

When a promotion completes successfully, changes in the sandbox are merged with changes from other users and processes in the BMC Atrium CMDB. As soon as you successfully promote changes to a production dataset, the sandboxes of all other users are updated to reflect the new data.

Promotion and automated publishing process

Promoting and publishing are a sequence, in which you initiate a process to push objects (new or changed) to the BMC Atrium CMDB, followed by the automatic publication process, which sends that data to appropriate BMC ProactiveNet Performance Management cell.

The promotion process is as follows:

NOTE No two users should have the same data (components, impact relationships, or management data instances) in their sandbox because only the values from the sandbox that was promoted last will be in the production dataset.

Service model publishing


■ After making changes in a sandbox View, you start the promotion process from the BMC Impact Model Designer interface.

■ BMC Impact Model Designer initiates a reconciliation job.

After the actual promotion process begins, you cannot work in BMC Impact Model Designer until the process finishes.

■ Promotion log objects are created in the BMC Atrium CMDB. The objects contain a list of objects selected for promotion.

■ BMC Impact Model Designer regularly checks the progress of the reconciliation job. When the process is completed, BMC Impact Model Designer updates the objects and indicates that the promotion is complete.

■ When the promotion has ended, if automated publishing is enabled, the publishing server initiates a publish from the production dataset to the BMC ProactiveNet Performance Management cells in the environment. If other publish operations are underway at that time, the request is queued.

Service model publishingService model publishing is the process of distributing the service model data to BMC ProactiveNet Performance Management cells. After a promotion completes, the publishing server is notified of the termination of a reconciliation and starts a publication. From the BMC Atrium CMDB, the publishing server distributes the BMC.ASSET dataset to the cells.

The publishing server also mirrors the last successful publish to the cells. You can initiate the publishing automatically using BMC Impact Model Designer or manually using the CLI command publish.

When the CIs and relationships are published, you can monitor the CIs by using BMC ProactiveNet Performance Management.

Service model execution on cellsService CIs are associated with events through the use of unique aliases, which you specify for each CI. When events that require alias processing enter the cell, the cell uses the values in the event’s slots to construct an alias and then searches for that alias in the cell’s impact CIs. When a match is found, the event is associated with the CI and the instance’s status may be changed.


C h a p t e r 66 Building a service model in BMC Impact Model Designer

This chapter provides detailed procedures on how to build the service model in BMC Impact Designer.

Service model creation processTo build a service model in BMC Impact Model Designer, you must

■ find or create configuration items (CIs) in BMC Atrium Explorer■ assign CIs to a BMC ProactiveNet Performance Management cell■ define CI relationships ■ assign schedules to CIs■ promote the service model and publish objects to cells

Launching BMC Impact Model DesignerYou can open BMC Impact Model Designer from BMC Remedy AR System:

1. Open a browser and enter the URL in the format http://<AR server mid-tier hostname>:<mid-tier port>/arsys. See the “Launching BMC Impact Model Designer” section for details about this URL.

2. Log on to BMC Remedy AR System.

3. In the Home page, click the Atrium Core Console link on the left side.

4. In the BMC Atrium Core Console page, click Impact Model Designer.

Working with service configuration items


BMC Atrium Core Console is displayed. BMC Impact Model Designer is a part of BMC Atrium Core Console.

Working with service configuration itemsTo populate the BMC Atrium CMDB with CIs for the service models, you can use discovery tools such as BMC Application Discovery and Dependency Mapping, or you can manually create the CIs by using BMC Impact Model Designer. BMC Impact Model Designer provides a GUI to the reconciled dataset in the BMC Atrium CMDB and provides a workspace for you to create service models using the objects from this dataset.

To search for existing CIs, see “Finding configuration items” on page 73.

Creating service configuration items in BMC Impact Model Designer

Use the Classes accordion in BMC Impact Model Designer to create a service CI. The figure below displays the Classes accordion.

NOTE BMC Software recommends creating a maximum of 20,000 service model CIs for each BMC ProactiveNet cell.



Figure 6 Classes accordion

Ensure that you have the service catalog spreadsheet that lists IT components and their relationships. Also, ensure that you have installed all the required software before creating the CI. For a list of the required software, see BMC Atrium CMDB User's Guide.



To create a service configuration item by using the Classes accordion

1 When you open BMC Impact Model Designer, a new asset view opens automatically if you have no saved views.

2 Drag the component type from the Classes accordion to the asset view. When you drag a component, click Yes in the Convert View to Sandbox View dialog box to convert the asset view to sandbox view.

3 In the sandbox view, right-click the new component icon and select Edit.

To specify attributes for configuration items

1 On the General tab, perform the following steps:

A In the Short Description text box, enter a component description that is meaningful to your enterprise.

B In the Name text box, replace the default name for the CI with a specific CI name that is meaningful to your enterprise and that you want to use as the label of the CI in a view.

C In the Cell list, select the cell on which the selected CI gets published.

BMC Impact Model Designer retrieves the list of cell names from the BMC Atrium CMDB. If the cell that you need is not listed, see the BMC ProactiveNet Administrator Guide for information about adding a cell.

D (optional) In the Owner Name text box, enter the name of the individual responsible for the CI.

E (optional) In the Owner Contact text box, enter a contact method, such as a phone number or e-mail address, for the individual.

F In the Publish to BMC ProactiveNet Performance Manager (BPPM) area, select:

■ Inherit if you want the CI to inherit the same mode of publication set for the consumers of the CI. In this case, if even one of the consumers of the CI is set to Yes and Propagate, the CI is also published. Inherit is selected by default.

NOTE A CI is displayed in the sandbox view with the short description attribute instead of the name attribute as its label. You can configure this label to display the name of the CI instead of the short description. To do this, you need to edit the BMC.CORE.CONFIG:BMC_UIComponent form using BMC Remedy Action Request System User (BMC AR User). For more information, see the BMC Atrium CMDB User's Guide.



■ Yes and Propagate to publish not only the CI but also all the providers of the CI to the cell.

■ Yes, Only Me to publish only the currently selected CI to the cell.

■ No to not publish the CI to the cell and to not publish the CI's providers.

2 On the Status and Alias tab, perform the following steps:

A In the Status Computation list, select a status computation model.

The default selection is Standard, which is acceptable for most CI definitions. For more information about status computation models, see Chapter 7, “Component and relationship status propagation”.

B In the Aliases text box, click Add Alias.

Each CI must have a unique alias; if more than one CI has the same alias, publishing fails.

— In the Alias text box, enter the alias and click OK.

— (optional) Enter additional aliases (one for each event that can potentially affect the status of the CI) by clicking Add Alias.

Each alias that you enter is listed in the Aliases box.

3 On the Permissions tab, assign the proper permission to each of the roles listed for this CI.

4 On the Schedule and Priority tab, perform the following steps:

A In the Schedule area, assign the appropriate service schedules information to the CI. For more information, see “Assigning components to service schedules” on page 81.

B In the Priority area, from the Propagate Priority to Providers list:

— Select Yes to have the selected components propagate their self-priority to their causal components.

— Select No (default) if you do not want the self-priority to be propagated.

NOTE Ensure that you select this option for at least the top-level consumer CI in your service model.



C In the Self Priority Function list, select a base priority for the CI.

D In the Priority and Cost by Timeframes area:

— Select a base priority for the high demand and low demand timeframes.

— Enter the cost per second of the high demand and low demand timeframes in the Cost text boxes and the currency of the cost in the Cost Unit text box.

5 The Other tab displays more information about the CI you created. You can enter values for fields not already populated or edit the default values of most fields. Table 19 lists some of the fields on the Other tab. The fields vary depending on the type of CI you created. Fields marked with * are mandatory and have to contain a value.

6 Click OK to save the CI in the BMC Atrium CMDB.

Table 19 Fields on the Other tab

Field Description

Account ID Account to which the CI belongs. Accounts can represent customers, organizations, departments, or other parties to which you want to give access to a limited set of CIs and relationships.

Category User-defined categorization of the CI. Used with the Type and Item attributes.

Company, Department, Region, Room, Floor, Site, SiteGroup

Details of the business associated with the CI.

HomePageURI URL of the Home page of the business.

Item User-defined categorization of the CI. Used with the Category and Type attributes.

ManufacturerName Organization that produced the entity that the CI represents. For example, if the CI represents a Pro Widget 2000, the name of the manufacturer is Acme Widget Company

Model Name by which the entity that the CI represents is known. For example, the model name of an Acme widget might be Pro Widget 2000.

SelfPriorityFunctionParam

Parameter that you can set to determine the priority of a CI.

SerialNumber Manufacturer-allocated number used to identify the physical entity that the CI represents.

Type User-defined categorization of the CI. Used with the Category and Item attributes.

VersionNumber Version number of the physical entity that the CI represents.

Notes Displays additional information if any about the CI. Click Details to view the complete details.

Switching sandbox view modes


Where to go from here

Continue creating CIs until you have a number of CIs that are related, and then see “Defining relationships between configuration items” on page 74.

To learn more about working with CIs (viewing, editing, copying, deleting, and finding), continue with the next section.

Switching sandbox view modes

In the sandbox view, you can switch between a model-based view of components that displays the components in a hierarchical graph and a table-based view that displays the components in a table that includes properties. Components selected in either mode remain selected after you switch to the other mode.

You can switch modes by clicking the appropriate toolbar icon, as shown in Table 20.

Editing configuration items

You can change properties (attributes) of a CI by using the Edit Component Properties dialog box.

If the CI is already being edited, a warning dialog is displayed. Though you are not locked-out of editing the CI, it is recommended that you wait until the edit is complete before proceeding.

Table 20 View mode switch icons

Icon View mode

Topology

Table

Hiding configuration items


To modify the properties of configuration items

1 Right-click the CI and select Edit from the context menu. The Edit Component Properties dialog box is displayed.

2 Make the appropriate changes. For more information about the Edit Component Properties dialog box, see “To specify attributes for configuration items” on page 68.

3 Click OK.

Hiding configuration items

You can hide a CI so that it is not visible in the current active view. BMC Impact Model Designer does not delete a hidden CI that has been published to a cell. You can retrieve the hidden CI by using the Find command.

To hide a configuration item

■ Right-click the CI that you want to hide and select Remove From View.

The selected CI is removed from the active view, but are still visible in other views in which they have been saved. If they are a part of the service model, they remain in the service model.

Deleting configuration items

When you delete a CI in a view:

■ Components in the BMC.ASSET (in the BMC Atrium CMDB) that are marked as deleted (MarkAsDeleted) are not visible in BMC Impact Model Designer.

■ Components in your sandbox that are marked as deleted appear in BMC Impact Model Designer with an “X” icon.

■ Components that are new in the sandbox (that have no copy in BMC.ASSET yet) are physically deleted from the sandbox.

NOTE

I

If you want only to remove a CI from your view without deleting it permanently, use the Remove From View command as described in “Hiding configuration items” on page 72.

Finding configuration items


To delete a configuration item

1 Right-click the CI you want to delete and select Delete from Database.

2 Verify that you want to delete the CI and click OK.

3 On the toolbar, click the Promote Sandbox Changes icon.

4 In the Promotion Preview Dialog dialog box, review the objects to be promoted to ensure that the CIs that you want to delete are listed.

5 Click Promotion.

The deleted CIs are removed from the service model and are no longer available in the BMC Atrium CMDB.

Finding configuration items

You can search the BMC Atrium CMDB for existing CIs by using the Find command. Only CIs associated with classes that are designated for impact management in the BMC Atrium CMDB can be found in the BMC Impact Model Designer. For information about designating classes in service impact management, see the BMC Impact Solutions Knowledge Base Development Reference Guide.

The search procedure described below searches for CIs in the BMC.ASSET view.

You cannot search for relationships with the Find command, but when related CIs are found and placed in a view, their relationships are also placed in the view. To view the relationships, right click the CI and select Expand Parents or Expand Children.

To find existing configuration items

1 Click the Find accordion on the left pane of BMC Impact Model Designer.

2 In the Quick Search of all CIs area, you can search on the basis of the name or description of the CI. You can also enter a partial name by using the % sign as a wildcard before the partial name, after it, or both (for example, %Sales%, Sales%, or %Sales).

To display a list of all CIs, leave the text boxes blank and click Search.

The result of the search is displayed next to the search query. To sort the values in any column, click the column heading. To change the order of the columns from left to right, drag the column headings.

Defining relationships between configuration items


To find configuration items in your sandbox

1 Click the Find accordion on the left pane of BMC Impact Model Designer.

2 Click the Options icon on the Find toolbar.

3 From the Dataset menu, select Sandbox for <user_name>.

4 Click OK.

Defining relationships between configuration items

Impact relationships define how status propagation is passed from the provider CI to the consumer CI. An active relationship is an impact relationship and indicates that the status of the CI depends on the status of the connected provider instance. An inactive relationship means that no dependency exists or that the dependency is irrelevant to the model; in either case, an impact relationship does not exist.

Whenever the status of the provider instance changes, it is propagated to the connected consumer CI.

For each CI for which you are creating relationships, you must know

■ whether it is a consumer or a provider for the related component■ its relationship state value (active or inactive)■ its status propagation model value (relationship policy)

After you have created relationships, test them to verify that they function in the way that you intended.

Creating and editing component relationshipsFor information about creating and editing component relationships, see the BMC Atrium CMDB User's Guide at http://webapps.bmc.com/support/faces/prodversion.jsp?prodverseqid=176447.

Associating events with a configuration item


Associating events with a configuration itemWhen an event is received by a cell, it is associated with the CI through alias formulae loaded on the cell. You can use the Alias Formulas Editor dialog box to define the formulae. For more information about alias formulae, see the BMC ProactiveNet Administrator Guide.

Working with timeframes and service schedules

You can edit service schedules using the Schedules and Timeframes icon of BMC Impact Model Designer. Schedule information is stored in the BMC Atrium CMDB.

If you do not select a schedule for a CI, the CI will have a default schedule of 24 x 7 x 365 (always in schedule).

After creating service schedules, you can assign components to schedules in the Edit Component Properties dialog box as described in “Assigning components to service schedules” on page 81.

The Full Access, Service Administrators, and Service Managers user groups have access to the schedule editor.

Icons used in the service schedule and timeframes dialog box

Table 21 contains descriptions of the functions of icons used in the Schedules And Timeframes dialog box.

Table 21 Schedules and timeframes icons

Icon Function

Create a new service schedule or timeframe.

Edit the selected service schedule or timeframe.

Copy the selected service schedule or timeframe.

Working with timeframes



Service schedules are built from timeframes that you can create and edit using the Schedules and Timeframes icon on the toolbar.

Figure 7 Edit Timeframe dialog box

Shows the usage of components assigned to the selected service schedule or timeframe. Opens the Schedules/Timeframe dialog box that respectively lists the schedules and timeframes currently associated with the CI.

Delete the selected service schedule or timeframe.

Table 21 Schedules and timeframes icons

Icon Function



Table 22 provides descriptions of the fields in the Edit Timeframe dialog box.

To create or edit a timeframe

1 On the toolbar, click the Schedules and Timeframes icon.

2 In the Schedules and Timeframes dialog box, on the Timeframes tab, click the New icon to create a new timeframe or click the Edit icon to edit an existing timeframe.

3 In the New Timeframe/Edit Timeframe dialog box, enter or modify the appropriate information in the available fields.

For more information about the Timeframe Edit dialog box, see Table 22, “Timeframe Edit field descriptions,” on page 6-77.

4 Click Save to save the timeframe and make it available for use in the Edit Schedule dialog box.

To copy a timeframe


2 In the Schedules and Timeframes dialog box, on the Timeframes tab, select a timeframe to copy.

3 Click the Copy icon.

Table 22 Timeframe Edit field descriptions

Name Name of the timeframe.

Description Description of the timeframe.

Start, End Time period for the beginning and end of the timeframe. Select Duration from the End list to set the duration of the timeframe. Alternatively, select Time from the End list to set the end period for the timeframe.

Recurrence pattern Defines the frequency in which the timeframe recurs. If you select a recurrence pattern on the left side, the list on the right changes according to the selection you made.

Besides the Daily, Weekly, Monthly, and Yearly timeframe options, you can select individual dates that are part of the timeframe by selecting Date List and choosing dates from the displayed calendar.

Range of recurrence Defines the start and end range of dates for the recurrence. Instead of choosing an end date, you can also enter the number of occurrences for the timeframe.

Working with service schedules


4 In the Copy Timeframe dialog box, modify the fields for the copied timeframe as appropriate. The copied timeframe name is appended with the prefix “Copy of.”

For more information about the fields, see Table 22, “Timeframe Edit field descriptions,” on page 6-77.

5 Click Save.

To list the service schedules and components that are associated with a timeframe


2 In the Schedules and Timeframes dialog box, on the Timeframes tab, select a timeframe.

3 Click the Show Usages icon.

The Timeframe - Components and Schedule dialog box displays a list of the components and schedules currently associated with the timeframe.

— To view components associated with the selected timeframe, click the Components tab.

— To view service schedules containing the selected component, click the Schedules tab.

4 Click Close.

To delete a timeframe


2 In the Schedules and Timeframes dialog box, on the Timeframes tab, select a timeframe to delete and click the Delete icon.

To view the schedules that use a given timeframe, click Show Usages.

3 Click Delete in the Delete Confirmation dialog box to confirm the action.

The selected timeframe is deleted.


You create and modify service schedules in BMC Impact Model Designer using the New Schedule/Edit Schedule dialog box as shown Figure 8.



Figure 8 Edit Schedule dialog box

To create or edit a service schedule


2 In the Schedules and Timeframes dialog box, on the Schedules tab, click the New icon to create a new service schedule or click the Edit icon to edit an existing service schedule.

3 In the Edit Schedule dialog box, enter or modify the appropriate information in the fields, as shown in Table 23.

Table 23 Edit Schedule field descriptions

Name Name of the service schedule to create or edit.

Usages (button) Opens the Schedules: Components assigned to this schedule dialog box that lists the components and component descriptions currently associated with the selected schedule.



4 Click Save.

To copy a service schedule


2 In the Schedules and Timeframes dialog box, on the Schedules tab, select a service schedule from the list.

3 Click the Copy icon.

4 In the Copy Schedule dialog box, modify the fields for the copied service schedule as appropriate.

5 Click Save.

Description Description of the service schedule.

Timeframes in this Schedule Information on the timeframes that are a part of the service schedule, and also which timeframes are high demand, low demand and which timeframes are available.

Any time period not part of a service schedule is considered off schedule.

High Demand Timeframes, at the left, contains timeframes during which the associated components exist in the service schedule period (as opposed to being off schedule). You can add or remove timeframes from this list by using the arrows between the timeframes.

Available Timeframes, at the center, contains timeframes that are available to be added to the high demand or low demand timeframes periods. You can create a new a timeframe to include in the Available Timeframes list by clicking the New icon below the list. You can also edit timeframe in the list by clicking Edit.

For information on the creating or editing timeframes, See “Working with timeframes” on page 6-76.

Low Demand Timeframes, at the right, contains timeframes during which the associated components are treated as off schedule even though the time exists within the high demand period.

Table 23 Edit Schedule field descriptions

Assigning components to service schedules


To display the configuration items that are associated with a service schedule


2 In the Schedules and Timeframes dialog box, on the Schedules tab, select a service schedule from the list.

3 Click the Show Usages icon.

The Schedules: Components assigned to this schedule dialog box displays a list of the components currently associated with the selected schedule and the description of the component. You can view associated components on the Components tab and associated service schedules on the Schedules tab.

4 Click Close.

To delete a service schedule


2 In the Schedules and Timeframes dialog box, on the Schedules tab, select a service schedule to delete and click the Delete icon.

A Delete Confirmation dialog box is displayed, informing you that after deletion, all components using the deleted schedules will be assigned to the default schedule.

To view the CIs that are associated with a given service schedule, on the Schedules tab, click Show Usages. See “To display the configuration items that are associated with a service schedule” on page 81.

3 Click Delete.

After creating service schedules, you can assign components to these schedules.

Assigning components to service schedules

You can assign one or more components to service schedules by using the Schedule and Priority tab in the Edit Component Properties dialog box. For more information on this tab, see “To specify attributes for configuration items” on page 68.

Granting permissions to individual service model objects


Granting permissions to individual service model objects

To grant permissions to individual configuration items

1 Right-click the CI and select Edit.

2 In the Edit Component Properties dialog box, on the Permissions tab, select the appropriate options.

By default, Unassigned is selected for all user groups. That is, the CI is visible to all user groups. If you, for example, select the Full Access option for the Full Access and Service Administrators role and the Unassigned option for the rest of the roles, the CI is visible only to users belonging to the Full Access and Service Administrators role. Users belonging to other roles will not be able to view the CI.

3 Click OK.

Promoting the service modelAfter promoting CIs in BMC Impact Model Designer, these changes are stored in the production dataset (BMC.ASSET) in the BMC Atrium CMDB and are automatically published (by default) to the assigned cells.

About the publishing process

Promotion and publishing are decoupled. Promotion is initiated and controlled from BMC Impact Model Designer, while publication is controlled by the publishing server.

NOTE When you modify user access permissions in the BMC Impact Model Designer, they are effective immediately. For the changes to appear in BMC ProactiveNet Performance Management, they must be promoted from BMC Impact Model Designer and you must then log out and then log on to BMC ProactiveNet Performance Management. For permissions at the CI (component) level, you need not log out and log on to BMC ProactiveNet Performance Management.

Before you promote


There are two modes of running the publishing server:

■ In automated mode, by default, publication is initiated by the completion of a reconciliation job run, such as after a promotion.

■ In manual mode, publication is initiated from CLI commands.

Note that a successful promotion does not guarantee that the automated publication will also be successful.

During the publishing of a service model, new or modified service model components and their relationships are selected from the BMC.ASSET dataset in the BMC Atrium CMDB and copied to respective BMC ProactiveNet Performance Management cells. The objects in BMC.ASSET are compared to any previously published instance in BMC.ASSET and the changes between them are sent to the cell. BMC.ASSET is then updated with the changes.

After events that affect service CIs are received by the cell, you can monitor status changes using BMC ProactiveNet Performance Management for the published CIs.

Before you promote

To ensure a successful promotion and publication of the service model, verify that:

■ each CI is assigned to a cell■ all target cells that are registered in BMC ProactiveNet Performance Management

are running and have a live connection with the publishing server.■ the publishing server is running in automated mode by using the CLI command ■ the BMC ProactiveNet Performance Management class definitions are in sync. The

publishing server validates the class definitions and establishes a live connection with BMC ProactiveNet Performance Management, the BMC Atrium CMDB, and the cells before submitting the publication. For information on synchronizing class definitions, see “Exporting class definitions from the BMC Atrium CMDB to cells” on page 85.

Submitting a promotion

When you submit a promotion, the Promotion Preview dialog box offers the opportunity to compare your unpromoted sandbox service model CIs and relationships with those that have already been promoted so that you can verify the work done in the current editing session. When you click Promotion, service model objects (CIs, impact relationships, and management data) shown in the preview are promoted (and subsequently automatically published).

Verifying promotion status


To promote all sandbox configuration items and relationships

1 On the toolbar, click the Promote Sandbox Changes icon to start the promotion.

2 In the Promotion Preview dialog box, in the Instances to be Promoted area, you can filter the list of objects according to CIs or relationships or both. When you filter the list, it only affects what is visible, not what will be promoted. All items are promoted. You can click a CI to view its details in the right pane.

3 In the right pane, review the list of attributes for the selected CI. You can use the Show list to view only those attributes that have been edited or all attributes.

4 Click Promotion.

After a successful promotion, the publication of the service model is triggered. Publication may take some time depending on the size and load of the service model.

To view the status of the publication (if the publication is a success or a failure):

■ Run the pshowlog command from the system in which the publishing server is installed.

■ View the publish history from the BMC ProactiveNet Administration Console. For information about this, see the BMC ProactiveNet Administrator Guide.

Verifying promotion status

After you submit a promotion request, you can view its status in the Promotion in Progress dialog box that displays after a promotion is requested.

Table 24 Icons in Objects-to-be-Published pane

Column heading Icon Description

Action object was deleted

object was added

object was modified

Type component

relationship

Modifying and deleting service model data


After the promotion process completes, a dialog box will display indicating whether the promotion succeeded or failed.

Modifying and deleting service model dataFor published service model data, changes and deletions are restricted to the original source of the data. Objects delivered to the BMC ProactiveNet cell from BMC Atrium CMDB must be edited and deleted in BMC Impact Model Designer (or BMC Atrium CMDB) and objects from the CLI command pposter must be changed and deleted using a BAROC source file and pposter.

Published data is protected from modification or deletion by any form of Direct Feed. In other words, while published components are visible in BMC ProactiveNet Performance Management, you cannot change or delete them with a rule or the mposter command.

If you first create a CI via a pposter and later publish that CI (same ComponentAlias) from BMC Atrium CMDB, then the DirectPublish CI is replaced by a BMC Atrium CMDB CI. If you first create a CI from publish from BMC Atrium CMDB then try to modify it via pposter, this fails because the DirectPublish environment is not the source of the CI.

Exporting class definitions from the BMC Atrium CMDB to cells

To synchronize classes from BMC Atrium CMDB to the cells, run the following CLI command on the system in which the publishing server is present:

pclassinfo -x -o mc_sm_object.baroc.

Exporting class definitions from the BMC Atrium CMDB to cells



C h a p t e r 77 Component and relationship status propagation

About component and relationship statusThe status of a component can be influenced by the propagated status of its provider components. Status computation models calculate the new value of component status using these factors.

A status computation model’s primary role is to associate an algorithm with each of the status computation functions. The model can be applied to one or more configuration items (CIs), enabling the cell to handle status computation appropriately for those objects.

The BMC_STATUS_COMPUTATION data class is the basis of all status computation model instances. The service model provides status computation models to support the definition of key component classes.

How component status computation worksThe cell computes component status automatically as new conditions occur, such as the reception of a direct impact event, or a status change on a provider component that results in a state change on an inbound relationship.

To compute component status, the cell uses the status computation model assigned to a CI. The cell obtains the name of the status computation model to use from the instance’s StatusComputationModel slot.

Status computation functions


Based on the type of condition that triggered the status computation, the cell selects the appropriate function to use from the status computation model. It also obtains the algorithm to use with the function to calculate the appropriate status for the component. Then, the cell calculates the new component status.

Status computation functions

The following functions perform status computation:

■ impact_function■ self_function■ consolidate_function

Table 25 lists the functions, their inputs, and the type of computed status that each function calculates.

All the functions return a status value in the range of the MC_SM_COMPONENT_STATUS enumeration.

Only the cell maintains the real-time status of components. Component status is not reflected in the BMC Atrium CMDB.

The CI’s status is set to the computed_status except when you set the component to manual status, in which case, the CI’s status is set to manual_status.

Table 25 Status computation functions and computed component statuses

Function Description Inputs Output

impact_function computes the impact status from status propagated by provider components

status values propagated by inbound relationships

impact_status

self_function computes the self_status from direct events

severities of direct events associated with the component

self_status

consolidate_function computes the component’s computed_status from impact_status and self_status, or both, or from the no_alert_status of the status computation model

the impact status and the self-status

computed_status

Status computation algorithms


Status computation algorithms

The status computation algorithms that are used by the status computation functions, use the cell's internal algorithms, such as HIGHEST_VAL. Defining a status computation model includes associating the appropriate algorithm with each function. The algorithms are:

Highest Val—Using this algorithm, a function returns the highest value among those it receives as input. In general, the higher the value, the less desirable it becomes. For example, the highest value for the status of a component is 70 (UNAVAILABLE).

Average—(impact_function only) Using this algorithm, impact_function returns the average status of the propagated status values.

Quorum—(impact_function) This impact_function returns the smaller status value among the highest values propagated by a quorum of incoming active relationships. The number of active relationships that constitute a quorum correspond to the quorum value of the status model multiplied by the total number of incoming active relationships divided by 100 (rounded up to the next integer if necessary).

Weighted—Status weight is an attribute (StatusWeight) of the BMC_Impact object, requiring an integer value. It is used in impact relationships to determine how much importance (numerically weighted) to give to each provider relationship that impacts a consumer instance. A higher numerical value indicates a greater importance.

Self-Preferred—(consolidate_function) computed_status is set to the self_status value except when the self_status is NONE.

How status computation algorithms work

Table 26 shows the type of value that a component status computation function returns when using an available algorithm.

Table 26 What a function returns when using an available algorithm

Function Algorithm Returns

self_function HIGHEST_VAL the highest value among the severities of the direct events, after they have been automatically mapped to component status values

About status computation models


About status computation models

In BMC Impact Model Designer, for each CI, you select one of the predefined status computation models: Standard, Cluster, Weighted Cluster, and Self-Preferred. Standard is the default status computation model.

The BMC_STATUS_COMPUTATION data class is the basis of all status computation model instances.

impact_function HIGHEST_VAL the highest value among the status values of the provider components

AVERAGE the average status of the provider components after weighting each status value, where the “weight” is the number of providers propagating this particular status divided by the total number of providers propagating a status

QUORUM the computed impact status is the lowest status that is propagated by the quorum percentage of providers (ignoring relationships propagating NONE)

consolidate_function HIGHEST_VAL the higher value between the impact status and the self-status

SELF_PREFERRED the self_status value except when the self_status is NONE. In this case, the computed_status is set to the no_alert_status value of the status computation model (by default OK).

Table 27 Description of predefined status computation models

Status computation model Description

Standard computes the status of a component using the HIGHEST_VAL impact_function; the impact_status is the highest propagated_status of the incoming relationships

Cluster computes the status of a component using the QUORUM impact function (see “Quorum algorithm examples” on page 91)

Weighted Cluster computes the status of a component using the Status Weight attribute of the BMC_Impact object

Status Weight is used in impact relationships to determine how much importance (numerically weighted) to give to each provider relationship that impacts a consumer instance. The higher the number, the greater the importance.

Self-Preferred computes the status of a component using the self-preferred algorithm for the consolidation_function

Table 26 What a function returns when using an available algorithm

Function Algorithm Returns

Anatomy of a status computation model


Anatomy of a status computation model

A status computation model defines the following:

■ the algorithm used by each of the functions involved in status computation■ a no-alert status value that applies only when the consolidate_function returns

NONE. The no-alert status is acceptable for all the default status computation functions.

■ a quorum percentage that applies only when the impact_function uses the QUORUM algorithm

■ an external algorithm that applies only when the impact_function uses the EXTERNAL placeholder

The internal status NONE

The status value NONE is an internal status only used in the component status computation function. The main status of a component should never have a value of NONE. For this reason, the following results apply to situations in which there is no input to a function or the input value is NONE.

Quorum algorithm examples

The CLUSTER option for Status Computation uses the QUORUM impact function, which is described below.

When you create a quorum type of StatusModel, you specify a percentage, called the quorum percentage. The quorum value is given by the quorum slot of the BMC_STATUS_COMPUTATION instance.

Function Input value Output value

impact_function Component has no inbound relationship.

NONE

Inbound relationships propagate NONE as a status.

NONE

self_function No events are associated with the component.

NONE

consolidate_function Impact status value is NONE and self-status value is NONE or there are no inputs.

default no-alert status value from the status computation model

Quorum algorithm examples


The impact_status is the highest propagated_status that a quorum percentage of provider agree upon.

An easy computation of the quorum status can be done as follows:

■ There are n providers with propagated_status different from NONE: let i be the lowest integer that is greater or equal to quorum*n/100.

■ Consider the array of propagated_status ordered from highest to lowest status.■ The impact_status is the status corresponding to the element i of this array.

Relationship status propagation concepts


Relationship status propagation conceptsThe cell performs status propagation for relationships and it relies on the status propagation model associated with each impact relationship instance.

EXAMPLE CASE A website 1 (quorum-based component status computation)host1host2

Example A1QUORUM=50, host1=OK, host2=IMPACTED

50*2/100 = 1 => i = 1array = [IMPACTED, OK]The percentage of hosts that are not AVAILABLE is 50%, which breaches the quorum threshold, so the status of website 1 is IMPACTED.

Example A2QUORUM=51, host1=OK, host2=IMPACTED

1 < 51*2/100 < 2 => q = 2 array = [IMPACTED, OK]

The percentage of hosts that are not AVAILABLE is 50%, which does not breach the quorum threshold, so the status of website 1 is OK.

Example A3QUORUM=51, host1=MINOR, host2=IMPACTED

1 < 51*2/100 < 2 => q=2 array = [IMPACTED, MINOR]There is indeed at least 51% of the providers (actually 100%) that state a severity at least MINOR, so the status of website 1 = MINOR

CASE B website 2 (quorum-driven, impact-based component status computation)host1host2host3host4

Example B1quorum_percent=30, host1=OK, host2=OK, host3=OK, host4=Minor

1<30*4/100<2=>q=2array = [MINOR, OK, OK, OK]The percent of hosts that are not UNAVAILABLE is 25%, which is less than 30%, so the status of website2 is OK.

Example B2quorum_percent=30, host1=OK, host2=OK, host3=UNAVAILABLE, host4=MINOR

1 < 30*4/100 < 2 => q = 2 array = [UNAVAILABLE, MINOR, OK, OK]There is at least 30% (actually 50%) of the providers that state a severity of at least MINOR, so the status of website 2 is MINOR.

Example B3quorum_percent=60, host1=MINOR, host2=OK, host3=UNAVAILABLE, host4=UNAVAILABLE

2 < 60*4/100 < 3 => q=3 array = [UNAVAILABLE, UNAVAILABLE, MINOR, OK]There is at least 60% (actually 75%) of the providers that state a severity at least MINOR, so the status of website 2 = MINOR

How status propagation works


Each status propagation model must have a unique name to identify it. You can create as many status propagation models as needed to control component status propagation. The name of a single BMC_STATUS_PROPAGATION refers to multiple BMC_PROPAGATION_MAP instances all of which have the same name (a one-to-many relationship). Each BMC_PROPAGATION_MAP instance defines how a provider component status is propagated over a relationship to the consumer component.

For example, for the INCREASING status propagation there will be a number of propagation map instances each of which increases the status propagated by a provider component to a consumer component. So, if a provider has status MINOR the status propagated over the relationship to the consumer will be IMPACTED. This would be a single propagation map instances - one is needed for each status.

How status propagation works

The cell automatically propagates the status of CIs through its outbound relationships as new conditions occur, such as a status change on the component or a state change on an outbound relationship. Status propagation is based on impact relationships and status propagation models.

The role of a status propagation model is to define the status value to be propagated in all possible situations. That model can then be applied to one or more impact relationship instances, enabling the cell to handle status propagation appropriately for those objects.

When a status change on a CI triggers a status propagation, the cell takes the main status (status slot value) of the component, retrieves each outbound impact relationship with its associated state and its status propagation model, and searches the propagation map for a matching entry. The result is the propagated_status value, which is passed as an input to the impact_function of each consumer component.

When a state change on an outbound impact relationship triggers a new status propagation for that CI, the cell combines the main status of the component with the retrieved state and the status propagation model of the relationship, and searches the propagation map of the status propagation model for a matching entry. The result is the propagated_status value that is then passed as an input to the impact_function of the consumer component.




A propagation model defines how the status of a provider component must be propagated in an impact relationship based on

■ the current state of the relationship■ the current value of the provider’s status

Status propagation models are used only by impact relationships.

Status propagation models serve the following purposes:

■ relationship control—enforcement of logical rules in creating new component relationships so that only valid relationships are created

■ dynamic status mapping—translating the main status of the provider component into a propagated status for input into the impact_function of the consumer component in a relationship

The impact_function is part of the status computation of a component. For more information, see “Anatomy of a status computation model” on page 91.

Default status propagation models

The service model provides the following default status propagation models:

■ DIRECT—consumer component depends on the provider’s services to the extent that its status is the same as the provider’s

■ INCREASING—consumer component is overly dependent on the provider. When a problem occurs, the consumer’s status degrades faster than the provider’s does

■ DECREASING—consumer component can function without provider’s services. When a problem occurs, the consumer’s status is less degraded than the provider’s

■ JUST_WARNING—propagates the status of a provider component so that any value less than OK maps to NONE, OK maps to OK, and any value greater than OK maps to WARNING

■ JUST_INFO—propagates the status of a provider component so that any value less than INFO maps to NONE, and any value greater or equal to INFO maps to INFO

What is a valid status propagation model?


Table 28 describes the how status propagation occurs for a specific model.

What is a valid status propagation model?

A valid status propagation model is a BMC_STATUS_PROPAGATION instance, complemented with the appropriate number of BMC_PROPAGATION_MAP instances, all sharing the same name. A BMC_STATUS_PROPAGATION instance is not created if the supporting BMC_PROPAGATION_MAP instances have not yet been created.

Table 28 How status propagation models work in relationships

Status propagation model Relationship state Result

DIRECT ACTIVE propagates the provider’s status without modification to the consumer

INACTIVE propagation of the provider’s status is blocked by mapping the provider’s status to NONE

This value is ignored by the consumer.

INCREASING ACTIVE increases the impact of the provider’s status on the consumer’s status



DECREASING ACTIVE decreases the impact of the provider’s status on the consumer’s status



JUST_WARNING ACTIVE for statuses greater than OK, WARNING is propagated



JUST_INFO ACTIVE for statuses greater than or equal to INFO, INFO is propagated; for statuses less than INFO, NONE is propagated



Important service components


A valid status propagation model must have:

■ 8 instances of the data class BMC_PROPAGATION_MAP, one for each possible provider component status value for the ACTIVE state

■ 8 instances of the data class BMC_PROPAGATION_MAP, one for each possible provider component status value for the INACTIVE state

■ 1 instance of the BMC_STATUS_PROPAGATION data class that defines the propagation model’s attributes

Important service componentsImportant service components are components with self_priority slot values that affect the overall impact_priority slot value of their root cause component(s). Root cause components propagate their status values forward to the important service components that they impact. In return, the self_priority slot values of the important service components are propagated back to their respective root cause component(s). Figure 9 depicts this relationship.

Dynamic prioritization


Figure 9 Propagation paths between root cause and important components

Component A is considered as a root cause of component B if

■ A.status > OK■ A.status > A.impact_status

and there is no other such component in the true impact path from A to B.

Dynamic prioritizationDynamic prioritization is a system of setting the priority of a component to help you understand what problems to work on first, based on whether a component is in demand at the time (as defined in its service schedule), the severity of its status, and its impacts.

The final priority of a component is determined by comparing the component’s self priority and impacts priority.

Self priority


The greater value becomes the final priority value of the component.

Self priority

Self priority is a dynamic priority that changes depending on

■ the status of the component■ the schedule status associated to the component (during or off schedule)■ and one of the following three methods of priority computation:

■ base priority (default) ■ cost ■ worst SLA state

Both the cost and the worst SLA state methods rely on the concept of down time. A component is considered down from a cost/SLA perspective when its status is greater or equal to a specified value. This value is stored in the slot status of the BMC_DOWNTIME_STATUS_CONFIG BAROC table.

Figure 10 Self priority determination

NOTE Normally, only one instance of this table should ever exist. If several instances exist, the instance with the lowest status is used.

Self priority


Base priority method

Base priority is the default method for computing self priority. Self priority is determined by mapping the current base priority (depending on whether the component is on or off schedule) against the status value of the component.

Enabling the base priority method

The base priority method is enabled by default. To specify the base priority method if the default has been changed, modify MC_SM_COMPONENT class to set the SelfPriorityFunction slot to the value BASE_PRIORITY.

How the base priority method calculates priority

Each component has two base priority values:

■ the High Demand Schedule priority, which is the priority assigned to the component during the peak hours of its schedule stored in the Priority slot

■ the Off Schedule priority, which is the priority assigned to the component during the hours that are not critical for its operation stored in the PriorityOut slot

For example, if the component is a server that supports a business that is open from 8:00AM to 6:00PM, then the higher High Demand Schedule priority would be applied to the server during the hours that the business is open and the Off Schedule priority would be applied to the server when the business is closed (6:00PM to 8:00AM).

The base priority values are static priority values that act as a baseline to determine self priority.

Cost method

The cost method determines priority based on the actual cost of a component being down. Cost is a user-specified monetary value per unit of time—for example, $5.00US per second. The more money it costs for a component to be down, the higher priority that component will have.

NOTE The cost of a component is always computed if the During/Off schedule cost values are set for that component, whether or not the cost method is used to determine the self priority of that component.

Self priority


Creating a BMC_COST_OF_DOWNTIME_PRIORITY_MAPPING instance

The cost model, concomitant cost values, and the mappings between cost values and the severity levels of the self_priority value are user defined. The cost value is typically defined as cost per unit of time: for example, the value 5 can indicate $5.00 per second of downtime.

When you create an instance of the BMC_COST_OF_DOWNTIME_PRIORITY_MAPPING, you specify the cost parameter as a date type REAL as shown:

Enabling the cost method

To enable the cost method, you must modify the following slots in the MC_SM_COMPONENT class:

■ Self_Priority_Function=COST

■ Self_Priority_Function_Param=name of the cost of downtime priority mapping group (a mapping group is made of a varying number of BMC_COST_OF_DOWNTIME_PRIORITY_MAPPING instances sharing the same name)

How the cost method calculates priority

Each component has two cost values:

■ the During Schedule cost, which is the cost assigned to the component during the peak hours of its schedule. This value is stored in the ImpactCostPerSec slot.

■ the Off Schedule cost, which is the cost assigned to the component during the hours that are not critical for its operation. This value is stored in the ImpactCostPerSecOut slot.

Depending on whether the component is in the During Schedule or Off Schedule time frame, the cell copies one or the other of these values to the slot cost.

The cost method first checks to determine if the component is down as specified by the down time definition in SIM_DOWNTIME_STATUS.

BMC_PUBLISH_DATA_CLASS :BMC_COST_OF_DOWNTIME_PRIORITY_MAPPING ISA BMC_SIM_DATADEFINES {name: STRING, key=yes;cost: REAL;self_priority : MC_PRIORITY, key=yes;};END

Self priority


If the cost status is less than the SIM_DOWNTIME_STATUS, then the component is not considered to be down, and its self priority is set the lowest priority (PRIORITY_5). Otherwise, the BMC_COST_OF_DOWNTIME_PRIORITY_MAPPING table is used to determine the self_priority value as follows:

Let c be the cost of the component and n be the name of a mapping stored in the SelfPriorityFunctionParam slot of the component.

If there is an instance i in this table with

■ name = n■ cost = costi

■ self_priority = priorityi

■ such that costi < c

and there is no other instance j with

■ such that costj > costi and costj < c

then the self_priority of the component is set to priorityi.

If there is no such instance, the self_priority of the component is set to the lowest priority (PRIORITY_5).

The status enumeration values for the cost method are stored in the SIM_DOWNTIME_STATUS_CONFIG table in the mc_sm_root.baroc file of each cell.

Self priority


Figure 11 Cost priority method of priority determination

Cost method example

In this example, the SelfPriorityFunction of the component definition is set equal to COST and the name of the mapping value is test_cost.

BMC_System;mc_udid=comp_r3_c2;Name=comp_r3_c2;SelfPriorityFunction=COST;SelfPriorityFunctionParam=test_cost;PriorityWatchdog=YES;ImpactCostPerSec=5.0;ImpactCostPerSecOut=1.0;END

Self priority


This series of mapping table examples associate different cost values with corresponding self_priority values in ascending order, with 4 as the least severe and 1 as the most severe.

Based on the sample test_cost mapping table, if the status is UNAVAILABLE (or at least greater than or equal to the SIM_DOWNTIME_STATUS) then

■ during schedule the cost is 5.0 and self_priority maps to PRIORITY_2■ off schedule the cost is 1.0 and self_priority maps to PRIORITY_4

BMC_COST_OF_DOWNTIME_PRIORITY_MAPPING;name=test_cost;cost=1;self_priority=PRIORITY_4;END




Self priority


Worst SLA state method

The worst SLA state method determines priority based on the Service Level Agreement (SLA) for a component. Each SLA is tracked separately within a specified time period, such as daily or weekly. The SLA states are rolled up for the specified period and the worst SLA state is given priority. The rolled up SLA states are stored in the sla_rollup_status slot. Possible SLA states are:

■ NO_SLAS■ COMPLIANT■ AT_RISK■ BREACHED

The SLA state for each component is assigned by BMC Service Level Management.

Creating a BMC_WORST_SLA_STATE_PRIORITY_MAPPING instance

When you create an instance of the BMC_WORST_SLA_STATE_PRIORITY_MAPPING, you specify the sla_state parameter as belonging to the enumeration type MC_SM_SLM_SLA_STATUS as shown:

The enumeration MC_SM_SLM_SLA_STATUS is defined as follows:

NOTE The worst SLA state method can be used only if you are using the BMC Service Level Management product.

NOTE The sla_rollup_status of a component is always computed if there is at least one service target associated to that component, whether or not the worst SLA method is used to determine the self priority of that component.

MC_PUBLISH_DATA_CLASS :BMC_WORST_SLA_STATE_PRIORITY_MAPPING ISA BMC_SIM_DATADEFINES {name: STRING, key=yes;sla_state: MC_SM_SLM_SLA_STATUS;self_priority : MC_PRIORITY, key=yes;};END

ENUMERATION MC_SM_SLM_SLA_STATUS0 NO_SLAS10 COMPLIANT20 AT_RISK30 BREACHEDEND

Self priority


Enabling the worst SLA state method

To enable the cost method, you must modify the following slots in the MC_SM_COMPONENT class:

■ Self_Priority_Function=WORST_SLA_STATE

■ Self_Priority_Function_Param=name of the worst SLA state priority mapping group (a mapping group is made up of a varying number of BMC_WORST_SLA_STATE_PRIORITY_MAPPING instances sharing the same name)

How the worst SLA state method calculates priority

To use the cost method to determine priority of a component, set its SelfPriorityFunction slot to the value WORST_SLA_STATE.

The worst SLA state method first determines if the component is down according to the down time definition in SIM_DOWNTIME_STATUS_CONFIG.

If the cost status is less than the SIM_DOWNTIME_STATUS, then the component is not considered to be down, and its self priority is set the lowest priority (PRIORITY_5). Otherwise, the BMC_WORST_SLA_STATE_PRIORITY_MAPPING BAROC table is used to determine the self_priority value as follows:

Let s be the value stored in the sla_rollup_status slot of the component and n be the name of a mapping stored in the SelfPriorityFunctionParam slot of the component.

If there is an instance i in this table with

■ name = n■ sla_state = s■ self_priority = p

then the self_priority of the component is set to p.

If there is no such instance, the self_priority of the component is set to the lowest priority (PRIORITY_5).

The status enumeration values for the worst SLA state method are stored in the SIM_DOWNTIME_STATUS_CONFIG table in the mc_sm_root.baroc file of each cell.

Self priority


Figure 12 Worst SLA method of priority determination

Worst SLA state method example

This series of mapping table examples associate different sla_state values with corresponding self_priority values arranged in ascending order. In this example, 5 is the least severe and 2 indicates a greater severity.

BMC_WORST_SLA_STATE_PRIORITY_MAPPING;name=test_sla;sla_state=NO_SLAS;self_priority=PRIORITY_5;END

BMC_WORST_SLA_STATE_PRIORITY_MAPPING;name=test_sla;sla_state=COMPLIANT;self_priority=PRIORITY_5;END

BMC_WORST_SLA_STATE_PRIORITY_MAPPING;name=test_sla;sla_state=AT_RISK;self_priority=PRIORITY_2;END

BMC_WORST_SLA_STATE_PRIORITY_MAPPING;name=test_sla;sla_state=BREACHED;self_priority=PRIORITY_1;END

Impacts priority


In this example, the Self_Priority_Function of the component definition is set equal to WORST_SLA_STATE and the name of the mapping value is test_sla.

Impacts priority

The impacts priority of a component reflects the urgency of resolving a problem based on the components it impacts.

The impacts priority is based on the components it is impacting that are marked as priority propagators. A component which is a priority propagator can be considered an “important” component in that a priority propagator sends its self priority value back to its causal component, which can have the result that the causal component’s problem is considered a more urgent problem than it would have been otherwise.

Thus, the impacts priority is a dynamic value which changes as the self-priorities of the impacted components change.

Figure 13 Impacts priority determination

BMC_System;mc_udid=compx;Name=compx;SelfPriorityFunction=WORST_SLA_STATE;SelfPriorityFunctionParam=test_slaPriorityWatchdog=YES;END

Determination of final priority



The final priority of a component is the highest value between the self priority and impacts priority, as illustrated in Figure 14 on page 110.



Figure 14 Final priority determination

How cost impact is calculated


How cost impact is calculated

The cell propagates the cost of important components to their root causes (causal components). Root cause components aggregate the cost of all their impacted important components by summing their cost into the impact_cost slot.

How SLA impact is calculated

The cell propagates the sla_rollup_status of important components to their root causes (causal components). Root cause components aggregate the sla_rollup_status of all their impacted important components by propagating the highest value into the impact_sla_rollup_status slot.

NOTE If the cost and sla_rollup_status data are available for an important service component, then these values are always propagated downward to the impact_cost and impact_sla_rollup_status slots of its causal component(s), even if the corresponding cost or worst SLA method is not used to determine the self priority of that important service component.

How SLA impact is calculated



C h a p t e r 88 Managing BMC Impact Model Designer

Service Management administration is performed in large part within BMC Impact Model Designer and its supporting data classes, with some administration also being done in the BMC ProactiveNet Performance Management.

Administration includes managing all user access to information contained in the service model. Access control is managed in the service model through individual configuration items (CIs). Each component has a ReadSecurity and WriteSecurity set of attributes, and each attribute can be associated with a user group that can be assigned either read or write access to a component.

Adding new classes to BMC Atrium CMDBAll superclasses of a BMC ProactiveNet class, up to BMC_BaseElement, need to be BMC ProactiveNet classes, regardless of whether they are abstract or concrete. For detailed information about creating classes and defining custom icons for class instances, see the BMC Atrium CMDB Administrator’s Guide.

Making your changes visible to applications

When you add classes and attributes to your data model, they are not automatically picked up by BMC Software products that use the BMC Atrium CMDB, such as BMC ProactiveNet Performance Management or BMC Remedy Asset Management. You must modify new classes and attributes so they can be used with these applications.

Making your changes visible to applications


BMC Remedy AR System applications

Some BMC Remedy AR System applications, such as BMC Remedy Asset Management, maintain their own set of join forms for viewing and modifying BMC Atrium CMDB instance data. The BMC Atrium CMDB now has the ability to generate attribute fields for such an application and arrange the fields according to view templates specified by the application. For information about using this feature, see the BMC Atrium CMDB Installation and Configuration Guide.

BMC ProactiveNet Performance Management

While updating BMC ProactiveNet Performance Management to use new classes and attributes, note the following information about classes:

■ Classes with the custom qualifier 100050 are BMC ProactiveNet-enabled classes. Instances with this property are pushed by the publishing server to the cells.

■ BMC ProactiveNet-enabled class definitions in the BMC Atrium CMDB and the class definitions in the BMC ProactiveNet cell must match.

■ For your new class to be a service model component class, not only does the new class need to be BMC ProactiveNet-enabled (having the class custom qualifier value of 100050), its superclasses, whether concrete or abstract, up to the root class (such as BMC:BaseElement, BMC:BaseRelationship) must be BMC ProactiveNet-enabled as well.

■ BMC Impact Model Designer filters out abstract classes.■ The new class inherits the attributes of its superclass.

Note the following information about attributes:

■ BMC ProactiveNet-enabled attributes have the custom qualifier 300050.■ The publishing server pushes attribute values to the cells.

Perform the following steps to update BMC ProactiveNet Performance Management to use new classes and attributes:

1 Using the Class Manager, add these custom qualifiers to the new classes and attributes:

■ Classes: 1\100050\2\1\

■ SMEReadWrite attributes: 2\300050\2\1\300070\2\1\

2 Add custom icons for new classes.

3 From BMC Impact Model Designer, export cell metadata by running the command in “Exporting class definitions from the BMC Atrium CMDB to cells” on page 85.

Creating a new service model component class in the BMC Atrium CMDB


4 Restart BMC Impact Model Designer by restarting Apache Tomcat. For information about restarting Apache Tomcat, see the BMC ProactiveNet Getting Started Guide.


This section contains steps for creating a new service model component class.

To create a new service model component class in the BMC Atrium CMDB

1 Use the BMC Atrium CMDB Class Manager to create a new CI class. For instructions, see “Modifying the Data Model” in the BMC Atrium CMDB Installation and Configuration Guide.

2 Assign the class to the namespace.It is advised not to add new classes to BMC.CORE or BMC.SIM. User userName should use namespace userName.

3 Select the service model component superclass to which you want to assign the new service model component class.

4 Specify the Custom Qualifier 1\100050\2\1\ in the General tab.

5 Click Save.


C h a p t e r 99 Managing the BMC ProactiveNet Publishing Server

After you create a service model in BMC Atrium CMDB, the service model data must be delivered from the CMDB or the pposter source files to the cells. The process of distributing service impact data from the source to the cells is managed and controlled by the BMC ProactiveNet Publishing Server.

This chapter provides an overview of the BMC ProactiveNet Publishing Server and information on managing it.

BMC ProactiveNet Publishing Server overviewThe BMC ProactiveNet Publishing Server is an application that publishes a service model to the BMC ProactiveNet cell. The publishing server performs the following functions:

■ triggers an automated publication of BMC ProactiveNet data from the BMC Atrium CMDB to cells when any reconciliation job terminates

■ publishes the BMC Atrium CMDB asset service model data to cells on demand

■ stores a master copy of the published service model for service models that originate from the BMC Atrium CMDB in the asset data set

■ publishes data from a BAROC source file to cells on demand

■ exports the class definitions on demand to BAROC files that are ready for distribution to the BMC ProactiveNet cells

BMC ProactiveNet Publishing Server architecture


BMC ProactiveNet Publishing Server architecture

The BMC ProactiveNet Publishing Server receives notification from BMC Atrium CMDB about changes to service model objects, such as by BMC Impact Model Designer. The publishing server retrieves the data from BMC Atrium CMDB and publishes the components to the BMC ProactiveNet cell. Through the BMC ProactiveNet Administration Console, you retrieve components from the cell, or you create and send components to the cell. You monitor components in the BMC ProactiveNet Operations Console.

The following diagram shows the high-level components involved in creating, publishing, and monitoring service model objects.

Figure 15 BMC ProactiveNet Publishing Server architecture

The following components are also part of the publishing server environment. They are used for diagnostics and troubleshooting, and are not shown in the diagram:

■ Notification Engine on BMC Atrium CMDB, which sends the publishing server changed component data

■ Service Model Manager (smmgr) on the cell, which is a service that is started by the cell to assist in publishing

■ Notifications from cell to the JServer service model cache (on the BMC ProactiveNet cell) and from service model cache to the JServer. The notifications synchronize the Operations Console with the JServer, and the Administration Console with the cell.

BMC Atrium CMDB


BMC Atrium CMDB

When service model component and relationship data is stored in BMC Atrium CMDB, you use these products to create and manage service models:

■ BMC Impact Model DesignerPurge activities for BMC ProactiveNet classes■ BMC ProactiveNet Publishing Server, a BMC ProactiveNet service

This is called the publish feed, or AtriumPublish, method of creating and publishing service model objects.

In the BMC Impact Model Designer, you build and maintain a service model with component objects, and manage your service model environment. In the BMC ProactiveNet Publishing Server, you publish service model data to the cells and manage publishing environments. Your service model objects can come solely from BMC Atrium CMDB or you can add objects to it from other sources.

For more information about creating service models using BMC Impact Model Designer, see Chapter 2, “BMC Impact Model Designer user interface.”

Non-Atrium CMDB sources for service model objects

There are several methods you can use to create and publish service model objects without using BMC Atrium CMDB. Non-Atrium methods are any application, executable, script, or rule that sends service model data directly to the cell.

Direct publish API

The direct publish application programming interface uses the BMC ProactiveNet Publishing Server. You can create a BAROC source file of object data and send it to the cell using the pposter CLI, which publishes the data to the cell using the publishing server. This method is useful if you have a third-party repository that contains your service model. You can extract your model into BAROC format and use the publishing server to feed your model to one or more cells.

Direct feed API

Using the direct feed application programming interface, you create a BAROC source file of object data and send it to the cell using the mposter CLI. Sending service model data to the cell from BMC ProactiveNet Administration Console, the CLI command mposter, or MRL rules is enabled by default. Because direct feed is enabled by default, when a cell starts, the service management data is loaded.

Publishing server optional configurations


Management data from direct feed cannot be referenced by a service model that is published. Publication will fail if the referenced management data is not published.

Publishing server optional configurationsThis section presents optional configurations for publishing server environments.

Specifying a port for Service Model Manager

The Service Model Manager (smmgr) is a service that is started by the cell to assist in publishing. When the service starts, it selects an available ephemeral port. You can configure it to listen on a fixed port so that the connection is not prevented when a random port crosses a firewall. If you use more than one cell, each cell must specify a different port number.

To specify a fixed port for Service Model Manager

1 Navigate to the %MCELL_HOME%/etc/cellName/smmgr.conf file.

2 Change the parameter ServerPort to a specific port number.

The default value is 0, which means that any port number can be used.

3 Save and close the file.

High availability cell server and BMC ProactiveNet Publishing Server

When a publication request is received by the BMC ProactiveNet Publishing Server component, the publishing server automatically connects to the active server, either primary or secondary, and publishes the service model.

NOTE If the specified port is not available when Service Model Manager is started, start up fails.



If you selected to integrate with BMC Atrium CMDB, then at the time of integration, the publishing server connects to BMC Atrium CMDB and the cell using the logical IP address of the cluster setup.

If the active server goes down during a publication, then the publication fails. When a server is active again, you must manually re-execute the publication on the active server with the CLI publish command.

If the active server goes down during a publication, a switchover takes place and BMC ProactiveNet becomes available on the standby server. In this case, the standby server becomes the active server. If a publication is taking place during the switchover and the publication status is:

■ Automated - the publication is carried forward to the new active server to prevent loss of publication.

■ Manual - you must execute the publish command manually after the switchover.

For automated publications, there are default retrials, but if the specified number of retrials was executed while there was no active server, you must execute the publish command again. For information about the CLI publish command, see the BMC ProactiveNet Command Line Interface Reference Manual available at http://webapps.bmc.com/support/faces/prodallversions.jsp?seqid=172810.

Sharing a single log directory between two publishing servers

If you employ two publishing server instances, each instance on a separate computer, you can share a single log directory between the two instances. For example, if the host of one publishing server is not running, you can start the other publishing server and resume publishing while writing to the same log directory.

The publishing server log directory is in the following location:

%MCELL_HOME%/log/%PSName%,

where■ %MCELL_HOME% is the mcell home directory■ %PSName% is ps_host, where host is the name of the computer on which the

publishing server is installed

To enable publishing servers on different computers to use the same log directory, you must give both publishing servers the same name.

http://webapps.bmc.com/support/faces/prodallversions.jsp?seqid=172810



To change the name of one publishing server to match the other:

1 Uninstall the publishing server for which you want to change the name using the relevant commands.

■ (Windows) uninstall_pserver_service.cmd

■ (UNIX) uninstall_pserver_service.sh

The commands are available from the %MCELL_HOME%/bin directory.

2 In the MCELL_HOME/etc/pserver_service.conf file, set the variable PS_NAME to the new publishing server name.

3 Reinstall the publishing server using the relevant command:

■ (Windows) install_pserver_service.cmd ■ (UNIX) install_pserver_service.sh

4 In the MCELL_HOME/etc/pserver.conf file, change the attribute SystemLogDirName to the name of the shared log directory.

You must use an network file system path name to specify the directory. For more information about the pserver.conf file, see “pserver.conf file and parameters” on page 158.

5 Update the SystemLogDirName attribute for the other publishing server to the same shared log directory.

NOTE If the log directory is remote and the publishing server runs as a service, ensure that the service logs on as an account with access to the remote directory. Do not use the Local System account default logon because it does not provide access to the remote directory.

Monitoring BMC ProactiveNet Publishing Server with cell events


Monitoring BMC ProactiveNet Publishing Server with cell events

This section describes how to monitor the BMC ProactiveNet Publishing Server using cell events. By default, the publishing server sends event information to the BMC ProactiveNet cell. Users with full access and service administrator access can monitor the status of publishing server using the BMC ProactiveNet Administration Console. For the request, connection, and error events, see the Administration tab. For information about the Administration Console, see the BMC ProactiveNet Administration Guide.

You can view all generated events in BMC ProactiveNet Operations Console on the Events tab in the collector “By Location - System - Publishing Server”.

BMC ProactiveNet creates ADMIN_EVENTs for the control events of the publishing server, so you can view the status of the publishing server in BMC ProactiveNet Infrastructure Management view of the Administration Console.

If automated Atrium CMDB Publishing is enabled, you should monitor the publication requests to locate failures.

Modifying the generation of events

The BMC ProactiveNet Publishing Server creates status, connection, and publication request information that describes the internal state of the publishing server and its connection to the BMC Atrium CMDB and the cells.

To modify the publishing server events sent to a cell, you make changes in configuration files. Table 29 describes the types of events with an example, the configuration file for each, and the location of the configuration file.

Table 29 BMC ProactiveNet Publishing Server event generation

Type of eventExample event message

Configuration file name

Configuration file location on the cell computer

control—status events generated when the publishing server starts or stops in a controlled way

BMC ProactiveNet Publishing Server started

pserver.conf MCELL_HOME/etc/ps_hostName/pserver.conf

or if this file does not exist, then MCELL_HOME/etc/pserver.conf

connection—events generated when the publishing server makes a connection with one of its surrounding components

serverName connection failure.



Modifying the generation of events


To modify the generation of events

1 In the pserver.conf file, set the IPSEventsIM parameter to the name of the cell that will receive the events.

In the example, events are sent to the cell named cell.Admin (default BMC ProactiveNet cell).

If you enter an incorrect cell name in this file, (a cell name that is not present in the cell directory as it is configured by IMFileDirectoryName), then no events are generated. In the tmp/ps_hostname/pserver.trace output file, the error message is Unable to report ips events to im X: IPSEventsIM points to unregistered im.

2 To generate error events, in the etc/pserver.trace file, uncomment the following line by removing the # at the beginning of the line.

#log4j.logger.com.bmc.sms.ps=DEBUG, IPSERROREVENTS

as shown in the example.

request—events generated for every publication and classinfo request that is processed by the publishing server

Class validation request failed.



error—events that indicate there is a problem with the correct functioning of the publishing server

serverName exception occurred: xxx

pserver.trace MCELL_HOME/etc/ps_hostName/pserver.trace

or if this does not exist, then MCELL_HOME/etc/pserver.trace

EXAMPLE In the relevant section of the pserver.conf file:

#---------------------------------------------------------------------------#Events#---------------------------------------------------------------------------#Events tracking Publishing Server’s operation and errors are sent to im#<IPSEventsIM>#IPSEventsIM=<ImpactAdminCell>#By default IPS_EVENTs are generated to the Impact Admin CellIPSEventsIM=cell.Admin#Only operation events of the classes listed in IPSEventClasses are created.#By default events of all IPS_EVENT concrete subclasses are created#IPSEventClasses=IPS_START,IPS_STOP,IPS_CONFIG,IPS_CONNECT,#IPS_IM_CONNECT,#IPS_PUBLISH,IPS_CLASSINFO#Enabling of error events (IPS_ERROR) is to be configured in pserver.trace

Table 29 BMC ProactiveNet Publishing Server event generation

Type of eventExample event message

Configuration file name

Configuration file location on the cell computer

Understanding classes and slots for BMC ProactiveNet Publishing Server events


3 Restart the BMC ProactiveNet Publishing Server service or process.


Table 30 describes the Common Event Model (CEM) slots (defined in CORE_EVENT) and values that are applicable to all events generated by BMC ProactiveNet Publishing Server.

EXAMPLE In the relevant section of the pserver.trace file:

# Print messages of level DEBUG or above in the package#log4j.logger.com.bmc.sms.imapi=DEBUG#log4j.logger.com.bmc.sms.imapi.nls=DEBUG#log4j.logger.com.bmc.sms.imapi.gw=DEBUG#log4j.logger.com.bmc.sms.imobject=DEBUGlog4j.logger.com.bmc.sms.ps=DEBUG, IPSERROREVENTS

Table 30 Common Event Model (CEM) slots (part 1 of 2)

Slot name Slot label Description Default value

mc_event_category Category high-level normalized category of the object the event represents

OPERATIONS_MANAGEMENT

mc_object_class Object Class identifies the class of an object ■ for status events of the publishing server itself = BMC ProactiveNet Publishing Server

■ for status events of the automated publishing service of the publishing server = BMC ProactiveNet Publishing Server - Automated Publishing

mc_object Object name of the BMC ProactiveNet Publishing Server instance

ps_hostname

mc_host_class Host Class type of host Computer

mc_host Host name of the computer on which BMC ProactiveNet Publishing Server is running

not defined

mc_host_address Host Address network address of the host computer on which BMC ProactiveNet Publishing Server is running

not defined



Event classes and slots specific to BMC ProactiveNet Publishing Server

The event classes that are specific to BMC ProactiveNet Publishing Server are subclasses of the class IPS_EVENT. The class hierarchy for IPS_EVENT is

IPS_EVENTIPS_CONTROL

IPS_STARTIPS_STOPIPS_CONFIG

IPS_CNXIPS_CONNECT

IPS_IM_CONNECTIPS_ERRORIPS_REQUEST

IPS_CLASSINFOIPS_PUBLISH

These classes are defined in the ips.baroc file, located in the MCELL_HOME\etc\default\EM\kb\classes directory.

When you enable event generation to a BMC ProactiveNet cell, all operational events are generated, which are the event classes IPS_START, IPS_STOP, IPS_CONFIG, IPS_CONNECT, IPS_IM_CONNECT, IPS_PUBLISH, and IPS_CLASSINFO.

In addition to operational events, you can also enable the generation of BMC ProactiveNet Publishing Server error events of the class IPS_ERROR.

mc_origin_class Origin Class identifies the event management system type

BMC ProactiveNet Publishing Server

mc_origin Origin specifies the event management system that is “closest” to the source of the event and is considered to have detected the event

ps_hostName

mc_tool_class Tool Class the way in which the incident is reported to the cell

BMC ProactiveNet Publishing Server

mc_tool Tool defines where any event is within a value that can further distinguish where the event is coming from within the mc_tool_class value

ps_hostName

mc_tool_address Tool Address IP address of the host computer on which BMC ProactiveNet Publishing Server is running

not defined

Table 30 Common Event Model (CEM) slots (part 2 of 2)

Slot name Slot label Description Default value



IPS_START—Impact Publishing Server start

The IPS_START class contains events that occur when the BMC ProactiveNet Publishing Server service (or process) is started or when automated publishing is started.

IPS_STOP—Impact Publishing Server stop

The IPS_STOP class contains events that occur when the BMC ProactiveNet Publishing Server service (or process) is stopped.

IPS_CONFIG—Impact Publishing Server configuration file

The IPS_CONFIG class contains events that are generated when BMC ProactiveNet Publishing Server starts and display configuration information for the Publishing Server instance, as shown in Table 33.

Table 31 IPS_START slots

Slot name Slot label Description

process_run_id Process Run ID All IPS_CONTROL events that are generated from the same processing run of BMC ProactiveNet Publishing Server are assigned the same process run ID (guid) for easy correlation of these events.

mc_parameter Status value is the string status

mc_parameter_value Parameter Value indicates the status of BMC ProactiveNet Publishing Server:

■ as it launches: starting■ when up and running: started

Table 32 IPS_STOP slots



severity Severity seriousness of the event; default is INFO

mc_parameter Status value is the string status

mc_parameter_value Parameter Value indicates the status of the BMC ProactiveNet Publishing Server:

■ when stopping: stopping■ when stopped: stopped



Event generation for this class is enabled by default.

IPS_CONNECT—Impact Publishing Server connect

The IPS_CONNECT class contains events that occur when BMC ProactiveNet Publishing Server tries to establish a connection to other components.

Table 33 IPS_CONFIG slots


os_class OS Class indicates the class of the operating system

os_version OS Version indicates the version of the operating system


ps_version IPS Version contains the version of the Publishing Server

ps_build_number IPS Build Number contains the software build number of the Publishing Server

ps_build_date IPS Build Date contains the build date of the Publishing Server

home_dir Home Directory contains the absolute path of the home directory for the Publishing Server

conf_file Configuration File contains the absolute path of the configuration file; pserver.conf is the default file

kb_dir KB Directory contains the absolute path of the kb directory

log_dir Log Directory contains the absolute path of the log directory

mcell_dir Cell Directory File contains the absolute path of the cell directory file (default is mcell.dir)

trace_conf Trace Configuration File

contains the absolute path of the trace configuration file; pserver.trace is the default file

trace_file Trace File contains the absolute path of the trace file; pserver.trace if the default file



IPS_IM_CONNECT—Impact Publishing Server connect

The IPS_IM_CONNECT class contains events that occur when the BMC ProactiveNet Publishing Server tries to establish a connection to a cell.

IPS_REQUEST—BMC ProactiveNet Publishing Server request

The IPS_REQUEST class contains events that occur when BMC ProactiveNet Publishing Server receives a request (for example, a request for a publishing preview).

Table 34 IPS_CONNECT slots


ips_request_id Request ID the ID of the request sent to the publishing server

The connection is required for the processing of the request. For every request, IPS_CONNECT events are created for every component that needs to be connected.

destination Destination type of the component to which the publishing server is connecting; possible values are:

■ CMDB for BMC Atrium CMDB■ IM for BMC Impact Manager■ SMM for Service Model Manager

dst_name Destination Name name of the component to which the publishing server is connecting

dst_location Destination Location host and port number of the computer to which the publishing server is connecting

dst_user Destination User logon used to connect

blank for Impact Manager and Service Model Manager connections because those connections do not require authentication

result Result indicates the success or failure of the connection; possible values are

■ SCS when the connection succeeds■ FLR when the connection fails

Table 35 IPS_IM_CONNECT slots


dst_location2 Destination Secondary Location

host and port number of the secondary BMC ProactiveNet Impact Manager server, if high availability is enabled



Table 36 IPS_REQUEST slots (part 1 of 2)


severity Severity enables you to follow the status of a request

When the request is sent to the BMC ProactiveNet Publishing Server, the severity is INFO. When the BMC ProactiveNet Publishing Server finishes the processing of this request, it updates the severity of the event:

■ OK if the request is successful■ WARNING if the request failed

client_data Client Data data coming from the client

For automated publishes resulting from a BMC Impact Model Designer promotion, this slot displays the ReconJobRunId and the PromotionId.

request_id Request ID the ID of the request sent to the BMC ProactiveNet Publishing Server

This ID is necessary when you retrieve the request log by using a BMC IX local action and is useful in diagnosing publication failures.

request_msg Request Message the content of the request (for example, EnvId=PROD; Queue=T)

This is the internal communication protocol, useful for debugging.

request_result Request Result initially UNK (unknown)

Set to SCS (success) or FLR (failure) when processing is terminated.

result_msg Result Message brief description of the success or the failure of the handled request

For example, Request failed: Publish verification of IM(s) failed. You can find more detailed failure messages in the request log.



user_id User ID the logon user ID of the requestor

For automated publishes that are invoked from a BMC Impact Model Designer promotion, this slot displays the BMC Impact Model Designer logon user ID.

For publishes from a CLI, this slot displays the user of the CLI or publish@hostname if the CLI is run locally without authentication.

description Description the description that comes with the request

For automated publishes resulting from a BMC Impact Model Designer promotion, this slot displays the BMC Impact Model Designer promotion comment.

For publishes from a CLI, this slot displays the description you enter when using the -s option.

Table 36 IPS_REQUEST slots (part 2 of 2)




IPS_PUBLISH—BMC ProactiveNet Publishing Server publication request

The IPS_PUBLISH class contains events that occur when a request for a publication is generated.

IPS_CLASSINFO—BMC ProactiveNet Publishing Server class information request

The IPS_CLASSINFO class contains events that are generated when information about classes is requested, for example, when you use a CLI to verify the class definitions between a cell and the BMC Atrium CMDB.

Table 37 IPS_PUBLISH slots


publish_type Publish Request Type indicates the type of publish; possible values are

■ direct when the publish request is for a DirectPublish

■ init when the publish request is an initialization, as with the pinit cli

■ publish when the publish request is a delta or incremental publication, as with automated publish or with the publish CLI command

■ selected_publish when a publish request is for selected objects, as with the publish -d CLI command

env_id Environment ID ID of the publishing environment

For example:■ PROD for production environment■ TEST.user.1 for BMC Impact Model

Designer test environment

Table 38 IPS_CLASSINFO slots


classinfo_type Class Info Request Type

indicates the type of classinfo; possible values are

■ validation when the classInfo request happens with the CLI command pclassinfo -n cellName

■ export when the classInfo request is generated with BMC Impact Model Designer export meta data functions, or with the CLI command pclassinfo -x

About impact management data


IPS_ERROR—BMC ProactiveNet Publishing Server errors

IPS_ERROR events are different from other events in the IPS_EVENT class. They report issues that occur with the BMC ProactiveNet Publishing Server, while other IPS_EVENTs report information.

IPS_ENV—BMC ProactiveNet Publishing Server environment request

Each time a penv CLI is issued (except for the action command info), an IPS_ENV event is generated. IPS_ENV events are generated for these environment requests:

■ creation of a publishing environment■ modification of a publishing environment■ initialization of CMDB datasets of an AtriumCMDB publishing environment ■ removal of a publishing environment

About impact management dataManagement data are the data that are referred to by configuration items (CIs) and impact relationships. Management data is always published to all cells of a publishing environment. A default set of management data is in the kb/data directory of the cell as well as in the BMC ProactiveNet CMDB Extensions and in the kb/data directory of the BMC ProactiveNet Publishing Server.

An impact management data instance of a higher priority publish origin might replace the same impact management data instance of a lower priority publish origin. However, in the case of the same priority publish origin, an impact management data instance can be published once and only once to a cell.

Table 39 IPS_ERROR slots


severity Severity indicates the seriousness of the event

The default is WARNING

Table 40 IPS_ENV slots


origin_id Origin ID contains the origin ID (AtriumCMDB or DirectPublish) of the publishing environment

env_id Environment ID contains the IDs of the publishing environment

env_type Environment Request Type

contains the action open, set, init or close

Understanding publishing environments


Each component and impact relationship of a cell can refer to each management data instance regardless of the source of the management data in the cell (Direct Feed or AtriumCMDB publishing or DirectPublish publishing or CellPublish publishing).

Direct Feed management data can also be referred to by published CIs and relationships. The management data need not be published to be referred to by published CIs and relationships.

Understanding publishing environmentsA publishing environment defines the source of the data and the cells to which the data is sent.

You can secure publishing environments by password protecting them.

About publishing environments

A publication is always executed within a set of conditions defined by the requirements of the BMC ProactiveNet data. This set of conditions is referred to as a publishing environment. For example, you want to send a service model from BMC Atrium CMDB (one condition) to a test cell (second condition). If the source of the service model data is a BAROC file and the data goes to a production cell, this requires a different environment and is handled differently by BMC ProactiveNet Publishing Server.

The BMC ProactiveNet Publishing Server component supports publishing BMC ProactiveNet data (service model data and management data) from three sources or origins: BMC Atrium CMDB, which is referred to as an Atrium Publish Feed, from BAROC source files using the CLI command pposter, which is referred to as Direct Publish Feed, or from a staging cell, which is referred to as Cell Publish Feed.

An environment is uniquely identified by EnvID plus OriginId. The environment identifier must be unique within all AtriumCMDB Publish environments or within all Direct Publish environments. However, it is simpler and easier to manage if all publishing environments in your enterprise have unique identifiers.

Publish origin Publish is initiated from OriginID

BMC Atrium CMDB ■ BMC Impact Model Designer■ Completion of reconciliation job■ CLI command publish

AtriumCMDB

Direct Publish ■ CLI command pposter DirectPublish

Cell Publish ■ CLI command publish CellPublish

About home cell, home cell alias, and cell alias


Specifying the publish origin

Publishing from these origins is enabled or disabled with configuration parameters (AtriumCMDBPublishOrigin and DirectPublishOrigin and CellPublishOrigin) in the pserver.conf file.

AtriumCMDB Publish is enabled by default and is initiated either through automated publishing or the CLI command publish.

Direct Publish is enabled by default and is initiated either through an API program or the CLI command pposter.

Cell Publish or within all CellPublish environments in a staging cell.

About home cell, home cell alias, and cell alias

A service model component can be assigned to only one cell at a time. If you want, for example, to assign a component to a production cell and, at the same time, use it in a test cell for impact experiments, a mechanism is needed to make this possible. The parameters, HomeCell, CellAliases, and the attributes HomeCell and HomeCellAlias are used by BMC ProactiveNet Publishing Server to determine the cells to which a configuration item (CI) is sent, depending on which have values. CellAliases and HomeCell are parameters of the publishing environment, whereas HomeCell and HomeCellAlias are attributes of the CI.

The environment’s parameter home cell defines the one cell to which all service model data and management data is sent.

The component’s attribute home cell alias defines another name for home cell looked up from a table so that the data with a specific home cell alias can be sent to different cells for different publishing environments.

Cell alias defines another name for a cell so that data can be sent to more than one cell.

A cell can have multiple cell aliases. The mapping of cell alias-to-cell name is one to many per environment. In other words, for each environment and for each cell alias, there can be only one cell name, but many cell aliases can be mapped to the same cell name.

A cell name can only be used in one AtriumCMDB Publish environment, however it can be re-used in many Direct Publish environments, even if it is also used in AtriumCMDB environment.

Cell-alias to cell-name values must already be defined when publishing is initiated.

Publishing from the BMC Atrium CMDB


Default home cell alias

When the parameter DefaultCell is set, the Publishing Server creates a default cell alias mapping to the cell that is configured for the BMC Atrium CMDB PROD publishing environment. By default the CIs and impact relationships are assigned to the cell that is set for the DefaultCell parameter. Leaving this parameter empty effectively drops CIs and impact relationships assigned to DefaultCell from publication.

Determining the cell to which a component is published

To determine the cell to which a component is published, the BMC ProactiveNet Publishing Server uses the following algorithm:

1. If HomeCell is defined for the publishing environment, that value is used (regardless of the values in the component’s HomeCellAlias attribute).

2. The component’s HomeCellAlias is looked up in the CellAliases for the publishing environment.

3. If one of the CellAliases defined for the publishing environment does not have a CellAlias defined, then its cell name is used as the default cell. Every component that has no HomeCellAlias set is published to this default cell.

Publishing from the BMC Atrium CMDBIn AtriumCMDB Publish environments, you can do the following activities:

■ promote service model objects in the BMC Impact Model Designer product. Promotion triggers reconciliation and then publishing of the objects to the cells

■ reconcile from any BMC Atrium CMDB reconciliation dataset

■ create additional AtriumCMDB Publish environments for advanced staging. To create an additional environment, you define parameters using the penv CLI command.

■ define filters in the BMC ProactiveNet Administration Console (see the BMC ProactiveNet Administrator Guide for details)

During the publishing of a service model, new or modified service model components and their relationships are selected from the asset dataset in the BMC Atrium CMDB and copied to the cell.

Enabling AtriumCMDB Publish publishing


Enabling AtriumCMDB Publish publishing

AtriumCMDB Publish is enabled by default, with a the AtriumCMDBPublishOrigin parameter in the pserver.conf file, located in %MCELL_HOME%/etc. For AtriumCMDB environments, cell information is also retrieved from the mcell.dir file, located in the same directory.

Using BMC Impact Model Designer

When the source of the service model data is the BMC Atrium CMDB and you are using BMC Impact Model Designer, the BMC ProactiveNet Publishing Server component can handle all of the requirements for standard publishing. BMC ProactiveNet Publishing Server defines the proper publishing environment based on choices you make in BMC Impact Model Designer and can automatically deliver the BMC ProactiveNet data to the cell after you promote and publish the objects in BMC Impact Model Designer.

About cell alias

When you use only the BMC Impact Model Designer to create service models, it is not necessary for you to understand the concept of cell alias because these values are created and managed for you.

In BMC Impact Model Designer, every CI that is created or modified must have a value for cell name (required field). For each component’s cell name, a cell alias is automatically created and managed by BMC Remedy AR System.

■ When you register a cell in BMC ProactiveNet and define it as production, an alias with the same name as the cell name is defined and stored in the PN:CellAlias form in BMC Remedy AR System.

Using BMC Impact Model Designer


About the production environment

An AtriumCMDB Publish environment uses an asset dataset, by default BMC.ASSET.EnvId.

The production AtriumCMDB Publish environment has the following dataset and form:

The production service model data is in the BMC Atrium CMDB in the production dataset BMC.ASSET.

Dataset and form in BMC Atrium CMDB Description Comments

asset dataset:

by default, BMC.ASSET

contains objects to be published

This is the dataset from which service model data is published to cells.

regular dataset

■ read-only; can be updated only by the CMDB Reconciliation Engine as objects are reconciled

■ a service model object is successfully promoted when it is moved from the sandbox to this dataset in the BMC Atrium CMDB

PN:PublishedData form contains information about published CIs

■ read-only: can only be updated by the BMC ProactiveNet Publishing Server as objects are published

■ a service model object is successfully published when object information is in this form in the BMC Atrium CMDB

WARNING To ensure that the service model data in the BMC Atrium CMDB and in the cell are synchronized, the data in the PN:PublishedData form should be managed solely by BMC ProactiveNet Publishing Server.

Creating advanced publishing environments


Creating advanced publishing environments

To do advanced publishing for BMC ProactiveNet data in AtriumCMDB Publish environments, you need to

You use the CLI command penv and the pclient.conf file to create, modify, and delete publishing environments. For more information about these topics, see the BMC ProactiveNet Command Line Interface Reference Manual.

In an AtriumCMDB Publish environment, the cell is automatically initialized with BMC ProactiveNet management data of the asset dataset of the environment when you execute the CLI command publish.

Home cell and home cell alias

If all CIs and relationships are being published to one cell, you can assign a home cell by

■ defining it in the CLI command penv when you define the environment■ defining it after the environment is opened in a CLI command penv with the action

command set

If home cell is defined, cell aliases, as defined in the BMC Atrium CMDB, are ignored. All service model data in that environment is published to the cell specified in HomeCell, even if HomeCellAlias contains a cell alias that points to another cell.

Table 41 Basic steps to create advanced test environments

Basic steps How to do

1. Determine the cells to use and create if necessary.

See BMC Impact Solutions Infrastructure Administration Guide

2. Register any new cells in BMC Atrium Core Console (which automatically creates them in BMC Atrium CMDB).

See BMC Impact Solutions Infrastructure Administration Guide

3. Determine the source of the service model data (another environment or a BAROC source file).

Use the penv init parameter SourceBarocMgmtData.

Create a BAROC source file.

4. Define the environment. Execute a CLI command penv open

5. Enter the data in the BMC Atrium CMDB.

If cells are running, this initializes cells with this data.

Execute a CLI command penv init

6. Publish the objects to the cell. Execute a CLI command publish

7. Troubleshoot problems. See Appendix A, Troubleshooting

Examples of advanced environments


Cell aliases

If you do not have home cell defined, then cell aliases are required. Using Remedy User or an API program, you must assign cell alias-to-cell name values (per environment) in the BMC Atrium CMDB form, PN:CellAliases.

■ Set the attribute EnvId to the ID of the publishing environment■ Set the attribute CellAlias to the alias■ Set the attribute CellName to the name of a cell that is registered in BMC Atrium

Core Console (registered in the PN:CellInformation form)

You can set a default cell by setting CellAlias to null. In this way, the attribute HomeCellAlias for individual CIs is not required to publish. If you create an instance in the BMC Atrium CMDB form, PN:CellAliases, like the following:

then every CI in BMC.ASSET.EnvId that has no value in HomeCellAlias is published to the cell arwad.


You use the Send to test function in BMC Impact Model Designer to test small service models. For larger service models, more advanced staging and testing options are available with the CLI command penv.

The penv command allows for staging scenarios like the following:

Example 1—Creating two service models for two departments

This approach is best suited for testing large service models where the effort to automate the tasks by script is acceptable in light of the volume of data being tested.

At the beginning of a BSM project, you want to test two separate service models for two different departments.

Environment CellAlias CellName

EnvId arwad



1. You define two environments for the two different departments, by executing the following command:

2. The components and impact relationships for each department are loaded from BAROC files, in the respective asset datasets BMC.ASSET.dept1 and BMC.ASSET.dept2.

After an initial publication, modifications are published incrementally. When you are satisfied with the results, the staging asset datasets can be reconciled into the production dataset.

3. Reconcile the staging asset datasets into the production dataset.

Example 2—Publishing a single service model to multiple environments

Additionally, it is possible to publish a single service model (the data in an asset dataset) to multiple environments. For example, you can send the service model to production cells (for real-life monitoring and impact analysis) and send the same service model data to a test cell to experiment with the impact of component failure.

For the simulation publishing environment, the HomeCell parameter of the publishing environment is defined.

Both the production publishing environment and the simulation publishing environment use the production asset dataset BMC.ASSET. The last successful publication of the simulation publishing environment SIMULATION is saved in PN:PublishedData form. A reconciliation merge to the BMC.ASSET dataset triggers an automated publish on both environments.

Alternatively, if you want to do simulations on a service model that is derived from the production service model, then your simulation publishing environment would use an overlay asset dataset BMC.ASSET.SIMULATION with underlying dataset BMC.ASSET. Reconciliation merges to the BMC.ASSET dataset will trigger an automated publish (if enabled) on the simulation publishing environment.

To create a simulation publishing environment that uses the production asset dataset, execute a command similar to the following:

EXAMPLE >penv open -e dept1

>penv open -1 dept2

EXAMPLE penv -e SIMULATION -p “AssetDataSetId=BMC.ASSET” -p “HomeCell=simulation”

Defining BMC Atrium CMDB classes for BMC ProactiveNet


This command creates only the simulation publishing environment, not the production publishing environment, which should already exist since it is created by default.

To create a simulation publishing environment with an overlay asset dataset:

Defining BMC Atrium CMDB classes for BMC ProactiveNet

Not all BMC Atrium CMDB classes have CIs that are useful for impact analysis. In order to be published to BMC ProactiveNet, BMC Atrium CMDB classes must have the attribute Custom Properties = 100050. You can qualify classes that are not defined as BMC ProactiveNet classes out-of-the-box.

To define a class as a BMC ProactiveNet class

1. In Remedy User's Class Manager Console, add the value 100050 to the existing Custom Properties.

2. Export the modified BMC ProactiveNet class information by executing the CLI command pclassinfo -x.

3. Update the Knowledge Base of the cells and recompile. For more information, see the BMC Impact Solutions Knowledge Base Development Reference Guide.

Defining BMC Atrium CMDB attributes for BMC ProactiveNet

Not all of the BMC Atrium CMDB attributes of BMC ProactiveNet classes are useful for BMC ProactiveNet. In order to be published to BMC ProactiveNet, CMDB attributes must have the following attribute:

Custom Properties = 3\300050\2\1\300070\2\1\300080\2\1\

You can qualify attributes that are not defined as BMC ProactiveNet attributes out-of-the-box.

EXAMPLE penv -e SIMULATION -p “AssetDataSetType=Overlay” -p “HomeCell=simulation” -p “AutomatedPublish=T”

Initializing the BMC Atrium CMDB with BMC ProactiveNet data


To define an attribute as a BMC ProactiveNet attribute

1. In Remedy User's Class Manager Console, set the value of the Custom Properties attribute to 3\300050\2\1\300070\2\1\300080\2\1\.

2. Export the modified BMC ProactiveNet class information by executing the CLI command pclassinfo -x.

3. Update the Knowledge Base of the cells and recompile.

Initializing the BMC Atrium CMDB with BMC ProactiveNet data

BMC ProactiveNet requires service management data for successful operations. During installation of BMC ProactiveNet CMDB Extensions, the production dataset is initialized with service model management data. Although possible, it is unlikely that reinitialization of the production environment will be necessary.

For publishing environments that do not have an asset dataset BMC.ASSET, or environments that use the BMC.ASSET.SIMULATION dataset, you must initialize the environment with service management data.

When you initialize a specific publishing environment, management data objects in the asset dataset and in the PN:PublishedData form of that environment are initialized. Likewise, for environments that use the BMC.ASSET.SIMULATION dataset overlay, management data objects are initialized.

The following initialization processes occur:

■ Existing management data objects are removed from the asset dataset and the PN:PublishedData form.

■ New management data objects in the asset dataset and in the PN:PublishedData form are copied from the initialization source.

For more information about initializing a publishing environment, see also the init action command in the BMC ProactiveNet Command Line Interface Reference Manual.

Initializing a cell


Initializing a cell

Initialization deletes all existing BMC ProactiveNet data (service model data and service management data) of the publishing environment from the cell. For an AtriumCMDB Publish environment, it sends the contents of the BMC Atrium CMDB PN:PublishedData form to the cells.

When a cell is initialized, existing events are associated with new copies of components, so status information of CIs is not lost.

You reinitialize a cell by using the CLI command pinit. Typically, you reinitialize only when

■ a cell is reinstalled (restart the cell with the -i option)■ a cell must be restarted for recovery purposes ■ BMC ProactiveNet data in the cell is no longer in sync with the data in the BMC

Atrium CMDB impact dataset or with the data in the Direct Publish source

When you add a new cell alias to an AtriumCMDB Publish environment, the BMC ProactiveNet Publishing Server automatically initializes it with the service model management data upon the first publication to it. When you initialize cells of an AtriumCMDB Publish environment, the BMC ProactiveNet Publishing Server sends the data in the PN:PublishedData form to the cells.

When only DirectPublish publishing is enabled, then you have to initialize the new cell with management data manually.

To initialize a cell from the BMC Atrium CMDB production environment, execute the following CLI command:

pinit -n cellName

For more information about reinitializing a cell, see the BMC ProactiveNet Command Line Interface Reference Manual.

Example—creating BMC ProactiveNet data in BMC Atrium CMDB from BAROC files


Example—creating BMC ProactiveNet data in BMC Atrium CMDB from BAROC files

In this scenario, the goal is to initialize the publishing environment for Dept1 with the default management data instances and with a number of components and impact relationships.

Creating a BAROC source with component and relationship objects

The following BAROC file, sm.baroc, defines the components and impact relationships of “dept1”:

EXAMPLE BMC_BusinessProcess; mc_udid=test1; Name=test1; OwnerName='DSM PSR/I Lab'; OwnerContact='713.918.8800'; Description='BMC DSM - PSR and Interoperability Lab Test Business Process'; StatusModel=STANDARD; HomeCell=lopud;END

BMC_BusinessService; mc_udid=test1_S0101; Name=test1_S0101; OwnerName='DSM PSR/I Lab'; OwnerContact='713.918.8800'; HomeCell=lopud;END

BMC_ComputerSystem; mc_udid=test1_S0101_N01; Type='WINDOWS_SYSTEM'; Name=test1_S0101_N01; OwnerName='DSM PSR/I Lab'; OwnerContact='713.918.8800'; Description=Computer; HostName=test1_S0101_N01; HomeCell=lopud;END

BMC_Application; mc_udid=test1_S0101_N01_A01; Name=test1_S0101_N01_A01; Type=app_type1; OwnerName='DSM PSR/I Lab'; OwnerContact='713.918.8800'; Description=Application; HomeCell=lopud; END

BMC_Impact; mc_udid=test1_obj1<-obj2; provider_id=test1_S0101; consumer_id=test1; PropagationModel=DIRECT; provider_home_cell=lopud; consumer_home_cell=lopud;

END

Purging and deleting service model objects


Sending service model data to a cell using a BAROC source file

To initialize the publishing environment for Dept1 with the default management data instances and a number of components and impact relationships, do the following:

1 Create a directory MCELL_HOME/etc/ps_hostname/kb/data_Dept1.

2 Copy into it the kb/data directory, add the file sm_Dept1, and edit the .load to add the sm_dept1.

3 Define the HomeCell parameter of the Dept1 environment as lopud.

4 Execute the following command:penv -e dept1 -p "ManagementData=etc/kb/data_dept1/.load" init -v

The management data is created in the asset dataset of the AtriumCMDB Publish environment Dept1. The cell for Dept1 is running and is initialized immediately when you initialize the BMC Atrium CMDB.

When the initialization completes, the cell has the components and the impact relationships.

Purging and deleting service model objects

BMC recommends that service model objects be soft-deleted in BMC Atrium CMDB (MarkAsDeleted=Yes) until the BMC ProactiveNet Publishing Server is able to process their deletion. Ensure that you have retention rules on the Reconciliation's Purge activities for BMC ProactiveNet classes. Occasionally, when objects have been purged or hard deleted in BMC Atrium CMDB before being published, the BMC ProactiveNet Publishing Server needs to publish them to avoid synchronization problems between cells and BMC Atrium CMDB data.

For automated publishing, if objects are purged from the asset dataset by a reconciliation’s purge activity, then the automated publisher is triggered, deleting the instances from the cells.

For manual publishing, the CLI command publish supports two parameters: Purge and Merge. By default, Purge=F and Merge=T.

To purge objects from the cells that have been hard deleted (purged) from the asset dataset, execute the following command:

publish -p “Purge=T”

Publishing in automated or manual mode



When the source of the service model data is the BMC Atrium CMDB, you can control when publishes occur by enabling or disabling automated publish.

By default, the BMC ProactiveNet Publishing Server automatically publishes service model objects to the cells. The BMC ProactiveNet Publishing Server service (or process) starts in automated mode.

To publish service model objects manually, you disable automated publish and use the CLI command publish. For more information about publish, see the BMC ProactiveNet Command Line Interface Reference Manual.

Switching between automated publish and manual publish

By default, the BMC ProactiveNet Publishing Server service starts in automated mode. This is controlled in the pserver.conf configuration file by the parameter AutomatedStartMode (which is set to Automated).

To permanently switch the mode (if you always want to control all publications, for example), edit the pserver.conf file and change the value of the parameter AutomatedStartMode to Manual.

To temporarily switch the mode in which BMC ProactiveNet Publishing Server is running, execute the command pscontrol automated or pscontrol manual.

Automated publish considerations

When automated publish is enabled,

■ publishing operates in the background

■ publish is pre-authenticated if you password protect the AtriumCMDB Publish environment

■ publish requests are queued; a new request starts when the one in progress completes

■ if multiple promotion and reconciliation processes are running at the same time, the throughput time of the publication increases

■ all modified instances since the last successful publish are published, so the instances that are promoted and reconciled, and the instances that are published are not necessarily the same



■ publication failures caused by reasons independent of model consistence (for example, when a cell is not available) result in the automated publisher reattempting the publication

■ promotion and reconciliation, and publish are independent processes. It is possible that the promotion and reconciliation processes are successful, but the subsequent publish fails.

■ if an in-progress publish is still retrieving publishable data from an asset dataset, it will also find publishable data that became publishable after the in-progress publish was initiated. This

— might cause inconsistent data (like an impact relationship pointing to a non-existent component) and publication failure. Such a failure cannot be prevented because the BMC Atrium CMDB does not “know” the concept of transactions.

— causes the first publication to also publish the data of the second reconciliation. The second publication displays the message Nothing to be published.

■ you can also use the CLI command publish

How automated publish works

When a BMC Atrium CMDB Reconciliation Engine job terminates, the ARDBC plug-in notifies the BMC ProactiveNet Publishing Server that the reconciliation job has terminated. BMC ProactiveNet Publishing Server looks up changes to BMC ProactiveNet data in the asset dataset since the last successful publication and attempts to publish the changes to the specified cells on publishing environments for which automated publication is enabled.

When the automated publisher is temporarily off, notifications from a reconciliation job run are saved in BMC ProactiveNet Publishing Server’s persistent store. This ensures that no notifications are lost. When automated publisher restarts, all the notifications that are present are included in one publish request.

By default, automated publish is enabled on publishing environments with regular asset dataset, so a promotion from BMC Impact Model Designer to asset dataset is automatically published to the cell. By default, automated publish is disabled on publishing environments with overlay asset dataset and an overlay publish mode, so a reconciliation to an asset dataset of a BMC Impact Model Designer test environment to a test cell is not automatically published.

Publishing from a Direct Publish source


Determining the current publish mode

To determine the current publish mode in which the BMC ProactiveNet Publishing Server is running, execute the CLI command psstat. One of the following messages is returned:

■ Started - Starting Automated mode■ Started - Automated mode■ Started - Manual mode

In an environment without the BMC Atrium CMDB, psstat returns the status of publishing server as Started.

For more information about psstat, see the BMC ProactiveNet Command Line Interface Reference Manual.

Publishing from a Direct Publish sourceWhen you have a source of data other than BMC Atrium CMDB, you can send it to cells using Direct Publish publishing. You provide a BAROC file that contains the data that is to be added, updated or deleted in the cells. You execute the CLI command pposter to publish the data from a Direct Publish environment. You can publish from multiple publishing environments.

Data that you send from a Direct Publish environment must be updated and deleted in the context of a Direct Publish environment. For example, if you create a component by publishing from the Direct Publish environment MySource, then the component can only be updated or deleted by publishing from the same Direct Publish environment.

The basic process of publishing from a Direct Publish source is

Table 42 Basic process of publishing from a Direct Publish source

Basic process For instructions, see

1. Enable Direct Publishing. “Enabling Direct Publish publishing” on page 153.

2. Create a Direct Publish environment for the BMC ProactiveNet management data.

“Sending BMC ProactiveNet data to the cell” on page 153

3. Create a Direct Publish environment for CIs and impact relationships.

“Sending BMC ProactiveNet data to the cell” on page 153

About home cell and cell alias



Table 43 describes the parameters that apply to a Direct Publish environment.

You must define either the HomeCell or the CellAliases parameter for a Direct Publish environment.

You can set a default cell by setting CellAlias to null. Then, the components that do not have a value set for the attribute HomeCellAlias are published to that default cell.

You can define values for the parameters HomeCell and CellAliases of Direct Publish environments when you define the environment or you can modify them later. However, when you modify them, keep track of the cells to which you published data using the Direct Publish environment.

Determining the cell to which a component is published

To determine the cell to which a component is published, the BMC ProactiveNet Publishing Server uses the following algorithm:

1. If a HomeCell is defined for the publishing environment, that value is used (regardless of the values of the component’s HomeCell or HomeCellAlias slots)

2. Only cell aliases and cell names defined in the publishing environment's CellAliases parameter are used.

4. Create a source file that contains the service model data in BAROC format.

BMC ProactiveNet Command Line Interface Reference Manual

5. Send service model data in the BAROC source file to the cells.

BMC ProactiveNet Command Line Interface Reference Manual

Table 43 Valid parameters for a Direct Publish environment

Parameter name Function

CellAliases specifies one or more cell alias to cell name pairs

By default, this parameter is not set.

HomeCell specifies to which cell to publish. If HomeCell is set, all BMC ProactiveNet data is published to that cell and CellAliases are not used.

By default, this parameter is not set.

Table 42 Basic process of publishing from a Direct Publish source

Basic process For instructions, see



3. If the component’s attribute HomeCell is set, that value is used (regardless the value of the HomeCellAlias slot).

4. The value of the HomeCellAlias slot is used to look up the HomeCell in the publishing environment's CellAliases.

Determining the cell to which an impact relationship is published

To determine the cell to which a impact relationship is published, the BMC ProactiveNet Publishing Server uses the following algorithm:

1. If HomeCell is defined for the publishing environment, that value is used (regardless of the values of the component's consumer_home_cell or Consumer.HomeCellAlias slots)

2. Only cell aliases and cell names defined in the publishing environment's CellAliases are used.

3. If consumer_home_cell is set, that value is used (regardless the value of the Consumer.HomeCellAlias slot)

4. The value of the Consumer.HomeCellAlias slot is used to look up the consumer_home_cell in the publishing environment's CellAliases.

An impact relationship must go to the cell of its consumer.

About the home cell of the provider

1. If HomeCell is defined for the publishing environment, that value is used (regardless of the values of the component's provider_home_cell or Provider.HomeCellAlias slots)

2. Only cell aliases and cell names defined in the publishing environment's CellAliases are used.

3. If provider_home_cell slot is set, that value is used (regardless of the value of the Provider.HomeCellAlias slot)

4. The value of the Provider.HomeCellAlias slot is used to look up the provider_home_cell in the publishing environment's CellAliases.

In a Direct Publish environment, status is not propagated when the value for provider_home_cell for a remote provider is incorrect.

About the enterprise mode


Relationships that cross cells

When a relationship crosses cells (the provider and consumer components belong to different cells), you must set the provider_classname slot for successful creation of relationship.

Determining the cells to which management data is published

1 If HomeCell is defined for the publishing environment, then management data is send to HomeCell.

2 Management data is sent to all cells defined in the CellAliases of the publishing environment.

About the enterprise mode

If you are running the publishing server on multiple systems, use the enterprise mode to send only CIs belonging to a specific system to the default cell. If you do not use the enterprise mode, all CIs are sent to the default cell.

By default, the publishing server is installed with the enterprise mode disabled (set to false). Edit the pserver.conf file to Enterprise=T to enable the enterprise mode.

About class and slot data

If there are classes in the source files that do not exist in the cell, the publication continues or terminates, depending on the value of the parameter ContinueOnFailure in the pclient.conf file. For information about the pclient.conf file, see the BMC ProactiveNet Command Line Interface Reference Manual.

The attributes or slots in the source files must also exist in the cell or the publication fails.

All slots that are defined in the source files for pposter, except possibly HomeCell, HomeCellAlias, Consumer.HomeCell, Consumer.HomeCellAlias, Provider.HomeCell, and Provider.HomeCellAlias are published to the cell.

Enabling Direct Publish publishing


Enabling Direct Publish publishing

By default, Direct Publish publishing is enabled. Direct Publish is controlled in the pserver.conf file, located in MCELL_HOME/etc, by the parameter DirectPublishOrigin = T. (Default = T)

For Direct Publish environments, the cell information is looked up from a cell directory file. You set this file in pserver.conf with the parameter IMFileDirectoryName. It defaults to mcell.dir, so cells and BMC ProactiveNet Publishing Server share the file.

Sending BMC ProactiveNet data to the cell

When all the BMC ProactiveNet data for the environment goes to the cell, you can define the cell with the parameter HomeCell. Create a Direct Publish environment and define HomeCell by executing the following command:

penv open -e EnvId -p “OriginId=DirectPublish” -p “HomeCell=cellName”

where■ EnvId represents the name of the environment you are creating.■ cellName represents the name of the cell to which you are sending objects.

Modifying home cell and cell aliases

To modify existing values for the parameters HomeCell or CellAliases, use the CLI command penv with its action command set.

To change the value of HomeCell to null (unset or remove the value), use the following command:

penv set -e EnvId -p "HomeCell="

To change the value of CellAliases to null (unset or remove the value), use the following command:

penv set -e EnvId -p "CellAliases="

NOTE

When you modify the value of the parameter CellAliases, you must redefine all cell aliases.

Initializing a cell from a Direct Publish environment


Initializing a cell from a Direct Publish environment

Initializing a cell from a Direct Publish environment consists of deleting all existing BMC ProactiveNet data of the publishing environment from the cell and then recreating it from the original BAROC source file.m

Reinitializing a cell

To initialize a cell from a Direct Publish environment and recreate the data from the BAROC source file, execute CLI commands similar to the following:

pposter -e EnvId sourceFileName.baroc

pposter -e EnvId -p “Init=T” sourceFileName.baroc

Removing data from a cell

To remove existing service model data for a specific environment from a cell, the second pposter command references an empty (containing no data) BAROC file. Execute CLI commands similar to the following:

pposter -e EnvId sourceFileName.baroc

pposter -e EnvId -p “Init=T” emptyFileName.baroc

For more information about reinitializing a cell, see the BMC ProactiveNet Command Line Interface Reference Manual.

Examples—using cell aliases for Direct Publish publishing

Example 1

You need a service model for the Sales department in the production cells austin and brussels.

You define a Direct Publish production environment by executing the following command:

EXAMPLE penv open -e Sales -p “OriginId=DirectPublish” -p “CellAliases=[austin, austin, brussels, brussels]”

Examples—using cell aliases for Direct Publish publishing


You create a BAROC source file named sales.baroc. In the source file, these attributes are set: HomeCellAlias=austin, Consumer.HomeCellAlias=austin and Provider.HomeCellAlias=brussels.

You send the objects in the source file to the cells austin and brussels by executing the following command:

Now you want to experiment with the impact of a change to the service model in the test cells austin_test and brussels_test. You define a test Direct Publish environment by executing the following command:

You make a copy of the BAROC source file, sales.baroc, and name the copy sales_test.baroc. In the sales_test.baroc file, you add a new component and a new impact relationship and leave the remainder of the data in the source file unmodified.

You send the objects in the source file sales_test.baroc to the cells austin_test and brussels_test by executing the following command:

Example 2

The service model for the Sales department is needed for training.

You define a Direct Publish environment by executing the following command:

EXAMPLE pposter -e Sales sales.baroc

EXAMPLE penv open -e Sales.Test “OriginId=DirectPublish” -p “CellAliases=[austin, austin_test, brussels, brussels_test]”

EXAMPLE pposter -e Sales sales_test.baroc

EXAMPLE penv open -e Sales.Training -p “OriginId=DirectPublish” -p “CellAliases=[austin, austin_training, brussels, brussels_training]”

Securing publishing environments


You need the same objects in the Sales.Training environment that are in the source file sales.baroc, so you send the objects in that source file to the cells austin_training and brussels_training by executing the following command:

Even though you did not modify the source file sales.baroc, which has CIs defined with HomeCellAlias=austin, the service model objects are sent to the cell austin_training because the Sales.Training environment was defined with cellalias-to-cellname pairs as austin, austin_training and brussels, brussels_training. See “Determining the cell to which a component is published” on page 150.

Securing publishing environmentsYou can control the execution of publishes for a specific publishing environment by putting a password on the environment. You can password protect both Atrium CMDB environments and Direct Publish environments.

Passwords are removed in generated request logs and from BMC ProactiveNet Publishing Server request events (class IPS_REQUEST), unless you enable password logging by setting the PasswordLogging parameter to T (true) in the pserver.conf file.

Passwords that contain a semicolon (;) and passwords that end with (encrypted) are not supported.

You can put a password in the pclient.conf CLI’s configuration file. You enter the password in plain text and it is encrypted the first time a CLI is executed. This relieves you from having to enter the password on the command line when executing the CLI, however it makes the password available for anyone who has the right to execute the CLI. Also, a password that is in a CLI's configuration file applies to all executions that do not specify a password on the command line itself, regardless of the publishing environment. Therefore, if you have multiple secured environments, you need to decide if you want to put the password of one of them in the configuration file.

Executing commands on password protected environments

If a publishing environment is password protected, then you must enter the password for every action on the environment: publishing, initializing, and penv action commands: init, set, close.

EXAMPLE pposter -e Sales.Training sales.baroc

Securing publishing environments


For example, you want to assign a value to the HomeCell parameter for the Accounting department, which has an environment ID = Accounting and is password protected, so you execute the following command:

Adding a password when you create an environment

To add a password when you create a new publishing environment, you use the CLI command penv and the action command open, in the format:

For example, you want to create a service model for the Sales department using a BAROC source file for the service model data and password protect it. So you create a Direct Publish environment with the CLI command penv and the action command open using the following command:

You can also enter a password in the pclient.conf or pinit.conf configuration files. You enter the password in plain text and it is encrypted the first time a CLI command that uses the configuration file is executed.

Adding a password to an existing environment

To add a password to an environment that was not password protected when it was created, you use the CLI command penv and the action command set, in the format:

EnvId represents the environment ID.the_password (first occurrence) represents the password.the_password (second occurrence) represents the password again, to confirm it.

Modifying the password on an environment

To change a password on an environment, you use the CLI command penv and the action command set, in the format:

EXAMPLE penv set -e Accounting -p “Password=ut0p1a” -p “HomeCell=cell2”

penv open -e EnvId -p “OriginId=DirectPublish|AtriumCMDB” -p “NewPassword1=the_password” -p “NewPassword2=the_password”

EXAMPLE penv open -e Sales -p “OriginId=DirectPublish” -p “NewPassword1=sam3ul” -p “NewPassword2=sam3ul”

penv set -e EnvId -p “NewPassword1=the_password” -p “NewPassword2=the_password”

pserver.conf file and parameters


Removing the password on an environment

To remove the password on an environment, you use the CLI command penv and the action command set, in the format:

Using CLI command publish for a password protected AtriumCMDB Publish environment

If you password protect an Atrium CMDB Publish environment, you must include the password in the command string when you execute the CLI command publish. For example:

Automated publishing for a secured Atrium CMDB Publish environment is pre-authenticated.

Using CLI command pposter for a password protected Direct Publish environment

If you password protect a Direct Publish environment, you must include the password in the command string when you execute the CLI command pposter. For example:

pserver.conf file and parametersThis section contains information you need to configure the BMC ProactiveNet Publishing Server. For changes to this file to take effect, you must restart the BMC ProactiveNet Publishing Server service or process.

Table 44 describes the default pserver.conf file and all its parameters.

penv set -e EnvId -p “Password=old_password” - p “NewPassword1=new_password” -p “NewPassword2=new_password”

penv set -e EnvId -p “Password=old_password” - p “NewPassword1=” -p “NewPassword2=”

EXAMPLE publish -e Accounting -p “Password=l0b3l1a”

EXAMPLE pposter -e Payroll -p “Password=86a032” sm_payroll.baroc



Table 44 pserver.conf file

Filename pserver.conf

File path MCELL_HOME/etc/ps_hostname or if that file does not exist MCELL_HOME/etc

Descriptioncontains the configuration settings that control the behavior of the BMC ProactiveNet Publishing Server

Parameter name Description Default value

SystemLogDirName specifies the name of the log directory for the publishing server

On UNIX platforms, you must specify an NFS path. Specifying a UNC path is not supported.

log

AtriumCMDBPublishOrigin enables (T) or disables (F) publishing from publishing server to a cell

T (true)

AtriumCMDBHeartbeatInterval sets the length of time that publishing server waits for a heartbeat, a cancel, or a commit from a client during publish preview

When no heartbeat is received after this interval, the publish is cancelled.

180 (seconds)

AtriumCMDBDefaultEnvId identifies the default environment for the BMC Atrium CMDB publication. If the environment does not already exist, it will be created when pserver starts.

PROD

AtriumCMDBDefaultAssetDatasetId

identifies the default asset dataset for the default publish environment of BMC Atrium CMDB. The default environment is created when pserver uses this asset dataset.

BMC.ASSET

AtriumCMDBDefaultFilterIds lists the default filters.

When pserver creates the default environment, it registers the default filters for this environment.

PublishProvidersToSIM,ServiceModelSet,HomeCell,ExtAuth

PreviewTimeout sets the length of time that publishing server waits for an answer to cancel or commit the publish after publish preview

When no answer is received after this interval, the publish is cancelled.

180 (seconds)

CellPublishOrigin enables (T) or disables (F) publishing from staging cells T (true)

CellPublishIms lists all the staging cells, that is, all the cells that define CellPublish publishing environments.

If you want to use the command "publish -e OVO" then you have to add the adapter cell to this parameter. If empty, then the command will fail with the message No publish environment OVO found, and you must use the command "publish -e OVO -p "OriginId=CellPublish" -p "Cell=ovo_java""



CellPublishGateway enables (T) or disables (F) listening by the Publishing Server for incoming IPS_CP_TRIGGER events propagated by a staging cell that will trigger a publication for a CellPublish environment of the cell

T (true)

CellPublishGatewayName defines the name of gateway that listens for incoming IPS_CP_TRIGGER events to trigger a CellPublish publication.

This name is looked up in the directory set in IMFileDirectoryName.

not defined, set by install

CellPublishGatewayIms lists the cells from which the Publishing Server accepts incoming events.

If no cell is listed then all incoming events are accepted.

not defined

CellPublish2CmdbContinueOnWarning

enables (T) or disables (F) continuation when instances that cannot be imported must skipped

The list of skipped instances and the reason they were skipped is output to the request log.

F (false)

CellPublish2CmdbReconJobTimeOut

defines the length of time, in seconds, that CellPublish2Cmdb checks for the termination of the reconciliation job run.

If the interval expires before the reconciliation job run completes, then the request log does not indicate the result. Even though no result is indicated, the reconciliation job might complete successfully after the timeout.

120 (seconds)

CellPublishCommitRetryTimeOut

defines the length of time, in seconds that CellPublish2Cmdb retries in total to commit the data in the import dataset.

When a commit fails, a new commit is retried without the offending data. By retrying the commit without the offending date, CellPublish2Cmdb can find all offending data in one run.

900 (seconds)

Cells gives the cells for which pserver creates the cell information in BMC Atrium CMDB




ClassInfoValidation if enabled, the class information of BMC Atrium CMDB and of the cell is validated when publishing. If disabled, then the class information is not validated when publishing.

Disabling the validation results in slightly better performance when publishing. This may be important when increments are really small (a single modification). When disabled, publication may fail when a CI is published with an attribute that does not exist in cell.

T (enabled)

DefaultCell sets the CellName for the default HomeCellAlias.

This is used by the PROD publish environment of CentralPublish and for the default BMC Atrium CMDB publish environment.

<DefaultCell>

DefaultEnvCells gives the cells for which pserver creates CellAliases <CellName> -> <CellName> for the default environment

DirectPublishOrigin enables (T) or disables (F) direct publishing feed F (false)

DropDuplicateComponentAlias if enabled, the offending duplicate alias is dropped from the CI that reports the collision.

T (enabled)

Enterprise enables (T) or disables (F) the enterprise mode of operation

F (false)

JNPServers defines the host and port of JNP Servers

When the Portal is set up in cluster mode, this value must match the same value in the pclient.conf file.

localhost:9379

JMSCommWarnReconnectCount the number of times to retry to establish JMS communication

If the trial fails then an IPS_ERROR event with message “Unable to establish JMS communications.” of severity WARNING is generated.

If JMSCommWarnReconnectCount is -1 then retries continue indefinitely.

30 (reconnect attempts)

JMSCommWarnReconnectInterval the interval (in seconds) between two reconnection attempts

10 (seconds)

JMSCommMajorReconnectCount the number of times to retry to establish JMS communication

If the trial fails then an IPS_ERROR event with message “Unable to establish JMS communications.” of severity MAJOR is generated.

If JMSCommMajorReconnectCount is -1 then retries continue indefinitely.

-1 (connection attempts)




JMSCommMajorReconnect Interval

the interval (in seconds) between two reconnection attempts

300 (seconds)

CMDBServer specifies the name of the computer on which BMC Atrium CMDB resides


CMDBPort defines the port number for connecting to the BMC Atrium CMDB


use 0 for dynamic port detection

CMDBUser defines the user ID that grants access to the BMC Atrium CMDB


CMDBPassword a valid BMC Atrium CMDB user password

appears in plain text when entered; encrypted at first launch


ARSGroupMembers lists the host and TCP/IP port of every AR Server Group member

If an AR Server Group is deployed then you must set this parameter, regardless of whether you use a load balancer.

Use 0 for dynamic port detection.

not defined

RequestHistorySize sets the maximum number of request log files that are retained by the publishing server

-1

CellConnectionTimeout sets the length of time the publishing server maintains a connection to a cell when there is no activity from the cell

60 (seconds)

IMMessageBufferSize sets the size of the message buffer for communication with the cell

2000

IMMessageBufferKeepSent sets the time to keep messages buffered while waiting for an answer

300 (seconds)

IMFileDirectoryName defines the name of the Impact Manager directory for direct publications; it is looked up in the directory MCELL_HOME/etc/PSName, or if that file does not exist, in the directory MCELL_HOME/etc

This directory file is also used to locate the cell for publishing server event generation.

mcell.dir

PasswordLogging enables (T) or disables (F) the display of passwords in generated request logs and IPS_REQUEST events

F (false)

SMMMessageBufferSize sets the size of the message buffer for communication with Service Model Manager

500

SMMMessageBufferKeepSent sets the time to keep messages buffered while waiting for an answer

300 (seconds)




SMMMessageBufferKeepSentEstimate

enables (T) or disables (F) the use of the estimate when the length of time exceeds the value that is calculated for the upload time of the service model

T (true)

ARSNormalTimeOut sets the time to stop waiting on a BMC Remedy AR System operation that occurs quickly

300 (seconds)

ARSLongTimeOut sets the time to stop waiting on a BMC Remedy AR System operation that occurs slowly

600 (seconds)

ARSXLongTimeOut sets the time to stop waiting on a BMC Remedy AR System operation that occurs slowly

1800

ARSXLongTimeOutEstimate enables (T) or disables (F) the use of the estimate when the length of time exceeds the value that is calculated for committing bulk entry transactions

T (true)

AutomatedCancelAckTimeout When automated publishing is stopped, an ongoing publish is canceled, if possible. This parameter sets the length of time for an ack reply of the publishing request, which returns the requestID.

If the requestID is unknown, then the publish request is not canceled.

5 (seconds)

AutomatedCancelScsFlrTimeout When automated publishing is stopped, an ongoing publish is canceled, if possible. This parameter sets the length of time for the final reply of the publish request, which returns a message indicating if the publish request was canceled or not.

If the publish is canceled or if the final reply is unknown, then the publish is retriggered when automated publish is restarted.

900 (seconds)

AutomatedHeartbeatInterval sets the length of time between the publishing server and the AR Notify plugin for heartbeat. 0 or a negative value disables heartbeat.

60 (seconds)

AutomatedHeartbeatTimeout sets the length of time that the publishing server waits for an answer to a heartbeat from the AR Notify plugin.

5 (seconds)


Configuring the Notify ARDBC plug-in


Configuring the Notify ARDBC plug-inThe Notify ARDBC plug-in adds real-time notification functionality to BMC Remedy AR System applications and enables clients to receive notification about events in BMC Remedy AR Server.

You can modify the Notify ARDBC parameters in the following files:

UNIX: arInstallDirectory/conf/ar.conf Windows: arInstallDirectory\conf\ar.cfg

AutomatedPublishRetryCount the maximum number of times automated publishing is retried after failures

n represents the number of repeated publication attempts:

■ n = 0 means the publication is attempted once and not retried

■ n = 1 means the publication is attempted and then retried once

■ n < 0 means the publishing server continues to retry until a publication is successful

Publications that are skipped are not counted as retry attempts, so AutomatedPublishRetryCount is the effective maximum number of retries.

12

AutomatedPublishRetryPeriod sets the length of time between two consecutive publish requests when publish fails

If a previous publish request is not terminated when the interval times out, the next trial is skipped.

300 seconds

AutomatedStartMode the publishing mode when the publishing server starts or restarts. When the publishing server is running, you can change the publishing mode by using requests (using the CLI command pscontrol). By default, the publishing server starts in automated mode.

automated

IPSEventsIM defines the cell to which publishing server events are sent

not defined, set by install to BMC ProactiveNet cell

IPSEventClasses defines the event classes for which publishing server events are created

all subclassess of IPS_EVENT


Configuring the Notify plug-in for AR server groups


After you make changes to these parameters, restart BMC Remedy AR System so the changes take affect.

Configuring the Notify plug-in for AR server groups

The Publishing Server supports the Notify plug-in for Remedy AR server groups. If you use a load balancer, you must add the load balancer host name to the CMDBServer parameter in the pserver.conf file. You must also add the individual group member nodes (<host>:<tcp/ip port>) to the ARSGroupMembers parameter in the pserver.conf file. If you do not use a load balancer, you must set the address of the Remedy AR server group member to which you want the Publishing Server to connect using the CMDBServer parameter in the pserver.conf file.

To check whether the Remedy AR server group is correctly configured for the Publishing Server and the Notify plug-in:

Table 45 ar.cfg file parameter descriptions

Parameter Description Default value

BMC-ARDBC-NOTIFY-Verify-Log log file location Remedy AR System/ Impact directory

BMC-ARDBC-NOTIFY-Server-Port port number for the server

If 0 is specified, the plug-in allows the operating system to choose an available port and binds to that port. The actual port is visible in the NOTIFY:servers form.

1840, set by install

BMC-ARDBC-NOTIFY-Protocol-V1-Encrypt switches encryption for V1 protocol on or off

If encryption is switched on (T), the NOTIFY:protocols property for the V1 protocol contains the key to use for encryption.

If encryption is switched off (F), the NOTIFY:protocols property for the V1 protocol is empty.

T (True)

BMC-ARDBC-NOTIFY-Mem-Trace enables (T) or disables (F) memory tracing

You should enable memory trace only when BMC Customer Support requests it.

F (False)

BMC-ARDBC-NOTIFY-Event-Cache sets the number of events for the event cache

When the size is 0, event caching is disabled

200

Viewing publication history


1 From the computer running the Publishing Server, logon as Remedy User to the individual AR Server Group Members.

2 Open the form, NOTIFY:Servers.

3 In the form NOTIFY:Servers, you should find one entry when you attempt to retrieve the entries.

Viewing publication historyThis section contains general guidelines for working with publication logs.

After you submit a promotion request in BMC Impact Model Designer, the promotion results dialog box reports only the success or failure of a promotion. It does not offer information about publication status.

You can view detailed information about each publication request from the request logs. Access the request logs in one of the following ways:

■ Publication History window in the BMC ProactiveNet Administration Console (see the BMC ProactiveNet Administrator Guide for details)

■ Request log files on the BMC ProactiveNet server, located in the installDirectory\pw\server\log\ps_hostname folder

■ CLI command pshowlog requestId (see the BMC ProactiveNet Command Line Interface Reference Manual for details)

The publication logs include detailed messages from the different products it communicates with, such as BMC Atrium Core Console, BMC Atrium CMDB, and the cells.

Diagnosing publication issuesUse the following guidelines to diagnose why a CI is not published:

NOTE If a Server Name Alias is set equal to one of the group members, the Publishing Server (the AR API client or Remedy User) cannot access the ARDBC vendor form NOTIFY:Servers of the plugin running on the node that is not the alias. Automated publishing will not function.

Diagnosing publication issues


■ In the BMC ProactiveNet Administration Console, open the Publication History window. If the publication request log is not available, diagnose why automated publication was not performed.

■ If the publication history indicates that the publication failed, examine the request log in the Publication Details pane for reasons.

■ If the publication succeeded and the CI does not appear, examine the request log in the Publication Details pane for the reasons. You should also examine the CI settings in the BMC Impact Model Designer.

■ Examine trace files: pserver.trace, mcell.trace, and smmgr.trace.

See Appendix A, “Troubleshooting” for details.

Diagnosing publication issues



A p p e n d i x AA Troubleshooting

This section describes problem solving for the BMC Impact Model Designer and the publishing server.

Publishing ServerThis section contains information on troubleshooting problems with the publishing server and publication failures.

Promotion, reconciliation, and publish are independent processes. It is possible that the promotion and reconciliation processes are successful, but the subsequent publication fails.

BMC Impact Model Designer notifies you only of the success or failure of a promotion, not whether the publication is successful or has failed. BMC recommends that you monitor the success or failure of publications that are automatically started.

Verifying that the publishing server is running

To ensure that only one publishing server is running, the publishing server maintains the file MCELL_HOME/log/ps_hostName/ps.lock. If the BMC ProactiveNet Performance Management JMS is not functioning properly, you can use ps.lock to verify whether the publishing server is running.

Using trace files


Using trace files

To help debug problems with publishing, you use the pserver.trace file. The file MCELL_HOME/tmp/ps_hostName/pserver.trace contains tracing information. By default, only trace information of level WARN or higher is logged. Enable debug tracing in MCELL_HOME/etc/<PSName>/pserver.trace (or MCELL_HOME/etc/pserver.trace) by commenting out the last two sections.

Stopping the publishing server when JMS is not running

If the JMS is not up and running properly, find and stop the publishing server process.

Ensure that you do not kill the publishing server process when it is processing a request. Note that this procedure is for UNIX platforms only.

1 At the command prompt, navigate to the MCELL_HOME/log/ps_hostName directory.

2 Execute the command fuser ps.lock

The processID of the publishing server process is returned.

3 Kill the publishing server process by executing the command: fuser -k ps.lock

Publishing large service models

When publishing large models, several parameters may require adjustment:

■ In the pserver.conf file, the configuration parameter ARSXLongTimeOut may not be set high enough. This parameter specifies the time out value for the communication between the publishing server and the BMC Atrium CMDB.

Reinitialization of a cell (pinit) and a new, successful publication are necessary to avoid subsequent publication job failure with the message Unique data identifier not/already in use.

By default, the publishing server estimates the timeout needed. If the timeout is not adequate, set ARSXLongTimeOutEstimate=F and increase ARSXLongTimeOut.

Publishing large service models


If publication fails during the database update with the message Failure while applying publish on CMDB - Error - 92 Timeout, the operation has been accepted by the server and will usually complete successfully, the value for ARSXLongTimeOut is not set high enough and expires before the BMC Atrium CMDB has terminated committing modifications in the impact dataset.

The BMC Atrium CMDB continues to commit modifications in the impact dataset and after a while the service model will be available in the impact dataset. Make sure the parameters are set correctly.

The same failure may happen when initializing CMDB with large service models.

■ In the MCELL_HOME/etc/smmgr.conf file, the DestinationBufferKeepSent parameter is the timeout for communication between smmgr and the cell. In the MCELL_HOME/etc/pserver.conf file, the SMMMessageBufferKeepSent parameter is the timeout for communication between the publishing server and smmgr.

By default, the publishing server estimates the timeout needed. If the publication fails with Publish verification of IMs failed, set SMMMessageBufferKeepSentEstimate=F and increase SMMMessageBufferKeepSent.

If publication fails with Publish validation of IMs failed, use the following information to troubleshoot the problem according to the message you receive:

IM <CellName> failed to upload service model from SMM

The DestinationBufferKeepSent of smmgr is not high enough and expires before the cell has terminated uploading service model from smmgr.

IM <CellName> did not answer the request

The SMMMessageBufferKeepSent of the publishing server is not high enough and expires before the smmgr has applied the verification or upload.

In both cases, the cell continues to upload and eventually the service model is available in the cell. Nevertheless, reinitialize the cell and publish again to avoid subsequent publish jobs failing with the message Unique data identifier not/already in use.

■ When performing a penv init or a pinit of a large service model the Stack Size and the Heap Size of the publishing server might need to be increased. For service models with approximately 10,000 CIs and 10,000 relationships, you should double both the Stack Size and the Heap Size. To double the Stack Size, in the pserver.bat file (Windows) or the pserver file (UNIX) change the default -Xoss400k and -

Publishing failures and reattempts


Xss512k values to -Xoss800k and -Xss1M. To double the Heap Size, in the pserver.bat file change the default -Xms256M -Xmx800M values to -Xms512M -Xmx1600M. Additionally, in the pserver_service.conf file, add the following parameters before restarting the Publishing Server:

wrapper.java.additional.2=-Xms512M wrapper.java.additional.3=-Xoss800k wrapper.java.additional.4=-Xss1Mwrapper.java.additional.5=-Xmx1600M

Making these changes will allow publishing of 10k models successfully if you run pserver.bat manually.

Publishing failures and reattempts

When an automated publish request fails because of reasons independent of model consistency (for example, when a cell is not available), the automated publisher retries the publish (the configuration parameter AutomatedPublishRetryPeriod in the pserver.conf file defines the interval between two publish requests). If a request is still not terminated when the interval runs out, a new interval is started.

The configuration parameter AutomatedPublishRetryCount gives the maximum number of retries:

■ 0 means no retrial, thus only a single publish request is performed. ■ 1 means a publish request and one retry attempt, if necessary.■ a number less than zero (-1) means the automated publisher will republish

indefinitely, until a publish is successful.

The publishing server service or daemon fails to start

Only one publishing server may be running at any given time. This is controlled in the MCELL_HOME/log/<PSName>/ps.lock file, which is updated with a timestamp every minute by the publishing server as it runs. If the publishing server is stopped gracefully, then ps.lock is removed.

If the publishing server service or daemon fails to start and displays the error message

Unable to launch BMC Impact Publishing Server. Another BMC Impact Publishing Server is already running

No publication after successful promotion


remove the ps.lock file in the MCELL_HOME/log/ps_hostname/ directory and restart the publishing server service (or daemon).

No publication after successful promotion

Even if promotion is successful, publication might still fail. Promotion and publication are asynchronous processes. If the Promotion dialog box in BMC Impact Model Designer indicates that the promotion was successful, but data does not appear in BMC ProactiveNet Performance Management, follow the guidelines in this section to troubleshoot the problem.

Unable to start automated publishing

If you receive the following error event after switching to automated mode:

Unable to start automated publishing. ERROR-8755 The specified plug-in does not exists. (BMC.ARDBC.NOTIFY).

This error occurs when the Notify ARDBC plugin is not loaded when the publishing server starts in automated mode. Verify that the plugin is properly installed and loaded.

Verify automated publishing mode

Verify that the publishing server is running in automated mode with the CLI command psstat. If the psstat command returns Started - Automated mode, automated publisher is up and running.

If the psstat command indicates that the publishing server is not running in automated mode, it may be in manual mode. This might have occurred because the configuration parameter AutomatedStartMode in pserver.conf is set to Manual, or because the mode was set with the CLI command pscontrol. If the publishing server is running in manual mode, you can request a publication using the CLI command publish.

To switch to automated mode, execute the CLI command pscontrol automated.

Reconciliation jobs hang

When reconciliation jobs hang and remain in a started status (causing BMC Impact Model Designer promotions to hang), the NotifyARDBC plug-in is not installed or is not running.

The publishing server does not reply to requests


Ensure that the NOTIFY plug-in configuration and the BMC Remedy AR System plug-in environment variables are correct so that the NOTIFY plug-in is loaded. To verify that the NotifyARDBC plugin is running, follow these steps:

1 Log on to Remedy User.

2 Open the form NOTIFY:protocols and retrieve entries.

You should get one entry with version 1.

3 Open the form NOTIFY:servers and retrieve entries.

You should get one entry. If the port is not accessible for the publishing server to open a TCP/IP connection, verify the installation of the Notify ARDBC plugin. The port should be open for the publishing server to open a TCP/IP connection.

The publishing server does not reply to requests

The client and server use the JMS service of BMC ProactiveNet Performance Management for communication. Normally, the publishing server restores when the JMS service drops. If the JMS service remains down, the publishing server stops with a critical error.

However, occasionally the communication is not restored and the publishing server doesn't stop, and the pserver.trace file contains repeated warnings from org.jboss.mq.SpyJMSException.

To resolve this situation,

1. Verify that BMC ProactiveNet Performance Management is running properly (or restart BMC ProactiveNet Performance Management).

2. Restart the publishing server.

Diagnosing publication failures

When a publication attempt or other request fails, examine the details of the request log in BMC Impact Model Designer using the menu command Publish History (Tools => Publish History).

Table 46 describes the request failure messages of the publishing server, what causes the problem, and what to do to correct the problem.



Table 46 Publishing server request failure messages (part 1 of 4)

Failure message Cause Action

Classinfo is not synchronized.

For various reasons, the class definitions in the BMC Atrium CMDB can become out of sync with the class definitions of published service model of the cells. For example, a class may be modified in the BMC Atrium CMDB after the service model is published to the cell.

In BMC Impact Service Model Editor, launch Tools => Export Cell Meta Data to generate an up-to-date mc_sm_baroc.object file.

Restart the BMC ProactiveNet Performance Management.

Execute pclassinfo -x -o mc_sm_object.baroc.

Replace the existing mc_sm_baroc.object file of the target cell in the MCELL_HOME/etc/cellName/kb/classes directory.

Recompile the cell’s Knowledge Base, and restart the cell.

Component alias "{0}" for component "{1}" is already used by component "{2}"

Two CIs have the same alias. ■ Make sure all CIs have unique aliases.

■ Publish the purge by using the CLI command publish -p "Purge=T"

Connection to IM cellName is not open OR Connection to IM cellName dropped

The publishing server is not able to connect to the BMC Impact Manager or the connection was dropped.

Verify that the target cell instance is running. Restart it if necessary. Also verify that the cell’s location and encryption key are registered with BMC ProactiveNet Performance Management.

Consumer/Provider component with mc_udid {0} is not defined

This message may occur if an impact relationship is pointing to a non-existent configuration item (CI)

Such problems may occur when two promotions follow very quickly and the first promotion adds a relationship and the second promotion moves a CI out of model.

Using automated publish for two promotions will prevent this failure.



IM {0} failed to launch SMM (Service Model Manager)

In a cell's trace file you find the message Service Model Manager process ({0}) not active within expected delay. Please verify.

The cell does fork a Service Model Manager (SMM) process. In the mcell.conf file, the parameter ServiceModelManagerStartTimeOut = 60 defines the timeout.

Increase the value of ServiceModelManagerStartTimeOut.

IM {0} failed to upload service model from SMM

This failure message displays after a failure in the second phase of two-phase commit.

Reinitialize the cell and publish again (to avoid subsequent publishes failing with the message Unique data identifier not/already in use)

IM is not publish enabled. The ServiceModelPublish parameter in the MCELL_HOME/etc/mcell.conf file or in MCELL_HOME/etc/<CellName>/mcell.conf file is set to No.

Reset the ServiceModelPublish parameter to Yes and restart the cell.

init verify failure When you have previously published from a Direct Publish environment and now want to publish from BMC Atrium CMDB, the Direct Publish management data conflicts with management data being published from BMC Atrium CMDB.

Delete Direct Publish management data using the pposter CLI command and the ddelete action command.

No user group defined with id {0}

In the BMC Atrium CMDB, a CI's securities point to BMC Remedy AR System user group ids. In the BMC IM, a CI's securities points to BMC Impact Administration User Roles. The publishing server maps the BMC Remedy AR System user group ids to user role names, by using the user group info found in the AR form groups and the AR external authentication group mappings.

This failure typically occurs when you remove a group in AR Server for which there still are components that refer to it.

Modify the CIs to point only to existing user groups.





Operation on instance of different environment

The data instance is already published to the cell from another publish environment.

Use the instance's publish environment to publish modifications or deletions.

Provider_home_cell ({0}) is remote but component {1} is local

This error can occur as a result of a typo when registering cells. For example, cell X runs on port X, and cell Y runs on port Y. However, port X is mistakenly entered for both cells.

While cell X is running, a provider component with cell name Y is sent to cell on port X, thus the cell X impact relationship is sent to the cell with name Y, thus

■ the cell on port X is component local (same cell as relationship)

■ provider_home_cell has value Y, so the provider_home_cell is remote (other cell as relationship)

The issue originates from the fact that although the CI is sent to cell Y, in reality, it is sent to cell X because that cell is listening on the (erroneous) port (X) of cell Y.

Correctly register the ports of the cells.

Publish returns generic failure message, such as Publish validation of Impact Manager failed

Publication failure Use the -v option (publish -v) to return both generic and detailed (verbose) failure messages.

The AR System Plug-In server is not responding (ERROR-8939)

When the load on the BMC Remedy Action Request (AR) System server plug-in is very high, the system sometimes returns a connection error.

Try the following workarounds:

■ Start another publication.■ Restart the BMC Remedy AR

System server.■ Adjust the BMC Remedy AR

System server configuration parameters (see “pserver.conf file and parameters” on page 158).

The cell alias is not mapped to a cell name in the current environment

The attribute HomeCellAlias has a value that is not defined in the publish environment's CellAliases.

Define the cell aliases correctly.

The minimum supported protocol version is 7.

The version of the target cell instance is earlier than the required version.

Uninstall the earlier version and install the appropriate version.





Unique data identifier already in use.

A service CI with the same mc_udid is already published in the cell.

The service model in the cell is most likely not in sync with the master copy kept in the BMC Atrium CMDB impact dataset. Reinitialize the cell.

If reinitializing the cell fails because of invalid data, then the master copy is invalid. Reinitialize the BMC Atrium CMDB.

Unique data identifier not in use

This failure may occur when the deletion or modification of a CI with a udid that does not exist is requested. For Atrium CMDB Publish, this typically happens when the service model in a cell is not in sync with service model in (the impact dataset of) the BMC Atrium CMDB, typically when a previous publish failed because of failure while applying publish on cell or BMC Atrium CMDB, or when cell has been restarted withthe -id option.

Reinitialize the BMC ProactiveNet data from the publish environment by executing the CLI command pinit -n cellName -e EnvId

If this solution fails, the data in the BMC Atrium CMDB may be invalid. Reinitialize the BMC Atrium CMDB.

Unknown home cell "{0}" for shadow component

The entry in the mcell.dir file of the consumer's cell is not defining the provider's cell.

Correct mcell.dir.

You may receive detailed failure messages from the BMC Atrium CMDB.

For instance, you will receive failure messages when the number of CI's exceeds the limited number available with a trial license.

These failures may occur in the second phase of the two-phase commit.

To troubleshoot these failure messages, consult the BMC Remedy AR System and BMC Atrium CMDB documentation.

If the failure occurred in the second phase of the two-phase commit, to avoid subsequent publish failures with the message Unique data identifier not in use or already in use, reinitialize the cell and publish again.



Another publish request is ongoing


Another publish request is ongoing

When the publishing server does not accept or begin processing a publish request, the following messages may display:

■ Another publish request is ongoing■ The environment is not registered■ Error with ids/udids for partial publish, i.e. publish of selected instances

Message: Another publish request is ongoing

The publishing server executes only one publication at a time, per cell. If you request a new publication (by using the CLI command publish or pposter) while another publication is in progress, the message Another publish request is ongoing displays.

If you receive this message unexpectedly, verify that the previous publication is still running. If a publication hangs (because of an uncached exception, which can be found in tmp/ps.err), then all following publications will result in failure messages and you must contact BMC Customer Support.

Using dynamic ports with the ARDBC Notify plug-in

The Notify plug-in uses the static port 1840 by default. However, if the Notify plug-in is configured to use a dynamic port, automated publishing might not work. If the Notify plug-in listens on a port that is registered and used by another service, for example, port 1828 used by the cell, automated publication does not function. If this occurs, psstat returns the message:

Started - Starting Automated mode

To prevent this issue, restart the Remedy AR Server so that Notify plug- in chooses another port to which to listen.

Frequently Asked QuestionsThis section contains some frequently asked questions about BMC Impact Model Designer.

I cannot launch BMC Impact Model Designer successfully


I cannot launch BMC Impact Model Designer successfully

You must restart Apache Tomcat after installing BMC ProactiveNet CMDB Extensions. If you try to launch BMC Impact Model Designer without restarting Apache Tomcat, the launch may fail. For information about BMC ProactiveNet CMDB Extensions and Apache Tomcat, see the BMC ProactiveNet Getting Started Guide at http://webapps.bmc.com/support/faces/prodallversions.jsp?seqid=172810.

I cannot see the BMC Impact Model Designer menu bar in spite of installing BMC Impact Model Designer successfully

You may not be able to view the BMC Impact Model Designer menu bar due to either of the following reasons:

■ You may have clicked the BMC Atrium Explorer icon instead of the BMC Impact Model Designer icon in the main page of BMC Atrium Core Console. The User Interface (UI) of both these products is similar. The figures below display the two icons.

I cannot see the changes I made to the CIs


Figure 16 BMC Atrium Explorer and BMC Impact Model Designer icons

■ You may not have administrator privileges. Only administrators can view BMC Impact Model Designer.

I cannot see the changes I made to the CIs

Sometimes, the changes you make may take some time to reflect in the GUI. Click the Refresh View icon on the toolbar to see the changes immediately.

The service model I try to create appears as yellow blocks

Sometimes, the service models you are trying to create may be displayed as yellow blocks. Click the Refresh View icon on the toolbar for the service models to display correctly.

Atrium Explorer icon

BMC Impact Model Designer icon

Troubleshooting BMC Impact Model Designer


Troubleshooting BMC Impact Model DesignerThe table below displays the error messages you may encounter while using BMC Impact Model Designer and the action that you can perform to resolve these errors.

Table 47 Error Messages

Error Message Cause Action

Changes submitted could not be saved. Please refer log for details.

When you select multiple groups on the Permissions tab in the Edit Component Properties dialog box, BMC Impact Model Designer tries to save all the groups as a single string in the BMC Atrium CMDB. However, the length of the string to be saved in the BMC Atrium CMDB must not exceed 255 characters.

Deselect one or more groups on the Permissions tab in the Edit Component Properties dialog box.

Javax.naming.CommunicationException: Failed to retrieve stub from server <server_name>

This error may be displayed when you try to connect to the publishing server.

Use the psstat cli command to connect to the publishing server. If this does not resolve the error, add the name of the BMC ProactiveNet Performance Management server to the host file. The host file is located at <system_drive>\Windows\system32\drivers\etc

Selected relationship types not valid

You may have chosen a relationship other than the type 'Impact'.

You can edit only the 'Impact' type of relationship. Only impact relationships are recognized by the BMC ProactiveNet cell. For information about creating and editing component relationships, see the BMC Atrium CMDB User's Guide.


A p p e n d i x BB Default service model data classes

This appendix describes the service model class hierarchy in the BMC Atrium CMDB Common Data Model.

Service model data structuresThe service model uses various data structures as data classes. In this documentation, the term class designates the structure definition. The term table is the set of data instances defined for a data class. The following discussions are not intended to represent an exhaustive hierarchy of all classes associated with the dynamic data model.

Service model data class overview

There are several types of BAROC data classes that are important in the service model:

■ Component data classes—the service model data classes that define the component types typically used by business organizations. These classes are loaded into the Knowledge Base by default.

■ Relationship data class (BMC_Impact)—the data class that defines the different types of relationships that can exist between service components. The only class that exists for impact relationships is BMC_Impact.

■ Service model management classes—the data classes that define the status computation and propagation, as well as the classes that support the service model event-to-component mapping mechanism. These classes are loaded into the Knowledge Base by default.

■ Event classes—the classes that define the product event types and their behaviors.

Service model data class files


Service model data class files

Table 48 lists the files in which the various data class definitions are located. Default class definitions are in the MCELL_HOME\BMC Software\server\etc\cellName\kb\classes directory. In addition, each cell has a working Knowledge Base with its class definitions in the MCELL_HOME\etc\cellName\classes directory.

Service model component data classesA service model component type is the data class that defines a logical or physical IT resource that participates in the delivery of business services. Service model configuration items (CIs) can represent a hardware component, an application, a service, or a business entity. A CI can be any aspect of the business for which service management is desired.

Service model CIs are organized in a hierarchy of data classes in which each class represents a component type. The farther down the hierarchy a particular class occurs, the more specific its type.

Table 48 Service management data class files

Data classes File name Contents

Component mc_sm_object.baroc these component types and their subclasses:

■ BMC_BaseElement■ BMC_Collection■ BMC_LogicalEntity■ BMC_System■ BMC_SystemComponent■ BMC_SystemService

Root mc_sm_root.baroc event and data classes and the enumerations that are the foundation of the solution

Mapping mc_sm_event_mapping.baroc mapping data classes that provide the event-to-component mapping mechanism

BMC_BaseElement data class



The parent class of the data class hierarchy is the BMC_BaseElement class. The classes that immediately extend from BMC_BaseElement are:

■ BMC_Collection■ BMC_LogicalEntity■ BMC_System■ BMC_SystemComponent■ BMC_SystemService

BMC_BaseElement data class definition

Figure 17 shows the BAROC definition of the BMC_BaseElement class, which is located in the mc_sm_object.baroc file.

BMC_BaseElement inherits slots from MC_SM_COMPONENT class, which is defined in Figure 18 on page 186. MC_SM_COMPONENT class is located in the mc_sm_root.baroc file.

Figure 17 BMC_BaseElement definitions

MC_PUBLISH_DATA_CLASS : BMC_BaseElement ISA MC_SM_COMPONENT DEFINES { AccountID : STRING; Category : STRING; Company : STRING; DatasetId : STRING; Department : STRING; Description : STRING; Floor : STRING; ImpactCostUnit : STRING; InstanceId : STRING; Item : STRING; ManufacturerName : STRING; Model : STRING; Name : STRING; Notes : LIST_OF STRING, representation = diary; OwnerContact : STRING; OwnerName : STRING; ReadSecurity : LIST_OF STRING; Region : STRING; Room : STRING; SerialNumber : STRING; ShortDescription : STRING, default = 'n/a'; Site : STRING; SiteGroup : STRING; Type : STRING; UsersAffected : INTEGER; VersionNumber : STRING; WriteSecurity : LIST_OF STRING; };END



MC_SM_COMPONENT inherits slots from MC_SM_DATA (which contains no slot definitions, as shown in Figure 19 on page 187). MC_SM_DATA is located in the mc_sm_root.baroc file.

Figure 18 MC_SM_COMPONENT definition

MC_PUBLISH_DATA_CLASS:MC_SM_COMPONENT ISA MC_SM_DATA DEFINES{ComponentAliases: LIST_OF STRING;HomeCell: STRING, read_only=yes;Priority:MC_PRIORITY, default=PRIORITY_5;StatusModel: STRING, default = 'STANDARD';business_data:STRING;change_number : INTEGER, parse=no, read_only=yes;comment: STRING;component_scope: MC_SM_COMPONENT_SCOPE, default = LOCAL, parse=NO, read_only = YES;computed_status: MC_SM_COMPONENT_STATUS, parse=no, read_only=yes, default = OK;consolidate_function: MC_SM_CO_FUNCTION, parse =no, read_only=yes;consumer_num: INTEGER, parse=NO, parse=no, read_only=yes;direct_events_count: INTEGER, parse=no, read_only=yes;impact_status: MC_SM_COMPONENT_STATUS, parse=no, read_only=yes, default = NONE;last_status_modification: INTEGER, parse=no, read_only=yes, representation = date;maintenance_mode: MC_YESNO, parse = no, read_only=yes, default = NO;manual_status: MC_SM_COMPONENT_STATUS, parse=no, read_only=yes, default = NONE;manual_status_comment: STRING, parse=no, read_only=yes;manual_status_providers: LIST_OF STRING, parse=no, read_only=yes;manual_status_providers_count: INTEGER, parse=no, read_only=yes;manual_status_requestor: STRING, parse=no, read_only=yes;self_status: MC_SM_COMPONENT_STATUS, parse=no, read_only=yes, default = NONE;shadow_cells: LIST_OF STRING, parse=NO, read_only=YES;status: MC_SM_COMPONENT_STATUS, parse=no, read_only=yes, default = OK;sub_status: MC_SM_COMPONENT_STATUS, parse=no, read_only=yes, default = NONE;# additional slot in 7.0possible_causes: LIST_OF STRING, parse=no, read_only=yes;root_causes: LIST_OF STRING, parse=no, read_only=yes;sla_rollup_status: MC_SM_SLM_SLA_STATUS, parse=no, default=NO_SLAS;impact_sla_rollup_status: MC_SM_SLM_SLA_STATUS, parse=no, default=NO_SLAS;ScheduleId:STRING;PriorityOut:MC_PRIORITY;ImpactCostPerSec : REAL;ImpactCostPerSecOut : REAL;PriorityWatchdog:MC_YESNO, default=NO;SelfPriorityFunction:MC_SM_PRIORITY_FUNCTION, default=BASE_PRIORITY;SelfPriorityFunctionParam:STRING;self_priority: MC_PRIORITY, parse=no, read_only=yes, default=PRIORITY_5;raw_impact_priority: REAL, parse=no, read_only=yes;impact_priority: MC_PRIORITY, parse=no, read_only=yes, default=PRIORITY_5;computed_priority: MC_PRIORITY, parse=no, read_only=yes, default=PRIORITY_5;cost:REAL, parse=no, read_only=yes;impact_cost:REAL, parse=no, read_only=yes;schedule_status: MC_SM_SCHEDULE_STATUS, default=IN;HomePageURI:STRING;DeviceID : INTEGER ;any_event_max_sev:SEVERITY, default=OK, read_only=yes;any_open_event_max_sev:SEVERITY, default=OK, read_only=yes;impacting_open_event_max_sev:SEVERITY, default=OK, read_only=yes;APPLICATION_event_max_sev:SEVERITY, default=OK, read_only=yes;DATABASE_event_max_sev:SEVERITY, default=OK, read_only=yes;NETWORK_event_max_sev:SEVERITY, default=OK, read_only=yes;SYSTEM_event_max_sev:SEVERITY, default=OK, read_only=yes;USER_TRANSACTIONS_event_max_sev:SEVERITY, default=OK, read_only=yes;OTHER_event_max_sev:SEVERITY, default=OK, read_only=yes;highest_pn_event_score: REAL, read_only=yes;highest_pn_predicted_severity : PREDICTED_SEVERITY, read_only=yes, default = '';pn_predict_to_occur_time : INTEGER, representation=date, read_only=yes;};END



Figure 19 MC_SM_DATA definition

MC_SM_DATA inherits slots from CORE_DATA, which is shown in Figure 20. CORE_DATA is located in the mc_root_internal.baroc file.

Figure 20 CORE_DATA definition

Configuration item instance slot descriptions in alphabetical order

Table 49 alphabetically lists the slots that define CIs with their descriptions and data type. The Source class column indicates the name of the class where the slot is defined.

MC_DATA_CLASS : MC_SM_DATA ISA CORE_DATA;END

MC_DATA_CLASS : CORE_DATA DEFINES { data_handle : INTEGER, parse = no, read_only = yes; mc_udid : STRING, read_only = yes; mc_creation_time : INTEGER, parse = no, read_only = yes, representation = date; mc_modification_time : INTEGER, parse = no, read_only = yes, representation = date; mc_modification_requestor : STRING, parse = no, read_only = yes; publish_env_id : STRING, parse = no, read_only = yes; };END

Table 49 Slots that define CIs (part 1 of 4)

Slots Description Data type or enumeration Source class

AccountId identification of the Account the object belongs to (Accounts are created in BMC ProactiveNet Performance Management)

STRING BMC_BaseElement

any_event_max_sev maximum severity across all underlying events

SEVERITY MC_SM_COMPONENT

any_open_event_max_sev maximum severity across all underlying events whose status = OPEN


APPLICATION_event_max_sev

highest severity of all the attached events for which mc_event_subcategory = APPLICATION


Category provides a user-defined categorization of a CI


change_number increments every time an event is sent for the component. Used to determine the order of events for events which happen in the same second.

INTEGER MC_SM_COMPONENT

consumer_num number of CIs acting as consumers of the CI


comment a comment that is set for the component via BMC Impact Manager

STRING MC_SM_COMPONENT



component_scope scope of the component (local, shadow, etc.)


computed_priority the priority of a component that is the highest between self priority and impacts priority. Set in the computed_priority field.

enumeration: MC_PRIORITY MC_SM_COMPONENT

computed_status status of the CI computed from self and substatuses

enumeration:MC_SM_COMPONENT_STATUS

MC_SM_COMPONENT

consolidate_function function used to determine impact_status from the provider’s propagated status

enumeration: MC_SM_CO_FUNCTION

MC_SM_COMPONENT

cost the current cost for the component depending on the current value of the schedule (either During Schedule or Exceptions Within During Schedule)

REAL MC_SM_COMPONENT

data_handle identifier in local cell INTEGER CORE_DATA

DATABASE_event_max_sev highest severity of any event of a particular sub-category that is attached to the CI or any other CI (inactive relationships are ignored)


DatasetId identification of the dataset within which the instance exists. This attribute relates to the CoreDatasetId attribute of a BMC_Dataset instance.


Description a description of the CI that is meaningful to the enterprise


direct_events_count count of events coming from instrumentation


HomeCell name of the parent cell for the CI STRING MC_SM_COMPONENT

highest_pn_predicted_severity

highest value of all alarm events attached to the CI


ImpactCostPerSec cost of one second of unavailability of the component


ImpactCostPerSec cost for a component when it is During Schedule


ImpactCostPerSecOut cost for the component when it is in an Exceptions Within During Schedule period


ImpactCostUnit unit of the cost expressed in ImpactCostPerSec


impact_priority priority determined from a component’s impacts


impact_status status computed by impact_function enumeration:MC_SM_COMPONENT_STATUS

MC_SM_COMPONENT

impacting_open_event_max_sev

maximum severity of impacting (causal) events whose status = OPEN

MC_SM_COMPONENT

InstanceId instance identification of a component within the BMC Atrium CMDB


Item Provides a user-defined categorization of a CI


last_status_modification last time the status or sub_status was changed (used by GUI)


maintenance_mode operational switch used to drop events when UM

enumeration:MC_YESNO

MC_SM_COMPONENT





manual_status manual status flag of the component (NONE if not set)


MC_SM_COMPONENT

manual_status_comment comment entered by user when CI is set to manual status


manual_status_providers list of direct and indirect providers; mc_udids of CIs with manual status set (may contain duplicate entries

LIST_OF_STRING MC_SM_COMPONENT

manual_status_providers_count

number of direct and indirect providers with manual status set (may contain duplicate entries)


manual_status_requestor login ID of user who sets the CI to manual status


ManufacturerName name of the company that manufactured the CI


mc_creation_time date and time when the object was created INTEGER CORE_DATA

mc_modification_time date and time when the object was last changed

INTEGER CORE_DATA

mc_modification_requestor modification requestor STRING CORE_DATA

mc_udid universal data identifier STRING CORE_DATA

Model model assigned to the CI by the manufacturing company


Name user-defined name that is meaningful to the enterprise


NETWORK_event_max_sev highest severity of any event of a particular sub-category that is attached to the CI or any other CI (inactive relationships are ignored)


Notes general notes on the object INTEGER BMC_BaseElement

OTHER_event_max_sev highest severity of all the attached events for which mc_event_subcategory = OTHER


OwnerContact A string that provides information on how the primary system owner can be reached (e.g. phone number, e-mail address


OwnerName name of the person in the enterprise who is responsible for the CI


pn_predict_to_occur_time lowest value amongst all the alarms sharing the highest pn_predicted_severity slot


possible_causes list of possible causes for the component’s current status (different from root causes)


Priority priority enumeration:MC_PRIORITY

MC_SM_COMPONENT

PriorityWatchdog indicates whether the component is a priority propagator

enumeration: MC_YESNO MC_SM_COMPONENT

raw_impact_priority the computed priority for an object (value between 0 and 1)


ReadSecurity list of permission groups that defines who has read access to a CI

LIST_OF_STRING BMC_BaseElement

root_causes list of root causes for the component’s current status




BMC_Impact data class



The BMC_Impact class is the parent class of the hierarchy of data classes that define the different types of service model relationships. This class inherits slots from the root class CORE_DATA and the superclass MC_SM_RELATIONSHIP.

BMC_Impact class definition

Figure 21 on page 191 shows the BAROC definition of the BMC_Impact superclass, which is located in the mc_sm_object.baroc file.

ShortDescription short textual description (one-line string) of the object


schedule_status indicates whether the component is currently During Schedule or Exception Within During Schedule

enumeration_ MC_SM_SCHEDULE_STATUS

MC_SM_COMPONENT

self_priority the priority of the component based on the base priority and the component’s current status


self_status the status of the object based on events directly attached to it (this does not take into account status from providers)


MC_SM_COMPONENT

sla_roleup_status the aggregation of the compliance status of the associated SLAs, if any

enumeration: MC_SM_SLM_SLA_STATUS

MC_SM_COMPONENT

shadow_cells list of cells that contain shadow of the CI LIST_OF_STRING MC_SM_COMPONENT

status main status of the component (equals computed_status unless manual status is set)


MC_SM_COMPONENT

StatusModel name of the status computation model STRING MC_SM_COMPONENT

sub_status derived status of the CI enumeration:MC_SM_COMPONENT_STATUS

MC_SM_COMPONENT

SYSTEM_event_max_sev highest severity of any event of a particular sub-category that is attached to the CI or any other CI (inactive relationships are ignored)


Type user-defined categorization of a CI STRING BMC_BaseElement

USER_TRANSACTIONS_event_max_sev

highest severity of any event of a particular sub-category that is attached to the CI or any other CI (inactive relationships are ignored)


VersionNumber version number of the CI, assigned by the manufacturer


WriteSecurity list of permission groups that define who has write access to a CI






BMC_Impact inherits slots from MC_SM_RELATIONSHIP, which is shown in Figure 22. MC_SM_RELATIONSHIP is located in the mc_sm_root.baroc file.

Figure 22 MC_SM_RELATIONSHIP definition

MC_SM_RELATIONSHIP inherits slots from MC_SM_DATA (which contains no slots, as shown in Figure 23). MC_SM_DATA is located in the mc_sm_root.baroc file.

Figure 23 MC_SM_DATA definition

MC_SM_DATA inherits slots from CORE_DATA, which is shown in Figure 24 on page 192. CORE_DATA is located in the mc_root.internal.baroc file.

Figure 21 BMC_Impact definition

MC_PUBLISH_DATA_CLASS : BMC_Impact ISA MC_SM_RELATIONSHIP DEFINES { AccountID : STRING; ReadSecurity : LIST_OF STRING; ShortDescription : STRING, default = 'na'; WriteSecurity : LIST_OF STRING; };END

MC_PUBLISH_DATA_CLASS:MC_SM_RELATIONSHIP ISA MC_SM_DATA DEFINES{PropagationModel: STRING;consumer_home_cell: STRING, parse=no, read_only=yes;provider_home_cell: STRING, read_only=yes;provider_classname: STRING;State: MC_SM_RELATIONSHIP_STATE, default = ACTIVE;StatusWeight : INTEGER, default=100;consumer_id: STRING, key = yes, read_only=yes;last_status_modification: INTEGER, parse=no, read_only=yes, representation = date;propagated_status: MC_SM_COMPONENT_STATUS, parse=no, read_only=yes, default = UNKNOWN;propagated_sub_status: MC_SM_COMPONENT_STATUS, parse=no, read_only=yes, default = UNKNOWN;provider_id: STRING, key = yes, read_only=yes;true_impact: MC_YESNO, parse=no, read_only=yes, default = NO;change_number : INTEGER, parse=no, read_only=yes;};END

MC_DATA_CLASS:MC_SM_DATA ISA CORE_DATA;END



Figure 24 CORE_DATA definition

Relationship slot descriptions in alphabetical order

Table 50 alphabetically lists the slots that define CI relationships, with their descriptions and data type. The Source class column indicates the name of the class where the slot is defined.

MC_DATA_CLASS : CORE_DATA DEFINES { data_handle : INTEGER, parse = no, read_only = yes; mc_udid : STRING, read_only = yes; mc_creation_time : INTEGER, parse = no, read_only = yes, representation = date; mc_modification_time : INTEGER, parse = no, read_only = yes, representation = date; mc_modification_requestor : STRING, parse = no, read_only = yes; publish_env_id : STRING, parse = no, read_only = yes; };END

Table 50 BMC_Impact slot definitions in alphabetical order (part 1 of 2)

Slot Description Data type or enumeration Source class

consumer_id mc_udid of the consumer CI STRING MC_SM_RELATIONSHIP

change_number change number INTEGER MC_SM_RELATIONSHIP

data_handle identifier in local cell INTEGER CORE_DATA

last_status_modification date/time when the value of true_impact function was last changed (used by GUI)

INTEGER MC_SM_RELATIONSHIP

mc_creation_time date and time when the object was created

INTEGER CORE_DATA

mc_modification_time date and time when the object was last changed

INTEGER CORE_DATA

mc_udid internal key used to reference the relationship; it is an inherited slot

STRING CORE_DATA

propagated_status status that is currently propagated through the relationship

enumeration: MC_SM_COMPONENT_STATUS

MC_SM_RELATIONSHIP

propagated_sub_status maximum of provider substatus and status values


MC_SM_RELATIONSHIP

PropagationModel name of the status propagation model used for determining the propagated status from of the provider’s main status

STRING MC_SM_RELATIONSHIP

BMC_DOWNTIME_STATUS_CONFIG data class


BMC_Impact enumerations

The following enumerations are listed in the mc_sm_root.baroc file:

■ MC_SM_RELATIONSHIP_STATE■ MC_SM_IMPACT_FUNCTION■ MC_SM_SELF_FUNCTION■ MC_SM_CO_FUNCTION■ MC_SM_SLA_RESET_MODE■ MC_SM_COMPONENT_SCOPE■ MC_SM_COMPONENT_STATUS■ MC_SM_SHADOW_REQUEST_OP■ MC_SM_SLM_SLA_STATUS■ MC_SM_CAUSE_TYPE■ PRIORITY_FORMULA■ MC_SM_SCHEDULE_STATUS■ BMC_SIM_DOWNTIME_STATUS_CONFIG

BMC_DOWNTIME_STATUS_CONFIG data class

The BMC_DOWNTIME_STATUS_CONFIG data class is used to define which status enumeration values qualify as downtime for both impact reports and priority computation.

provider_classname name of the class of the provider CI STRING MC_SM_RELATIONSHIP

provider_home_cell the cell that receives events for the provider CI


provider_id mc_udid of the provider CI, the impacting CI


State state of the relationship, Active or Inactive

enumeration:MC_SM_RELATIONSHIP_STATE

MC_SM_RELATIONSHIP

StatusWeight number that determines the degree of importance to give to each provider relationship that impacts a consumer CI

INTEGER MC_SM_RELATIONSHIP

true_impact flag indicating whether this relationship affects the impact_status of the consumer

enumeration:MC_SM_YESNO

MC_SM_RELATIONSHIP

Table 50 BMC_Impact slot definitions in alphabetical order (part 2 of 2)


BMC_STATUS_COMPUTATION data class


BMC_DOWNTIME_STATUS_CONFIG data class definition

Figure 25 shows the BAROC definition of the BMC_DOWNTIME_STATUS_CONFIG data class, which is located in the mc_sm_root.baroc file.

BMC_DOWNTIME_STATUS_CONFIG inherits slots from BMC_SIM_DATA, which is shown in Figure 28 on page 195. BMC_SIM_DATA is located in the mc_sm_root.baroc file.

BMC_DOWNTIME_STATUS_CONFIG slots

BMC_DOWNTIME_STATUS_CONFIG has the following slot.


The BMC_STATUS_COMPUTATION data class is used to define status computation models for the CIs. A status computation model is a model that determines the current status of a service model component when direct impact events occur or the status of a provider CI changes.

Figure 25 BMC_DOWNTIME_STATUS_CONFIG definition

MC_PUBLISH_DATA_CLASS : BMC_DOWNTIME_STATUS_CONFIG ISA BMC_SIM_DATA DEFINES { status : MC_SM_COMPONENT_STATUS, default = UNAVAILABLE; }; END

Figure 26 BMC_SIM_DATA definition

MC_DATA_CLASS: BMC_SIM_DATA ISA MC_SM_DATA DEFINES{ReadSecurity : LIST_OF_STRING;WriteSecurity : LIST_OF_STRING;};END

Table 51 BMC_DOWNTIME_STATUS_CONFIG slot


status the lowest component status that qualifies as down time


BMC_SIM_DOWNTIME_STATUS_CONFIG



BMC_STATUS_COMPUTATION data class definition

Figure 27 shows the BAROC definition of the BMC_STATUS_COMPUTATION data class, which is located in the mc_sm_root.baroc file.

BMC_STATUS_COMPUTATION inherits slots from BMC_SIM_DATA, which is shown in Figure 28. BMC_SIM_DATA is located in the mc_sm_root.baroc file

BMC_STATUS_COMPUTATION slots in alphabetical order

Table 52 alphabetically lists the BMC_STATUS_COMPUTATION slots with their descriptions and types.

Figure 27 BMC_STATUS_COMPUTATION definition

MC_PUBLISH_DATA_CLASS:BMC_STATUS_COMPUTATION ISA BMC_SIM_DATA DEFINES{ model_name: STRING, key = yes;

impact_function: MC_SM_IMPACT_FUNCTION, default = HIGHEST_VAL;ext_impact_function: LIST_OF STRING;self_function: MC_SM_SELF_FUNCTION, default = HIGHEST_VAL;consolidate_function: MC_SM_CO_FUNCTION, default = HIGHEST_VAL;quorum: INTEGER, default = 51;no_alert_status: MC_SM_COMPONENT_STATUS, default = OK;

};END



Table 52 BMC_STATUS_COMPUTATION slots in alphabetical order (part 1 of 2)


consolidate_function name of the algorithm used to compute the component computed status; it consolidates the impact_status and the self_status

enumeration:MC_SM_CO_FUNCTION

BMC_STATUS_COMPUTATION

ext_impact_function the name of the external algorithm to be used by the impact_function when the impact_function slot contains the placeholder EXTERNAL This slot is reserved for future extension.

LIST_OF_STRING BMC_STATUS_COMPUTATION

BMC_STATUS_PROPAGATION data class


BMC_STATUS_PROPAGATION data class

The BMC_STATUS_PROPAGATION class defines the different pairs of component types whose instances can be related to one another through relationships, along with the propagation map to be used by those relationships.

BMC_STATUS_PROPAGATION class definition

Figure 29 shows the BAROC definition of the BMC_STATUS_PROPAGATION data class, which is located in the mc_sm_root.baroc file.

impact_function name of the algorithm used to compute the impact status from provider components; it merges the propagated status values of the different provider components

enumeration:MC_SM_IMPACT_FUNCTIONS


model_name name of the status computation model (key of the table)

STRING BMC_STATUS_COMPUTATION

noalert_status default main status when the consolidate function’s status is NONE

enumeration:BMC_BaseElement_STATUS


quorum quorum percentage applied by the impact function when set to use the QUORUM algorithm

INTEGER BMC_STATUS_COMPUTATION


LIST_OF_STRING BMC_SIM_DATA

self_function name of the algorithm used to compute the self status; it maps and merges the severity values directly from the events

enumeration:MC_SM_SELF_FUNCTION


WriteSecurity list of permission groups that defines who has write access to a CI


Figure 29 BMC_STATUS_PROPAGATION definition

MC_PUBLISH_DATA_CLASS:BMC_STATUS_PROPAGATION ISA BMC_SIM_DATA DEFINES{

name: STRING, key = yes;provider_type: STRING, key = yes;consumer_type: STRING, key = yes;description: STRING;

};END

Table 52 BMC_STATUS_COMPUTATION slots in alphabetical order (part 2 of 2)


BMC_PROPAGATION_MAP data class


BMC_STATUS_PROPAGATION inherits slots from BMC_SIM_DATA, which is shown in Figure 30. BMC_SIM_DATA is located in the mc_sm_root.baroc file.

BMC_STATUS_PROPAGATION slots in alphabetical order

Table 53 alphabetically lists the class slots with their descriptions.


The BMC_PROPAGATION_MAP class is used to define status mapping instances for the relationships. The BAROC definition of the class follows.

BMC_PROPAGATION_MAP data class definition

Figure 31 on page 198 shows the BAROC definition of the BMC_PROPAGATION_MAP data class, which is located in the mc_sm_root.baroc file.



Table 53 Status propagation slots in alphabetical order

Slot Description Data type Source class

consumer_type

valid component types for the consumer CI

STRING BMC_STATUS_PROPGATION

description description applicable to the relationships using this model


name name of the status propagation model; it must match the name of a propagation map




provider_type valid component types for the provider CI






BMC_PROPAGATION_MAP inherits slots from BMC_SIM_DATA, shown in Figure 32. BMC_SIM_DATA is located in the mc_sm_root.baroc file

BMC_PROPAGATION_MAP slots in alphabetical order

Table 54 alphabetically lists the BMC_PROPAGATION_MAP slots with their descriptions, enumeration or data type, and source class.

Figure 31 BMC_PROPAGATION_MAP definition

MC_PUBLISH_DATA_CLASS:BMC_PROPAGATION_MAP ISA BMC_SIM_DATA DEFINES{

name: STRING, key = yes;relationship_state: MC_SM_RELATIONSHIP_STATE, key = yes;provider_status: MC_SM_COMPONENT_STATUS, key = yes;propagated_status: MC_SM_COMPONENT_STATUS;

};END



Table 54 BMC_PROPAGATION_MAP slot definitions


name name of the parent status propagation model

STRING BMC_PROPAGATION_MAP

propagated_status status to be propagated to the consumer component


BMC_PROPAGATION_MAP

provider_status status of the provider component


BMC_PROPAGATION_MAP



relationship_state applicable relationship state

enumeration:MC_SM_RELATIONSHIP_STATE

BMC_PROPAGATION_MAP



BMC ProactiveNet data class descriptions


BMC ProactiveNet data class descriptionsThe following data classes are used in creating service models:

■ BMC_SEVERITY_TO_STATUS■ BMC_SIM_MATCH_TABLE■ BMC_SIM_ALIAS■ BMC_SLOT_FORMULAS■ COMPONENT_CREATION

BMC_SEVERITY_TO_STATUS data class

The BMC_SEVERITY_TO_STATUS class is used to map the severity value of an impact event to a status value that will participate in the computation of the self status for the associated CI.

BMC_SEVERITY_TO_STATUS data class definition

Figure 33 shows the BAROC definition of the BMC_SEVERITY_TO_STATUS class, which is located in the mc_sm_root.baroc file.

You should not edit a SEVERITY_TO_STATUS table unless the severity and/or the status enumerations are customized.

BMC_SLOT_FORMULAS data class

The SLOT_FORMULAS class is used to map event slots to other slots when processing a new raw event.

Figure 33 SEVERITY_TO_STATUS definition

MC_PUBLISH_DATA_CLASS:BMC_SEVERITY_TO_STATUS ISA BMC_SIM_DATA DEFINES{

severity: SEVERITY, key = yes;status: MC_SM_COMPONENT_STATUS, key = yes;

};END

BMC_TIME_SCHEDULE data class


BMC_SLOT_FORMULAS data class definition

Figure 34 shows the BAROC definition of the SLOT_FORMULAS class, which is located in the mc_sm_event_mapping.baroc file.

BMC_TIME_SCHEDULE data class

The BMC_TIME_SCHEDULE data class defines a service schedule.

Figure 35 shows the BAROC definition of the BMC_TIME_SCHEDULE class, which is located in the mc_sm_root.baroc file.

BMC_TIME_FRAME_TO_SCHEDULE data class

The BMC_TIME_FRAME_TO_SCHEDULE data class maps time frames to schedules. As part of the mapping, it indicates whether the time frame contains During Schedule or Exceptions Within During Schedule time.

Figure 36 on page 201 shows the BAROC definition of the BMC_TIME_FRAME_TO_SCHEDULE class, which is located in the mc_sm_root.baroc file.

Figure 34 BMC_SLOT_FORMULAS definition

MC_PUBLISH_DATA_CLASS: BMC_SIM_ALIAS ISA BMC_SIM_DATA DEFINES { ComponentAlias: STRING, key=yes; ComponentID: STRING; };

END

Figure 35 BMC_TIME_SCHEDULE definition

MC_PUBLISH_DATA_CLASS : BMC_TIME_SCHEDULE ISA BMC_SIM_DATA DEFINES { Name : STRING; Description : STRING; status: MC_SM_SCHEDULE_STATUS, read_only=YES,parse=NO; };END

BMC_SELF_PRIORITY_MAPPING data class


BMC_SELF_PRIORITY_MAPPING data class

The BMC_SELF_PRIORITY_MAPPING data class contains the resulting self priorities for each combination of base priority mapped against component status.

Figure 37 shows the BAROC definition of the BMC_SELF_PRIORITY_MAPPING class, which is located in the mc_sm_root.baroc file.

BMC_SERVICE_SCHEDULE_CONFIG data class

The BMC_SERVICE_SCHEDULE_CONFIG data class contains the settings for the priority formula, the default schedule, and the list of classes which are priority propagators by default.

Figure 38 shows the BAROC definition of the BMC_SERVICE_SCHEDULE_CONFIG class, which is located in the mc_sm_root.baroc file.

Figure 36 BMC_TIME_FRAME_TO_SCHEDULE definition

MC_PUBLISH_DATA_CLASS : BMC_TIME_FRAME_TO_SCHEDULE ISA BMC_SIM_DATA DEFINES { Timeframe : STRING, key=yes; Schedule : STRING, key=yes; Included : MC_YESNO, default=YES; };END

Figure 37 BMC_SELF_PRIORITY_MAPPING definition

MC_PUBLISH_DATA_CLASS : BMC_SELF_PRIORITY_MAPPING ISA BMC_SIM_DATA DEFINES { priority : MC_PRIORITY, key=yes; status :MC_SM_COMPONENT_STATUS, key=yes; self_priority : MC_PRIORITY; }; END

Figure 38 BMC_SERVICE_SCHEDULE_CONFIG definition

MC_PUBLISH_DATA_CLASS : BMC_SERVICE_SCHEDULE_CONFIG ISA BMC_SIM_DATA DEFINES { PriorityFormula : PRIORITY_FORMULA, default = WEIGHTED, key=yes; };END

BMC_STATUS_TO_SEVERITY data class


BMC_STATUS_TO_SEVERITY data class

The BMC_STATUS_TO_SEVERITY class is used to map the status value of an impact event to a severity value that will participate in the computation of the self status for the associated CI.

Figure 39 shows the BAROC definition of the BMC_STATUS_TO_SEVERITY class, which is located in the mc_sm_root.baroc file.

SIM_TIME_FRAME class

The SIM_TIME_FRAME class defines a time period that can be used as part of a schedule.

Figure 40 shows the BAROC definition of the BMC_STATUS_TO_SEVERITY class, which is located in the mc_sm_root.baroc file.

SIM_CellAlias class

The SIM_CellAlias class is assigned to cells and used for publishing. The class maps a cell alias to a real cell name. Cell aliases can be remapped to different cells for different test environments.

The definition of the SIM_CellAlias class is located in the cellalias.def file.

Figure 39 BMC_STATUS_TO_SEVERITY definition

MC_PUBLISH_DATA_CLASS:BMC_STATUS_TO_SEVERITY ISA BMC_SIM_DATA DEFINES{

status: MC_SM_COMPONENT_STATUS, key = yes;severity: SEVERITY, key = yes;

};END

Figure 40 SIM_TIME_FRAME definition

SIM_TIME_FRAME;mc_udid='SMS_DEFAULT_TIMEFRAME';description='sms.defaulttimeframe.description';name='sms.defaulttimeframe.name';dtstart='20060101T000000';duration='P1D';interruptions=[];tzid='';rdate=[];rrule=['FREQ=DAILY;INTERVAL=1;WKST=SU'];exdate=[];exrule=[];

END

SIM_CellInformation class


SIM_CellInformation class

The SIM_CellInformation class stores cell connection information (similar to mcell.dir). Additionally, it contains a field which specifies whether the cell is a production cell or a test cell.

BMC_PROMOTION_LOG class

BMC_PROMOTION_LOG is a log object created for each user promotion. The object tracks data such as promoted objects, users who initiated the promotion, promotion start and end times, and the status of the promotion (in progress, success, or failed).

Service model event classesThe service model implements event structures. These event structures are in the form of BAROC event classes. The file containing the root class definitions, mc_sm_root.baroc, is in the MCELL_HOME\server\etc\cellName\kb\ directory.

CORE_EVENT base class

CORE_EVENT is the base class for all BMC ProactiveNet Performance Management event classes. This base class is defined in mc_root_internal.baroc file, and extended in the mc_root_redef.baroc file. It is not specific to the service model, but it includes slots specifically for service impact management functionality.

CORE_EVENT partial data class definition

Figure 41 on page 204 shows the BMC ProactiveNet-related definition of the class. For a complete description of all event class slots, see BMC Impact Solutions Knowledge Base Development Reference Guide.

CORE_EVENT base class


Figure 41 Partial CORE_EVENT definition

MC_EV_CLASS : CORE_EVENT DEFINES { event_handle : INTEGER, parse = no, read_only = yes; mc_ueid : STRING, read_only = yes; mc_client_address : STRING, parse = no; adapter_host : STRING; mc_location : STRING; mc_service : STRING; mc_host_class : STRING; mc_host : STRING; mc_host_address : STRING; mc_host_id : INTEGER, hidden = yes; mc_account : STRING; mc_object_class : STRING; mc_object : STRING; mc_object_uri : STRING; mc_object_owner : STRING; mc_tool_class : STRING; mc_tool : STRING; mc_tool_id : STRING; mc_tool_rule : STRING; mc_tool_key : STRING; mc_tool_sev : STRING; mc_tool_address : STRING; mc_tool_uri : STRING; mc_tool_time : INTEGER, representation = date; mc_tool_suggestion : STRING; mc_origin_class : STRING; mc_origin : STRING; mc_origin_key : STRING; mc_origin_sev : STRING; mc_parameter : STRING; mc_parameter_value : STRING; mc_parameter_unit : STRING; mc_parameter_threshold : STRING; mc_event_category : MC_EVENT_CATEGORY; mc_event_subcategory : MC_EVENT_SUBCATEGORY, default=OTHER; mc_event_model_version : STRING, default = '1.1.00'; mc_incident_time : INTEGER, representation = date; mc_incident_report_time : INTEGER, representation = date; mc_arrival_time : INTEGER, representation = date; mc_local_reception_time : INTEGER, representation = date; date_reception : INTEGER, representation = date; date : STRING, hidden=yes; status : STATUS, default = OPEN; severity : SEVERITY, default = WARNING; mc_original_severity : SEVERITY, parse = no; mc_priority : MC_PRIORITY, default = PRIORITY_5; mc_original_priority : MC_PRIORITY, parse = no; mc_owner : STRING; mc_long_msg : STRING; msg : STRING; duration : INTEGER, parse = no;mc_timeout : INTEGER; repeat_count : INTEGER; mc_action_count : INTEGER; administrator : STRING; mc_acl : LIST_OF STRING, parse = no; mc_date_modification : INTEGER, representation = date; mc_notes : LIST_OF STRING, hidden = yes; mc_operations : LIST_OF STRING, hidden = yes; mc_notification_history : LIST_OF STRING, hidden = yes; mc_bad_slot_names : LIST_OF STRING; mc_bad_slot_values : LIST_OF STRING; mc_history : LIST_OF STRING, hidden = yes; mc_modhist : LIST_OF STRING, hidden = yes; mc_propagations : LIST_OF STRING, parse = no; mc_collectors : LIST_OF STRING, parse = no, hidden = yes; mc_abstraction : LIST_OF INTEGER, parse = no, hidden = yes; mc_abstracted : LIST_OF INTEGER, parse = no, hidden = yes; mc_associations : LIST_OF STRING, parse = no, hidden = yes; mc_cause : INTEGER, parse = no, hidden = yes; mc_effects : LIST_OF INTEGER, parse = no, hidden = yes; mc_event_relations : LIST_OF STRING, parse = no, hidden = yes; mc_relation_source : STRING;

Root event class


CORE_EVENT slots

The CORE_EVENT slots are listed in BMC Impact Solutions Knowledge Base Development Reference Guide.

Root event class

The MC_SMC_ROOT event class is used to isolate the service management events from the other branches of the event hierarchy and, more specifically, to distinguish among the events associated with a component, those which come from the outside, and those which have been generated internally.

Figure 42 shows the BAROC definition of the MC_SMC_ROOT class, which is located in the mc_sm_root.baroc file.

The service model root event class branches into two subclasses: a history event class and an impact event class.

History event class

The history event class, SMC_STATE_CHANGE, is an internal event class used to trace the status changes of components.

mc_smc_id : STRING; mc_smc_alias : STRING; mc_smc_impact : MC_SMC_IMPACT, default=NOT_ELECTED; mc_smc_type : STRING; mc_smc_priority : REAL, parse=no, read_only=yes; mc_smc_causes : LIST_OF STRING, parse = no, hidden=yes; mc_smc_effects : LIST_OF STRING, parse = no, hidden=yes; itsm_category : STRING; itsm_type : STRING; itsm_item : STRING; itsm_product_name : STRING; itsm_model_version : STRING; itsm_manufacturer : STRING; itsm_operational_category1 : STRING; itsm_operational_category2 : STRING; itsm_operational_category3 : STRING; itsm_company : STRING; itsm_location : STRING; pn_detail_diag : INTEGER, hidden = yes; pn_detail_diag_count : INTEGER, hidden = yes; pn_device_name : STRING; };

Figure 42 MC_SMC_ROOT definition

MC_EV_CLASS : MC_SMC_ROOT ISA EVENT;END

Impact event class


Figure 43 shows the BAROC definition of the SMC_STATE_CHANGE class, which is located in the state.change.baroc file.

Events of class SMC_STATE_CHANGE are automatically generated and associated with their component by the cell. As history events, they are not used in the status computation process.

Impact event class

The MC_SMC_EVENT internal event class should be used as the abstract class when abstracting raw events into service model events. The BAROC definition of the class follows.

Figure 44 shows the BAROC definition of the MC_SMC_EVENT class, which is located in the mc_sm_root.baroc file.

Events of class MC_SMC_EVENT, or any custom subclass of that class, are not used in the status computation process.

Figure 43 SMC_STATE_CHANGE definition

MC_EV_CLASS:SMC_STATE_CHANGE ISA EVENT DEFINES{mc_smc_id: STRING, dup_detect=yes ;smc_status: SIM_NOTIFICATION_STATUS;smc_previous_status: SIM_NOTIFICATION_STATUS;msg: default='A Service Management Component status has changed';mc_smc_impact: default=NON_ELECTABLE;};END

Figure 44 MC_SMC_EVENT definition

MC_EV_CLASS:MC_SMC_EVENT ISA MC_CELL_EVENT DEFINES{mc_smc_impact: MC_SMC_IMPACT, default = ELECTED;component_sub_type: STRING;component_name: STRING;};END


A p p e n d i x CC Upgrading a service model to BMC Atrium CMDB

This appendix describes the considerations and steps to upgrade from a BMC ProactiveNet environment that does not employ BMC Atrium CMDB, to an environment that does employ BMC Atrium CMDB.

Upgrading from non-Atrium-CMDB SIM to BMC Atrium CMDB SIM

When you have implemented service impact management without the BMC Atrium CMDB product and now want to use the BMC Atrium CMDB to store and manage service components and their relationships, you can upgrade service model data from BMC ProactiveNet to the BMC Atrium CMDB by using the sim2cmdb tool. The sim2cmdb tool facilitates the migration of a non-BMC Atrium CMDB service impact management implementation to a solution where BMC Atrium CMDB stores and manages service components and their relationships. The sim2cmdb tool populates the BMC Atrium CMDB with service model data from BMC ProactiveNet.

Service impact management without the BMC Atrium CMDB product means that you have created component instances and relationships directly in BMC ProactiveNet by using Direct Feed (through BMC ProactiveNet, mposter CLI command, or rules) or by using Direct Publish (a BAROC source file and the pposter CLI command) or that you are using a third-party database for service model data.

Upgrading SIM data that originates from third-party source


Upgrading SIM data that originates from third-party source

If you have a third-party repository for your service model, you do not have to use the sim2cmdb tool to copy it into the BMC Atrium CMDB. It is probably more efficient to import this data into the BMC Atrium CMDB directly from the third-party repository than to use the data in the cell as the interface between these two repositories. Once the initial model is imported into the BMC Atrium CMDB, BMC recommends that you make further changes to the model directly in the BMC Atrium CMDB. sim2cmdb is intended as an upgrade tool to be used when the main repository of service impact manage data is actually the cell; it is not a way to keep a third-part repository in sync with the BMC Atrium CMDB.

Recommended upgrade stepsUse the following process to ensure the most uneventful upgrade to service impact management implementation with the BMC Atrium CMDB.

1 Review and understand how the sim2cmdb upgrade works.

2 Ensure you have quality data in the BMC Atrium CMDB.

3 Analyze and understand the data in the cell so you know how it will be identified and reconciled in the BMC Atrium CMDB.

4 Modify the sim2cmdb.conf file as needed.

5 Run sim2cmdb without any command to verify the data.

Running sim2cmdb without any command verifies if the data is qualified for the BMC Atrium CMDB, generating a detailed output file which lists all the data to be imported and detects any dropped or skipped instances. The dropped or skipped instances are those that could cause potential issues when Running sim2cmdb with the commit option. The output file is explained in the section, “Reviewing the output files for sim2cmdb” on page 222.

6 Repair the offending data in the cell.

7 Repeat steps 5 and 6 until no more data is excluded.

8 Run the sim2cmdb command with the commit option.

When commit is requested, you want as much data as possible to be upgraded. Consequently, set the ContinueOnSkip parameter to T (default is F). For more information about commitment, see “Upgrade commitment” on page 225.

Understanding how the upgrade works


9 Verify that the output file contains no excluded data.

10 Verify that publication was successful.

You can verify if the publication is successful by using CMDB tools or SIM tools. If the data is not automatically published to SIM, you need to diagnose the failure, and, if necessary, repair the data in BMC.ASSET and republish the data using the publishing server client.

11 Check the output file for unidentified CIs. Identify them manually, and reconcile. For more information, see “CI identification” on page 226

12 Verify that publication was successful.

If publication was not successful, diagnose failure and, if necessary, repair data in BMC.ASSET and publish again.

13 If in step 9 data you discovered excluded data, repair the offending data in the cell and restart this procedure from step 5.

Verify that all expected data (especially impact relationships) are exported. You might need to upgrade DirectFeed data, too.

14 When all data from the publish environment is upgraded, close the upgrade.

15 When DirectPublish cell data is upgraded to BMC Atrium CMDB, close the publish environment.

The following sections explain some of these steps in greater detail.

Understanding how the upgrade works

To upgrade service model data to the BMC Atrium CMDB product, you execute the sim2cmdb CLI command. sim2cmdb takes the service model data and the management data in the cell of a specific publish environment and copies the data to a BMC Atrium CMDB dataset, BMC.SIM, where it is reconciled into the BMC.ASSET (production) dataset. When reconciliation terminates, the data is automatically (or manually) published back to the cell. In other words, the CI that was originally created directly in the cell is replaced with a CI from BMC Atrium CMDB.

NOTE If more excluded data is found in the output file, continue through step 12.

Ensuring quality data in BMC Atrium CMDB


Replacement in the cell is based on

■ for CIs—the ComponentAliases attribute

Even CIs without a value in the ComponentAliases attribute are replaced by sim2cmdb, because if ComponentAliases for a CI is empty, it is assigned the mc_udid as a default.

■ for impact relationships—the consumer_id and provider_id attributes■ for management data—key attributes of the class

Best practice for service models with CIs in multiple cells is to upgrade all the involved cells at the same time.

If the service model data you want to import into the BMC Atrium CMDB is from a secure publish environment, you must provide authentication information in the sim2cmdb CLI command string.

Ensuring quality data in BMC Atrium CMDB

Before you can upgrade to BMC Atrium CMDB, component data that was created directly in the cell must be qualified. Qualified data means that the data complies with the normalization rules required by the BMC Atrium CMDB so that duplicate CIs can be prevented. Normalization is achieved when a CI from multiple sources is identified by the Reconciliation Engine as the same CI.

To ensure quality data in the BMC Atrium CMDB, you must

■ consider the classes under which component instances were created in the cell. Are they valid classes for BMC Atrium CMDB?

■ consider the attributes for each class under which you have created components in the cell

To guarantee qualified data, data imported to BMC Atrium CMDB has to follow the normalization rules. The BMC Atrium Common Data Model Normalization Guidelines whitepaper provides general guidelines for data normalization on major IT component classes. A CI created directly in the cell needs to have the required slot values assigned and the values must follow the normalization formula addressed in BMC Atrium Common Data Model Normalization Guidelines.

NOTE The final set of data in BMC.ASSET (after reconciliation and publication) is not necessarily the same as it was in the cell, because this depends on existing data in BMC.ASSET and the precedences of the reconciliation.

Identifying components and data reconciliation



A default reconciliation job “BMC SIM to CMDB Migration - Identification and Merge” is provided for the sim2cmdb tool. It is installed on the BMC Atrium CMDB when BMC ProactiveNet CMDB Extensions are installed. The reconciliation job defines the data identification rules and identification activities for both component instances and management data instances.

■ For IT component classes, the identification is “best match” rule. Attributes that participate in the identification rules are defined by the requirements in BMC Atrium CMDB data normalization. If the Auto Identify flag for identification activity is set to NO, it means that the ReconciliationId value will not be assigned to the CI during the reconciliation process, therefore the instance (CI) will not get pushed to the master dataset (BMC.ASSET by default).

■ For logical business classes (for example, BusinessProcess and BusinessService), SIM is the authoritative source, so the Auto Identify flag is set to Yes and the reconciliation ID is assigned automatically.

■ BMC_BusinessProcess.SourceLocation is set to SIM in BMC Atrium CMDB by sim2cmdb.

■ For management data, sim2cmdb uses identification rules that are based on the cell’s key slots. The reconciliation ID is automatically assigned.

■ If you do not use any discovery tools to push data into the BMC Atrium CMDB, you can enable auto identify on all identification rules (before you run sim2cmdb) so that no manual identification is necessary. Be careful; keeping unique CIs in the BMC Atrium CMDB Master Dataset is a very important BMC Atrium CMDB concept. You should only enable the auto identification on all rules if you are certain the action will not create duplicate CIs in the BMC Atrium CMDB.

■ If a CI is not auto identified, then you must manually identify the CI. Refer to the three options as explained in the section, “CI identification” on page 226.

NOTE If ITSM is installed, then certain attributes (Category, Type, Item, Model, ManufacturerName) of a CI have to correspond with the attributes of existing products (Tier1, Tier2, Tier3, Product Name, Manufacturer) in the catalog before performing a sim2cmdb commit. If these attributes fail to correspond, the commit will fail when executed.

For more information about how to create entries in the product catalog, how to create product catalog alias mappings, and how to work with trusted datasets for the product catalog see the supplied ITSM documentation.



sim2cmdb has a default set of identification groups for identifying the components in the BMC Atrium CMDB. Table 56 lists these identifying components.

■ base class that the identification is defined on■ classes that inherit the identification group■ best match attributes that are used in the rule■ value of the auto-identification flag

Table 55 Identifying components in the BMC Atrium CMDB

Base class of the identification group Classes that inherit the rule Best match attributesAuto-identify

BMC_Activity Name Yes

BMC_Application NameApplicationType

No

BMC_ApplicationInfrastructure NameApplicationInfrastructureType

No

BMC_ApplicationService NameSystemNameSystemClassId

No

BMC_BaseElement BMC_DataBaseBMC_ApplicationSystemBMC_ClusterBMC_ConnectivityCollectionBMC_ConnectivitySegmentBMC_IPConnectivitySubnetBMC_LNsCollectionBMC_LANBMC_WAN

Name No

BMC_BusinessProcess NameSourceLocation

Yes

BMC_BusinessService Name Yes

BMC_ComputerSystem BMC_MainframeBMC_VirtualSystem

HostNameDomainSerialNumber

No

BMC_HardwareSystemComponent BMC_MediaBMC_CDROMDriveBMC_DiskDriveBMC_FloppyDriveBMC_TapeDriveBMC_UPS

NameSystemNameSystemClassIdSerialNumber

No

BMC_IPXConnectivityNetwork NameNetworkNumber

No

BMC_LogicalSystemComponent BMC_FileSystemBMC_DataBaseStorageBMC_LocalFileSystemBMC_RemoteFileSystemBMC_DiskPartitionBMC_SystemResource

NameSystemNameSystemClassId

No

BMC_Organization Name Yes



The reconciliation rules for management data are based on the key slots of the classes.

BMC_SoftwareServer NameSoftwareServerType

No

BMC_SystemSoftware BMC_OperatingSystem NameSerialNumberVersionNumber

No

BMC_UserCommunity Name Yes

BMC_VirtualSystemEnabler NameSystemNameSsytemClassId

No

BMC_VMWare NameSystemNameSystemClassIdVMImageName

No

Table 56 Key slots in reconciliation rules for management data

Class Keys Auto-identify

BMC_COST_OF_DOWNTIME_PRIORITY_MAPPING nameself_priority

Yes

BMC_DOWNTIME_STATUS_CONFIG Yes

BMC_PROPAGATION_MAP namerelationship_stateprovider_status

Yes

BMC_SELF_PRIORITY_MAPPING prioritystatus

Yes

BMC_SERVICE_SCHEDULE_CONFIG Yes

BMC_SEVERITY_TO_STATUS severitystatus

Yes

BMC_SIM_MATCH_TABLE taginput_match

Yes

BMC_SLOT_FORMULAS event_class Yes

BMC_STATUS_COMPUTATION model_name Yes

BMC_STATUS_PROPAGATION nameprovider_typeconsumer_type

Yes

BMC_STATUS_TO_SEVERITY statusseverity

Yes

BMC_TIME_FRAME_TO_SCHEDULE TimeframeSchedule

Yes

BMC_TIME_SCHEDULE Yes

Table 55 Identifying components in the BMC Atrium CMDB

Base class of the identification group Classes that inherit the rule Best match attributesAuto-identify

Data imported into BMC.SIM


You can modify the reconciliation rules and identification activities according to the nature of your data, but do not change the name of reconciliation job.

Data imported into BMC.SIM

This section describes factors that affect the data imported into the BMC.SIM dataset.

If the ContinueOnSkip parameter of the sim2cmbd.conf file is set to =T (true), data will be imported in BMC.SIM, even if some of the data cannot be imported. If the parameter is set to =F (false), then if some of the data cannot be imported, no data is imported. In both cases the data that cannot be imported is to the output file with a message describing the reason for the failure to import.

When Diary (Notes in SIM) are imported from SIM to CMDB, the Notes slot is not imported as multiple entries. All entries are concatenated into a single string and imported as one entry.

Weak relationships

If the relationship is a weak relationship, its destination member, called the weak member, cannot exist without its source member, called the strong member. A weak relationship creates a logical composite object consisting of both member CIs.

In BMC Atrium CMDB, the strong members are the CIs derived from BMC_System class and the weak members are the CIs derived from BMC_SystemComponent or BMC_SystemService. An example of BMC_System class is BMC_ComputerSystem and an example of BMC_SystemComponent class is BMC_FileSystem. Normally, since a FileSystem can not exist without a ComputerSystem, sim2cmdb creates a weak relationship between them. So, an instance of BMC_HostedSystemComponents is created, which is a logical composite object consisting of both member CIs.

For CIs whose class is derived from BMC_SystemComponent or BMC_SystemService, BMC recommends that you set a value in the SystemName slot so that a weak relationship can be created when sim2cmdb runs.

If a BMC_SystemComponent or BMC_SystemService object has a value in the SystemName slot, sim2cmdb attempts to create the following two weak relationships during the import process:

BMC_WORST_SLA_STATE_PRIORITY_MAPPING namesla_state

Yes

SIM_TIME_FRAME Yes

Table 56 Key slots in reconciliation rules for management data

Class Keys Auto-identify

sim2cmdb CLI command


Possible Import Results

Table 57 lists possible import results for specific circumstances.


Before you run sim2cmdb

For Direct Feed data—If you have not previously published data from BMC Atrium CMDB to a cell, then before executing a sim2cmdb, you must execute the CLI command pinit -n cellName. This prevents the default management data from being upgraded as part of the execution of sim2cmdb.

Source (Strong member) Weak relationship Destination (Weak member)

BMC_System BMC_HostedSystemComponents BMC_SystemComponent

BMC_System BMC_ HostedService BMC_SystemService

Table 57 Possible import results

Condition Result

a relationship has only one endpoint in BMC Atrium CMDB

■ the relationship is not created in BMC Atrium CMDB■ the endpoint CI in BMC Atrium CMDB is not affected■ if ContinueOnSkip is true, the relationship is not

imported■ if ContinueOnSkip is false, none of the data is imported

a CI belongs to an abstract class in the cell

■ the CI and any relationships to the CI are not imported into BMC Atrium CMDB

■ the CI and relationships are listed in the output file■ if ContinueOnSkip is true, the CI and relationships are

not imported■ if ContinueOnSkip is false, none of the data is imported

a weak CI points to a strong CI that does not exist in BMC Atrium CMDB

■ the weak relationship is not created■ the no-strong member message is listed in the output file■ if ContinueOnSkip is true, the CI without a strong

relationship is imported, but the weak relationship is not created

■ if ContinueOnSkip is false, none of the data is imported

a value for HomeCellAliases is not found for a CI

■ the CI is not imported into BMC Atrium CMDB■ the not found message is written to the output file■ if ContinueOnSkip is true, the CI is not imported■ if ContinueOnSkip is false, none of the data is imported



sim2cmdb.conf file and parameters

Table 58 describes the sim2cmdb.conf file which contains properties and parameters for managing the sim2cmdb CLI command.

Modify the following parameters in particular to suit your specific requirements before you execute sim2cmdb.

■ ContinueOnSkip■ ReverseCellAliases■ ReconJobTimeout

Table 58 sim2cmdb.conf file (part 1 of 3)

Filename sim2cmdb.conf

File path MCELL_HOME/etc

Description contains the sim2cmdb CLI command configuration properties

Parameter name Description Default value

IASServers specifies the Impact Administration Server (usually by host name) against which the CLI commands authenticate

CLI commands may be executed on a computer other than the computer on which Impact Administration Server is installed.

If you specify a remote Impact Administration Server in the sim2cmdb.conf file, but do not provide user credentials, you must provide them as command line arguments when you run a CLI command.

If the Impact Administration Server has a backup server, then you can specify the primary server as well as the secondary server. If the primary is not running, then the CLI will authenticate against the secondary server.

none

IASUserName specifies a valid Impact Administration Server user name to be presented as credentials to the specified Impact Administration Server

none



IASPassword specifies the valid Impact Administration Server password for the specified Impact Administration Server (IASUserName) to be presented as credentials for the specified Impact Administration Server

Enter the IASPassword as plain text. Upon the first execution, it is encrypted.

To set up remote automatic authentication of CLI commands, specify the user name (IASUserName), and password (IASPassword) to be used as valid credentials for the specified Impact Administration Server (IASServers) in the sim2cmdb.conf file.

none

ARSXLongTimeOut sets the time to stop waiting on a BMC Remedy AR System operation that occurs slowly

1800

ARSXLongTimeOutEstimate enables (T) or disables (F) the use of the estimate when the length of time exceeds the value that is calculated for committing bulk entry transactions

T (true)

ContinueOnSkip defines sim2cmdb behavior if one or more instances cannot be imported

If ContinueOnSkip is set to T, true, instances that can be imported are imported and instances that cannot be imported are not imported. The output file contains the list of instances that could not be imported.

If ContinueOnSkip is set to F, false (default), the occurrence of even one instance that cannot be imported results in no data being created in the BMC Atrium CMDB. In other words, if all instances can be imported, all data (with attributes) in BMC.SIM is exactly as it is in the cell. If even one instance cannot be imported, only previously existing data in BMC.SIM still exists. The output file indicates the results.

F (false)

ReverseCellAliases specifies which alias corresponds to which cell

Format: cellName, cellAlias{, cellName, cellAlias}

When several aliases point to the same cell, retrieving an alias from a cell name is not deterministic. With the ReverseCellAliases parameter, you can specify which alias corresponds to which cell. It should have only one cellAlias for a cell in ReverseCellAliases. The letters in cellAlias value are case sensitive.

If this parameter is not set, sim2cmdb makes an undefined, arbitrary choice.

none


Running the upgrade


Running the upgrade

sim2cmdb is executed as a CLI command.

sim2cmdb syntax

The three commands of sim2cmdb are close, commit, and identify. Unless you specify one of these commands, sim2cmdb will execute in default command, meaning that it will only verify the data. See “Upgrade commitment” on page 225, “CI identification” on page 226, and “Dataset cleanup” on page 227 for more information about each of these commands.

sim2cmdb command options

Table 59 lists the options for the sim2cmdb command.

ReconJobTimeout sets the length of time that sim2cmdb checks for the termination of the reconciliation job

If the interval expires before the reconciliation job completes, the sim2cmdb output file does not indicate the results of the reconciliation job. It may or may not have completed successfully.

120 (seconds)

CommitRetryTimeOut defines the length of time, in seconds, that sim2cmdb retries the bulk entry transaction

If the transaction failed due to the data problem, sim2cmdb will drop the offending data and retry the transaction. sim2cmdb will successfully commit good data into CMDB within the time specified by the CommitRetryTimeOut parameter or terminates the transaction if it exceeds the time specified by the CommitRetryTimeOut parameter.

900 (seconds)

PublishingServerName the name of the publishing server

This name is used in validating the publish environment and for DirectPublish credentials.

none

sim2cmdb [-c ConfigFile] [-h|-?] [-i User/Password [@Host[/Port] [,Host[/Port][,...]]] [-l HomeLocation] {-p "Var=Value"} [-v] [-z] [-f] [-q] [-e EnvId1[,EnvId2[...]] [-n Cell1[,Cell2[...]] [-o OutputFile] [close | commit | identify]


Running the upgrade


Table 59 sim2cmdb command options

Options Description

<common options>-c -h -? -i -q -l -p -v -z

see BMC ProactiveNet Command Line Interface Reference Manual

-e EnvIDenvID1[,envID2[...]]

identifies the specific environments

If an environment is not specified, then Direct Feed data is upgraded.

If you are upgrading Direct Feed data only, EnvID must be empty; do not use the -e option for Direct Feed data.

For example, the following command displays all the Direct Feed data present in the cell to be upgraded

sim2cmdb –v –n <cellname>

For secured environments, you must provide a valid password using the –p "password=xx" option. If multiple EnvID options are specified, you must provide a password value for each EnvID.

If one of the EnvID command options fails during environment verification, the sim2cmdb execution terminates.

If both Direct Feed data and Direct Publish data must be imported, the Direct Publish EnvIDs as well as one empty EnvID has to be specified with –e option. To display data in Direct Feed and Direct Publish environments, use one of the following examples:

sim2cmdb –v –n <cellname> -e “,DirectPubEnvId1,DirectPubEnvId2”

sim2cmdb –v –n <cellname> -e “DirectPubEnvId1,DirectPubEnvId2,”

sim2cmdb –v –n <cellname> -e “DirectPubEnvId1,,DirectPubEnvId2”

The comma (,) at the beginning, end, or middle of the option represents an empty EnvID.

-f forces the command execution without prompting you to confirm the action

If you do not specify the -f option, you must confirm the action when prompted to allow the action to execute.

Running the upgrade


-n cellName1[,cellName2[...]]

specifies the specific cell or cells from which to retrieve the service model classes

On Windows platforms, you must enclose the cell list in quotation marks (").

If no cell name is specified and there is an –e option, all the cells involved in the EnvIds are included. If there is no –e option, all the cells in the AtriumCMDB PROD environment will be included.

If one of the cells fails during cell verification, the sim2cmdb execution terminates.

-o ReportFileName file that contains the report of sim2cmdb execution, in other words, the list of data that will be imported into BMC Atrium CMDB and a list of data that will not be imported into BMC Atrium CMDB, and a list of errors that have occurred

BMC Software recommends examining this report each time you run sim2cmdb. You might need to correct the SIM date before executing sim2cmdb again.

If you omit this option, sim2cmdb generates a default report file name.

-p Password= specifies the password for each environment listed in the -e option, if a password is required for the environment

Separate additional passwords with commas (,)

For example, if three environments exist, and environment 2 has no password (is unsecured), the command might look like this:

sim2cmdb -e "Env1, NoSecEnv,Env3" -n cell -p "Password=pw1, ,pw3"

close removes all the instances in the BMC.SIM dataset

Although you can force removal of all the data in the BMC.SIM dataset, if the dataset is not clean you should first return to the CI identification stage to identify CIs. Forcing removal of unidentified CIs can cause unsynchronized data between SIM and CMDB.


Options Description

Running the upgrade


sim2cmbd CLI command examples

sim2cmdb -e testEnv -i user/user

Verifies imported data. Data are from all the cells in the direct publish environment testEnv.

sim2cmdb -e testENV -n cellA -i user/user

Verifies imported data. Data are from cell cellA in the direct publish environment testEnv.

sim2cmdb -n cellB -i user/user

Verifies imported data. Data are from cellB created from direct feed.

sim2cmdb -e testSecuredEnv -i user/user -p Password=mypasswd

Verifies imported data from the secured environment testSecuredEnv with the password parameter.

sim2cmdb -n cellS1, cellS2 -i user/user -p Password=passwd1,passwd2

Verifies imported data from multiple cells with multiple password parameters.

sim2cmdb -e testEnv commit

Runs the commit command to import data into the BMC Atrium CMDB. The reconciliation and publish process takes place following the success of the commit.

sim2cmdb -i user/user identify

commit imports the SIM data into the CMDB BMC.SIM dataset

Upon a successful commit, sim2cmdb automatically starts the reconciliation job to merge data into the BMC.ASSET dataset.

identify assigns a ReconciliationIdentity value to the components in BMC.SIM which have not been identified.

See “CI identification” on page 226 for more information.


Options Description

Reviewing the output files for sim2cmdb


Assigns the ReconciliationId to the CIs in the BMC.SIM dataset if they are not automatically identified. The reconciliation and publish process takes place following the success of the commit.

sim2cmdb close

Removes all the data in the BMC.SIM dataset.


The output files report on the results of sim2cmdb execution. The output includes

■ the sim2cmdb command string that you entered

■ an indication of the success or failure of user authentication

■ an indication of the success or failure of connection to the BMC Remedy AR System

■ a list of instances in the cell that will be copied to the BMC Atrium CMDB (Exporting service impact data from cells)

■ a list of instances that could not be imported into the BMC Atrium CMDB with the reason (Importing service impact data into CMDB’s dataset BMC.SIM)

If there are no issues with the data, this section of the output file is blank; only data instances that cannot be imported will be listed here.

■ an indication of the success or failure of the reconciliation job with a list of instances that you must manually reconcile (BMC SIM to CMDB reconciliation into CMDB’s data BMC.ASSET)

■ an indication of the success or failure of the sim2cmdb execution

Figure 45, Figure 46, and Figure 47 are examples of an output files.



Figure 45 Example output file without commitsim2cmdb -e JZTest -n hou-jezhou-37 -o JTest_Data_Warning_no_commit.log -mSun, 24 Feb 2008 11:31:42:454 CST

User jean successfully authenticated with IAS.

User Demo successfully connected to AR System hou-jezhou-37:0.

==================================================================Exporting service impact data from cell(s).==================================================================

ellName:hou-jezhou-37Components - 1. BMC_ComputerSystem; mc_udid=JZTest_Computer_1; ComponentAliases=[JZTest_Computer_1]; AccountID=JZTest1; Description='test one end relationship publish Computer'; Name=JZTest_Computer_1; OwnerContact='713.918.8800'; OwnerName=jean; Type=WINDOWS_SYSTEM; HostName=JZTest_1;2. BMC_ComputerSystem; mc_udid=JZTest_Computer_2; ComponentAliases=[JZTest_Computer_2]; AccountID=JZTest2; Description='simple test sim2cmdb 2'; Name=JZTest_Computer_2; OwnerContact='713.918.8800'; OwnerName=jean; Type=WINDOWS_SYSTEM; HostName=JZTest_2;3. BMC_FileSystem; mc_udid=JZTest_Filesystem_2; ComponentAliases=[JZTest_Filesystem_2]; AccountID=JZTest2; Description='SIM2CMDB testing No SystemName, no weakrelationship'; Name=JZTest_Filesystem_2; SystemName=JZTest_Computer_2;4. BMC_FileSystem; mc_udid=JZTest_Filesystem_TestWK; ComponentAliases=[JZTest_Filesystem_TestWK]; AccountID=JZTest2; Description='SIM2CMDB testing weakrelationship'; Name=JZTest_Filesystem_TestWK; SystemName='SME-Computer-Test-WkRel';5. BMC_BusinessService; mc_udid=JZTest_BusService_4; ComponentAliases=[JZTest_BusService_4]; AccountID=JZTest4; Description='simple test sim2cmdb 2'; Name=JZTest_BusService_4; OwnerContact='713.918.8800'; OwnerName=jean;6. BMC_ComputerSystem; mc_udid=JZTest_Computer_4; ComponentAliases=[JZTest_Computer_4]; AccountID=JZTest4; Description='simple test sim2cmdb 2'; Name=JZTest_Computer_4; OwnerContact='713.918.8800'; OwnerName=jean; Type=WINDOWS_SYSTEM; HostName=JZTest_4;7. BMC_FileSystem; mc_udid=JZTest_Filesystem_4; ComponentAliases=[JZTest_Filesystem_4]; AccountID=JZTest4; Description='SIM2CMDB testing file to computer with weak_relationship'; Name=JZTest_Filesystem_4; SystemName=JZTest_Computer_4;8. BMC_FileSystem; mc_udid=JZTest_Filesystem_4_1; ComponentAliases=[JZTest_Filesystem_4_1]; AccountID=JZTest4; Description='SIM2CMDB testing Wrong SystemName'; Name=JZTest_Filesystem_4_1; SystemName=WrongSystemName;9. BMC_FileSystem; mc_udid=JZTest_Filesystem_4_2; ComponentAliases=[JZTest_Filesystem_4_2]; AccountID=JZTest4; Description='SIM2CMDB testing No SystemName'; Name=JZTest_Filesystem_4_2;Relationships - 10. BMC_Impact; mc_udid=JZTest_File2_To_Computer2; consumer_id=JZTest_Computer_2; provider_id=JZTest_Filesystem_2; AccountID=JZTest2;11. BMC_Impact; mc_udid=JZTest_Rel_ComputerToService_4; consumer_id=JZTest_BusService_4; provider_id=JZTest_Computer_4; AccountID=JZTest4;12. BMC_Impact; mc_udid=JZTest_File4_To_Computer4; consumer_id=JZTest_Computer_4; provider_id=JZTest_Filesystem_4; AccountID=JZTest2;13. BMC_Impact; mc_udid=JZTest_File4_1_To_Computer4; consumer_id=JZTest_Computer_4; provider_id=JZTest_Filesystem_4_1; AccountID=JZTest2;14. BMC_Impact; mc_udid=JZTest_File4_2_To_Computer4; consumer_id=JZTest_Computer_4; provider_id=JZTest_Filesystem_4_2; AccountID=JZTest2;

==================================================================Importing service impact data into CMDB's dataset BMC.SIM.==================================================================During the data import, the following issues were found:

1. BMC_FileSystem; mc_udid=JZTest_Filesystem_4_1; ComponentAliases='[JZTest_Filesystem_4_1]'; Name=JZTest_Filesystem_4_1; Warning: No System instance with Name WrongSystemName exists in CMDB or input data source. No relationship BMC_HostedSystemComponents with instance JZTest_Filesystem_4_1 is created.Reason/Suggestion: Please verify the valid System CI WrongSystemName is existing in either import source or in CMDB

2. BMC_FileSystem; mc_udid=JZTest_Filesystem_4_2; ComponentAliases='[JZTest_Filesystem_4_2]'; Name=JZTest_Filesystem_4_2; Warning: Slot SystemName has no value. No BMC_HostedSystemComponents relationship created with a BMC_SystemComponent instance.Reason/Suggestion: This CI is an instance of a subclass of BMC_SystemComponent. To create BMC_HostedSystemComponents relationship, it is required to have the SystemName slot value.

==================================================================Reconcile data in BMC.SIM dataset into BMC.ASSET dataset in CMDB==================================================================

The following CIs in BMC.SIM have not been automatically identified:

1. BMC_ComputerSystem; mc_udid=JZTest_Computer_1; ComponentAliases='[JZTest_Computer_1]'; Name=JZTest_Computer_1; 2. BMC_ComputerSystem; mc_udid=JZTest_Computer_2; ComponentAliases='[JZTest_Computer_2]'; Name=JZTest_Computer_2; 3. BMC_FileSystem; mc_udid=JZTest_Filesystem_2; ComponentAliases='[JZTest_Filesystem_2]'; Name=JZTest_Filesystem_2; 4. BMC_FileSystem; mc_udid=JZTest_Filesystem_TestWK; ComponentAliases='[JZTest_Filesystem_TestWK]'; Name=JZTest_Filesystem_TestWK; 5. BMC_ComputerSystem; mc_udid=JZTest_Computer_4; ComponentAliases='[JZTest_Computer_4]'; Name=JZTest_Computer_4; 6. BMC_FileSystem; mc_udid=JZTest_Filesystem_4; ComponentAliases='[JZTest_Filesystem_4]'; Name=JZTest_Filesystem_4; 7. BMC_FileSystem; mc_udid=JZTest_Filesystem_4_1; ComponentAliases='[JZTest_Filesystem_4_1]'; Name=JZTest_Filesystem_4_1; 8. BMC_FileSystem; mc_udid=JZTest_Filesystem_4_2; ComponentAliases='[JZTest_Filesystem_4_2]'; Name=JZTest_Filesystem_4_2;

lease identify them manually with Reconciliation Manager's Manual Identification Console.Then start a new "BMC SIM to CMDB" reconciliation job from Reconciliation Manager's Job History Console.

==================================================================sim2cmdb completed ==================================================================Please verify that the automated publication triggered by the reconciliation was successful, or execute a manual publication with cli publish and verify that it is successful



Figure 46 Example verify.log filesim2cmdb -e testPSR -i user/**** -o test_y_commit.log commitWed, 14 May 2008 09:49:51:954 CDT

IAS Server version: 7.2.00 [Build 1544526 - 29-Apr-2008]User user successfully authenticated with IAS server hou-jezhou-37:3084.

BMC Atrium CMDB version: 2.1.0.0User Demo successfully connected to AR System hou-jezhou-37:0.

Upgrade data of all cells of the publish environment(s).Using cell(s) hou-jz-37-psr for DirectPublish data of testPSR.

==================================================================Exporting service impact data from cell(s)==================================================================

Cell:hou-jz-37-psrComponents:1. BMC_BusinessProcess; mc_udid=BusProcess_Y; ComponentAliases=[BusProcess_Y]; AccountID=Y; Description='SIM2CMDB testing no-InstanceId, relationships'; Name=BusProcess_Y;2. BMC_ComputerSystem; mc_udid=Computer_Y; ComponentAliases=[Computer_Y]; AccountID=Y; Description='SIM2CMDB testing no-InstanceId, relationships'; Name=Computer_Y; Type=WINDOWS_SYSTEM; HostName=JZTest_1;3. BMC_FileSystem; mc_udid=FileSystem_Y; ComponentAliases=[FileSystem_Y]; AccountID=Y; Description='SIM2CMDB testing no-InstanceId, relationships'; Name=FileSystem_Y; SystemName=Computer_wrongName;Relationships:4. BMC_Impact; mc_udid=Computer_Y_TO_BusProcess_Y; PropagationModel=DIRECT; consumer_id=BusProcess_Y; provider_id=Computer_Y; AccountID=Y;5. BMC_Impact; mc_udid=FileSystem_Y_TO_Computer_Y; PropagationModel=DIRECT; consumer_id=Computer_Y; provider_id=FileSystem_Y; AccountID=Y;

==================================================================Importing service impact data into CMDB's dataset BMC.SIM==================================================================

During the data import, the following issues were found:

1. BMC_FileSystem; mc_udid=FileSystem_Y; Name=FileSystem_Y; ComponentAliases=[FileSystem_Y]; Warning: No System instance with Name Computer_wrongName exists in CMDB or upgraded data. No relationship BMC_HostedSystemComponents with instance FileSystem_Y is created.Reason/Suggestion: Please verify the valid System CI Computer_wrongName is existing in either import source or in CMDB.

No SIM data is imported to CMDB because commit was not requested.

==================================================================sim2cmdb result==================================================================Program ended with no SIM data imported to CMDB.

Upgrade commitment


Upgrade commitment

When you run sim2cmdb with the commit command, SIM data is imported into the BMC Atrium CMDB. The data is first imported into the BMC Atrium CMDB BMC.SIM dataset. Afterward, sim2cmdb starts the reconciliation job, BMC SIM to CMDB Migration, to merge the identified instances into the BMC.ASSET dataset. Finally, the SIM publish process is automatically triggered to push the data into the cell with new reconciliation IDs.

The sim2cmdb commit command terminates for two reasons:

■ If issues are found in data verification and the configuration parameter ContinueOnSkip is set to false (default).

Figure 47 Example output file with commitsim2cmdb -e testPSR -i user/**** -o test_commit.log commitWed, 14 May 2008 09:36:44:809 CDT

IAS Server version: 7.2.00 [Build 1544526 - 29-Apr-2008]User user successfully authenticated with IAS server hou-jezhou-37:3084.

BMC Atrium CMDB version: 2.1.0.0User Demo successfully connected to AR System hou-jezhou-37:0.

Upgrade data of all cells of the publish environment(s).Using cell(s) hou-jz-37-psr for DirectPublish data of testPSR.

==================================================================Exporting service impact data from cell(s)==================================================================

ell:hou-jz-37-psrComponents:1. BMC_BusinessProcess; mc_udid=BusProcess_X; ComponentAliases=[BusProcess_X]; AccountID=X; Description='SIM2CMDB testing no-InstanceId, relationships'; Name=BusProcess_X;2. BMC_ComputerSystem; mc_udid=Computer_X; ComponentAliases=[Computer_X]; AccountID=X; Description='SIM2CMDB testing no-InstanceId, relationships'; Name=Computer_X; Type=WINDOWS_SYSTEM; HostName=JZTest_1;3. BMC_FileSystem; mc_udid=FileSystem_X; ComponentAliases=[FileSystem_X]; AccountID=X; Description='SIM2CMDB testing no-InstanceId, relationships'; Name=FileSystem_X; SystemName=Computer_X;Relationships:4. BMC_Impact; mc_udid=Computer_X_TO_BusProcess_X; PropagationModel=DIRECT; consumer_id=BusProcess_X; provider_id=Computer_X; AccountID=X;5. BMC_Impact; mc_udid=FileSystem_X_TO_Computer_X; PropagationModel=DIRECT; consumer_id=Computer_X; provider_id=FileSystem_X; AccountID=X;

==================================================================Importing service impact data into CMDB's dataset BMC.SIM==================================================================

All data was successfully imported.

==================================================================Reconciling data in BMC.SIM dataset into BMC.ASSET dataset in CMDB==================================================================

The following CIs in BMC.SIM have not been automatically identified:

1. BMC_ComputerSystem; mc_udid=Computer_X; Name=Computer_X; ComponentAliases=[Computer_X]; HomeCell=hou-jz-37-psr; 2. BMC_FileSystem; mc_udid=FileSystem_X; Name=FileSystem_X; ComponentAliases=[FileSystem_X]; HomeCell=hou-jz-37-psr;

Please identify them manually with Reconciliation Manager's Manual Identification Console.Then start a new "BMC SIM to CMDB Migration" reconciliation job from Reconciliation Manager's Job History Console.Or, use sim2cmdb 'identify' command to automatically identify CIs in BMC.SIM dataset.

==================================================================sim2cmdb result==================================================================Please verify that the automated publication triggered by the reconciliation was successful, or execute a manual publication with cli publish and verify that it is successful.

CI identification


To continue upgrading, you must fix the data or set ContinueOnSkip to true, which commits the data upgrade regardless of issues with the data.

■ The BMC.SIM dataset is not clean. A clean dataset means that all CIs in the BMC.SIM dataset are identified. In other words, all the component instances in the dataset have the unique ReconciliationIdentity value assigned.

If the dataset is not clean, you must either:

■ return to the CI identification step to identify CIs

■ return to the dataset cleanup step to force clean all the data in BMC.SIM dataset

The sim2cmdb commit reports CIs which have not been automatically identified. If the output report contains any un-identified CIs, you must return to the CI identification stage to identify the CIs.

You must also verify the results of data publication, as explained in step 10 on page 209.

CI identification

The CI identification procedure identifies the component instances in the BMC.SIM dataset and triggers the BMC SIM to CMDB Migration reconciliation job.

You have three options to identify CIs.

1. Manually assign ReconciliationIdentity values to unidentified CIs from the CMDB Reconciliation Manager, and then manually run the BMC SIM to CMDB Migration reconciliation job.

2. Modify the identification rules in the BMC SIM to CMDB Migration - Identification and Merge job from the CMDB Console and manually run the reconciliation job. See “Identifying components and data reconciliation” on page 211 for details.

3. Run the sim2cmdb identify command. The sim2cmdb identify command assigns a unique ID to each unidentified CI in the BMC.SIM dataset and calls the reconciliation job.

Options 2 and 3 have the potential to create duplicates in the BMC Atrium CMDB. Duplicates should be avoided. Therefore, use options 2 and 3 only if SIM data are the sole resource of the BMC Atrium CMDB data or you are certain that the option will not cause duplication.

After CIs in the BMC.SIM dataset are identified and the reconciliation job successfully executed, you must verify if the publication is successful.

Dataset cleanup


Dataset cleanup

The sim2cmdb close command cleans up all the data in the BMC.SIM dataset.

You cannot run the sim2cmdb commit command if the BMC.SIM dataset is not clean. A clean dataset means that all CIs in BMC.SIM dataset are identified, that is, all the component instances in the dataset have a unique ReconciliationIdentity value assigned.

Although you can force removal of all the data in BMC.SIM dataset, BMC Software recommends that if the dataset is not clean you return to the CI Identification stage to identify those CIs. Forced removal of unidentified Cis can cause unsynchronized data between SIM and the BMC Atrium CMDB.

sim2cmdb return codes

When the sim2cmdb command exits with a return value other than 0 (success), additional textual information on the error cause is displayed to standard output and to the generated trace file MCELL_HOME\sim2cmdb.trace.

To enable debug tracing, comment out the last two sections in the MCELL_HOME/sim2cmdb.trace configuration file.

These exit codes, their meanings, and recommended remedial actions are described in Table 60.

Table 60 error exit codes for sim2cmdb CLI command (part 1 of 3)

Error Exit Code Description Recommended remedial action

1 indicates a syntax error on one or more command line arguments or options

Verify the correct syntax for the command string.

3 indicates that the home directory of the CLI is not defined

Do the following:

1. Verify that the MCELL_HOME environment variable is set for the application.

2. Verify that the CLI script (.bat or .sh) file correctly contains:

-DhomeLocation=%MCELL_HOME%

3. Specify the home directory (-D HomeLocation) path at the command line.

4 indicates the supplied configuration file could not be found

Verify that the value of the -c argument is an existing, readable file.



5 indicates an I/O error occurred when reading the configuration file

Verify that the user has read access to the configuration file.

6 indicates the Impact Administration Server (IAS) interface cannot be initialized

Check that the Impact Administration Server (IAS) is up and running.

7 indicates a security problem (for example, write access) to the CLI home directory

Check that the user has read and write access to the etc/ log/ directory and write access to the temp/ directory in the CLI home directory.

8 indicates that the home directory of the CLI does not exist

14 indicates that the CLI cannot find a file that it requires to run properly; for example a FileNotFound exception.

Verify that the file whose name appears as missing does exist

15 indicates that the CLI cannot resolve a host name

Repair the computer’s network settings

16 indicates the failure to authenticate with the BMC Portal server

Do the following:

■ If you are running a CLI command, verify the credentials that you specified.

■ If automatic authentication is set up in the sim2cmdb.conf file, verify that the credentials (IASUsername, IASPassword, and IASServers) are valid.

17 indicates an error with starting impact CLI Do the following:

Verify that the file MCELL_HOME/etc/locale/sim2cmdb.load exists on the BMC Portal server host computer.

18 indicates that the UTF-8 character set is not supported by the host

The host computer must support the UTF-8 character set.

30 indicates verification of publish environment failed

31 indicates an error occurred when retrieving a cell directory from the BMC Atrium CMDB

Verify the access rights for the cell directory.

32 indicates an error occurred when communicating with a cell

Verify that the cell is running.

Verify network connectivity.

33 indicates verification of cell protocol version failed

34 indicates classes between CMDB and cell(s) are not synchronized





35 indicates an error when communicating with BMC Atrium CMDB

Verify that BMC Remedy AR System is running.

Verify network connectivity.

36 indicates an error when executing a CMDB operation

37 indicates an error when importing data into CMDB

Check standard out for more details regarding the error.



Index 231

A B C D E F G H I J K L M N O P Q R S T U V W X Y Z

AAccess Server component type 45active relationship

defined 74Activity component type 44Activity Decision component type 44Activity End component type 44Activity Interaction component type 44Activity Manual component type 44Activity Start component type 44algorithm, quorum 91alias

entering in component instance 69analyzing relevance of events 32Application component type 45Application Infrastructure component type 45Application Service component type 49Application System component type 45applications, using with extended data models 113AR System server

using with extended data models 114ARDBC plug-in 148attributes

generating fields for AR System 114automated publishing 63, 64, 173AutomatedPublish configuration parameter 165AutomatedPublishRetryPeriod configuration parameter

164, 165

BBMC Atrium Configuration Management Database

described 57BMC ProactiveNet Performance Management

using new classes 114BMC Software, contacting 2BMC.ASSET data set 82BMC_Activity component class 44BMC_Application component class 45BMC_ApplicationInfrastructure component class 45BMC_ApplicationService component class 49BMC_ApplicationSystem component class 45BMC_BaseElement

BAROC definition 185slot definitions 187, 192

BMC_BusinessProcess component class 44BMC_BusinessService component class 44BMC_CDROMDrive component class 49BMC_Cluster component class 45BMC_ComputerSystem component class 45, 46, 47, 48, 49

BMC_ConnectivityCollection component class 45BMC_DataBase component class 44BMC_DataBaseStorage component class 50BMC_DiskDrive component class 49BMC_DiskPartition component class 50BMC_FileSystem component class 50BMC_FloppyDrive component class 49BMC_HardwareSystemComponent component class 49BMC_Impact

data class 190enumerations 193

BMC_IPConnectivitySubnet component class 45BMC_IPXConnectivityNetwork component class 45BMC_LAN component class 45BMC_LNsCollection component class 45BMC_LNsCollection component type 45BMC_LocalFileSystem component class 50BMC_LogicalSystemComponent component class 50BMC_Mainframe component class 47BMC_Media component class 49BMC_Monitor component class 47BMC_OperatingSystem component class 50BMC_Organization component class 45BMC_PROPOGATION_MAP

defined 197slots 197

BMC_RemoteFileSystem component class 50BMC_Software component class 50BMC_SoftwareServer component class 46, 47, 48, 49BMC_STATUS_COMPUTATION data class 194BMC_STATUS_PROPOGATION data class 196BMC_SystemResource component class 50BMC_SystemSoftware component class 50BMC_TapeDrive component class 49BMC_UPS component class 49BMC_UserCommunity component class 45BMC_VirtualSystem component class 49BMC_VirtualSystemEnabler component class 50BMC_VMWare component class 50BMC_WAN component class 45Business Process component type 44Business Service component type 44

Index

Index 232


CCD ROM Drive component type 49cell

determining topology 35field 68list of cell names 68reinitializing 144

cell aliasabout 135

Class Manager Console 114classes

IPS_CONFIG 127IPS_ERROR 133IPS_EVENT 126

Cluster component type 45command options

publish 219Common Data Model (CDM)

SIM-qualified classes of 58Communication Server component type 46component classes

BMC_Activity 44BMC_Application 45BMC_ApplicationInfrastructure 45BMC_ApplicationService 49BMC_ApplicationSystem 45BMC_BMCComputerSystem 45, 46, 47, 48, 49BMC_BusinessProcess 44BMC_BusinessService 44BMC_CDROMDrive 49BMC_Cluster 45BMC_ComputerSystem 45, 46, 47, 48, 49BMC_ConnectivityCollection 45BMC_DataBase 44BMC_DataBaseStorage 50BMC_DiskDrive 49BMC_DiskPartition 50BMC_FileSystem 50BMC_FloppyDrive 49BMC_HardwareSystemComponent 49BMC_IPConnectivitySubnet 45BMC_IPXConnectivityNetwork 45BMC_LAN 45BMC_LNsCollection 45BMC_LocalFileSystem 50BMC_LogicalSystemComponent 50BMC_Mainframe 47BMC_Media 49BMC_Monitor 47BMC_OperatingSystem 50BMC_Organization 45BMC_RemoteFileSystem 50BMC_Software 50BMC_SoftwareServer 46, 47, 48, 49BMC_SystemResource 50BMC_SystemSoftware 50

BMC_TapeDrive 49BMC_UPS 49BMC_UserCommunity 45BMC_VirtualSystem 49BMC_VirtualSystemEnabler 50BMC_VMWare 50BMC_WAN 45

component instancesdeleting 72determining dependencies 31editing 71finding existing 73relationship state 53

component statuscomputation model 43computing 87

component types 42Access Server 45Activity 44Activity Decision 44Activity End 44Activity Interaction 44Activity Manual 44Activity Start 44Application 45Application Infrastructure 45Application Service 49Application System 45BMC_LNsCollection 45Business Process 44Business Service 44CD ROM Drive 49Cluster 45Communication Server 46Computer System 46Configuration Management Agent 46Connectivity Collection 45Database 44Database Server 46Database Storage 50Disk Drive 49Disk Partition 50DNS Server 46File Server 46File System 50Firewall 46Floppy Drive 49FTP Server 46Gateway 46Hardware System Component 49Hub 46Input/Output Device 46IP Connectivity Network 45IP Connectivity Subnet 45JBOD 46LAN Network 45Layer 3 Switch 46

Index 233


LDAP Server 47Load Balancer 47Local File System 50Logical System Component 50Mail Server 47Mainframe 47Media 49Message Server 47Mobile User Device 47Monitor 47Operating System 50Organization 45Print Server 47RAID Storage Device 47Remote File System 50Resource Server 47Router 47SAN Bridge 47SAN Director 48SAN Hub 48SAN Router 48SAN Switch 48Security Server 48Server 48Software 50Software Server 48Storage 48Switch 48System Resource 50System Software 50Tape Drive 49Tape Library 48Telnet Server 48Transaction Server 48UDDI Server 48Uninterruptible Power Supply (UPS) 49User Community 45Virtual System 49Virtual System Enabler 50VMware 50WAN Network 45Web Cache 49Web Server 49

Computer System component type 46computing

status, of a component 87configuration items

hiding 72Configuration Management Agent component type 46configuration parameters

AutomatedPublish (publishing server) 165AutomatedPublishRetryPeriod 164, 165InitEffectivelyMgmtData 164, 165

Connectivity Collection component type 45customer support 3

Ddata classes

BMC_BaseElement, BAROC definition 185BMC_Impact 190BMC_PROPOGATION_MAP 197BMC_STATUS_COMPUTATION 90, 194BMC_STATUS_PROPOGATION 196extending 42file location 184mapping 199relationship 183service model relationships 190service model, overview of 183SEVERITY_TO_STATUS 199status related 183

Database component type 44Database Server component type 46Database Storage component type 50datasets

BMC.ASSET 83BMC.IMPACT.PROD 83defined 57for Atrium Publish environments 138

deletingcomponent instance 72

Direct Feed for service model data 40, 119discovery tools 66Disk Drive component type 49Disk Partition component type 50DNS Server component type 46dynamic prioritization

final priority 109impacts priority 108overview 56priority propagators 108self priority 99

Eediting

component instances 71event classes 203

history 205impact 200, 201, 202, 206

eventsgenerating publishing 123missing, described 33

exits 227extending Common Data Model

BMC applications and 113BMC Impact Solutions and 114

Index 234


Ffile location of data classes 184File Server component type 46File System component type 50finding

component instances 73relationships 73

Firewall component type 46Floppy Drive component type 49FTP Server component type 46functions

in status computation 88

GGateway component type 46generating publishing events 123

HHardware System Component component type 49hiding

configuration items 72history event class 205home cell

about 135home cell alias

about 135Hub component type 46

Iidentifying critical events 32impact event class 200, 201, 202, 206important component 108inactive relationship, defined 74InitEffectivelyMgmtData configuration parameter 164, 165Input/Output Device component type 46IP Connectivity Subnet component type 45IPS_CONFIG class 127IPS_ERROR class 133IPS_EVENT class 126IPX Connectivity Network component type 45

JJBOD (Just a Bunch Of Disks) component type 46

LLAN Network component type 45Layer 3 Switch component type 46

LDAP Server component type 47Load Balancer component type 47Local File System component type 50Logical System Component component type 50

MMail Server component type 47Mainframe component type 47mc_root_internal.baroc 191mc_root_redef.baroc 203MC_SM_COMPONENT data class, BAROC definition 185mc_sm_event_ mapping.baroc 184mc_sm_object.baroc 184mc_sm_root.baroc 184MC_SMC_EVENT data class BAROC definition 200, 201,

202, 206Media component type 49Message Server component type 47missing events 33Mobile User Device component type 47Monitor component type 47

OOperating System component type 50Organization component type 45output file

for sim2cmdb CLI command 222

PPrint Server component type 47priority propagators 108product support 3promotion

all instances 84deleting instances 73guidelines 83overview 63requirements before 83step-by-step instructions 84submitting 83verifying status 84

promotion of service model 82provider relationship, described 51publish command

command options 219publishing

automated 63, 64, 173publishing large service models 170Publishing Server

generating events for 123

Index 235


RRAID Storage Device component type 47reinitializing a cell 144relationships

active 74finding 73inactive 74state 53state values 53status propagation models 54

Remote File System component type 50Resource Server component type 47Router component type 47

SSAN Bridge component type 47SAN Director component type 48SAN Hub component type 48SAN Router component type 48SAN Switch component type 48Security Server component type 48Server component type 48service components

types 44service model

class hierarchy 183composition 37data classes, overview of 183Direct Feed 40, 119internals of 183promotion 82publishing large 170

service model componentscomputing status of 87status computation 43

service model relationshipsdata classes 190defined 52

SEVERITY_TO_STATUS data class 199sim2cmdb.conf file 216SMC_STATE_CHANGE data class BAROC definition 205Software component type 50Software Server component type 48state_change.baroc file 206Status and Alias tab 69status computation

functions 91model 43model anatomy 91of components 43

status propagation modelsfor relationships 54in BMC Impact Model Designer 95

STATUS_COMPUTATION

data class, BAROC definition 194, 195slots 194, 195

Storage component type 48support, customer 3Switch component type 48System Resource component type 50System Software component type 50

TTape Drive component type 49Tape Library component type 48technical support 3Telnet Server component type 48Transaction Server component type 48

UUDDI Server component type 48Uninterruptible Power Supply (UPS) component type 49User Community component type 45

Vverifying promotion status 84Virtual System component type 49Virtual System Enabler component type 50VMware component type 50

WWAN Network component type 45Web Cache component type 49Web Server component type 49weighted cluster status model 43wildcards

using with Find command 73

Index 236


*209419**209419**209419**209419*

*209419*

proactivenet service modeling and publishing guide

Documents