ProactiveNet Service Modeling and Publishing Guide

BMC ProactiveNet Service Modeling and Publishing Guide
Supporting
BMC ProactiveNet version 8.6 BMC Impact Model Designer version 1.0
July 2011
www.bmc.com
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 INC 2101 CITYWEST BLVD HOUSTON TX 77042-2827 USA Telephone 713 918 8800 or 800 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 legend

U.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.
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
I I I I I I I I
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 customer_support@bmc.com. (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:
I
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
I I I
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
Contents
Chapter 1 Overview 15 15 16 16 16 17 19 19 19 20 20 20 21 21 23 23 25 26 27 28 29 29 30 31 32 32 34 35 35 36 37 About this guide. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . About BMC Impact Model Designer. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . After upgrading to BMC ProactiveNet version 8.5. . . . . . . . . . . . . . . . . . . . . . . . . . . . . Before you begin using BMC Impact Model Designer . . . . . . . . . . . . . . . . . . . . . . . . . . Other documents you may need . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . Chapter 2 BMC Impact Model Designer user interface
Installing BMC Impact Model Designer . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . Prerequisites to using BMC Impact Model Designer . . . . . . . . . . . . . . . . . . . . . . . . . . . Launching BMC Impact Model Designer. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . BMC Atrium Explorer and BMC Impact Model Designer. . . . . . . . . . . . . . . . . . . . . . . Who should use BMC Atrium Explorer? . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . BMC Impact Model Designer features . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . BMC Impact Model Designer menu bar. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . Chapter 3 Designing a service model
Service model design process. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . Defining business goals for the service model . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . Decomposing a business service . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . Defining the service catalog . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . Defining the service model . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . Defining a configuration item . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . Defining a new component class for a component type . . . . . . . . . . . . . . . . . . . . . Analyzing a components critical failures . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . Determining a components relationship and dependencies . . . . . . . . . . . . . . . . . Determining the organization of the modeled relationships . . . . . . . . . . . . . . . . . Identifying a components critical events and their sources . . . . . . . . . . . . . . . . . . Displaying business key performance indicators (KPIs) . . . . . . . . . . . . . . . . . . . . . Service model design considerations . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . Determining cell topology for the service model . . . . . . . . . . . . . . . . . . . . . . . . . . . Component property updates . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . Chapter 4 Understanding a service model
Sources of service model objects . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 37 Rules for service model data modification and deletion . . . . . . . . . . . . . . . . . . . . . 39 Using the BMC Atrium CMDB as a source of service model data. . . . . . . . . . . . . 40
Using Direct Feed . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . Precedences . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . Service components . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . Component classes and types . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . Service configuration items . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . Component status and substatus . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . Component status computation . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . Service model component types . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . Component relationships . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . Service consumers and providers . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . Status propagation in relationships . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . Relationship states. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . Relationship control . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . Service schedules . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . Timeframes . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . Service schedules example with exceptions . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . Chapter 5
40 40 41 41 42 42 43 44 51 51 53 53 54 55 55 56
Understanding a service model created in BMC Impact Model Designer 57 57 58 62 63 63 64 64 65 65 65 66 66 71 71 72 72 73 74 74 75 75 75 76 78 81 82 82 82

6
Role of the BMC Atrium CMDB in service modeling. . . . . . . . . . . . . . . . . . . . . . . . . . . Service model and the Common Data Model . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . Sandboxes . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . Datasets . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . Promotion . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . Service model publishing . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . Service model execution on cells . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . Chapter 6 Building a service model in BMC Impact Model Designer
Service model creation process . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . Launching BMC Impact Model Designer. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . Working with service configuration items . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . Creating service configuration items in BMC Impact Model Designer . . . . . . . . Switching sandbox view modes . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . Editing configuration items . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . Hiding configuration items . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . Deleting configuration items . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . Finding configuration items. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . Defining relationships between configuration items . . . . . . . . . . . . . . . . . . . . . . . . . . . Creating and editing component relationships . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . Associating events with a configuration item . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . Working with timeframes and service schedules . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . Icons used in the service schedule and timeframes dialog box . . . . . . . . . . . . . . . Working with timeframes . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . Working with service schedules . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . Assigning components to service schedules . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . Granting permissions to individual service model objects . . . . . . . . . . . . . . . . . . . . . . Promoting the service model . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . About the publishing process . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
Contents
Before you promote. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . Submitting a promotion . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . Verifying promotion status . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . Modifying and deleting service model data . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . Exporting class definitions from the BMC Atrium CMDB to cells. . . . . . . . . . . . . . . . Chapter 7 Component and relationship status propagation
83 83 84 85 85 87
About component and relationship status . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 87 How component status computation works . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 87 Status computation functions . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 88 Status computation algorithms . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 89 How status computation algorithms work . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 89 About status computation models . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 90 Anatomy of a status computation model. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 91 The internal status NONE . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 91 Quorum algorithm examples. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 91 Relationship status propagation concepts . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 93 How status propagation works . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 94 Status propagation models. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 95 Default status propagation models. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 95 What is a valid status propagation model? . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 96 Important service components. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 97 Dynamic prioritization . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 98 Self priority . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 99 Impacts priority . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 108 Determination of final priority . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 109 How cost impact is calculated . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 111 How SLA impact is calculated. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 111 Chapter 8 Managing BMC Impact Model Designer 113
Adding new classes to BMC Atrium CMDB . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 113 Making your changes visible to applications . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 113 Creating 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 . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 117 BMC ProactiveNet Publishing Server architecture . . . . . . . . . . . . . . . . . . . . . . . . 118 BMC Atrium CMDB . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 119 Non-Atrium CMDB sources for service model objects . . . . . . . . . . . . . . . . . . . . . 119 Publishing server optional configurations . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 120 Specifying a port for Service Model Manager. . . . . . . . . . . . . . . . . . . . . . . . . . . . . 120 High availability cell server and BMC ProactiveNet Publishing Server. . . . . . . 120 Monitoring BMC ProactiveNet Publishing Server with cell events . . . . . . . . . . . . . . 123 Modifying the generation of events . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 123 Understanding classes and slots for BMC ProactiveNet Publishing Server events 125 About impact management data . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 133
Contents
Understanding publishing environments. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 134 About publishing environments . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 134 About home cell, home cell alias, and cell alias. . . . . . . . . . . . . . . . . . . . . . . . . . . . 135 Publishing from the BMC Atrium CMDB. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 136 Enabling AtriumCMDB Publish publishing . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 137 Using BMC Impact Model Designer . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 137 Creating advanced publishing environments . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 139 Examples of advanced environments . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 140 Defining BMC Atrium CMDB classes for BMC ProactiveNet . . . . . . . . . . . . . . . 142 Defining BMC Atrium CMDB attributes for BMC ProactiveNet . . . . . . . . . . . . . 142 Initializing the BMC Atrium CMDB with BMC ProactiveNet data . . . . . . . . . . . 143 Initializing a cell . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 144 Examplecreating BMC ProactiveNet data in BMC Atrium CMDB from BAROC files. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 145 Purging and deleting service model objects . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 146 Publishing in automated or manual mode. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 147 Publishing from a Direct Publish source. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 149 About home cell and cell alias . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 150 About the enterprise mode . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 152 About class and slot data . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 152 Enabling Direct Publish publishing . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 153 Sending BMC ProactiveNet data to the cell . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 153 Modifying home cell and cell aliases . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 153 Initializing a cell from a Direct Publish environment. . . . . . . . . . . . . . . . . . . . . . . 154 Examplesusing cell aliases for Direct Publish publishing . . . . . . . . . . . . . . . . . 154 Securing publishing environments . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 156 pserver.conf file and parameters . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 158 Configuring the Notify ARDBC plug-in . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 164 Configuring the Notify plug-in for AR server groups . . . . . . . . . . . . . . . . . . . . . . . . . 165 Viewing publication history . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 166 Diagnosing publication issues . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 166 Appendix A Troubleshooting 169
Publishing Server . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 169 Verifying that the publishing server is running . . . . . . . . . . . . . . . . . . . . . . . . . . . 169 Using trace files . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 170 Stopping the publishing server when JMS is not running. . . . . . . . . . . . . . . . . . . 170 Publishing large service models . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 170 Publishing failures and reattempts . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 172 The publishing server service or daemon fails to start. . . . . . . . . . . . . . . . . . . . . . 172 No publication after successful promotion . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 173 Reconciliation jobs hang . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 173 The publishing server does not reply to requests . . . . . . . . . . . . . . . . . . . . . . . . . . 174 Diagnosing publication failures. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 174 Another publish request is ongoing . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 179 Using dynamic ports with the ARDBC Notify plug-in . . . . . . . . . . . . . . . . . . . . . 179 Frequently Asked Questions. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 179 I cannot launch BMC Impact Model Designer successfully . . . . . . . . . . . . . . . . . 180
I cannot see the BMC Impact Model Designer menu bar in spite of installing BMC Impact Model Designer successfully . . . . . . . . . . . . . . . . . . . . . . . . . . . . . I cannot see the changes I made to the CIs . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . The service model I try to create appears as yellow blocks . . . . . . . . . . . . . . . . . Troubleshooting BMC Impact Model Designer . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . Appendix B Default service model data classes
180 181 181 182 183 183 183 184 184 185 190 193 194 196 197 199 199 199 200 200 201 201 202 202 202 203 203 203 203 205 205 206 207 207 208 208 209 210 211 214 215 218 222 225 226
9
Service model data structures . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . Service model data class overview . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . Service model data class files. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . Service model component data classes . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . BMC_BaseElement data class . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . BMC_Impact data class. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . BMC_DOWNTIME_STATUS_CONFIG data class . . . . . . . . . . . . . . . . . . . . . . . . BMC_STATUS_COMPUTATION data class . . . . . . . . . . . . . . . . . . . . . . . . . . . . . BMC_STATUS_PROPAGATION data class . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . BMC_PROPAGATION_MAP data class . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . BMC ProactiveNet data class descriptions. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . BMC_SEVERITY_TO_STATUS data class . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . BMC_SLOT_FORMULAS data class . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . BMC_TIME_SCHEDULE data class . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . BMC_TIME_FRAME_TO_SCHEDULE data class . . . . . . . . . . . . . . . . . . . . . . . . . BMC_SELF_PRIORITY_MAPPING data class . . . . . . . . . . . . . . . . . . . . . . . . . . . . BMC_SERVICE_SCHEDULE_CONFIG data class . . . . . . . . . . . . . . . . . . . . . . . . BMC_STATUS_TO_SEVERITY data class . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . SIM_TIME_FRAME class . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . SIM_CellAlias class . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . SIM_CellInformation class . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . BMC_PROMOTION_LOG class . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . Service model event classes . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . CORE_EVENT base class . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . Root event class . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . History event class. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . Impact event class . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . Appendix C Upgrading a service model to BMC Atrium CMDB
Upgrading from non-Atrium-CMDB SIM to BMC Atrium CMDB SIM . . . . . . . . . . Upgrading SIM data that originates from third-party source . . . . . . . . . . . . . . . Recommended upgrade steps . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . Understanding how the upgrade works . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . Ensuring quality data in BMC Atrium CMDB . . . . . . . . . . . . . . . . . . . . . . . . . . . . Identifying components and data reconciliation . . . . . . . . . . . . . . . . . . . . . . . . . . Data imported into BMC.SIM . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . sim2cmdb CLI command . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . Running the upgrade . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . Reviewing the output files for sim2cmdb . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . Upgrade commitment. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . CI identification . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
Contents
Dataset cleanup . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 227 sim2cmdb return codes . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 227 Index 231
10
Tables
Then and now . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 16 Useful BMC documentation . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 17 Example business service model spreadsheet . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 27 BMC Impact Model Designer values for IT service Sales Logix . . . . . . . . . . . . . . . . . 28 Severity level index . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 30 Occurrence level index . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 30 How service model objects get to a cell . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 38 Advantages and disadvantages of different object sources . . . . . . . . . . . . . . . . . . . . . 39 Service model component types . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 44 Main relationship classes . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 51 Global and Local timeframe differences . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 56 BMC ProactiveNet-qualified subclasses of BMC_Collection . . . . . . . . . . . . . . . . . . . . 58 BMC ProactiveNet-qualified subclasses of BMC_LogicalEntity . . . . . . . . . . . . . . . . . 59 BMC ProactiveNet-qualified subclasses of BMC_System . . . . . . . . . . . . . . . . . . . . . . . 59 BMC ProactiveNet-qualified subclasses of BMC_SystemComponent . . . . . . . . . . . . 59 BMC ProactiveNet-qualified subclasses of BMC_Software . . . . . . . . . . . . . . . . . . . . . 60 BMC ProactiveNet-qualified subclass of BMC_SystemService . . . . . . . . . . . . . . . . . . 60 BMC ProactiveNet Performance Management-qualified attributes . . . . . . . . . . . . . . 61 Fields on the Other tab . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 70 View mode switch icons . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 71 Schedules and timeframes icons . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 75 Timeframe Edit field descriptions . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 77 Edit Schedule field descriptions . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 79 Icons in Objects-to-be-Published pane . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 84 Status computation functions and computed component statuses . . . . . . . . . . . . . . . 88 What a function returns when using an available algorithm . . . . . . . . . . . . . . . . . . . . 89 Description of predefined status computation models . . . . . . . . . . . . . . . . . . . . . . . . . 90 How status propagation models work in relationships . . . . . . . . . . . . . . . . . . . . . . . . 96 BMC ProactiveNet Publishing Server event generation . . . . . . . . . . . . . . . . . . . . . . . 123 Common Event Model (CEM) slots . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 125 IPS_START slots . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 127 IPS_STOP slots . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 127 IPS_CONFIG slots . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 128 IPS_CONNECT slots . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 129 IPS_IM_CONNECT slots . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 129 IPS_REQUEST slots . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 130 IPS_PUBLISH slots . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 132 IPS_CLASSINFO slots . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 132 IPS_ERROR slots . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 133 IPS_ENV slots . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 133
Tables 11
Basic steps to create advanced test environments . . . . . . . . . . . . . . . . . . . . . . . . . . . . 139 Basic process of publishing from a Direct Publish source . . . . . . . . . . . . . . . . . . . . . . 149 Valid parameters for a Direct Publish environment . . . . . . . . . . . . . . . . . . . . . . . . . . 150 pserver.conf file . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 159 ar.cfg file parameter descriptions . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 165 Publishing server request failure messages . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 175 Error Messages . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 182 Service management data class files . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 184 Slots that define CIs . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 187 BMC_Impact slot definitions in alphabetical order . . . . . . . . . . . . . . . . . . . . . . . . . . . 192 BMC_DOWNTIME_STATUS_CONFIG slot . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 194 BMC_STATUS_COMPUTATION slots in alphabetical order . . . . . . . . . . . . . . . . . . 195 Status propagation slots in alphabetical order . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 197 BMC_PROPAGATION_MAP slot definitions . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 198 Identifying components in the BMC Atrium CMDB . . . . . . . . . . . . . . . . . . . . . . . . . . 212 Key slots in reconciliation rules for management data . . . . . . . . . . . . . . . . . . . . . . . . 213 Possible import results . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 215 sim2cmdb.conf file . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 216 sim2cmdb command options . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 219 error exit codes for sim2cmdb CLI command . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 227
12
Figures
BMC Impact Model Designer features in the BMC Atrium Core Console menu bar . . 21 Example of a service model . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 24 Inserting KPI data into the business_slot with an action . . . . . . . . . . . . . . . . . . . . . . . 35 Updating KPI data with a rule . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 35 Impact (status) propagation in relationships . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 52 Classes accordion . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 67 Edit Timeframe dialog box . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 76 Edit Schedule dialog box . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 79 Propagation paths between root cause and important components . . . . . . . . . . . . . . 98 Self priority determination . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 99 Cost priority method of priority determination . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 103 Worst SLA method of priority determination . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 107 Impacts priority determination . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 108 Final priority determination . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 110 BMC ProactiveNet Publishing Server architecture . . . . . . . . . . . . . . . . . . . . . . . . . . . 118 BMC Atrium Explorer and BMC Impact Model Designer icons . . . . . . . . . . . . . . . . 181 BMC_BaseElement definitions . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 185 MC_SM_COMPONENT definition . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 186 MC_SM_DATA definition . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 187 CORE_DATA definition . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 187 BMC_Impact definition . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 191 MC_SM_RELATIONSHIP definition . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 191 MC_SM_DATA definition . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 191 CORE_DATA definition . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 192 BMC_DOWNTIME_STATUS_CONFIG definition . . . . . . . . . . . . . . . . . . . . . . . . . . . 194 BMC_SIM_DATA definition . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 194 BMC_STATUS_COMPUTATION definition . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 195 BMC_SIM_DATA definition . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 195 BMC_STATUS_PROPAGATION definition . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 196 BMC_SIM_DATA definition . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 197 BMC_PROPAGATION_MAP definition . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 198 BMC_SIM_DATA definition . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 198 SEVERITY_TO_STATUS definition . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 199 BMC_SLOT_FORMULAS definition . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 200 BMC_TIME_SCHEDULE definition . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 200 BMC_TIME_FRAME_TO_SCHEDULE definition . . . . . . . . . . . . . . . . . . . . . . . . . . . . 201 BMC_SELF_PRIORITY_MAPPING definition . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 201 BMC_SERVICE_SCHEDULE_CONFIG definition . . . . . . . . . . . . . . . . . . . . . . . . . . . 201 BMC_STATUS_TO_SEVERITY definition . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 202
Figures 13
SIM_TIME_FRAME definition . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 202 Partial CORE_EVENT definition . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 204 MC_SMC_ROOT definition . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 205 SMC_STATE_CHANGE definition . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 206 MC_SMC_EVENT definition . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 206 Example output file without commit . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 223 Example verify.log file . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 224 Example output file with commit . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 225
14
Chapter
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:
I
BMC Atrium Explorer BMC Impact Model Designer The Administration Console of BMC ProactiveNet Performance Management
About this guide

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. 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.
Chapter 1 Overview
15
About BMC Impact Model Designer
About BMC Impact Model Designer

BMC 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. Table 1 Then and now
What you will use now BMC Impact Model Designer BMC Atrium Core Console BMC ProactiveNet Performance Management
What you were using earlier BMC Service Model Editor BMC Impact Portal BMC Service Impact Manager
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:
I
BMC ARSystem Datastore BMC Remedy Action Request System
16
Other documents you may need
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.
I
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.

In 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
Description Contains information on installing BMC ProactiveNet Performance Management and BMC ProactiveNet CMDB Extensions which is a part of the installation. Contains information on using BMC ProactiveNet Performance Management.
Guide name BMC ProactiveNet Getting Started Guide BMC ProactiveNet User Guide
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.
Chapter 1 Overview
17
Table 2
Useful BMC documentation

Description Contains information on working with CIs and relationships using BMC Atrium Explorer of the BMC Atrium Configuration Management Database (CMDB) product. Contains information about setting permissions, configuring federation, modifying the data model, configuring an impact model, and other administrative tasks in BMC Atrium CMDB.
Guide name BMC Atrium CMDB User's Guide
BMC Atrium CMDB Administrators Guide
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
18
Chapter
BMC Impact Model Designer user interface

2
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

I
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.
Chapter 2 BMC Impact Model Designer user interface
19
Launching BMC Impact Model Designer

You 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:
I
AR server mid-tier hostname represents the system on which BMC Remedy AR
System mid-tier is installed

I
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.
20
BMC Impact Model Designer features
BMC Impact Model Designer features

The following features are unique to BMC Impact Model Designer and are not present in BMC Atrium Explorer:
I
Creating schedules and timeframes Editing impact management attributes of CIs using the GUI
BMC Impact Model Designer menu bar

Figure 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
Schedules and timeframes
Promote Sandbox Changes
NOTE
The Promote Sandbox Changes icon is visible to both BMC Impact Model Designer and BMC Atrium Core Console users.
Chapter 2 BMC Impact Model Designer user interface
21
BMC Impact Model Designer menu bar
22
Chapter
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 process

The best service models are enterprise-specific, achieving the organizations 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.
Chapter 3
23
Service model design process
Figure 2
Example of a service model
business consumers
service layer
IT infrastructure
The following factors determine how a service impact management solution should be designed and implemented:
I I
I I I
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
24
Defining business goals for the service model
The service modeling process involves:

I I I I I I I
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 model

The 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 shortterm, 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:
I
operational efficiencyThis 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 efficiencyThis 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 availabilityThis 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.
Chapter 3
25
Decomposing a business service
Decomposing a business service

The 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:
I
business processesIdentify 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 applicationsIdentify 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.
26
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:
I
I I
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. Table 3 Example business service model spreadsheet
Business functions Marketing Business processes Market research
Core competencies Plan and develop products
IT services
IT component
Research product and planning development Manager customer relations Front office sales Customer support Response management Support service requests FTP Server: FTP
Sprint Sales Logix
Server: Walrus Database: SALLOG Applications: Sales Logix User group: Tech Support dept Servers: Antelope
Defining the service catalog

A 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.
Chapter 3
27
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. Table 4
Compon ent name
BMC Impact Model Designer values for IT service Sales Logix

Provider instances Consumer Status computati Relationsh that instances impact on model ip Policy depending on direct Tech Support Analysts Sales Logix v6.01 Support service requests Tech Support Analysts
Compone nt type business process
Component description
Cell name bogart
In/out model in
Support Business service function is requests Customer support
user Tech Techs communit Support supporting y Analysts service requests applicatio Sales n Logix v6.01 applicatio Sales n server Logix server database
bogart
in
standard
direct
Sales Logix bogart application, v 6.01 Sales Logix server bogart
in
standard
increasing Sales Logix server
in
standard
increasing Sales Sales Logix Logix DB v6.01 software Tech Support Analysts direct SALLOG Sales Logix application Tech Support Analysts Sales Logix db software Tech Support Analysts
Sales Logic Sales database Logix software v6.0 DB software SALLOG Sales Logix database server
bogart
in
standard
database server
bogart
in
standard
direct
Defining the service model

After 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:
I I
each resources name or component identification pattern its location or site
28
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
I I I
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 modelits 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.
Chapter 3
29
Analyzing a components critical failures
Analyzing a components 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:
I
I I I
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.
Table 5
severe significant moderate minor slight minimal
Severity level index

Definition Permanently disabling critical end user dissatisfaction causes degradation of service causes inconvenience to end user caused annoyance for customer not noticeable by end user
Severity level
assign a frequency or occurrence level to each failure
Occurrence level index values are listed in Table 6. Table 6

high frequent moderate occasional slight remote
Occurrence level index

Definition high change of occurrence and needs immediate attention frequent change to happen and needs attention moderate change to consider prevention occasionally might happen slight chance to happen unlikely to happen
Occurrence level
30
Determining a components relationship and dependencies
Sample of failure modes effects and analysis

I I I I I
I I I I I
ComponentMessage Transfer Agent (MTA) Functionroutes and convert messages Point of failurequeue length size growing Issue typeperformance Cause of failurenetwork connection failure, receiving MTA failure, problem on sending or receiving machine Effect of failureremote recipients will not receive e-mail while MTA down Severitysignificant Occurrenceslight Preventionmonitoring of the system, network, and exchange services DetectionPATROL NT and Exchange parameters related to the issue
Determining a components 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.
I
consider relationships and dependencies within the IT service; for example, within email service, or call supports 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.
Chapter 3
31
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:
I
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 Softwares 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 components 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 components real-time status to reflect the health of the actual resource that it represents.
32
Identifying a components critical events and their sources
To create the event associations for a component, you must

I I
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:
I
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.
Chapter 3 Designing a service model 33
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 services IT resources.
I
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.
34
Service model design considerations
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
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). 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
Service model design considerations

This 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:
I I I
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.
Chapter 3
35
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.
36
Chapter
Understanding a service model

A BMC service model is made up of
I
data classes that describe the various types of physical and logical IT resources that make up an enterprises 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 objects

The cell can receive service model objects (components and relationships) from several different sources:
I I I I I
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:
Chapter 4
37
Sources of service model objects
BMC ProactiveNet Administration Consoleon 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 7 How service model objects get to a cell
How objects are delivered to a cell Delivery method name Atrium Publish Feed 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 you create a BAROC source file of object data and Direct Publish Feed send it to the cell using the pposter CLI command, which publishes the data to the cell using the publishing server you create a BAROC source file of object data and source Direct Feed send it to the cell using the mposter CLI command MRL rule BMC ProactiveNet Administration Console you create a rule that adds objects to the cell on receipt of a trigger event you create service models using the Administration Console of BMC ProactiveNet Performance Management tool direct feed source direct feed
Source for service model objects BMC Atrium CMDB
BAROC source file
Table 8 describes some of the advantages and disadvantages of the different sources for service model data.
38
Rules for service model data modification and deletion
Table 8
Advantages and disadvantages of different object sources

Advantages
I I I
Object source BMC Atrium CMDB
Disadvantages
I I
I I
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 easy to set up a simple service model quickly managed by the publishing server, so data is protected from uncontrolled edits handles highly dynamic changes
complex to implement time factor to discover or create, reconcile, and publish objects
BAROC file with the pposter CLI command
I I
I I I I I I
useful only for small, simple models BAROC file must be created to exact standards requires knowledge of CLIs only practical for special circumstances may not build complete model no primary copy in external datastore
MRL rule
Direct Publish Feed
validation of the service model is off-loaded from the cell, preventing cell processing performance degradation
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.
Chapter 4
39
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.
40
Service components
Data overrides other data with a lower precedence if

I I
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 components
This 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).
Chapter 4
41
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 components icon in the Operations Console of BMC ProactiveNet Performance Management. Information about the status of a CI is stored in the cell in the instances 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.
42
Component status computation
Component status computation

The status of a CI is computed automatically by the cell when new conditions occur, such as
I I I
a new event is received that has a direct impact on the component the severity of an event impacting a component changes another components 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 components 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 components 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
I I I
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.
Chapter 4
43
Service model component types

Table 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
Component superclass Logical Entity Activity
Service model component types (part 1 of 7)

Icon Component type Component class BMC_LogicalEntity BMC_Activity
Activity Decision
BMC_Activity ActivityType=ActivityDecision BMC_Activity ActivityType=ActivityEnd BMC_Activity ActivityType=ActivityInteraction BMC_Activity ActivityType=ActivityManual BMC_Activity ActivityType=ActivityStart BMC_BusinessProcess
Activity End
Activity Interaction
Activity Manual
Activity Start
Business Process
Business Service
BMC_BusinessService
Database
BMC_DataBase
44
Table 9
Component superclass Collection

Icon Component type User Community Component class BMC_Collection 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 Access Server
BMC_System BMC_ComputerSystem PrimaryCapability=Access Server BMC_Application
Application
Application Infrastructure
BMC_ApplicationInfrastructure
Application System
BMC_ApplicationSystem
Cluster
BMC_Cluster
Chapter 4
45
Table 9
Component superclass System

Icon Component type Communication Server Component class BMC_System BMC_SoftwareServer SoftwareServerType=Communication Server BMC_ComputerSystem
Computer System
Configuration Management Agent
BMC_SoftwareServer SoftwareServerType=ConfigMgmtAgent
Database Server
BMC_SoftwareServer SoftwareServerType=DataBaseServer BMC_SoftwareServer SoftwareServerType=DNSServer BMC_ComputerSystem PrimaryCapability=File Server BMC_ComputerSystem PrimaryCapability=Firewall BMC_SoftwareServer SoftwareServerType=FTPServer BMC_ComputerSystem PrimaryCapability=Gateway BMC_ComputerSystem PrimaryCapability=Hub BMC_ComputerSystem PrimaryCapability BMC_ComputerSystem PrimaryCapability=JBOD BMC_ComputerSystem PrimaryCapability=Layer 3 Switch
DNS Server
File Server
Firewall
FTP Server
mp
Gateway
Hub
Input/Output Device
JBOD (Just a Bunch Of Disks)
Layer 3 Switch
46
Table 9

Icon Component type LDAP Server Component class BMC_System BMC_SoftwareServer SoftwareServerType=LDAPServer BMC_ComputerSystem PrimaryCapability=LoadBalancer BMC_SoftwareServer SoftwareServerType=MailServer BMC_Mainframe
Load Balancer
Mail Server
Mainframe
Message Server
BMC_SoftwareServer SoftwareServerType=MessageServer BMC_ComputerSystem PrimaryCapability=Mobile User Device
Mobile User Device (a handheld personal data assistant (PDA)) Monitor
BMC_Monitor
Print Server
BMC_ComputerSystem PrimaryCapability=Print BMC_SoftwareServer SoftwareServerType=PrintServer BMC_ComputerSystem PrimaryCapability=RAIDStorageDevice BMC_SoftwareServer SoftwareServerType=ResourceServer BMC_ComputerSystem PrimaryCapability=Router BMC_ComputerSystem PrimaryCapability=SANBridge
Print Server
RAID Storage Device
Resource Server
Router
SAN Bridge
Chapter 4
47
Table 9

Icon Component type SAN Director Component class BMC_System BMC_ComputerSystem PrimaryCapability=SANDirector BMC_ComputerSystem PrimaryCapability=SANHub BMC_ComputerSystem PrimaryCapability=SANRouter BMC_ComputerSystem PrimaryCapability=SANSwitch BMC_SoftwareServer SoftwareServerType=SecurityServer BMC_ComputerSystem PrimaryCapability=Server BMC_SoftwareServer
SAN Hub
SAN Router
SAN Switch
p
Security Server
Server
Software Server
Storage
BMC_ComputerSystem PrimaryCapability=Storage BMC_ComputerSystem PrimaryCapability=Switch BMC_ComputerSystem PrimaryCapability=TapeLibrary BMC_SoftwareServer SoftwareServerType=TelnetServer BMC_SoftwareServer SoftwareServerType=TransactionServer
Switch
Tape Library
Telnet Server
Transaction Server
UDDI Server
BMC_SoftwareServer SoftwareServerType=UDDIServer
48
Table 9

Icon Component type Virtual System Component class BMC_System BMC_VirtualSystem (deprecated as of BMC Atrium CMDB version 7.5.00) BMC_ComputerSystem PrimaryCapability=Web Caching BMC_SoftwareServer SoftwareServerType=WebServer BMC_SystemService Application Service BMC_ApplicationService
Web Cache
Web Server
System Service
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 BMC_UPS (UPS)
Chapter 4
49
Table 9
Component superclass

Icon Component type Logical System Component Component class BMC_SystemComponent BMC_LogicalSystemComponent
System Component
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) BMC_SystemResource
System Resource
50
Component relationships
Component relationships
Service management relationships are impact relationships.
NOTE
Only BMC_Impact relationships are considered, or used, by the BMC ProactiveNet cell.
Table 10 lists the main relationship classes derived from BMC_BaseRelationship, of which only BMC_Impact defines impact relationships for a service model. Table 10
Class name BMC_Impact
Main relationship classes

Class description The BMC_Impact relationship, and the subclasses that derive from this class are used to define service impact relationships between CIs. 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 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 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 ElementLocation associates a ManagedElement with a Location for positioning, inventory, maintenance and similar purposes.
BMC_Dependency
BMC_Component
BMC_MemberOfCollection
BMC_ElementLocation
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.
Chapter 4
51
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.
NOTE
From version 7.6.03 of BMC Atrium CMDB onwards, BMC_Impact is an attribute of all relationship classes.
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.
52
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
I I
the components 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 ACTIVE INACTIVE
Meaning The consumer component depends on its provider. An impact relationship exists. The consumer does not have a dependency, or the dependency is unimportant. No impact relationship exists.
Chapter 4
53
Relationship control
In status propagation models, the state of a relationship determines whether the providers 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
I I
the current state of the relationship (active or inactive) the current value of the providers 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:
I
relationship controlPropagation models enforce logical rules in new component relationships so that only valid relationships are created.
dynamic status mappingPropagation 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
I I I
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 components 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.
54
Service schedules
Service schedules
Service 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).
I
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 components 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.
I
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.
Chapter 4
55
Service schedules example with exceptions
Table 11 illustrates the differences between global timeframes and local timeframes. Table 11
Global Local
Global and Local timeframe differences

Created in Stored in Available to
Timeframe type
BMC Impact Model Designer
BMC Atrium CMDB all cells event management policies within a single cell
a single cell BMC ProactiveNet Performance Management
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.
56
Chapter
Understanding a service model created in BMC Impact Model Designer

5
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.
Chapter 5 Understanding a service model created in BMC Impact Model Designer
57
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
Third Level BMC_ConnectivitySegment BMC_IPConnectivitySubnet BMC_IPXConnectivityNetwork BMC_LNsCollection BMC_LAN BMC_WAN Fourth Level
Second Level BMC_ConcreteCollection BMC_ConnectivityCollection
58
Second Level BMC_Organization BMC_UserCommunity
Third Level
Fourth Level
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
Third Level BMC_BusinessProcess
Second Level BMC_Activity BMC_BusinessService BMC_Database
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
Third Level BMC_Application BMC_ApplicationInfrastructure BMC_SoftwareServer BMC_Mainframe Printer BMC_VirtualSystem
Second Level BMC_ApplicationSystem
BMC_Cluster BMC_ComputerSystem
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
Third Level BMC_ Software BMC_DiskPartition BMC_SystemResource BMC_FileSystem BMC_DataBaseStorage BMC_LocalFileSystem BMC_RemoteFileSystem Fourth Level BMC_SystemSoftware
Second Level LogicalSystemComponent
59
Second Level HardwareSystemComponent
Third Level BMC_UPS BMC_Media
Fourth Level BMC_CDROMDrive BMC_DiskDrive BMC_FloppyDrive BMC_TapeDrive
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
Fifth Level BMC_SystemSoftware
BMC ProactiveNet-qualified subclasses of BMC_Software

Sixth Level BMC_OperatingSystem BMC_VirtualSystemEnabler Seventh Level BMC_VMWare
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. Table 17 BMC ProactiveNet-qualified subclass of BMC_SystemService
Second Level BMC_ApplicationService
60
BMC ProactiveNet Performance Management attributes

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

Namespace BMC.CORE Attributes 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] 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] 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]
BMC.AM
BMC.SIM
61
Sandboxes
Table 18
Class
BMC ProactiveNet Performance Management-qualified attributes

Namespace BMC.CORE Attributes 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] ConnectivityType [SIM, SME_Read, SME_ReadWrite] OSType [SIM, SME_Read, SME_ReadWrite] VirtualSystemType [SIM, SME_Read, SME_ReadWrite] WANType [SIM, SME_Read, SME_ReadWrite] 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] SystemClassId [SIM, SME_Read, SME_ReadWrite] SystemName [SIM, SME_Read, SME_ReadWrite] MaxMediaSize [SIM, SME_Read, SME_ReadWrite] MediaType [SIM, SME_Read, SME_ReadWrite] SystemClassId [SIM, SME_Read, SME_ReadWrite] SystemName [SIM, SME_Read, SME_ReadWrite]
BMC_Cluster
BMC_ConnectivitySegm BMC.CORE ent BMC_OperatingSystem BMC_VirtualSystem BMC_WAN BMC_ComputerSystem BMC.CORE BMC.CORE BMC.CORE BMC.CORE
BMC_SystemComponen BMC.CORE t BMC_Media BMC_SystemService BMC.CORE BMC.CORE
The definitions of the BMC ProactiveNet Performance Management qualifiers are

I I I
SIM: 300050 SIM_Internal: 300060 SIM_ReadWrite: 300070
Sandboxes
A 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.
62
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.
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.
Datasets
The 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.
Promotion
You 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:
63
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 publishing

Service 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 cells

Service 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 events slots to construct an alias and then searches for that alias in the cells impact CIs. When a match is found, the event is associated with the CI and the instances status may be changed.
64
Chapter
Building a service model in BMC Impact Model Designer

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

To build a service model in BMC Impact Model Designer, you must
I I I I I
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

You 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.
Chapter 6 Building a service model in BMC Impact Model Designer 65
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 items

To 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.
NOTE
BMC Software recommends creating a maximum of 20,000 service model CIs for each BMC ProactiveNet cell.
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.
66
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.
Chapter 6
67
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.
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.
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:

I
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.
68
Yes and Propagate to publish not only the CI but also all the providers of the CI to the cell.
NOTE
Ensure that you select this option for at least the top-level consumer CI in your service model.
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.
Chapter 6
69
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. Table 19
Field Account ID
Fields on the Other tab

Description 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. User-defined categorization of the CI. Used with the Type and Item attributes.
Category
Company, Department, Details of the business associated with the CI. Region, Room, Floor, Site, SiteGroup HomePageURI Item ManufacturerName URL of the Home page of the business. User-defined categorization of the CI. Used with the Category and Type attributes. 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 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.
Model
SelfPriorityFunctionPar Parameter that you can set to determine the priority of a CI. am SerialNumber Type VersionNumber Notes Manufacturer-allocated number used to identify the physical entity that the CI represents. User-defined categorization of the CI. Used with the Category and Item attributes. Version number of the physical entity that the CI represents. Displays additional information if any about the CI. Click Details to view the complete details.
6 Click OK to save the CI in the BMC Atrium CMDB.
70
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. Table 20
Icon
View mode switch icons

View mode Topology
Table
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.
Chapter 6
71
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

I
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:
I
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
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.
I
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.
Chapter 6
73
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
I I I
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 relationships

For 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.
74
Associating events with a configuration item
Associating events with a configuration item

When 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
Icon
Schedules and timeframes icons

Function Create a new service schedule or timeframe.
Edit the selected service schedule or timeframe.
Copy the selected service schedule or timeframe.
Chapter 6
75
Working with timeframes
Table 21
Icon
Schedules and timeframes icons

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

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
76
Table 22 provides descriptions of the fields in the Edit Timeframe dialog box. Table 22
Name Description Start, End
Timeframe Edit field descriptions

Name of the timeframe. Description of the timeframe. 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. 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.
Recurrence pattern
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.
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 1 On the toolbar, click the Schedules and Timeframes icon. 2 In the Schedules and Timeframes dialog box, on the Timeframes tab, select a
timeframe to copy.
3 Click the Copy icon.
Chapter 6
77
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 1 On the toolbar, click the Schedules and Timeframes icon. 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 1 On the toolbar, click the Schedules and Timeframes icon. 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.
78 BMC ProactiveNet Service Modeling and Publishing Guide
Figure 8
Edit Schedule dialog box
To create or edit a service schedule 1 On the toolbar, click the Schedules and Timeframes icon. 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
Name Usages (button)
Edit Schedule field descriptions

Name of the service schedule to create or edit. Opens the Schedules: Components assigned to this schedule dialog box that lists the components and component descriptions currently associated with the selected schedule.
Chapter 6
79
Table 23
Edit Schedule field descriptions

Description of the service schedule.
Description
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.
4 Click Save. To copy a service schedule 1 On the toolbar, click the Schedules and Timeframes icon. 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.
80
Assigning components to service schedules
To display the configuration items that are associated with a service schedule 1 On the toolbar, click the Schedules and Timeframes icon. 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 1 On the toolbar, click the Schedules and Timeframes icon. 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.
Chapter 6
81
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. 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.
Promoting the service model

After 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.
82
Before you promote
There are two modes of running the publishing server:

I
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:
I I
I I
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).
Chapter 6
83
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. Table 24
Action
Icons in Objects-to-be-Published pane

Icon Description object was deleted object was added object was modified
Column heading
Type
component relationship
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):
I
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.
84
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 data

For 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.
Chapter 6
85
Exporting class definitions from the BMC Atrium CMDB to cells
86
Chapter
Component and relationship status propagation

7
About component and relationship status

The 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 models 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 works

The 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 instances StatusComputationModel slot.
Chapter 7
87
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:
I I I
impact_function self_function consolidate_function
Table 25 lists the functions, their inputs, and the type of computed status that each function calculates. Table 25
Function impact_function
Status computation functions and computed component statuses

Description computes the impact status from status propagated by provider components computes the self_status from direct events computes the components computed_status from impact_status and self_status, or both, or from the no_alert_status of the status computation model Inputs Output status values propagated by impact_status inbound relationships severities of direct events associated with the component the impact status and the self-status self_status
self_function
consolidate_function
computed_status
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 CIs status is set to the computed_status except when you set the component to manual status, in which case, the CIs status is set to manual_status.
88
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 ValUsing 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).
WeightedStatus 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
Function self_function
What a function returns when using an available algorithm

Algorithm HIGHEST_VAL Returns the highest value among the severities of the direct events, after they have been automatically mapped to component status values
Chapter 7
89
About status computation models
Table 26
Function
What a function returns when using an available algorithm

Algorithm HIGHEST_VAL AVERAGE Returns the highest value among the status values of the provider components 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 the computed impact status is the lowest status that is propagated by the quorum percentage of providers (ignoring relationships propagating NONE) the higher value between the impact status and the self-status 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).
impact_function
QUORUM
consolidate_function
HIGHEST_VAL SELF_PREFERRED
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. Table 27
Standard
Description of predefined status computation models

Description computes the status of a component using the HIGHEST_VAL impact_function; the impact_status is the highest propagated_status of the incoming relationships computes the status of a component using the QUORUM impact function (see Quorum algorithm examples on page 91) 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.
Status computation model
Cluster
Weighted Cluster
Self-Preferred
computes the status of a component using the self-preferred algorithm for the consolidation_function
The BMC_STATUS_COMPUTATION data class is the basis of all status computation model instances.
90
Anatomy of a status computation model
Anatomy of a status computation model

A status computation model defines the following:
I I
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.
Function impact_function Input value Component has no inbound relationship. Inbound relationships propagate NONE as a status. self_function consolidate_function No events are associated with the component. Impact status value is NONE and self-status value is NONE or there are no inputs. Output value
NONE NONE NONE
default no-alert status value from the status computation model
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.
Chapter 7
91
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:
I
I I
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.
92
Relationship status propagation concepts
EXAMPLE
CASE A website 1 (quorum-based component status computation) host1 host2 Example A1 QUORUM=50, host1=OK, host2=IMPACTED 50*2/100 = 1 => i = 1 array = [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 A2 QUORUM=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 A3 QUORUM=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) host1 host2 host3 host4 Example B1 quorum_percent=30, host1=OK, host2=OK, host3=OK, host4=Minor 1<30*4/100<2=>q=2 array = [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 B2 quorum_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 B3 quorum_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
Relationship status propagation concepts

The cell performs status propagation for relationships and it relies on the status propagation model associated with each impact relationship instance.
Chapter 7
93
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-tomany 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.
94

A propagation model defines how the status of a provider component must be propagated in an impact relationship based on
I I
the current state of the relationship the current value of the providers status
Status propagation models are used only by impact relationships. Status propagation models serve the following purposes:
I
relationship controlenforcement of logical rules in creating new component relationships so that only valid relationships are created dynamic status mappingtranslating 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:
I
DIRECTconsumer component depends on the providers services to the extent
that its status is the same as the providers

I
INCREASINGconsumer component is overly dependent on the provider. When a
problem occurs, the consumers status degrades faster than the providers does
I
DECREASINGconsumer component can function without providers services.
When a problem occurs, the consumers status is less degraded than the providers
I
JUST_WARNINGpropagates 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_INFOpropagates 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
Chapter 7
95
What is a valid status propagation model?
Table 28 describes the how status propagation occurs for a specific model. Table 28 How status propagation models work in relationships
Status propagation model Relationship state Result DIRECT ACTIVE INACTIVE propagates the providers status without modification to the consumer propagation of the providers status is blocked by mapping the providers status to NONE This value is ignored by the consumer. INCREASING ACTIVE INACTIVE increases the impact of the providers status on the consumers status propagation of the providers status is blocked by mapping the providers status to NONE This value is ignored by the consumer. DECREASING ACTIVE INACTIVE decreases the impact of the providers status on the consumers status propagation of the providers status is blocked by mapping the providers status to NONE This value is ignored by the consumer. JUST_WARNING ACTIVE INACTIVE for statuses greater than OK, WARNING is propagated propagation of the providers status is blocked by mapping the providers status to NONE This value is ignored by the consumer. JUST_INFO ACTIVE for statuses greater than or equal to INFO, INFO is propagated; for statuses less than INFO, NONE is propagated propagation of the providers status is blocked by mapping the providers status to NONE This value is ignored by the consumer.
INACTIVE
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.
96
Important service components
A valid status propagation model must have:

I
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 models attributes
Important service components

Important 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.
Chapter 7
97
Dynamic prioritization
Figure 9
Propagation paths between root cause and important components
Component A is considered as a root cause of component B if

I I
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 prioritization
Dynamic 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 components self priority and impacts priority.
98
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
I I I
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: I base priority (default) I cost I 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.
NOTE
Normally, only one instance of this table should ever exist. If several instances exist, the instance with the lowest status is used.
Figure 10
Self priority determination
Chapter 7
99
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:
I
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 timefor 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.
100
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:
BMC_PUBLISH_DATA_CLASS : BMC_COST_OF_DOWNTIME_PRIORITY_MAPPING ISA BMC_SIM_DATA DEFINES { name: STRING, key=yes; cost: REAL; self_priority : MC_PRIORITY, key=yes; }; END
Enabling the cost method

To enable the cost method, you must modify the following slots in the MC_SM_COMPONENT class:
I
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:
I
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.
Chapter 7 Component and relationship status propagation
101
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

I I I I
name = n cost = costi self_priority = priorityi
such that costi < c
and there is no other instance j with

I
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.
102
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
103
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.
BMC_COST_OF_DOWNTIME_PRIORITY_MAPPING; name=test_cost; cost=1; self_priority=PRIORITY_4; END BMC_COST_OF_DOWNTIME_PRIORITY_MAPPING; name=test_cost; cost=2; self_priority=PRIORITY_3; END BMC_COST_OF_DOWNTIME_PRIORITY_MAPPING; name=test_cost; cost=5; self_priority=PRIORITY_2; END BMC_COST_OF_DOWNTIME_PRIORITY_MAPPING; name=test_cost; cost=10; self_priority=PRIORITY_1; END
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
I I
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
104
Self priority
Worst SLA state method

NOTE
The worst SLA state method can be used only if you are using the BMC Service Level Management product.
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:
I I I I
NO_SLAS COMPLIANT AT_RISK BREACHED
The SLA state for each component is assigned by BMC Service Level Management.
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.
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:
MC_PUBLISH_DATA_CLASS : BMC_WORST_SLA_STATE_PRIORITY_MAPPING ISA BMC_SIM_DATA DEFINES { name: STRING, key=yes; sla_state: MC_SM_SLM_SLA_STATUS; self_priority : MC_PRIORITY, key=yes; }; END
The enumeration MC_SM_SLM_SLA_STATUS is defined as follows:

ENUMERATION MC_SM_SLM_SLA_STATUS 0 NO_SLAS 10 COMPLIANT 20 AT_RISK 30 BREACHED END
105
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:
I
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
I I I
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.
106
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
107
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.
BMC_System; mc_udid=compx; Name=compx; SelfPriorityFunction=WORST_SLA_STATE; SelfPriorityFunctionParam=test_sla PriorityWatchdog=YES; END
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 components 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
108
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.
109
Figure 14
Final priority determination
110
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.
111
How SLA impact is calculated
112
Chapter
Managing BMC Impact Model Designer

8
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 CMDB

All 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 Administrators 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.
Chapter 8
113
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:
I
I I
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 ProactiveNetenabled 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:

I I
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:
I
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.
114
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.
Chapter 8
115
116
Chapter
Managing the BMC ProactiveNet Publishing Server

9
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 overview

The BMC ProactiveNet Publishing Server is an application that publishes a service model to the BMC ProactiveNet cell. The publishing server performs the following functions:
I
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
Chapter 9
117
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:
I
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.
118
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:
I I
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.
Chapter 9
119
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 configurations

This 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.
NOTE
If the specified port is not available when Service Model Manager is started, start up fails.
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.
120
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:
I
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
I I
%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.
Chapter 9
121
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.
I I
(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:

I I
(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.
122
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
Example event message BMC ProactiveNet Publishing Server started Configuration Configuration file location file name on the cell computer pserver.conf MCELL_HOME/etc/ps_hostName/ pserver.conf or if this file does not exist, then MCELL_HOME/etc/pserver.conf serverName connection failure. pserver.conf MCELL_HOME/etc/ps_hostName/ pserver.conf or if this file does not exist, then MCELL_HOME/etc/pserver.conf Chapter 9 Managing the BMC ProactiveNet Publishing Server 123
Type of event controlstatus events generated when the publishing server starts or stops in a controlled way connectionevents generated when the publishing server makes a connection with one of its surrounding components
Modifying the generation of events
Table 29
BMC ProactiveNet Publishing Server event generation

Example event message Class validation request failed. Configuration Configuration file location file name on the cell computer pserver.conf MCELL_HOME/etc/ps_hostName/ pserver.conf or if this file does not exist, then MCELL_HOME/etc/pserver.conf 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
Type of event requestevents generated for every publication and classinfo request that is processed by the publishing server errorevents that indicate there is a problem with the correct functioning of the publishing server
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).
EXAMPLE
In the relevant section of the pserver.conf file:
#--------------------------------------------------------------------------#Events #--------------------------------------------------------------------------#Events tracking Publishing Servers operation and errors are sent to im #<IPSEventsIM> #IPSEventsIM=<ImpactAdminCell> #By default IPS_EVENTs are generated to the Impact Admin Cell IPSEventsIM=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
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.

Understanding classes and slots for BMC ProactiveNet Publishing Server events
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=DEBUG log4j.logger.com.bmc.sms.ps=DEBUG, IPSERROREVENTS
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. Table 30
Slot name
Common Event Model (CEM) slots (part 1 of 2)

Slot label Description high-level normalized category of the object the event represents identifies the class of an object Default value
OPERATIONS_MANAGEMENT
mc_event_category Category mc_object_class Object Class
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 mc_host_class mc_host
Object Host Class Host
name of the BMC ProactiveNet Publishing Server instance type of host
ps_hostname Computer
name of the computer on which BMC not defined ProactiveNet Publishing Server is running network address of the host computer on which BMC ProactiveNet Publishing Server is running not defined
mc_host_address
Host Address
Chapter 9
125
Table 30
Slot name
Common Event Model (CEM) slots (part 2 of 2)

Slot label
Origin Class Origin
Description identifies the event management system type
Default value
BMC ProactiveNet Publishing Server
mc_origin_class mc_origin
ps_hostName specifies the event management system that is closest to the source of the event and is considered to have detected the event
mc_tool_class mc_tool
Tool Class Tool
the way in which the incident is reported to the cell defines where any event is within a value that can further distinguish where the event is coming from within the mc_tool_class value
BMC ProactiveNet Publishing Server ps_hostName
mc_tool_address
Tool Address
IP address of the host computer on not defined which BMC ProactiveNet Publishing Server is running
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_EVENT IPS_CONTROL IPS_START IPS_STOP IPS_CONFIG IPS_CNX IPS_CONNECT IPS_IM_CONNECT IPS_ERROR IPS_REQUEST IPS_CLASSINFO IPS_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.
126
IPS_STARTImpact 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. Table 31
Slot name
process_run_id
IPS_START slots
Slot label Process Run ID Description 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. value is the string status indicates the status of BMC ProactiveNet Publishing Server:
I I
mc_parameter
Status
mc_parameter_value Parameter Value
as it launches: starting when up and running: started
IPS_STOPImpact Publishing Server stop

The IPS_STOP class contains events that occur when the BMC ProactiveNet Publishing Server service (or process) is stopped. Table 32
Slot name
process_run_id
IPS_STOP slots
Slot label Process Run ID Description 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. seriousness of the event; default is INFO value is the string status indicates the status of the BMC ProactiveNet Publishing Server:
I I
severity mc_parameter
Severity Status
mc_parameter_value Parameter Value
when stopping: stopping when stopped: stopped
IPS_CONFIGImpact 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.
Chapter 9
127
Event generation for this class is enabled by default. Table 33

Slot name
os_class os_version process_run_id
IPS_CONFIG slots
Slot label
OS Class OS Version
Description indicates the class of the operating system indicates the version of the operating system 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. contains the version of the Publishing Server contains the software build number of the Publishing Server contains the build date of the Publishing Server contains the absolute path of the home directory for the Publishing Server contains the absolute path of the configuration file; pserver.conf is the default file contains the absolute path of the kb directory contains the absolute path of the log directory contains the absolute path of the cell directory file (default is mcell.dir) contains the absolute path of the trace configuration file; pserver.trace is the default file contains the absolute path of the trace file; pserver.trace if the default file
Process Run ID
ps_version ps_build_number ps_build_date home_dir conf_file kb_dir log_dir mcell_dir trace_conf trace_file
IPS Version IPS Build Number IPS Build Date Home Directory Configuration File KB Directory Log Directory Cell Directory File Trace Configuration File Trace File
IPS_CONNECTImpact Publishing Server connect

The IPS_CONNECT class contains events that occur when BMC ProactiveNet Publishing Server tries to establish a connection to other components.
128
Table 34
Slot name
IPS_CONNECT slots
Slot label
Request ID
Description 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.
ips_request_id
destination
Destination
type of the component to which the publishing server is connecting; possible values are:
I I I
CMDB for BMC Atrium CMDB IM for BMC Impact Manager SMM for Service Model Manager
dst_name dst_location dst_user
Destination Name Destination Location Destination User
name of the component to which the publishing server is connecting host and port number of the computer to which the publishing server is connecting 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

I I
SCS when the connection succeeds FLR when the connection fails
IPS_IM_CONNECTImpact 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. Table 35
Slot name
dst_location2
IPS_IM_CONNECT slots
Slot label Destination Secondary Location Description host and port number of the secondary BMC ProactiveNet Impact Manager server, if high availability is enabled
IPS_REQUESTBMC 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).
Chapter 9
129
Table 36
Slot name
severity
IPS_REQUEST slots (part 1 of 2)

Slot label
Severity
Description 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:
I I
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.
130
Table 36
Slot name
user_id
IPS_REQUEST slots (part 2 of 2)

Slot label
User ID
Description 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.
Chapter 9
131
IPS_PUBLISHBMC ProactiveNet Publishing Server publication request

The IPS_PUBLISH class contains events that occur when a request for a publication is generated. Table 37
Slot name
publish_type
IPS_PUBLISH slots
Slot label Description are
I
Publish Request Type indicates the type of publish; possible values
I I
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: I PROD for production environment I TEST.user.1 for BMC Impact Model Designer test environment
IPS_CLASSINFOBMC 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 38
Slot name
classinfo_type
IPS_CLASSINFO slots
Slot label
Class Info Request Type
Description indicates the type of classinfo; possible values are

I
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
132
About impact management data
IPS_ERRORBMC 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.
Table 39
Slot name
severity
IPS_ERROR slots
Slot label
Severity
Description indicates the seriousness of the event The default is WARNING
IPS_ENVBMC 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:
I I I I
creation of a publishing environment modification of a publishing environment initialization of CMDB datasets of an AtriumCMDB publishing environment removal of a publishing environment IPS_ENV slots
Slot label Origin ID Environment ID Environment Request Type Description contains the origin ID (AtriumCMDB or DirectPublish) of the publishing environment contains the IDs of the publishing environment contains the action open, set, init or close
Table 40
Slot name
origin_id env_id env_type
About impact management data

Management 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.
Chapter 9
133
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 environments

A 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.
Publish origin BMC Atrium CMDB Publish is initiated from
I I I
OriginID AtriumCMDB
BMC Impact Model Designer Completion of reconciliation job CLI command publish CLI command pposter CLI command publish
Direct Publish Cell Publish
I I
DirectPublish CellPublish
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.
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 environments parameter home cell defines the one cell to which all service model data and management data is sent. The components 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.
Chapter 9
135
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 components HomeCellAlias attribute). 2. The components 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 CMDB

In AtriumCMDB Publish environments, you can do the following activities:
I
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.
136
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 components cell name, a cell alias is automatically created and managed by BMC Remedy AR System.
I
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.
Chapter 9
137
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:
Dataset and form in BMC Atrium CMDB asset dataset: by default, BMC.ASSET This is the dataset from which service model data is published to cells. regular dataset PN:PublishedData form contains information about published CIs
I I
Description contains objects to be published
Comments
I
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 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
The production service model data is in the BMC Atrium CMDB in the production dataset BMC.ASSET.
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.
138
Creating advanced publishing environments
Creating advanced publishing environments

To do advanced publishing for BMC ProactiveNet data in AtriumCMDB Publish environments, you need to Table 41
Basic steps 1. Determine the cells to use and create if necessary. 2. Register any new cells in BMC Atrium Core Console (which automatically creates them in BMC Atrium CMDB). 3. Determine the source of the service model data (another environment or a BAROC source file). 4. Define the environment. 5. Enter the data in the BMC Atrium CMDB. If cells are running, this initializes cells with this data. 6. Publish the objects to the cell. 7. Troubleshoot problems. Execute a CLI command publish See Appendix A, Troubleshooting
Basic steps to create advanced test environments

How to do See BMC Impact Solutions Infrastructure Administration Guide See BMC Impact Solutions Infrastructure Administration Guide Use the penv init parameter SourceBarocMgmtData. Create a BAROC source file. Execute a CLI command penv open Execute a CLI command penv init
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
I I
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.
Chapter 9
139
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.
I I I
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:
Environment EnvId CellAlias CellName arwad
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 1Creating 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.
140
1. You define two environments for the two different departments, by executing the following command:
EXAMPLE
>penv open -e dept1 >penv open -1 dept2
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 2Publishing 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 -e SIMULATION -p AssetDataSetId=BMC.ASSET -p HomeCell=simulation
Chapter 9
141
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:
EXAMPLE
penv -e SIMULATION -p AssetDataSetType=Overlay -p HomeCell=simulation -p AutomatedPublish=T
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-ofthe-box.
142
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:
I
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.
Chapter 9
143
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
I I I
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.
144
Examplecreating BMC ProactiveNet data in BMC Atrium CMDB from BAROC files
Examplecreating 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
Chapter 9
145
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 reconciliations 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
146
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,
I
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
Chapter 9
147
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 nonexistent 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 plugin 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 Servers 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.
148
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:
I I I
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 source

When 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
For instructions, see Enabling Direct Publish publishing on page 153.
Basic process 1. Enable Direct Publishing.
2. Create a Direct Publish environment for Sending BMC ProactiveNet data to the cell the BMC ProactiveNet management data. on page 153 3. Create a Direct Publish environment for CIs and impact relationships. Sending BMC ProactiveNet data to the cell on page 153
Chapter 9
149
About home cell and cell alias
Table 42
Basic process of publishing from a Direct Publish source

For instructions, see BMC ProactiveNet Command Line Interface Reference Manual BMC ProactiveNet Command Line Interface Reference Manual
Basic process 4. Create a source file that contains the service model data in BAROC format. 5. Send service model data in the BAROC source file to the cells.

Table 43 describes the parameters that apply to a Direct Publish environment. Table 43 Valid parameters for a Direct Publish environment
Function 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.
Parameter name CellAliases
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 components HomeCell or HomeCellAlias slots) 2. Only cell aliases and cell names defined in the publishing environment's CellAliases parameter are used.
150
3. If the components 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.
Chapter 9
151
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.
152
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 I EnvId represents the name of the environment you are creating. I 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.
NOTE
When you modify the value of the parameter CellAliases, you must redefine all cell aliases.
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="
Chapter 9
153
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.
Examplesusing 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]
154
Examplesusing 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:
EXAMPLE
pposter -e Sales sales.baroc
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:
EXAMPLE
penv open -e Sales.Test OriginId=DirectPublish -p CellAliases=[austin, austin_test, brussels, brussels_test]
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
pposter -e Sales sales_test.baroc
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
penv open -e Sales.Training -p OriginId=DirectPublish -p CellAliases=[austin, austin_training, brussels, brussels_training]
Chapter 9
155
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:
EXAMPLE
pposter -e Sales.Training sales.baroc
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-tocellname pairs as austin, austin_training and brussels, brussels_training. See Determining the cell to which a component is published on page 150.

You 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 CLIs 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.
156
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:
EXAMPLE
penv set -e Accounting -p Password=ut0p1a -p HomeCell=cell2
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:
penv open -e EnvId -p OriginId=DirectPublish|AtriumCMDB -p NewPassword1=the_password -p NewPassword2=the_password
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:
EXAMPLE
penv open -e Sales -p OriginId=DirectPublish -p NewPassword1=sam3ul -p NewPassword2=sam3ul
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:
penv set -e EnvId -p NewPassword1=the_password -p NewPassword2=the_password
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:
Chapter 9
157
pserver.conf file and parameters
penv set -e EnvId -p Password=old_password - p NewPassword1=new_password -p NewPassword2=new_password
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:
penv set -e EnvId -p Password=old_password - p NewPassword1= -p NewPassword2=
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:
EXAMPLE
publish -e Accounting -p Password=l0b3l1a
Automated publishing for a secured Atrium CMDB Publish environment is preauthenticated.
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:
EXAMPLE
pposter -e Payroll -p Password=86a032 sm_payroll.baroc

This 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.
158
Table 44
Filename File path Description
pserver.conf file
pserver.conf MCELL_HOME/etc/ps_hostname or if that file does not exist MCELL_HOME/etc contains the configuration settings that control the behavior of the BMC ProactiveNet Publishing Server Description 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. Default value log
Parameter name
SystemLogDirName
AtriumCMDBPublishOrigin AtriumCMDBHeartbeatInterval
enables (T) or disables (F) publishing from publishing server to a cell 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.
T (true) 180 (seconds)
AtriumCMDBDefaultEnvId
identifies the default environment for the BMC Atrium PROD CMDB publication. If the environment does not already exist, it will be created when pserver starts. BMC.ASSET
AtriumCMDBDefaultAssetDatase identifies the default asset dataset for the default tId publish environment of BMC Atrium CMDB. The
default environment is created when pserver uses this asset dataset.

AtriumCMDBDefaultFilterIds
lists the default filters. When pserver creates the default environment, it registers the default filters for this environment.
PublishProvider sToSIM,Service ModelSet,Home Cell,ExtAuth 180 (seconds)
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.
CellPublishOrigin CellPublishIms
enables (T) or disables (F) publishing from staging cells T (true) 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""
Chapter 9
159
Table 44
pserver.conf file
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 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. T (true)
CellPublishGateway
CellPublishGatewayName
not defined, set by install
CellPublishGatewayIms
lists the cells from which the Publishing Server accepts not defined incoming events. If no cell is listed then all incoming events are accepted.
CellPublish2CmdbContinueOn Warning
enables (T) or disables (F) continuation when instances F (false) that cannot be imported must skipped The list of skipped instances and the reason they were skipped is output to the request log.
CellPublish2CmdbReconJobTime defines the length of time, in seconds, that Out CellPublish2Cmdb checks for the termination of the
120 (seconds)
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.
CellPublishCommitRetryTime Out
900 (seconds) 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.
Cells
gives the cells for which pserver creates the cell information in BMC Atrium CMDB
160
Table 44
pserver.conf file
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)
ClassInfoValidation
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 enables (T) or disables (F) direct publishing feed if enabled, the offending duplicate alias is dropped from the CI that reports the collision. enables (T) or disables (F) the enterprise mode of operation 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. F (false) T (enabled) F (false) localhost:9379
DirectPublishOrigin DropDuplicateComponentAlias Enterprise JNPServers
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
10 (seconds) -1 (connection attempts)
attempts
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.
Chapter 9
161
Table 44
pserver.conf file
the interval (in seconds) between two reconnection attempts specifies the name of the computer on which BMC Atrium CMDB resides defines the port number for connecting to the BMC Atrium CMDB 300 (seconds) not defined, set by install not defined, set by install use 0 for dynamic port detection
JMSCommMajorReconnect Interval CMDBServer CMDBPort
CMDBUser CMDBPassword
defines the user ID that grants access to the BMC Atrium CMDB a valid BMC Atrium CMDB user password appears in plain text when entered; encrypted at first launch
not defined, set by install not defined, set by install
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 CellConnectionTimeout
sets the maximum number of request log files that are retained by the publishing server
-1
sets the length of time the publishing server maintains 60 (seconds) a connection to a cell when there is no activity from the cell sets the size of the message buffer for communication with the cell sets the time to keep messages buffered while waiting for an answer 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. 2000 300 (seconds) mcell.dir
IMMessageBufferSize IMMessageBufferKeepSent IMFileDirectoryName
PasswordLogging SMMMessageBufferSize SMMMessageBufferKeepSent
enables (T) or disables (F) the display of passwords in generated request logs and IPS_REQUEST events sets the size of the message buffer for communication with Service Model Manager sets the time to keep messages buffered while waiting for an answer
F (false) 500 300 (seconds)
162
Table 44
pserver.conf file
enables (T) or disables (F) the use of the estimate when T (true) the length of time exceeds the value that is calculated for the upload time of the service model sets the time to stop waiting on a BMC Remedy AR System operation that occurs quickly sets the time to stop waiting on a BMC Remedy AR System operation that occurs slowly sets the time to stop waiting on a BMC Remedy AR System operation that occurs slowly 300 (seconds) 600 (seconds) 1800
SMMMessageBufferKeepSent Estimate ARSNormalTimeOut ARSLongTimeOut ARSXLongTimeOut ARSXLongTimeOutEstimate
enables (T) or disables (F) the use of the estimate when T (true) the length of time exceeds the value that is calculated for committing bulk entry transactions 5 (seconds) 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.
AutomatedCancelAckTimeout
AutomatedCancelScsFlrTimeout When automated publishing is stopped, an ongoing
900 (seconds)
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.
AutomatedHeartbeatInterval
sets the length of time between the publishing server 60 (seconds) and the AR Notify plugin for heartbeat. 0 or a negative value disables heartbeat. sets the length of time that the publishing server waits 5 (seconds) for an answer to a heartbeat from the AR Notify plugin.
AutomatedHeartbeatTimeout
Chapter 9
163
Configuring the Notify ARDBC plug-in
Table 44
pserver.conf file
the maximum number of times automated publishing is retried after failures
n represents the number of repeated publication attempts:
I I I
AutomatedPublishRetryCount
12
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.
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 automated 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. defines the cell to which publishing server events are sent not defined, set by install to BMC ProactiveNet cell all subclassess of IPS_EVENT
IPSEventsIM
IPSEventClasses
defines the event classes for which publishing server events are created
Configuring the Notify ARDBC plug-in

The 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
164
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. Table 45
Parameter
BMC-ARDBC-NOTIFY-Verify-Log
ar.cfg file parameter descriptions

Description log file location Default value Remedy AR System/ Impact directory 1840, set by install
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.
BMC-ARDBC-NOTIFY-Protocol-V1-Encrypt switches encryption for V1 protocol on or off T (True)
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.
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 200 When the size is 0, event caching is disabled
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:
Chapter 9 Managing the BMC ProactiveNet Publishing Server 165
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.
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.
Viewing publication history

This 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:
I
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 issues

Use the following guidelines to diagnose why a CI is not published:
166
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.
Chapter 9
167
168
Appendix
Troubleshooting
This section describes problem solving for the BMC Impact Model Designer and the publishing server.
Publishing Server
This 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.
Appendix A
Troubleshooting
169
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:
I
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.
170
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.
I
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.
I
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 -
Appendix A
Troubleshooting
171
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=-Xss1M wrapper.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:
I I I
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
172
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.
Appendix A
Troubleshooting
173
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.
174
Table 46
Publishing server request failure messages (part 1 of 4)

Cause 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. Action 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
Failure message
Classinfo is not synchronized.
cell in the
MCELL_HOME/etc/cellName/kb/class es directory.
Recompile the cells Knowledge Base, and restart the cell.

Component alias "{0}" for component "{1}" is already used by component "{2}"
Two CIs have the same alias.
I I
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 cells location and encryption key are registered with BMC ProactiveNet Performance Management. 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.
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)
Appendix A
Troubleshooting
175
Table 46

Cause In a cell's trace file you find the message Service Model Manager
process ({0}) not active within expected delay. Please verify.
Failure message
IM {0} failed to launch SMM (Service Model Manager)
Action Increase the value of

ServiceModelManagerStartTimeOut.
The cell does fork a Service Model Manager (SMM) process. In the mcell.conf file, the parameter
ServiceModelManagerStartTimeOut = 60
defines the timeout.
IM {0} failed to upload service model from SMM
This failure message displays after Reinitialize the cell and publish a failure in the second phase of again (to avoid subsequent two-phase commit. publishes failing with the message
Unique data identifier not/already in use)
IM is not publish enabled.
Reset the ServiceModelPublish The ServiceModelPublish parameter in the parameter to Yes and restart the MCELL_HOME/etc/mcell.conf file cell. or in MCELL_HOME/etc/<CellName>/ mcell.conf file is set to No. 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.
init verify failure
No user group defined with id {0}
In the BMC Atrium CMDB, a CI's Modify the CIs to point only to existing user groups. 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.
176
Table 46

Cause The data instance is already published to the cell from another publish environment. Action Use the instance's publish environment to publish modifications or deletions.
Failure message
Operation on instance of different environment Provider_home_cell ({0}) is remote but component {1} is local
This error can occur as a result of a Correctly register the ports of the cells. 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
I
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. Publish returns generic failure message, such as Publish
validation of Impact Manager failed The AR System Plug-In server is not responding (ERROR8939)
Publication failure
Use the -v option (publish -v) to return both generic and detailed (verbose) failure messages.
Try the following workarounds: When the load on the BMC Remedy Action Request (AR) System server plug-in is very high, I Start another publication. the system sometimes returns a I Restart the BMC Remedy AR connection error. System server. I Adjust the BMC Remedy AR System server configuration parameters (see pserver.conf file and parameters on page 158). The attribute HomeCellAlias has a Define the cell aliases correctly. value that is not defined in the publish environment's CellAliases. The version of the target cell Uninstall the earlier version and instance is earlier than the required install the appropriate version. version. Appendix A Troubleshooting 177
The cell alias is not mapped to a cell name in the current environment The minimum supported protocol version is 7.
Table 46

Cause A service CI with the same mc_udid is already published in the cell. Action 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.
Failure message
Unique data identifier already in use.
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 with the -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 Correct mcell.dir. consumer's cell is not defining the provider's cell. 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.
You may receive detailed failure messages from the BMC Atrium CMDB.
178
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:
I I I
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 Questions

This section contains some frequently asked questions about BMC Impact Model Designer.
Appendix A
Troubleshooting
179
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:
I
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.
180
I cannot see the changes I made to the CIs
Figure 16
BMC Atrium Explorer and BMC Impact Model Designer icons
Atrium Explorer icon
BMC Impact Model Designer icon
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.
Appendix A
Troubleshooting
181
Troubleshooting BMC Impact Model Designer
Troubleshooting BMC Impact Model Designer

The 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
Cause Action
Error Message
Changes submitted could not be When you select multiple groups Deselect one or more groups on the saved. Please refer log for details. on the Permissions tab in the Edit Permissions tab in the Edit Component Properties dialog box, 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.
Javax.naming.CommunicationExc This error may be displayed when Use the psstat cli command to eption: Failed to retrieve stub you try to connect to the connect to the publishing server. If from server <server_name> publishing server. 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\syste m32\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.
182
Appendix
Default service model data classes

This appendix describes the service model class hierarchy in the BMC Atrium CMDB Common Data Model.
Service model data structures

The 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:
I
Component data classesthe 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 classesthe 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 classesthe classes that define the product event types and their behaviors.
Appendix B
183
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. Table 48 Service management data class files
File name mc_sm_object.baroc Contents these component types and their subclasses:
I
Data classes Component
BMC_BaseElement I BMC_Collection I BMC_LogicalEntity I BMC_System I BMC_SystemComponent I BMC_SystemService
Root
mc_sm_root.baroc
event and data classes and the enumerations that are the foundation of the solution mapping data classes that provide the event-to-component mapping mechanism
Mapping
mc_sm_event_mapping.baroc
Service model component data classes

A 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.
184
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:
I I I I I
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. 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
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.
Appendix B
185
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.0 possible_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
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.
186
Figure 19
MC_SM_DATA definition
MC_DATA_CLASS : MC_SM_DATA ISA CORE_DATA; END
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
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
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. Table 49
Slots
AccountId
Slots that define CIs (part 1 of 4)

Description
identification of the Account the object belongs to (Accounts are created in BMC ProactiveNet Performance Management) maximum severity across all underlying events maximum severity across all underlying events whose status = OPEN
Data type or enumeration

STRING
Source class
BMC_BaseElement
any_event_max_sev any_open_event_max_sev
SEVERITY SEVERITY SEVERITY
MC_SM_COMPONENT MC_SM_COMPONENT MC_SM_COMPONENT
APPLICATION_event_max_ highest severity of all the attached events sev for which mc_event_subcategory = APPLICATION Category change_number
provides a user-defined categorization of a STRING CI increments every time an event is sent for INTEGER the component. Used to determine the order of events for events which happen in the same second. number of CIs acting as consumers of the CI INTEGER
BMC_BaseElement MC_SM_COMPONENT
consumer_num comment
MC_SM_COMPONENT MC_SM_COMPONENT
a comment that is set for the component via STRING BMC Impact Manager
Appendix B
187
Table 49
Slots

Description
scope of the component (local, shadow, etc.)

STRING
Source class
MC_SM_COMPONENT MC_SM_COMPONENT
component_scope computed_priority
the priority of a component that is the enumeration: MC_PRIORITY highest between self priority and impacts priority. Set in the computed_priority field. status of the CI computed from self and substatuses function used to determine impact_status from the providers propagated status the current cost for the component depending on the current value of the schedule (either During Schedule or Exceptions Within During Schedule) identifier in local cell
computed_status consolidate_function cost
enumeration: MC_SM_COMPONENT MC_SM_COMPONENT_STATUS enumeration: MC_SM_CO_FUNCTION REAL MC_SM_COMPONENT MC_SM_COMPONENT
data_handle
INTEGER
CORE_DATA MC_SM_COMPONENT
DATABASE_event_max_sev highest severity of any event of a particular SEVERITY 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. STRING
BMC_BaseElement
Description direct_events_count HomeCell
a description of the CI that is meaningful to STRING the enterprise count of events coming from instrumentation name of the parent cell for the CI INTEGER STRING REAL STRING REAL
BMC_BaseElement MC_SM_COMPONENT MC_SM_COMPONENT MC_SM_COMPONENT BMC_BaseElement MC_SM_COMPONENT MC_SM_COMPONENT BMC_BaseElement MC_SM_COMPONENT
highest_pn_predicted_severi highest value of all alarm events attached ty to the CI ImpactCostPerSec ImpactCostPerSec ImpactCostPerSecOut ImpactCostUnit impact_priority impact_status cost of one second of unavailability of the component cost for a component when it is During Schedule
cost for the component when it is in an REAL Exceptions Within During Schedule period unit of the cost expressed in ImpactCostPerSec priority determined from a components impacts status computed by impact_function STRING enumeration: MC_PRIORITY
enumeration: MC_SM_COMPONENT MC_SM_COMPONENT_STATUS MC_SM_COMPONENT STRING BMC_BaseElement BMC_BaseElement MC_SM_COMPONENT MC_SM_COMPONENT
impacting_open_event_max maximum severity of impacting (causal) _sev events whose status = OPEN InstanceId Item last_status_modification maintenance_mode instance identification of a component within the BMC Atrium CMDB
Provides a user-defined categorization of a STRING CI last time the status or sub_status was changed (used by GUI) operational switch used to drop events when UM INTEGER enumeration: MC_YESNO
188
Table 49
Slots

Description
manual status flag of the component (NONE if not set)
Source class
manual_status manual_status_comment manual_status_providers
enumeration: MC_SM_COMPONENT MC_SM_COMPONENT_STATUS MC_SM_COMPONENT MC_SM_COMPONENT
comment entered by user when CI is set to STRING manual status list of direct and indirect providers; mc_udids of CIs with manual status set (may contain duplicate entries LIST_OF_STRING
manual_status_providers_co number of direct and indirect providers unt with manual status set (may contain duplicate entries) manual_status_requestor ManufacturerName mc_creation_time mc_modification_time mc_modification_requestor mc_udid Model Name login ID of user who sets the CI to manual status name of the company that manufactured the CI
INTEGER
MC_SM_COMPONENT
STRING STRING
MC_SM_COMPONENT BMC_BaseElement CORE_DATA CORE_DATA CORE_DATA CORE_DATA BMC_BaseElement BMC_BaseElement MC_SM_COMPONENT
date and time when the object was created INTEGER date and time when the object was last changed modification requestor universal data identifier model assigned to the CI by the manufacturing company INTEGER STRING STRING STRING
user-defined name that is meaningful to the STRING enterprise
NETWORK_event_max_sev highest severity of any event of a particular SEVERITY sub-category that is attached to the CI or any other CI (inactive relationships are ignored) Notes OTHER_event_max_sev OwnerContact general notes on the object INTEGER
BMC_BaseElement MC_SM_COMPONENT BMC_BaseElement
highest severity of all the attached events SEVERITY for which mc_event_subcategory = OTHER A string that provides information on how STRING the primary system owner can be reached (e.g. phone number, e-mail address name of the person in the enterprise who is STRING responsible for the CI lowest value amongst all the alarms sharing the highest pn_predicted_severity slot list of possible causes for the components current status (different from root causes) priority indicates whether the component is a priority propagator the computed priority for an object (value between 0 and 1) list of permission groups that defines who has read access to a CI list of root causes for the components current status INTEGER
OwnerName pn_predict_to_occur_time
possible_causes Priority PriorityWatchdog raw_impact_priority ReadSecurity root_causes
LIST_OF_STRING enumeration: MC_PRIORITY enumeration: MC_YESNO REAL LIST_OF_STRING LIST_OF_STRING
MC_SM_COMPONENT MC_SM_COMPONENT MC_SM_COMPONENT MC_SM_COMPONENT BMC_BaseElement MC_SM_COMPONENT
Appendix B
189
BMC_Impact data class
Table 49
Slots

Description Data type or enumeration Source class
BMC_BaseElement MC_SM_COMPONENT short textual description (one-line string) of STRING the object indicates whether the component is currently During Schedule or Exception Within During Schedule enumeration_ MC_SM_SCHEDULE_STATUS
ShortDescription schedule_status
self_priority
the priority of the component based on the enumeration: MC_PRIORITY base priority and the components current 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
self_status
enumeration: MC_SM_COMPONENT MC_SM_COMPONENT_STATUS MC_SM_COMPONENT MC_SM_COMPONENT
sla_roleup_status shadow_cells status
the aggregation of the compliance status of enumeration: the associated SLAs, if any MC_SM_SLM_SLA_STATUS list of cells that contain shadow of the CI main status of the component (equals computed_status unless manual status is set) name of the status computation model derived status of the CI LIST_OF_STRING
enumeration: MC_SM_COMPONENT MC_SM_COMPONENT_STATUS STRING MC_SM_COMPONENT
StatusModel sub_status SYSTEM_event_max_sev
enumeration: MC_SM_COMPONENT MC_SM_COMPONENT_STATUS MC_SM_COMPONENT
highest severity of any event of a particular SEVERITY sub-category that is attached to the CI or any other CI (inactive relationships are ignored) user-defined categorization of a CI STRING
Type
USER_TRANSACTIONS_ev highest severity of any event of a particular SEVERITY ent_max_sev sub-category that is attached to the CI or any other CI (inactive relationships are ignored) VersionNumber WriteSecurity version number of the CI, assigned by the manufacturer list of permission groups that define who has write access to a CI LIST_OF_STRING LIST_OF_STRING
BMC_BaseElement BMC_BaseElement

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.
190
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
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_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_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_DATA_CLASS: MC_SM_DATA ISA CORE_DATA; END
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.
Appendix B
191
Figure 24
CORE_DATA definition
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
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. Table 50
Slot consumer_id change_number data_handle
BMC_Impact slot definitions in alphabetical order (part 1 of 2)

Description mc_udid of the consumer CI change number identifier in local cell Data type or enumeration STRING INTEGER INTEGER INTEGER Source class MC_SM_ RELATIONSHIP MC_SM_ RELATIONSHIP CORE_DATA MC_SM_ RELATIONSHIP CORE_DATA CORE_DATA CORE_DATA MC_SM_ RELATIONSHIP MC_SM_ RELATIONSHIP MC_SM_ RELATIONSHIP
last_status_modification date/time when the value of true_impact function was last changed (used by GUI) mc_creation_time mc_modification_time mc_udid propagated_status date and time when the object was created date and time when the object was last changed internal key used to reference the relationship; it is an inherited slot status that is currently propagated through the relationship maximum of provider substatus and status values name of the status propagation model used for determining the propagated status from of the providers main status
INTEGER INTEGER STRING enumeration: MC_SM_COMPONENT_ STATUS enumeration: MC_SM_COMPONENT_ STATUS STRING
propagated_sub_status
PropagationModel
192
BMC_DOWNTIME_STATUS_CONFIG data class
Table 50
Slot
BMC_Impact slot definitions in alphabetical order (part 2 of 2)

Description Data type or enumeration Source class MC_SM_ RELATIONSHIP MC_SM_ RELATIONSHIP MC_SM_ RELATIONSHIP MC_SM_ RELATIONSHIP MC_SM_ RELATIONSHIP name of the class of the provider CI STRING the cell that receives events for the provider CI mc_udid of the provider CI, the impacting CI state of the relationship, Active or Inactive STRING STRING enumeration: MC_SM_RELATIONSHIP _STATE
provider_classname provider_home_cell provider_id State
StatusWeight
number that determines the degree INTEGER of importance to give to each provider relationship that impacts a consumer CI flag indicating whether this relationship affects the impact_status of the consumer enumeration: MC_SM_YESNO
true_impact
MC_SM_ RELATIONSHIP
BMC_Impact enumerations
The following enumerations are listed in the mc_sm_root.baroc file:
I I I I I I I I I I I I I
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.
Appendix B Default service model data classes 193
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. 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
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. 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
BMC_DOWNTIME_STATUS_CONFIG slots
BMC_DOWNTIME_STATUS_CONFIG has the following slot. Table 51
Slot
BMC_DOWNTIME_STATUS_CONFIG slot
Data type or enumeration enumeration: MC_SM_COMPONENT_STATUS Source class BMC_SIM_DOWNTIME_ST ATUS_CONFIG
Description
status the lowest component status that qualifies as down time

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.
194
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. 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
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 Figure 28 BMC_SIM_DATA definition
BMC_STATUS_COMPUTATION slots in alphabetical order

Table 52 alphabetically lists the BMC_STATUS_COMPUTATION slots with their descriptions and types. Table 52
Slot
BMC_STATUS_COMPUTATION slots in alphabetical order (part 1 of 2)

enumeration: MC_SM_CO_FUNCTION BMC_STATUS_COMPUTATION
consolidate_function name of the algorithm used to compute the component computed status; it consolidates the impact_status and the self_status 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
Appendix B
195
BMC_STATUS_PROPAGATION data class
Table 52
Slot
BMC_STATUS_COMPUTATION slots in alphabetical order (part 2 of 2)

BMC_STATUS_COMPUTATION name of the algorithm used to enumeration: compute the impact status from MC_SM_IMPACT_FUNCTI provider components; it ONS merges the propagated status values of the different provider components name of the status computation STRING model (key of the table) default main status when the consolidate functions status is NONE
impact_function
model_name noalert_status
enumeration: BMC_STATUS_COMPUTATION BMC_BaseElement_STATUS BMC_STATUS_COMPUTATION
quorum
quorum percentage applied by INTEGER the impact function when set to use the QUORUM algorithm list of permission groups that defines who has read access to a CI LIST_OF_STRING
ReadSecurity
BMC_SIM_DATA
self_function
name of the algorithm used to enumeration: compute the self status; it maps MC_SM_SELF_FUNCTION and merges the severity values directly from the events list of permission groups that LIST_OF_STRING defines who has write access to a CI
WriteSecurity
BMC_SIM_DATA
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. 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
196
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. Figure 30 BMC_SIM_DATA definition
BMC_STATUS_PROPAGATION slots in alphabetical order

Table 53 alphabetically lists the class slots with their descriptions. Table 53
Slot
Status propagation slots in alphabetical order

Description Data type STRING STRING Source class BMC_STATUS_PROPGATION BMC_STATUS_PROPGATION BMC_STATUS_PROPGATION
consumer_typ valid component types for the e consumer CI description name description applicable to the relationships using this model
name of the status propagation STRING model; it must match the name of a propagation map
ReadSecurity
list of permission groups that LIST_OF_STRING BMC_SIM_DATA defines who has read access to a CI STRING BMC_STATUS_PROPGATION
provider_type valid component types for the provider CI WriteSecurity list of permission groups that defines who has write access to a CI
LIST_OF_STRING BMC_SIM_DATA

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.
Appendix B
197
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
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 Figure 32 BMC_SIM_DATA definition
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. Table 54
Slot name
BMC_PROPAGATION_MAP slot definitions

Description Data type or enumeration Source class BMC_PROPAGATION_MAP name of the parent STRING status propagation model enumeration: MC_SM_COMPONENT_STATUS
propagated_status status to be propagated to the consumer component provider_status status of the provider component
BMC_PROPAGATION_MAP
enumeration: MC_SM_COMPONENT_STATUS
BMC_PROPAGATION_MAP
ReadSecurity
list of permission LIST_OF_STRING groups that defines who has read access to a CI applicable relationship state
BMC_SIM_DATA
relationship_state WriteSecurity
enumeration: BMC_PROPAGATION_MAP MC_SM_RELATIONSHIP_STATE BMC_SIM_DATA
list of permission LIST_OF_STRING groups that defines who has write access to a CI
198
BMC ProactiveNet data class descriptions
BMC ProactiveNet data class descriptions

The following data classes are used in creating service models:
I I I I I
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. 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
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.
Appendix B
199
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. 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
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. 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_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.
200
BMC_SELF_PRIORITY_MAPPING data class
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
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. 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
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 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
Appendix B
201
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. 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
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. 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_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.
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 classes

The 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.
Appendix B
203
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;
204
Root event class
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; };
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. Figure 42 MC_SMC_ROOT definition
MC_EV_CLASS : MC_SMC_ROOT ISA EVENT; END
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.
Appendix B
205
Impact event class
Figure 43 shows the BAROC definition of the SMC_STATE_CHANGE class, which is located in the state.change.baroc file. 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
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. 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
Events of class MC_SMC_EVENT, or any custom subclass of that class, are not used in the status computation process.
206
Appendix
Upgrading a service model to BMC Atrium CMDB

C
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.
Appendix C
207
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 steps

Use 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.
208
Understanding how the upgrade works
9 Verify that the output file contains no excluded data. NOTE

If more excluded data is found in the output file, continue through step 12.
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.
Appendix C
209
Ensuring quality data in BMC Atrium CMDB
Replacement in the cell is based on

I
for CIsthe 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.
I I
for impact relationshipsthe consumer_id and provider_id attributes for management datakey attributes of the class
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.
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
I
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.
210
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.
I
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 cells 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.
Appendix C
211
sim2cmdb has a default set of identification groups for identifying the components in
the BMC Atrium CMDB. Table 56 lists these identifying components.

I I I I
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

Classes that inherit the rule Best match attributes Name Name ApplicationType Name ApplicationInfrastructureType Name SystemName SystemClassId BMC_DataBase BMC_ApplicationSystem BMC_Cluster BMC_ConnectivityCollection BMC_ConnectivitySegment BMC_IPConnectivitySubnet BMC_LNsCollection BMC_LAN BMC_WAN Name Autoidentify Yes No No No
Base class of the identification group BMC_Activity BMC_Application BMC_ApplicationInfrastructure BMC_ApplicationService
BMC_BaseElement
No
BMC_BusinessProcess BMC_BusinessService BMC_ComputerSystem BMC_Mainframe BMC_VirtualSystem BMC_Media BMC_CDROMDrive BMC_DiskDrive BMC_FloppyDrive BMC_TapeDrive BMC_UPS
Name SourceLocation Name HostName Domain SerialNumber Name SystemName SystemClassId SerialNumber
Yes Yes No
BMC_HardwareSystemComponent
No
BMC_IPXConnectivityNetwork BMC_LogicalSystemComponent BMC_FileSystem BMC_DataBaseStorage BMC_LocalFileSystem BMC_RemoteFileSystem BMC_DiskPartition BMC_SystemResource
Name NetworkNumber Name SystemName SystemClassId
No No
BMC_Organization
Name
Yes
212
Table 55
Identifying components in the BMC Atrium CMDB

Classes that inherit the rule Best match attributes Name SoftwareServerType BMC_OperatingSystem Name SerialNumber VersionNumber Name Name SystemName SsytemClassId Name SystemName SystemClassId VMImageName Autoidentify No No
Base class of the identification group BMC_SoftwareServer BMC_SystemSoftware
BMC_UserCommunity BMC_VirtualSystemEnabler
Yes No
BMC_VMWare
No
The reconciliation rules for management data are based on the key slots of the classes. Table 56
Class BMC_COST_OF_DOWNTIME_PRIORITY_MAPPING BMC_DOWNTIME_STATUS_CONFIG BMC_PROPAGATION_MAP name relationship_state provider_status priority status severity status tag input_match event_class model_name name provider_type consumer_type status severity Timeframe Schedule
Key slots in reconciliation rules for management data

Keys name self_priority Auto-identify Yes Yes Yes
BMC_SELF_PRIORITY_MAPPING BMC_SERVICE_SCHEDULE_CONFIG BMC_SEVERITY_TO_STATUS BMC_SIM_MATCH_TABLE BMC_SLOT_FORMULAS BMC_STATUS_COMPUTATION BMC_STATUS_PROPAGATION
Yes Yes Yes Yes Yes Yes Yes
BMC_STATUS_TO_SEVERITY BMC_TIME_FRAME_TO_SCHEDULE BMC_TIME_SCHEDULE
Yes Yes Yes
Appendix C
213
Data imported into BMC.SIM
Table 56
Class
Key slots in reconciliation rules for management data

Keys name sla_state Auto-identify Yes Yes
BMC_WORST_SLA_STATE_PRIORITY_MAPPING SIM_TIME_FRAME
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:
sim2cmdb CLI command
Source (Strong member) BMC_System BMC_System
Weak relationship BMC_HostedSystemComponents BMC_ HostedService
Destination (Weak member) BMC_SystemComponent BMC_SystemService
Possible Import Results

Table 57 lists possible import results for specific circumstances. Table 57
Condition a relationship has only one endpoint in BMC Atrium CMDB
Possible import results

Result
I I I I
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 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 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 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
a CI belongs to an abstract class in the cell
I I I I
a weak CI points to a strong CI that does not exist in BMC Atrium CMDB
I I I
a value for HomeCellAliases is not found for a CI
I I I I

Before you run sim2cmdb
For Direct Feed dataIf 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.
Appendix C
215
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.
I I I
ContinueOnSkip ReverseCellAliases ReconJobTimeout
Table 58
Filename File path Description
sim2cmdb.conf file (part 1 of 3)

sim2cmdb.conf MCELL_HOME/etc contains the sim2cmdb CLI command configuration properties Description 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. Default value none
Parameter name
IASServers
IASUserName
specifies a valid Impact Administration Server user name to be presented as credentials to the specified Impact Administration Server
none
216
Table 58

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
IASPassword
ARSXLongTimeOut ARSXLongTimeOutEstimate
sets the time to stop waiting on a BMC Remedy AR System operation that occurs slowly 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 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.
1800 T (true)
ContinueOnSkip
F (false)
ReverseCellAliases
specifies which alias corresponds to which cell Format:

cellName, cellAlias{, cellName, cellAlias}
none
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.
Appendix C
217
Running the upgrade
Table 58

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)
ReconJobTimeout
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
Running the upgrade

sim2cmdb is executed as a CLI command.
sim2cmdb syntax
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]
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.
218
Running the upgrade
Table 59
Options

Description see BMC ProactiveNet Command Line Interface Reference Manual 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.
<common options> -c -h -? -i -q -l -p -v -z -e EnvID envID1[,envID2[...]]
-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.
Appendix C
219
Running the upgrade
Table 59
Options

Description 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.
-n cellName1[,cellName2[...]]
-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.
220
Running the upgrade
Table 59
Options commit

Description 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.
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
Appendix C
221
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
I
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 CMDBs 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 CMDBs 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.
222
Figure 45
Example output file without commit
sim2cmdb -e JZTest -n hou-jezhou-37 -o JTest_Data_Warning_no_commit.log -m Sun, 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-37 Components 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
Appendix C
223
Figure 46
Example verify.log file
sim2cmdb -e testPSR -i user/**** -o test_y_commit.log commit Wed, 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.0 User 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-psr Components: 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 noInstanceId, 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 noInstanceId, 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.
224
Upgrade commitment
Figure 47
Example output file with commit
sim2cmdb -e testPSR -i user/**** -o test_commit.log commit Wed, 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.0 User 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-psr Components: 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 noInstanceId, 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 noInstanceId, 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.
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:
I
If issues are found in data verification and the configuration parameter ContinueOnSkip is set to false (default).
Appendix C
225
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.
I
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:
I
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 Code 1 3
error exit codes for sim2cmdb CLI command (part 1 of 3)
Description indicates a syntax error on one or more command line arguments or options
Recommended remedial action Verify the correct syntax for the command string.
indicates that the home directory of the CLI Do the following: is not defined 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.
indicates the supplied configuration file could not be found
Verify that the value of the -c argument is an existing, readable file. Upgrading a service model to BMC Atrium CMDB 227
Appendix C
Table 60
Error Exit Code 5 6 7
Description indicates an I/O error occurred when reading the configuration file
Recommended remedial action Verify that the user has read access to the configuration file.
indicates the Impact Administration Server Check that the Impact Administration Server (IAS) is up (IAS) interface cannot be initialized and running. indicates a security problem (for example, write access) to the CLI home directory indicates that the home directory of the CLI does not exist indicates that the CLI cannot find a file that Verify that the file whose name appears as missing does it requires to run properly; for example a exist FileNotFound exception. indicates that the CLI cannot resolve a host Repair the computers network settings name indicates the failure to authenticate with the BMC Portal server Do the following:
I
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 14
15 16
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 30 31
indicates that the UTF-8 character set is not The host computer must support the UTF-8 character supported by the host set. indicates verification of publish environment failed indicates an error occurred when retrieving Verify the access rights for the cell directory. a cell directory from the BMC Atrium CMDB indicates an error occurred when communicating with a cell indicates verification of cell protocol version failed indicates classes between CMDB and cell(s) are not synchronized Verify that the cell is running. Verify network connectivity.
32
33 34
228
Table 60
Error Exit Code 35
Description indicates an error when communicating with BMC Atrium CMDB indicates an error when executing a CMDB operation
Recommended remedial action Verify that BMC Remedy AR System is running. Verify network connectivity.
36 37
indicates an error when importing data into Check standard out for more details regarding the error. CMDB
Appendix C
229
230
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
Index
A
Access Server component type 45 active relationship defined 74 Activity component type 44 Activity Decision component type 44 Activity End component type 44 Activity Interaction component type 44 Activity Manual component type 44 Activity Start component type 44 algorithm, quorum 91 alias entering in component instance 69 analyzing relevance of events 32 Application component type 45 Application Infrastructure component type 45 Application Service component type 49 Application System component type 45 applications, using with extended data models 113 AR System server using with extended data models 114 ARDBC plug-in 148 attributes generating fields for AR System 114 automated publishing 63, 64, 173 AutomatedPublish configuration parameter 165 AutomatedPublishRetryPeriod configuration parameter 164, 165 BMC_ConnectivityCollection component class 45 BMC_DataBase component class 44 BMC_DataBaseStorage component class 50 BMC_DiskDrive component class 49 BMC_DiskPartition component class 50 BMC_FileSystem component class 50 BMC_FloppyDrive component class 49 BMC_HardwareSystemComponent component class 49 BMC_Impact data class 190 enumerations 193 BMC_IPConnectivitySubnet component class 45 BMC_IPXConnectivityNetwork component class 45 BMC_LAN component class 45 BMC_LNsCollection component class 45 BMC_LNsCollection component type 45 BMC_LocalFileSystem component class 50 BMC_LogicalSystemComponent component class 50 BMC_Mainframe component class 47 BMC_Media component class 49 BMC_Monitor component class 47 BMC_OperatingSystem component class 50 BMC_Organization component class 45 BMC_PROPOGATION_MAP defined 197 slots 197 BMC_RemoteFileSystem component class 50 BMC_Software component class 50 BMC_SoftwareServer component class 46, 47, 48, 49 BMC_STATUS_COMPUTATION data class 194 BMC_STATUS_PROPOGATION data class 196 BMC_SystemResource component class 50 BMC_SystemSoftware component class 50 BMC_TapeDrive component class 49 BMC_UPS component class 49 BMC_UserCommunity component class 45 BMC_VirtualSystem component class 49 BMC_VirtualSystemEnabler component class 50 BMC_VMWare component class 50 BMC_WAN component class 45 Business Process component type 44 Business Service component type 44
B
BMC Atrium Configuration Management Database described 57 BMC ProactiveNet Performance Management using new classes 114 BMC Software, contacting 2 BMC.ASSET data set 82 BMC_Activity component class 44 BMC_Application component class 45 BMC_ApplicationInfrastructure component class 45 BMC_ApplicationService component class 49 BMC_ApplicationSystem component class 45 BMC_BaseElement BAROC definition 185 slot definitions 187, 192 BMC_BusinessProcess component class 44 BMC_BusinessService component class 44 BMC_CDROMDrive component class 49 BMC_Cluster component class 45 BMC_ComputerSystem component class 45, 46, 47, 48, 49
Index
231
C
CD ROM Drive component type 49 cell determining topology 35 field 68 list of cell names 68 reinitializing 144 cell alias about 135 Class Manager Console 114 classes IPS_CONFIG 127 IPS_ERROR 133 IPS_EVENT 126 Cluster component type 45 command options publish 219 Common Data Model (CDM) SIM-qualified classes of 58 Communication Server component type 46 component classes BMC_Activity 44 BMC_Application 45 BMC_ApplicationInfrastructure 45 BMC_ApplicationService 49 BMC_ApplicationSystem 45 BMC_BMCComputerSystem 45, 46, 47, 48, 49 BMC_BusinessProcess 44 BMC_BusinessService 44 BMC_CDROMDrive 49 BMC_Cluster 45 BMC_ComputerSystem 45, 46, 47, 48, 49 BMC_ConnectivityCollection 45 BMC_DataBase 44 BMC_DataBaseStorage 50 BMC_DiskDrive 49 BMC_DiskPartition 50 BMC_FileSystem 50 BMC_FloppyDrive 49 BMC_HardwareSystemComponent 49 BMC_IPConnectivitySubnet 45 BMC_IPXConnectivityNetwork 45 BMC_LAN 45 BMC_LNsCollection 45 BMC_LocalFileSystem 50 BMC_LogicalSystemComponent 50 BMC_Mainframe 47 BMC_Media 49 BMC_Monitor 47 BMC_OperatingSystem 50 BMC_Organization 45 BMC_RemoteFileSystem 50 BMC_Software 50 BMC_SoftwareServer 46, 47, 48, 49 BMC_SystemResource 50 BMC_SystemSoftware 50
BMC_TapeDrive 49 BMC_UPS 49 BMC_UserCommunity 45 BMC_VirtualSystem 49 BMC_VirtualSystemEnabler 50 BMC_VMWare 50 BMC_WAN 45 component instances deleting 72 determining dependencies 31 editing 71 finding existing 73 relationship state 53 component status computation model 43 computing 87 component types 42 Access Server 45 Activity 44 Activity Decision 44 Activity End 44 Activity Interaction 44 Activity Manual 44 Activity Start 44 Application 45 Application Infrastructure 45 Application Service 49 Application System 45 BMC_LNsCollection 45 Business Process 44 Business Service 44 CD ROM Drive 49 Cluster 45 Communication Server 46 Computer System 46 Configuration Management Agent 46 Connectivity Collection 45 Database 44 Database Server 46 Database Storage 50 Disk Drive 49 Disk Partition 50 DNS Server 46 File Server 46 File System 50 Firewall 46 Floppy Drive 49 FTP Server 46 Gateway 46 Hardware System Component 49 Hub 46 Input/Output Device 46 IP Connectivity Network 45 IP Connectivity Subnet 45 JBOD 46 LAN Network 45 Layer 3 Switch 46
Index
232
LDAP Server 47 Load Balancer 47 Local File System 50 Logical System Component 50 Mail Server 47 Mainframe 47 Media 49 Message Server 47 Mobile User Device 47 Monitor 47 Operating System 50 Organization 45 Print Server 47 RAID Storage Device 47 Remote File System 50 Resource Server 47 Router 47 SAN Bridge 47 SAN Director 48 SAN Hub 48 SAN Router 48 SAN Switch 48 Security Server 48 Server 48 Software 50 Software Server 48 Storage 48 Switch 48 System Resource 50 System Software 50 Tape Drive 49 Tape Library 48 Telnet Server 48 Transaction Server 48 UDDI Server 48 Uninterruptible Power Supply (UPS) 49 User Community 45 Virtual System 49 Virtual System Enabler 50 VMware 50 WAN Network 45 Web Cache 49 Web Server 49 Computer System component type 46 computing status, of a component 87 configuration items hiding 72 Configuration Management Agent component type 46 configuration parameters AutomatedPublish (publishing server) 165 AutomatedPublishRetryPeriod 164, 165 InitEffectivelyMgmtData 164, 165 Connectivity Collection component type 45 customer support 3
D
data classes BMC_BaseElement, BAROC definition 185 BMC_Impact 190 BMC_PROPOGATION_MAP 197 BMC_STATUS_COMPUTATION 90, 194 BMC_STATUS_PROPOGATION 196 extending 42 file location 184 mapping 199 relationship 183 service model relationships 190 service model, overview of 183 SEVERITY_TO_STATUS 199 status related 183 Database component type 44 Database Server component type 46 Database Storage component type 50 datasets BMC.ASSET 83 BMC.IMPACT.PROD 83 defined 57 for Atrium Publish environments 138 deleting component instance 72 Direct Feed for service model data 40, 119 discovery tools 66 Disk Drive component type 49 Disk Partition component type 50 DNS Server component type 46 dynamic prioritization final priority 109 impacts priority 108 overview 56 priority propagators 108 self priority 99
E
editing component instances 71 event classes 203 history 205 impact 200, 201, 202, 206 events generating publishing 123 missing, described 33 exits 227 extending Common Data Model BMC applications and 113 BMC Impact Solutions and 114
Index
233
F
file location of data classes 184 File Server component type 46 File System component type 50 finding component instances 73 relationships 73 Firewall component type 46 Floppy Drive component type 49 FTP Server component type 46 functions in status computation 88
LDAP Server component type 47 Load Balancer component type 47 Local File System component type 50 Logical System Component component type 50
M
Mail Server component type 47 Mainframe component type 47 mc_root_internal.baroc 191 mc_root_redef.baroc 203 MC_SM_COMPONENT data class, BAROC definition 185 mc_sm_event_ mapping.baroc 184 mc_sm_object.baroc 184 mc_sm_root.baroc 184 MC_SMC_EVENT data class BAROC definition 200, 201, 202, 206 Media component type 49 Message Server component type 47 missing events 33 Mobile User Device component type 47 Monitor component type 47
G
Gateway component type 46 generating publishing events 123
H
Hardware System Component component type 49 hiding configuration items 72 history event class 205 home cell about 135 home cell alias about 135 Hub component type 46
O
Operating System component type 50 Organization component type 45 output file for sim2cmdb CLI command 222
I
identifying critical events 32 impact event class 200, 201, 202, 206 important component 108 inactive relationship, defined 74 InitEffectivelyMgmtData configuration parameter 164, 165 Input/Output Device component type 46 IP Connectivity Subnet component type 45 IPS_CONFIG class 127 IPS_ERROR class 133 IPS_EVENT class 126 IPX Connectivity Network component type 45
P
Print Server component type 47 priority propagators 108 product support 3 promotion all instances 84 deleting instances 73 guidelines 83 overview 63 requirements before 83 step-by-step instructions 84 submitting 83 verifying status 84 promotion of service model 82 provider relationship, described 51 publish command command options 219 publishing automated 63, 64, 173 publishing large service models 170 Publishing Server generating events for 123
J
JBOD (Just a Bunch Of Disks) component type 46
L
LAN Network component type 45 Layer 3 Switch component type 46
Index
234
R
RAID Storage Device component type 47 reinitializing a cell 144 relationships active 74 finding 73 inactive 74 state 53 state values 53 status propagation models 54 Remote File System component type 50 Resource Server component type 47 Router component type 47
data class, BAROC definition 194, 195 slots 194, 195 Storage component type 48 support, customer 3 Switch component type 48 System Resource component type 50 System Software component type 50
T
Tape Drive component type 49 Tape Library component type 48 technical support 3 Telnet Server component type 48 Transaction Server component type 48
S
SAN Bridge component type 47 SAN Director component type 48 SAN Hub component type 48 SAN Router component type 48 SAN Switch component type 48 Security Server component type 48 Server component type 48 service components types 44 service model class hierarchy 183 composition 37 data classes, overview of 183 Direct Feed 40, 119 internals of 183 promotion 82 publishing large 170 service model components computing status of 87 status computation 43 service model relationships data classes 190 defined 52 SEVERITY_TO_STATUS data class 199 sim2cmdb.conf file 216 SMC_STATE_CHANGE data class BAROC definition 205 Software component type 50 Software Server component type 48 state_change.baroc file 206 Status and Alias tab 69 status computation functions 91 model 43 model anatomy 91 of components 43 status propagation models for relationships 54 in BMC Impact Model Designer 95 STATUS_COMPUTATION
U
UDDI Server component type 48 Uninterruptible Power Supply (UPS) component type 49 User Community component type 45
V
verifying promotion status 84 Virtual System component type 49 Virtual System Enabler component type 50 VMware component type 50
W
WAN Network component type 45 Web Cache component type 49 Web Server component type 49 weighted cluster status model 43 wildcards using with Find command 73
Index
235
Index
236
Notes
*209419* *209419* *209419* *209419*

*209419*

ProactiveNet Service Modeling and Publishing Guide

Enviado por

Dados do documento

Descrição original:

Direitos autorais

Formatos disponíveis

Compartilhar este documento

Compartilhar ou incorporar documento

Opções de compartilhamento

Você considera este documento útil?

Este conteúdo é inapropriado?

Direitos autorais:

Formatos disponíveis

ProactiveNet Service Modeling and Publishing Guide

Enviado por

Direitos autorais:

Formatos disponíveis

BMC ProactiveNet Service Modeling and Publishing Guide

Contacting BMC Software

United States and Canada

Outside United States and Canada

Restricted rights legend

Support by telephone or e-mail

Before contacting BMC

BMC ProactiveNet Service Modeling and Publishing Guide

BMC ProactiveNet Service Modeling and Publishing Guide

Understanding a service model created in BMC Impact Model Designer 57 57 58 62 63 63 64 64 65 65 65 66 66 71 71 72 72 73 74 74 75 75 75 76 78 81 82 82 82

BMC ProactiveNet Service Modeling and Publishing Guide

Dataset cleanup . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 227 sim2cmdb return codes . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 227 Index 231

BMC ProactiveNet Service Modeling and Publishing Guide

BMC ProactiveNet Service Modeling and Publishing Guide

BMC ProactiveNet Service Modeling and Publishing Guide

About this guide

About BMC Impact Model Designer

About BMC Impact Model Designer

After upgrading to BMC ProactiveNet version 8.5 or later

Before you begin using BMC Impact Model Designer

BMC ARSystem Datastore BMC Remedy Action Request System

BMC ProactiveNet Service Modeling and Publishing Guide

Other documents you may need

Other documents you may need

Other documents you may need

Useful BMC documentation

Guide name BMC Atrium CMDB User's Guide

BMC Atrium CMDB Administrators Guide

BMC ProactiveNet Service Modeling and Publishing Guide

BMC Impact Model Designer user interface

Installing BMC Impact Model Designer

Prerequisites to using BMC Impact Model Designer

Chapter 2 BMC Impact Model Designer user interface

Launching BMC Impact Model Designer

Launching BMC Impact Model Designer

AR server mid-tier hostname represents the system on which BMC Remedy AR

System mid-tier is installed

BMC Atrium Explorer and BMC Impact Model Designer

Who should use BMC Atrium Explorer?

BMC ProactiveNet Service Modeling and Publishing Guide

BMC Impact Model Designer features

BMC Impact Model Designer features

BMC Impact Model Designer menu bar

Schedules and timeframes

Promote Sandbox Changes

Chapter 2 BMC Impact Model Designer user interface

BMC Impact Model Designer menu bar

BMC ProactiveNet Service Modeling and Publishing Guide

Designing a service model

Service model design process

Designing a service model

Service model design process

Example of a service model

BMC ProactiveNet Service Modeling and Publishing Guide

Defining business goals for the service model

The service modeling process involves:

Defining business goals for the service model

Designing a service model

Decomposing a business service

Decomposing a business service

1 Identify business services.

business processesIdentify key business processes such as Market Research,

BMC ProactiveNet Service Modeling and Publishing Guide