Service Model

BMC Impact Solutions: Service Model Administrators Guide
Supporting
BMC Impact Service Model Editor 7.2 BMC Impact Publishing Server 7.2
June 2008
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 20072008 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. ITIL is a registered trademark, and a registered community trademark of the Office of Government Commerce, and is registered in the U.S. Patent and Trademark Office, and is used here by BMC Software, Inc., under license from and with the permission of OGC. Linux is the registered trademark of Linus Torvalds. Oracle is a registered trademark of Oracle Corporation. UNIX is the registered trademark of The Open Group in the US and other countries. 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_home. From this website, you can
s s s s s s s s
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:
s
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
s s s
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 Service model overview 19 20 21 23 23 24 24 24 27 28 29 30 32 33 33 34 34 35 36 37 39 39 40 41 43 44 44 44 45 46 47 52 53 54 55 56
5
Service model overview . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . Sources of objects in a service model . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . Rules for service model data modification and deletion . . . . . . . . . . . . . . . . . . . . . Using the BMC Atrium CMDB as a source of service model data. . . . . . . . . . . . . Using BMC Performance Manager . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . Using Direct Feed . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . Precedences . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . Chapter 2 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 component instance . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 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 3 Understanding a service model
Service components . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . Component classes and types . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . Service component instances . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 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 . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
Contents
Dynamic status mapping . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . Event associations . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . Bringing events from the resource into the cell . . . . . . . . . . . . . . . . . . . . . . . . . . . . Component aliases . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . Event alias associations. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . Service schedules . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . Timeframes . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . Service schedules example with exceptions . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . Chapter 4
56 58 58 58 59 62 62 63
Understanding a service model created in BMC Impact Service Model Editor 65 66 66 70 71 71 71 73 73 73 74 75
Role of the BMC Atrium CMDB in service modeling. . . . . . . . . . . . . . . . . . . . . . . . . . . Service model and the Common Data Model . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . Sandboxes . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . Datasets . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . Testing . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . Promotion . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . Service model publishing . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . Service model execution on cells . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . In-model and not-in-model component instances . . . . . . . . . . . . . . . . . . . . . . . . . . . . . Importing Business Time Segments from BMC Remedy AR System . . . . . . . . . . . . . Chapter 5 Building a service model in BMC Impact Service Model Editor
Service model creation process . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 77 Launching BMC Impact Service Model Editor . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 77 Working with service component instances . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 78 Creating service component instances in BMC Impact Service Model Editor . . . 78 Switching sandbox View modes . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 83 Viewing properties for a component instance . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 84 Editing component instances. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 85 Performing actions on multiple objects . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 85 Copying component instances. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 87 Hiding a component instance . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 88 Deleting a component instance . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 89 Finding component instances . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 89 Defining relationships between component instances . . . . . . . . . . . . . . . . . . . . . . . . . . 96 Creating a component relationship in BMC Impact Service Model Editor . . . . . 97 Assigning related component instances to cells . . . . . . . . . . . . . . . . . . . . . . . . . . . 101 Updating relationships . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 102 Deleting relationships . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 103 Associating events with a component instance . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 104 Working with timeframes and service schedules . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 109 Icons used in the service schedule and timeframes editors . . . . . . . . . . . . . . . . . 110 Working with timeframes . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 110 Working with service schedules . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 113 Assigning components to service schedules . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 117 Granting access to service model objects . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 118 Granting permissions to individual service model objects . . . . . . . . . . . . . . . . . . . . . 118
Contents 6
Testing the service model . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . Testing component relationships . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . Testing event associations . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . Promoting the service model . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . About the publishing process . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . Before you promote. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . Submitting a promotion . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . Verifying promotion status . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . Working with publication logs . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . Organizing service component instances for monitoring . . . . . . . . . . . . . . . . . . . . . . Working with BMC Impact Service Model Editor Views . . . . . . . . . . . . . . . . . . . . . . Saving, opening, renaming, and deleting Views . . . . . . . . . . . . . . . . . . . . . . . . . . Understanding visual cues in a View . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . Repositioning objects in a View. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . Controlling what you see in a View . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . Exploring consumer and provider paths . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . Refreshing the View . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . Repositioning the dockable windows . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . Showing topology views . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . Exporting and importing service model data . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . Exporting class definitions from the BMC Atrium CMDB to a cells . . . . . . . . . . . . . Chapter 6 Upgrading a service model to BMC Atrium CMDB
120 120 120 121 121 122 122 125 126 128 132 133 134 135 136 138 139 140 140 141 142 143 144 144 145 145 145 147 148 148 151 153 156 160 163 164 165 165 169 169 170 170 171 172 173 174
7
Upgrading from non-Atrium-CMDB SIM to BMC Atrium CMDB SIM . . . . . . . . . . Upgrading SIM data that originates from BMC Performance Manager . . . . . . . Upgrading SIM data that originates from third-party source . . . . . . . . . . . . . . . sim2cmdb restrictions . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 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 . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . Dataset cleanup . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . sim2cmdb return codes. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . Chapter 7 Component and relationship status propagation
About component and relationship status . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . How component status computation works . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . Status computation functions . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . Status computation algorithms . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . How status computation algorithms work . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . About status computation models . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . Anatomy of a status computation model. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
Contents
The internal status NONE . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 174 Quorum algorithm examples . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 174 Relationship status propagation concepts . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 177 How status propagation works . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 177 Status propagation models . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 178 Default status propagation models . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 178 What is a valid status propagation model? . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 180 Important service components . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 180 Dynamic prioritization. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 181 Self priority . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 182 Impacts priority . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 191 Determination of final priority. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 192 How cost impact is calculated . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 194 How SLA impact is calculated . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 194 Chapter 8 Managing BMC Impact Service Model Editor 195
Setting BMC Impact Service Model Editor options. . . . . . . . . . . . . . . . . . . . . . . . . . . . 196 Configuring the topology view in BMC Impact Service Model Editor . . . . . . . . . . . 200 Using a firewall with BMC Impact Service Model Editor . . . . . . . . . . . . . . . . . . . . . . 201 Adding new classes to the BMC Atrium CMDB . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 202 Making your changes visible to applications. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 202 Creating a new service model component class in the BMC Atrium CMDB . . . 203 Associating a custom icon with a service model component . . . . . . . . . . . . . . . . 204 Documenting your extensions . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 207 smeserver properties file and parameters. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 208 Chapter 9 Managing BMC Impact Publishing Server 211
Starting and stopping the BMC Impact Publishing Server . . . . . . . . . . . . . . . . . . . . . 212 Starting and stopping BMC Impact Publishing Server on Windows. . . . . . . . . . 212 Starting and stopping BMC Impact Publishing Server on UNIX . . . . . . . . . . . . . 214 Working with publication logs . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 215 Viewing publication history . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 215 Viewing publication history details . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 216 Specifying a port for Service Model Manager . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 217 High availability and BMC Impact Publishing Server . . . . . . . . . . . . . . . . . . . . . . . . . 217 Monitoring BMC Impact Publishing Server with BMC Impact Manager events . . . 218 Modifying the generation of events . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 218 Understanding classes and slots for BMC Impact Publishing Server events . . . 220 About SIM management data . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 228 Understanding publish environments . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 229 About publish environments . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 230 About home cell, home cell alias, and cell alias. . . . . . . . . . . . . . . . . . . . . . . . . . . . 231 Publishing from the BMC Atrium CMDB. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 232 Enabling AtriumCMDB Publish publishing . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 232 Using BMC Impact Service Model Editor . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 233 Creating advanced publish environments . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 236 Examples of advanced environments . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 237 Defining BMC Atrium CMDB classes for SIM . . . . . . . . . . . . . . . . . . . . . . . . . . . . 239
8 BMC Impact Solutions: Service Model Administrators Guide
Defining BMC Atrium CMDB attributes for SIM . . . . . . . . . . . . . . . . . . . . . . . . . . ServiceModelSet attribute for components and management data . . . . . . . . . . . ServiceModelSet attribute for impact relationships . . . . . . . . . . . . . . . . . . . . . . . . Initializing the BMC Atrium CMDB with SIM data. . . . . . . . . . . . . . . . . . . . . . . . Initializing a cell. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . Examplecreating SIM data in BMC Atrium CMDB from BAROC files . . . . . Purging and deleting service model objects . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . Publishing in automated or manual mode . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . Publishing from a Direct Publish source . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . About home cell and cell alias . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . About class and slot data . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . Enabling Direct Publish publishing . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . Creating an environment for SIM management data . . . . . . . . . . . . . . . . . . . . . . Publishing SIM management data from exclusive environment . . . . . . . . . . . . . Creating an environment for component instances and relationships . . . . . . . . Modifying home cell and cell aliases . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . Initializing a cell from a Direct Publish environment . . . . . . . . . . . . . . . . . . . . . . Examplesusing cell aliases for Direct Publish publishing . . . . . . . . . . . . . . . . . Securing publish environments . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . pserver.conf file and parameters . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . Configuring the Notify ARDBC plug-in. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . Chapter 10 BMC Impact Publishing Server CLIs
239 240 241 241 246 248 249 250 252 253 255 255 256 256 257 257 258 258 260 262 266 269
Installing the CLIs on another computer . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 270 Configuring BMC Impact Publishing Server CLIs . . . . . . . . . . . . . . . . . . . . . . . . . . . . 272 Configuration file and parameters for CLIs . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 273 Changing the time-out values for all the CLI commands . . . . . . . . . . . . . . . . . . . 279 Setting the configuration for a specific CLI command . . . . . . . . . . . . . . . . . . . . . 280 Setting up automatic authentication of CLI commands . . . . . . . . . . . . . . . . . . . . 280 Specifying the BMC Impact Administration Server used for CLI authentication . . 281 Configuring trace for CLIs . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 281 Understanding common command options for CLIs. . . . . . . . . . . . . . . . . . . . . . . . . . 281 Understanding return codes for CLIs . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 283 Return codes for pserver . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 286 Using CLI commands . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 287 Summary of CLI commands for BMC Impact Publishing Server . . . . . . . . . . . . 287 pclassinfoComparing service model classes on cells with class definitions in the BMC Atrium CMDB . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 289 penvManaging publish environments . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 292 pinitInitializing a cell with service model data . . . . . . . . . . . . . . . . . . . . . . . . . . 301 plogObtaining the XML log for a request . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 304 plogdisplayConverting the XML log for a request to text format . . . . . . . . . . 306 pposterSending service model objects to a cell . . . . . . . . . . . . . . . . . . . . . . . . . . 307 pscontrolSending a command to BMC Impact Publishing Server. . . . . . . . . . 318 pserverStarting the BMC Impact Publishing Server service or daemon. . . . . 320 psstatDisplaying status of BMC Impact Publishing Server . . . . . . . . . . . . . . . 321 publishPublishing a service model or viewing instances to be published . . . 322 . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 324
Contents 9
Appendix A
Troubleshooting
325
BMC Impact Service Model Editor . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 325 Using the BMC Impact Service Model Editor log . . . . . . . . . . . . . . . . . . . . . . . . . . 325 Other BMC Impact Service Model Editor Troubleshooting Options . . . . . . . . . . 329 BMC Impact Publishing Server . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 330 Verifying that BMC Impact Publishing Server is running. . . . . . . . . . . . . . . . . . . 330 Using trace files . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 330 Stopping BMC Impact Publishing Server when JMS is not running . . . . . . . . . . 330 Publishing large service models . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 331 Publishing failures and reattempts . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 332 BMC Impact Publishing Server service or daemon fails to start. . . . . . . . . . . . . . 333 No publication after successful promotion . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 333 Reconciliation jobs hang . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 334 BMC Impact Publishing Server does not reply to requests . . . . . . . . . . . . . . . . . . 334 Diagnosing publication failures. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 335 Another publish request is ongoing . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 339 Appendix B Default service model data classes 341
Service model data structures. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 342 Service model data class overview . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 342 Service model data class files . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 342 Service model component data classes . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 343 BMC_BaseElement data class. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 343 BMC_Impact data class . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 349 BMC_DOWNTIME_STATUS_CONFIG data class. . . . . . . . . . . . . . . . . . . . . . . . . 352 BMC_STATUS_COMPUTATION data class . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 353 BMC_STATUS_PROPAGATION data class . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 355 BMC_PROPAGATION_MAP data class . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 357 SIM data class descriptions . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 358 BMC_SEVERITY_TO_STATUS data class . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 358 BMC_SIM_MATCH_TABLE data class . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 359 BMC_SIM_ALIAS data class . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 359 BMC_SLOT_FORMULAS data class. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 360 BMC_TIME_SCHEDULE data class . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 360 BMC_TIME_FRAME_TO_SCHEDULE data class . . . . . . . . . . . . . . . . . . . . . . . . . 361 BMC_SELF_PRIORITY_MAPPING data class . . . . . . . . . . . . . . . . . . . . . . . . . . . . 361 BMC_SERVICE_SCHEDULE_CONFIG data class . . . . . . . . . . . . . . . . . . . . . . . . . 362 BMC_STATUS_TO_SEVERITY data class . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 362 SIM_TIME_FRAME class . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 363 SIM_CellAlias class . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 363 SIM_CellInformation class . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 363 BMC_PROMOTION_LOG class . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 363 Service model event classes. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 364 CORE_EVENT base class . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 364 Root event class . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 366 History event class . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 366 Impact event class . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 367
10
Glossary Index
369 403
Contents
11
12
Figures
Service model objects . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 20 Example of a service model . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 28 Inserting KPI data into the business_slot with an action . . . . . . . . . . . . . . . . . . . . . . . 39 Updating KPI data with a rule . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 39 Impact (status) propagation in relationships . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 54 Parts of a simple alias formula . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 60 Find Component dialog box . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 90 Advanced Find dialog box . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 92 Using Conditional Find . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 94 Create Relationship dialog box . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 99 Drawing relationships . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 101 Creating an alias association . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 105 Defining the events to be processed by the alias formula . . . . . . . . . . . . . . . . . . . . . . 106 Example of match attributes . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 107 Timeframe Edit dialog box . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 111 Schedule Edit dialog box . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 114 Schedules Editor section of Edit Component Properties dialog box . . . . . . . . . . . . . 117 Changing access for an individual component instance . . . . . . . . . . . . . . . . . . . . . . . 119 Example output file without commit . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 161 Example verify.log file . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 162 Example output file with commit . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 163 Propagation paths between root cause and important components . . . . . . . . . . . . . 181 Self priority determination . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 182 Cost priority method of priority determination . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 186 Worst SLA method of priority determination . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 190 Impacts priority determination . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 191 Final priority determination . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 193 Default value for com.bmc.sms.sme.topoviews parameter . . . . . . . . . . . . . . . . . . . . 200 Graph definition format . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 201 Example of a graph definition . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 201 BMC_BaseElement default icon image . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 207 pscontrol stop example . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 319 pscontrol automated example . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 319 pscontrol automated -u example . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 319 pscontrol manual example . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 320 BMC Impact Service Model Editor log . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 325 BMC_BaseElement definitions . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 344 MC_SM_COMPONENT definition . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 345 MC_SM_DATA definition . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 345 CORE_DATA definition . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 346
Figures 13
BMC_Impact definition . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 350 MC_SM_RELATIONSHIP definition . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 350 MC_SM_DATA definition . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 350 CORE_DATA definition . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 351 BMC_DOWNTIME_STATUS_CONFIG definition . . . . . . . . . . . . . . . . . . . . . . . . . . . 353 BMC_SIM_DATA definition . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 353 BMC_STATUS_COMPUTATION definition . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 354 BMC_SIM_DATA definition . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 354 BMC_STATUS_PROPAGATION definition . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 356 BMC_SIM_DATA definition . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 356 BMC_PROPAGATION_MAP definition . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 357 BMC_SIM_DATA definition . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 357 SEVERITY_TO_STATUS definition . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 359 BMC_SIM_MATCH_TABLE definition . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 359 BMC_SIM_ALIAS definition . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 360 BMC_SLOT_FORMULAS definition . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 360 BMC_TIME_SCHEDULE definition . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 361 BMC_TIME_FRAME_TO_SCHEDULE definition . . . . . . . . . . . . . . . . . . . . . . . . . . . . 361 BMC_SELF_PRIORITY_MAPPING definition . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 362 BMC_SERVICE_SCHEDULE_CONFIG definition . . . . . . . . . . . . . . . . . . . . . . . . . . . 362 BMC_STATUS_TO_SEVERITY definition . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 362 SIM_TIME_FRAME definition . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 363 Partial CORE_EVENT definition . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 365 MC_SMC_ROOT definition . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 366 SMC_STATE_CHANGE definition . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 366 MC_SMC_EVENT definition . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 367
14
Tables
How service model objects get to a SIM cell . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 21 Advantages and disadvantages of different object sources . . . . . . . . . . . . . . . . . . . . . 22 Example business service model spreadsheet . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 31 BMC Impact Service Model Editor values for IT service Sales Logix . . . . . . . . . . . . . 32 Severity level index . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 34 Occurrence level index . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 34 Service component status definitions . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 45 Service model component types . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 47 Main relationship classes . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 52 How an event alias association works . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 60 Global and Local timeframe differences . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 63 SIM-qualified subclasses of BMC_Collection . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 67 SIM-qualified subclasses of BMC_LogicalEntity . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 67 SIM-qualified subclasses of BMC_System . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 68 SIM-qualified subclasses of BMC_SystemComponent . . . . . . . . . . . . . . . . . . . . . . . . . 68 SIM-qualified subclass of BMC_SystemService . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 68 SIM-qualified attributes . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 69 View mode switch icons . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 83 Default component properties . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 84 Description of additional search criteria . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 93 Definition of relational operators . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 95 Description of conditional operators . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 106 Service schedule and timeframes editors icons . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 110 Timeframe Edit field descriptions . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 111 Schedule Edit field descriptions . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 114 Default user groups and rights for BMC Impact Service Model Editor . . . . . . . . . . 118 Icons in Objects-to-be-Published pane . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 123 Topics covered in this section . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 132 Visual cues in a View . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 135 Adjusting the graphical view . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 136 Understanding expansion handles . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 139 Identifying components in the BMC Atrium CMDB . . . . . . . . . . . . . . . . . . . . . . . . . . 149 Key slots in reconciliation rules for management data . . . . . . . . . . . . . . . . . . . . . . . . 151 Possible import results . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 153 sim2cmdb.conf file . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 154 sim2cmdb command options . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 157 error exit codes for sim2cmdb CLI command . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 165 Status computation functions and computed component statuses . . . . . . . . . . . . . . 171 What a function returns when using an available algorithm . . . . . . . . . . . . . . . . . . . 172 Description of predefined status computation models . . . . . . . . . . . . . . . . . . . . . . . . 173
Tables 15
How status propagation models work in relationships . . . . . . . . . . . . . . . . . . . . . . . 179 smeserver.properties file . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 208 BMC Impact Publishing Server event generation . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 219 Common Event Model (CEM) slots . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 221 IPS_START slots . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 222 IPS_STOP slots . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 223 IPS_CONFIG slots . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 223 IPS_CONNECT slots . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 224 IPS_IM_CONNECT slots . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 225 IPS_REQUEST slots . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 225 IPS_PUBLISH slots . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 227 IPS_CLASSINFO slots . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 227 IPS_ERROR slots . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 228 IPS_ENV slots . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 228 Basic steps to create advanced test environments . . . . . . . . . . . . . . . . . . . . . . . . . . . . 236 ServiceModelSet attribute values . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 240 Determination of ServiceModelSet value for an impact relationship . . . . . . . . . . . . 241 Parameters in the pclient.conf file for initializing the BMC Atrium CMDB . . . . . . . 242 InitEffectivelyMgmtData parameter values and results . . . . . . . . . . . . . . . . . . . . . . . 243 InitEffectivelyServiceModel parameter settings and results . . . . . . . . . . . . . . . . . . . . 245 Basic process of publishing from a Direct Publish source . . . . . . . . . . . . . . . . . . . . . . 252 Valid parameters for a Direct Publish environment . . . . . . . . . . . . . . . . . . . . . . . . . . 253 pserver.conf file . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 263 ar.cfg file parameter descriptions . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 267 pclient.conf parameters . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 273 BMC Impact Publishing Server CLI common command options . . . . . . . . . . . . . . . 282 BMC Impact Publishing Server and sim2cmdb CLI error exit codes . . . . . . . . . . . . 283 pserver error exit codes . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 286 BMC Impact Publishing Server CLI command descriptions . . . . . . . . . . . . . . . . . . . 288 pclassinfo options . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 289 penv options . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 293 Actions commands . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 294 Valid parameters for a BMC Atrium CMDB publish environment . . . . . . . . . . . . . . 296 Valid parameters for a Direct Publish environment . . . . . . . . . . . . . . . . . . . . . . . . . . 298 pinit options . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 302 plog options . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 305 plogdisplay options . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 306 plogdisplay return codes . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 307 pposter options . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 308 pposter return codes . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 317 pscontrol command options . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 318 pserver command options . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 320 psstat command options . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 321 publish command options . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 322 BMC Impact Publishing Server request failure messages . . . . . . . . . . . . . . . . . . . . . . 335 Service management data class files . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 343 Slots that define component instances . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 346 BMC_Impact slot definitions in alphabetical order . . . . . . . . . . . . . . . . . . . . . . . . . . . 351 BMC_DOWNTIME_STATUS_CONFIG slot . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 353
16
BMC_STATUS_COMPUTATION slots in alphabetical order . . . . . . . . . . . . . . . . . . 355 Status propagation slots in alphabetical order . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 356 BMC_PROPAGATION_MAP slot definitions . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 358
Tables
17
18
Chapter
1
20 21 23 23 24 24 24
Service model overview

This book provides detailed information about designing, developing, and maintaining service models that enable you to manage your IT resources from the perspective of the business services that they provide. This chapter contains the following topics: Service model overview . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . Sources of objects in a service model . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . Rules for service model data modification and deletion . . . . . . . . . . . . . . . . . . . . . Using the BMC Atrium CMDB as a source of service model data. . . . . . . . . . . . . Using BMC Performance Manager . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . Using Direct Feed . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . Precedences . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
Chapter 1 Service model overview
19

A service model is an extensible system that defines the various resources that deliver business services, models their behaviors and functional relationships, and manages the delivery of the resulting services. A physical or logical resource represented in the model is known as a service component instance or component instance. The functional relationship between two resources (component instances) is called a service component relationship or a relationship. These concepts are illustrated in Figure 1 on page 20. Figure 1 Service model objects
Building, promoting, and publishing a service model involves processes that span from the discovery or manual creation of component instances in your IT environment to verifying the service model before promoting and publishing it to specific BMC Impact Manager cells.
20
Sources of objects in a service model

A service model can contain objects (components and relationships) from different sources. In addition, the service model objects in a single cell can originate from multiple sources. So, you can mix different sources of data in a SIM cell. For example, you may have the bulk of your service model objects come from the BMC Atrium CMDB, and then add special objects manually using a BAROC file. It is also possible to track very dynamically occurring objects, with MRL rules, for example. Data that you send from any given environment must be updated and deleted in the context of that environment. Sources for service model objects in a SIM cell are
s s s s s
BMC Atrium CMDB BMC Impact Explorer CLI commands pposter and mposter Master Rule Language (MRL) third-party repository
The source of the service model data determines the method of delivery into the cell, as described in Table 1. Table 1 How service model objects get to a SIM cell
How objects are delivered to a cell Delivery method name Atrium Publish Feed objects are discovered using discovery tools or you create them in the BMC Impact Service Model Editor component; they are reconciled by the BMC Atrium CMDB Reconciliation Engine, and then automatically published to the cell using BMC Impact Publishing Server you create a BAROC source file of object data and Direct Publish Feed send it to the cell using the CLI command pposter, which publishes the data to the cell using BMC Impact Publishing Server you create a BAROC source file of object data and source Direct Feed send it to the cell using the CLI command mposter BMC Impact Explorer you create components, relationships, or both in BMC Impact Explorer using the Edit => Create Component menu command; when the objects are saved, they are sent directly to the cell you create a rule that adds objects to the cell on receipt of a trigger event you configure BMC Performance Manager to handle Direct Service Model integration source Direct Feed
Source for service model objects BMC Atrium CMDB
BAROC source file
MRL rule BMC Performance Manager
tool direct feed source direct feed
21
Table 2 describes some of the advantages and disadvantages of the different sources for service model data. Table 2 Advantages and disadvantages of different object sources
Advantages
s s s
Object source BMC Atrium CMDB
Disadvantages
s s
s s
handles large, complex service models accepts objects from discovery tools sophisticated features, such as BMC Impact Service Model Editor 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 BMC Impact Publishing Server, so data is protected from uncontrolled edits user interface to create and edit components and relationships you can add data to complement other sources handles highly dynamic changes
complex to implement time factor to discover or create, reconcile, and publish objects
BAROC file with pposter CLI command
s s
s s s
useful only for small, simple models BAROC file must be created to exact standards requires knowledge of CLIs may not build complete model not as protected from uncontrolled edits no primary copy in external datastore only practical for special circumstances may not build complete model no primary copy in external datastore
BMC Impact Explorer
s s s
MRL rule
s s s
Direct Publish Feed
validation of the service model is off-loaded from the cell, preventing cell processing performance degradation
22
Rules for service model data modification and deletion
Rules for service model data modification and deletion

For published service model data, changes and deletions are restricted to the original source of the data. Objects delivered to the SIM cell from BMC Atrium CMDB must be edited and deleted in BMC Impact Service Model Editor (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 Impact Explorer, you cannot change or delete them in BMC Impact Explorer, nor 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 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.
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 use these products from BMC Impact Solutions to create and manage service models:
s s
BMC Impact Service Model Editor BMC Impact Publishing Server
In the BMC Impact Service Model Editor, you build and maintain a service model with component objects, and manage your service model environment In the BMC Impact Publishing Server, you 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 Chapter 4, Understanding a service model created in BMC Impact Service Model Editor and Chapter 5, Building a service model in BMC Impact Service Model Editor.
23
Using BMC Performance Manager
Using BMC Performance Manager

With both BMC Impact Portal and BMC Performance Manager installed, you can send service model components from BMC Performance Manager directly to the cell. Service model objects that originate from BMC Performance Manager may be missing relationships, making the service model incomplete. In BMC Impact Explorer, you can create an impact relationship between the two components. For information about this, see BMC Performance Manager Portal Monitoring and Management 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 BMC Impact Explorer, the CLI command mposter, 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). For more information about creating and editing service model components in BMC Impact Explorer, see BMC Impact Solutions: Service Monitoring User Guide. 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 will fail if the referred management data is not published.
Precedences
Data published from BMC Atrium CMDB automatically overwrites Direct Publish data and 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.
24
Precedences
Data overrides other data with a lower precedence if

s s
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 BMC Impact Explorer, 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 SIM 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.
25
Precedences
26
Chapter
2
28 29 30 32 33 33 34 34 35 36 37 39 40 41
Designing a service model

This chapter covers the following topics: 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 component instance . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 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 . . . . . . . . . . . . . . . . . . Service model design considerations . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . Determining cell topology for the service model . . . . . . . . . . . . . . . . . . . . . . . . . . . Component property updates . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
Chapter 2
27
Service model design process
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 Service Model Editor with business users, services, and IT structure layers. The lines between the component instances represent the provider/consumer relationships. Figure 2 Example of a service model
business consumers
service layer
IT infrastructure
28
Defining business goals for the service model
The following factors determine how a service impact management solution should be designed and implemented:
s s
s s s
the diversity of IT resources and how they are monitored the location of resources and how the management responsibilities for them are distributed within and among IT or information services (IS) groups the relative importance of various resources in the delivery of business services the need for change management the maintainability of the service model over time
The service modeling process involves:

s s s s s s s
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:
s
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.
Chapter 2
29
Decomposing a business service
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.

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:
s
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.
30
Map the functional applications to IT service components to create the 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. 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:
s
s s
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
Chapter 2
31
Defining the service catalog
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. For the Sales Logix IT service example shown in Table 3 on page 31, the detailed IT component information (except for Alias and Alias formula) that are required by BMC Impact Service Model Editor is shown in Table 4. Table 4
Compon ent name
BMC Impact Service Model Editor 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
32
Defining the service model
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:
s s
each resources name or component identification pattern its location or site
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
s s s
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 component instance

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 component instance. Component instances are created as a single instance of a class type that is defined in the BMC Atrium CMDB. Classes may identify such physical components as servers or databases, and such logical components as user groups. Component instances are created through BMC Impact Service Model Editor. 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.
Chapter 2
33
Defining a new component class for a component type
Defining a new component class for a component type

Component instances represent an individual occurrence of a component type, or class. Component classes are displayed in BMC Impact Service Model Editor 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 SIM classes in the BMC Atrium CMDB, you must distribute the changes to all of the SIM BMC Impact Manager instances (cells) and recompile them.
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:
s
s s s
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 34
Occurrence level index

Definition high change of occurrence and needs immediate attention frequent change to happen and needs attention
Occurrence level
Determining a components relationship and dependencies
Table 6
moderate occasional slight remote
Occurrence level index

Definition moderate change to consider prevention occasionally might happen slight chance to happen unlikely to happen
Occurrence level
Sample of FMEA
s s s s s
s s s s s
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.
s
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.
Chapter 2
35
Determining the organization of the modeled relationships
Identify the relationships and dependencies among the IT components and the logical components to one another. The direction of the relationship is important. If a system component is to be linked to a hardware component, the hardware component must be the provider and the system component the consumer. Examine how the various resources combine to deliver a service on a particular host. Define the resources that are providers and the resources that consume their services in the service delivery stream.
Determining the organization of the modeled relationships

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:
s
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.
36
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. To create the event associations for a component, you must
s s
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:
s
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.
Chapter 2
37
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. 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.
s
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.
38
Displaying business key performance indicators (KPIs)
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 Impact Explorer.) Figure 3 shows an example of the action. 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.
Chapter 2
39
Determining cell topology for the service model
Determining cell topology for the service model

There are three basic approaches to cell topology:
s s s
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. 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. If you are assigning different components of the same service model across multiple cells, first determine which components are related. Then assign related components to appropriate cells until you assign all components of the service model.
To determine related component instances

This topic addresses the publication of different components of a service model to multiple cells: for example, publishing component 1 to cell A, component 2 to cell B, and so forth, until all components of the service model have an assigned cell. You determine related component instances based on your interpretation of the service model. For example, you might group instances based on geographic proximity, network connectivity, similarity of function, provider-to-consumer relation, and so forth. You can assign different component instances to different cells to distribute the processing load, or you can make the assignment based on the proximity of the cell to the instance it is monitoring. See Assigning related component instances to cells on page 101.
40
Component property updates
After you publish the service model, you can view the entire model from a single Impact Explorer console, as long as all the cells are registered with the BMC Impact Portal.

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.
Chapter 2
41
42
Chapter
Understanding a service model

A BMC impact service model is made up of
s
s s s
s s
data classes that describe the various types of physical and logical IT resources that make up an enterprises business corresponding data classes in the SIM KB of cells event classes associated with specific resources component instances that represent the unique physical and the logical configuration items that deliver business services impact relationships management data instances
This chapter presents the following topics: Service components . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . Component classes and types . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . Service component instances . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . Component status and substatus . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . Component status computation . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . Service model component types . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . Component relationships . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . Service consumers and providers . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . Relationship states. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . Status propagation in relationships . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . Relationship control . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . Dynamic status mapping . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . Event associations . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . Bringing events from the resource into the cell . . . . . . . . . . . . . . . . . . . . . . . . . . . . Event alias associations. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . Service schedules . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . Timeframes . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . Service schedules example with exceptions . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 44 44 44 45 46 47 52 53 55 54 56 56 58 58 59 62 62 63
Chapter 3
43
Service components
Service components
This section contains overview information about components classes and types, types of service component instances, 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 Service Model Editor and BMC IM. There are whole classes of objects that are not visible to SIM because they do not make sense in a service model (for example, BMC_Keyboard). 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 component instances

In BMC Impact Service Model Editor, a component instance is a specific, unique occurrence of a component type. A component type is the generic object: for example, server. The component instance is the specific, unique version of the type: for example, JBoxxServer 123. In BMC Impact Service Model Editor, you select one of the component types from the Templates dockable window and modify that template to create a component instance that defines a specific logical or physical asset.
Component status and substatus
All service model classes and related slots are stored in the BMC Impact Managers 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 on page 341.
Component status and substatus

A service component instance is characterized by its status, which is indicated by the color of the components icon in BMC Impact Explorer and BMC Impact Portal. Information about the status of a component instance is stored in the cell in the instances status slot. The initial status of a service component instance, just after its creation, is determined by the default value of its class-level status slot (usually this value is green or OK). Table 7 defines the default service component status values that are available in BMC Impact Explorer. Table 7 Service component status definitions
Default color value Equivalent BAROC Enumeration status 01 BLACKOUT monitoring of the component dark gray is suspended for a scheduled period status of the component has not yet or cannot be determined nothing has occurred that affects the components normal delivery of service awaiting information on the component component is delivering services normally, but some problem may effect it components delivery of service is slightly affected components delivery of service is affected component has a failure and is unable to deliver service light gray 10 NONE (no substatus) BLACKOUT
Service component status
Meaning
UNKNOWN
20
UNKNOWN
OK
green
30
OK
INFORMATION WARNING
medium blue yellow
40 50
INFO WARNING
MINOR IMPACT IMPACTED UNAVAILABLE
light orange orange red
60 70 80
MINOR MAJOR CRITICAL
Chapter 3
45
Component status computation
NOTE
Do not confuse the MC_SM_COMPONENT_STATUS enumeration with the STATUS enumeration that defines event status values, such as OPEN or ACK.
Component status computation

The status of a component instance is computed automatically by the cell when new conditions occur, such as
s s s
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 component instance in the StatusModel attribute. Based on the specific status computation model, the cell uses an algorithm to calculate the
s s s
status values propagated by inbound relationships severities of direct events associated with the service component instance impact status and service component self-status
The predefined status computation models available are Standard, Cluster, Weighted Cluster, Self-Preferred, and Cluster By Count. 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 select the status computation model for each component instance in the Create (or Edit) Component dialog box, on the Status and Alias tab, in the Status Computation box. BMC Impact Service Model Editor ensures that each component instance is associated with a valid status computation model. See Creating service component instances in BMC Impact Service Model Editor on page 78. For more information about component status computation and status computation models, see Chapter 7, Component and relationship status propagation on page 43.
Service model component types
NOTE
Whether and how the status of a provider component is propagated through a relationship is controlled by the relationship policy assigned to the component instance. For more information about selecting a relationship policy for a component, see Chapter 5, Building a service model in BMC Impact Service Model Editor on page 43.

Table 8 lists the component types, the superclass of the component, the icon that represents the component in BMC Impact Service Model Editor and in the consoles, and the class of the component as defined in the data model. These classes are derived from the class BMC_BaseElement. Table 8
Component superclass Logical Entity Activity Activity Decision Activity End Activity Interaction Activity Manual Activity Start Business Process Business Service Database Collection User Community Connectivity Collection IP Connectivity Subnet IPX Connectivity Network BMC_LNsCollection LAN Network WAN Network Organization
Service model component types (part 1 of 6)

Icon Component type Component class BMC_LogicalEntity BMC_Activity BMC_Activity ActivityType=ActivityDecision BMC_Activity ActivityType=ActivityEnd BMC_Activity ActivityType=ActivityInteraction BMC_Activity ActivityType=ActivityManual BMC_Activity ActivityType=ActivityStart BMC_BusinessProcess BMC_BusinessService BMC_DataBase BMC_Collection BMC_UserCommunity BMC_ConnectivityCollection BMC_IPConnectivitySubnet BMC_IPXConnectivityNetwork BMC_LNsCollection BMC_LAN BMC_WAN BMC_Organization
Chapter 3
47
Table 8
Component superclass System

Icon Component type Access Server Application Application Infrastructure Application System Cluster Communication Server Computer System Configuration Management Agent Component class BMC_System BMC_ComputerSystem PrimaryCapability=Access Server BMC_Application BMC_ApplicationInfrastructure BMC_ApplicationSystem BMC_Cluster BMC_SoftwareServer SoftwareServerType=Communication Server BMC_ComputerSystem BMC_SoftwareServer SoftwareServerType=ConfigMgmtAgent
48
Table 8

Icon Component type Database Server DNS Server File Server Firewall FTP Server Gateway Hub Input/Output Device JBOD (Just a Bunch Of Disks) Layer 3 Switch LDAP Server Load Balancer Mail Server Mainframe Message Server Mobile User Device (a handheld personal data assistant (PDA)) Component class BMC_System 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 BMC_SoftwareServer SoftwareServerType=LDAPServer BMC_ComputerSystem PrimaryCapability=LoadBalancer BMC_SoftwareServer SoftwareServerType=MailServer BMC_Mainframe BMC_SoftwareServer SoftwareServerType=MessageServer BMC_ComputerSystem PrimaryCapability=Mobile User Device
Chapter 3
49
Table 8

Icon Component type Monitor Print Server Print Server RAID Storage Device Resource Server Router SAN Bridge SAN Director SAN Hub SAN Router SAN Switch Security Server Server Software Server Storage Switch Component class BMC_System BMC_Monitor BMC_ComputerSystem PrimaryCapability=Print BMC_SoftwareServer SoftwareServerType=PrintServer BMC_ComputerSystem PrimaryCapability=RAIDStorageDevice BMC_SoftwareServer SoftwareServerType=ResourceServer BMC_ComputerSystem PrimaryCapability=Router BMC_ComputerSystem PrimaryCapability=SANBridge 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 BMC_ComputerSystem PrimaryCapability=Storage BMC_ComputerSystem PrimaryCapability=Switch
50
Table 8

Icon Component type Tape Library Telnet Server Transaction Server Component class BMC_System BMC_ComputerSystem PrimaryCapability=TapeLibrary BMC_SoftwareServer SoftwareServerType=TelnetServer BMC_SoftwareServer SoftwareServerType=TransactionServer
UDDI Server Virtual System Web Cache Web Server System Service Application Service System Component
BMC_SoftwareServer SoftwareServerType=UDDIServer BMC_VirtualSystem BMC_ComputerSystem PrimaryCapability=Web Caching BMC_SoftwareServer SoftwareServerType=WebServer BMC_SystemService BMC_ApplicationService BMC_SystemComponent
Hardware System Component BMC_HardwareSystemComponent
Media CD ROM Drive Disk Drive Floppy Drive Tape Drive
BMC_Media BMC_CDROMDrive BMC_DiskDrive BMC_FloppyDrive BMC_TapeDrive
Uninterruptible Power Supply BMC_UPS (UPS)
Chapter 3
51
Component relationships
Table 8
Component superclass

Icon Component type Logical System Component File System Database Storage Local File System Remote File System Disk Partition Software System Software Operating System Virtual System Enabler VMware System Resource Component class BMC_SystemComponent BMC_LogicalSystemComponent BMC_FileSystem BMC_DataBaseStorage BMC_LocalFileSystem BMC_RemoteFileSystem BMC_DiskPartition BMC_Software BMC_SystemSoftware BMC_OperatingSystem BMC_VirtualSystemEnabler BMC_VMWare BMC_SystemResource
System Component
Component relationships
Service management relationships are impact relationships. Table 9 lists the main relationship classes derived from BMC_BaseRelationship, of which only BMC_Impact defines impact relationships for a service model. Table 9
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 component instances. 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_Dependency
BMC_Component
52
Service consumers and providers
Table 9
Class name
Main relationship classes

Class description 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 component instances 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_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. The concepts of provider and consumer are relative to the relationship being considered. In Figure 5 on page 54, Component B is a provider in one relationship and a consumer in another. The service model enables a component instance to be related to another component instance by defining the relationship in the BMC_Impact class. Such a relationship states that a component instance is impacted if something happens to the component instances to which it is related. For example, a group of people responsible for accounting will be impacted when the accounting database server is down. Service model relationships are organized in a hierarchy of data classes in which each class represents a relationship type. The parent class for component relationships is BMC_Relationship. All service model relationship classes are defined in the BMC Atrium CMDB as a subclass of BMC_Relationship.
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 Impacts priority on page 191.
Chapter 3
53
Status propagation in relationships
Figure 5
Impact (status) propagation in relationships
Status propagation in relationships

Status propagation is the passing of a status or a modified status from one component instance 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
s s
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 on page 169.
54
Relationship states
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.
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
s s
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:
s
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.
Chapter 3
55
Relationship control
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
s s s
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.
Dynamic status mapping

Dynamic status mapping translates the main status of the provider component into a propagated status for input into the impact function of the consumer component in a relationship, as described in the following process: 1. bringing the events from the monitoring application into the cell For physical resources, most of which are or can be instrumented, you can obtain status information by actively monitoring the resources variables, parsing its log files, or capturing the SNMP traps that it sends. This information can be formatted into events that a cell can process. The cell can accept event instances from a variety of sources:
s
s s
Events can be manually obtained directly through adapters and the msend and mposter commands. Cells also provide events through propagation rules. Other sources include third-party products that can be integrated with BMC IM.
2. associating those events with the service model component instance that represents the resource
56
Dynamic status mapping
You can associate events from a resource with the component instance that represents it by using the alias key. The actual association is done using a slot-mapping data table, which stores all the slot-mapping formulas for event classes. The arrival of an event invokes a unique predefined rule that generates a value for the events mc_smc_alias slot and searches for the matching service component in the alias table. With this process in place, incoming events can alter the status of the component directly in real time. For example, an event with a severity of CRITICAL could turn the status of the associated component to UNAVAILABLE by using a severity-tostatus mapping table. The BMC_PROPAGATION_MAP table defines the status-mapping instances for the relationships. A group of BMC_PROPAGATION_MAP instances sharing the same name form a propagation map that is uniquely bound to the status propagation model with the same name. When two components participate in an impact relationship and the status of the provider changes, the new status must be propagated to a consumer component. First, the cell seeks the BMC_PROPAGATION_MAP instance in which the following value matches occur:
BMC_PROPAGATION_MAP instance slot value Matching class instance name relationship_state provider_status relationship relationship provider component
Matching value propagation_model slot value state slot value status slot value
Then, the cell obtains the appropriate propagated_status value to propagate, depending on the current state of the relationship (ACTIVE or INACTIVE). The cell propagates this value to the consumer component for input to the consumers status computation. For example, consider an impact relationship with service component named XService that is a consumer of an IT component, DBsoftware. The relationship is active and the propagation model assigned to it is INCREASING. When the cell needs to propagate DBsoftwares current status (IMPACTED) to its consumer component, XService, it searches the INCREASING propagation map to find the instance corresponding to a provider status of IMPACTED. To obtain the appropriate propagated_status value, it matches the corresponding relationship state (ACTIVE), which is a value of UNAVAILABLE in this instance. Finally, the cell propagates the appropriate changed status to the consumer component. Propagation maps affect only the way in which the main status of the provider is propagated in the relationship. They do not affect how the substatus is propagated from the provider to the consumer.
Chapter 3
57
Event associations
Event associations
A production service model requires that the incoming events that contain information about the state of a IT asset be associated with the appropriate service model component instance. This event association provides the mechanism for keeping a component instances status up-to-date, so that it reflects the real-time health of the actual resource that it represents. Event association uses the aliases that you assign to service components and event alias associations that you create in BMC Impact Service Model Editor. To set up an event association, you must
s
bring events from the resource into the cell associate the events with the service model component instance that represents the resource enter an alias in the Alias attribute of the component instance create an appropriate event alias association for the component instance
verify that the event association works correctly
Bringing events from the resource into the cell

To bring events to a cell, you configure the event sources for the resource, such as a log file or an SNMP trap file, to provide the necessary information about its status. You can use a BMC Impact Event adapter, a BMC Impact Integration product, a thirdparty product, or another utility to produce BMC Impact Manager events.
Component aliases
You designate a component instance as participating in alias activity by entering a value in the Alias attribute when you create or edit a component instance in BMC Impact Service Model Editor. An alias identifies a specific component instance. When an event arrives at the cell, the cell constructs an alias using data in the events slots plus any other elements specified in the alias formula. An alias formula defines the content and format of the alias.
58
Event alias associations
A service component instance can have several different aliases so that different event types can be easily associated with it. Service component aliases are stored in the BMC Atrium CMDB and are associated with the relevant service component by the components universal data identifier (udid). An alias formula is an object published to the cell; it is not associated with any object in the service model; it is management data supporting the service model. For information about entering component aliases in a component instance, see Creating service component instances in BMC Impact Service Model Editor on page 78.

You set up the dynamic association of events with a component instance by using the Tools => Alias Formulas menu command in BMC Impact Service Model Editor. When you set up the dynamic association of events with a component instance, you must specify two elements:
s s
an event class an alias formula
The event class identifies which incoming events may affect the status of the component instance. For example, for an application component instance, you want events of a particular category, such as SYSTEM_EVENT, APPLICATION_EVENT, DATABASE_EVENT, to be considered by the cell. After the cell has constructed the events alias, it searches each component instance to see if the value in its ComponentAlias attribute matches the alias constructed from values in the event. If it matches, the event is associated with the component instance in the BMC_SIM_ALIAS class and can change the component instances status, depending on the component instances status propagation model. The alias formula must have a syntax that can be read by the cell. It consists of sprintf format specifications (which specify the format for the output) followed by expressions that specify event slots and functions involved in the construction of the alias. An example of a simple alias formula is
EXAMPLE
[sprintf("%s/%s", [$1.mc_object,$1.mc_host])']
The order of the sprintf format specifications corresponds to the order of the expressions, as shown in Figure 6.
Chapter 3
59
Figure 6
Parts of a simple alias formula

sprintf format specifications expressions
['sprintf("%s/%s",[$1.mc_object/$1.mc_host])']
In Figure 6, %s/%s is the data type of the output and $1.mc_object $1.mc_host are variable expressions. The first format specification, %s (a string), corresponds to the first variable expression $1.mc_object (which is the value in the mc_object slot of the event, with $1 representing the event ID). The second format specification %s (a string), corresponds to the second variable expression, $1.mc_host. Table 10 shows the event data, the alias formula, the alias that was computed from the data in the event and the alias formula, and the alias stored in the component instance, which in this example matches the computed alias from the event data. Table 10
Event
How an event alias association works

Alias Formula [sprintf("%s/%s", [$1.mc_object/ $1.mc_host])] The values in mc_object and Alias SALES/dcsrv02.store.com Component instance alias
DATABASE DOWN; mc_host='dcsrv02.s tore.com'; mc_object_class='C entral Database'; mc_object='SALES'; msg='Database is down'; END
mc_host are output as string values,

with a slash between them.
When the cell finds a match, an entry is created in the BMC_SIM_ALIAS class, as shown in this example:
EXAMPLE
BMC_SIM_ALIAS; ComponentAlias='SALES/dcsrv02.megastore.com'; ComponentID='1234'; END
The alias links the event DATABASE DOWN to the component instance with the component ID 1234.
60
NOTE
The BMC_SIM_ALIAS object is part of the SIM management data. It is not visible in BMC Impact Service Model Editor.
Other examples of alias formulas:
EXAMPLE
[sprintf(%s,strextract($1.mc_object,1,6))] [sprintf(Mail@robot%s,strextract($1.mc_object,(len($1.mc_object)),1)] ['sprintf("%s%s%s",[$1.date,$1.mc_ueid,$1.adapter_host])']
Precedence rules for alias formulas

The most specific matching entry is selected. Since there can be more than one matching entry, precedence rules determine the entry that is used:
s
a match for element nth has precedence over a match for element (nth + 1) for matches on the same element, precedence is based on the conditional operator in the formula, in the following order: equals, has_prefix, has_suffix, contains, any
for multiple has_prefix matches on the same element, the longest prefix wins for multiple has_suffix matches on the same element, the longest suffix wins for multiple contains matches on the same element, the longest contains wins for multiple contains matches on the same element and with the same length, the contains that has its match closer to the beginning of the string wins
Chapter 3
61
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).
s
Periods when a component instance is in high demand, or when it must meet its availability and performance goals, are called During Schedule. Periods when a component instance is in low demand, or when the components s availability and performance are less important, are called Off Schedule. 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 Dynamic prioritization on page 181.
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.
s
Global timeframes are created in the BMC Impact Service Model Editor, 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 Service Model Editor and the BMC Impact Explorer. 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 Impact Explorer schedules editor.
62
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 BMC Impact Service Model Editor BMC Impact Explorer Stored in Available to BMC Atrium CMDB all cells a single cell event management policies within a single cell
Timeframe type

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.
Chapter 3
63
64
Chapter
Understanding a service model created in BMC Impact Service Model Editor

4
This chapter presents the following topics: Role of the BMC Atrium CMDB in service modeling. . . . . . . . . . . . . . . . . . . . . . . . . . . Service model and the Common Data Model . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . Sandboxes . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . Datasets . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . Testing . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . Promotion . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . Service model publishing . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . Service model execution on cells . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . In-model and not-in-model component instances . . . . . . . . . . . . . . . . . . . . . . . . . . . . . Importing Business Time Segments from BMC Remedy AR System . . . . . . . . . . . . . 66 66 70 71 71 71 73 73 73 74
Chapter 4
65
Role of the BMC Atrium CMDB in service modeling
Role of the BMC Atrium CMDB in service modeling

The BMC Atrium Configuration Management Database (BMC Atrium CMDB) is a multi-component 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 component instances and relationships for a given purpose. This makes it possible for the same component or relationship instances to exist in more than one dataset. Datasets provide a mechanism for storing raw data from multiple resources in discrete locations. Then the reconciliation process takes that data and merges it appropriately to create a composite set of unique data instances that includes information from each source, based on what each source is proficient at obtaining. The ability to capture the raw data from various sources and reconcile it to a controlled dataset enables the interaction between various automation tools.
Service model and the Common Data Model

The Common Data Model (CDM) is an extensible class schema that represents configuration items 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.
SIM classes
BMC Impact Solutions extends the BMC Atrium CMDB CDM with a predefined set of SIM-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 SIM CMDB Extensions also define attributes that are used only for SIM, such as StatusModel and ImpactCostPerSec.
66
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 comes with the BMC SIM CMDB Extension 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 SIM-qualified subclasses for BMC_Collection, which provides mechanisms for grouping components together into logical elements, including business processes and services. Table 12 SIM-qualified subclasses of BMC_Collection
Third Level BMC_ConnectivitySegment BMC_IPConnectivitySubnet BMC_IPXConnectivityNetwork BMC_LNsCollection BMC_Organization BMC_UserCommunity BMC_LAN BMC_WAN Fourth Level
Second Level BMC_ConnectivityCollection
Table 13 lists the SIM-qualified classes for BMC_LogicalEntity, which tracks other logical elements of a system, including people, physical plants, and location information. Table 13 SIM-qualified subclasses of BMC_LogicalEntity
Third Level BMC_BusinessProcess
Second Level BMC_Activity BMC_BusinessService BMC_Database
Table 14 lists the SIM_qualified classes for BMC_System, which contains the definition of computer systems, mainframes, application systems, and virtual systems.
Chapter 4
67
Table 14
SIM-qualified subclasses of BMC_System

Third Level BMC_Application BMC_ApplicationInfrastructure BMC_SoftwareServer MainframeBMC_Activity Printer VirtualSystem
Second Level BMC_ApplicationSystem
BMC_ComputerSystem
Table 15 lists the SIM-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 SIM-qualified subclasses of BMC_SystemComponent
Third Level BMC_DiskPartition BMC_SystemResource BMC_FileSystem BMC_DataBaseStorage BMC_LocalFileSystem BMC_RemoteFileSystem BMC_CDROMDrive BMC_DiskDrive BMC_FloppyDrive BMC_TapeDrive Fourth Level
Second Level LogicalSystemComponent
HardwareSystemComponent
BMC_UPS BMC_Media
Table 16 lists the SIM-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 configuration items. The attributes for BMC_SystemService are SystemClassId and SystemName. Table 16 SIM-qualified subclass of BMC_SystemService
Second Level BMC_ApplicationService
68
SIM attributes
SIM qualifiers have been added to the attributes listed in Table 17. Table 17
Class BMC_BaseElement
SIM-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] ClusterType [SIM, SME_Read, SME_ReadWrite] Interconnect [SIM, SME_Read, SME_ReadWrite] InterconnectAddress [SIM, SME_Read, SME_ReadWrite] MaxNumberOfNodes [SIM, SME_Read, SME_ReadWrite] Types [SIM, SME_Read, SME_ReadWrite]
BMC.AM
BMC.SIM
BMC_Cluster
BMC.CORE
Chapter 4
69
Sandboxes
Table 17
Class
SIM-qualified attributes
Namespace Attributes 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_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 SIM qualifiers are

s s s s
SIM: 300050 SIM_Internal: 300060 SIM_ReadWrite: 300070 SME_Read: 300080
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. BMC Impact Service Model Editor users each 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 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.
70
Datasets
Datasets
The production dataset is the reference dataset, or logical partition of data in the BMC Atrium CMDB, shared by SIM and ITSM applications. Objects contained in the production dataset are components, relationships, and management data. The production dataset is not limited to objects that are in-model. Many of these objects can be out-of-model (they are not yet in BMC Impact Manager cells). 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. Another type of dataset is the test dataset. The test dataset relays objects from a sandbox view to a test BMC Impact Manager instance.
Testing
Before moving sandbox changes into production, you can send the changes to a defined test cell and explore service model behavior in the context of various events. For example, you could send test data to a test cell, then view the generated events in BMC Impact Explorer to determine if the desired result occurs. You must have sufficient permissions to send data to a test cell. If you have promote permissions, you also have access to a test cell.
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 and, if automated publishing is enabled, in-model data is sent to BMC Impact Manager cells in the environment. As soon as you successfully promote changes to a production dataset, the sandboxes of all other users are updated to reflect the new data. BMC Impact Service Model Editor limits promotion to 3000 component instances at a time.
Chapter 4
71
Promotion
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 Impact Manager cells. The promotion process is as follows:
s
After making changes in a sandbox View, you start the promotion process from the BMC Impact Service Model Editor interface. BMC Impact Service Model Editor initiates a reconciliation job. After the actual promotion process begins, you cannot work in BMC Impact Service Model Editor until the process finishes; however, you can stop the promotion or exit the BMC Impact Service Model Editor interface.
Promotion log objects are created in the BMC Atrium CMDB. The objects contain the name of the user, a short, user-specified description of the promotion, the ID of the reconciliation job, start and end dates, and a list of objects selected for promotion. BMC Impact Service Model Editor regularly checks the progress of the reconciliation job. When the process is completed, BMC Impact Service Model Editor updates the objects and indicates that the promotion is complete. When the promotion has ended, if automated publishing is enabled, the BMC Impact Publishing Server initiates a publish from the production dataset to the BMC Impact Manager cells in the environment. If other publish operations are underway at that time, the request is queued. After the changes have been published to BMC Impact Manager instances, an execution log is generated. You can view it from the BMC Impact Service Model Editor Promote and Publish History dialog box.
NOTE
Most data published during an automated publish comes from sandboxes. By default, new objects from a discovery source such as BMC Foundation Discovery or BMC Topology Discovery, or from BMC Remedy Asset Management, are not flagged as in-model and are not published to the cell. However, these sources can update objects that are already in-model and those changes are published to cells.
72
Service model publishing
Service model publishing

Service model publishing is the process of distributing the service model data to BMC Impact Manager cells. After a promotion completes, the BMC Impact Publishing Server is notified of the termination of a reconciliation and starts a publication. From the BMC Atrium CMDB, the BMC Impact Publishing Server distributes the BMC.ASSET dataset to cells and stores a master copy in the BMC.IMPACT.PROD dataset. The BMC.IMPACT.PROD dataset is updated and maintained only by the BMC Impact Publishing Server. It mirrors the last successful publish to the cells. Publishing can be initiated automatically by using BMC Impact Service Model Editor or manually by using the BMC Impact Publishing Server CLI publish. When the component instances and relationships are published, you can monitor the component instances by using BMC Impact Explorer and BMC Portal.
Service model execution on cells

Service component instances are associated with events through the use of unique aliases, which you specify for each component instance. 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 component instances. When a match is found, the event is associated with the component instance and the instances status may be changed.
In-model and not-in-model component instances

Service component instances that are visible in BMC Impact Service Model Editor are classified as in-model or not-in-model component instances. In-model service component instances exist in the BMC Atrium CMDB and in the specified cell, and can be monitored in BMC Impact Explorer and BMC Impact Portal. (At any given time, they might not be visible in BMC Impact Explorer and BMC Impact Portal, depending on their status.)
Chapter 4
73
Importing Business Time Segments from BMC Remedy AR System
Not-in-model component instances are visible and available in BMC Impact Service Model Editor; however, they have not been published, are not present in the cell, and cannot be monitored in BMC Impact Explorer and BMC Impact Portal. You can choose to designate component instances as not-in-model at design time. For example, you might want to create the component instance but not monitor it right away. You would designate that component as not in model. Changes to in-model, published component instances are not seen in BMC Impact Explorer and BMC Impact Portal until the changes are published. A component instance that is in model can be monitored in BMC Impact Explorer and BMC Impact Portal. A component instance that is not in the model cannot be monitored in BMC Impact Explorer or BMC Impact Portal.
Importing Business Time Segments from BMC Remedy AR System

You can import Business Time Segments from BMC Remedy AR System into BMC Impact Service Model Editor to use as timeframes when you define service schedules for service components. Imported timeframes, considered Global timeframes, are published when the next publish occurs. For information on importing Business Time Segments, see BMC Portal Getting Started.
74
Chapter
Building a service model in BMC Impact Service Model Editor

5
This chapter provides detailed procedures on how to build the service model in BMC Impact Service Model Editor. This chapter covers the following topics: Service model creation process . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 77 Launching BMC Impact Service Model Editor . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 77 Working with service component instances . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 78 Creating service component instances in BMC Impact Service Model Editor . . . 78 Switching sandbox View modes . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 83 Viewing properties for a component instance . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 84 Editing component instances. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 85 Performing actions on multiple objects . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 85 Copying component instances. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 87 Hiding a component instance . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 88 Deleting a component instance . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 89 Finding component instances . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 89 Defining relationships between component instances . . . . . . . . . . . . . . . . . . . . . . . . . . 96 Creating a component relationship in BMC Impact Service Model Editor . . . . . 97 Assigning related component instances to cells . . . . . . . . . . . . . . . . . . . . . . . . . . . 101 Updating relationships . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 102 Deleting relationships . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 103 Associating events with a component instance . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 104 Working with timeframes and service schedules . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 109 Icons used in the service schedule and timeframes editors . . . . . . . . . . . . . . . . . 110 Working with timeframes . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 110 Working with service schedules . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 113 Assigning components to service schedules . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 117 Granting access to service model objects . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 118 Granting permissions to individual service model objects . . . . . . . . . . . . . . . . . . . . . 118 Testing the service model . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 120 Testing component relationships . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 120 Testing event associations . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 120
Chapter 5 Building a service model in BMC Impact Service Model Editor 75
Promoting the service model . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 121 About the publishing process. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 121 Before you promote . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 122 Submitting a promotion . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 122 Verifying promotion status. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 125 Organizing service component instances for monitoring . . . . . . . . . . . . . . . . . . . . . . 128 Working with BMC Impact Service Model Editor Views. . . . . . . . . . . . . . . . . . . . . . . 132 Saving, opening, renaming, and deleting Views. . . . . . . . . . . . . . . . . . . . . . . . . . . 133 Understanding visual cues in a View . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 134 Repositioning objects in a View . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 135 Controlling what you see in a View . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 136 Exploring consumer and provider paths . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 138 Refreshing the View. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 139 Repositioning the dockable windows . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 140 Showing topology views. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 140 Exporting and importing service model data. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 141 Exporting class definitions from the BMC Atrium CMDB to a cells . . . . . . . . . . . . . 142
76
Service model creation process
Service model creation process

To build a service model in BMC Impact Service Model Editor, you must
s s s s s s
find or create component instances in the BMC Atrium CMDB assign component instances to a BMC Impact Manager cell define component instance relationships associate events with component instances assign schedules to component instances promote the service model and publish objects to cells
Launching BMC Impact Service Model Editor

You can open BMC Impact Service Model Editor from the BMC Portal.
To log on to BMC Impact Service Model Editor from BMC Portal 1 Open a browser. 2 In the Address box, enter the URL in the format https://serverName.
serverName represents the name of the server on which BMC Portal is installed.
3 Log on to BMC Portal as a user.

For instructions for logging on to BMC Portal, see BMC Portal Getting Started.
4 On the Configure tab, in the navigation pane on left side, under Tasks, click BMC
Impact Service Model Editor. Before you can launch BMC Impact Service Model Editor to view and manage services, you must install it in one of the following ways:
s
as a stand-alone console from the BMC Portal product installation disk As a stand-alone console, BMC Impact Service Model Editor can reside on the same host computer as the BMC Portal or it can reside on another host computer. However, all user validation and security is managed by the BMC Portal server.
as a Java Web Start application from BMC Impact Portal
Chapter 5 Building a service model in BMC Impact Service Model Editor
77
Working with service component instances
As a Java Web Start application, after BMC Impact Service Model Editor is deployed on your local desktop, you can launch it from the local desktop icon a local startup menu the Java Web Start Application Manager on your local host computer from the BMC Portal Configure tab as a task User authentication and security is managed centrally by the BMC Portal server. To launch BMC Impact Service Model Editor, you must connect to the BMC Portal.
Working with service component instances

To populate the BMC Atrium CMDB with component instances for the service models, you can use discovery tools such as BMC Topology Discovery or you can manually create the component instances by using the BMC Impact Service Model Editor. The BMC Impact Service Model Editor component 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 component instances, see Finding component instances on page 89.
NOTE
BMC Software recommends creating a maximum of 20,000 service model component instances for each BMC Impact Manager cell.
Creating service component instances in BMC Impact Service Model Editor

You can create a service component instance in BMC Impact Service Model Editor by using the following features of the interface:
s s
the Template window the Create Component menu command
Before you begin

Ensure that you have the service catalog spreadsheet that lists IT components and their relationships.
Ensure that the BMC Portal product is installed; see the BMC Portal Getting Started guide.
TIP
s
To free more desktop area for the View, you can hide the dockable windows by clicking the left-pointing quick-expansion arrow located along the right side of the dockable windows. You can also undock and move the Templates, Pan and Zoom, Find, Properties, Views, and Console Navigation Bar windows. See Repositioning the dockable windows on page 140.
To create a service component instance by using the menu command 1 With a sandbox View open, from the menu bar, choose Edit => Create Component.
When you open BMC Impact Service Model Editor, a new sandbox View opens automatically if you have no saved Views. You can also open a new sandbox View at any time by clicking on the toolbar. If you have saved Views, you can open the appropriate View from the Views panel.
2 In the Create Component dialog box, on the General tab, scroll in the Component
Type pane until you find the appropriate component type for the instance that you are creating.
The service component types are listed in hierarchical order, not in alphabetical order.
Where to go from here

To enter values for other component instance attributes, see To specify component instance attributes on page 81. To learn about creating component instances using the Template window, continue with the next section.
79
To create a service component instance by using the Template window 1 With a sandbox View open, find the appropriate service component type (class) for
the instance that you are creating in the Templates window. When you open BMC Impact Service Model Editor, a new sandbox View opens automatically if you have no saved Views. You can also open a new sandbox View at any time by clicking on the toolbar. If you have saved Views, you can open the appropriate View from the Views panel. You can change the way the list of components are presented in the Templates window by clicking the appropriate icon for List, Large Icon, and Tree layouts. The List and Large Icon layouts are sorted alphabetically (you can reverse the sort) and the Tree layout is in SIM class hierarchy order.
2 Drag the component type from the Templates window to the View-Sandbox
window. When placing objects in the sandbox View window, place consumer instances above provider instances for a hierarchical layout. Create multiple copies of the component type at one time by holding down a number key while dragging the component icon to the View window. For example, to create eight copies of a component, hold the number 8 key while dragging the component icon. Holding down the 0 key while dragging creates ten copies. Note that holding down the 1 key while dragging creates eleven copies of the component type.
3 In the View-Sandbox window, right-click the new component icon and select Edit
Component Properties.
On the General tab, in the Component Type pane, the component type you chose is selected by default. If you chose the wrong component type, click Cancel and start again with step 2.

To enter values for component instance attributes other than component type, see To specify component instance attributes on page 81.
80
To specify component instance attributes 1 On the General tab, perform the following steps: A In the Component Name box, replace the default name with a specific component
instance name that is meaningful to your enterprise and that you want to use as the components label in a View.
B In the Cell box, accept the default, unassigned, or select the cell that will receive
events for the component instance. BMC Impact Service Model Editor retrieves the list of cell names from the BMC Atrium CMDB. If the cell that you need is not listed, see the BMC Portal Getting Started guide for information about adding a cell.
WARNING
s
If unassigned is chosen, the component instance is automatically set to Not In Model and cannot be published. BMC Impact Service Model Editor verifies that the cell name chosen is present in the BMC Impact Portal, but if the component instance is created outside of BMC Impact Service Model Editor or if the cell is deleted from BMC Impact Portal after it has been created but before it is published, data integrity errors may result.
C (optional) In the Description box, enter a component description that is

meaningful to your enterprise.
D (optional) In the Owner section, in the Name box, enter the name of the individual
who is responsible for the component, and in the Contact box, enter a contact method, such as a phone number or email address, for the individual.
E In the Component Is area, choose Not In Model or In Model:

s
To include a component instance in the service model, select In Model; it can be published to the cell. To not include a component instance in the service model at the present time, select Not In Model; it cannot be published to the cell.
For more information about in-model and not-in-model, see In-model and notin-model component instances on page 73.
2 On the Status and Alias tab, perform the following steps:
81
A In the Status Computation list, select a status computation model.

The default selection is Standard, which is acceptable for most component instance definitions. For more information about status computation models, see Chapter 7, Component and relationship status propagation. The default status for new component instances is OK.
B In the Aliases box, click Add Alias.

Each component instance must have a unique alias; if more than one component instance has the same alias, publishing fails. For information about aliases, see Event associations on page 58. In the Alias box, enter the alias and press Return or click OK. (optional) Enter additional aliases (one for each event that can potentially affect the status of the component instance) by clicking Add Alias. Each alias that you enter is listed in the Aliases box.
3 On the Permissions tab, assign the proper permissions for this component instance
to each of the roles listed.
4 On the Schedule tab, perform the following steps: A Assign the appropriate service schedules information to the components.
For more information, see Assigning components to service schedules on page 117.
B In the Time-variable Properties area

Choose a base priority for the components for During Schedule Timeframes and Off Schedule Timeframes. Enter the cost units per second for During Schedule Timeframes and Off Schedule Timeframes.
C In the Priority Propagation area, select

s
Yes to have the selected components propagate their self priority to their
causal components
s
No (default) if self priority should not be propagated
82
Switching sandbox View modes
5 (optional) On the Other tab, enter relevant information about the component in the
fields listed.
6 To save the component instance in the BMC Atrium CMDB (or save changes if you
used the Templates window), click OK.

Continue creating component instances until you have a number of component instances that are related, and then see Defining relationships between component instances on page 96. To learn more about working with component instances (viewing, editing, copying, deleting, and finding), continue with the next section.
Switching sandbox View modes

In the sandbox, 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 View modes by clicking the appropriate toolbar icon, as shown in Table 18. Table 18
Icon
View mode switch icons

View mode Topology
Component Table
83
Viewing properties for a component instance
Viewing properties for a component instance

You can view properties for a component instance, do one of the following:
s s
s s
In a View window, right-click a component instance and select Properties. Select the Properties dockable window, and in a View window, select a component instance or select a component instance and then click Properties on the Properties dockable window. On the toolbar, click the Display the properties window icon. Select a component instance and from the menu bar and choose Windows => Properties. Switch to Component Table mode . You can select columns (for this session only) by right-clicking any column heading and selecting Configure table columns.
By default, the properties shown for a component in Component Table mode include Table 19
Type Type Name Scope Cell Owner Name Company Status Model Priority - During Schedule Priority - Off Schedule Description Reconciliation Identity
Default component properties

Description the general component type, such as application, computer system, and database. the name of the component. whether the component is in a production, sandbox, or test environment. the name of the BMC Impact Manager to which the component is assigned. the name of the person responsible for the component. the name of the business associated with the component. status computation model description, such as Standard the base priority of a component (1-5) in a During Schedule timeframe the base priority of a component (1-5) in an Off Schedule timeframe any special notes on the component ID used to reconcile this component, as in matching this component instance across datasets
You can configure which component properties are displayed for a component in Component Table mode by right-clicking a table column heading and selecting Configure Table Columns. The default sort order is by Name.
84
Editing component instances
You can also change the values for a property from the Properties dockable window by clicking the appropriate Edit button. (Each section of data has its own Edit button.) For more information about changing properties of a component instance, see Editing component instances.
Editing component instances

You can change properties (attributes) for a component instance, except the components class, by opening the Edit Component Properties dialog box. If the component is already being edited, a warning dialog is displayed. Though you are not locked-out of editing the component, you should wait until the edit is complete before proceeding.
To modify component instance properties 1 Either

s s
in the active View window, select the component instance to edit, or in a Table of Components view, select the component property to edit.
2 Do one of the following to display the Edit Component Properties dialog:

s
Right-click the component instance or property and choose Edit Component Properties from the context menu. From the menu bar, choose Edit => Edit Component Properties.
3 Make the appropriate changes. For more information about the properties of
components, see To specify component instance attributes on page 81.
4 Click OK.
Performing actions on multiple objects

You can perform some actions on multiple objects at the same time (or example, you can add the same cell to several component instances, or delete multiple component instances).
85
Performing actions on multiple objects
To select multiple objects 1 On the toolbar, click Selection

you want to select. .
2 With the mouse pointer, click and drag to draw a box around all the objects that 3 Right-click and select the action that you want to perform. To change in-model or not-in-model setting quickly
In an active View window, select the component instances, or component instances and relationships, and do use of the following methods:
s s
On the toolbar, click the add-to-model or remove-from-model Right-click and choose Add to Model or Remove from Model.
icon.
Only the object type specific to a particular action is affected and the other type is ignored. For example, selected relationships are ignored when you assign multiple objects to a cell.
To add or change the assigned cell 1 In an active View window, select the component instances. 2 Right-click and choose Assign Component to Cell.
If all the component instances have the same cell, the cell name is displayed. If even one cell name is different, the Cell box is blank.
3 Select a cell from the list, or select [unassigned].

When you select a cell, all component instances are updated with that cell. If you select unassigned, component instances no longer have cell assignments and all components that were in model are changed to not in model and cannot be published.
86
Copying component instances
To edit multiple component instances 1 Select the appropriate component instances. See To select multiple objects on
page 86.
2 Take one of the following actions:

s s
Right-click the component instances and choose Edit Component Properties. From the menu bar, choose Edit => Edit Component Properties.
3 In the Edit Multiple Component Properties dialog box, make the necessary
changes. The objects you selected appear in the Component List box. Changes you make will apply to every component instance in the list. If even one component instance has a different value for a property, the field is blank.
4 When you have finished making changes, take on of the following actions:
s s s
to save and exit, click OK. to save and keep the dialog box open, click Apply. to discard the changes and exit, click Cancel.
Copying component instances

You can copy one or more component instances and paste the copies into the sandbox View. When pasting copies, you can automatically rename the pasted components by attaching a prefix or suffix to the original component name. To configure copy and paste options, see To set copy/paste and miscellaneous options on page 198. Relationships are not copied unless they are also selected. See To select multiple objects on page 86.
To copy component instances 1 Select one or more component instances that you want to copy. 2 Right-click and choose Copy. 3 Right-click and choose Paste. 4 If you are copying more than one component, in the Paste Multiple Components
dialog box, add a prefix or suffix to the original component name as needed and click OK.
87
Hiding a component instance
The default prefix is Copy of, but you can specify a prefix by entering a new value in this box.
Output Preview displays the name of one of the newly pasted component instances.
When more than one component instance is selected for copying, the name of only one of the selected component instances displays. You can replace the default prefix or suffix by changing it in the Options settings. To prevent the Paste Components dialog box from prompting you at each paste, select Do not show this dialog again. When this check box is selected, the current option is used until you change it in the Options settings. See To set copy/paste and miscellaneous options on page 198.
Hiding a component instance

You can hide a component instance so that it is not visible in the current active View or in all Views. A hidden component instance that has been published to a cell is not deleted from BMC Impact Service Model Editor and can be retrieved with the Find command.
To hide a component instance 1 Select the component instances to hide. 2 To hide the component instances in the active View, take one of the following
actions:
s s
Right-click and choose Hide in This View. Choose Edit => Hide in This View.
The selected component instances are removed from the active View, but are still visible in other Views in which they have been saved. If they are part of the service model, they remain in the service model.
3 To hide the component instances in all Views, take one of the following actions:
s s
Right-click and choose Hide in All Views. Choose Edit => Hide in All Views.
The selected component instances are removed from all Views and from the service model. Data in the component instance is not modified in any way; the component instance just does not appear in any of the current Views.
88
Deleting a component instance
Deleting a component instance

When you delete a component instance in a View
s
Components in the BMC.ASSET (in the BMC Atrium CMDB) that are marked as deleted (MarkAsDeleted) are not visible in BMC Impact Service Model Editor. Components in your sandbox that are marked as deleted appear in BMC Impact Service Model Editor with an X icon. Components that are new in the sandbox (that have no copy in BMC.ASSET yet) are hard-deleted from the sandbox.
NOTE
If you want only to remove a component instance from your Views without deleting it permanently, use the Hide in All Views command as described in Hiding a component instance on page 88.
To delete a component instance 1 In a View window, select the component instances you want to delete and take one
of the following actions:
s s
Right-click the component instance and choose Delete from CMDB. from the menu bar, choose Edit => Delete from CMDB.
2 Verify that you want to delete the component instances and click Yes. 3 Choose File => Promote All Sandbox Changes. 4 Review the Objects to be Promoted area to ensure that the component instances that
you want to delete are listed.
5 Click Begin Promotion.

The deleted instances are removed from the service model; they are no longer available in BMC Atrium CMDB.
Finding component instances

You can search the BMC Atrium CMDB for existing component instances by using the Find command. Only component instances associated with classes that are designated for service impact management in the BMC Atrium CMDB can be found in the BMC Impact Service Model Editor.
89
Figure 7
Find Component dialog box
You cannot search for relationships with the Find command, but when related component instances are found and placed in a View, their relationships are also placed in the View.
To find existing component instances 1 Launch the Find command by taking one of the following actions:
s s s
On the toolbar, click Find. From the dockable windows, click Find. From the menu bar, choose Window => Find.
2 On the Find tab, in the Component Name box, enter the name of the component
instance that you want to find. To display a list of all component instances, leave the Component Name box blank and click Find. You can 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).
3 (optional) Save the search statement by clicking Add to Saved Finds and reuse it by
clicking Open Saved Finds.
90
4 (optional) In the Look in area, accept the default, Sandbox and Production, or filter
the list of component instances in the results pane by choosing Production Only or Test Only.
5 (optional) To define the attributes that are displayed in the results table and their
order, right-click in any results-table column heading and select Configure table columns. The attributes shown in the Available Attributes pane are
s s
listed in alphabetical order common to all component types
In the Configure Find Results dialog box, select the appropriate attributes.
s
To change the order of the columns in the final results display, use the up and down arrow buttons. To move the attributes that you want to display into the Attributes to Show pane, use the left and right arrow buttons.
6 To start the search, click Find.

While the search is in progress, a find-activity indicator spins next to the Find button. You might see results before the search is complete. The indicator disappears when the search is complete.
7 In the Results pane, review the results of the search.

The default sort order is by component name, if component name is one of the columns you choose to display. If component name is not chosen for display, the default sort order is creation date and time. 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. For each user, the last-used settings are saved and reapplied at the next logon session.
8 (optional) In the results pane, select one of the instances and take any of the
following actions:
s s
To place objects in a new View window, click Open in New View. To place objects in the active View window, drag the instances into the View window or select them and click Place in Selected View.
91
When you move one instance into a View, if the object already exists in that View window, the Duplicate Component dialog box opens. To shift the View focus so that you can see the existing object, click Go to Component. If you select more than one component instance to move into view, the Go to
Component button is not available.
s
To view the characteristics of a selected component instance, click Show Properties.
9 (optional) To start another search, click Reset to clear all the selection criteria
options on the Find tab to the default values (blank component name field, All Components, no results in table).
Using the Advanced Find feature

On the Advanced Find tab, you can refine a search based on additional search criteria listed in Table 20 on page 93. For example, in Figure 8, the search will locate objects assigned to the specified cell with a publish date within the past year. Figure 8 Advanced Find dialog box
92
Table 20 describes the additional search criteria available in Advanced Find. Table 20
Look in
Description of additional search criteria

Options Sandbox and Production Selects based on components that are in either sandbox or production (promoted and published) Views components that have been promoted and published and are now in production components that have been assigned to a test cell any component type the specific component type selected from the list any service impact cell the specific cell name selected from the list the date range during which the component instance was last changed the date range during which the component instance was created the user ID who last changed the component instance properties
Search criteria
Production Only
Test Only Component Type All list of component types (classes) Cell All Specific cell names Date Last Edited Date
Last Created Date
User
Last Editor
Creator
the login ID of the user who created the component instance
Using the Conditional Find feature

With Conditional Find you can create a custom selection criteria phrase to select the component instances that cannot be located using Find or Advanced Find.
93
Figure 9
Using Conditional Find
In the Query Builder area, you define the attributes and specific values on which you want to base the search.
NOTE
When you search on the Aliases attribute, you must use LIKE as the relational operator, because if the component instance has more than one alias, the values are stored as a string, (for example: [dcsrvstore2.cvom, dcsrvstore3.com]).
94
To build selection criteria phrases 1 (optional) If needed, in the first list box in Query Builder, select the beginning
parenthesis. If the statement requires multiple selection criteria phrases, you might need the beginning and ending parentheses to define precedence. For example, you need the parentheses for a statement like
(phrase1 OR phrase2) AND phrase3
2 In the Select list box, select a component instance attribute.

As you build the statement, it is displayed in the Query Display area.
3 In the relational operator list box, select one from those defined in Table 21.
Table 21
= != < > <= >= LIKE
Definition of relational operators

Definition equal to not equal to less than greater than less than or equal to greater than or equal to similar to
Relational operators
4 In the text box, enter the specific value that must be contained in the attribute.
The relational operator describes the relationship between the value in the attribute from step 2 and the value you specify in step 4.
5 (optional) To create multiple selection criteria phrases, add lines as needed by

clicking Add Line. If you have more than one selection criteria line, in the first list box on the subsequent line, select the appropriate Boolean operator:
s s
And means both conditions must be met. Or means either condition must be met for the component instance to be selected.
6 (optional) If needed, in the last list box for any selection criteria phrase, select the
ending parenthesis.
95
Defining relationships between component instances
7 (optional) To delete lines, click the Delete Line button that is directly under the line
you want to delete.
8 To start the search, click Find. TIP

To save the search statement for reusing later, click Add to Saved Finds.
Using smart select

With smart select, you can choose to select only component instances in the current view which match the attributes you specify. The smart select attributes include
s s s s s s s
In Model (any view) Out of Model (any view) New (sandbox view) Edited (sandbox view) Production Components (sandbox view) Components With No Cell (any view) Components With Cell but Out of Model (any view)
To use smart select 1 With a View open, choose Edit=>Select. 2 Click on the appropriate attributes to select.
The component instances which match the specified attributes are selected.
Defining relationships between component instances

Impact relationships define how status propagation is passed from the provider component instance to the consumer component instance. An active relationship is an impact relationship and indicates that the status of the consumer instance 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.
96
Creating a component relationship in BMC Impact Service Model Editor
Whenever the status of the provider instance changes, it is propagated to the connected consumer component instance. For each component instance for which you are creating relationships, you must know
s s s
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. See Associating events with a component instance on page 104.

You can create consumer/provider relationships for components in BMC Impact Service Model Editor by
s s
drawing lines between components in the View window using the Create Relationship command
TIP
When you place components in a View, place them such that provider components are below consumer components.
To create a relationship by using draw mode 1 In the View window, on the toolbar, click
.
The default relationship direction is from provider to consumer. If necessary, you can change it to consumer to provider by clicking on the arrow next to the tool. In draw mode, the cursor changes to .
2 Draw a relationship line from provider to consumer by clicking at the top of the
provider component and moving to the bottom of the consumer component, and then click again.
TIP
To delete a graphic line that you have started and do not want to complete, press Esc.
97
3 On the toolbar, click Selection

drew.
and right-click on the relationship line you just

To specify other impact relationship attributes, see To specify other impact relationship attributes on page 100. To learn about creating relationships using the commands, continue with the next section.
To create relationships by using menu commands 1 In a View with component instances that need relationships defined, take one of
the following actions:
s s s
On the toolbar, click Create a new Relationship . From the menu bar, choose Edit => Create Relationship. In a View window, right-click on a component, and choose Create Relationship.
2 In the Create Relationship Properties dialog box, in the Consumer List area, click
Add.
98
Figure 10
Create Relationship dialog box
3 In the Find window, locate the component instances that function as the consumer
in an impact relationship. For information about the Find command, see Finding component instances on page 89. You can add more than one component instance (using basic Windows selection) to either the Consumer List box or the Provider List box.
4 In the Provider List area, click Add. 5 In the Find window, locate and choose the component instance that functions as
the provider in the impact relationship. If there are multiple component instances in the Consumer List, you can add only one provider component instance; the one that is the provider for each of the component instances in the consumer list.
99
WARNING
Avoid creating circular relationships in which an component instance can propagate events to itself. For example: instance 1 > instance 2 > instance 1 again. Publishing will fail if loops (circular relationships) are created within the service model.
6 (optional) To switch the contents of the two lists (make the consumer the provider
and vice versa), click Swap List Contents.

To specify other impact relationship attributes, see To specify other impact relationship attributes on page 100.
To specify other impact relationship attributes 1 On the toolbar, select Selection

and right-click on a relationship line.
2 Choose Edit Relationship Properties. 3 In the Edit Relationship Properties dialog box, for the Activity options, select Active
or Inactive.
s
Activethe status of the provider component instance is propagated to the
consumer component instance. Inactivethe status of the provider component instance is not propagated to the consumer component instance.
4 In the Relationship Policy list, select one of the pre-defined status propagation
models:
s
Directthe status of the consumer component instance may be identical to that
of its provider component instance, depending on the events directly affecting the consumers status, which is also taken into account. Decreasingthe status of the consumer component instance is less critical than that of the provider component instance by one level. For example, if the provider status is WARNING, the consumer status is INFO. Increasingthe status of the consumer component instance becomes more critical than that of its provider component instance by one level. For example, if the provider status is WARNING, the consumer status is MINOR.
NOTE
BMC Impact Service Model Editor verifies that the impact relationship is associated with a valid status propagation model.
100
Assigning related component instances to cells
5 In the Status Weight box, accept the default value or enter a number for the
consumer object. (Status weight is used in the WEIGHTED_CLUSTER status computation model.)
6 (optional) In the Description box, enter an explanation of the relationship that is

meaningful to your enterprise.
7 Click OK. WARNING

If you attempt to create a relationship between two components that already have a relationship between them, BMC Impact Service Model Editor displays an error message. Even if the original impact relationship was created outside of BMC Impact Service Model Editor, for example, through BMC Topology Discovery, BMC Impact Service Model Editor detects it.
Figure 11 shows an example sandbox View after some relationships were created. Figure 11 Drawing relationships
Assigning related component instances to cells

After you have grouped your related component instances of the service model and determined on which cells to publish them, you are ready to assign the related components to the specified cells.
Chapter 5
101
Updating relationships
First, identify the target cells that share component relationships. Next, in the cells that share relationships, make entries in each mcell.dir file to identify the other related cells. For example, you intend to publish different component instances of your model across five different cells (1, 2, 3, 4, and 5), but only three cells (1, 3, 5) share a relationship. The mcell.dir file of cell 1 should have entries identifying cells 3 and 5; the mcell.dir file of cell 3 should have entries identifying cells 1 and 5; and the mcell.dir file of cell should have entries identifying cells 1 and 3.
To assign related component instances to cells 1 In an active View window, select one or more of the component instances and do
one of the following:
s s
Right-click and choose Edit Component Properties. From the menu bar, choose Edit => Edit Component Properties.
The General tab of the Edit Component Properties dialog box displays the corresponding component type in the component type hierarchy. The component instance name is displayed in the Component Name box. If you chose more than one component instance, the Edit Multiple Component Properties dialog box is displayed.
2 In the Edit Component Properties dialog box (or Edit Multiple Component
Properties dialog box), in the Cell box, select the cell to which you want to publish the components.
3 To assign other related components to a different cell, select them in the View
window, and repeat steps 1 and 2.

To continue with the creation of a service model, see Associating events with a component instance on page 104. To learn about updating and deleting relationships, continue with the next section.
Updating relationships
You can change the properties for an existing relationship, but you cannot add or delete the consumer or provider instances, nor can you swap the consumer and provider nodes.
102
Deleting relationships
To edit one or more impact relationships 1 In the View window, do one of the following:
s
Select one or more relationship graph lines, right-click and choose Edit Relationship Properties. Select one or more relationship graph lines and from the menu bar, choose Edit => Edit Relationship Properties from the menu bar. Select one or more the relationship graph lines, set the focus on the Properties window, and click Edit.
If more than one relationship is selected, all are listed in the Edit Multiple
Relationship Properties window.
2 Enter a new value in the Activity, Relationship Policy, Status Weight, and/or
Description boxes.
If more than one relationship was selected:

s
for each of the boxes, values are filled in if they are the same for all relationships listed; if even one relationship has a different value in a property box, the box is blank the changes you make are applied to all relationships listed in the Edit Multiple Relationship Properties dialog box
For more information about the properties, see To specify other impact relationship attributes on page 100.
TIP
You can select multiple components and multiple relationships and then open the Edit Relationship Properties dialog box.
Deleting relationships
When you delete a relationship, the component instances remain in the service model. The relationship is recorded as to be deleted in the user sandbox and it is immediately removed from the SME View. However, prior to promoting the change, if you activate the Show/Hide Deleted Components toggle button in the toolbar, the deleted relationship can be seen in the View if you re-expand the graph. Relationships that are to be deleted are, by default, rendered in red, though this option can be changed in the Personal Options dialog.
Chapter 5
103
Associating events with a component instance
When a component is deleted, all relationships referencing the component (provider and consumer) are automatically deleted to maintain the consistency of the service model.
To delete a relationship 1 In the View window, select the relationship line that you want to delete and do one
of the following:
s s
Right-click and choose Delete from CMDB. From the menu bar, choose Edit => Delete from CMDB.
2 In the confirmation window, verify that you are deleting the intended object, and
click OK.
3 Select File=>Promote All Sandbox Changes to remove the relationship from the
production model.

When an event is received by a cell, its event alias slot is checked for a value. If this value does not exist, the cell uses an alias association formula to construct an alias. The constructed alias must match the value you entered in the Alias box on the Status and Alias tab in the Create (or Edit) Component Properties dialog box. This section describes how to create the formula. For more information about event alias association, see Event associations on page 58.
WARNING
s
Only one promotion can be processed at a time. If you submit a promotion while a previous promotion is being processed, the second promotion will not start until the second one is complete. Event class definitions must be the same in all SIM cells. If you add custom event classes, you must manually modify the KB of each cell, recompile the KB, and then restart each cell.
To create an event alias association 1 From the menu bar, choose Tools =>Alias Formulas. 2 In the Event Alias Associations dialog box, click Add.
The list of existing alias event associations displays. To sort either column, click in the column heading.
104
3 In the Edit Event Alias Associations dialog box, in the Name box, enter a name for
the event association. Figure 12 Creating an alias association
4 In the Event Match Criteria area, in the Event Class box, select an event class from the
list. BMC Impact Service Model Editor looks at the first available cell and uses its event classes in the list. When an event comes in, its event class has to match the event class or a subclass of the event class before the alias formula is even considered.
5 (optional) In the Match Attributes box, choose attributes and enter values to refine
which events (within the event class) will generate aliases.
Chapter 5
105
Figure 13
Defining the events to be processed by the alias formula
For each attribute you choose, select one of the conditional operators, as described in Table 22, and enter a value in the text box to further define the events that are used to generate aliases using this formula. Table 22
Conditional operators anything
Description of conditional operators

Description the attribute can contain any value and is not used as a selection criteria If every attribute listed has anything that means that every incoming event that belongs to the event class will pass through alias formula processing
contains has prefix has suffix equals
the characters you enter in the text box occur someplace in the value the value starts with the characters you enter in the text box the value ends with the characters you enter in the text box the value exactly matches the characters you enter in the text box
If you use more than one attribute, each condition must test true (the Boolean operator between the selection criteria phrases is AND) before the alias formula process is performed. For example, in Figure 14 on page 107, the search phrase would read: Hostname contains SALLOG and IP address equals 555.22.19.105. Both conditions must be true for the event to be selected for alias processing.
106
Figure 14
Example of match attributes
6 In the Alias Formula area, use the Attribute, Text, and Function buttons in any order
and as many times as needed to build the formula:
A To insert an attribute in the formula, click the Attribute button. The attributes
shown are those that belong to the event class you selected in the Event Definition area. When an attribute is selected, the control shows the attribute name, and the preview area is updated to show the syntax of the formula as it currently exists.
TIP
If your formula for a component instance (CI) contains the mc_host slot with a host name value, then the mc_host slot of the matching event definition should also contain the host name value, not the IP address, of the CI. For example, if you assign the mc_host slot in your formula the value mycomputer.abc.com, then the mc_host slot of the incoming event should contain the same host name value, not the IP address. You can check with your system administrator for the correct Domain Name System (DNS) resolution if the object represented by the component instance experiences host name resolution errors.
B To insert literal text (for example, a period, semi-colon, the word Oracle), click
on the Text button. In the text box, type the literal text that you want in the alias formula. Literal text appears in the first part of the alias formula with data type definitions.
C To insert a function that defines the data type and an expression in the formula,
click on the Function button. Type the function and choose the data type. For a list of functions you can use, see BMC Impact Solutions: Knowledge Base Development.
Chapter 5
107
D (optional) To change the order of the elements in the alias formula, select the part
of the formula you want to move and click the Move arrow button as appropriate.
E (optional) To delete one of the elements in the alias formula, select the part of the
formula you want to delete and click the Delete button.
7 When the alias formula is complete, click Save. Where to go from here
To continue with the creation of a service model, see Promoting the service model on page 121. To learn about editing and deleting an event alias association, and adding an alias to a component instance, continue with the next section.
To edit an event alias formula 1 Choose Tools => Alias Formulas. 2 In the Event Alias Associations dialog box, select an existing alias computing
formula.
3 Click Edit. 4 In the Edit Event Alias Association dialog box, make changes as needed.
For details about each field, see To create an event alias association starting with step 4 on page 105.
5 When your changes are complete, click OK. To delete an event alias formula 1 Choose Tools =>Alias Formulas. 2 In the Event Alias Associations dialog box, select an existing alias computing
formula.
3 Click Delete.
108
Working with timeframes and service schedules
To add an alias to a component instance 1 In an active View window, select a component instance and either
s s
right-click the component instance and choose Edit Component Properties choose Edit => Edit Component Properties from the menu bar.
2 On the Status and Alias tab, click Add Alias. 3 In the Input box, enter the alias name and click OK.
Each alias you enter is listed in the Aliases box.
4 (optional) Enter additional aliases (one for each event that can potentially affect the
status of the component instance).
5 (optional) To edit an alias name, in the Aliases box, select the alias and click Edit. 6 (optional) To delete an alias, in the Aliases box, select the alias and click Delete. 7 Click OK.
Edits on this tab are not saved to the BMC Atrium CMDB until you click OK.
TIP
To search for the component instances that use a specific alias, use the Conditional Find tab in the Find dockable window. One of the attributes available in the Select list box is Aliases. You must use LIKE as the relational operator.

To learn about creating service schedules and assigning components to service schedules, continue with the next section.
Working with timeframes and service schedules

You edit service schedules using the Schedules Editor function of BMC Impact Service Model Editor. Schedule information is stored in the BMC Atrium CMDB and can be viewed in BMC Impact Portal and BMC IX. If a schedule is not selected for a component, the component will have a default schedule of 24 x 7 x 365 (always in schedule).
Chapter 5 Building a service model in BMC Impact Service Model Editor 109
Icons used in the service schedule and timeframes editors
After service schedules are created, you can assign components to schedules in the Edit Component Properties dialog box as described in Assigning components to service schedules on page 117. Full Access, Service Administrators, and Service Managers user groups have access to the schedule editor.
Icons used in the service schedule and timeframes editors

Table 23 contains descriptions of the functions of icons used in the service schedule and timeframe editors. Table 23
Icon
Service schedule and timeframes editors icons

Function Edit the selected service schedule or timeframe
Create a new service schedule or timeframe
Copy of the selected service schedule or timeframe
Show Usages of components assigned to the selected service schedule or timeframe. Opens the Timeframe - Components and Schedule dialog box, which lists the components and schedules currently associated with the timeframe. If you are creating a new timeframe, these lists will not contain any components or schedules. Delete the selected service schedule or timeframe
Working with timeframes

Service schedules are built from timeframes, which can be created and edited using the Timeframe Edit dialog box of BMC Impact Service Model Editor as shown in Figure 15.
110
Figure 15
Timeframe Edit dialog box
Table 24 provides descriptions of the fields in the Timeframe Edit dialog box. Table 24
Name Description Usages (button)
Timeframe Edit field descriptions (part 1 of 2)

Name of the timeframe Description of the timeframe Opens the Timeframe - Components and Schedule dialog box, which lists the components and schedules currently associated with the timeframe. If you are creating a new timeframe, these lists will not contain any components or schedules. Period when the timeframe begins and ends, and the duration of the timeframe. Changing the duration will change the value in the End field, and vice-versa. The individual time zone of each components BMC Impact Manager will be used in timeframe calculations.
Start, End, and Duration
Chapter 5
111
Table 24
Timeframe Edit field descriptions (part 2 of 2)

Defines the frequency in which the timeframe recurs. Changing the selection in the left side list changes the options available on the right side. 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 starting and ending date range for the recurrence. Optionally, instead of choosing an end date, you can enter the number of recurrences for the timeframe.
To create or edit a timeframe 1 From the menu bar, choose Tools => Edit Schedules. 2 In the Schedules Editor 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 Timeframe Edit dialog box, enter or modify the appropriate information in
the fields available in the Timeframe Edit dialog box. For more information about the Timeframe Edit dialog box, see Table 24, Timeframe Edit field descriptions, on page 111.
4 Click Save to save the timeframe and make it available for use in the Schedules
Editor.
To copy a timeframe 1 From the menu bar, choose Tools => Edit Schedules. 2 In the Schedules Editor dialog box, on the Timeframes tab, select a timeframe to
copy.
3 Click the Copy icon. 4 In the Timeframe Edit 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 Timeframe Edit dialog box, see Table 24, Timeframe Edit field descriptions, on page 111.
5 Click Save.
112
Working with service schedules
To list the service schedules and components that are associated with a timeframe 1 From the menu bar, choose Tools => Edit Schedules. 2 In the Schedules Editor dialog box, on the Timeframes tab, select a timeframe. 3 Click the Show Usages icon.
In the Timeframe - Components and Schedule dialog box is 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 From the menu bar, choose Tools => Edit Schedules. 2 In the Schedules Editor dialog box, select one or more timeframes from the list of
timeframes.
3 On the Schedules tab, click the Delete icon.

To view the schedules that make use of a given timeframe, on the Timeframes tab of the Schedules Editor dialog box, click Show Usages. See To list the service schedules and components that are associated with a timeframe on page 113.
4 Click Delete.

You create and modify service schedules in the BMC Impact Service Model Editor Schedule Edit dialog box as shown Figure 16.
Chapter 5
113
Figure 16
Schedule Edit dialog box
To create or edit a service schedule 1 From the menu bar, choose Tools => Edit Schedules. 2 In the Schedules Editor 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 Schedules Edit dialog box, enter or modify the appropriate information in
the fields, as shown in Table 25. Table 25 Schedule Edit field descriptions
Name of the service schedule being created or edited Description of the service schedule Opens the Schedules - Components Assigned to this Schedule dialog box, which lists the components and component descriptions currently associated with the selected schedule.
Schedule name Description Usages (button)
114
Table 25
Schedule Edit field descriptions

Information on what timeframes are part of the service schedule, what timeframes are Exceptions Within During Schedule, and what timeframes are available. Any time period that is not part of a service schedule is considered Off Schedule. Available Timeframes, the center panel, contains the timeframes that are available to be added to the During Schedule and Exceptions Within During Schedule periods. During Schedule Timeframes, the left panel, contains the timeframes during which the associated components exists in the service schedule period (as opposed to being Off Schedule). Add or remove timeframes from the list by using the arrows between During Schedule Timeframes and Available Timeframes. Exceptions Within During Schedule, the right panel, contains the timeframes during which the associated components are treated as Off Schedule even though the time exists within the During Schedule period.
Timeframes in this schedule
Timeframe details
Opens the Timeframe Details dialog box listing the times, dates, and recurrence periods of the selected timeframe.
4 Click Save. To copy a service schedule 1 From the menu bar, choose Tools => Edit Schedules. 2 In the Schedules Editor dialog box, on the Schedules tab, select a service schedule
from the list.
3 Click the Copy icon. 4 In the Schedule Edit dialog box, modify the fields for the copied service schedule
as appropriate. For more information about the Timeframe Edit dialog box, see Table 25, Schedule Edit field descriptions, on page 114.
5 Click Save.
Chapter 5
115
To display the component instances that are associated with a service schedule 1 From the menu bar, choose Tools => Edit Schedules. 2 In the Schedules Editor dialog box, on the Schedules tab, select a service schedule
from the list.
3 Click the Show Usages icon.

In the Timeframe - Components and Schedule dialog box is a list of the components and schedules currently associated with the timeframe. 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 From the menu bar, choose Tools => Edit Schedules. 2 In the Schedules Editor dialog box, on the Schedules tab, select one or more service
schedules from the list.
3 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 current default schedule. To view the component instances that are associated with a given service schedule, on the Schedules tab of the Schedules Editor dialog box, click Show Usages. See To display the component instances that are associated with a service schedule on page 116.
4 Click Delete. Where to go from here

After you create service schedules, you assign components to the schedules. See Assigning components to service schedules on page 117.
116
Assigning components to service schedules
Assigning components to service schedules

You can assign one or more components to service schedules by launching the Schedules Editor from the Edit Component Properties dialog box, Schedule tab, as shown in Figure 17. Figure 17 Schedules Editor section of Edit Component Properties dialog box
To assign components to service schedules 1 Select one or more components in the active View to which you want to assign to a
service schedule.
2 Choose Edit=>Edit Component Properties. 3 On the Schedule tab, in the Schedule pane, click Select.
The Select a Schedule dialog box contains the During Schedule and Exceptions Within During Schedule timeframes. By default, components are assigned the always-in-During Service schedule (24 x 7 x 365). To choose a schedule for the components, select the schedule from the Schedules pane and click OK. To edit an schedule, select a schedule and click Edit to display the Schedules Editor. For more information about editing schedules see To create or edit a service schedule on page 114. To view what component instances are using the selected schedule, click Usages. To view the details of what times and dates are specified in a selected timeframe, click Timeframe Details.
Chapter 5
117
Granting access to service model objects
4 Click OK.
Granting access to service model objects

You define and maintain BMC Impact Service Model Editor user groups and permissions in the BMC Impact Portal. To modify user group permissions, go to the BMC Impact Portal, open the Configure tab, and under Tasks, select User Groups. To add users to these user groups, go to the BMC Impact Portal, open the Configure tab, and under Tasks, select Users. For more information, see BMC Portal Getting Started. Table 26 describes default BMC Impact Service Model Editor user groups and their corresponding rights. Table 26
User role Service Administrators, Service Executives, Service Managers - Senior
Default user groups and rights for BMC Impact Service Model Editor
Rights
s s s s s s
save View create/edit component and relationship instances publish service models view publication history reinitialize to a cell import and export service model data save View create/edit component and relationship instances view publication history read only
Service Managers
s s s
Service Operators - Senior Service Operators
Granting permissions to individual service model objects

By default, BMC Impact Service Model Editor user groups that have permissions to create and edit component and relationship instances are: Service Administrator, Service Manager - Senior, and Service Manager. You can override these default permissions for individual component instances.
118
Granting permissions to individual service model objects
To grant permissions to individual component instances 1 With the component instance in an open View, select the component and do one of
the following:
s s
Right-click and choose Edit Component Properties From the menu bar, choose Edit => Edit Component Properties.
2 In the Edit Component Properties dialog box, on the Permissions tab, select the
appropriate options. Figure 18 Changing access for an individual component instance
User groups with Unassigned selected do not see the object.
3 Click OK. NOTE

When you modify user access permissions in the BMC Impact Service Model Editor, they are effective immediately in BMC Impact Service Model Editor. For the changes to appear in Impact Portal, they must be promoted from BMC Impact Service Model Editor and you must then log out and then log on to Impact Portal. For permissions at the CI (component) level, you need not log out and log into the Portal portal for the permissions to take effect.
Chapter 5
119
Testing the service model
Testing the service model

Before promoting and publishing the components in your sandbox service model, you may test them by sending the component instances and relationships to a test cell that you have previously created specifically for the purposes of testing. BMC Impact Service Model Editor users having the correct permissions (set up in the BMC Portal) have their own individual test environments. From the BMC Impact Service Model Editor, you can send component, relationship, and management data to a cell that has been previously created exclusively for testing by using the Send to Test option on the File menu. (if the relationship View option is set to show non-impact relationships, the Send to Test option is not available.) You can send the sandbox service model to a test cell before promoting it into the production environment. After the test is initiated, the following events occur:
s s
existing data in the test environment is cleared components and relationships, including production components, as well as those in the sandbox, are sent to the test environment. Management data is also sent. if no impact relationships are visible in the selected view, or if components exist which are not part of an impact relationship, a dialog box is displayed warning the user that the test components being sent do not have impact relationships
Testing component relationships

After you have set up a relationship, you can test it by posting events against the provider component in the relationship and observe the resulting status of the consumer component in the relationship.
Testing event associations

After you have set up event alias associations, in the component instance and by creating an alias formula, you need to verify that the association occurs correctly. In the BMC Impact Explorer console, open the Events tab. When an incoming event is associated with a component instance, the mc_smc_type and mc_smc_id slots will have values. If the slots are empty, the event is not associated. In the BMC Impact Service Model Editor, check the component alias and the event alias formula.
120
Promoting the service model
To send components to a test cell 1 Choose File => Send to Test Objects in Current View.
If there are no impact relationships for the components in the current View, a warning dialog box is displayed. Choose Yes to continue, or No to stop. If there are no test cells available in the current environment, an error dialog box is displayed and the process is stopped. If the send to test is successful, a dialog box is displayed indicating that the test dataset has been populated. Management data is copied automatically to the test environment.
2 Close the dialog box.
Promoting the service model

After promoting component instances in BMC Impact Service Model Editor, 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. When you service model data is successfully to the cells, the BMC Impact Publishing Server updates the BMC.IMPACT.PROD dataset, which mirrors the last successful publish to the cells.
About the publishing process

Promotion and publishing are decoupled. Promotion is initiated and controlled from BMC Impact Service Model Editor, while publication is controlled by BMC Impact Publishing Server. There are two modes of running the BMC Impact Publishing Server.
s
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. For more details about automated publishing, see Chapter 9, Managing BMC Impact Publishing Server.
Chapter 5
121
Before you promote
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 Impact Manager cells. The objects in BMC.ASSET are compared to any previously published instance in BMC.IMPACT.PROD and the changes between them are sent to the cell. BMC.IMPACT.PROD is then updated with the changes. After events that affect service component instances are received by the cell, you can monitor status changes using BMC Impact Explorer or BMC Portal for the published component instances.
Before you promote

To ensure a successful promotion and publication of the service model, verify that:
s s
s s
each component instance is assigned to a cell all target cells that are registered in the BMC Impact Portal are running and have a live connection with the BMC Impact Publishing Server event types are associated with component instances the BMC Impact Publishing Server is running in automated mode by using the CLI command psstat. This command should return Started - Automated mode. your user account belongs to one of these user groups: Service Administrator, Service Manager, or Service Manager - Senior (these are the default user group assignments; you may change them in the BMC Impact Portal) the SIM class definitions are in sync. The BMC Impact Publishing Server validates the class definitions and establishes a live connection with BMC Impact Portal, the BMC Atrium CMDB, and the cells before submitting the publication.
Submitting a promotion
When you submit a promotion, the Promotion Preview dialog box offers the opportunity to compare your unpromoted sandbox service model component instances 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 Begin Promotion, service model objects (component instances, impact relationships, and management data) shown in the preview are promoted (and subsequently automatically published).
Before you begin

Verify the items listed in the section Before you promote on page 122.
122
To promote all sandbox component instances and relationships 1 Start the promotion by doing one of the following:
s s s
On the toolbar, click Promote . From the menu bar, choose File => Promote All Sandbox Changes. In a View window, right-click and choose Promote All Sandbox Changes.
TIP
If promote service model options are unavailable, you may not have the permissions to promote component instances. For information on configuring user rights, see BMC Portal Getting Started.
2 In the Promotion Preview dialog box, in the Objects to be Promoted area, choose
how you want to filter the list of objects that you see. When you filter the list, it only affects what is visible, not what will be promoted. All items will be promoted. In the first Show list, choose All, Components, Relationships, Components and Relationships, or Management Data. In the second Show list, choose All Actions, New Objects, Changed Objects, or Deleted Objects. The component instances and relationships to be promoted are listed in the left pane.
3 In the results pane, review the list of objects.

The default sort order of objects is by Action, then Type (component or relationship), and then by Object Name. To change the sort order, click in the column heading. The icons in the Action and Type columns are defined in Table 27. The icons in the Class column match the icons associated with the component type in the Templates dockable window. Table 27
Action
Icons in Objects-to-be-Published pane

Icon Description object was deleted object was added object was modified
Column heading
Chapter 5
123
Table 27
Type
Icons in Objects-to-be-Published pane

Icon Description component relationship timeframe or service schedule
Column heading
4 In the Comparison of Sandbox and Promoted Property Values area, for the Show
options, select Changed Properties or All Properties for the component instances you selected in the Objects to be Promoted pane.
5 Select one or more objects in the left pane and, in the right pane, compare the new
and previously published property values to verify that the new data is correct before you publish it.
TIP
s
To hide either the Objects to be Promoted pane or the Comparison of New and Promoted Property Values pane, click on the quick expansion arrows (tiny black arrows) between the panes. You can compare published and newly created, changed, or deleted component instances independently of the publication process by choosing Tools => Compare Sandbox to Production.
6 Click Begin Promotion.

The Promotion in Progress dialog box is displayed, along with the elapsed time since the promotion was started. Even if BMC Impact Service Model Editor is shut down and restarted, the elapsed time will reflect the total time since the promotion was originally started.
7 (optional) To stop the promotion, in the Promotion in Progress dialog box, click
Stop.
Closing the dialog box does not stop the promotion; the promotion continues in the background.
8 (optional) To exit BMC Impact Service Model Editor, click Exit SME, then click the
appropriate selection on the confirmation dialog box.
9 A status message indicates the success or failure of the promotion request.
124
Verifying promotion status
If the promotion and subsequent automated publication processes are successful, the service model is available to the specified cells and you can monitor the component instances in BMC Impact Portal and in BMC Impact Explorer. For troubleshooting information, see Initial source parameters on page 245.

To learn about verifying promotion status, continue with the next section.
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. After the promotion process completes, a dialog box will display indicating whether the promotion succeeded or failed. If the promotion fails, the Promotion Status dialog box declares a promotion failure along with the error, a timestamp, and the user name of the submitter. Click OK to dismiss the dialog box. Note that a publication success or failure is not shown in the dialog box, but can be viewed in the Promote and Publish History dialog box (Tools => Promote and Publish History) or using the plog requestID | plogdisplay -@ commands. For more information about CLI commands, see Appendix 10, Chapter Contents.
Chapter 5
125
Working with publication logs

This section contains general guidelines to remember when working with publication logs.
s
After you submit a promotion request, the Promotion in Progress dialog box opens automatically, enabling you to monitor the progress of the promotion request. However, promotion results dialogs only report success or failure of a promotion and do not offer information about publication status. More detailed information about each publication is available in BMC Impact Publishing Server log files. A log exists for every publish request containing detailed information as to why publication failed and can be consulted to diagnose a publication failure. All publish logs are available in BMC Impact Service Model Editor's publish history. Publish logs can also be retrieved via the CLI command plog -s <requestId> | plogdisplay -@ (see plogObtaining the XML log for a request on page 304). It is recommended that you give every promotion a unique description because promotion descriptions are found in the publication log and will make locating each publish easier. Another way to find the correct publication in the log is to use the promotion id. BMC Impact Publishing Server includes detailed messages from the different components (such as BMC Impact Portal, BMC Atrium CMDB, and BMC Impact Managers) it communicates with. To understand and troubleshoot these messages, consult the documentation of those components.
Viewing promotion and publication history

At any time, you can use the Promote and Publish History command in BMC Impact Service Model Editor to review previous promotion and publication information, including failures. The Promote and Publish History command displays the status and date and time of requests. Information in the Publication errors section of the Publish tab can help you troubleshoot publication failures.
To view promotion history 1 From the menu bar, choose Tools => Promote and Publish History. 2 To view promotion details, select the Promotion tab, then select the promotion for
which you want to see details in the Promote History table area. The list of recent promotions is in reverse chronological order, that is, the most recent is listed first.
126
To view publication history 1 From the menu bar, choose Tools => Promote and Publish History. 2 To view publication details, select the Publish tab, then select the publication for
which you want to see details in the Publication History table area. The list of recent publications is in reverse chronological order, that is, the most recent is listed first.
Viewing publication history details

This section contains information on viewing publication history details.
To view publication history details 1 From the menu bar, choose Tools => Promote and Publish History.
The list of recent publications is in reverse chronological order, that is, the most recent is listed first. By default, 100 publication log files are saved; when the 101st log is saved, the first log is deleted. All BMC Impact Publishing Server requests are counted (not only publish and initialization, but also classinfo (for example, export) requests). You can change the RequestHistorySize parameter in pserver.conf to modify the default number of logs saved.
2 To view publication details, select the Publication tab, then select the publication
for which you want to see details in the Publication History table area.
A On the Publication Details tab, review the detailed information for the
publication you selected. Failures are displayed in red. If the failure is the result of a particular component instance, the component type and component name are included. To open a View with the component instance, select the failure and click Open in New View.
B On the Publication Errors tab (available only if there were failures associated
with the selected publication), review the failure information. You can sort on any column and, if the column width limit truncates the text, the tooltip displays the complete text string.
C In the Recommended Action area, review the action to correct the problem with
publish.
Chapter 5
127
Organizing service component instances for monitoring
NOTE
You can replace the action recommended by BMC Software, add to it, or modify it by editing the pslog_error_solutions.properties file located in the BMC_PORTAL_KIT_HOME\appserver\websdk\tools\jboss\server\all\conf\resourc es\en_US\smsConsoleServer directory on the server running BMC Portal.
3 To close the dialog box, click Close.

Before you can monitor service model component instances that are in production (have been published) in the BMC Impact Portal and the BMC Impact Explorer, you must populate the console navigation tree in BMC Impact Service Model Editor. The Console Navigation Tree dockable window provides a flexible way of organizing your service component instances under folders that you create. The tree that you create in BMC Impact Service Model Editor is visible in BMC Impact Portal, on the Configure tab, under Properties and in BMC Impact Explorer, from the Services View, the Services Group tab. The top-level folder of the hierarchical directory is userAccount/Business, with userAccount representing the active BMC Impact Portal user account name. You create subfolders that meet the service monitoring requirements for your enterprise. Changes that are made to published service model component instances in the console navigation tree are immediately reflected in the BMC Impact Portal. To see changes that you made in BMC Impact Service Model Editor to a console navigation tree in BMC Impact Explorer, you must exit Impact Explorer and log in again. If you still cannot see changes, they have probably not been published.
To add a folder to the console navigation tree 1 In the Console Navigation Tree dockable window, navigate to and select the folder
under which you want to create a folders. All service component folders must be created under the userAccount/Business folder (which cannot be edited or renamed). The way you organize the folders and component instances is entirely dependent on your enterprise and the way you want to monitor the component instances in BMC Impact Portal and BMC Impact Explorer.
128
2 In the Console Navigation Tree toolbar, click Create Folder
3 In the Create New Folder dialog box, in the text box, enter the folder name. 4 Specify the permission levels for the appropriate user groups. These permissions
settings enable users to see the folder and its contents in BMC Impact Portal and BMC Impact Explorer.
5 Click OK. To rename folders 1 In the Console Navigation Tree dockable window, expand the Business folder
under the userAccount folder.
2 Select the folder you want to rename. NOTE

You can rename group folders, but you cannot rename component instances from the console navigation tree; you can rename them in a View.
3 On the Console Navigation Tree toolbar, click Rename Selected Folder 4 In the Rename Folder dialog box, enter the new name. 5 Click OK. To move a folder and its component instances
1 In the Console Navigation Tree dockable window, expand the Business folder
2 Select the folder or component instance that you want to move to another folder.
You can only move those component instances which exist directly under a folder. Components which appear as providers to other component instances in the console navigation tree cannot be moved (that would be editing the model).
3 Drag the object to the new location.
Chapter 5
129
To copy folders 1 In the Console Navigation Tree dockable window, expand the Business folder
2 Select the folder or component instance that you want to copy to another folder. 3 Control-drag the object to the new location. To define permissions for folders 1 In the Console Navigation Tree dockable window, navigate to and select the folder
for which you want to define permissions.
2 On the Console Navigation Tree toolbar, click Edit Permissions

user groups.
3 In the Edit Permissions dialog box, specify the permission level for the appropriate 4 Click OK. NOTE
Folder-level permission for the BMC Impact Service Model Editor is controlled by the BMC Portal. This means that if you create a folder in the BMC Impact Service Model Editor and assign specific access control permissions to that folder, the access control permissions from the BMC Portal override the permissions of the BMC Impact Service Model Editor.
To remove a folder or a component 1 In the Console Navigation Tree dockable window, expand the Business folder
2 Select the folder you want to remove. 3 On the Console Navigation Tree toolbar, either click Remove Folders or components
or right-click and choose Remove from the context menu.
4 In the Confirmation box, click Yes.
130
To add a component to the console navigation tree 1 In the Console Navigation Tree dockable window, navigate to and select the folder
under which you want to add component instances.
2 On the Console Navigation Tree toolbar, click Add a Component
3 In the Find window, locate and select the components to add and click Add.
For information on using the Find command, see Finding component instances on page 89. When you click Add, the component instances are automatically saved as part of the console navigation tree. You can also undock the Find window and drag component instances from the Find results pane to the console navigation tree.
4 (optional) Continue adding component instances using the Find command. NOTE
s
When you add a component instance that has providers to a folder, you can drill down and see the providers in the console navigation tree, even if they are not published. To see component instances in the BMC Impact Portal that you see in the console navigation tree, you must publish them. When you expand the tree, BMC Impact Service Model Editor checks the BMC Atrium CMDB to see if there are changes to provider component instances, and if there are changes, the tree is refreshed. These provider component instances are not saved as part of the console navigation tree.
To add a component to the console navigation tree from a View 1 In the Console Navigation Tree dockable window, navigate to and select the folder
under which you want to add component instances.
2 In an open View, select the component instances to add and do one of the
following:
s s
Right-click and choose Add Components to Navigation Tree. On the menu bar, choose Edit => Add Components to Navigation Tree.
Chapter 5
131
Working with BMC Impact Service Model Editor Views
To open component instances in a View 1 In the Console Navigation Tree dockable window, expand the Business folder
2 Locate the component instances you want to open in a View. 3 Select the component instances and do one of the following:
s
To open in a new View, on the Console Navigation Tree toolbar, click

Open the selected components in a new view
To open in the current View, on the Console Navigation Tree toolbar, click
Place the selected components in current view
Right-click on the component instances and choose Open in New View or Place in Selected View.
You cannot move a folder into a View.
To refresh the tree

To query the BMC Atrium CMDB and redisplay the tree with the latest data, including provider component instances, on the toolbar, click Refresh navigation tree.
Working with BMC Impact Service Model Editor Views

Table 28 lists the topics covered in this section with page numbers. Table 28
Topic To save a View To open a saved View To rename a View To delete a View Understanding visual cues in a View Repositioning objects in a View Controlling what you see in a View
Topics covered in this section

Page Number 133 133 134 134 134 135 136
132
Saving, opening, renaming, and deleting Views
Table 28
Topic
Topics covered in this section

Page Number 138 139 140 140
Exploring consumer and provider paths Refreshing the View Repositioning the dockable windows Showing topology views
Saving, opening, renaming, and deleting Views

A View is a window into the service model, whether it exists in a sandbox environment, test environment, or the production environment. It may or may not encompass the entire service model, depending on the size of the service model and how the View is set up. Each View is unique to a user account. Each user can create and save multiple Views and multiple users can have many different Views into the same service model.
To save a View 1 In an open, active View, choose File => Save View. 2 In the View Name box, enter a unique name for the View.
The name of a saved View displays in the title bar of the View.
3 Click OK. To open a saved View 1 In the dockable panes area, click Views. 2 In the list of Views, locate the View you want to open and do one of the following:
s s s
Double-click on the View name. Select the View and click on the View toolbar. Right-click and choose Open View.
When you open a saved View, its component and relationship instances are verified against the definitions in the BMC Atrium CMDB. Depending on the number of objects contained in the View, this process can take some time. If any instance cannot be verified in the BMC Atrium CMDB, the View does not open.
Chapter 5
133
Understanding visual cues in a View
To rename a View 1 In the dockable panes area, click Views. 2 In the list of Views, locate the View you want to rename and do one of the
following:
s s
Select the View and click on the View toolbar. Right-click and choose Rename View.
3 The selected row becomes editable; type a new name and press Enter. To delete a View 1 In the dockable panes area, click Views. 2 In the list of Views, locate the View you want to delete and do one of the following:
s s
Select the View and click on the View toolbar. Right-click and choose Delete View.
NOTE
When you delete a View, it does not affect the service model or the topology view. You are deleting only the View window, not any of the actual component or relationship instances in the BMC Atrium CMDB.
3 In the Confirm View Delete box, verify that you are deleting the correct View and
click Yes.
Understanding visual cues in a View

BMC Impact Service Model Editor is a graphically rich interface. The component types are depicted as unique icons in the Templates dockable window. Additionally, you have the option of defining colors for background, border, line styles. The definitions for the icons in Table 29 can be viewed in the Legend, available by choosing Window => Legend. Table 29 contains visual cues for components in the View.
134
Repositioning objects in a View
Table 29
Visual cue
Visual cues in a View

Icon Description a component instance that is set to In Model displays the In model Component icon
a component instance that is set to Not in Model displays the Not in Model Component icon
a component instance that has been edited is flagged with this icon in the top right corner
a newly-created component instance is flagged with this icon in the top right corner
a component that is set to be deleted becomes semitransparent and is flagged with this icon in the top right corner
outline
a component instance showing the mouseover effect that results as you drag the mouse cursor over the icon
solid background
a selected component instance has a solid background and can be moved, viewed, and edited
Repositioning objects in a View

You can move objects in a View using a variety of methods:
s
To quickly move all the objects in a View, click objects as needed. To layout the objects automatically, click
on the toolbar and move
on the toolbar.
You can also manually move single or multiple objects in a View as described below.
Chapter 5
135
Controlling what you see in a View
To reposition objects manually 1 In an active View, ensure that the mouse cursor is in selection mode
box around the appropriate objects. .
2 Select an object or multiple objects. To select multiple objects as a group, draw a 3 Drag the object to the desired position.

A service model may become quite large and not be entirely visible in the View window. To explore a service model you need to know how to
s s s
adjust the graphical view use pan and zoom to focus on specific areas of the model exploring consumer and provider paths
Table 30 describes each method of adjusting the graphical view. Table 30

Goal automatically align objects
Adjusting the graphical view

Action
s s
Toolbar button
on the toolbar, click Auto-Layout or from the menu bar, choose View => Layout Objects on the toolbar, click Fit to View or from the menu bar, choose View => Fit to View on the toolbar, choose a value in the percentage list or from the menu bar, choose View => Zoom => value Zoom Out on the toolbar, click Zoom Out or Zoom In or from the menu bar, choose View => Zoom In or View => Zoom Out Zoom In
fit all objects in the View window adjust the zoom factor
s s
s s
zoom in or out in predefined percentage intervals
s s
grab and move objects
see To use the pan and zoom tool on page 137.
136
Table 30
Goal
Adjusting the graphical view

Action
s s
Toolbar button
magnify an area of the model
click the magnifier icon to turn on magnifier mode left- or right-click an area of the model to magnify that area. click the topology view icon to turn on the topology view click the Component Table View icon to turn on the component table view click the Show Deleted Components icon click the Show Modifier Icons icon
view the component objects in a topology view view the component objects in component table show or hide deleted components show or hide modifier icons for each component
To use the pan and zoom tool 1 Open a View window. 2 Capture the service model view in a outlined rectangle (panner) by using one of
the following methods:
s s
From the menu bar, choose Window => Pan and Zoom. Click the Pan and Zoom dockable window.
The actions you take in the Pan and Zoom dockable window with the panner rectangle are mirrored on the service model in the View window.
3 (optional) To zoom in, position the cursor over a corner of the panner and reduce
the size of the panner. To zoom out, increase the size of the panner.
4 (optional) To resize or reposition the window, drag the panner. 5 (optional) Set the zoom percentage by adjusting the slider bar at the bottom of the
Pan and Zoom window.
Chapter 5
137
Exploring consumer and provider paths
Exploring consumer and provider paths

The relationships between consumers and providers are depicted with lines between the objects. The graph line that connects providers to consumers begins at the expansion handle atop the provider object and connects to the expansion handle at the bottom of the consumer object. By default, consumer objects are arranged above and providers are arranged below a specific node.
To explore consumer and provider paths 1 In an active View window, ensure that the cursor is in selection mode. 2 To explore the consumer paths, click the collapsed expansion handle at the top of
the component instance you want to explore.
3 To explore the provider paths, click the collapsed expansion handle at the bottom
of the node. If the component renditions indicate other providers in the chain, you can continue clicking the expansion handles until you reach the last provider node (identifiable because it has no expansion handle). When you click on a + expansion handle, the server is always queried and an up-todate list of consumers or providers is displayed.
138
Refreshing the View
Table 31
Understanding expansion handles
A component instance with expansion handles at the top and/or bottom functions as a consumer and/or provider in an impact relationship. To see the consumer (top +) or provider (bottom +) component instances, click on the expansion handle.
A component instance with two consumer or provider expansion handles indicates that there are other related component instances that are not displayed. For example, clicking on the expansion handle for Database 1 displays all its providers, in this case, Computer System 3. Computer System 3 has additional consumers as indicated by the extra + symbol at the top of the component instance icon.
Clicking the - symbol above Computer System 3 collapses all of its consumers, as shown.
Clicking on the + symbol above Computer System 3 results in the display of all consumer component instances, as shown.
Refreshing the View

To validate the current component instances against their current class definitions in the BMC Atrium CMDB, do one of the following:
s s
On the toolbar, click Refresh . From the menu bar, choose View => Refresh.
To refresh the list of component types, from the menu bar, choose Tools => Refresh Component Types.
Chapter 5
139
Repositioning the dockable windows
Repositioning the dockable windows

To undock and move the Templates, Pan and Zoom, Find, Properties, Views, or Console Navigation Bar windows, do one of the following:
s
Select one of the bars and drag it into the right pane of BMC Impact Service Model Editor. Right-click on the bar and choose Undock.
To redock an undocked window, do one of the following:

s s
Click the X in the top right corner of the undocked window. Right-click in the title bar and choose Close.
Showing topology views

There are many configuration items in the BMC Atrium CMDB that do not have consumer/provider relationships and are not appropriate for service impact management. If non-impact relationships exist between such component instances in your active View, you can see this topology for the entire View.
To show topology 1 In an active View window, from the menu bar, choose View, and then choose one
of the following:
s s s
Impact Relationships Non-impact Relationships All Relationships
TIP
You can redefine the line style for each type of relationship by selecting Tools => Options. See To define line styles for relationships on page 197.
2 (optional) In the same View, choose another relationship type to view its topology. 3 (optional) To see a legend of line styles, open the Relationship Legend box by
choosing Window => Legend.
140
Exporting and importing service model data
Exporting and importing service model data

You can export component instance definitions between different BMC Atrium CMDB datasets only if they contain the following values:
s s
DatasetId = BMC.ASSET ServiceModelSet = IN
You cannot select a subset of this data for export. The data is exported as a series of files in XML format to a user-specified directory. You can import specified component instance definitions in XML format from another BMC Atrium CMDB dataset.
To export service model data 1 From the menu bar, choose File => Export. 2 In the Look in box, choose the directory where you want to save the file. 3 In the Directory Name box, verify that the path is correct. NOTE
In the Files of type box, do not change the file type; the files must be saved in XML format.
4 Click Export. To import service model data 1 From the menu bar, choose File => Import. 2 In the Look in box, locate the folder and select the file you want to import. 3 In the File Name box, verify the name of the file. 4 Click Import. 5 A dialog displays informing you that the import is in progress. 6 (optional) Close the dialog. The import process will continue in the background.
A notification will display when the import process is complete.
Chapter 5
141
Exporting class definitions from the BMC Atrium CMDB to a cells
7 To update the current View with the most recent data from the BMC Atrium
CMDB, on the toolbar, click Refresh .
8 To search for the new data, open the Find dockable window. See Finding
component instances on page 89.
Exporting class definitions from the BMC Atrium CMDB to a cells

The Export Cell Meta Data command enables you to synchronize the class definitions in the BMC Impact Manager knowledge bases in the target cells with those from the BMC Atrium CMDB. BMC Impact Service Model Editor sends the export request to the BMC Impact Publishing Server, which collects the entire hierarchy of component and relationship class definitions from the BMC Atrium CMDB. Next, the BMC Impact Publishing Server creates a BAROC-formatted class definition file (mc_sm_object.baroc file) of the component and relationship class definitions so that the BMC Impact Manager cell can interpret the contents of the file. The BMC Impact Publishing Server sends this file to BMC Impact Service Model Editor and you can save it to a location you specify. Then you must manually copy the file to the appropriate directory of the destination cell and recompile the Knowledge Base of the cell. Alternatively you can export the class definitions with the CLI command
pclassinfo -x -o mc_sm_object.baroc.
For more information on pclassinfo usage, see pclassinfoComparing service model classes on cells with class definitions in the BMC Atrium CMDB on page 289.
142
Chapter
6
144 144 145 145 145 147 148 148 151 153 156 160 163 164 165 165
Upgrading a service model to BMC Atrium CMDB

6
This chapter covers the following topics: Upgrading from non-Atrium-CMDB SIM to BMC Atrium CMDB SIM . . . . . . . . . . Upgrading SIM data that originates from BMC Performance Manager . . . . . . . Upgrading SIM data that originates from third-party source . . . . . . . . . . . . . . . sim2cmdb restrictions . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 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 . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . Dataset cleanup . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . sim2cmdb return codes. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
Chapter 6 Upgrading a service model to BMC Atrium CMDB
143
Upgrading from non-Atrium-CMDB SIM to BMC Atrium CMDB SIM
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 the cell (version 7.2) 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 the cell. Service impact management without the BMC Atrium CMDB product (Standard or Basic deployment of BMC Impact Solutions) means that you have created component instances and relationships directly in the cell by using Direct Feed (through BMC Performance Manager, BMC Impact Explorer, mposter CLI command, or rules) or by using Direct Publish (a BAROC source file and the pposter CLI command) or that you are using a third-party database for service model data.
Upgrading SIM data that originates from BMC Performance Manager

Before you execute the sim2cmdb CLI command on Direct Feed service model objects, service model objects in the cell that originated from BMC Performance Manager must be created in the BMC.BPM dataset in the BMC Atrium CMDB, reconciled into the BMC.ASSET dataset, and published to the cell. Because BPM is the source of this data, both BMC Performance Manager and BMC Impact Portal must be upgraded to version 2.6. If you do not upgrade BMC Performance Manager and BMC Impact Portal
s
the data upgraded by BMC Performance Manager in the BMC Atrium CMDB will not be published, because BMC Performance Manager does not set ServiceModelSet to IN) there will be duplicate CIs in the cell (because BMC Performance Manager stores mc_udid as ComponentAlias in the cell, but not in the BMC Atrium CMDB
For more information about the integration between BMC Performance Manager and SIM, see the Direct Service Model Integration section in the BMC Performance Manager Portal Monitoring and Management Guide.
144
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 BMC Impact Manager 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 BMC Impact Manager; it is not a way to keep a third-part repository in sync with the BMC Atrium CMDB.
sim2cmdb restrictions
The cell must be upgraded to version 7.2, because there are new slots in the cell in version 7.2 that are used in the best match rules. Components that do not have values in these new slots cannot be properly identified and merged into the BMC Atrium CMDB. See Table 32 on page 149 and Table 32 on page 149 for slots that participate in the reconciliation.
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 Verify that the cell is upgraded to 7.2. 3 Ensure you have quality data in the BMC Atrium CMDB. 4 Analyze and understand the data in the cell so you know how it will be identified
and reconciled in the BMC Atrium CMDB.
5 Modify the sim2cmdb.conf file as needed. 6 Run sim2cmdb without any command to verify the data.
145
Recommended upgrade steps
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 160.
7 Repair the offending data in the cell. 8 Repeat steps 6 and 7 until no more data is excluded. 9 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 163.
10 Verify that the output file contains no excluded data. NOTE

If more excluded data is found in the output file, continue through step 13.
11 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.
12 Check the output file for unidentified CI's. Identify them manually, and reconcile.
For more information, see CI identification on page 164
13 Verify that publication was successful.

If publication was not successful, diagnose failure and, if necessary, repair data in BMC.ASSET and publish again.
14 If in step 10 data you discovered excluded data, repair the offending data in the
cell and restart this procedure from step 6. Verify that all expected data (especially impact relationships) are exported. You might need to upgrade DirectFeed data, too.
15 When all data from the publish environment is upgraded, close the upgrade.
146
Understanding how the upgrade works
16 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. Replacement in the cell is based on
s
for CIsthe ComponentAliases attribute If a CI has no value in the ComponentAliases slot, then the CI will not be replaced in the cell when the CI in the BMC Atrium CMDB is published back to the cell, resulting in duplicate CIs in the cell. Upgrading the cell to 7.2 ensures that even CIs without a value in the
ComponentAliases attribute are replaced by sim2cmdb, because in 7.2, if ComponentAliases for a CI is empty, it is assigned the mc_udid as a default.
s s
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.
147
Ensuring quality data in BMC Atrium CMDB
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
s
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.
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 into BMC Atrium CMDB when the BMC SIM CMDB Extensions are installed. The reconciliation job defines the data identification rules and identification activities for both component instances and management data instances.
s
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.
148
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 164.
NOTE
If ITSM is installed, then certain attributes (Category, Type, Item, Model, ManufacturerName) of a CI have to correspond with the attributes of existing products (Tier1, Tier2, Tier3, Product Name, Manufacturer) in the catalog before performing a sim2cmdb commit. If these attributes fail to correspond, the commit will fail when executed. For more information about how to create entries in the product catalog, how to create product catalog alias mappings, and how to work with trusted datasets for the product catalog see the supplied ITSM documentation.
sim2cmdb has a default set of identification groups for identifying the components in the BMC Atrium CMDB. Table 33 lists these identifying components.
s s s s
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 32
Identifying components in the BMC Atrium CMDB

Classes that inherit the rule Best match attributes Name Name ApplicationType Name ApplicationInfrastructureType Name SystemName SystemClassId Autoidentify Yes No No No
Base class of the identification group BMC_Activity BMC_Application BMC_ApplicationInfrastructure BMC_ApplicationService
149
Table 32
Identifying components in the BMC Atrium CMDB

Classes that inherit the rule BMC_DataBase BMC_ApplicationSystem BMC_Cluster BMC_ConnectivityCollection BMC_ConnectivitySegment BMC_IPConnectivitySubnet BMC_LNsCollection BMC_LAN BMC_WAN Best match attributes Name Autoidentify No
Base class of the identification group BMC_BaseElement
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 BMC_SoftwareServer BMC_SystemSoftware BMC_OperatingSystem
Name Name SoftwareServerType Name SerialNumber VersionNumber Name Name SystemName SsytemClassId Name SystemName SystemClassId VMImageName
Yes No No
BMC_UserCommunity BMC_VirtualSystemEnabler
Yes No
BMC_VMWare
No
The reconciliation rules for management data are based on the key slots of the classes.
150
Data imported into BMC.SIM
Table 33
Class
Key slots in reconciliation rules for management data

Keys name self_priority 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 name sla_state Auto-identify Yes Yes Yes
BMC_COST_OF_DOWNTIME_PRIORITY_MAPPING BMC_DOWNTIME_STATUS_CONFIG BMC_PROPAGATION_MAP
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 BMC_WORST_SLA_STATE_PRIORITY_MAPPING SIM_TIME_FRAME
Yes Yes Yes Yes Yes
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.

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.
151
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:
Source (Strong member) BMC_System BMC_System
Weak relationship BMC_HostedSystemComponents BMC_ HostedService
Destination (Weak member) BMC_SystemComponent BMC_SystemService
Possible Import Results

Table 34 lists possible import results for specific circumstances.
152
sim2cmdb CLI command
Table 34
Condition
Possible import results

Result
s s s s
a relationship has only one endpoint in BMC Atrium CMDB
the relationship is not created in BMC Atrium CMDB the endpoint CI in BMC Atrium CMDB is not affected if ContinueOnSkip is true, the relationship is not imported if ContinueOnSkip is false, none of the data is imported 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
s s s s
a weak CI points to a strong CI that does not exist in BMC Atrium CMDB
s s s
a value for HomeCellAliases is not found for a CI
s s s s

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.
sim2cmdb.conf file and parameters

Table 35 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.
s s s
ContinueOnSkip ReverseCellAliases ReconJobTimeout
153
Table 35
Filename File path Description
sim2cmdb.conf file (part 1 of 3)

sim2cmdb.conf MCELL_HOME/ 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 localhost:3084
Parameter name
IASServers
IASUserName
specifies a valid Impact Administration Server user name to be presented as credentials to the specified Impact Administration Server
none
IASPassword
specifies the valid Impact Administration Server none 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.
CMDBServer CMDBPort
specifies the name of the computer on which BMC Atrium CMDB resides defines the port number for connecting to the BMC Atrium CMDB
not defined, set by install not defined, set by install use 0 for dynamic port detection
154
Table 35
CMDBUser

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
CMDBPassword
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.
ReconJobTimeout
sets the length of time that sim2cmdb checks for the termination of the reconciliation job If the interval expires before the reconciliation job completes, the sim2cmdb output file does not indicate the results of the reconciliation job. It may or may not have completed successfully.
120 (seconds)
155
Running the upgrade
Table 35

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)
CommitRetryTimeOut
PublishingServerName
the name of the publishing server This name is used in validating the publish environment and for DirectPublish credentials.
ps_hostName
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 163, CI identification on page 164, and Dataset cleanup on page 165 for more information about each of these commands.
sim2cmdb command options

Table 36 lists the options for the sim2cmdb command.
156
Running the upgrade
Table 36
Options

Description
<common options> -c -h -? -i -q -l -p -v -z -e EnvID envID1[,envID2[...]]
see Understanding common command options for CLIs on page 281

identifies the specific environments If an environment is not specified, then Direct Feed data is upgraded. If you are upgrading Direct Feed data only, EnvID must be empty; do not use the -e option for Direct Feed data. For example, the following command displays all the Direct Feed data present in the cell to be upgraded sim2cmdb v n <cellname> For secured environments, you must provide a valid password using the p password=xx option. If multiple EnvID options are specified, you must provide a password value for each EnvID. If one of the EnvID command options fails during environment verification, the sim2cmdb execution terminates. If both Direct Feed data and Direct Publish data must be imported, the Direct Publish EnvIDs as well as one empty EnvID has to be specified with e option. To display data in Direct Feed and Direct Publish environments, use one of the following examples: sim2cmdb v n <cellname> -e ,DirectPubEnvId1,DirectPubEnvId2 sim2cmdb v n <cellname> -e DirectPubEnvId1,DirectPubEnvId2, sim2cmdb v n <cellname> -e DirectPubEnvId1,,DirectPubEnvId2 The comma (,) at the beginning, end, or middle of the option represents an empty EnvID.
-f
forces the command execution without prompting you to confirm the action If you do not specify the -f option, you must confirm the action when prompted to allow the action to execute.
157
Running the upgrade
Table 36
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.
158
Running the upgrade
Table 36
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 164 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
159
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
s
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 19, Figure 20, and Figure 21 are examples of an output files.
160
Figure 19
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
161
Figure 20
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.
162
Upgrade commitment
Figure 21
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:
s
If issues are found in data verification and the configuration parameter "ContinueOnSkip" is set to false (default).
163
CI identification
To continue upgrading, you must fix the data or set the ContinueOnSkip to true, which commits the data upgrade regardless of issues with the data.
s
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:
s
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 11 on page 146.
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 148 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 37. Table 37
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. 165
Table 37
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:
s
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
166
Table 37
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
167
168
Chapter
7
169 170 173 174 174 174 174 172 174 177 177 178 178 180 181 182 191 192
Component and relationship status propagation

7
This chapter contains the following topics: About component and relationship status . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . How component status computation works . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . About status computation models . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . Anatomy of a status computation model. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . Anatomy of a status computation model. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . The internal status NONE . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . Quorum algorithm examples. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . How status computation algorithms work . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . Quorum algorithm examples. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . Relationship status propagation concepts . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . How status propagation works . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . Status propagation models. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . Default status propagation models. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . What is a valid status propagation model? . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . Dynamic prioritization . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . Self priority . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . Impacts priority . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . Determination of final priority . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
About component and relationship status

The status of a component can be influenced directly by the severities of its associated events, indirectly by the propagated status of its provider components, or by both. Status computation models calculate the new value of component status using these factors.
Chapter 7 Component and relationship status propagation
169
How component status computation works
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 component instances, 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, 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 component instance. The cell obtains the name of the status computation model to use from the instances StatusComputationModel slot. 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:
s s s
impact_function self_function consolidate_function
Table 38 lists the functions, their inputs, and the type of computed status that each function calculates.
170
Status computation algorithms
Table 38
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
impact_function
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 component instances status is set to the computed_status except when you set the component to manual status, in which case, the component instances status is set to manual_status.
Status computation algorithms

The status computation algorithms define the functions involved in status computation use the cells 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).
171
How status computation algorithms work
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. By CountUsing this algorithm, a function factors in the number of cluster members in particular states (for example, OK, UNAVAILABLE). By default, the status of the cluster is set to
s s s s
OK if at least two members are OK and no more than one is UNAVAILABLE WARNING if one single member is OK and none is UNAVAILABLE IMPACTED if one single member is OK and at least one is UNAVAILABLE UNAVAILABLE if no member is OK and at least two are UNAVAILABLE
By default, all component types rely on a 3-High status computation model, in which all of the status computation functions use the HIGHEST_VAL algorithm.
How status computation algorithms work

Table 39 shows the type of value that a component status computation function returns when using an available algorithm. Table 39
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 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
HIGHEST_VAL AVERAGE
QUORUM
HIGHEST_VAL SELF_PREFERRED
172
About status computation models
About status computation models

In the BMC Impact Service Model Editor product and in the BMC Impact Explorer product, for each component instance, you select one of the predefined status computation models: Standard, Cluster, Weighted Cluster, Self-Preferred, and Cluster By Count. Standard is the default status computation model. Table 40
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 174) 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 Cluster By Count
computes the status of a component using the self-preferred algorithm for the consolidation_function computes the status of a cluster component using the impact_function BY_COUNT
The BMC_STATUS_COMPUTATION data class is the basis of all status computation model instances. For a description of BMC_STATUS_COMPUTATION slots, see BMC_STATUS_COMPUTATION data class on page 353.
173
Anatomy of a status computation model
Anatomy of a status computation model

A status computation model defines the following:
s s
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.
174
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:
s
s s
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.
175
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
176
Relationship status propagation concepts
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. The BMC_STATUS_PROPAGATION data class supports relationship control and, together with the BMC_PROPAGATION_MAP data class, provides dynamic status mapping. One status propagation model is made up of several instances in both data classes. 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 component instances 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 component instance 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.
177
When a state change on an outbound impact relationship triggers a new status propagation for that component instance, the cell combines the main status of the component with the retrieved state and the status propagation model of the relationship, and searches the propagation map of the status propagation model for a matching entry. The result is the propagated_status value that is then passed as an input to the impact_function of the consumer component.

A propagation model defines how the status of a provider component must be propagated in an impact relationship based on
s s
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:
s
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 174.
Default status propagation models

The service model provides the following default status propagation models:
s
DIRECTconsumer component depends on the providers services to the extent
that its status is the same as the providers

s
INCREASINGconsumer component is overly dependent on the provider. When a problem occurs, the consumers status degrades faster than the providers does DECREASINGconsumer component can function without providers services. When a problem occurs, the consumers status is less degraded than the providers
178
Default status propagation models
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
Table 41 describes the how status propagation occurs for a specific model. Table 41 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
179
What is a valid status propagation model?
What is a valid status propagation model?

A valid status propagation model is a BMC_STATUS_PROPAGATION instance, complemented with the appropriate number of BMC_PROPAGATION_MAP instances, all sharing the same name. A BMC_STATUS_PROPAGATION instance is not created if the supporting BMC_PROPAGATION_MAP instances have not yet been created. A valid status propagation model must have:
s
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 22 depicts this relationship.
180
Dynamic prioritization
Figure 22
Propagation paths between root cause and important components
Component A is considered as a root cause of component B if

s s
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.
181
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
s s s
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: s base priority (default) s cost s 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 23
Self priority determination
182
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:
s
the During 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 During 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.
Mapping base priority

You can map these values by editing the BMC_SELF_PRIORITY_MAPPING BAROC table in the BMC Impact Service Model Editor.
183
Self priority
The self-priority value of the important component is calculated based on a formula that takes into account both the base_priority value and its status value, as depicted in the BMC Impact Portal:
This mapping is configured in the match table in BMC Impact Service Model Editor.
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.
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.
184
Self priority
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:
s
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:
s
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 timeframe, 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. 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.
185
Self priority
If there is an instance i in this table with

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

s
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.
Figure 24
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.
186
Self priority
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
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
s s
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
187
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:
s s s s
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
188
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:
s
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
s s s
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.
189
Self priority
Figure 25
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
190
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 26 Impacts priority determination
191
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 27 on page 193.
192
Figure 27
Final priority determination
193
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.
194
Chapter
Managing BMC Impact Service Model Editor

8
Service Management administration is performed in large part within BMC Impact Service Model Editor and its supporting data classes, with some administration also being done in the BMC Impact Portal. Administration includes managing all user access to information contained in the service model. Access control is managed in the service model through individual component instances. 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. Additional user control functions in BMC Impact Service Model Editor include console navigation trees, which impose a structure on the organization of service management information, control folder-level rights, and pass this information to the BMC Impact Portal. This chapter includes the following topics: Setting BMC Impact Service Model Editor options . . . . . . . . . . . . . . . . . . . . . . . . . . . Configuring the topology view in BMC Impact Service Model Editor . . . . . . . . . . . Configuring the topology view in BMC Impact Service Model Editor . . . . . . . . . . . Using a firewall with BMC Impact Service Model Editor . . . . . . . . . . . . . . . . . . . . . . Adding new classes to the BMC Atrium CMDB . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . Making your changes visible to applications . . . . . . . . . . . . . . . . . . . . . . . . . . . . . Creating a new service model component class in the BMC Atrium CMDB . . . Associating a custom icon with a service model component . . . . . . . . . . . . . . . . Documenting your extensions. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . smeserver properties file and parameters . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 196 200 200 201 202 202 203 204 207 208
Chapter 8
195
Setting BMC Impact Service Model Editor options

The Options command offers numerous configuration settings for user-specific definition as well as global options and is available to any user with access to BMC Impact Service Model Editor.
Personal options
Personal options settings are unique to the user. The values specified here are specific to the user and are reapplied when the user logs into BMC Impact Service Model Editor on any computer. The options settings are saved on BMC Impact Service Model Editor server. Options that you can change include icon colors and label styles, line styles, regional preferences, View appearance, copy/paste settings, and log file preferences. All personal options are available by choosing Tools => Personal Options.
To define component instance icon colors and label styles 1 From the menu bar, choose Tools => Personal Options. 2 On the Components tab, in the Component icon area, choose a drawing mode.
Drawing mode affects how the component instance looks when it is being moved.
s s
Ghost results in a simple rectangular border. Opaque results in the component being fully drawn.
3 In the Selection Background Color list, choose a background color for the
component instance icon when the component instance is selected.
4 In the Active Border Color list, choose a color for the border of the component
instance icon when the mouse cursor is over it.
5 In the Component Label area,

s
choose a font, type size, color, and style for the label that names the component instance icon. in the Maximum Number of Characters to Display box, choose a number that limits the number of characters to display for component instance name labels. If a component name is longer that the maximum number of characters, the name is truncated. This value applies to every component instance in every View.
196
To define line styles for relationships 1 From the menu bar, choose Tools => Personal Options. 2 On the Relationships tab, in the Relationship Type pane, select the relationship type
that you want to change.
3 In the Line Color list, choose a predefined color or set a custom color for the line. 4 In Line Style list, select one of the predefined line styles or create a custom line
style. To create a custom line style, enter numbers separated by commas, which alternately define the length of the visible/invisible line segments. For example: 9,3,1,3 creates a repeating line pattern with 9 solid units, 3 invisible units, 1 solid unit, and 3 invisible units.
5 In the Line Weight list, choose a predefined line weight or define a custom line
weight by entering a decimal number (between 0.01 and 5.0) that defines the width of the line. For example, a weight of 2.0 creates a line that is twice as thick as one with a weight of 1.0.
TIP
When a View is open, you can see a legend of line styles by choosing Window => Legend.
To set regional preferences 1 From the menu bar, choose Tools => Personal Options. 2 On the Regional Settings tab, in the Locale area, choose the option that works best in
your environment. The Use Country/Region Specified in BMC Portal User Account option uses the locale specified when BMC Portal was registered as a user.
3 In the Date Format and Time Format areas, choose a format for each.
For the Time Format, the Long and Full options appear the same in English, but may be different in other languages.
Chapter 8
197
To set View appearance options 1 From the menu bar, choose Tools => Personal Options. 2 On the Appearance tab, in the Production/Sandbox View Background Color list,
choose a color for the production and sandbox View background.
3 In the Test View Background Color list, choose a color for the test View background. 4 In the Desktop Background Color list, choose a color for the right pane of BMC
Impact Service Model Editor before a View is opened.
5 For the Show Tooltips check box,

s
clear this check box to not see tooltips, or enter values (in milliseconds) for the Initial Delay, Dismiss Delay, and Reshow Delay.
6 For the Show Embedded Help Text check box, clear this check box to not display
paragraph-style instances of Help text that appear in some dialog boxes.
To set copy/paste and miscellaneous options 1 From the menu bar, choose Tools => Personal Options. 2 On the Other tab, in the Copy/Paste area, select the appropriate copy/paste options
for renaming copied component instances. This tab also controls the Paste Multiple Components dialog box; see To copy component instances on page 87.
3 In the Miscellaneous area, for the Load Saved Views at Login check box, options are
defined as follows:
s
check box selected: data for all Views is loaded into memory when you log into BMC Impact Service Model Editor check box cleared: data for a View is loaded into memory only when you open that specific View.
4 For the Use Live Server Data During Selection check box, options are defined as
follows:
s
check box selected: as each component is selected in the View, the data is retrieved again from the BMC Atrium CMDB. check box cleared: data for all the components in a View is retrieved from the BMC Atrium CMDB when the View is opened. Data for an individual component may become outdated.
198
NOTE
Whichever setting is selected, when you open the Edit Component or Edit Relationship dialog boxes, the latest information is always retrieved from the BMC Atrium CMDB.
5 For the Show Duplicate Component Dialog checkbox, the dialog box displays when
you use the Find command and want to place found objects in a View (by dragging or clicking Place in Selected View) that already has contains the objects:
s s
checkbox selected: dialog box displays checkbox cleared: dialog box does not display; there is no alert that you are duplicating objects in the View
To set log file preferences 1 From the menu bar, choose Tools => Personal Options. 2 In the Logging tab, set the level of log information you need on the client computer.
Logging becomes more detailed as you go from the top of column one to the bottom of column one, then to the top of column two to the bottom of column two. The most detailed log selection is All. The more detailed the log is, the more disk space is used.
3 In the Buffer Size box, enter the maximum number of log messages you want to
save in memory. This is a first in, first out buffer; when the maximum number of messages is reached, the oldest message is deleted when a new one is added.
4 In the Log Files area, select options for saving log files on the client computer.
You can specify a directory to save the files in, but the file name bmc_sme_integer_log# is generated by BMC Impact Service Model Editor. The first file saved is numbered 0; subsequent logs increment by one. When the number of log files saved reaches the value in the Number of Log Files box, the count starts again at zero and the existing files with the same name are written over.
Global options
To set component instance self-priorities when in a given status, select Tools => Options => Global Options.
Chapter 8
199
Configuring the topology view in BMC Impact Service Model Editor
For more information on Service Schedules, see Service schedules on page 62.
NOTE
If you change the self-priority of the component for an Other status, the self-priority values are automatically changed for the statuses of INFO, UNKNOWN, and BLACKOUT.
To edit service schedule self-priorities 1 In the Options - Global dialog box, in the Base Priority/Status table, select the
appropriate status level (1-5) for each base priority/status level.
2 In the Impacts Priority Calculation Method, choose the calculation method for the
component.
3 In the Default Component Types that Propagate Priority box, enter the classes of
components that will have a default value of Propagate Priority=Yes. Separate the class names by commas.
4 Click OK to save your changes.

For more information, see Chapter 7, Component and relationship status propagation.
Configuring the topology view in BMC Impact Service Model Editor

You can set the type of topology views displayed by BMC Impact Service Model Editor in the ..\smsIwc\application.properties file using the com.bmc.sms.sme.topoviews parameter. This parameter has a comma-delimited list of the supported topology views. For example, the default is shown in Figure 28. Figure 28 Default value for com.bmc.sms.sme.topoviews parameter
com.bmc.sms.sme.topoviews=com.bmc.sms.sme.topo.application,com.bmc.sms.sme.topo. non.impact
Each item in the list has two functions:

s
It is a resource key to a localized name (that can appear in the user interface). The localized name is defined in the sme_messages.properties file for the appropriate locale. It is the base key for the definition of the topology view.
200
Using a firewall with BMC Impact Service Model Editor
Each base key is appended with an integer (for as many as needed) that defines a graph to traverse for the topology view. The general format of a graph definition is shown in Figure 29. Figure 29 Graph definition format
<ComponentType>.<RelationshipType>.<ComponentType>
For example, for a graph type whose key is com.bmc.sms.sme.topo.application, the following graph entries could be defined as shown in Figure 30. Figure 30 Example of a graph definition
com.bmc.sms.sme.topo.application.1=BMC_BaseElement.BMC_Component.BMC_BaseElement com.bmc.sms.sme.topo.application.2=BMC_BaseElement.BMC_MemberOf.BMC_BaseElement
A graph definition can include as many types as desired, but it must always begin and end with a component type. For example:
BMC_BaseElement.BMC_Impact.BMC_BaseElement
Using a firewall with BMC Impact Service Model Editor

If your environment contains a firewall between the BMC Impact Service Model Editor client and BMC Impact Service Model Editor server (with http port open), the BMC Impact Service Model Editor Client will fail unless ports 9378 and 9386 are opened in the firewall.
Chapter 8
201
Adding new classes to the BMC Atrium CMDB
Adding new classes to the BMC Atrium CMDB

This section contains information about adding new classes and attributes to your data model.
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 Impact Solutions products or BMC Remedy Asset Management. You must modify new classes and attributes so they can be used with these 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 2.0.1 Installation and Configuration Guide.
BMC Impact Solutions

While updating BMC Impact Solutions to use new classes and attributes, note the following information about classes:
s
s s
Classes with the custom qualifier 100050 are SIM-enabled classes. Instances with this property are pushed by the BMC Impact Publishing Server to the cells. SIM-enabled class definitions in the BMC Atrium CMDB and the class definitions in the BMC Impact Manager cell must match. For more information, see Exporting class definitions from the BMC Atrium CMDB to a cells on page 142. For your new class to be a service model component class, not only does the new class need to be SIM-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 SIM-enabled as well. BMC Impact Service Model Editor filters out abstract classes. The new class inherits the attributes of its superclass.
Note the following information about attributes:

s s
SIM-enabled attributes have the custom qualifier 300050. BMC Impact Publishing Server pushes attribute values to the cells.
202
Creating a new service model component class in the BMC Atrium CMDB
Perform the following steps to update BMC Impact Solutions to use new classes and attributes:
1 Using the Class Manager, add these custom qualifiers to the new classes and
attributes:
s
Classes: 1\100050\2\1\ SMEReadWrite attributes: 2\300050\2\1\300070\2\1\ SMEReadOnly attributes: 2\300050\2\1\300080\2\1\
For instructions on this step, see Creating a new service model component class in the BMC Atrium CMDB on page 203.
2 Add custom icons for new classes.

For instructions on this step, see Associating a custom icon with a service model component on page 204.
3 From BMC Impact Service Model Editor, export cell metadata, import the resulting
file into the cells Knowledge Base, and recompile the cell. For instructions on this step, see Exporting and importing service model data on page 141 and BMC Impact Solutions: Knowledge Base Development.
Creating a new service model component class in the BMC Atrium CMDB
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 2.0.1 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. SIM-enabled classes are listed in Service model and the Common Data Model on page 66.
Chapter 8
203
Associating a custom icon with a service model component
4 Specify the Custom Qualifier 1\100050\2\1\ in the General tab. 5 Click Save.
All superclasses of a SIM class, up to BMC_BaseElement, need to be SIM classes, regardless if they are abstract or concrete.

The BMC Impact Service Model Editor, BMC Impact Portal, and BMC Impact Explorer Services views utilize icons to represent service model components. Each component type in BMC Impact Service Model Editor is associated with an icon, which you can view in the Templates dockable window. For a list of default service model component icons, see Service model component types on page 47.
NOTE
Icons must be in .gif format. The .gif format is the only supported file type for icons.
When you create a new component type by adding a new class to the BMC Atrium CMDB, associate an icon with the new component.
To associate an icon with a service model component class

When adding a custom icon to a newly created class, follow this sequence for initializing the new data and synchronizing the class definition with those in the SIM KB of the target cell or cells.
1 Create a new class in the BMC Atrium CMDB. For instructions, see Adding new
classes to the BMC Atrium CMDB on page 202.
2 Create a set of the three different-sized icons for the new class, and save them
using the file naming convention className_size.ext. See Guidelines for associating a custom icon with a service model component class on page 206.
3 Store an identical set of the three icon fileseach file in the set designating a
different pixel sizeunder each of the three specified subfolders on the system where the BMC Portal application server is running. See Guidelines for associating a custom icon with a service model component class on page 206.
4 Associate the icon with the service model component class by performing the
following actions:
204
A Edit the component_icon.properties file. By default, the component_icon.properties

file is located in the following directory path:
s
Solaris
%BMC_Portal_Kit_Home%\appserver\websdk\tools\jboss\server\all\conf\pr operties\smsConsoleServer\
Windows
%BMC_Portal_Kit_Home%\appserver\websdk\tools\jboss\server\all\conf\pr operties\smsConsoleServer\
B Add the following to the component_icon.properties file:

Replace ClassName with the name of the new class you defined in the BMC Atrium CMDB and IconFileClassName with the prefix you used to name the three icon files (className_size.ext).
sms.component.icon.ClassName=IconFileClassName
C Save the component_icon.properties file. 5 Restart the BMC Impact Administration Server. 6 Restart the BMC Portal application server and all BMC Impact Service Model
Editor client instances.
7 Refresh BMC Impact Service Model Editor templates by using Tools => Refresh
Component Types.
8 Synchronize the new service model class definitions with the SIM KB. For
instructions see Exporting and importing service model data on page 141.
9 Create the new class definition in BAROC format by using Tools => Export Cell
Meta Data. The file that is created is named mc_sm_object.baroc.
After you convert the class definition to BAROC format, you make it available to the SIM KB of the target cell or cells.
10 Manually copy the mc_sm_object.baroc file to the destination directory of the target
cell or cells. By default, the mc_sm_object.baroc file is located in the following directory path:
s
Solaris$MCELL_HOME/etc/CellName/kb/classes Windows%MCELL_HOME%\etc\CellName\kb\classes
Chapter 8
205
11 Recompile each cells KB by using the mccomp -v manifest.kb command. 12 Restart the cell or cells. Guidelines for associating a custom icon with a service model component class
Follow these guidelines when adding and associating custom icons with service model component classes:
s
BMC Impact Service Model Editor and BMC Impact Portal accept three sets of pixel sizes for the component icons: 16 x 16, 32 x 32, and 128 x 128. For each custom class that you create, you must include three sets of identical icons, each set using the three different pixel sizes: 16 x 16, 32 x 32, and 128 x 128. Use .gif format only. For example, set one contains three identical icons of 16 x 16, 32 x 32, and 128 x 128 pixels; set two contains the same three icons of 16 x 16, 32 x 32, and 128 x 128 pixels, and so forth.
Name each custom icon using the same name as the custom class it represents. Follow this naming convention:
className_size.gif
className is the name of the custom class you created. size refers to the pixel sizes 16, 32, and 128. gif is the file extension and is required. For example, if you created a custom class named BMC_ABCServer, you would create three corresponding custom icons named as follows: BMC_ABCServer_16.gif BMC_ABCServer_32.gif BMC_ABCServer_128.gif
s
Save a set of the three different-sized custom icons to each of the following three subdirectories under the BMC_Portal_Kit_Home installation directory. You can find these directories on the system where the BMC Portal application server is installed. On Windows, the directories are located as follows: %BMC_Portal_Kit_Home%\appserver\websdk\tools\jboss\server\all\modules\
smsSme.sar\smsSme.war\images
%BMC_Portal_Kit_Home%\appserver\websdk\tools\jboss\server\all\data\
smsConsoleServer\Image\Icon\objects
206
Documenting your extensions
NOTE: You must create the objects subdirectory in the path above and save the icons there. %BMC_Portal_Kit_Home%\appserver\websdk\tools\jboss\server\all\modules\
smsConsoleServer.sar\smsConsoleServer.war\images\objects
On Solaris, the directory are located as follows: $BMC_Portal_Kit_Home/appserver/websdk/tools/jboss/server/all/modules/

smsSme.sar/smsSme.war/images
$BMC_Portal_Kit_Home/appserver/websdk/tools/jboss/server/all/data/
smsConsoleServer/Image/Icon
$BMC_Portal_Kit_Home/appserver/websdk/tools/jboss/server/all/modules/
smsConsoleServer.sar/smsConsoleServer.war/images/objects
By saving an identical set of the three different-sized icon files to each of the subdirectories, you are making them available to both BMC Impact Service Model Editor, BMC Impact Portal, and BMC Impact Explorer Services View.
Default icon when no match is found

When retrieving component icons, BMC Impact Service Model Editor first searches its local repository for the icons shipped with the product. If the matching icons are not found, it next searches the images subfolder. If no match is found, BMC Impact Service Model Editor uses the default icon Unknown_16.png, Unknown_32.png, or Unknown_128.png. Figure 31 BMC_BaseElement default icon image
Documenting your extensions

Just as you need to occasionally look up information about classes in the CDM, you will need to look up information about classes you create. One easy way to document a class is to copy one of the existing HTML files in CMDBInstallationFolder\sdk\doc\cdm and modify it to fit your class. If you copy the help file for a class with the same superclass as your class, you wont need to change the information about inherited attributes and relationships. After creating your HTML help files, be sure to make a backup copy of them in a separate location so that they wont be overwritten when you install a future version of the BMC Atrium CMDB.
Chapter 8 Managing BMC Impact Service Model Editor 207
smeserver properties file and parameters

Table 42 describes the smeserver.properties file and its parameters. Table 42
smeserver.properties file
smeserver.properties BMC_PORTAL_KIT_HOME/appserver/webskd/tools/jboss/server/all/conf/properties/smsS me contains all the user configurable BMC Impact Service Model Editor properties Description sets whether the precache applet is run to request component types from the BMC Atrium CMDB if defined, sets the number (integer) of component instances retrieved as a result of the Find command sets the temp directory of the BMC Impact Service Model Editor server Default value true
Parameter name
com.bmc.sms.sme.server. cmdbservice.precache. componenttypes com.bmc.sms.sme.server. cmdb.find.result.limit com.bmc.sms.sme.server. tmpdir
undefined; no limit undefined; default temp directory is JBOSS_HOME/ server/all/tmp/ sme ps_requests ps_response ps_notifications
com.bmc.sms.sme.server. publish.queue.requests com.bmc.sms.sme.server. publish.queue.response com.bmc.sms.sme.server. publish.topic.publish. status.change com.bmc.sms.sme.server. publish.controller.name
sets the name for the BMC Impact Publishing Server request queue sets the name for the BMC Impact Publishing Server response queue sets the name for the BMC Impact Publishing Server notification topic
sets the Java Management Extensions (JMX) name for com.bmc.sms. the publishing controller component of the BMC Impact sme.server: Publishing Server name= PublishService Controller defines the JMX name of the last successful Publishing Manager com.bmc.sms. consoleserver: name=LastPubli shManager 60 seconds
com.bmc.sms.sme.lsp.manager
com.bmc.sms.sme.server. publish.response.timeout com.bmc.sms.sme.server. publish.extended.response. timeout
sets the timeout value (the number of seconds to wait) for reception of BMC Impact Publishing Server responses sets the timeout value (the number of seconds to wait) for reception of BMC Impact Publishing Server extended responses
3600 seconds
com.bmc.sms.sme.server.promot sets the timeout, in seconds, for the Reconciliation ion.timeout Engine to reconcile objects into production
3600000 seconds
208
Table 42
smeserver.properties file
1000 seconds true HH:mm:ss z MM/dd/yyyy BMC.ASSET 60 seconds smsConsoleServ er
com.bmc.sms.sme.server.promot sets the amount of time to wait before checking the ion.wait.time status on a reconciliation job
com.bmc.sms.sme.publish. preview.enable com.bmc.sms.sme.date.format com.bmc.sms.sme.server. export.datasetid com.bmc.sms.sme.cmdb.ping com.bmc.sms.sme.localized. classes.dir
enables (true) or disables (false) publishing previews sets the date format for the BMC Impact Service Model Editor defines the dataset (using dataset ID) to use for service model exports sets the polling interval, in seconds, for pinging the BMC Atrium CMDB to ensure that it is available defines the base directory used under SDK_HOME/tools/jboss/server/all/ conf/resources/locale/classesdir to retrieve localized server resources for class names and attributes lists the names of property files that contain localized classes and attributes. You can define custom files and add them to the list. The files are loaded in the order listed and the files loaded later override settings in files loaded earlier. The files listed must exist in the SDK_HOME/tools/jboss/server/all/ conf/resources/locale/classesdir
com.bmc.sms.sme.kb.info. resources
kb_deprecated_ resource. properties,kb_co re_resource. properties
com.bmc.sms.sme.topoviews
defines a comma-delimited list of supported topology views. Each element in the list has two functions:
s
See smeserver. properties file for current It is a resource key for a localized name (suitable for default values. the UI). It is the base key for the definition of the topology view. Each key is appended with an integer (for as many as needed) that defines a graph to traverse for the topology view.
If you edit any of these configuration files manually, you must restart the BMC Portal service or daemon for the changes to take effect. If you have edited any of the BMC Impact Publishing Server configuration files, you must restart the BMC Impact Publishing Server service or daemon also.
Chapter 8
209
210
Chapter
Managing BMC Impact Publishing Server

9
After you create a service model, the service model data must be delivered from the BMC Atrium CMDB or the pposter source files to the cells. The process of distributing SIM data from the source to the cells is managed and controlled by the BMC Impact Publishing Server component of BMC Impact Solutions. This chapter provides information on managing the BMC Impact Publishing Server and contains these topics: Starting and stopping the BMC Impact Publishing Server . . . . . . . . . . . . . . . . . . . . . Starting and stopping BMC Impact Publishing Server on Windows . . . . . . . . . Starting and stopping BMC Impact Publishing Server on UNIX. . . . . . . . . . . . . Working with publication logs . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . Viewing publication history . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . Viewing publication history details . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . Specifying a port for Service Model Manager . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . High availability and BMC Impact Publishing Server . . . . . . . . . . . . . . . . . . . . . . . . . Monitoring BMC Impact Publishing Server with BMC Impact Manager events. . . Modifying the generation of events . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . Understanding classes and slots for BMC Impact Publishing Server events . . . About SIM management data . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . Understanding publish environments . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . About publish environments . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . About home cell, home cell alias, and cell alias . . . . . . . . . . . . . . . . . . . . . . . . . . . Publishing from the BMC Atrium CMDB . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . Enabling AtriumCMDB Publish publishing . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . Using BMC Impact Service Model Editor . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . Creating advanced publish environments. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . Examples of advanced environments. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . Defining BMC Atrium CMDB classes for SIM . . . . . . . . . . . . . . . . . . . . . . . . . . . . Defining BMC Atrium CMDB attributes for SIM . . . . . . . . . . . . . . . . . . . . . . . . . . ServiceModelSet attribute for components and management data . . . . . . . . . . . ServiceModelSet attribute for impact relationships . . . . . . . . . . . . . . . . . . . . . . . . Initializing the BMC Atrium CMDB with SIM data. . . . . . . . . . . . . . . . . . . . . . . .
Chapter 9 Managing BMC Impact Publishing Server
212 212 214 215 215 216 217 217 218 218 220 228 229 230 231 232 232 233 236 237 239 239 240 241 241
211
Starting and stopping the BMC Impact Publishing Server
Initializing a cell . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 246 Examplecreating SIM data in BMC Atrium CMDB from BAROC files . . . . . . 248 Purging and deleting service model objects . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 249 Publishing in automated or manual mode. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 250 Publishing from a Direct Publish source. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 252 About home cell and cell alias . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 253 About class and slot data . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 255 Enabling Direct Publish publishing . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 255 Creating an environment for SIM management data . . . . . . . . . . . . . . . . . . . . . . . 256 Publishing SIM management data from exclusive environment . . . . . . . . . . . . . 256 Creating an environment for component instances and relationships . . . . . . . . 257 Modifying home cell and cell aliases . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 257 Initializing a cell from a Direct Publish environment. . . . . . . . . . . . . . . . . . . . . . . 258 Examplesusing cell aliases for Direct Publish publishing . . . . . . . . . . . . . . . . . 258 Securing publish environments . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 260 pserver.conf file and parameters . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 262 Configuring the Notify ARDBC plug-in . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 266
Starting and stopping the BMC Impact Publishing Server

BMC Impact Publishing Server is installed in the MCELL_HOME directory. It runs as a service (or process). Clients, such as the BMC Impact Service Model Editor and command line interfaces (CLIs) communicate with BMC Impact Publishing Server by using the Java Messaging Service (JMS) of the BMC Impact Portal.
Starting and stopping BMC Impact Publishing Server on Windows

The installation process creates a service named BMC Impact Publishing Server ps_hostName with Startup type Automatic. When the computer is rebooted, the BMC Impact Publishing Server ps_hostName service is automatically started. The service also starts automatically after installation.
To start the BMC Impact Publishing Server on Windows platforms by using services 1 Open the Services window by choosing Start => Settings => Control Panel =>
Administrative Tools => Services.
2 Select BMC Impact Publishing Server ps_hostName.
212
Starting and stopping BMC Impact Publishing Server on Windows
3 Click Start Service. To start the BMC Impact Publishing Server on Windows platforms by using the net start command 1 Select Start => Programs => Command Prompt. 2 Enter the following command:
net start "BMC Impact Publishing Server ps_hostName"
To start the BMC Impact Publishing Server from a command prompt 1 Select Start => Programs => Command Prompt. 2 Enter the following command:
pserver
This command defaults to pserver -b ps_hostName, so it starts BMC Impact Publishing Server ps_hostName. On Windows only, pserver always runs in the foreground, so the -d option has no affect.
To stop the BMC Impact Publishing Server on Windows platforms by using services 1 Open the Services window by choosing Start => Settings => Control Panel =>
Administrative Tools => Services.
2 Select BMC Impact Publishing Server ps_hostName. 3 Click Stop Service. To stop the BMC Impact Publishing Server on Windows platforms by using the net start command 1 Select Start => Programs => Command Prompt. 2 Enter the following command:
net stop "BMC Impact Publishing Server ps_hostName"
213
Starting and stopping BMC Impact Publishing Server on UNIX
To stop the BMC Impact Publishing Server from a command prompt 1 Select Start => Programs => Command Prompt. 2 Enter the following command:
pscontrol stop
Starting and stopping BMC Impact Publishing Server on UNIX

The installation process creates the script BMCImpactPublishingServer in /etc/init.d. When you reboot the computer, the daemon BMCImpactPublishingServer automatically starts. After install, the daemon BMCImpactPublishingServer automatically starts.
To start the BMC Impact Publishing Server as a daemon on UNIX platforms

Execute the command: pserver This command defaults to pserver -b ps_hostName
To start the BMC Impact Publishing Server in the foreground on UNIX platforms
Execute the command: pserver -d which defaults to pserver -b ps_hostName -d
To stop the BMC Impact Publishing Server on Unix platforms

Execute the command: pscontrol stop
214

This section contains general guidelines to remember when working with publication logs.
s
After you submit a promotion request in BMC Impact Service Model Editor, the promotion results dialog box reports only the success or failure of a promotion. It does not offer information about publication status. Detailed information about each publication is available in the request log files. A request log file exists for every publish request containing detailed information as to why publication failed and must be consulted to diagnose a publication failure. All request logs are available in BMC Impact Service Model Editor's publish history. Publish logs can also be retrieved by using the CLI command plog -s <requestId> | plogdisplay -@ (see plogObtaining the XML log for a request on page 304). BMC recommends that you give every promotion a unique description because that makes it easier to locate a specific publish in the BMC Impact Service Model Editors publish history. Another way to find the correct publication in the publish history is to use the promotion ID. BMC Impact Publishing Server includes detailed messages from the different products it communicates with (such as BMC Impact Portal, BMC Atrium CMDB, and BMC Impact Managers). To understand and troubleshoot these messages, consult the documentation of the product.
Viewing publication history

At any time, you can use the Promote and Publish History command in BMC Impact Service Model Editor to review publication information, including failures. The Promote and Publish History command displays the status and date and time of requests. Information in the Publication errors section of the Publish tab can help you troubleshoot publication failures.
To view publication history 1 From the menu bar, choose Tools => Promote and Publish History. 2 To view publication details, select the Publish tab, then select the publication for
which you want to see details in the Publication History table area. The list of recent publications is in reverse chronological order, that is, the most recent is listed first.
215

This section contains information on viewing publication history details.
To view publication history details 1 From the menu bar, choose Tools => Promote and Publish History.
The list of recent publications is in reverse chronological order, that is, the most recent is listed first. By default, 100 publication log files are saved; when the 101st log is saved, the first log is deleted. All BMC Impact Publishing Server requests are counted (not only publish and initialization, but also classinfo (for example, export) requests). You can change the RequestHistorySize parameter in pserver.conf to modify the default number of logs saved.
2 To view publication details, select the Publication tab, then select the publication
for which you want to see details in the Publication History table area.
A On the Publication Details tab, review the detailed information for the
publication you selected. Failures are displayed in red. If the failure is the result of a particular component instance, the component type and component name are included. To open a View with the component instance, select the failure and click Open in New View.
B On the Publication Errors tab (available only if there were failures associated
with the selected publication), review the failure information. You can sort on any column and, if the column width limit truncates the text, the tooltip displays the complete text string.
C In the Recommended Action area, review the action to correct the problem with
publish.
NOTE
You can replace the action recommended by BMC Software, add to it, or modify it by editing the pslog_error_solutions.properties file located in the BMC_PORTAL_KIT_HOME\appserver\websdk\tools\jboss\server\all\conf\resourc es\en_US\smsConsoleServer directory on the server running BMC Portal.
3 Click Close.
216
Specifying a port for Service Model Manager
Specifying a port for Service Model Manager

The Service Model Manager (smmgr) is a service (or process) 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. To specify a fixed port for Service Model Manager, in the file MCELL_HOME/etc/cellName/smmgr.conf, change the parameter ServerPort to a specific port number. The default value is 0, which means that any port number can be used. If the specified port is not available when Service Model Manager is started, start up fails.
High availability and BMC Impact Publishing Server

When a publish request is received by the BMC Impact Publishing Server component, the Publishing Server automatically connects to the active server (either primary or secondary) and publishes. To determine which server was active for a specific publish, look in the request log. For information about publishing logs, see Working with publication logs on page 126. If neither the primary nor the secondary server is active, then the publish request fails. The request log indicates that neither server is active. If the active server goes down during a publish, then the publication fails. When a server is active again, you must manually re-execute the publish on the active server with the CLI publish command. For automated publications, there are default retrials, but if the specified number of retrials was executed while there was no active server, and a new retrial will not be executed after one of the servers becomes active, you must execute the publish command again. For information about the CLI command publish, see publishPublishing a service model or viewing instances to be published on page 322.
217
Monitoring BMC Impact Publishing Server with BMC Impact Manager events
Monitoring BMC Impact Publishing Server with BMC Impact Manager events
This section describes how to monitor the BMC Impact Publishing Server using BMC Impact Manager events. By default, the BMC Impact Publishing Server sends event information to the Impact Administration Cell (IAC). Users with Full Access and Service Administrator access can monitor the status of BMC Impact Publishing Server in BMC Impact Explorer on the Impact Administration Cell subtab. For the request, connection, and error events, see the Events tab. For more information about Impact Administration Cells, see BMC Impact Solutions: General Administration. You can view all generated events in BMC IX on the Events tab in the collector "By Location - System - Publishing Server". Also, the IAC creates ADMIN_EVENTs for the control events of BMC Impact Publishing Server, so you can view the status of the BMC Impact Publishing Server in the Infrastructure Management view of BMC IX. If automated AtriumCMDB Publishing is enabled, you should monitor the publish requests to find publication failures.
Modifying the generation of events

The BMC Impact Publishing Server creates status, connection, and publish request information that describes the internal state of the BMC Impact Publishing Server and its connection to the BMC Atrium CMDB and BMC Impact Manager cells. To modify the BMC Impact Publishing Server events sent to a cell, you make changes in configuration files. Table 43 describes the types of events with an example, the configuration file for each, and the location of the configuration file.
218
Modifying the generation of events
Table 43
BMC Impact Publishing Server event generation

Example event message Configuration Configuration file location file name on the BMC Impact Manager computer pserver.conf MCELL_HOME/etc/ps_hostName/ pserver.conf or if this file does not exist, then MCELL_HOME/etc/pserver.conf pserver.conf MCELL_HOME/etc/ps_hostName/ pserver.conf or if this file does not exist, then MCELL_HOME/etc/pserver.conf 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
BMC Impact controlstatus events generated when BMC Impact Publishing Server Publishing Server starts or started stops in a controlled way serverName connectionevents connection failure. generated when the BMC Impact Publishing Server makes a connection with one of its surrounding components requestevents generated for every publish and classinfo request that is processed by Publishing Server errorevents that indicate there is a problem with the correct functioning of the BMC Impact Publishing Server Class validation request failed.
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 Impact Administration 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
219
Understanding classes and slots for BMC Impact Publishing Server events
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.
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 Impact Publishing Server service or process.
Table 44 describes the Common Event Model (CEM) slots (defined in CORE_EVENT) and values that are applicable to all events generated by BMC Impact Publishing Server.
220
Table 44
Slot name
Common Event Model (CEM) slots

Description high-level normalized category of the object the event represents identifies the class of an object Default value
OPERATIONS_MANAGEMENT
Slot label in BMC IX
mc_event_category Category mc_object_class Object Class
for status events of the publishing server itself =

BMC Impact Publishing Server
for status events of the automated publishing service of the publishing server = BMC Impact
Publishing Server Automated Publishing
mc_object mc_host_class mc_host mc_host_address
Object Host Class Host Host Address
name of the BMC Impact Publishing Server instance type of host
ps_hostname Computer
name of the computer on which BMC not defined Impact Publishing Server is running network address of the host computer on which BMC Impact Publishing Server is running identifies the event management system type not defined
mc_origin_class mc_origin
Origin Class 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 IP address of the host computer on which BMC Impact Publishing Server is running
BMC Impact Publishing Server ps_hostName
mc_tool_address
Tool Address
not defined
Event classes and slots specific to BMC Impact Publishing Server

The event classes that are specific to BMC Impact Publishing Server are subclasses of the class IPS_EVENT. The class hierarchy for IPS_EVENT is
221
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 SIM 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 Impact Publishing Server error events of the class IPS_ERROR.
IPS_STARTImpact Publishing Server start

The IPS_START class contains events that occur when the BMC Impact Publishing Server service (or process) is started or when automated publishing is started. Table 45
Slot name
process_run_id
IPS_START slots
Slot label in BMC IX Process Run ID Description All IPS_CONTROL events that are generated from the same processing run of BMC Impact 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 Impact Publishing Server:
s s
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 Impact Publishing Server service (or process) is stopped.
222
Table 46
Slot name
IPS_STOP slots
Slot label in BMC IX Process Run ID Description All IPS_CONTROL events that are generated from the same processing run of BMC Impact 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 Impact Publishing Server:
s s
process_run_id
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 Impact Publishing Server starts and display configuration information for the Publishing Server instance, as shown in Table 47. Event generation for this class is enabled by default. Table 47
Slot name
os_class os_version process_run_id
IPS_CONFIG slots (part 1 of 2)

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 Impact 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)
Process Run ID
ps_version ps_build_number ps_build_date home_dir conf_file kb_dir log_dir mcell_dir
IPS Version IPS Build Number IPS Build Date Home Directory Configuration File KB Directory Log Directory Cell Directory File
223
Table 47
Slot name
IPS_CONFIG slots (part 2 of 2)

Trace Configuration File Trace File
Description 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
trace_conf trace_file
IPS_CONNECTImpact Publishing Server connect

The IPS_CONNECT class contains events that occur when BMC Impact Publishing Server tries to establish a connection to other components. Table 48
Slot name
ips_request_id
IPS_CONNECT slots
Request ID
Description the ID of the request sent to the BMC Impact Publishing Server The connection is required for the processing of the request. For every request, IPS_CONNECT events are created for every component that needs to be connected.
destination
Destination
type of the component to which BMC Impact Publishing Server is connecting; possible values are:
s s s
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 BMC Impact Publishing Server is connecting host and port number of the computer to which BMC Impact 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

s s
SCS when the connection succeeds FLR when the connection fails
224
IPS_IM_CONNECTImpact Publishing Server connect

The IPS_IM_CONNECT class contains events that occur when BMC Impact Publishing Server tries to establish a connection to an Impact Manager cell. Table 49
Slot name
dst_location2
IPS_IM_CONNECT slots
Slot label in BMC IX Destination Secondary Location Description host and port number of the secondary Impact Manager server, if high availability is enabled
IPS_REQUESTBMC Impact Publishing Server request

The IPS_REQUEST class contains events that occur when BMC Impact Publishing Server receives a request (for example, a request for a publishing preview). Table 50
Slot name
severity
IPS_REQUEST slots (part 1 of 2)

Severity
Description enables you to follow the status of a request When the request is sent to the BMC Impact Publishing Server, the severity is INFO. When the BMC Impact Publishing Server finishes the processing of this request, it updates the severity of the event:
s s
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 Service Model Editor promotion, this slot displays the ReconJobRunId and the PromotionId.
request_id
Request ID
the ID of the request sent to the BMC Impact 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. See Diagnosing publication failures on page 335.
request_msg
Request Message
the content of the request (for example, EnvId=PROD; Queue=T) This is the internal communication protocol, useful for debugging.
225
Table 50
Slot name
IPS_REQUEST slots (part 2 of 2)

Request Result
Description initially UNK (unknown) Set to SCS (success) or FLR (failure) when processing is terminated.
request_result
result_msg
Result Message
brief description of the success or the failure of the handled request For example, Request failed: Publish verification of IM(s) failed. You can find more detailed failure messages in the request log.
user_id
User ID
the logon user ID of the requestor For automated publishes that are invoked from a BMC Impact Service Model Editor promotion, this slot displays the BMC Impact Service Model Editor 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 Service Model Editor promotion, this slot displays the BMC Impact Service Model Editor promotion comment. For publishes from a CLI, this slot displays the description you enter when using the -s option.
226
IPS_PUBLISHBMC Impact Publishing Server publish request

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

s
validation when the classInfo request happens with the CLI command pclassinfo n cellName
export when the classInfo request is generated with BMC Impact Service Model Editor export meta data functions, or with the CLI command pclassinfo -x
227
About SIM management data
IPS_ERRORBMC Impact Publishing Server errors

IPS_ERROR events are different from other events in the IPS_EVENT class. They report issues that occur with the BMC Impact Publishing Server, while other IPS_EVENTs
report information. Table 53

Slot name
severity
IPS_ERROR slots
Severity
Description indicates the seriousness of the event The default is WARNING
IPS_ENVBMC Impact 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:
s s s s
creation of a publish environment modification of a publish environment initialization of CMDB datasets of a AtriumCMDB? publish environment removal of a publish environment IPS_ENV slots
Slot label in BMC IX Origin ID Environment ID Environment Request Type Description contains the origin ID (AtriumCMDB or DirectPublish) of the publish environment contains the IDs of the publish environment contains the action open, set, init or close
Table 54
Slot name
origin_id env_id env_type
About SIM management data

Management data are the data that are referred to by component instances and impact relationships. Management data is always common to all cells of a publish environment. A default set of management data is in the SIM CMDB extension as well as in the kb/data directory of BMC Impact Publishing Server. Each SIM management data instance may be published once and only once to a cell. Before a component or an impact relationship can refer to a particular SIM management data instance, it must be published.
228
Understanding publish 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). If AtriumCMDB Publish is not enabled, best practice for Direct Publish environments is to create a publish environment that has only SIM management data. Then, any other Direct Publish environments that you create on the cell use that management data. For example, you could create an environment MgmtDataEnv and publish the management data to it using pposter.
WARNING
Loading SIM management data more than once on a cell causes the publication to fail. If you define one environment (EnvA) that has both SIM management data and component instances and relationships, define another environment for the cell (EnvB), and then delete EnvA, management data is also deleted. This causes publications to EnvB to fail because the required management data no longer exists in the cell.
If the HomeCell of the environment is set, management data is published to it. If it is not set, management data is published to all cells defined in CellAliases. If you want to publish SIM data from a Direct Publish source to a cell that
s
already has service model data that originated from BMC Atrium CMDB, then management data has already been published to the cell and you do not have to manually send it has no service model data that originates from the BMC Atrium CMDB, then you must send service management data to the cell manually, using the CLI command
pposter
will have service model data that originates from BMC Atrium CMDB, but does not yet (you will execute a pposter command before data is published from BMC Atrium CMDB), you must initialize the environment with management data by executing the command
pinit -n cellName
which defaults to pinit -n cellName -e PROD (which initializes from the Atrium CMDB PROD publish environment).
Understanding publish environments

A publish environment defines the source of the data and the cells to which the data is sent.
229
About publish environments
You can secure publish environments by password protecting them.
About publish environments

A publish is always executed within a set of conditions defined by the requirements of the SIM data. This set of conditions is referred to as a publish 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 Impact Publishing Server. The BMC Impact Publishing Server component supports publishing SIM data (service model data and management data) from two sources or origins: BMC Atrium CMDB, which is referred to as an Atrium Publish Feed or from BAROC source files using the CLI command pposter, which is referred to as Direct Publish Feed.
Publish origin BMC Atrium CMDB Publish is initiated from
s s s
OriginID AtriumCMDB
BMC Impact Service Model Editor termination of reconciliation job CLI command publish CLI command pposter
Direct Publish
DirectPublish
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 publish environments in your enterprise have unique identifiers.
Specifying the publish origin

Publishing from these two origins is enabled or disabled with configuration parameters (AtriumCMDBPublishOrigin and DirectPublishOrigin) 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 disabled by default and is initiated either through an API program or the CLI command pposter.
230
About home cell, home cell alias, and cell alias
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, to 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 Impact Publishing Server to determine the cells to which a component instance is sent, depending on which have values. CellAliases and HomeCell are parameters of the publish environment, whereas HomeCell and HomeCellAlias are attributes of the component instance. 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 publish 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, but in a single publish environment, a cell can have only one cell alias. 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 DirectPublish environments, even if it is also used in AtriumCMDB environment. Cell-alias to cell-name values must already be defined when publishing is initiated.
Determining the cell to which a component is published

To determine the cell to which a component is published, the BMC Impact Publishing Server uses the following algorithm: 1. If HomeCell is defined for the publish 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 publish environment. 3. If one of the CellAliases defined for the publish environment has empty CellAlias, then its cell name is used as the default cell. Every component that has no HomeCellAlias set is published to this default cell.
231
Publishing from the BMC Atrium CMDB
Publishing from the BMC Atrium CMDB

In the case of AtriumCMDB Publish environments,
s
you can promote SIM objects in the BMC Impact Service Model Editor product, which triggers reconciliation and when that terminates, publishing of the objects to the cells you can reconcile from any BMC Atrium CMDB reconciliation dataset you can use the Send to test function in BMC Impact Service Model Editor, in which case, the parameters of the environment are defined and managed for you, based on choices you make in the BMC Impact Service Model Editor you can create other AtriumCMDB Publish environments for advanced staging, for which you define the parameters of the environment using the CLI command penv.
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 respective BMC Impact Manager cells. New objects coming from a discovery source (such as BMC Topology Discovery or BMC Foundation Discovery) are not flagged as In-Model and are therefore ignored by BMC Impact Publishing Server. If discovery sources provide updates to objects that are flagged as In-Model, these changes are sent to the cells.
Enabling AtriumCMDB Publish publishing

AtriumCMDB Publish is enabled by default, with a parameter in the pserver.conf file, located in MCELL_HOME/etc, ServiceModelPublish = T. (Default = T.) For AtriumCMDB environments, cell information is looked up from the class SIM_CellInformation from the BMC.ASSET dataset of BMC Atrium CMDB. The Impact Administration Server (IAS) creates this information whenever you administer a cell.
232
Using BMC Impact Service Model Editor

When the source of the service model data is the BMC Atrium CMDB and you are using BMC Impact Service Model Editor, the BMC Impact Publishing Server component can handle all of the requirements for standard publishing. BMC Impact Publishing Server defines the proper publishing environment based on choices you make in BMC Impact Service Model Editor and can automatically deliver the SIM data to the cell after you promote the objects in BMC Impact Service Model Editor.
About cell alias

When you use only the BMC Impact Service Model Editor 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 Service Model Editor, every component instance 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.
s
When you register a cell in BMC Impact Portal and define it as production, an alias with the same name as the cell name is defined and stored in the SIM_CellAlias CMDB class in the dataset BMC.ASSET. When you send service model objects to test in the BMC Impact Service Model Editor (using the Send to test function), all existing aliases are mapped to the test cell you chose for the test in BMC Impact Service Model Editor.
Cell alias cellA cellB cellC Cell name (prod cell) cellA cellB cellC Cell name (test cell) testcell1 testcell1 testcell1
Component SL Appl SL DB SL Server
In production the three component instances are sent to the production cells: cellA, cellB, and cellC. When you send them to test in BMC Impact Service Model Editor, they are all sent to the same test cell, testcell1.
233
About the production environment

An AtriumCMDB Publish environment consists of an asset dataset, by default BMC.ASSET.EnvId and an impact dataset, BMC.IMPACT.EnvId. The production AtriumCMDB publish environment has the following two datasets:
Datasets 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
s s
Description contains objects to be published
Comments
s
read-only; can be updated only by the CMDB Reconciliation Engine as objects are reconciled not limited to objects that are in-model 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 Impact Publishing Server as objects are published a service model object is successfully published when a copy of it is in this dataset in the BMC Atrium CMDB
impact dataset: by default, BMC.IMPACT.PROD
contains objects that have been successfully published This dataset is a master copy of the service model data in the asset dataset regular dataset
The production service model data is in the BMC Atrium CMDB in the production dataset BMC.ASSET. After you promote service model objects in BMC Impact Service Model Editor, these changes are reconciled in the production dataset and then stored in the production dataset BMC.IMPACT.PROD upon successful publication, which mirrors the last successful publish to the cells.
WARNING
To ensure that the service model data in the BMC Atrium CMDB and in the cell are synchronized, the data in the impact dataset should be managed solely by BMC Impact Publishing Server.
234
About test environments

When you select Send To Test Objects In Current View in BMC Impact Service Model Editor, a request is sent to the BMC Impact Publishing Server to open a test environment. The test environment consists of two datasets:
s s
asset dataset BMC.ASSET.user.Test.1 impact dataset BMC.IMPACT.user.Test.1
BMC Impact Service Model Editor puts the service model data that was sent to test into the asset dataset (BMC.ASSET.user.Test.1) of the new test environment and requests a publication from the BMC Impact Publishing Server. The BMC Impact Publishing Server then looks up the test cell for the cell alias of every component. The last successful publish to the test cells is mirrored in the impact dataset BMC.IMPACT.user.Test.1. The Send to Test function
s s s s
validates the existence of or creates a test publish environment for the user validates the existence of an available test cell for publishing updates entries in the Cellalias table for the current environment empties test datasets of previous contents
A test cell contains only the latest objects sent to test. Any previous objects are removed. Test objects cannot be added to the Console Navigation Tree in BMC Impact Service Model Editor, which means they cannot be monitored in BMC Impact Portal. After a successful publish, the BMC Atrium CMDB contains entries in the BMC.ASSET.user.TEST.1 and BMC.IMPACT.user.TEST.1 datasets for the environment.
WARNING
To ensure that the service model data in the BMC Atrium CMDB and in the cell are synchronized, only the BMC Impact BMC Impact Publishing Server should modify the data in the impact test dataset.
The BMC Impact Service Model Editor test publish environments have an overlay asset dataset, with the production dataset as underlying dataset.
s
To have all management data instances of the production dataset in the test environment, publish mode Overlay is used for PublishModeMgmtData. To be able to cut down the test to a limited number of components and impact relationships the publish mode Current is used for PublishModeServiceModel.
235
Creating advanced publish environments
Creating advanced publish environments

To do advanced publishing for SIM data in AtriumCMDB Publish environments, you need to Table 55
Basic steps 1. Determine the cells to use and create if necessary.
Basic steps to create advanced test environments

How to do See BMC Impact Solutions: General Administration.
2. Register any new cells in BMC Impact See BMC Impact Solutions: General Portal (which automatically creates them Administration. in BMC Atrium CMDB). 3. Determine the source of the service model data (another environment or a BAROC source file). Use the penv init parameters SourceEnvMgmtData and
SourceEnvServiceModel or SourceBarocMgmtData and SourceBarocServiceModel
Create 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. Monitor services. 8. Troubleshoot problems. Execute a CLI command publish In BMC Impact Explorer, on the Services tab See Appendix A, Troubleshooting 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 publish environments. For more information about these topics, see penv Managing publish environments on page 292. In an AtriumCMDB Publish environment, the cell is automatically initialized with SIM management data of the asset dataset of the environment when you execute the CLI command publish.
Home cell and home cell alias

If all component instances and relationships are being published to one cell, you can assign a home cell by
s s
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
236
Examples of advanced environments
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.
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 in instances of the BMC.ASSET dataset in the BMC Atrium CMDB class BMC.SIM.CONFIG:SIM_CellAliases. The values that are assigned at the time of publishing are also stored in the dataset BMC.IMPACT.PROD.
s s s
set the attribute EnvId to the ID of the publish environment set the attribute CellAlias to the alias set the attribute CellName to the name of a cell that is registered in BMC Impact Portal (registered in the class SIM_CellInformation)
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 class BMC.SIM.CONFIG:SIM_Cellaliases like
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 Service Model Editor 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.
237
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 publish environment, the HomeCell parameter of the publish environment is defined. Both the production publish environment and the simulation publish environment use the production asset dataset BMC.ASSET. The last successful publish of the production publish environment is saved in BMC.IMPACT.PROD. The last successful publish of the simulation publish environment SIMULATION is saved in BMC.IMPACT.SIMULATION. 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 publish 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 publish environment. To create a simulation publish 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
238
Defining BMC Atrium CMDB classes for SIM
This command creates only the simulation publish environment, not the production publish environment, which should already exist since it is created by default. To create a simulation publish 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 SIM

Not all BMC Atrium CMDB classes have component instances that are useful for impact analysis. In order to be published to SIM, BMC Atrium CMDB classes must have the attribute Custom Properties = 100050. You can qualify classes that are not defined as SIM classes out-of-the-box.
To define a class as a SIM class

1. In Remedy User's Class Manager Console, add the value 100050 to the existing Custom Properties. 2. Export the modified SIM class information by executing the CLI command pclassinfo -x. 3. Update the Knowledge Base of the cells and recompile. For more information, see Adding new classes to the BMC Atrium CMDB on page 202.
Defining BMC Atrium CMDB attributes for SIM

Not all of the CMDB attributes of SIM classes are useful for SIM. In order to be published to SIM, CMDB attributes must have attribute Custom Properties = 300050. You can qualify attributes that are not defined as SIM attributes out-of-the-box.
To define an attribute as a SIM attribute

1. In Remedy User's Class Manager Console, add the value 300050 to the existing Custom Properties. 2. Export the modified SIM class information by executing the CLI command pclassinfo -x.
Chapter 9 Managing BMC Impact Publishing Server 239
ServiceModelSet attribute for components and management data
3. Update the Knowledge Base of the cells and recompile.
ServiceModelSet attribute for components and management data

All SIM classes in the BMC Atrium CMDB have a ServiceModelSet attribute. This attribute makes it possible for data to be in the BMC Atrium CMDB but not be included in any data published to a SIM cell. Possible values are listed in Table 56. Table 56
Value IN
ServiceModelSet attribute values

Description indicates the data instance is in the service model In-model component instances are published to the cell.
OUT
indicates the data instance is not in the service model Out-of-model instances are not published to the cell. default value
OUT_OF_IN
indicates the data instance was in the model but has since been removed from the model At the next publication, the instance is removed from the cell.
For a component in the BMC Atrium CMDB to be considered for publishing by BMC Impact Publishing Server, this attribute must contain specific values:
s
Only CIs with ServiceModelSet IN or OUT_OF_IN are considered by the BMC Impact Publishing Server. The value IN indicates that the CI is included in the service model published to a SIM cell. The value OUT_OF_IN indicates that the CI is not included in the service model published to SIM.
To ensure synchronization between the impact dataset in BMC Atrium CMDB and the service model in a SIM cell, ServiceModelSet cannot be reset to OUT after it has been IN or OUT_OF_IN. Every CI that has a ServiceModelSet value of IN or OUT_OF_IN should have a ReconciliationIdentity defined. See also In-model and not-in-model component instances on page 73.
240
ServiceModelSet attribute for impact relationships
ServiceModelSet attribute for impact relationships

For an impact relationship, the value in ServiceModelSet is calculated from the ServiceModelSet values assigned to the relationships consumer and provider component instances and is determined in the manner shown in Table 57 on page 241. Table 57 Determination of ServiceModelSet value for an impact relationship
and if component instance 2 Then value of ServiceModelSet has value for the impact relationship is
IN IN OUT_OF_IN OUT OUT_OF_IN IN OUT OUT OUT IN OUT_OF_IN
If component instance 1 has value

IN OUT_OF_IN IN OUT_OF_IN OUT OUT IN OUT
The determination is:

s
If both instances are assigned IN, then the ServiceModelSet value for the impact relationship is IN. If either or both are assigned OUT_OF_IN, then the relationship is defined as OUT_OF_IN. If either or both are assigned OUT, then the relationship is defined as OUT.
Initializing the BMC Atrium CMDB with SIM data

SIM requires service management data for successful operations. During installation of SIMs 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 publish environments other than those with an asset dataset BMC.ASSET or overlay asset dataset with BMC.ASSET as the underlying dataset, initialization of the environment with service management data is required for a successful publication. When you initialize a specific publish environment, objects in the asset and in the impact dataset of that environment are initialized (as well as objects in the datasets of an environment with asset dataset that overlays the asset dataset of the environment that is being initialized):
241
in the impact dataset, existing objects are removed in the asset dataset, existing objects are either removed or kept, but are moved outof-model, depending on the values in the InitEffectivelyMgmtData and InitEffectivelyServiceModel parameters new initial objects in asset dataset and in impact dataset are copied from the initialization source (see Initial source parameters on page 245)
Objects in the datasets of an environment with asset dataset that overlays the asset dataset of the environment that is being initialized are also initialized. For more information about initializing a publish environment, see also the init action command under penvManaging publish environments on page 292.
Using initialization parameters

You use the configuration parameters of the CLI command penv (with the -p option) to define the initialization. These parameters are defined in the pclient.conf configuration file, located in the MCELL_HOME/etc directory. Two of the parameters, InitEffectivelyMgmtData and InitEffectivelyServiceModel reference the attribute ServiceModelSet. Table 58 lists and describes the parameters for initializing. Table 58
Parameter
InitEffectivelyMgmtData
Parameters in the pclient.conf file for initializing the BMC Atrium CMDB
Description determines which management data instances are removed from the BMC Atrium CMDB during initialization or reinitialization, based on the value in the ServiceModelSet class attribute relationship instances are removed from the BMC Atrium CMDB during initialization or reinitialization, based on the value assigned in the SeviceModelSet class attribute
InitEffectivelyServiceModel determines which service model component and impact
InitMgmtData InitServiceModel SourceBarocMgmtData SourceBarocServiceModel SourceEnvMgmtData SourceEnvServiceModel
specifies whether management data is initialized specifies whether service model data is initialized specifies the BAROC files from which the default or initial management data instances are copied specifies the BAROC files from which initial components and impact relationships are copied specifies the publish environment. From its datasets the default or initial management data instances are copied specifies the publish environment. From its datasets the initial components and impact relationships are copied
242
InitEffectively parameters
The two InitEffectively parameters determine the retention of the existing instances in the asset dataset when initializing. Only the IN and OUT values for ServiceModelSet attribute are taken into consideration.
InitEffectivelyMgmtData relates to management data instances. InitEffectivelyServiceModel relates to component instances and impact
relationship instances. When the objects in the BAROC file have a value in the mc_udid slot, keeping existing data may be impossible. In BMC Atrium CMDB, the DatasetId and the ReconciliationIdentity must be unique.
InitEffectivelyMgmtData parameter settings and their results

Table 59 lists the possible values for the InitEffectivelyMgmtData configuration parameter and the subsequent actions taken during BMC Atrium CMDB reinitialization. Table 59 InitEffectivelyMgmtData parameter values and results (part 1 of 2)
Resulting actions on asset management data during Atrium CMDB reinitialization If set to this default value, all current management data instances are removed from the BMC Atrium CMDB. Management data instances with the ServiceModelSet attribute value of IN or OUT_OF_IN are removed from the BMC Atrium CMDB.
s
InitEffectivelyMgmtData parameter setting

InitEffectivelyMgmtData=IN,OUT
InitEffectivelyMgmtData=IN
InitEffectivelyMgmtData=OUT
Management data instances with ServiceModelSet attribute value of OUT are removed from the BMC Atrium CMDB. Management data instances with the ServiceModelSet attribute value of IN or OUT_OF_IN have their attribute value reset to OUT.
243
Table 59
InitEffectivelyMgmtData parameter values and results (part 2 of 2)

Resulting actions on asset management data during Atrium CMDB reinitialization If set to an empty list (default), these actions occur
s
InitEffectivelyMgmtData parameter setting

InitEffectivelyMgmtData=
Existing management data instances are kept in the BMC Atrium CMDB. Instances with the ServiceModelSet attribute value of IN or OUT_OF_IN have their values reset to OUT.
Generally, you do not move management data in and out of model. Therefore, you do not want to keep existing management data instances. In fact, some of the default management data instances have a mc_udid set, which makes it impossible to keep them. In order to keep a backup of custom management data instances, which is useful when you must reinitialize the production environment, export them to BAROC files by using the CLI command mquery. The default management data BAROC files are stored in the file:
MCELL_HOME\etc\ps_hostname\kb\data
244
InitEffectivelyServiceModel parameter settings and their results

Table 60 lists the possible values for the InitEffectivelyServiceModel configuration parameter and the subsequent actions taken during BMC Atrium CMDB reinitialization. Table 60 InitEffectivelyServiceModel parameter settings and results
Resulting actions on service model asset component instances and impact relationships during BMC Atrium CMDB reinitialization If set to an empty list (default), these actions occur
s
InitEffectivelyServiceModel parameter setting

InitEffectivelyServiceModel=
all service model component or impact relationship instances are not removed from the BMC Atrium CMDB components and impact relationships with the ServiceModelSet attribute value of IN or OUT_OF_IN have their attribute value reset to OUT
The default initialization does not contain any component or impact relationship. Generally, when reinitializing you do not want to lose components and impact relationships that were already defined or that were detected by a discovery tool. When you reinitialize, you need to browse the existing components and decide if they still need to be in model.
InitEffectivelyServiceModel=IN
Components and impact relationships with the ServiceModelSet attribute value of IN or OUT_OF_IN are removed from the BMC Atrium CMDB.
InitEffectivelyServiceModel=IN, OUT All components and impact relationships, regardless of the value of ServiceModelSet
being IN, OUT_OF_IN or OUT, are removed from the BMC Atrium CMDB.
Initial source parameters

The initial data can come from
s s
BAROC files another publish environment (asset and impact datasets)
245
Initializing a cell
By default, the source of service management data for the production publish environment (BMC.ASSET and BMC.IMPACT.PROD) is the BAROC files in MCELL_HOME/etc/ps_hostname/kb/data/.load. For other AtriumCMDB publish environments, the production environment is the source. If the source is BAROC files, then the baroc instances are copied to the asset dataset and the impact dataset. If the source is a publish environment, then the instances from the impact dataset of the source publish environment are copied to the impact dataset of the publish environment that is being initialized. Likewise, the instances from the asset dataset of the source publish environment are copied to the asset dataset of the publish environment that is being initialized. In copying to the asset dataset, the type (Overlay or Regular) and the publish mode (Overlay or Current) is taken into account. If the asset dataset is an overlay dataset and the publish mode is overlay and the initialization's source is the underlying asset dataset, then effectively no copies are taken.
Initializing a cell
Initialization deletes all existing SIM data (service model data and service management data) of the publish environment from the cell. For an AtriumCMDB publish environment, it sends the contents of the BMC Atrium CMDB impact dataset to the cells. When a cell is initialized, existing events are associated with new copies of components, so status information of component instances is not lost. You reinitialize a cell by using the CLI command pinit. Typically, you reinitialize only when
s s s
a cell is reinstalled (restart the cell with the -i option) a cell must be restarted for recovery purposes SIM 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 Impact 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 data in the impact dataset (like BMC.IMPACT.PROD) is sent by the BMC Impact Publishing Server to the cells. When only DirectPublish publishing is enabled, then you have to initialize the new cell with management data manually.
246
Initializing a cell
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 pinitInitializing a cell with service model data on page 301.
247
Examplecreating SIM data in BMC Atrium CMDB from BAROC files
Examplecreating SIM data in BMC Atrium CMDB from BAROC files

In this scenario, the goal is to initialize the publish 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
248
Purging and deleting service model objects
Sending service model data to a cell using a BAROC source file

To initialize the publish 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 "SourceBarocServiceModel=etc/kb/data_dept1/.load" init -v
The service model is created in the asset and impact datasets 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 Impact Publishing Server is able to process their deletion. Ensure that you have retention rules on the Reconciliation's Purge activities for SIM classes. Occasionally, when objects have been purged or hard deleted in BMC Atrium CMDB before being published, the BMC Impact 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
249
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 Impact Publishing Server automatically publishes service model objects to the cells. The BMC Impact 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 publish Publishing a service model or viewing instances to be published on page 322.
Switching between automated publish and manual publish

By default, the BMC Impact 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 Impact Publishing Server is running, execute the command pscontrol automated or pscontrol manual.
Automated publish considerations

When automated publish is enabled,
s
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
250
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 Impact Publishing Server that the reconciliation job has terminated. BMC Impact Publishing Server looks up changes to SIM data in the asset dataset since the last successful publication and attempts to publish the changes to the specified cells on publish environments for which automated publication is enabled. When the automated publisher is temporarily off, notifications from a reconciliation job run are saved in BMC Impact 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 publish environments with regular asset dataset, so a promotion from BMC Impact Service Model Editor to a production cell is automatically published. By default, automated publish is disabled on publish environments with overlay asset dataset and an overlay publish mode, so a reconciliation to an asset dataset of a SME test environment to a test cell is not automatically published.
251
Publishing from a Direct Publish source
Determining the current publish mode

To determine the current publish mode in which the BMC Impact Publishing Server is running, execute the CLI command psstat. One of the following messages is returned:
s s s
Started - Starting Automated mode Started - Automated mode Started - Manual mode
For more information about psstat, see psstatDisplaying status of BMC Impact Publishing Server on page 321.
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 publish 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 61 Basic process of publishing from a Direct Publish source
For instructions, see Enabling Direct Publish publishing on page 255. Creating an environment for SIM management data on page 256 Publishing SIM management data from exclusive environment on page 256 Creating an environment for component instances and relationships on page 257
Basic process 1. Enable Direct Publishing. 2. Create a Direct Publish environment for the SIM management data. 3. Publish the SIM management data from the Direct Publish environment. 4. Create a Direct Publish environment for component instances and impact relationships.
252
About home cell and cell alias
Table 61
Basic process of publishing from a Direct Publish source

For instructions, see pposterSending service model objects to a cell on page 307 pposterSending service model objects to a cell on page 307
Basic process 5. Create a source file that contains the service model data in BAROC format. 6. Send service model data in the BAROC source file to the cells.

Table 62 describes the parameters that apply to a Direct Publish environment. Table 62 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 SIM 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 Impact Publishing Server uses the following algorithm: 1. If a HomeCell is defined for the publish 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 publish environment's CellAliases parameter are used.
253
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 publish 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 Impact Publishing Server uses the following algorithm: 1. If HomeCell is defined for the publish 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 publish 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 publish 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 publish 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 publish 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 publish 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.
254
About class and slot data
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 publish environment, then management data is send
to HomeCell.
2 Management data is sent to all cells defined in the CellAliases of the publish
environment.
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 Configuration file and parameters for CLIs on page 273. The attributes or slots in the source files must also exist in the cell or the publication fails. All slots that are defined in the source files for pposter, except possibly HomeCell, HomeCellAlias, Consumer.HomeCell, Consumer.HomeCellAlias, Provider.HomeCell, and Provider.HomeCellAlias are published to the cell.
Enabling Direct Publish publishing

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 DirectPublish 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 Impact Publishing Server share the file.
255
Creating an environment for SIM management data
Creating an environment for SIM management data

Creating an environment exclusively for SIM management data makes managing this data easier because you will not remove it when executing a reinitialization on the environment by which the management data was published. Create a Direct Publish environment exclusively for SIM management data by executing a command similar to the following:
penv open -e MgmtDataEnv -p OriginId = DirectPublish
MgmtDataEnv represents the ID of the environment (or you can use MgmtDataEnv as the literal ID of the environment for SIM management data).
Publishing SIM management data from exclusive environment

Publish default SIM management data by executing the pposter CLI command for all the BAROC files that are in the MCELL_HOME/etc/ps_hostName/kb/data directory.
EXAMPLE
>pposter -e MgmtDataEnv -v MCELL_HOME/etc/ps_hostName/kb/data/ di_event.mapping.baroc >pposter -e MgmtDataEnv -v MCELL_HOME/etc/ps_hostName/kb/data/ di_models.baroc >pposter -e MgmtDataEnv -v MCELL_HOME/etc/ps_hostName/kb/data/ sim_downtime_status.baroc >pposter -e MgmtDataEnv -v MCELL_HOME/etc/ps_hostName/kb/data/ sim_schedules.baroc >pposter -e MgmtDataEnv -v MCELL_HOME/etc/ps_hostName/kb/data/ sim_self_priority_mapping.baroc
NOTE
Do not use the files in the MCELL_HOME/etc/hostName/kb/data folder because this default folder does not contain any mc_udids, which are needed.
256
Creating an environment for component instances and relationships
Creating an environment for component instances and relationships

Sending SIM data to one cell
When all the SIM data for the environment goes to one cell, you can define the cell once 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
EnvId represents the name of the environment you are creating. cellName represents the name of the cell to which you are sending objects.
Sending SIM data to multiple cells

When SIM data for the environment goes to more than one cell, you need to define cell aliases with the parameter CellAliases. Create a Direct Publish environment and define CellAliases by executing a similar command (depending on the number of cells):
penv open -e EnvId -p OriginId=DirectPublish -p CellAliases = [cellAlias1, cellName1, cellAlias2, cellName2]
EnvId represents the name of the environment you are creating. cellAlias# represents the cell alias to which you are sending objects. cellName# represents the name of the cell to which you are sending objects with the preceding cell alias.
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="
257
Initializing a cell from a Direct Publish environment
To change the value of CellAliases to null (unset or remove the value), use the following command:
penv set -e EnvId -p "CellAliases="
Initializing a cell from a Direct Publish environment

Initializing a cell from a Direct Publish environment consists of deleting all existing SIM data of the publish 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 pinitInitializing a cell with service model data on page 301.
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:
Examplesusing cell aliases for Direct Publish publishing
EXAMPLE
penv open -e Sales -p OriginId = DirectPublish -p CellAliases = [austin, austin, brussels, brussels]
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]
259
Securing publish 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 component instances defined with HomeCellAlias = austin, the service model objects are sent to the cell austin_training because the Sales.Training environment was defined with cellalias-to-cellname pairs as austin, austin_training and brussels, brussels_training. See Determining the cell to which a component is published on page 253.

You can control the execution of publishes for a specific publish 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 Impact 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 publish 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 publish 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.
260
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 publish 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:
261
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 Impact Publishing Server. For changes to this file to take affect, you must restart the BMC Impact Publishing Server service or process. Table 63 describes the default pserver.conf file and all its parameters.
262
Table 63
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 Impact Publishing Server Description specifies the name of the log directory for the BMC Impact Publishing Server enables (T) or disables (F) publishing from BMC Atrium CMDB to a cell Default value log T (true)
Parameter name
SystemLogDirName AtriumCMDBPublishOrigin AtriumCMDBHeartbeatInterval
sets the length of time that BMC Impact Publishing 180 (seconds) 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.
AtriumCMDBPreviewTimeout
sets the length of time that BMC Impact Publishing Server waits for an answer to cancel or commit the publish after publish preview When no answer is received after this interval, the publish is cancelled.
180 (seconds)
DirectPublishOrigin
DirectPublishHeatbeatInterval
enables (T) or disables (F) direct publishing feed
F (false)
180 (seconds) sets the length of time that BMC Impact Publishing Server waits for a heartbeat, a direct request, or a close from a client When no heartbeat is received after this interval, the publish is cancelled.
JNPServers
defines the host and port of JNP Servers When the Portal is set up in cluster mode, this value must match the same value in the pclient.conf file.
localhost:9379
JMSCommWarnReconnectCount
the number of times to retry to establish JMS communication If the trial fails then an IPS_ERROR event with message "Unable to establish JMS communications." of severity WARNING is generated. If JMSCommWarnReconnectCount is -1 then retries continue indefinitely.
30 (reconnect attempts)
JMSCommWarnReconnectInterval the interval (in seconds) between two reconnection
10 (seconds)
attempts
263
Table 63
pserver.conf file
the number of times to retry to establish JMS communication If the trial fails then an IPS_ERROR event with message "Unable to establish JMS communications." of severity MAJOR is generated. If JMSCommMajorReconnectCount is -1 then retries continue indefinitely. -1 (connection attempts)
JMSCommMajorReconnectCount
JMSCommMajorReconnectInterval
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
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
RequestHistorySize CellConnectionTimeout
sets the maximum number of request log files that are retained by the BMC Impact Publishing Server
100
sets the length of time the BMC Impact Publishing 60 (seconds) Server maintains 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 BMC Impact Publishing Server event generation. 2000 300 (seconds) mcell.dir
IMMessageBufferSize IMMessageBufferKeepSent IMFileDirectoryName
PaswordLogging 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)
264
Table 63
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 120 (seconds) 300 (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 BMC Impact Publishing Server and the AR Notify plugin for heartbeat. 0 or a negative value disables heartbeat. sets the length of time that BMC Impact Publishing Server waits for an answer to a heartbeat from the AR Notify plugin.
-1 (seconds)
AutomatedHeartbeatTimeout
5 (seconds)
265
Configuring the Notify ARDBC plug-in
Table 63
pserver.conf file
the maximum number of times automated publishing is retried after failures
n represents the number of repeated publication attempts:
s s s
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 BMC Impact 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 BMC Impact Publishing automated Server starts or restarts. When the BMC Impact Publishing Server is running, you can change the publishing mode by using requests (using the CLI command pscontrol). By default, the BMC Impact Publishing Server starts in automated mode. defines the cell to which BMC Impact Publishing Server events are sent not defined, set by install to Impact Administration Cell all subclassess of IPS_EVENT
IPSEventsIM
IPSEventClasses
defines the event classes for which BMC Impact Publishing Server events are created

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
266
After you make changes to these parameters, restart BMC Remedy AR System so the changes take affect. Table 64
Parameter
BMC-ARDBC-NOTIFY-Verify-Log
ar.cfg file parameter descriptions

Description log file location Default value Remedy AR System/ Impact directory 0
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
267
268
Chapter
10
10
BMC Impact Publishing Server CLIs

Use the BMC Impact Publishing Server Command Line Interface (CLI) to
s s s s s s s
start the BMC Impact Publishing Server service or daemon stop the BMC Impact Publishing Server service or daemon initiate a service model publish create service model data (with a BAROC source file) create, initialize, and close publish environments request and review information about BMC Impact Publishing Server execution compare service model class definitions on cells with the class definitions in the BMC Atrium Configuration Management Database (BMC Atrium CMDB)
This appendix provides reference information on the BMC Impact Publishing Server CLIs. It contains the following topics: Installing the CLIs on another computer . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 270 Configuring BMC Impact Publishing Server CLIs . . . . . . . . . . . . . . . . . . . . . . . . . . . . 272 Configuration file and parameters for CLIs . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 273 Changing the time-out values for all the CLI commands . . . . . . . . . . . . . . . . . . . 279 Setting the configuration for a specific CLI command . . . . . . . . . . . . . . . . . . . . . 280 Setting up automatic authentication of CLI commands . . . . . . . . . . . . . . . . . . . . 280 Specifying the BMC Impact Administration Server used for CLI authentication . . 281 Configuring trace for CLIs . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 281 Understanding common command options for CLIs. . . . . . . . . . . . . . . . . . . . . . . . . . 281 Understanding return codes for CLIs . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 283 Using CLI commands . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 287 Summary of CLI commands for BMC Impact Publishing Server . . . . . . . . . . . . 287 pclassinfoComparing service model classes on cells with class definitions in the BMC Atrium CMDB . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 289 penvManaging publish environments . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 292 pinitInitializing a cell with service model data . . . . . . . . . . . . . . . . . . . . . . . . . . 301 plogObtaining the XML log for a request . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 304 plogdisplayConverting the XML log for a request to text format . . . . . . . . . . 306 pposterSending service model objects to a cell . . . . . . . . . . . . . . . . . . . . . . . . . . 307
Chapter 10
269
Installing the CLIs on another computer
pscontrolSending a command to BMC Impact Publishing Server . . . . . . . . . . 318 pserverStarting the BMC Impact Publishing Server service or daemon . . . . . 320 psstatDisplaying status of BMC Impact Publishing Server. . . . . . . . . . . . . . . . 321 publishPublishing a service model or viewing instances to be published . . . 322

You can set up the BMC Impact Publishing Server CLIs on another computer so that you can run CLI commands for the BMC Impact Publishing Server and manage service model publishing remotely.
NOTE
pserver must be run from only one computer at a time, and BMC Software recommends that you do not install pserver on multiple computers. The only valid situation for which pserver should be installed on multiple boxes is for a high availability scenario. In this case, multiple pservers share the same log directory, so that when the primary server goes down, the pserver of the secondary server can immediately be started and take over.
To set up the BMC Impact Publishing Server CLI on a remote computer 1 Copy the following CLI commands from the MCELL_HOME/bin directory to the
MCELL_HOME/bin directory on the remote computer.
s s s s s s s s s
pclassinfo penv pinit plog plogdisplay pposter pscontrol psstat publish
2 Adjust the script setenv_pcli to set the correct environment variables JAVA_HOME
and IM_HOME.
270
3 Copy the MCELL_HOME/etc directory with the following contained files and
directories to the equivalent /etc directory on the remote computer.
s s s s s s s s s s s s
pclient.conf locale/imapi.properties locale/ixsmsg.properties locale/mcmdmsg.properties locale/pclient.load locale/psmsg.properties locale/pclientmsg.properties locale/pclimsg.properties locale/mcellmsg.properties locale/mccompmsg.properties locale/psautomated.properties locale/messages.properties
4 Copy the following files and directories from the MCELL_HOME/lib directory to the
equivalent /lib directory on the remote computer.
s s s s s s s s s
commons-cli-1.0.jar imapi.jar ixscomm.jar log4j-1.2.15.jar pcli.jar pslog.jar psapi.jar jboss directory jwsdp directory
5 Edit the pclient.conf file with a text editor to change the JNPServers parameter value
to identify the host computer on which the BMC Portal resides (and provides JNDI services). The other parameters do not need to be modified when copying CLIs on another host.
Chapter 10
271
Configuring BMC Impact Publishing Server CLIs
When you run a BMC Impact Publishing Server CLI command on a computer that is not a BMC Portal host computer, you must provide the user credentials to the specified BMC Portal server. You can provide all the authentication information as arguments of the -i common option of the CLI command. Or, with the proper configuration, when you run a CLI command remotely, you can:
s
authenticate automatically; see Setting up automatic authentication of CLI commands on page 280 provide only user credentials on the command; see Specifying the BMC Impact Administration Server used for CLI authentication on page 281
Configuring BMC Impact Publishing Server CLIs

You configure the BMC Impact Publishing Server CLI by using a text editor to set the parameter values in the pclient.conf file located in the MCELL_HOME/etc directory. You can
s
configure the CLI to change the length of time that CLI commands wait for an acknowledgement of a request (ConnectionInitTimeout) or for the completion of a request (RequestTimeout). See Changing the time-out values for all the CLI commands on page 279. eliminate the need to provide full user credentials for authentication when you run a CLI command remotely. You can: set automatic authentication up by specifying the user name, password, and host computer for authentication. Then, when you run a CLI command remotely, you do not need to use the -i option to authenticate. See Setting up automatic authentication of CLI commands on page 280. specify the BMC Impact Administration Server (IAS) for authentication. Then, when you run a CLI command remotely, you must provide only the user name and password arguments for authentication. See Specifying the BMC Impact Administration Server used for CLI authentication on page 281.
272
Configuration file and parameters for CLIs

Table 65 on page 273 lists and describes the configuration parameters for BMC Impact Publishing Server CLIs, located in the MCELL_HOME/etc/pclient.conf file. Table 65
Parameter JNPServers
pclient.conf parameters (part 1 of 7)

Description host and port of the naming service of BMC Impact Portal. When the Portal is set up in cluster mode, the values must match. Default value <host of Portal>: 9379
IASServers
specifies the BMC Impact Administration Server (usually by localhost: 3084 host name) that authenticates the CLI commands If you specify a remote BMC Impact Administration Server in the pclient.conf file but do not provide user credentials, you must provide them as command line arguments when you run a CLI command. Two BMC Impact Administration Servers can be setup as a high availability pair. To do this, you must enter both servers as a comma separated list, for example: primaryIAS:3084,secondaryIAS:3084 The p-CLIs first attempt to connect the BMC Impact Administration Server on the host primaryIAS. If that connection attempt fails, an attempt is made to connect to the BMC Impact Administration Server on the host secondaryIAS. Note that this is not only applicable to nodes of a high availability BMC Impact Administration Server pair. You can specify more than one independent BMC Impact Administration Server. The p-CLIs attempt to connect to the first BMC Impact Administration Server. If that connection attempt fails, an attempt is made to connect to the next server in the list and so on until a connection is successful.
IASUsername
specifies a valid BMC Impact Administration Server user name to be presented as credentials to the specified BMC Impact Administration Server
none
Chapter 10
273
Table 65
Parameter

Description Default value none specifies the valid BMC Impact Administration Server password for the specified BMC Impact Administration Server (IASUsername) to be presented as credentials for the specified BMC Impact Administration Server Enter the IASPassword as plain text. Upon the first execution, it is encrypted. To set remote automatic authentication of CLI commands up, specify the user name (IASUserName), and password (IASPassword) to be used as valid credentials for the specified BMC Impact Administration Server (IASServers) in the pclient.conf file.
IASPassword
ConnectionInitTimeout
5 seconds sets the length of time, measured in seconds, that a CLI command on making a request waits for the acknowledging reply from the BMC Impact Publishing Server, or if the Portal is not running, or the Portal's JMS service is not up and running Normally, the BMC Impact Publishing Server immediately acknowledges any request that it receives. If this time-out expires, it often indicates the BMC Impact Publishing Server is not receiving the request. For example, the BMC Impact Publishing Server service is not running.
RequestTimeout
sets the length of time, measured in seconds, that a CLI command waits for the processing of an acknowledged request to complete Depending on the type of request, request processing may take a reasonable amount of time. If this time-out period expires, the CLI command stops following the request processing and, if possible, cancels the request.
3600 seconds
Locale
outputs messages in the language of the specified locale if message resource files for the language are defined. The format is language[_country]. Language is a valid 2-letter ISO Language Code as defined by ISO-639. Country is a valid 2-letter ISO Country Code as defined by ISO-3166. indicates whether the Publishing Server should look for additions, modifications, and soft deletions that are to be published. The option is set to T when an automated publication is triggered from a reconciliation job with Merge activity
inherits systems locale
Parameters specific to the publish CLI command Merge T
Purge
F indicates whether the Publishing Server should look for hard deletions that are to be published. This option is set to T when an automated publication is triggered from a reconciliation job with Purge activity
274
Table 65
Parameter Password

Description Default value sets the password of a secured publish environment for the none execution of the publish CLI command indicates whether pposter should stop when encountering invalid data in the source file If ContinueOnFailure is set to T, true (default), pposter sends as much data as possible, skipping invalid data in the source file. If ContinueOnFailure is set to F, false, pposter stops as soon as invalid data in the source file is encountered and no data is sent to the cell, not even those items processed before the incorrect data in the source file. T
Parameters specific to the pposter CLI command ContinueOnFailure
Init
when set to T (true), pposter removes all existing data in the F cell of the publish environment and recopies the data in the input BAROC file to the cell when set to F (false), pposter incrementally updates the cell of the publish environment with data in the input BAROC file
Password
sets the password of a secured publish environment for the none execution of the pposter CLI command specifies the asset dataset name sets the asset dataset type options are Regular or Overlay BMC.ASSET. EnvId Regular
Parameters specific to the penv CLI command

AssetDataSetId AssetDataSetType
AssetUnderlyingDataSetId
sets the underlying dataset ID Used when AssetDataSetType = Overlay
BMC.ASSET
AutomatedPublish
enables (T) or disables (F) automated publishing on the publish environment The default value is T, except for an overlay publish environment (an overlay dataset which has a publish mode of overlay), which defaults to F. In this way, automated publication is by default enabled on PROD environment, and is disabled by default on test environments of BMC Impact Service Model Editor.
T (true)
Chapter 10
275
Table 65
Parameter

Description defines cell alias and cell name pairs that are unique in a given environment, in the BAROC list of string format: [cellAlias,cellName[,cellAlias,cellName]] This parameter applies only on Direct Publish environments. For Atrium CMDB environments, cells aliases cannot be created or modified with the penv CLI command. Default value not defined
CellAliases
Cells
If cell aliases are not used, you can set this parameter as an alternative, in the BAROC list of string format: [cellName[,cellName]] This parameter applies only on Direct Publish environments.
not defined
CloseAliases
enables (T) or disables (F) the removal of aliases of an environment; this releases the cells for use in another environment enables (T) or disables (F) the removal of the asset dataset along with all objects in the dataset
F (false)
CloseAsset CloseCells
F (false)
enables (T) or disables (F) the removal of all data instances T (true) (including management data) of the service model from the cells specifies a description for the environment to BMC Asset EnvDesc sets the environment name to BMC Asset EnvId sets the format of information to Raw (a parsable data stream) or Display (readable by a user) specific to the CLI; it is not sent to the Publishing Server as a request BMC Asset EnvDesc BMC Asset EnvId Display
EnvDesc EnvName Format
HomeCell
sets the cell to which the entire service model is published If set, CellAliases are not used.
not set
InitEffectivelyMgmtData
determines which asset management data instances, based on the value assigned to their ServiceModelSet class attribute, are removed from the BMC Atrium CMDB Before setting this parameter, please refer to InitEffectively parameters on page 243 which discusses the effect of the possible InitEffectivelyMgmtData settings on management data retention in or removal from the BMC Atrium CMDB.
IN, OUT
276
Table 65
Parameter

Description determines which service model component and impact relationship instances, based on the value assigned to their ServiceModelSet attribute, are removed from the BMC Atrium CMDB asset dataset Before setting this parameter, please refer to InitEffectively parameters on page 243 that discusses the effect of the possible InitEffectivelyServiceModel settings on SIM component instance retention in or removal from the BMC Atrium CMDB. By default, all service model component or impact relationship instances are not removed from the BMC Atrium CMDB. Asset instances with the ServiceModelSet attribute value of IN or OUT_OF_IN have their attribute value reset to OUT. Default value blank
InitEffectivelyServiceModel
InitMgmtData InitServiceModel Level
specifies whether management data are initialized, T (true) or F (false)
specifies whether the service model is initialized, T (true) or T F (false) determines the amount of information display by the info 0 action command. Cell names and aliases are displayed only when -p Level=1 is part of the command string. sets a new password for a secured environment confirms a new password for a secured environment specifies the origin of the environment options are AtriumCMDB or DirectPublish not defined not defined AtriumCMDB
NewPassword1 NewPassword2 OriginId
Password PublishModeMgmtData
sets a password for a secured environment determines the mask used when retrieving publishable management data instances if AssetDataSetType =
Overlay
not defined Overlay
if Overlay, all instances of the overlay dataset, as well as the underlying dataset, are considered if Current, only instances of the overlay dataset are considered.
Chapter 10
277
Table 65
Parameter

Description determines the mask used when retrieving publishable components and impact relationships, if
AssetDataSetType = Overlay
Default value Overlay
PublishModeServiceModel
used when the dataset type is overlay, this parameter determines the mask used when retrieving publishable service model instances. if Overlay, all instances of the overlay dataset, as well as the underlying dataset, are considered if Current, only instances of the overlay dataset are considered.
SIM
enables (T) or disables (F) the classes that may be published T (true) for the Direct Publish environments only if T, only SIM classes may be published if F, components and relationships of MC_SM_COMPONENT, MC_SM_RELATIONSHIP, and all subclasses cannot be published
SourceBarocMgmtData
causes the import of initial management data from instances in the .baroc files pointed to in the .load file. Service model instances in those files are ignored. This parameter cannot be set if SourceEnvMgmtData is set.
MCELL_HOME /etc/<PSName >/kb/data/.loa d
This is the default value for the PROD environment.

SourceBarocServiceModel
causes the import of initial service model data from instances in the .baroc files pointed to in the .load file. Management data in those files are ignored. This parameter cannot be set if SourceEnvServiceModel is set.
MCELL_HOME /etc/<PSName >/kb/data/.loa d
This is the default value for the PROD environment.
278
Changing the time-out values for all the CLI commands
Table 65
Parameter

Description causes initial management data to be imported from instances of the source environment EnvId. Default value PROD environment
SourceEnvMgmtData
SourceEnvMgmtData cannot be set if SourceBarocMgmtData This is the
is set.
default value for all environments other than PROD. PROD, for reinitialization of environments other than PROD
SourceEnvServiceModel
causes initial service model data to be imported from instances in the asset dataset in the source environment EnvId. Data are created in the asset dataset of the environment. If the asset dataset of source environment is an overlay dataset and EnvId refers to an underlying regular dataset, then:
s s
If PublishModeServiceModel is Overlay, no instances are created in the overlay dataset. If PublishModeServiceModel is Current, all instances will be created in the overlay dataset.
SourceEnvServiceModel cannot be set if SourceBarocServiceModel is set.
Changing the time-out values for all the CLI commands

You can change the length of time that CLI commands wait for an acknowledgement of a request (ConnectionInitTimeout) or for the completion of a request (RequestTimeout).
To set the time-out values for all the CLI commands

Use a text editor to edit the pclient.conf file located in the MCELL_HOME/etc directory and change the values set of these parameters:
s s
ConnectionInitTimeout RequestTimeout
Chapter 10
279
Setting the configuration for a specific CLI command
Setting the configuration for a specific CLI command

If you want to customize a configuration for a specific CLI command, you can create a configuration file just for it; for example, pposter.conf.
To set the configuration for specific CLI command 1 Make a copy of the pclient.conf file and name it CLIcommand.conf where
CLIcommand is the name of the CLI command for which you are creating a special configuration; for example: pposter.conf.
2 Save the file in the MCELL_HOME/etc directory. 3 Edit the new configuration file with a text editor and set the appropriate parameter
values. When the CLI command is run, the values in the appropriate configuration file are used. Alternately, you can use the -c option (see Understanding common command options for CLIs on page 281).
Setting up automatic authentication of CLI commands

You can define the credentials to be used to automatically authenticate CLI commands being run remotely. This eliminates the need to use the -i command option to manually enter user credentials.
To set up the automatic authentication of CLI commands 1 Edit the pclient.conf file located in the MCELL_HOME/etc directory of the computer
on which you run the BMC Impact Publishing Server CLI commands, using a text editor.
2 Type the name or names of the BMC Impact Administration Server to which you
are presenting a valid user credential as the value or values for the BIPServers parameter.
3 Type a valid user name for the specified BMC Impact Administration Server
(IASServers) as the IASUsername parameter value.
4 Type the valid password for the specified user name (IASUsername) as the
IASPassword parameter value.
Enter the IASPassword in plain text. Upon the first execution, it is encrypted.
280
Specifying the BMC Impact Administration Server used for CLI authentication
5 Save the file.
Specifying the BMC Impact Administration Server used for CLI authentication
You can specify the BMC Impact Administration Server to use for authentication when you run a CLI command. Then, when you run a CLI command remotely, you can enter only the -i option user name and password arguments to authenticate.
To specify the BMC Impact Administration Server to use for authentication 1 Edit the pclient.conf file located in the MCELL_HOME/etc directory of the computer
on which you run the BMC Impact Publishing Server CLI commands with a text editor.
2 Edit the IASServers parameter to specify the name of the BMC Impact
Administration Server to use for authentication in the pclient.conf file.
3 Save and close the file.
Configuring trace for CLIs

You set and configure tracing of the BMC Impact Publishing Server CLIs in the MCELL_HOME\etc\pclient.trace file. By default, only fatal, error, and warning messages appear in the trace file MCELL_HOME/tmp/pcli/pcli.trace. You can enable the inclusion of informational and debugging messages for specific packages and subpackages by editing the pclient.trace file and removing the comment character (# ) from the lines that contain the value =DEBUG.
Understanding common command options for CLIs

Many BMC Impact Publishing Server CLI commands use the same option to perform the same function. This section describes the options that may be used by multiple commands.
Chapter 10
281
Understanding common command options for CLIs
Syntax for common options

[-c ConfigFile] [-h|-?] [-i User/Password[@Host[/Port][,Host[/Port][,...]]] [-q] [-l HomeLocation] {-p "Var=Value"} [-r RequestLogFile] [-t ConnectionInitTimeout] [-u RequestTimeout] [-v] [-z]
Common command options

Table 66 describes the common options for the BMC Impact Publishing Server CLI commands. Table 66 BMC Impact Publishing Server CLI common command options (part 1 of 2)
Description specifies another configuration file to use instead of the default MCELL_HOME\etc\pclient.conf file displays help information, including command syntax and options authenticates the specified user name and password with the BMC Impact Administration Server running on the specified host computer and port; you can specify multiple hosts and ports If executing a CLI command on the BMC Impact Administration Server host computer, this option is optional. However, if you do use this option for local authentication and the credentials that you provide are invalid, the command will fail. If executing a CLI command on a computer that is remote to the BMC Impact Administration Server host computer, this option is required, with all arguments. You can configure the CLI to eliminate the need to provide full user credentials for authentication when you run a CLI command remotely. You can:
s
Option Syntax
-c ConfigFile -h -? -i User/Password[@Host [/Port][,Host[/Port] [,...]]]
set up automatic authentication in the pclient.conf file by specifying the user name, password, and host computer for authentication. See Setting up automatic authentication of CLI commands on page 280. specify the BMC Impact Administration Server to use for authentication in the pclient.conf file. Then you must enter only the user name and password arguments to authenticate. See Specifying the BMC Impact Administration Server used for CLI authentication on page 281.
282
Understanding return codes for CLIs
Table 66
BMC Impact Publishing Server CLI common command options (part 2 of 2)

Description specifies a home directory other than MCELL_HOME for the command sets an option (Var) to the specified value (Value); this option modifies and overrides a value defined in the configuration file invokes quiet execution (no banner appears) retrieves the XML-formatted log file and stores it as
RequestLogFile
Option Syntax
-l HomeLocation -p "Var=Value" -q -r RequestLogFile
By default, the location of the log file is relative to the directory where you run the CLI. If you provide only a file name, the file is created in the directory where you run the CLI. You can also provide the absolute path for the log file.
-t ConnectionInitTimeout -u RequestTimeout
specifies the length of time, in seconds, for the command to wait for a connection before terminating; default is 5 seconds specifies the length of time, in seconds, for the command request to wait for an answer before terminating; default is 3600 seconds activates verbose mode to display more information (such as detailed failure messages) displays version information and ends command
-v -z

When a BMC Impact Publishing Server CLI command or a 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 publishing CLI trace file MCELL_HOME\tmp\pcli\pcli.trace. These exit codes, their meanings, and recommended remedial actions are described in Table 67. Table 67
Error Exit Code 1 2
BMC Impact Publishing Server and sim2cmdb CLI error exit codes (part 1 of 3)
Description indicates a syntax error on one or more command line arguments or options indicates an invalid number option
Recommended remedial action Verify the correct syntax for the command string. Verify the correct syntax for the numerical options such as -t and -u.
Chapter 10
283
Table 67
Error Exit Code 3
Description
Recommended remedial action
indicates that the home directory Do the following: (MCELL_HOME) of the application can not be found 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 (-l HomeLocation) path at the command line.
10
indicates a generic (unspecified) error
(This is an internal error.) Do the following: 1. Enable tracing and execute the command again to have a trace. 2. Locate the pcli.trace file to submit to BMC Software Support. pcli.trace is located in MCELL_HOME/tmp/pcli. 3. Contact BMC Software Support and file a user case for this failure.
11
indicates that the CLI is unable to initialize Retry the command. If the error still occurs, do the its communication layer following: 1. Verify that the URL of the provider specified in the pclient.conf file (in the MCELL_HOME/etc directory) is correct. 2. Restart the BMC Portal and BMC Impact Publishing Server. 3. Try the command again.
12
indicates a communication failure when the CLI sent data to its communication provider, for example, the jBoss server
Retry the command. If the error still occurs, do the following: 1. Restart the BMC Portal and BMC Impact Publishing Server. 2. Try the command again.
284
Table 67
Error Exit Code 13
Description indicates that the CLI cannot decode an answer that it has received from its communication provider
Recommended remedial action (This is an internal error.) Do the following: 1. Enable tracing and execute the command again so there is an entry in the trace file. 2. Locate the pcli.trace file (MCELL_HOME/tmp/pcli ) to submit to BMC Software Support. 3. Contact BMC Software Support and file a user case for this failure.
14
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 Impact Administration Server Do the following:
s
15 16
If you are running a CLI command, verify the credentials that you specified. If automatic authentication is set up in the pclient.conf file, verify that the credentials (IASUsername, IASPassword, and IASServers) are valid.
17
indicates an Impact interface initialization Do the following: failure; for example the I18N configuration may be wrong Verify that the file MCELL_HOME/etc/locale/pclient.load exists on the host where the pcli is running/installed. indicates that the UTF-8 character set is not The host computer must support the UTF-8 character supported by the host set. indicates that the CLI does not have a request identifier Do the following: 1. Enable tracing and execute the command again to generate a trace. 2. Locate the pcli.trace file (MCELL_HOME/tmp/pcli) to submit to BMC Software Support. 3. Contact BMC Software Support and file a user case for this failure.
18 19
20
indicates an I/O error when the publishing Verify that the write permission is set for the publishing log file is written request log file. You specify the name of the RequestLogFile for a CLI command by using the -r common option
Chapter 10
285
Return codes for pserver
Return codes for pserver

The pserver command has return codes that differ from other CLI commands. These exit codes, their meanings, and recommended remedial actions are described in Table 68. Table 68
Error Exit Code 1
pserver error exit codes (part 1 of 2)
Description indicates that the HomeLocation system property is not set
Recommended remedial action Do the following: 1. Verify that the MCELL_HOME environment variable is set for the application. 2. Verify that the CLI script (.bat or .sh) file correctly contains: -DHomeLocation=%MCELL_HOME% 3. Specify the home directory (-l HomeLocation) path at the command line.
2 3 4 5 6 7 9 10
indicates the log directory cannot be created
Ensure the pserver user has write access to MCELL_HOME/log.
indicates that the log/ps.lock file cannot be Ensure the pserver user has write access to created MCELL_HOME/log. indicates another Publishing Server is already running indicates the CMDB interface cannot initialize Verify with fuser (Unix) that a process is keeping a lock on ps.lock. If not, remove ps.lock. Verify ARServer and BMC Atrium CMDB settings and installation.
indicates the Impact Administration Server Verify BMC Impact Administration Server settings and interface cannot initialize installation. indicates a configuration file is missing indicates an I/O exception occurred on a configuration file indicates a syntax error Provide the configuration file. Ensure the pserver user has write access to the configuration file. Check the syntax you used for the command and try the command again.
286
Using CLI commands
Table 68
Error Exit Code 11
pserver error exit codes (part 2 of 2)
Description
Recommended remedial action
indicates the home directory does not exist Do the following: 1. Verify that the MCELL_HOME environment variable is set for the application. 2. Verify that the CLI script (.bat or .sh) file correctly contains: -DHomeLocation=%MCELL_HOME% 3. Specify the home directory (-l HomeLocation) path at the command line.
12 13
indicates a security exception error on the home directory
Ensure the pserver user has write access to the home directory.
indicates an I/O exception occurred during Ensure the pserver user has write access to the creation of the MCELL_HOME/tmp. HomeLocation/tmp/ps.trace file indicates the publish environments cannot be initialized Verify that the SIM CMDB extension of the same version as the Publishing Server is installed.
14
Using CLI commands

This section provides information on how you use BMC Impact Publishing Server CLI commands, including functions, syntax, and examples.
Summary of CLI commands for BMC Impact Publishing Server

Table 69 lists all of the available BMC Impact Publishing Server CLI commands and provides a brief description of the purpose for each command. You can invoke BMC Impact Publishing Server CLI commands from a command prompt on Windows, from a UNIX operating system prompt, or from a script, either locally on the BMC Portal host computer or remotely on another computer. To use the BMC Impact Publishing Server CLI commands remotely, you must copy the CLI installation to the remote host and configure the CLI for remote access See Configuring BMC Impact Publishing Server CLIs on page 272.
Chapter 10
287
Summary of CLI commands for BMC Impact Publishing Server
Table 69
Command
BMC Impact Publishing Server CLI command descriptions

Description Page compares the service model class definitions on a cell or 289 cells with the class definitions in the BMC Atrium CMDB and lists the differences You can also use this command to export service model class definitions from the BMC Atrium CMDB.
pclassinfo
penv
enables you to set up advanced environments and staging 292 scenarios beyond the abilities of the Send to Test commands available in BMC Impact Service Model Editor initializes or reinitializes cells with service model impact data obtains the XML log for a specific service model publishing request and routes it to standard output Use this command with the plogdisplay command. 301 304
pinit plog
plogdisplay pposter
displays the XML log for a specific service model publishing in text format to standard output sends SIM elements, such as component instances, relationships, and management data to cells by using the BMC Impact Publishing Server sends a specific command (automated, manual, stop) to the BMC Impact Publishing Server starts the BMC Impact Publishing Server service or daemon The major differences between pserver and the other BMC Impact Publishing Server CLI commands are:
s s
306 307
pscontrol pserver
318 320
s s
the exit codes are different pserver is the BMC Impact Publishing Server itself, while the others are CLI commands that communicate with the server the configuration files and tracing files are different although possible, the process for copying pserver to another computer is different, and performance considerations should be taken into account 321
psstat
returns the status (starting, started, or stopping) and mode (automated or manual) of the BMC Impact Publishing Server publishes service model or displays (-w) the service model objects to be published
publish
322
288
pclassinfoComparing service model classes on cells with class definitions in the BMC Atrium CMDB
Use the pclassinfo command to
s
compare the service model class definitions on a specific cell or cells with the service model class definitions in the BMC Atrium CMDB and list the differences between them. export the service model class definitions from the BMC Atrium CMDB.
pclassinfo syntax
pclassinfo <common options> [-n cellName1[,cellName2[...]] |-a | -x] [-o OutputFile] [-s Description]
pclassinfo command options

Table 70 lists the options for pclassinfo. There are no required options for pclassinfo. Table 70
Options <common options> -? -c -h -i -l -p -q -t -u -v -z -a
pclassinfo options (part 1 of 2)

Description

specifies to retrieve the service model classes from ALL the cells and compare them with the BMC Atrium CMDB service model classes specifies the specific cell or cells from which to retrieve the service model classes and compare them with the BMC Atrium CMDB service model classes On Windows platforms, you must enclose the cell list in quotation marks ("). If a cell name is not specified, the default cell name (the unqualified version of the host computer name) is used. If the cell has a different name, the command fails.
-n cellName1[,cellName2[...]]
Chapter 10
289
Table 70
Options
pclassinfo options (part 2 of 2)

Description If the -a or -n option is specified, prints the differences between the specified service model class definitions to the specified output file. If the -x option is specified, prints the service model class definitions from the BMC Atrium CMDB to the specified output file.
-o OutputFile
-s description -x
describe request exports service model class definitions from the BMC Atrium CMDB to standard output or if an output file (-o option) is specified to a file Service model class definitions are exported in BAROC language format.
pclassinfo examples
This section contains several examples of the pclassinfo command including:
s
exporting service model class definitions from the BMC Atrium CMDB to standard output exporting service model class definitions from the BMC Atrium CMDB to a file comparing cell service model class definitions with those in the BMC Atrium CMDB
Exporting service model class definitions from the BMC Atrium CMDB To export the service model class definitions in the BMC Atrium CMDB to standard output, type the following command:
pclassinfo -x
This command generates a listing of the service model class definitions defined in the BMC Atrium CMDB and outputs it to standard output. To export the service model class definitions in the BMC Atrium CMDB to a specific file, type the following command:
pclassinfo -x -o fileName
290
The service model class definitions are written to a BAROC file with the specified name. You can load this file on a cell.
Comparing cell service model class definitions with those in the BMC Atrium CMDB
To compare the service model class definitions in the cell whose name is the shortversion of its host computer name (the default cell name) with the definitions in the BMC Atrium CMDB, type the following command:
pclassinfo
If there are no differences between the service model class definitions on the cell and those defined in the BMC Atrium CMDB, the command returns output similar to the following:
MCELL_HOME\bin>pclassinfo BMC Impact Service Model Class Retriever v7.2.00 (Build 1544975.000 20-May-2008) Copyright 2005-2008 BMC Software, Inc. as an unpublished work. All rights reserved. Class info is synchronized.
If there are differences between the service model class definitions on the cell and those defined in the BMC Atrium CMDB, the command returns the differences, which appear similar to the following:
MCELL_HOME\bin>pclassinfo BMC Impact Service Model Class Retriever v7.2.00 (Build 1544975.000 20-May-2008) Copyright 2005-2008 BMC Software, Inc. as an unpublished work. All rights reserved. -- BEGIN DIFFS -<PreviewItem><Im>arwad</Im><SlotAdd><Class>BMC_BaseElement</Class><S lot>VersionNumber</CmdbSlot></SlotAdd></PreviewItem> <PreviewItem><Im>arwad</Im><ClassAdd><CmdbClass>BMC_Region</CmdbClas s></ClassAdd></PreviewItem> -- END DIFFS -Class info is not synchronized
To compare the service model class definitions in a specific cell with those defined in the BMC Atrium CMDB on Windows platforms, type the following command:
pclassinfo -n cellName
Chapter 10
291
penvManaging publish environments
NOTE
On Windows platforms, you must enclose the cell list in quotation marks (").
This command returns the differences, if there are any, between the service model class definitions on the cell named with those defined in the BMC Atrium CMDB. To compare the service model class definitions for all the cells registered with the BMC Impact Portal with those defined in the BMC Atrium CMDB, type the following command:
pclassinfo -a
This command returns the differences, if any, found between the classes defined in the BMC Atrium CMDB and the service model class definitions on all the cells found by the BMC Impact Publishing Server.
pclassinfo return codes

For information about CLI return codes, see Understanding return codes for CLIs on page 283.

Use the penv command to create and manage publishing environments when the source of the service model data is either the BMC Atrium CMDB (Atrium Publish) or the CLI pposter (Direct Publish). For more information about publish environments, see Understanding publish environments on page 229 and Publishing from a Direct Publish source on page 252. You can secure publish environments by applying a password. See Securing publish environments on page 260.
penv syntax
penv <common options> [-f] (-e EnvId (close | init | open | set)|[-e EnvID] info)
292
penv command options

Table 71 lists the options for penv. Table 71
Option <common options> -c -h -? -i -l -q -p -t -u -v -z Cells = ["["] cell1 {, cellN} ["]"]
penv options (part 1 of 2)

Description

The pair of opening and closing brackets are allowed but not mandatory. Cells extend the existing concept of the HomeCell parameter. HomeCell becomes deprecated because setting HomeCell is equivalent to setting Cells with one element. A DirectPublish environment can be created using either Cells or CellAliases. Defining a DirectPublish environment with HomeCell is supported for backward compatibility, but it is deprecated. If a CellAliases is given, a list of cells is built by the Publishing Server, consisting of all cell names found in CellAliases. The destination cell names are determined as follows:
s
If Cells contains a single element, then this cell name is used to publish all data, regardless of any cell information found in the data. If Cells contains more than one element, then for components and relationships, the destination cell must be found through the data instance: For components, the attribute HomeCell is first searched, then HomeCellAlias is searched. For relationships, the attribute consumer_home_cell is searched, then Consumer.HomeCellAlias is searched.
If no valid destination cell is found, publish fails. If HomeCellAlias is used then CellAliases must be set, otherwise publish fails.
Management data or non-SIM data (that is, instances other than components or relationships) are published to all cells. -e EnvID sets a unique identifier for the environment Default is PROD.
Chapter 10
293
Table 71
Option -f
penv options (part 2 of 2)

Description forces the command execution without prompting the user to confirm the initialization action. If the -f option is not specified, you are prompted to confirm command execution.
-s description
describe request
penv action commands: open, init, close, set, info

penv provides additional functionality with these action commands: close, info, init, open, and set. Some action commands work differently or have different
requirements, depending on the type of environment, Atrium Publish or Direct Publish, as described in Table 72. Table 72
action command close
Actions commands (part 1 of 2)

General description removes data related to the specified environment. The impact dataset and all its instances are removed. Specific to BMC Atrium CMDB environments If CloseAsset=T, asset dataset instances are removed and the asset dataset is removed; default = F (false). If CloseCells=T, cells are reinitialized with empty ServiceModel; default is T (true). If CloseAliases=T, aliases of the environment are removed, which releases the cells for usage in another environment; default is T (true). Specific to Direct Publish environments
294
Table 72
action command info
Actions commands (part 2 of 2)

General description displays information relevant to environments
s s s
Specific to BMC Atrium CMDB environments all parameters are valid except CellAliases
Specific to Direct Publish environments relevant parameters are CellAliases, Format, HomeCell, Level, and
OriginId
to display column headings, use the -v option to display cell alias information, use the -p Level=1 option Display characteristics are when HomeCell is not set, a empty string is returned () cell alias values may include blank characters cell name values do not include blank characters values containing blank characters are quoted according to the rules for quoting BAROC strings
you must include

-p OriginId=Direct Publish as part of the
command string if the EnvID is not included.
init
initializes (or reinitializes) the asset and impact datasets of the specified environment creates the asset and impact datasets of also stores the settings for the specified environment and stores the environment in the environment settings in the cell BMC Atrium CMDB after the environment is opened, you cannot modify values for PublishModeServiceModel or PublishModeMgmtData parameters
not applicable
open
data is stored only in the cell (and the source file); there is no secondary datastore
set
sets or resets the parameters of the publish environment
you can reset only parameters

AutomatedPublish, HomeCell, CellAliases, Password, NewPassword1, and NewPassword2
you can reset only parameters HomeCell, Cells, and CellAliases, Password, NewPassword1, and NewPassword2
Atrium Publish environmentsvalid parameters for each action command

Table 73 provides a brief description of the parameters in the pclient.conf configuration file for an Atrium Publish environment and specifies the parameters that are valid for each penv action command: close, info, init, open, and set. For a complete list of parameters in the pclient.conf file and additional parameter information, see Configuration file and parameters for CLIs on page 273.
Chapter 10
295
Table 73
Valid parameters for a BMC Atrium CMDB publish environment (part 1 of 2)

Description defines the asset dataset ID; default is BMC.ASSET.EnvId defines the asset dataset type as Regular or Overlay; default is Overlay defines the underlying dataset for an overlay asset dataset; default is BMC.ASSET enables (T) or disables (F) automated publication for the publish environment; default is T, except for overlay publish environments defines cellalias-to-cellname pairs that are unique to a given environment You cannot define CellAliases with the CLI command penv. close info init open set yes yes yes
Parameter name
AssetDataSetId AssetDataSetType AssetUnderlyingDataSetId
AutomatedPublish
yes
CellAliases
yes
yes
CloseAliases
enables (T) or disables (F) the removal of aliases of an environment; this releases the cells for use in another environment enables (T) or disables (F) the removal of the asset dataset along with all objects in the dataset
yes
CloseAsset
yes
CloseCells
enables (T) or disables (F) the removal yes of all data instances (including management data) of the service model from the cells describes the environment specifies the name of the environment specifies to which cell to publish. If HomeCell is set, the entire service model is published to the specified cell. In this case, CellAliases are not used defines the information displayed with
info
EnvDesc EnvName HomeCell
yes yes yes yes
Format InitEffectivelyMgmtData
yes yes
determines which asset management data instances, based on their ServiceModelSet attribute, are removed from the BMC Atrium CMDB See Configuration file and
parameters for CLIs on page 273.
296
Table 73
Valid parameters for a BMC Atrium CMDB publish environment (part 2 of 2)

Description component and impact instances, based on their ServiceModelSet attribute, are removed from the BMC Atrium CMDB close info init yes open set
Parameter name
InitEffectivelyServiceModel determines which service model
InitMgmtData
specifies whether management data are initialized, T (true) or F (false) See Configuration file and
yes

InitServiceModel
specifies whether the service model is initialized, T (true) or F (false) See Configuration file and
yes

Level NewPassword1 NewPassword2 OriginId Password PublishModeMgmtData
determines the amount of information display by the info action command specifies a new password confirms a new password defines the source of the service model yes data specifies a password for authentication yes defines whether management data should be approached as overlay or as regular dataset defines whether components and impact relationships should be approached as overlay or as regular dataset causes the import of initial management data from instances in the .baroc files pointed to in the .load file. causes the import of initial service model data from instances in the .baroc files pointed to in the .load file. causes initial management data to be imported from instances of the source environment EnvId. causes initial service model data to be imported from instances in the asset dataset in the source environment EnvId. Data are created in the asset dataset of the environment.
yes yes yes yes yes yes yes yes yes yes yes
PublishModeServiceModel
yes
SourceBarocMgmtData
yes
SourceBarocServiceModel
yes
SourceEnvMgmtData
yes
SourceEnvServiceModel
yes
Chapter 10
297
Direct Publish environmentsvalid parameters for each action command

Table 74 provides a brief description of the valid parameters in the pclient.conf configuration file for a Direct Publish environment and specifies the parameters that are valid for each penv action command: close, info, init, open, and set. For a complete list of parameters in the pclient.conf file and additional parameter information, see Configuration file and parameters for CLIs on page 273. Table 74 Valid parameters for a Direct Publish environment
Description defines cell alias and cell name pairs that are unique in an given environment defines cell names when cell aliases are not used defines the information displayed with info specifies to which cell to publish. If HomeCell is set, the whole service model is published to the specified cell. In this case, CellAliases are not used. determines the amount of information displayed by the info action command specifies a new password confirms a new password defines the source of the service model data specifies a password for authentication enables (T) or disables (F) the classes that may be published for the Direct Publish environments only if T, only SIM classes may be published if F, components and relationships of MC_SM_COMPONENT, MC_SM_RELATIONSHIP, and all subclasses cannot be published yes yes yes yes yes yes yes yes yes yes yes yes yes yes yes yes close info init open set yes yes yes
Parameter name
CellAliases Cells Format HomeCell
Level NewPassword1 NewPassword2 OriginId Password SIM
penv examples
This section contains examples of penv info. For other examples of penv, see Examples of advanced environments on page 237.
298
Example 1includes cell names and cell aliases, but no column headings
In example 1, Atrium Publish environments are displayed and cell names and cell aliases are displayed because the -p Level=1 option is used, but column headings are missing because the -v option is not used.
EXAMPLE
$ penv -p "OriginId=AtriumCMDB" -p "Level=1" info BMC Impact Publishing Server Environment Manager v7.0 (Build 666.343 - 05/21/2007) Copyright 2005-2007 BMC Software, Inc. as an unpublished work. All rights reserved. Request received and accepted by the Publishing Server requestId=Z00000emahxa59Xp9yZhyMZ6zowkZ AtriumCMDB Ghislain.TEST.1 BMC.ASSET.Ghislain.TEST.1 Overlay Current F cell1 cell2 cell3 test_ghislain test_ghislain test_ghislain BMC.IMPACT.Marcelle.TEST.1 BMC.IMPACT.PROD Overlay Regular BMC.IMPACT.Ghislain.TEST.1 Overlay
Marcelle.TEST.1 BMC.ASSET.Marcelle.TEST.1 Overlay Current F imtest PROD cell1 cell2 cell3 BMC.ASSET cell1 cell2 cell3
Example 2raw format

Example 2 displays the information in Raw format, rather than display format
EXAMPLE
$ penv -p "OriginId=AtriumCMDB" -p "Format=Raw" -p "Level=1" info BMC Impact Publishing Server Environment Manager v7.0 (Build 666.343 - 05/21/2007) Copyright 2005-2007 BMC Software, Inc. as an unpublished work. All rights reserved. Request received and accepted by the Publishing Server requestId=Z00000emahxa59Xp9sZhyMZ6zowkZ AtriumCMDB Ghislain.TEST.1 BMC.ASSET.Ghislain.TEST.1 BMC.IMPACT.Ghislain.TEST.1 Overlay Current Current F '' 3 cell1 test_ghislain cell2 test_ghislain cell3 test_ghislain Marcelle.TEST.1 BMC.ASSET.Marcelle.TEST.1 BMC.IMPACT.Marcelle.TEST.1 Overlay Current Current F imtest 0 PROD BMC.ASSET BMC.IMPACT.PROD Regular T '' 3 cell1 cell1 cell2 cell2 cell3 cell3
Chapter 10
299
Example 3includes cell aliases and column headings

In Example 3, cell aliases and column headings are included for an Atrium Publish environment.
EXAMPLE
$ penv -p "OriginId=AtriumCMDB" -p "Level=1" -v info BMC Impact Publishing Server Environment Manager v7.0 (Build 666.343 - 05/21/2007) Copyright 2005-2007 BMC Software, Inc. as an unpublished work. All rights reserved. Request received and accepted by the Publishing Server requestId=Z00000emahxa59Xp9uZhyMZ6zowkZ OriginId: AtriumCMDB -----------------------------------------------------------------------------------EnvId AssetDataSetId ImpactDataSetId AssetDataSetType PublishModeMgmtData PublishModeServiceModel AutomatedPublish HomeCell Ghislain.TEST.1 BMC.ASSET.Ghislain.TEST.1 BMC.IMPACT.Ghislain.TEST.1 Overlay Overlay Current F CellAlias CellName cell1 test_ghislain cell2 test_ghislain cell3 test_ghislain -----------------------------------------------------------------------------------------------------------------------------------------------------------------------EnvId AssetDataSetId ImpactDataSetId AssetDataSetType PublishModeMgmtData PublishModeServiceModel AutomatedPublish HomeCell Marcelle.TEST.1 BMC.ASSET.Marcelle.TEST.1 BMC.IMPACT.Marcelle.TEST.1 Overlay Overlay Current F ImTest -----------------------------------------------------------------------------------EnvId AssetDataSetId ImpactDataSetId AssetDataSetType PublishModeMgmtData PublishModeServiceModel AutomatedPublish HomeCell PROD BMC.ASSET BMC.IMPACT.PROD Regular T CellAlias CellName cell1 cell1 cell2 cell2 cell3 cell3 -------------------------------------------------------------------------------------
300
pinitInitializing a cell with service model data
Example 4Direct Publish environment with cell aliases

Example 6 is for a Direct Publish publish environment. Cell names and cell alias are displayed because of the -p Level=1 option and column headings are displayed because the -v option is used.
EXAMPLE
$ penv -p "OriginId=DirectPublish" -p "Level=1" -v info BMC Impact Publishing Server Environment Manager vDeveloper-ppa (Build 666.343 xx/xx/2008) Copyright 2005-2008 BMC Software, Inc. as an unpublished work. All rights reserved. Request received and accepted by the Publishing Server requestId=Z00000f48fmlfkXp9tZdlMZ3dbyuZ OriginId: DirectPublish -----------------------EnvId HomeCell direct direct_cell -----------------------EnvId HomeCell direct_2 CellAlias CellName direct_al_1 d_cell_1 direct_al_2 d_cell_2 -----------------------EnvId HomeCell direct_3 direct_cell_3 ------------------------

The pinit command copies the service model data of the publish environment to the specified cells. Initializing a cell does not remove status values from component instances. If publish from BMC Atrium CMDB is enabled, then the cells are automatically initialized with the data of the Atrium Publish environment to which they are assigned and default management data is also created on the cells. Normally, the BMC Impact Publishing Server initializes new cells automatically. You may need to use the pinit command to restore a cells service model when it is not in sync with the impact service model of BMC Atrium CMDB. If publish from BMC Atrium CMDB is disabled, then you must publish the management data manually before the components and impact relationships by using the CLI command pposter. For more information for a Direct Publish environment, see Initializing a cell from a Direct Publish environment on page 258.
Chapter 10
301
pinit syntax
pinit <common options> [-f] [-n cellName1[,cellName2[...]] |-a ] -e EnvId [-s Description]
pinit command options

Table 75 lists the command options for pinit. There are no required options for pinit. Table 75
Option
pinit options (part 1 of 2)

Description
<common options> see Understanding common command options for CLIs -c -h -? -i -q -l -p - on page 281 t -v -z -a initializes HomeCell or the cells defined by CellAliases If one or more of the cells cannot be initialized (for example, because a cell is not running), none of them are initialized and the request fails. -f forces the cell initialization without prompting you to confirm the initialization action If the -f option is not specified, you are prompted to confirm the initialization action. -n cellName1[,cellName2[ ...]] For a BMC Atrium CMDB publish environment: specifies the cells to initialize or reinitialize with the impact service model. On Windows platforms, you must enclose the cell list in quotation marks ("). If a cell name is not specified, the default cell name (the unqualified version of the host computer name) is used. If such a cell does not exist or does not belong to the considered environment, the command fails. If one or more of the cells cannot be initialized (for example, because a cell is not running), none of them are initialized and the request fails. -s description describes request
302
Table 75
Option
pinit options (part 2 of 2)

Description sets environment identifier to environmentID. The default value is PROD. It specifies either an Atrium CMDB environment or a Direct Publish environment, depending on the value of OriginId. For example, OriginId = AtriumCMDB or OriginId = DirectPublish).
-e environmentID
When you execute a pinit command for a specific environment, only the data for that environment is reinitialized. So, if the same cell contains different environments (for example, Atrium Publish and DirectPublish), then only part of the cells data is reinitialized.
pinit examples
This section provides examples of using the pinit command to initialize or reinitialize a cell with service model data.
Initializing a cell with the production service model data from the BMC Atrium CMDB
To initialize or reinitialize the cell whose name is the short host name (default cell name) with the BMC Atrium CMDB production service model, type the following command. (The short host name is the unqualified version of the host computer name.)
pinit
Initializing a specific cell with the BMC Atrium CMDB production service model To initialize a specific cell named jana with the BMC Atrium CMDB production service model, type the following command:
pinit -n jana
Initializing all BMC Impact Portal-registered cells with the BMC Atrium CMDB production service model
To initialize all the cells registered with the BMC Impact Portal with the BMC Atrium CMDB production service model, type the following command.
pinit -a
Chapter 10
303
plogObtaining the XML log for a request
If one or more of the specified cells cannot be initialized, for example, if a cell is not running, none of them are initialized and the request fails.
Initializing a cells data for a Direct Publish environment

To initialize the cell austin in the Direct Publish environment Sales, type the following command.
pinit -n austin -e Sales
This command removes all data of the service model in the Direct Publish environment Sales. In the cell, this corresponds to data that has the slot publish_env_id set to DirectPublish.Sales. If the BMC Impact Publishing Server has both Atrium CMDB and Direct Publish enabled, then you must specify OriginId = DirectPublish, either in the pclient.conf file or in the CLI penv command string as -p OriginId = DirectPublish.
pinit return codes


Use the plog command to obtain and optionally view the XML log for a publishing request. The plog command requests the XML log for a specific request from the BMC Impact Publishing Server and routes it in XML format to standard output. Use the plogdisplay command with the plog command to convert the XML log to text and to output the text to standard output.
plog syntax
plog <common options> RequestID [-r] [-s] [-w]
plog command options

The required command option for plog is the Request ID. Table 76 lists the options for plog.
304
Table 76
Option
plog options
Description
<common options> -c -h -? -i -q -l -p -t -v -z RequestID -r -w -s

the ID of a specific publish request request the replies part of the XML log request the instances to be published request the process report of the XML log
plog examples
This section provides examples of using the plog command to obtain and output the XML log for a specific service model publishing request.
Viewing the XML log for a specific publishing request as stdout

To obtain the XML log for a specific publishing request, and send it to standard output for viewing, type a command similar to the following, substituting the request ID in this example:
plog -s Z00000e8mu7xw9Xpa1ZfsMZeg4v1Z
Viewing the XML log for a specific publishing request as a text in stdout
To obtain the XML publishing log for a specific publishing request, convert it to text format, and output it to standard output for viewing, type a command similar to the following, substituting the request ID:
plog -s Z00000e8mu7xw9Xpa1ZfsMZeg4v1Z | plogdisplay -@
Using this command, you pipe the output of the plog command through the plogdisplay command to convert it to text format for output. See plogdisplay Converting the XML log for a request to text format on page 306.
plog return codes

Chapter 10
305
plogdisplayConverting the XML log for a request to text format
plogdisplayConverting the XML log for a request to text format

Use the plogdisplay command to convert the XML log for a request to text and output it to standard output. Use this command with the plog command.
plogdisplay syntax
plogdisplay <common options> (-@ | RequestLogFile)
plogdisplay command options

You must specify an input for the command; it can be either standard input (-@) or a specified file. Table 77 lists the options for plogdisplay. Table 77
Option <common options except: -r, -t, and u>
plogdisplay options
Description
see Understanding common command options for CLIs on page 281 This command does not interact with the BMC Impact Publishing Server so it does not accept these CLI common options: -r, -t, and -u.
You do not need to authenticate a user with the BMC Portal when using this command. If you do include the authentication option (-i), the user is authenticated.
-@ | RequestLogFile
specifies the source of input to display Use one of these arguments:

s s
Use -@ to indicate standard input as the source to display. For a specific publishing request, type the name of the XML log file as the source to display.
plogdisplay examples
This section provides examples of using the plogdisplay command to convert an XML log file for a publishing request to text and output it to standard output.
306
pposterSending service model objects to a cell
Converting an XML log file for a specific publishing request to text

To convert the XML log file for a publishing request to text and output it to standard output, type a command similar to the following command, substituting the correct xml file name:
publish -r myLog.xml plogdisplay myLog.xml
Viewing the XML log for a specific publishing request as a text in stdout
You pipe the output of the plog command through the plogdisplay command to convert it to text format and output it to standard output. To view a specific publishing log in text format, type the following command:
plog -r -s Z00000e8mu7xw9Xpa1ZfsMZeg4v1Z | plogdisplay -@
plogdisplay return codes

The plogdisplay command returns a nonzero value if it encounters any errors during execution. It returns a zero (0) value upon a successful execution, as shown in Table 78. Table 78
Code 0
plogdisplay return codes

Description success
a number error other than 0 When a CLI command exits with a return value other than 0, additional textual information on the error cause is displayed to standard output and, possibly, to the generated publishing CLI trace file pcli.trace. For information about these error codes, see Understanding return codes for CLIs on page 283.

You use the pposter command to send service model objects (components, relationships, and SIM management data) to a cell for Direct Publish environments only by using BMC Impact Publishing Server. The main difference between pposter and mposter is that pposter communicates with a Publishing Server and uses an environment identifier (EnvId) to refer to a specific service model and enables the deletion of service model objects. For information on mposter, see BMC Impact Solutions: General Administration.
Chapter 10
307
To use the pposter command, you must set the parameter DirectPublishOrigin to T in pserver.conf and create a Direct Publish environment with a penv command. For example, at the command prompt, type:
penv -e EnvId -p OriginId = DirectPublish open -p HomeCell = cellName
For more information about creating environments and the penv command, penv Managing publish environments on page 292.
pposter syntax
pposter <common options> -e EnvId sourceFile {sourceFile}
pposter command options

Table 75 lists the options for pposter. You must specify a environment ID and a source file for pposter. Table 79
Option <common options> -c -h -? -i -q -l -p -r -s -t -u -v -z -e EnvId SIM=T/F
pposter options (part 1 of 2)

Description

sets the environment identifier to EnvID to specify a service model
If SIM is set to T, true (default), pposter publishes components (instances of subclasses of MC_SM_COMPONENT) and impact relationships (instances of subclasses of MC_SM_RELATIONSHIP) to their HomeCell. Instances of all other classes are considered Service Impact Management Data and are published to all cells of the environment. If SIM is set to F, false, pposter publishes data other than SIM data. It is not possible to publish components (instances of subclasses of MC_SM_COMPONENT) and impact relationships (instances of subclasses of MC_SM_RELATIONSHIP). All data is always published to all cells of the environment.
308
Table 79
Option
pposter options (part 2 of 2)

Description
Init=T/F
If Init is set to F, false (default) or omitted, then existing data is updated with the new data. If Init is set to T, true, then existing published data is replaced with the data of the Baroc file. In other words, existing published data of the DirectPublish publish environment is removed and new data as defined in the Baroc file is added. If the data in the Baroc file has no mc_udid, then the new data will have mc_udid that differs from the existing data. To remove all published data of a DirectPublish publish environment from a cell, execute pposter -p "Init=T" with an empty Baroc file or without Baroc file. When using Init=T, pposter requires confirmation (-f option).
sourceFile
file that contains the data to send See Source files for pposter on page 309.
pposter uses the following parameter in the MCELL_HOME/etc/pclient.conf file: ContinueOnFailure=T/F
If ContinueOnFailure is set to F, false (default), pposter stops as soon as invalid data in the source file is encountered and no data is sent to the cell, not even those items processed before the incorrect data in the source file. If ContinueOnFailure is set to T, true, pposter sends as much data as possible, skipping invalid data in the source file.
Source files for pposter

You create a source file and, using the following commands, define the contents in BAROC format with the appropriate data additions, modifications, or deletions.
Chapter 10
309
Command dnew +
Definition create a new data instance; if this instance exists, update it The space between dnew and + is required. This is the default; if none of the three commands are present at the beginning of a line in a source file, dnew + is assumed.
dnew -
create a new data instance The space between dnew and - is required. If this instance exists, do not change it; ignore the dnew - command.
dmodify ddelete
change the existing data instance delete the existing data instance
For each data instance, provide a value for mc_udid. You can publish new data instances without specifying a value for mc_udid, but the mc_udid is still needed to modify or delete the existing data in cell, except if all existing data is replaced when publishing. For environments that do not have a value for the HomeCell slot, you must provide a value for the HomeCell slot for each component, and a value for the provider_home_cell and the consumer_home_cell slots for each relationship. A relationship is sent to the cell of its consumer component. For relationships in which the consumer and provider components belong to different cells, you must specify a value for the provider_classname slot. See pposter example 2two cells on page 313. You can also use cell aliases by specifying values for HomeCellAlias for components, and Consumer.HomeCellAlias and Provider.HomeCellAlias for relationships. Since these slots do not exist in the class definition of the cell, BMC Impact Publishing Server uses the alias table of the environment and replaces them with the values in the HomeCell, consumer_home_cell and provider_home_cell slots. See pposter example 3using cell aliases on page 315. Data instances, possibly prepended with dnew (+ or -), dmodify, or ddelete commands, must terminate with END, followed by a Return.
pposter example 1
This example shows how to create a simple service model, modify the service model, and delete the service model. The service model consists of three objects: an application (comp0), that depends on a database (comp1), and the relationship between the two. The environment is MY_ENV and the HomeCell is MY_HOMECELL.
Creating a service model

To create this service model, create a source file. For this example, it is named FileDnew.baroc:
EXAMPLE
BMC_DataBase; mc_udid = comp0; Name = comp0; END BMC_Application; mc_udid = comp1; Name = comp1; END BMC_Impact; mc_udid = rel; provider_id = comp0; consumer_id = comp1; PropagationModel = DIRECT; Name = comp1; END
To send this new service model to the cell, at the command prompt, type the following command:
EXAMPLE
pposter -v -e MY_ENV FileDnew.baroc BMC Impact Publishing Server Data Poster vDeveloper-ppa (Build 666.343 - xx/xx/2007) Copyright 2005-2007 BMC Software, Inc. as an unpublished work. All rights reserved. Publish successfully applied.
Modifying a service model

To modify the service model by adding impact costs, create a source file. For this example, it is named FileDModify.baroc:
EXAMPLE
dmodify BMC_DataBase; mc_udid = comp0; ImpactCostPerSec = 5; ImpactCostPerSecOut = 2; END
Chapter 10
311
To send this modification to the service model to the cell, at the command prompt, type the following command:
EXAMPLE
pposter -v -e MY_ENV FileDmodify.baroc BMC Impact Publishing Server Data Poster vDeveloper-ppa (Build 666.343 - xx/xx/2007) Copyright 2005-2007 BMC Software, Inc. as an unpublished work. All rights reserved. Publish successfully applied.
Deleting a service model

To delete the service model, create a source file. For this example, it is named FileDdelete.baroc:
EXAMPLE
ddelete BMC_DataBase; mc_udid = rel; END ddelete BMC_Application; mc_udid = comp0; END ddelete BMC_Impact; mc_udid = comp1; END
To send this deletion of the service model to the cell, at the command prompt, type the following command:
EXAMPLE
pposter -v -e MY_ENV FileDdelete.baroc BMC Impact Publishing Server Data Poster vDeveloper-ppa (Build 666.343 - xx/xx/2007) Copyright 2005-2007 BMC Software, Inc. as an unpublished work. All rights reserved. Publish successfully applied.
312
pposter example 2two cells

This service model consists of three objects: an application (comp0) that belongs in cell_1, a database (comp1) that belongs in cell_2, and the relationship between the two.
Creating a service model for two cells

EXAMPLE
BMC_DataBase; HomeCell = cell_1; mc_udid = comp0; Name = comp0; END BMC_Application; HomeCell = cell_2; mc_udid = comp1; Name = comp1; END BMC_Impact; provider_home_cell = cell_1; consumer_home_cell = cell_2; provider_classname = BMC_DataBase; mc_udid = rel; provider_id = comp0; consumer_id = comp1; PropagationModel = DIRECT; END
To send this new the service model to the cells, at the command prompt, type the following command:
EXAMPLE
Chapter 10
313
Modifying a service model for two cells

EXAMPLE
dmodify BMC_DataBase; HomeCell = cell_1; mc_udid = comp0; ImpactCostPerSec = 5; ImpactCostPerSecOut = 2; END
To send this modification to the service model to the cells, at the command prompt, type the following command:
EXAMPLE
Deleting a service model

EXAMPLE
ddelete BMC_DataBase; HomeCell = cell_1; mc_udid = rel; END ddelete BMC_Application; HomeCell = cell_2; mc_udid = comp0; END ddelete BMC_Impact; consumer_home_cell = cell_1; mc_udid = comp1; END
314
EXAMPLE
pposter example 3using cell aliases

This service model consists of three objects: an application (comp0) that belongs in cell_1, a database (comp1) that belongs in cell_2, and the relationship between the two. For this example, cell aliases are as follows:
cell alias c_alias_1 c_alias_2 cell name cell_1 cell_2
Creating a service model with cell aliases

EXAMPLE
BMC_DataBase; HomeCellAlias = c_alias_1; mc_udid = comp0; Name = comp0; END BMC_Application; HomeCellAlias = c_alias_2; mc_udid = comp1; Name = comp1; END BMC_Impact; Provider.HomeCellAlias = c_alias_1; Consumer.HomeCellAlias = c_alias_2; provider_classname = BMC_DataBase; mc_udid = rel; provider_id = comp0; consumer_id = comp1; PropagationModel = DIRECT; END
Chapter 10
315
To send this new the service model to the cells, at the command prompt, type the following command:
EXAMPLE
Modifying a service model with cell aliases

EXAMPLE
dmodify BMC_DataBase; HomeCellAlias = c_alias_1; mc_udid = comp0; ImpactCostPerSec = 5; ImpactCostPerSecOut = 2; END
To send this modification to the service model to the cell, at the command prompt, type the following command:
EXAMPLE
316
Deleting a service model with cell aliases

EXAMPLE
ddelete BMC_DataBase; HomeCellAlias = c_alias_1; mc_udid = rel; END ddelete BMC_Application; HomeCellAlias = c_alias_2; mc_udid = comp0; END ddelete BMC_Impact; Consumer.HomeCellAlias = c_alias_2; mc_udid = comp1; END
EXAMPLE
Return codes for pposter

Table 80 describes the return codes specific to the pposter command. For return (or error exit) codes common to all BMC Impact Publishing Server CLI commands, see Understanding return codes for CLIs on page 283. Table 80
0 50
pposter return codes (part 1 of 2)

Description All data commands in the source files are successfully applied to all cells of the environment. Publish has successfully completed, but some errors were detected. This can occur only if ContinueOnFailure is set to T (true). For more information, see the publish log; the -v option provides more detail.
Return Code
51
BMC Impact Publishing Server refused to initiate the publish process. The actual cause of the error (for example, another publish is in progress) is displayed on the standard error device. An error is returned by BMC Impact Publishing Server when data are being sent to it. For more information, see the publish log; the -v option provides more detail.
52
Chapter 10
317
pscontrolSending a command to BMC Impact Publishing Server
Table 80
53
pposter return codes (part 2 of 2)

Description An error is returned by BMC Impact Publishing Server when data are effectively applied to the cells. For more information, see the publish log; the -v option provides more detail.
Return Code
54 55
There is a syntax or invalid BAROC object in the source file. There is an I/O error with a source file, for example, no source file or the source file cannot be opened.

Use the pscontrol command to send a command (automated, manual, stop) to the BMC Impact Publishing Server. By default, pscontrol only sends the command to the BMC Impact Publishing Server. To monitor that the mode effectively changed to Automated or Manual, you can use the -u option.
pscontrol syntax
pscontrol [-c ConfigFile] [-h|-?] [-i User/Password[@Host[/Port] [,Host[/Port] [,...]]] [-q] [-l HomeLocation] {-p "Var=Value"} [-t ConnectionInitTimeout] [-u RequestTimeout] [-v] [-z] [-f] (automated | manual | stop)
pscontrol command options

Table 81 lists the options for the pscontrol command. There are no required command options for the pscontrol command. Table 81
Options <common options> -c -h -i -q -l -p -t -u -v -z -f stop
pscontrol command options (part 1 of 2)

Description

The -u option default for pscontrol is 0 seconds. forces the command to run without prompting the user to verify the execution of the command
stops the BMC Impact Publishing Server
318
Table 81
Options
pscontrol command options (part 2 of 2)

Description turns automated publishing on turns automated publishing off
automated manual
pscontrol examples
This section contains examples of usage of the pscontrol command. Figure 32 contains an example of the pscontrol stop command, which stops the BMC Impact Publishing Server. Figure 32 pscontrol stop example
$ pscontrol stop BMC Impact Publishing Server Controller vDeveloper-ppa (Build 666.343 - xx/xx/2007) Copyright 2005-2006 BMC Software, Inc. as an unpublished work. All rights reserved. Please confirm control command (stop) (type y (yes) / n (no). Default is n): y Publishing Server is stopping
Figure 33 contains an example of the pscontrol automated command, which restarts automated publishing. Figure 33 pscontrol automated example
pscontrol -f automated BMC Impact Publishing Server Controller vDeveloper-ppa (Build 666.343 - xx/xx/2007) Copyright 2005-2006 BMC Software, Inc. as an unpublished work. All rights reserved. Automated publishing is starting
Figure 34 contains an example of the pscontrol automated command using the -u option. Figure 34 pscontrol automated -u example
pscontrol -f -u 300 automated BMC Impact Publishing Server Controller vDeveloper-ppa (Build 666.343 - xx/xx/2007) Copyright 2005-2006 BMC Software, Inc. as an unpublished work. All rights reserved. Automated publishing is starting Automated publishing is started
Chapter 10
319
pserverStarting the BMC Impact Publishing Server service or daemon
Figure 35 contains an example of the pscontrol manual command, which stops automated publishing. Figure 35 pscontrol manual example
pscontrol manual BMC Impact Publishing Server Controller vDeveloper-ppa (Build 666.343 - xx/xx/2007) Copyright 2005-2007 BMC Software, Inc. as an unpublished work. All rights reserved. Please confirm control command (manual) (type y (yes) / n (no). Default is n): y Automated publishing is stopping
pserverStarting the BMC Impact Publishing Server service or daemon

Use the pserver command to start the Publishing Service service or daemon.
pserver syntax
pserver [-b psname] [-c ConfigFile] [-d] [-h|-?] [-q] [-l HomeLocation] {-p "Var=Value"} [-v] [-z]
pserver command options

Table 82 lists the options for the pserver command. There are no required command options for the pserver command. Table 82
Options <common options> -? -c -h -p -q -v -z -d
pserver command options

Description

on UNIX platforms, causes the BMC Impact Publishing Server to run in the foreground instead of as a daemon in the background (On Windows platforms, the BMC Impact Publishing Server always runs in the foreground.)
-b psname
identifies the name of the BMC Impact Publishing Server; defaults to ps_hostname
320
psstatDisplaying status of BMC Impact Publishing Server
psstatDisplaying status of BMC Impact Publishing Server

Use the psstat command to determine if the BMC Impact Publishing Server is running and in what mode, automated or manual.
psstat syntax
psstat [-c ConfigFile] [-h|-?] [-i User/Password [@Host[/Port] [,Host[/Port] [,...]]] [-q] [-l HomeLocation] {-p "Var=Value"} [-t ConnectionInitTimeout] [-u RequestTimeout] [-v] [-z]
psstat command options

There are no required command options for the psstat command. Table 83 lists the options for the psstat command. Table 83
Options <common options>
psstat command options

Description
psstat examples
This section provides examples of using the psstat command to view the status of the BMC Impact Publishing Server and whether it is in automated or manual mode.
BMC Impact Publishing Server running with automated publish enabled

When the BMC Impact Publishing Server is running and automated publish is enabled, psstat returns the following message:
psstat Started - Automated mode
BMC Impact Publishing Server running with automated publish disabled

When the BMC Impact Publishing Server is up and automated publish is disabled, psstat returns the following message:
Chapter 10
321
publishPublishing a service model or viewing instances to be published
psstat Started - Manual mode
BMC Impact Publishing Server not running (or cannot be contacted)

When the BMC Impact Publishing Server is down or cannot be reached, psstat returns the message Request Timeout Expired.

Use the publish command to
s
publish the service model without viewing what is being published (default) view the service model instances, including components, relationships, and management data instances that are marked for publishing publish the entire service model or selected service model class instances and view a listing of the component, relationship, and management data instances being published
publish syntax
publish <common options> [-d ClassName.UdId[,ClassName.UdId[,...]]] [-e EnvId] [-w [-o File] [-m]] [-s Description]
publish command options

Table 84 lists the options for the publish command. There are no required command options for the publish command. Table 84
Options <common options> [-d ClassName.UdId[,ClassName.U dId[,...]]]

Description

publishes the specified service model object class instances, which can include component, relationship, and management data
322
Table 84
Options -m

Description publishes the service model class instances, including component, relationship, and management data instances, that you viewed (relevant only with the -w option) prints the service model class instances, including components, relationships, and management data, to be published to the specified output file (relevant only with the -w option) view the service model class instances marked for publishing describe request publishes in environmentID. The default value is PROD. Other values will result in error messages if using a BMC Impact Publishing Server version prior to 5.x.
-o OutputFile
-w -s description -e environmentID
publish examples
This section provides examples of using the publish command to view the service model class instances to be published (including components, relationships, and management data) and to publish them.
Publishing the service model without viewing it

To publish a service model without viewing the objects queued for publish, type the following command:
publish
Viewing the service model class instances to be published prior to publishing

To view the service model class instances that are queued for publishing, type the following command:
publish -w
Viewing what is queued to publish and then publishing the objects

To view and then publish the service model objects that are marked for publishing, type the following command:
publish -w -m
Chapter 10
323
Viewing hard-deleted service model instances and publishing deletions

To view the service model objects that have been hard-deleted from the production asset dataset, but that still exist in cells, type the following command:
publish -p Purge=T -p Merge=F -w
To view the service model objects that have been hard-deleted from the production asset dataset, but that still exist in cells, and then to publish the deletions to the cells, type the following command:
publish -p Purge=T -p Merge=F -w -m
publish return codes

324
Appendix
Troubleshooting
This section describes problem solving for the BMC Impact Service Model Editor and BMC Impact Publishing Server products.
BMC Impact Service Model Editor

This section describes problem solving for the BMC Impact Service Model Editor product.
Using the BMC Impact Service Model Editor log

To open the BMC Impact Service Model Editor Log dialog box and view the log messages, choose Tools => View Log. Figure 36 BMC Impact Service Model Editor log
By default, this log captures startup and shutdown information. To record different levels of information for debugging purposes, see To set log file preferences on page 199. The following illustration depicts representative log entries of the BMC Impact Service Model Editor GUI log.
Appendix A Troubleshooting 325
Nov 27, 2006 4:57:08 PM [Seq: 0, ID: BMCSME001010, Level: INFO] FindPanel Creation done Nov 27, 2006 4:57:09 PM [Seq: 2, ID: BMCSME000006, Level: INFO] Service Model Editor console started. Version: 5.0.0 Build: 1124943 Nov 27, 2006 4:57:42 PM [Seq: 3, ID: BMCSME000018, Level: INFO] Loaded 1 workspaces from server. Nov 27, 2006 5:01:03 PM [Seq: 4, ID: BMCSME000004, Level: INFO] Logging level changed to ALL.
Outside BMC Impact Service Model Editor, you can enable the log for the BMC Impact Service Model Editor server and the Java Web Start console.
BMC Impact Service Model Editor Server

The BMC Impact Service Model Editor Server records commands, runtime exceptions, and debugger information. To view the output of the BMC Impact Service Model Editor Server log, you must modify the log4j.xml configuration file of the JBoss application server. The log4j.xml configuration file is located on the system where the BMC Portal is installed in the directory: BMC_PORTAL_KIT_HOME/appserver/websdk/tools/jboss/server/all/conf. You can modify the log4j.xml file to send its output to
s s s
the BMC Portal log file a console window a console window and the JBoss log file
To send BMC Impact Service Model Editor Server debug output to the BMC Portal log file 1 In an appropriate editor, open the
BMC_PORTAL_KIT_HOME/appserver/websdk/tools/jboss/server/all/conf/log4j.xml.
2 Add the following appender and category elements under the Setup the Root
Category heading.
<appender name="CLUSTER" class="org.jboss.logging.appender.RollingFileAppender"> <errorHandler class="org.jboss.logging.util.OnlyOnceErrorHandler"/> <param name="Threshold" value="DEBUG"/> <param name="File" value="${jboss.server.home.dir}/log/portal.log"/> <param name="Append" value="true"/> <param name="MaxFileSize" value="100MB"/> <param name="MaxBackupIndex" value="10"/> <layout class="org.apache.log4j.PatternLayout"> <param name="ConversionPattern" value="<%5.1p,%d{MM/dd/yy HH:mm:ss z},%c{1}> %m%n"/>
326
</layout> </appender> <category name="com.bmc.sms.sme"> <priority value="DEBUG"/> <appender-ref ref="SME_FILE"/> </category>
To send BMC Impact Service Model Editor Server debug output to a console window 1 In an appropriate editor, open the
2 Add the following appender and category elements under the Setup the Root
Category heading.
<appender name="SME_CONSOLE" class="org.apache.log4j.ConsoleAppender"> <errorHandler class="org.jboss.logging.util.OnlyOnceErrorHandler"/> <param name="Target" value="System.out"/> <param name="Threshold" value="DEBUG"/> <layout class="org.apache.log4j.PatternLayout">  <param name="ConversionPattern" value="<%5.1p,%d{MM/dd/yy HH:mm:ss z},%c{1}> %m%n"/> </layout> </appender> <category name="com.bmc.sms.sme"> <priority value="DEBUG"/> <appender-ref ref="SME_CONSOLE"/> </category>
3 To view debug output in a console window, start the BMC Impact Portal from a
shell window:
s
For Windows, open a Command Prompt window, and enter the following command:
BMC_PORTAL_KIT_HOME\appserver\websdk\bin\run.bat
For Solaris, open a terminal window, and enter the following command:
BMC_PORTAL_KIT_HOME/tools/jboss/bin/jboss.sh
4 Restart the BMC Portal application server.
Appendix A
Troubleshooting
327
To send BMC Impact Service Model Editor Server debug output to a console window and the BMC Portal log file 1 In an appropriate editor, open the
2 Add both sets of appender and category elements for sending output to the BMC
Portal log and to a console window as described in the preceding two procedures.
3 Add the following ref subelement pointing to the SME_FILE under the category
element with the value com.bmc.sms.sme.
<category name="com.bmc.sms.sme"> <priority value="DEBUG"/> <appender-ref ref=SME_CONSOLE/> <appender-ref ref="SME_FILE"/> </category>
NOTE
The appender element FILE is defined under the Preserve Messages in a local file heading of the default log4j.xml file.
Java Web Start logging

The Java Web Start log helps you to identify BMC Impact Service Model Editor deployment problems.
To enable Java Web Start logging 1 Open the Java Web Start Application Manager console in one of the following
ways:
s s
Double-click the Java Web Start icon on your desktop. Under Windows, choose Start => Programs => Java Web Start => Java Web Start or, from the Command Prompt, execute the following command:
%JAVA_HOME%\jre\javaws\javaws.exe
2 In the Java Web Start Application Manager console, choose File => Preferences. 3 On the Advanced tab, in the Output Options area, select Log Output. 4 To select an existing file, click Choose Log File Name, or enter a file path in the Log
File Name box.
328
Other BMC Impact Service Model Editor Troubleshooting Options
5 Click OK.
Other BMC Impact Service Model Editor Troubleshooting Options

These workarounds apply to various troubleshooting scenarios that you might encounter.
Deleting all Views

Remove all the View files from the following locations:
s
BMC_PORTAL_KIT_HOME/appserver/websdk/tools/jboss/server/all/data/ smsConsoleServer/sme/indexes BMC_PORTAL_KIT_HOME/appserver/websdk/tools/jboss/server/all/data/ smsConsoleServer/sme/Views
Connecting to the Remedy AR System server

To verify that the BMC Atrium CMDB is accessible, you connect to the Remedy AR System server using the Remedy User Tool. If necessary, restart the Remedy AR System server service. If the BMC Atrium CMDB is not accessible, you may receive a blank error dialog box when performing commands in BMC Impact Service Model Editor.
Testing the connection between BMC Impact Portal and the BMC Atrium CMDB
To verify the connection between BMC Impact Portal and the BMC Atrium CMDB, you can run the Impact Portal superadmin task Synchronize User Groups. If this fails, it is probably due to a bad BMC Atrium CMDB configuration in Impact Portal. BMC Impact Service Model Editor connects to the BMC Atrium CMDB through the Impact Portal, so it is a vital configuration. If the BMC Atrium CMDB is not accessible, you may receive a blank error dialog box when performing commands in BMC Impact Service Model Editor.
Appendix A
Troubleshooting
329

This section contains information on troubleshooting problems with the BMC Impact 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 Service Model Editor 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. For information about publication logs, which provide helpful information when troubleshooting problems, see Working with publication logs on page 126.
Verifying that BMC Impact Publishing Server is running

To ensure that only one BMC Impact Publishing Server is running, BMC Impact Publishing Server maintains the file MCELL_HOME/log/ps_hostName/ps.lock. If the BMC Impact Portal JMS is not functioning properly, you can use ps.lock to verify whether a BMC Impact Publishing Server is running.
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 BMC Impact Publishing Server when JMS is not running

If the BMC Impact Portal JMS is not up and running properly, find and stop the BMC Impact Publishing Server process. Ensure that you do not kill the BMC Impact Publishing Server process when it is processing a request. Note that this procedure is for UNIX platforms only.
330
Publishing large service models
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 BMC Impact Publishing Server process is returned.
3 Kill the BMC Impact Publishing Server process by executing the command:
fuser -k ps.lock
Publishing large service models

When publishing large models, several parameters may require adjustment:
s
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 BMC Impact 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, BMC Impact Publishing Server estimates the timeout needed. If the timeout is not adequate, set ARSXLongTimeOutEstimate=F and increase ARSXLongTimeOut. If publication fails during the database update with the message Failure while applying publish on CMDB - Error - 92 Timeout, the operation has been accepted by the server and will usually complete successfully, the value for ARSXLongTimeOut is not set high enough and expires before the BMC Atrium CMDB has terminated committing modifications in the impact dataset. The BMC Atrium CMDB continues to commit modifications in the impact dataset and after a while the service model will be available in the impact dataset. Make sure the parameters are set correctly. The same failure may happen when initializing CMDB with large service models.
In the MCELL_HOME/etc/smmgr.conf file, the MessageBufferKeepSent 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 BMC Impact Publishing Server and smmgr.
Appendix A
Troubleshooting
331
Publishing failures and reattempts
By default, BMC Impact 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 MessageBufferKeepSent 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 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.
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:
s s s
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.
332
BMC Impact Publishing Server service or daemon fails to start
BMC Impact Publishing Server service or daemon fails to start

Only one BMC Impact 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 BMC Impact Publishing Server as it runs. If the Impact Publish Server is stopped gracefully, then ps.lock is removed. If the BMC Impact 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
remove the ps.lock file in the MCELL_HOME/log/ps_hostname/ directory and restart the BMC Impact 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 Results dialog box in BMC Impact Service Model Editor indicates that the promotion was successful, but data does not appear in the BMC Impact Portal or BMC Impact Explorer, 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 BMC Impact Publishing Server starts in automated mode. Verify that the plugin is properly installed and loaded.
Verify automated publishing mode

Verify that the BMC Impact 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.
Appendix A
Troubleshooting
333
Reconciliation jobs hang
If the psstat command indicates that the BMC Impact 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 BMC Impact 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 Service Model Editor promotions to hang), the NotifyARDBC plug-in is not installed or is not running. 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 BMC Impact Publishing Server to open a TCP/IP connection, verify the installation of the Notify ARDBC plugin. The port should be open for the BMC Impact Publishing Server to open a TCP/IP connection.
BMC Impact Publishing Server does not reply to requests

The client and server use the JMS service of BMC Impact Portal for communication. Normally, the BMC Impact Publishing Server restores when the JMS service drops. If the JMS service remains down, the BMC Impact Publishing Server stops with a critical error. However, occasionally the communication is not restored and the BMC Impact Publishing Server doesn't stop, and the pserver.trace file contains repeated warnings from org.jboss.mq.SpyJMSException. To resolve this situation,
Diagnosing publication failures
1. Verify that BMC Impact Portal is running properly (or restart the BMC Impact Portal). 2. Restart the BMC Impact Publishing Server.

When a publication attempt or other request fails, examine the details of the request log in BMC Impact Service Model Editor using the menu command Publish History (Tools => Publish History). Table 85 describes BMC Impact Publishing Server request failure messages, what causes the problem, and what to do to correct the problem. Table 85 BMC Impact Publishing Server request failure messages (part 1 of 5)
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 Portal. 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.
s s
Make sure all CIs have unique aliases. Publish the purge by using the CLI command publish -p
"Purge=T"
See Purging and deleting service model objects on page 249 for more information.
Appendix A
Troubleshooting
335
Table 85
BMC Impact Publishing Server request failure messages (part 2 of 5)

Cause The BMC Impact Publishing Server is not able to connect to the BMC Impact Manager or the connection was dropped. This message may occur if
s
Failure message
Connection to IM cellName is not open OR Connection to IM cellName dropped
Action 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 Impact Portal. Verify that the ServiceModelSet of impact relationship is correct. 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. Increase the value of
ServiceModelManagerStartTimeOut.
Consumer/Provider component with mc_udid {0} is not defined
an impact relationship is pointing to a non-existent CI the impact relationship has ServiceModelSet IN, but the consumer or provider component instance has ServiceModelSet OUT_OF_IN or OUT
IM {0} failed to launch SMM (Service Model Manager)
In a cell's trace file you find the message Service Model Manager
process ({0}) not active within expected delay. Please verify.
The cell does fork a Service Model Manager (SMM) process. In the mcell.conf file, the parameter
ServiceModelManagerStartTimeOut = 60
defines the timeout.
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
336
Table 85

Cause Action 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. BMC Impact 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.
Failure message
No user group defined with id {0}
Operation on instance of different environment Provider_home_cell ({0}) is remote but component {1} is local
The data instance is already published to the cell from another publish environment.
Use the instance's publish environment to publish modifications or deletions.
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
s
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.
Appendix A
Troubleshooting
337
Table 85

Cause Publication failure Action Use the -v option (publish -v) to return both generic and detailed (verbose) failure messages.
Failure message Publish returns generic failure message, such as Publish

validation of Impact Manager failed The cell alias is not mapped to a cell name in the current environment The component has a class id BMC_TRANSACTION that does not correspond with a SIM class.
The attribute HomeCellAlias has a Define the cell aliases correctly. value that is not defined in the publish environment's CellAliases. A CI of the class with the given id has ServiceModelSet IN or OUT_OF_IN, although the class is not flagged as a SIM class. Only instances of SIM classes should have ServiceModelSet IN or OUT_OF_IN. To make the class a SIM class, follow these steps: 1. Use Remedy User's Class Manager Console and assign the attribute Custom Properties to 100050. 2. Export the modified SIM class information with the CLI command pclassinfo -x. 3. Update the Knowledge Base of the cells and recompile. For more information, see Adding new classes to the BMC Atrium CMDB on page 202.
The minimum supported protocol version is 7. Unique data identifier already in use.
The version of the target cell Uninstall the earlier version and instance is earlier than the required install the appropriate version. version. A service component instance with The service model in the cell is the same mc_udid is already most likely not in sync with the published in the cell. 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.
338
Another publish request is ongoing
Table 85

Cause 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. Action Reinitialize the SIM 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.
Failure message
Unique data identifier not in use
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.

When the BMC Impact Publishing Server does not accept or begin processing a publish request, the following messages may display:
s s s
Another publish request is ongoing The environment is not registered Error with ids/udids for partial publish, i.e. publish of selected instances
Appendix A
Troubleshooting
339
Message: Another publish request is ongoing

The BMC Impact 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.
340
Appendix
B
342 342 342 343 343 349 353 355 357 358 358 359 359 360 360 361 361 362 362 363 363 363 363 364 364 366 366 367
Default service model data classes

This appendix describes the service model class hierarchy in the BMC Atrium CMDB Common Data Model. This appendix covers the following topics: 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_STATUS_COMPUTATION data class . . . . . . . . . . . . . . . . . . . . . . . . . . . . . BMC_STATUS_PROPAGATION data class . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . BMC_PROPAGATION_MAP data class . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . SIM data class descriptions. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . BMC_SEVERITY_TO_STATUS data class . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . BMC_SIM_MATCH_TABLE data class . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . BMC_SIM_ALIAS 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 B
341
Service model data structures
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:
s
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.
Service model data class files

Table 86 on page 343 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.
342
Service model component data classes
Table 86
Service management data class files

File name mc_sm_object.baroc Contents these component types and their subclasses:
s
Data classes Component
BMC_BaseElement s BMC_Collection s BMC_LogicalEntity s BMC_System s BMC_SystemComponent s 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 component instances can represent a hardware component, an application, a service, or a business entity. A component instance can be any aspect of the business for which service management is desired. Service model component instances 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.
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:
s s s s s
BMC_Collection BMC_LogicalEntity BMC_System BMC_SystemComponent BMC_SystemService
Appendix B
343
BMC_BaseElement data class definition

Figure 37 shows the BAROC definition of the BMC_BaseElement class, which is located in the mc_sm_object.baroc file. Figure 37 BMC_BaseElement definitions
MC_PUBLISH_DATA_CLASS : BMC_BaseElement ISA MC_SM_COMPONENT DEFINES { Type : STRING; Item : STRING; ReadSecurity : LIST_OF STRING; ManufacturerName : STRING; Description : STRING; ShortDescription : STRING, default = 'n/a'; OwnerContact : STRING; Name : STRING; DatasetId : STRING, default = '0'; ImpactCostUnit : STRING; Notes : STRING; InstanceId : STRING; AccountID : STRING; OwnerName : STRING; Model : STRING; VersionNumber : STRING; WriteSecurity : LIST_OF STRING; Category : STRING; }; END
BMC_BaseElement inherits slots from MC_SM_COMPONENT class, which is defined in Figure 38 on page 345. MC_SM_COMPONENT class is located in the mc_sm_root.baroc file.
344
Figure 38
MC_SM_COMPONENT definition
MC_PUBLISH_DATA_CLASS: MC_SM_COMPONENT ISA MC_SM_DATA DEFINES { ComponentAliases: LIST_OF STRING; HomeCell: STRING; Priority:MC_PRIORITY, default=PRIORITY_5; StatusModel: STRING, default = 'STANDARD'; business_data : STRING; change_number : INTEGER; 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_roleup_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; 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; schedule_status: MC_SM_SCHEDULE_STATUS, default=IN; }; END
MC_SM_COMPONENT inherits slots from MC_SM_DATA (which contains no slot definitions, as shown in Figure 39). MC_SM_DATA is located in the mc_sm_root.baroc file. Figure 39 MC_SM_DATA definition
MC_DATA_CLASS : MC_SM_DATA ISA CORE_DATA; END
Appendix B
345
MC_SM_DATA inherits slots from CORE_DATA, which is shown in Figure 40. CORE_DATA is located in the mc_root_internal.baroc file. Figure 40 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, read_only = yes; }; END
Component instance slot descriptions in alphabetical order

Table 87 alphabetically lists the slots that define component instances with their descriptions and data type. The Source class column indicates the name of the class where the slot is defined. Table 87
Slots
AccountId
Slots that define component instances (part 1 of 4)

Description
identification of the Account the object belongs to (Accounts are created in the Portal)
Data type or enumeration

STRING
Source class
BMC_BaseElement
Category
provides a user-defined categorization of a STRING component instance
BMC_BaseElement
change_number
increments every time an event is sent for the component. Used to determine the order of events for events which happen in the same second.
INTEGER
MC_SM_COMPONENT
ComponentAliases
list of aliases used to associate events to the STRING component instance
MC_SM_COMPONENT
consumer_num
number of component instances acting as consumers of the component instance
INTEGER
MC_SM_COMPONENT
comment
a comment that is set for the component via STRING BMC Impact Manager
MC_SM_COMPONENT
component_scope
scope of the component (local, shadow, etc.)
STRING
MC_SM_COMPONENT
computed_priority
the priority of a component that is the highest between self priority and impacts priority. Set in the computed_priority field.
enumeration: MC_PRIORITY
MC_SM_COMPONENT
computed_status
status of the component instance computed enumeration: from self and substatuses MC_SM_COMPONENT_STATUS
MC_SM_COMPONENT
346
Table 87
Slots

Description
function used to determine impact_status from the providers propagated status

enumeration: MC_SM_CO_FUNCTION REAL
Source class
MC_SM_COMPONENT
cost
the current cost for the component depending on the current value of the schedule (either During Schedule or Exceptions Within During Schedule)
MC_SM_COMPONENT
data_handle DatasetId
identifier in local cell identification of the dataset within which the instance exists. This attribute relates to the CoreDatasetId attribute of a BMC_Dataset instance.
INTEGER STRING
CORE_DATA BMC_BaseElement
Description
a description of the component instance that is meaningful to the enterprise
STRING
BMC_BaseElement
direct_events_count
count of events coming from instrumentation
INTEGER
MC_SM_COMPONENT
HomeCell
name of the parent cell for the component instance
STRING
MC_SM_COMPONENT
ImpactCostPerSec
cost of one second of unavailability of the component
STRING
BMC_BaseElement
ImpactCostPerSec
cost for a component when it is During Schedule
REAL
MC_SM_COMPONENT
ImpactCostPerSecOut
cost for the component when it is in an Exceptions Within During Schedule period
REAL
MC_SM_COMPONENT
ImpactCostUnit
unit of the cost expressed in ImpactCostPerSec
STRING
BMC_BaseElement
impact_priority
priority determined from a components impacts
MC_SM_COMPONENT
impact_status
status computed by impact_function
enumeration: MC_SM_COMPONENT_STATUS
MC_SM_COMPONENT
InstanceId
instance identification of a component within the BMC
STRING
BMC_BaseElement
Atrium CMDB
BMC_BaseElement
Item
Provides a user-defined categorization of a STRING component instance
last_status_modification
last time the status or sub_status was changed (used by GUI)
INTEGER
MC_SM_COMPONENT
maintenance_mode
operational switch used to drop events when UM
enumeration: MC_YESNO enumeration: MC_SM_COMPONENT_STATUS
MC_SM_COMPONENT
manual_status
manual status flag of the component (NONE if not set)
MC_SM_COMPONENT
manual_status_comment
comment entered by user when component STRING instance is set to manual status
MC_SM_COMPONENT
Appendix B
347
Table 87
Slots

Description
list of direct and indirect providers; mc_udids of component instances with manual status set (may contain duplicate entries

LIST_OF_STRING
Source class
MC_SM_COMPONENT
manual_status_providers
manual_status_providers_co number of direct and indirect providers unt with manual status set (may contain duplicate entries) manual_status_requestor login ID of user who sets the component instance to manual status ManufacturerName name of the company that manufactured the component instance mc_creation_time mc_modification_time
INTEGER
MC_SM_COMPONENT
STRING
MC_SM_COMPONENT
STRING
BMC_BaseElement
date and time when the object was created INTEGER date and time when the object was last changed INTEGER
CORE_DATA CORE_DATA
mc_modification_requestor mc_udid Model
modification requestor universal data identifier
STRING STRING
CORE_DATA CORE_DATA BMC_BaseElement
model assigned to the component instance STRING by the manufacturing company
Name
user-defined name that is meaningful to the STRING enterprise
BMC_BaseElement
Notes OwnerContact
general notes on the object
INTEGER
BMC_BaseElement BMC_BaseElement
A string that provides information on how STRING the primary system owner can be reached (e.g. phone number, e-mail address
OwnerName
name of the person in the enterprise who is STRING responsible for the component instance
BMC_BaseElement
possible_causes
list of possible causes for the components current status (different from root causes)
LIST_OF_STRING
MC_SM_COMPONENT
Priority
priority
MC_SM_COMPONENT
PriorityWatchdog
indicates whether the component is a priority propagator
enumeration: MC_YESNO
MC_SM_COMPONENT
raw_impact_priority
the computed priority for an object (value between 0 and 1)
REAL
MC_SM_COMPONENT
ReadSecurity
list of permission groups that defines who has read access to a component instance
LIST_OF_STRING
BMC_BaseElement
root_causes
list of root causes for the components current status
LIST_OF_STRING
MC_SM_COMPONENT
ShortDescription
short textual description (one-line string) of STRING the object
BMC_BaseElement
schedule_status
indicates whether the component is currently During Schedule or Exception Within During Schedule
enumeration_ MC_SM_SCHEDULE_STATUS
MC_SM_COMPONENT
348
BMC_Impact data class
Table 87
Slots
self_priority

Description
base priority and the components current status
Source class
MC_SM_COMPONENT
the priority of the component based on the enumeration: MC_PRIORITY
self_status
the status of the object based on events directly attached to it (this does not take into account status from providers)
MC_SM_COMPONENT
sla_roleup_status
the aggregation of the compliance status of enumeration: the associated SLAs, if any MC_SM_SLM_SLA_STATUS LIST_OF_STRING
MC_SM_COMPONENT
shadow_cells
list of cells that contain shadow of the component instance
MC_SM_COMPONENT
status
main status of the component (equals computed_status unless manual status is set)
MC_SM_COMPONENT
StatusModel sub_status
name of the status computation model derived status of the component instance
STRING enumeration: MC_SM_COMPONENT_STATUS
MC_SM_COMPONENT MC_SM_COMPONENT
Type
user-defined categorization of a component STRING instance
BMC_BaseElement
VersionNumber
version number of the component instance, LIST_OF_STRING assigned by the manufacturer
BMC_BaseElement
WriteSecurity
list of permission groups that define who has write access to a component instance
LIST_OF_STRING
BMC_BaseElement
BMC_BaseElement enumerations
Enumeration types, such as MC_SM_COMPONENT_STATUS, are listed in the mc_sm_root.baroc file and their descriptions are provided in Table 7 on page 45.

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 41 shows the BAROC definition of the BMC_Impact superclass, which is located in the mc_sm_object.baroc file.
Appendix B
349
Figure 41
BMC_Impact definition
MC_PUBLISH_DATA_CLASS : BMC_Impact ISA MC_SM_RELATIONSHIP DEFINES { WriteSecurity : LIST_OF STRING; ShortDescription : STRING, default = 'na'; AccountID : STRING; ReadSecurity : LIST_OF STRING; }; END
BMC_Impact inherits slots from MC_SM_RELATIONSHIP, which is shown in Figure 42. MC_SM_RELATIONSHIP is located in the mc_sm_root.baroc file. Figure 42 MC_SM_RELATIONSHIP definition
MC_PUBLISH_DATA_CLASS: MC_SM_RELATIONSHIP ISA MC_SM_DATA DEFINES { PropagationModel: STRING; provider_home_cell: STRING; provider_classname: STRING; State: MC_SM_RELATIONSHIP_STATE, default = ACTIVE; StatusWeight : INTEGER, default=100; consumer_id: STRING, key = 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; true_impact: MC_YESNO, parse=no, read_only=yes, default = NO; change_number : INTEGER; }; END
MC_SM_RELATIONSHIP inherits slots from MC_SM_DATA (which contains no slots, as shown in Figure 43). MC_SM_DATA is located in the mc_sm_root.baroc file. Figure 43 MC_SM_DATA definition
MC_DATA_CLASS : MC_SM_DATA ISA CORE_DATA; DEFINES { publish_env_id : STRING, parse = no, read_only = yes;
};
END
MC_SM_DATA inherits slots from CORE_DATA, which is shown in Figure 44. CORE_DATA is located in the mc_root.internal.baroc file.
350
Figure 44
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, read_only = yes; }; END
Relationship slot descriptions in alphabetical order

Table 88 alphabetically lists the slots that define component instance relationships, with their descriptions and data type. The Source class column indicates the name of the class where the slot is defined. Table 88
Slot consumer_id change_number data_handle
BMC_Impact slot definitions in alphabetical order

Description mc_udid of the consumer component instance 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 name of the class of the provider component instance
INTEGER INTEGER STRING enumeration: MC_SM_COMPONENT_ STATUS enumeration: MC_SM_COMPONENT_ STATUS STRING
propagated_sub_status
PropagationModel
provider_classname
STRING
MC_SM_ RELATIONSHIP
Appendix B
351
BMC_DOWNTIME_STATUS_CONFIG data class
Table 88
Slot
BMC_Impact slot definitions in alphabetical order

Description the cell that receives events for the provider component instance Data type or enumeration STRING Source class MC_SM_ RELATIONSHIP MC_SM_ RELATIONSHIP MC_SM_ RELATIONSHIP MC_SM_ RELATIONSHIP
provider_home_cell provider_id
mc_udid of the provider STRING component instance, the impacting component instance state of the relationship, Active or Inactive enumeration: MC_SM_RELATIONSHIP _STATE
State
StatusWeight
number that determines the degree INTEGER of importance to give to each provider relationship that impacts a consumer component instance 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:
s s s s s s s s s s s s s
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.
352
BMC_STATUS_COMPUTATION data class
BMC_DOWNTIME_STATUS_CONFIG data class definition

Figure 45 shows the BAROC definition of the BMC_DOWNTIME_STATUS_ CONFIG data class, which is located in the mc_sm_root.baroc file. Figure 45 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 48. BMC_SIM_DATA is located in the mc_sm_root.baroc file. Figure 46 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 89
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 component instances. 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 component instance changes.
Appendix B
353
BMC_STATUS_COMPUTATION data class definition

Figure 47 shows the BAROC definition of the BMC_STATUS_COMPUTATION data class, which is located in the mc_sm_root.baroc file. Figure 47 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 48. BMC_SIM_DATA is located in the mc_sm_root.baroc file Figure 48 BMC_SIM_DATA definition
BMC_STATUS_COMPUTATION slots in alphabetical order

Table 90 alphabetically lists the BMC_STATUS_COMPUTATION slots with their descriptions and types.
354
BMC_STATUS_PROPAGATION data class
Table 90
Slot
BMC_STATUS_COMPUTATION slots in alphabetical order

Description Data type or enumeration Source class
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
impact_function
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
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 component instance 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 component instance
WriteSecurity
BMC_SIM_DATA

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.
Appendix B
355
BMC_STATUS_PROPAGATION class definition

Figure 49 shows the BAROC definition of the BMC_STATUS_PROPAGATION data class, which is located in the mc_sm_root.baroc file. Figure 49 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
BMC_STATUS_PROPAGATION inherits slots from BMC_SIM_DATA, which is shown in Figure 50. BMC_SIM_DATA is located in the mc_sm_root.baroc file. Figure 50 BMC_SIM_DATA definition
BMC_STATUS_PROPAGATION slots in alphabetical order

Table 91 alphabetically lists the class slots with their descriptions. Table 91
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 component instance 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 list of permission groups that defines who has read access to a component instance
ReadSecurity
LIST_OF_STRING BMC_SIM_DATA
356
BMC_PROPAGATION_MAP data class
Table 91
Slot
Status propagation slots in alphabetical order

Description Data type STRING Source class BMC_STATUS_PROPGATION
provider_type valid component types for the provider component instance WriteSecurity list of permission groups that defines who has write access to a component instance
LIST_OF_STRING BMC_SIM_DATA
BMC_PROPAGATION_MAP data class

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 51 shows the BAROC definition of the BMC_PROPAGATION_MAP data class, which is located in the mc_sm_root.baroc file. Figure 51 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 52. BMC_SIM_DATA is located in the mc_sm_root.baroc file Figure 52 BMC_SIM_DATA definition
BMC_PROPAGATION_MAP slots in alphabetical order

Table 92 alphabetically lists the BMC_PROPAGATION_MAP slots with their descriptions, enumeration or data type, and source class.
Appendix B
357
SIM data class descriptions
Table 92
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 list of permission groups that defines who has read access to a component instance applicable relationship state list of permission groups that defines who has write access to a component instance
BMC_PROPAGATION_MAP
enumeration: MC_SM_COMPONENT_STATUS LIST_OF_STRING
BMC_PROPAGATION_MAP
ReadSecurity
BMC_SIM_DATA
relationship_state WriteSecurity
enumeration: BMC_PROPAGATION_MAP MC_SM_RELATIONSHIP_STATE LIST_OF_STRING BMC_SIM_DATA
SIM data class descriptions

The following data classes are used in creating service models:
s s s s s
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 component instance.
358
BMC_SIM_MATCH_TABLE data class
BMC_SEVERITY_TO_STATUS data class definition

Figure 53 shows the BAROC definition of the BMC_SEVERITY_TO_STATUS class, which is located in the mc_sm_root.baroc file. Figure 53 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_SIM_MATCH_TABLE data class

The BMC_SIM_MATCH_TABLE is used to associate events with component instances. Figure 54 shows the BAROC definition of the BMC_SIM_MATCH_TABLE class. BMC_SIM_MATCH_TABLE is located in the mc_sm_event_mapping.baroc file. Figure 54 BMC_SIM_MATCH_TABLE definition
MC_PUBLISH_DATA_CLASS : BMC_SIM_MATCH_TABLE ISA BMC_SIM_DATA DEFINES { name : STRING ; tag : STRING , key=yes, read_only=yes, default=alias; input_match : LIST_OF STRING , key=yes; ref_instances_classes : LIST_OF STRING ; output_expressions : LIST_OF STRING ; }; END
BMC_SIM_ALIAS data class

The BMC_SIM_ALIAS is used to associate events with component instances. Figure 55 shows the BAROC definition of the BMC_SIM_ALIAS class. BMC_SIM_ALIAS is located in the mc_sm_root.baroc file.
Appendix B
359
BMC_SLOT_FORMULAS data class
Figure 55
BMC_SIM_ALIAS definition
MC_PUBLISH_DATA_CLASS: BMC_SIM_ALIAS ISA BMC_SIM_DATA DEFINES { ComponentAlias: STRING, key=yes; ComponentID: STRING; }; END
BMC_SLOT_FORMULAS data class

The SLOT_FORMULAS class is used to map event slots to other slots when processing a new raw event.
BMC_SLOT_FORMULAS data class definition

Figure 56 shows the BAROC definition of the SLOT_FORMULAS class, which is located in the mc_sm_event_mapping.baroc file. Figure 56 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 57 shows the BAROC definition of the BMC_TIME_SCHEDULE class, which is located in the mc_sm_root.baroc file.
360
BMC_TIME_FRAME_TO_SCHEDULE data class
Figure 57
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 timeframes to schedules. As part of the mapping it indicates whether the timeframe contains During Schedule or Exceptions Within During Schedule time. Figure 58 shows the BAROC definition of the BMC_TIME_FRAME_TO_SCHEDULE class, which is located in the mc_sm_root.baroc file. Figure 58 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 59 shows the BAROC definition of the BMC_SELF_PRIORITY_MAPPING class, which is located in the mc_sm_root.baroc file.
Appendix B
361
BMC_SERVICE_SCHEDULE_CONFIG data class
Figure 59
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 60 shows the BAROC definition of the BMC_SERVICE_SCHEDULE_CONFIG class, which is located in the mc_sm_root.baroc file. Figure 60 BMC_SERVICE_SCHEDULE_CONFIG definition
MC_PUBLISH_DATA_CLASS : BMC_SERVICE_SCHEDULE_CONFIG ISA BMC_SIM_DATA DEFINES { PriorityFormula : PRIORITY_FORMULA, default = WEIGHTED; DefaultSchedule : STRING; }; END
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 component instance. Figure 61 shows the BAROC definition of the BMC_STATUS_TO_SEVERITY class, which is located in the mc_sm_root.baroc file. Figure 61 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
362
SIM_TIME_FRAME class
SIM_TIME_FRAME class
The SIM_TIME_FRAME class defines a time period that can be used as part of a schedule. Figure 62 shows the BAROC definition of the BMC_STATUS_TO_SEVERITY class, which is located in the mc_sm_root.baroc file. Figure 62 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
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).
Appendix B Default service model data classes 363
Service model event classes
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 Impact Manager 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 (SIM only)

Figure 63 on page 365 shows the SIM-related definition of the class. For a complete description of all event class slots, see BMC Impact Solutions: Knowledge Base Development.
364
CORE_EVENT base class
Figure 63
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_object_class : STRING; mc_object : STRING; mc_tool_class : STRING; mc_tool : STRING; mc_tool_rule : STRING; mc_tool_key : STRING; mc_tool_sev : STRING; mc_origin_class : STRING; mc_origin : STRING; mc_origin_key : STRING; mc_origin_sev : STRING; mc_parameter : STRING; mc_parameter_value : STRING; mc_event_category : MC_EVENT_CATEGORY; mc_incident_time : INTEGER, representation = date; mc_arrival_time : INTEGER, representation = date; mc_local_reception_time : INTEGER, representation = date; date_reception : INTEGER, representation = date; date : STRING; 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; msg : STRING; duration : INTEGER, parse = no; mc_timeout : INTEGER; repeat_count : INTEGER; mc_action_count : INTEGER, parse = no; 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, hidden = yes; 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; mc_smc_id : STRING; mc_smc_alias : STRING; mc_smc_impact : INTEGER, default = 0; mc_smc_type : STRING; mc_smc_causes : LIST_OF STRING, parse = no; mc_smc_effects : LIST_OF STRING, parse = no; }; END
Appendix B
365
Root event class
CORE_EVENT slots
The CORE_EVENT slots are listed in BMC Impact Solutions: Knowledge Base Development.
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 64 shows the BAROC definition of the MC_SMC_ROOT class, which is located in the mc_sm_root.baroc file. Figure 64 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. Figure 65 shows the BAROC definition of the SMC_STATE_CHANGE class, which is located in the state.change.baroc file. Figure 65 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=2; }; END
366
Impact event class
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 66 shows the BAROC definition of the MC_SMC_EVENT class, which is located in the mc_sm_root.baroc file. Figure 66 MC_SMC_EVENT definition
MC_EV_CLASS: MC_SMC_EVENT ISA MC_SMC_ROOT DEFINES { mc_smc_impact : default = 1; 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.
Appendix B
367
Impact event class
368
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
Glossary
A
Abstract phase The event-processing phase in which Abstract rules are evaluated and, if conditions are met, abstraction events are generated. See also abstraction event. Abstract rule An event-processing rule that creates an abstraction event from one or more raw events. See also abstraction event. abstracted event An event that contributes to the creation of an abstraction event. The abstracted event is the basis for inferring that some condition exists. For example, if a critical subprocess of an application is down, the application is down. See also abstraction event. abstraction event A conceptual or summary event based on other events that are occurring. You cannot understand the context of an abstraction event by its details. To understand its context, you must view the relationships between the abstraction event and the events that triggered its creation in the BMC Impact Explorer Events tab, Relationships window. See also abstracted event. Acknowledge The event operation action that acknowledges the existence of an event. See also local action. Acknowledged status The event status that results from an Acknowledge event operation action; it means that an operator has acknowledged the event's existence. action 1. Generally, a procedure that is invoked to produce a specific result. It can be a script or a call to an executable that is invoked automatically in response to an event, or it can be a manual intervention. Actions can be scheduled or immediately invoked locally or remotely. 2. In BMC Impact Manager, an executable that can be run by a cell. Actions are called in an Execute rule. Users can request the execution of actions in the BMC Impact Explorer. See also local action and non-local action.
Glossary
369
adapter A background process that audits data from various sources, evaluates it for specific conditions, and creates the corresponding events. Adapters also transform event data into the format understood by BMC Impact Manager. adapter instance An instance of an adapter that is defined in the adapter configuration file. The definition is given a name and specifies an adapter type, such as a log file adapter. adapter map file A text file that defines the translation of a message between one event format and another. It is also known as a .map file. Administrative View The BMC Impact Explorer user interface for cell administration. Administrative users can start, pause, stop, and reconfigure a cell by using this interface. They can also make changes to a cells dynamic data tables. You access this view by clicking the Administration tab in BMC Impact Explorer. administrator The person responsible for administrative tasks within the product. alias See service component alias. annotated data point A specially marked point on a parameter graph that provides detailed information about a parameter at a particular moment. The associated data is accessed by double-clicking the data point, which is represented by a user-specified character. API See Application Program Interface (API). Application Program Interface (API) A set of externalized functions that allow interaction with an application. asset An object instance in the BMC Atrium Configuration Management Database (BMC Atrium CMDB). There are two types of assets in the BMC Atrium CMDB: non-service components, such as desks and other non-IT physical assets, and service components that participate in the delivery of enterprise services. asset inventory The list of all physical and logical assets that have an identifiable value to the organization or against which threats and vulnerabilities can be identified and quantified as part of risk assessment.
370
Assign To The event operation action that assigns the responsibility for an event to an individual. Assigned status The event status that indicates that the specified operator is responsible for the event. It results from the Assign To or the Take Ownership event operation actions. attribute A characteristic or property of an object, such as a common-data-model service-model component class. An attribute may contain a value. automation In BMC Impact Explorer, operator responses that have been programmed to occur automatically when an event is received.
B
BAROC language Basic Recorder of Objects in C. A structured language used to create and modify class definitions. A class definition is similar to a structure in the C programming language. The elements in a BAROC class are called slots. base class In programming, a root superclass, a class from which all other classes of its type are derived. base priority A static priority value that is combined with the component's current status to determine the final self-priority value. Typically, the base priority determines the highest self-priority that a component will reach when its status become Unavailable. blackout schedule A schedule that determines when one or more components will be automatically placed in a blackout state. BMC Atrium CMDB Common Data Model (BMC Atrium CMDB CDM) An extensible schema that provides a unified representation of configuration items and their relationships to each other. It is used to store asset data (such as hardware information, service management information, and people information) and to provide a mechanism for linking that information to provide a complete view of how all assets are connected and can affect each other. BMC Atrium CMDB Reconciliation Engine The BMC Atrium CMDB application used to merge data from multiple sources, such as topology discovery and configuration discovery, into a consistent dataset.
Glossary
371
BMC Atrium Configuration Management Database (BMC Atrium CMDB) The database application that is the common datastore for asset, configuration management, and service model data in BMC Business Service Management products. It enables BMC products to share IT management and monitoring data and perform service management. BMC Desktop Status Indicator (BMC DSI) An icon that appears in the desktop system tray of a computer to show the current status of an object being monitored by BMC Impact Portal. To view the status page of the monitored object, you double-click the icon. BMC Event Manager (BMC EM) A real-time event management product license package that provides event management, including event collection, correlation, enrichment, and integration. It enables IT operations staff to focus the proper resources on resolving the most critical events. BMC EM See BMC Event Manager (BMC EM). BMC IDG See BMC Impact Database Gateway (BMC IDG). BMC IEA See BMC Impact Event Adapters (BMC IEA). BMC IELA See BMC Impact Event Log Adapter for Windows (BMC IELA). BMC Impact Database Gateway (BMC IDG) The interface that enables BMC Impact Manager events to be exported to a relational database. BMC Impact Event Adapters (BMC IEA) The adapters that collect log file information, convert it to BMC Impact events, and send the events to designated BMC Impact Manager instances. BMC Impact Event Log Adapter for Windows (BMC IELA) The native Windows platform executable that audits Windows event logs. It runs as a Windows service and checks for new event log records. BMC Impact Explorer (BMC IX) The console with which you can connect to BMC Impact Manager instances, examine the events stored in them, and perform event and service management activities. BMC Impact Explorer Server Obsolete term. See BMC Impact Portal.
372
BMC Impact Integration product (BMC II product) An interface that enables the synchronized flow of events and data between a BMC Impact Manager instance and another BMC Software product or a specific third-party product. BMC Impact Manager (BMC IM) The BMC Impact product that provides automated event and service impact management. It runs as a service on supported Windows platforms and as a daemon on UNIX platforms, and can be distributed throughout the networked enterprise and connected in various topologies to support IT goals. BMC Impact Manager instance An installation of the BMC Impact Manager product on a host computer. Compare with cell. BMC Impact Publishing Server The BMC Impact Portal service or daemon that obtains the service model from the BMC Atrium CMDB and publishes (distributes) it to the designated service impact management cell or cells. BMC Impact Portal The BMC Portal module that you use to monitor the status of business services and their components. BMC Impact Reporting The BMC Impact Solutions component that you use to create and view long-term reports. BMC Impact Service Model Editor A graphical editor that you use to develop, maintain, and extend the service model that is stored in the BMC Atrium Configuration Management Database (BMC Atrium CMDB). BMC Impact Web Console (BMC IWC) Obsolete term. See BMC Impact Portal. BMC IWC Obsolete term. See BMC Impact Portal. BMC IX See BMC Impact Explorer (BMC IX). BMC IXS Obsolete term. See BMC Portal. BMC Portal A BMC product that consists of the BMC Portal Server (infrastructure) and console modules, each of which deliver specific Business Service Management (BSM) functionality. The BMC Impact Portal and BMC Performance Manager Portal are examples of console modules. BMC Reporting Foundation The base component on which BMC Software reporting systems and solutions are built.
Glossary 373
BMC Service Impact Manager (BMC SIM) A real-time service impact management product license package that provides technologies for both service impact and event management. BMC SIM identifies related applications and the underlying systems and databases of any software or infrastructure component and ties systems-level monitoring to the supported business services, enabling IT personnel to respond quickly to problems that threaten the delivery of business services. BMC SIM See BMC Service Impact Manager (BMC SIM). BMC_System class In the BMC Atrium CMDB Common Data Model, the parent class for all system information. In this class tree, classes representing computer systems, mainframes, application systems, and virtual systems are defined. built-in action An automated, predefined action performed by a system. business function A group of business processes that make up a specific function, such as customer support. business objects An object defined in the BMC Impact Service Model Editor, published to a BMC Impact Manager instance, and monitored in BMC Impact Portal. Business objects contribute business service data for use in status indicators and reports. business process A series of related business activities that operate to achieve one or more business objectives in a measurable way. Typical business processes include receiving orders, marketing services, delivering services, distributing products, invoicing for services, and accounting for money received. A business process rarely operates in isolation. It depends on other business processes, and other business processes, in turn, rely on it. A business process usually relies on several business functions for support, such as IT and Personnel. business process decomposition The identification and cataloging of the business activities and IT resources that combine to make up a business process. The result of business decomposition is a business process model. business service A service that is identifiable by business representatives and supports explicit business processes that have a clear link to the businesss value chain. Most business services have an easily identifiable senior business representative, are composed of a number of specific applications, and rely on the functioning of infrastructure services. For example, the provision of all logistic components underpinning the sale of consumer goods is a business service. See also service.
374
Business Service Management (BSM) A dynamic method for connecting key business services to the IT systems that manage them. BSM enables users to understand and predict how technology changes will affect their business, and how changes in the business affect the IT infrastructure.
C
cause event In a sequence of events, the event that is identified as the cause of the other events. See also effect event. CDM See BMC Atrium CMDB Common Data Model (BMC Atrium CMDB CDM). cell The event processing engine that collects, processes, and stores events within a BMC Impact Manager instance. Each cell uses the information in its associated Knowledge Base to identify the types of events to accept and how to process and distribute them. child collector A collector contained within another collector. See also event collector. class 1. A data storage element. In database terms, it relates to a table in a database or a form in the Remedy AR System. 2. In BMC Impact Manager, a BAROC-language data structure that defines a type of object used in BMC Impact Manager. A BAROC class is made up of data fields, called slots, that define its properties. 3. In BMC Impact Portal: see object class. CLI command A command that is issued on the OS command line for automation or immediate execution. For a complete list of CLI commands, see BMC Impact Solutions: Administration. See also command line interface (CLI). Close The event operation action that closes an event. If the event was assigned to the current user, Close sets the status to Closed and shows an Operator Closed entry in the operation history. Otherwise, Close sets the status to Closed and shows an Override Closed entry in the operation history. Closed status The event status that results from a Close event operation action.
Glossary
375
CMDB See BMC Atrium Configuration Management Database (BMC Atrium CMDB). collector See event collector. collector rule See event collector rule. collector set See event collector set. command line interface (CLI) A user interface in which you issue commands one at a time on a command line for automation or immediate execution. In BMC Impact Manager, you use the CLI in conjunction with a graphical user interface (GUI) to operate the product. component A logical or physical asset that is represented in the BMC Atrium CMDB. There are two types of assets represented in the BMC Atrium CMDB: non-service components, such as desks and other non-IT physical assets, and service components that participate in the delivery of business services. See also service component. component instance A named component that represents an actual IT resource. See also service component. component pool A reference to all of the logical and physical assets that participate in the delivery of enterprise services and can be part of the service model. The component pool includes both assets that are part of the service model and assets that are not. See also object and component. component relationship See service component relationship. component type In the Service Model Editor, an icon with an editable template that represents a specific common data model component class. A user can select a component type and edit its template to create a new instance of the component class. computed priority See priority. configuration management database (CMDB) See BMC Atrium Configuration Management Database (BMC Atrium CMDB).
376
console One of the following commonly BMC Impact Manager product GUIs: BMC Impact Portal, BMC Impact Explorer, BMC Impact Reporting Console, and Service Model Editor. console local action An action taken from a console and that is executed on the console host computer. consolidation node A BMC Impact Manager instance that can receive and process events originating from other systems on the network. consumer In a service model component relationship, the component that uses a service provided by another component, the provider. See also provider. core competency Capabilities that collectively account for all business activities within a business enterprise, such as planning and developing products. CORE_DATA class The base class for all BMC Impact Manager BAROC data classes. It is the parent class for all customized data classes. CORE_EVENT class The base class for all BMC Impact Manager event classes. It is the parent class for all customized event classes. Correlate phase The event-processing phase in which the Correlate rules are evaluated to determine whether any events have a cause-and-effect relationship. See also Correlate rule. Correlate rule An event-processing rule that establishes the cause-and-effect relationship between two events. Correlate rules represent a one-to-one relationship. correlation 1. The process of identifying a cause-and-effect relationship between two events from one or more sources for the purpose of identifying a root cause. 2. The cause and effect relationship itself. 3. A type of policy.
Glossary
377
D
data class A BAROC class that is a child of the base data class, CORE_DATA, and that defines a type of data. Users can create their own data classes. datastore A central place in which an aggregation of data is kept and maintained in an organized way. Decline Ownership The event operation action that indicates that the assigned operator does not accept responsibility for an event. Decline Ownership clears the owners name, sets the status back to Acknowledged, and shows a Declined entry in the operation history. default status view type In the BMC Impact Portal, one of the view types available from the Status tab. Delete phase The event-processing phase in which Delete rules are evaluated and actions are taken to ensure that data integrity is maintained when an event is deleted from the event repository during the cleanup process. Delete rule An event-processing rule that is used to clean up obsolete information when an event is deleted from the repository. Delete rules are evaluated when an event is deleted and they take actions to ensure that data integrity is maintained. destination One end of a relationship. In the case of an impact relationship, it is the end associated with the consumer of events. draft service model A working version of the service model that can contain both published and unpublished elements. duplicate event A subsequent occurrence of an event that has already been received, such as the second or later notification that a component is down. An event that has matching values for all the slots defined with the dup_detect=yes facet in the event class definition. You can use Regulate rules to detect and count duplicate events. See also facet. During Schedule Time periods in which a component has a higher service demand and higher importance than in the off-schedule time period. In a During Schedule time period, the component is typically assigned a higher priority value and downtime cost than during an off-schedule time period.
378
For example, if a high service demand occurs during 9:00 AM and 5:00 PM, you can create a During Schedule timeframe for that time period. See also off-schedule time and Exceptions Within During Schedule. During Schedule cost The outage cost (per second) related to the component when the outage occurs within the During Schedule timeframe. dynamic collector A special type of collector that, in response to events, can add or remove event collectors from the cell during runtime. dynamic data Contextual reference data that is stored in a table in the event repository (mcdb) and that is updated during runtime if the context has changed. Administrators can use and manipulate dynamic data in the BMC Impact Explorer Administration View.
E
ECF See Event Condition Formula (ECF). effect event In a sequence of events, the event that is identified as an effect of a cause event. See also cause event. elected event See impact event. encryption key The seed encryption key. If the destination product has a key value, all clients must encrypt their communications using the same key value. enrichment 1. The process of adding to or modifying the original event data to enhance it for problem management, service management, correlation, automation, notification, or reporting functions. 2. A type of policy. escalation 1. The process of referring a problem up the chain of command. 2. A type of policy.
Glossary
379
escalation procedure The particular steps defined for performing escalation. For example, you might specify that operations personnel would be notified within 5 minutes of a problem occurrence, a manager would learn of it after 15 minutes, and a director after 1 hour (if the problem still exists). event In a BMC Impact environment, a structured message passed to and from cells. Each event is an instance of an event class. Event Adapters See BMC Impact Event Adapters (BMC IEA). event class 1. A BAROC class that is a child of the base event class, CORE_EVENT, and that defines a type of event. 2. A category of events that you can create as a child of the base event class, CORE_EVENT, according to how you want the events to be handled by an event manager and what actions you want to be taken when the event occurs. Event classes may be inherited from parent objects, depending on the specific product. Event classes are inherited from parent objects in BMC Impact Manager. event collector An event grouping whose content is defined by its collector rule. Event collectors are displayed in the BMC Impact Explorer and are defined in the BMC Impact Manager Knowledge Base. See also event collector rule. event collector rule A type of rule in the Knowledge Base that defines how events from a cell are organized and presented in the BMC Impact Explorer. Collector rules are written in Master Rule Language (MRL). event collector set A group of event collectors, organized in a parent-child hierarchy, that results from progressive filtering of the incoming events that match the top-level (parent event collector) criteria. A collector set organizes the events for display in the BMC Impact Explorer. Event Condition Formula (ECF) The section of an MRL rule definition that specifies the conditions that an incoming event must meet to trigger evaluation of the rule during processing. For example: APP_MISSING_PROCESSES where [hostname: == red1,sub_origin: contains System] is an ECF. See Master Rule Language (MRL). event datastore An archive of generated event data.
380
event group A grouping of collectors that depicts the relationship of events through the hierarchy of the navigation tree. Each level of the collector set is shown as a node under the event group. The parent level of an event group represents all of the events associated with the collectors. An event list is associated with the lowest level nodes of an event group. The parent level of an event group is associated with an image view. event list 1. A tabular listing of events. 2. In BMC Impact Explorer, you can access the event list from the Events tab. Event Log Adapter for Windows See BMC Impact Event Log Adapter for Windows (BMC IELA). event management The collection and correlation of events across an enterprise to enable IT operations to focus the proper resources on the most critical events. event management policy One of several generic rule types that perform actions against events that meet selection criteria specified in an associated event selector. Unlike manually written rules, event policies are defined interactively using the Event Management Policy Editor in the BMC Impact Explorer. See also user-defined policy. event operation history The tabular display of the operation actions taken against an event in BMC Impact Explorer. You can access the event operation history from the Operations History tab of the Event Details pane on the Events tab in BMC Impact Explorer. event operations Commands issued by operators to respond to events and correct the problems that the events represent. Operators perform these commands from an event list in BMC Impact Explorer. event processor See cell. event propagation The act of forwarding events and maintaining their synchronization among multiple BMC Impact Manager instances (cells). event repository 1. An archive of generated event data. 2. In BMC Impact Manager instances (cells), the storage facility (mcdb) in which event information is stored.
Glossary
381
event selection criteria The syntax of an event selector that specifies the conditions that an incoming event must meet to trigger selection of the event for rule evaluation during each phase of event processing. You can specify event selection criteria through the BMC Impact Explorer GUI. An MRL Event Condition Formula (ECF) also contains event selection criteria. An event selector contains one or more event selection criteria. event selector The filtering mechanism associated with an event management policy that selects the events against which the event management policy performs actions. An event selector contains one or more event selection criteria. Event selectors are defined interactively by using the BMC Impact Explorer. An event management policy can use one or more event selectors. event source The monitored IT resource from which source event data is collected, such as an operating system or application log file. event timeout An event timeout policy changes an event status to closed after a specified period of time elapses. Events View The BMC Impact Explorer user interface for viewing and manipulating event data. See also Services View and Administration View. Exceptions Within During Schedule Time periods in a service schedule that are exceptions to the During Schedule timeframe, and in which a component has a lower service demand and lower importance than in the During Schedule time period. For example, if you have a During Schedule timeframe of 9:00 AM to 5:00 PM, you can specify the period between 12:00 PM and 1:00 PM as an Exception Within During Schedule timeframe. The time between 12:00 and 1:00 is treated as Off schedule time, and a lower priority is associated with the component in that time. See also During Schedule and offschedule time. Exceptions Within During Schedule cost The outage cost (per second) related to the component when the outage occurs within the Exceptions Within During Schedule timeframe. Execute phase The event-processing phase in which Execute rules are evaluated, and, if conditions are met, specified actions are performed. Execute rule An event-processing rule that performs actions when an attribute (slot) value changes in the event repository. Execute rules are evaluated during the Execute phase of event processing. Often, the resulting actions are internal actions, but you can use the execute primitive in a rule to call an external executable.
382
expression A combination of operators, operands (constants, variables, functions, and primitives), and conditions that represents a value or a relationship between values.
F
facet A specific attribute of a BAROC class slot (field) that either controls the values that the slot can have or controls aspects of a class instance's processing. field See attribute. Filter phase The event-processing phase in which Filter rules are evaluated to determine which events need additional processing or are unneeded and can be discarded. Filter rule An event-processing rule that determines whether a specific type of event should be passed as it is, subjected to further processing, or discarded during the Filter phase. function Code that executes an operation in a cell and returns a value. A function can be used as an expression within a rule or a policy and in alias formulas. See also primitive.
G
gateway See BMC Impact Integration product (BMC II product). gateway.export file A special file that controls the propagation and synchronization of events to a BMC Impact Manager Integration product. The file is in the $MCELL_HOME/etc/ directory on UNIX platforms and in the %MCELL_HOME\etc\ directory on Windows platforms. global record A special BAROC class instance that defines a persistent global variable. When a cell starts, it creates one instance of each global record defined in the Knowledge Base and restores any existing values. Global record definitions are stored in the record subdirectory of the cell Knowledge Base. You can get and set global record values in MRL rules or by using the BMC Impact Manager CLI mgetrec and msetrec commands. global slot order In BMC Impact Explorer, a set of slots (attributes), in a particular order, that is associated with a filter and is shared among users.
Glossary
383
global timeframe A timeframe that is created in the Service Model Editor and stored in the BMC Atrium CMDB. A global timeframe is usable from within the BMC Impact Service Model Editor and the BMC Impact Explorer and is available to all cells within an environment. See also local timeframe. group A logical or an arbitrary collection of user-defined objects that may or may not have measurable relationships and may or may not have summary data associated with them.
H
heartbeat 1. A periodic message sent between communicating objects to inform each object that the other is still active and accessible. 2. In BMC Impact Manager, a dynamic data object sent by a cell to monitor other cells to verify that they remain active and accessible. heartbeat interval The time between heartbeats; the period of the heartbeat. highest value function A calculation method that is used to determine impacts priority
I
image view A graphical and hierarchical display that depicts a business view. You can create image view objects or elements to represent managed systems (tools), geographic locations, operators, time, severity levels, categories, and so forth. impact An assessed measure of the effect that an incident, fault, or other change will or may have on business operations or service levels. impact event An event whose status is used in computing the status of its associated service component. By default, the status of each event associated with a service component is used to compute its status. However, you can exclude events. impact production dataset Instances of an environment that are effectively published to the environments impact managers. The following example is an impact dataset: BMC.IMPACT.PROD: the impact production dataset associated with the BMC Impact Service Model Editor
384
impact propagation The effect of an impact to a providing service component (provider) on the service components that use its services (consumers) as defined by an impact relationship. See also impact relationship. impact relationship A relationship between two service components in a service infrastructure in which a consumer component depends on a provider component to deliver some needed resource to it. A change in status of the provider affects (has an impact on) the status of the consumer component. impacted state The object state that indicates that an objects functioning is impaired. impacts priority The priority of a component based on the self-priorities of components that this component impacts. So that the remediation process can be aligned with business needs, the computed priority for each causal component is based upon impacts priority. The value is the result of the combined priorities of all the other components that are impacted when the component goes down. The value is dynamic and changes as the self-priorities of the impacted components change. import dataset A dataset that contains objects imported to the BMC Atrium CMDB from an external data source such as BMC Topology Discovery. inactive relationship A relationship between two components in a service infrastructure in which there is no impact to the consumer component. An inactive relationship indicates that the two components are connected logically and are represented visually as linked. See also impact relationship. in-model Qualifies a service component as being part of a service model. By default, new components in the BMC Atrium CMDB do not belong to any service model. To change a component to inmodel, you will typically use the BMC Impact Service Model Editor. Impact relationships get automatically set to in-model when their related components are in-model. Only those that are in-model can be published to a production cell. included timeframes A set of timeframes that are included in the service schedule. index A value that is used by an MRL rule to sort the slot information for an event or data object. informational alert An alert of relatively low importance, such as a message about a routine state change. See also severity.
Glossary
385
infrastructure element An addressable object that can be monitored, such as a managed system in PATROL. instance 1. A specific object with specific attributes or characteristics that distinguish it from other items (members) of its class or type. 2. In BMC Impact Manager, an object that has specific attribute values and that was created using a class definition. integration product See BMC Impact Integration product (BMC II product). interface class A BAROC class that defines the programming interface used by an MRL rule primitive, such as get_external, to return data from an external program. At cell startup, an interface class is loaded into memory. The cell invokes the executable defined in an argument of the primitive. The executables value is returned by the interface. internal base class A BAROC internal class that defines the required structure for the base class from which a group of BMC Impact Manager classes is derived. internal event An event that is created by the cell during event processing. An internal event is processed in the same way as an incoming event. All internal events are processed before any new, incoming external events are processed. Internet Protocol (IP) adapter An adapter that collects and translates events from a Telnet, UDP, or TCP data source. IP adapter See Internet Protocol (IP) adapter. IT component See BMC_System class.
K
key slot A slot whose value is compared during searches. Knowledge Base (KB) A collection of information that forms the intelligence of a BMC Impact Manager instance and enables it to process events and perform service impact management activities. This information includes event class definitions, service component definitions, record definitions, interface definitions, collector definitions, data associations, and processing rules.
L
local action An executable that you can run directly from the BMC Impact Manager. Local actions are written in XML and are stored in the OS-specific subdirectory of the bin directory of the BMC Impact Manager cell Knowledge Base. local timeframe A timeframe that is created in the BMC Impact Explorer. A local timeframe is stored in a single cell and is available to the event management policies within the cell. See also global timeframe. logical component A non-physical object that represents something that does not exist physically in the IT infrastructure such as a service, geography, organization, or user group.
M
macro An executable used in .map files to manipulate the fields used for event translation. manifest.kb A central locator file that specifies the locations of the directories that make up a Knowledge Base. The manifest.kb file is used by the compiler to load the Knowledge Base sources files for compilation. map See image view. masking The process of combining an overlay dataset with a standard dataset to obtain a view in which the standard dataset objects are overlaid or masked by any modified copy contained in the overlay dataset. Master Rule Language (MRL) A compact, declarative language used to define rules and collectors for processing and organizing events in BMC Impact Manager. Uncompiled rule and collector source files have a .mrl file extension. mccomp The BMC Impact Manager rules compiler. Rules are written in the Master Rule Language (MRL). The platform-independent compiler converts them to byte code that the cell can read and process. mcdb See event repository.
Glossary
387
mcell.conf file The configuration file that contains configuration options for a BMC Impact Manager instance (cell). It is in the $MCELL_HOME/etc/ directory on UNIX platforms and in the %MCELL_HOME%\etc\ directory on supported Windows platforms. mcell.dir file The file that lists the cells to which a BMC Impact Solutions product or component can connect and communicate. The information in each cell includes its name, its encryption key, and its host name and port number. This file is in the $MCELL_HOME/etc/ directory on UNIX platforms and in the %MCELL_HOME%\etc\ directory on supported Windows platforms. mcell.modify file The file that lists the slots that affect the mc_modification_date slot. When a specified slot is modified, the time stamp of the modification is reset in the mc_modification_date slot, so that slot is listed in mcell.modify. mcell.propagate file The configuration file that specifies the slot values that are synchronized during event propagation between BMC Impact Manager instances (cells). It is in the $MCELL_HOME/etc/ directory on UNIX platforms and in the %MCELL_HOME%\etc\ directory on supported Windows platforms. mcell.trace file The configuration file that specifies the trace information about a BMC Impact Manager (cell) that should be recorded and the location to which it is written. It is in $MCELL_HOME/etc/ directory on UNIX platforms and in the %MCELL_HOME%\etc\ directory on supported Windows platforms. mclient.conf file The configuration file that specifies the configurations for the BMC Impact Manager CLI commands. It is in the $MCELL_HOME/etc/ directory on UNIX platforms and in the %MCELL_HOME%\etc\ directory on supported Windows platforms. mclient.trace file The configuration file that specifies the trace information that should be collected for the BMC Impact Manager CLI commands and the location to which it should be written. This file is in the $MCELL_HOME/etc/ directory on UNIX platforms and in the %MCELL_HOME%\etc\ directory on supported Windows platforms. mcontrol command The CLI command that sends control commands to a BMC Impact Manager instance (cell). mc_udid See universal data identifier (mc_udid).
388
mean time between failures (MTBF) The average elapsed time from the point at which an IT service object is made available until the next occurrence of failure in the same service object. mean time between system/service incidents (MTBSI) The average elapsed time between the occurrence of a system or service failure and the next failure in the same system or service. mean time to repair (MTTR) The average elapsed time from the occurrence of an incident to restoration of the service. metaclass See internal base class. MetaCollector A virtual collector that contains a group of event collectors from multiple BMC Impact Manager instances. It exists only in the BMC Impact Explorer. You can customize it to suit your organizational needs. module A product that plugs into the BMC Portal. MTBF See mean time between failures (MTBF). MTBSI See mean time between system/service incidents (MTBSI). MTTR See mean time to repair (MTTR).
N
navigation tree See navigation tree view. navigation tree view 1. A hierarchical display of the objects and user-defined groups and views. 2. In BMC Impact Explorer, a hierarchical view of defined objects and groups. An object can be a filter, rule, or event. The groups are arranged to show relationship and dependency between the managed systems. The navigation tree view appears in the left pane. 3. In the BMC Portal, a hierarchical display of groups defined in a view.
Glossary
389
New phase The event-processing phase in which New rules are evaluated to determine which events in the repository should be updated with new information from new incoming events. New rule An event processing rule that is evaluated during the New event processing phase, and can update events stored in the repository (mcdb) with fresh information from new incoming events. node A BMC Impact Manager instance that can receive only events originating on the local host system. non-local action A user-initiated action that does not execute on the user console host computer. non-service component A logical or physical asset defined in the BMC Atrium CMDB that does not participate in the delivery of business services, such as a desk or other non-IT physical asset. A non-service component is not visible within the BMC Impact Service Model Editor. normalization The process of homogenizing event data into a common event format so that a standard set of event data is collected and reported regardless of the event source. not-in-model A service component that exists as a logical or physical asset in the BMC Atrium CMDB but is not currently part of the service model. A not-in-model service component is visible within the BMC Impact Service Model Editor component pool. notification 1. A message, either detailed or concise, that contains information about a condition that triggered an alert state on a monitored element. An email message or SNMP trap that is sent when the program detects a problem that triggers an alert. 2. A type of policy. null relationship See inactive relationship.
390
O
object 1. An item that can be inserted into a dashboard. For example, a chart, link, or Active-X control. 2. A generic term for anything that is displayed in the user interface. See class. object class In BMC Impact Solutions, a data structure that defines a type of object. An object class can be a BAROC-language data structure in a BMC Impact Manager cell Knowledge Base or a Common Data Model (CDM) data structure in the BMC Configuration Management Database. A class is made up of data fields, called attributes (slots) that define its properties. See also event class and object. object linking In BMC Portal, the ability to associate two objects that are the same IT asset or resource but that occur in different console modules, and manage them as one object. off-schedule time Time periods in which the component has a lower service demand, a lower priority, and lower downtime cost than in the During Schedule time periods. Off-schedule time includes any time that is not defined in the service schedule. Exceptions Within During Schedule time periods are treated as off-schedule time when determining base priority. See also service schedule, Exceptions Within During Schedule, and During Schedule. open event An event that may require action. An open event may have a status of Open, Acknowledged, Assigned, or Blackout. Open status The event status that indicates that the event has not been examined, or that neither an operator nor an automated process has been assigned responsibility for the event.
P
parent event collector A event collector that contains child collectors to form an event collector set. permission A rule associated with an object to control which users, groups, and roles can access the object and in what manner. A permission gives the user a specific type of access to the object (for example, read permission or write permission). See right. phase, rule See rule phase.
Glossary
391
policy See event management policy. policy class A BAROC class that is a child of the base data class POLICY and that defines a type of policy. policy instance A specific implementation of any of the types of event management policies. For example, you could have an instance of a blackout policy that defined blackout periods for holidays and another instance of the same policy that defined blackout periods for monthly maintenance. port A number that designates a specific communication channel in TCP/IP networking. Ports are identified by numbers. BMC Impact Manager communicates using the ports specified during installation. portal The access point for web-based management tools. The portal houses applications installed by a user and communicates with remotely monitored systems. See also BMC Portal. presentation name A descriptive name or label that you can designate to appear instead of a specific internal slot name or class name in the user interface screens. You define presentation names in resource files. primitive Similar to a function, code that executes an operation in a cell and returns a value; can be used as an instruction, or as a function if contained in a Boolean expression. priority An attribute indicating the precedence or scale of importance of an event. priority propagator A component that is configured to propagate its priority to its causal components. production cell A BMC EM or BMC SIM cell that service operators and service managers use to monitor the events and services associated with IT resources in real time. production view A read-only view in the BMC Impact Service Model Editor that displays some of the components and relationships contained in the production dataset (the visibility can be constrained by user permissions). Each BMC Impact Service Model Editor user can have several of these views. BMC Impact Service Model Editor users can dynamically convert a production view into a sandbox View. See also sandbox and sandbox View.
392
promotion A user-initiated action in BMC Impact Service Model Editor that assists in reconciling objects (such as components, relationships, and management data) from a sandbox dataset to the production dataset. Propagate phase The event-processing rule phase in which Propagate rules are evaluated to determine the events to be forwarded to another cell or to a BMC Impact Integration product. propagate policy A type of policy that forwards events to other cells in the managed domain. A propagate policy is evaluated during the Propagate phase of event processing. propagate priority When a component forwards its self-priority to its causal components. Propagate rule An event-processing rule that is used to forward events to other cells in the managed domain. Propagate rules are evaluated during the Propagate phase of event processing. propagated event An event that is forwarded from one cell to another cell or to a BMC Impact Integration product during the Propagate phase of event processing. provider A logical or physical asset that delivers services or provides resources that are used by other service components in the delivery of business services. publish environment An environment that consists of a production dataset, an impact production dataset, and one or more test or production cells that are published. published-modified component A service component that has been modified since its service model was published (distributed) to BMC Impact Manager instances. published component A service component that is currently part of the published service model that has been distributed to BMC Impact Manager instances. publishing The automated or user-initiated action performed by the BMC Impact Publishing Server in which components, relationships, and management data from the production dataset are published to one or several production or test cells. publishing server See BMC Impact Publishing Server.
Glossary
393
published service model A service model that is currently distributed to BMC Impact Manager instances (cells). It contains only published elements.
R
Reconciliation Engine See BMC Atrium CMDB Reconciliation Engine. record See global record. recurrence 1. The characteristic of occurring more than once. 2. The type of policy that handles recurrent events. See also recurrent event. recurrent event An event that occurs more than one time. Both scheduled and unscheduled events can be recurrent events: a monitored hardware device could experience multiple voltage spikes within a single polling cycle, and a reminder notification could be scheduled to be sent periodically until acknowledgment is received. See also duplicate event. Refine phase The first phase of event processing, in which Refine rules are evaluated to validate incoming events and, if necessary, collect additional data needed before further event processing can occur. Refine rule A rule evaluated during the first phase of event processing to validate an incoming event and, if necessary, to collect any additional data needed before further processing can occur. regular expression Sometimes referred to as regex, regular expressions are used in pattern matching and substitution operators. A simple regular expression is a sequence or pattern of characters that is matched against a text string when performing search and replacement functions. Regulate phase The event-processing phase in which Regulate rules are evaluated and, if true, collect duplicate events for a time period and, if a specified threshold of duplicates is reached, passes an event to the next processing phase. Regulate rule An event-processing rule that processes duplicate events or events that occur with a specified frequency. With a Regulate rule, you can create a new event based on the detection of repetitive or frequent events. See also Regulate phase.
394
related event The event that was generated by a source event. A related event can also be the source of other related events. relation A logical association that expresses the relevance of one event to another. relation definition The BAROC data instance that defines a relation. remote action A user-initiated action that does not execute on the user console host computer; an executable that can be run by a cell. Remote actions are written in the Master Rule Language (MRL) and are stored in the OS-specific subdirectory of the bin directory of the Knowledge Base. Reopen The event operation action that reopens an event that is in the Closed state. Reopen sets the status to Open and shows a Reopen entry in the operation history. repository See event repository. restricted object A dynamically created object that contributes to service status, but which the user does not have permission to view. right An authorization entitling a user to perform a certain action. Rights apply to a whole application or to specific objects of a certain type. root cause analysis The process of monitoring events and correlating event data to identify the true cause of a problem. rule A conditional statement written in MRL and that, if determined to be true, executes actions. Cell event processing occurs in phases with the cell comparing each event to the series of rules associated with that phase. Each phases rules are evaluated one by one before the event is passed to the next phase. The order in which rules are evaluated during a particular phase is based on the order in which the rules were loaded. rule engine See cell. rule phase A specific stage of event processing. Event processing compromises a combination of sequential phases and nonsequential phases, each with a corresponding rule type.
Glossary
395
rule type The designation that identifies a rule as being in a specific phase of event processing. The cell executes rules within the context of the associated event-processing phase and in the order in which the rules were loaded from the rule file.
S
sandbox An overlay dataset associated with 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. sandbox View In the BMC Impact Service Model Editor, a personal work area for designing and developing a service model. saved state The state of a BMC Impact Manager instance (cell) as determined by the StateBuilder utility, statbld.exe. The StateBuilder utility periodically consolidates the data in the transactions file (xact) to produce the saved state of the product instance. This information is stored in the event repository (mcdb) and the state is reloaded when BMC Impact Manager restarts. schedule See service schedule. SDK See Software Development Kit (SDK). selector See event selector. selector class A BAROC class that is a child of the base data class SELECTOR and that defines a type of event selector. self-priority The result of mapping the base priority value for a component with its status value. send to test A user-initiated action in the BMC Impact Service Model Editor in which objects (such as components and relationships) are copied from a sandbox View to a test dataset. The copy captures both sandbox objects and production objects to reproduce a consistent model or submodel in the test environment.
396
service An integrated composite of several components, such as management processes, hardware, software, facilities, and people, that delivers something of value to satisfy a management need or objective. service catalog A list of IT services that identifies the physical and logical assets that help provide a service. The data collected in the service catalog can be used to form a configuration management database. service component A logical or physical resource that participates in the delivery of services. A service component is any class that is a subclass of the BMC_BaseElement class in the BMC Atrium CMDB or the cell Knowledge Base. service component alias A name that is assigned to a service component instance and used in associating an event type with the component instance. You add an alias to a service component instances definition in the Service Model Editor. A service component instance can have several different aliases to enable different event types to be associated with it. service component relationship In a service model, the association of two service components in which one component, the provider, delivers some resource or service to the consuming component or components. See also provider and consumer. Service Impact Management (SIM) A technique for managing the impact of IT events on the companys core business services to ensure their delivery. See also BMC Service Impact Manager (BMC SIM). service model An extensible system for defining the various resources that combine to deliver business services, for modeling their behaviors and functional relationships, and for managing the delivery of the resulting services. In Service Impact Management, the map of how IT components relate to the business processes that they support. All IT events and service issues are analyzed against the service model to determine the root cause of problems and to report on service impacts. service schedule A set of timeframes that includes During Schedule timeframes, Exceptions Within the During Schedule timeframes, and the priority values and downtime costs for a component associated with each timeframe. Services View The BMC Impact Explorer user interface for viewing service-model components and their relationships and for viewing and managing the events that affect service availability.
Glossary
397
Set Priority The event operation action that escalates or de-escalates an event. Set Priority sets the events priority to the specified values and shows a Priority Set entry in the operation history. severity An indication of the seriousness of an event. severity-to-status mapping table One of the two tables that relate event severity and service component status. It is used by the cell to map the severity of an impact event to a status value to be used in the computation of the associated service component's status. See also status-to-severity mapping table. slot An field in a BAROC class definition. A class definition consists of one or more slots. Each slot has a data type and can have specific attributes, called facets, that can control the values that the slot can have or other aspects of a class instances processing. A subclass inherits all the slots of the parent class. See also attribute. slot facet See facet. SM See service model. SNMP adapter An adapter that listens at a port for SNMP traps. It evaluates the traps and formats them based on the configured event mapping. If the event-mapping conditions are satisfied, it sends the event to the cell. SNMP Adapter Configuration Manager A component of the BMC Impact Event Adapters that converts Management Information Base (MIB) data into BMC Impact Manager class data. Software Development Kit (SDK) A set of procedures and tools with which you can develop a type of application. source data The information that enters the BMC Impact Manager system from another entity and that will be transformed into an event in the system. source event The event that generates a related event. statbld.conf file The configuration file for the StateBuilder utility. It is in the $MCELL_HOME/etc/ directory on UNIX platforms and in the %MCELL_HOME%\etc\ directory on supported Windows platforms.
398
statbld.trace file The configuration file that specifies the trace information to be collected for the StateBuilder utility and where it should be written. It is in the $MCELL_HOME/etc/ directory on UNIX platforms and in the %MCELL_HOME%\etc\ directory on supported Windows platforms. state change event A generated event type that records changes in a components status. State change events never participate in component status computation. StateBuilder utility The utility, statbld.exe, that periodically consolidates the data in a cells transactions file (xact) and writes the saved state of the cell to the repository (mcdb). status 1. For events, an indication of the events management. Possible values are Open, Closed, Acknowledged, Assigned, and Blackout. 2. For service components, an indication of the relative availability of an IT resource. Possible values are OK, Unknown, Blackout, Information, Warning, Minor Impact, Impacted, and Unavailable. status-to-severity mapping table The status-to-severity map is used by the cell to map the main status of a component to the severity of a history event. status computation model A model that determines the status of a consumer service component when a change in the status of its provider service component occurs. status propagation The effect that a change in status of a provider component has on the status of its consumer components. STATUS_PROPAGATION table A dynamic data table that defines the different pairs of service component types whose instances can have a relationship and the status propagation model to be used for each relationship. store and forward A mechanism that ensures that if an event cannot reach its destination, it is saved in a file and sent when a viable connection to the destination becomes available. stored event An event that has been processed by the cell and stored in its event repository. Only stored events can be returned by queries and displayed in BMC Impact Explorer, returned by the mquery CLI command, or referenced by the Using and Update clauses of an MRL rule.
Glossary
399
superclass A hierarchically superior event or data class. A class that is derived from another class inherits part of its attributes (slots) from its superclass. suppression 1. The intentional exclusion of an event or a type of event. 2. The type of policy that governs event suppression. syslog adapter An adapter that collects information from the log file generated by the UNIX daemon syslogd. The syslog adapter reads syslogd events and formats and sends them to the cell.
T
Take Ownership The event operation action that assigns the current user as the events owner, sets the event status as Assigned, and shows an entry of Taken in the operation history. target The entity designated to receive events from an adapter, an event generator, or a BMC Impact Manager instance. Also, a cell whose content currently is displayed in a BMC Impact Explorer dialog box. test cell A cell, distinct from a production cell, in which to test an in-development service model. A test cell is either a BMC EM cell used to develop and test event management data, rules, policies, actions, and collectors, or a BMC SIM cell used to develop, test, and publish service models. test dataset A dataset that is used to relay objects from a sandbox View to a test cell. Each BMC Impact Service Model Editor user has a dedicated test dataset. A test dataset combines with a test cell to make a user test environment. The following example is a test dataset: BMC.IMPACT.Joe.TEST.1: the impact dataset containing instances that are effectively published to the impact manager of Joes Test environment threshold 1. In BMC Impact Manager, the point beyond which the value of a facet, slot, or other attribute can trigger an alert. 2. A type of policy. Threshold rule A rule that executes if the number of events exceeds the specified number within a particular timeframe.
400
TIME_FRAME class A BAROC class that is a child of the base data class TIME_FRAME and that defines a type of timeframe. TIME_ZONE class A BAROC class that is a child of the base data class TIME_ZONE and that defines a type of time zone. timeframe 1. User-defined blocks of time that can be added to a service schedule. Timeframes are added to the service schedule as During Schedule timeframes or Exceptions Within During Schedule timeframes. Any unassigned time is considered Off schedule. See also During Schedule, Exceptions Within During Schedule, and off-schedule time. 2. The specification for the period during which an event management policy instance is in effect. Timer phase The event-processing phase in which Timer rules for the delayed execution of another rule type are evaluated. This phase spans the New, Abstract, Correlate, and Execute phases of event processing. Timer rule An event-processing rule that triggers the delayed execution of another type of rule. Timer trigger See Timer rule. tree See navigation tree view.
U
unknown object An object whose status cannot be determined because of a connectivity failure. universal data identifier (mc_udid) A unique, system-generated value used to identify a specific service component instance. Each service component must have a value for the mc_udid attribute (slot). One use of the universal data identifier is in associating aliases to a service component instance. unpublished component A service component that is currently part of the service model but that has not been published (distributed) to BMC Impact Manager instances.
Glossary
401
user-defined policy A type of policy that a service manager or operations manager can define to perform specialized event processing; not available through any BMC Impact Explorer built-in policy. See also event management policy Using clause An MRL rule clause that is used primarily to retrieve data instances for a dynamic rule, but can also be used to retrieve instances of past events.
V
View In the Service Model editor, the centralized area where you begin to build and maintain a service model. Each View is unique to a user account. Multiple users can have different Views into the same service model. You can save Views for later reuse.
W
weighted function A calculation method that is used to determine impacts priority. When clause A part of MRL rule syntax for Abstract, Correlate, Execute, Propagate, and Timer rules. Events must first meet the selection criteria in the rule before the When clause is evaluated. Changes to slot values cause When clauses to be re-evaluated. wildcard A type of pattern matching that uses the asterisk character (*) to represent any number of different characters, and the question mark character (?) to represent a single unknown character. See also regular expression. workspace See View.
402
Index
A
access rights to service model objects 118 Access Server component type 48 active relationship defined 96 setting as 100 Activity component type 47 Activity Decision component type 47 Activity End component type 47 Activity Interaction component type 47 Activity Manual component type 47 Activity options 100 Activity Start component type 47 Add to Saved Finds button 90 Advanced Find tab 92 algorithm, quorum 174 alias entering in component instance 82 alias formulas conditional operators 106 creating 104 functions in 107 analyzing relevance of events 37 Application component type 48 Application Infrastructure component type 48 Application Service component type 51 Application System component type 48 applications, using with extended data models 202 AR System server using with extended data models 202 ARDBC plug-in 251 Atrium Publish environments parameters for 295 attributes generating fields for AR System 202 automated publishing 72, 333 AutomatedPublish configuration parameter 267 AutomatedPublishRetryPeriod configuration parameter 266, 267 described 66 exporting SIM class definitions from 290 BMC Impact Explorer monitoring service events 128 BMC Impact Portal monitoring service events 128 BMC Impact Publishing Server generating events for 218 starting service 212 BMC Impact Publishing Server CLI command summary 287288 common options for commands 281283 configuring 272281 configuring error tracing 281 error exit codes 285 error tracing, configuring 281 installing on another computer 270272 pclassinfo command 289 pcli.trace file 281, 284, 285 pinit command 301 plog command 304 plogdisplay command 306 pscontrol stop command 318 pserver command 320 publish command 322 BMC Impact Publishing Server service stopping with pcontrol stop CLI command 318 BMC Impact Solutions using new classes 202 BMC Software, contacting 2 BMC.ASSET data set 121 BMC.IMPACT.PROD data set 73, 121 BMC_Activity component class 47 BMC_Application component class 48 BMC_ApplicationInfrastructure component class 48 BMC_ApplicationService component class 51 BMC_ApplicationSystem component class 48 BMC_BaseElement BAROC definition 343 enumerations 349 slot definitions 346, 351 BMC_BusinessProcess component class 47 BMC_BusinessService component class 47 BMC_CDROMDrive component class 51 BMC_Cluster component class 48 BMC_ComputerSystem component class 48, 49, 50, 51
B
blackout status described 45 BMC Atrium Configuration Management Database
Index
403
BMC_ConnectivityCollection component class 47 BMC_DataBase component class 47 BMC_DataBaseStorage component class 52 BMC_DiskDrive component class 51 BMC_DiskPartition component class 52 BMC_FileSystem component class 52 BMC_FloppyDrive component class 51 BMC_HardwareSystemComponent component class 51 BMC_Impact data class 349 enumerations 352 BMC_IPConnectivitySubnet component class 47 BMC_IPXConnectivityNetwork component class 47 BMC_LAN component class 47 BMC_LNsCollection component class 47 BMC_LNsCollection component type 47 BMC_LocalFileSystem component class 52 BMC_LogicalSystemComponent component class 52 BMC_Mainframe component class 49 BMC_Media component class 51 BMC_Monitor component class 50 BMC_OperatingSystem component class 52 BMC_Organization component class 47 BMC_PROPOGATION_MAP defined 357 slots 357 BMC_RemoteFileSystem component class 52 BMC_SIM_ALIAS data class 359 BMC_Software component class 52 BMC_SoftwareServer component class 48, 49, 50, 51 BMC_STATUS_COMPUTATION data class 353 BMC_STATUS_PROPOGATION data class 355 BMC_SystemResource component class 52 BMC_SystemSoftware component class 52 BMC_TapeDrive component class 51 BMC_UPS component class 51 BMC_UserCommunity component class 47 BMC_VirtualSystem component class 51 BMC_VirtualSystemEnabler component class 52 BMC_VMWare component class 52 BMC_WAN component class 47 Business Process component type 47 Business Service component type 47 SIM, comparing SIM class definitions 292 unassigned 81 cell alias about 231 chart illustrating 233 Class Manager Console 203 classes IPS_CONFIG 223 IPS_ERROR 228 IPS_EVENT 221 CLI for BMC Impact Publishing Server 269274 close, action command for penv 294 Cluster component type 48 color setting active border 196 setting selected background 196 command options pclassinfo 289 pinit 293, 302, 308 plog 305 plogdisplay 306 pscontrol stop 318 pserver 320 publish 157, 321, 322 commands mposter 56 msend 56 pclassinfo 289 penv 292 penv, action commands 294 pinit 301 plog 304 plogdisplay 306 pposter 307 pscontrol stop 318 pserver 320 publish 322 common 285 Common Data Model (CDM) SIM-qualified classes of 66 Communication Server component type 48 comparing published to new 124 component classes BMC_Activity 47 BMC_Application 48 BMC_ApplicationInfrastructure 48 BMC_ApplicationService 51 BMC_ApplicationSystem 48 BMC_BMCComputerSystem 48, 49, 50, 51 BMC_BusinessProcess 47 BMC_BusinessService 47 BMC_CDROMDrive 51 BMC_Cluster 48 BMC_ComputerSystem 48, 49, 50, 51 BMC_ConnectivityCollection 47 BMC_DataBase 47
C
CD ROM Drive component type 51 cell add or change name 86 assigning related component instances to 101 determining topology 40 field 81 initializing with pinit command 303304 initializing with service model data 301 list of cell names 81 reinitializing 246
404
BMC_DataBaseStorage 52 BMC_DiskDrive 51 BMC_DiskPartition 52 BMC_FileSystem 52 BMC_FloppyDrive 51 BMC_HardwareSystemComponent 51 BMC_IPConnectivitySubnet 47 BMC_IPXConnectivityNetwork 47 BMC_LAN 47 BMC_LNsCollection 47 BMC_LocalFileSystem 52 BMC_LogicalSystemComponent 52 BMC_Mainframe 49 BMC_Media 51 BMC_Monitor 50 BMC_OperatingSystem 52 BMC_Organization 47 BMC_RemoteFileSystem 52 BMC_SoftwareServer 48, 49, 50, 51 BMC_Sofware 52 BMC_SystemResource 52 BMC_SystemSoftware 52 BMC_TapeDrive 51 BMC_UPS 51 BMC_UserCommunity 47 BMC_VirtualSystem 51 BMC_VirtualSystemEnabler 52 BMC_VMWare 52 BMC_WAN 47 component instances access to 118 assigning related to cells 101 associating with events 104 copying 87 creating 79 creating multiple copies 80 deleting 89 determining dependencies 35 editing 85 exporting 141 finding existing 89 hide 88 relationship state 55 setting icon colors and labels 196 viewing properties 84 component status computation model 46 computing 170 description of 45 component types 44 Access Server 48 Activity 47 Activity Decision 47 Activity End 47 Activity Interaction 47 Activity Manual 47 Activity Start 47 Application 48 Application Infrastructure 48 Application Service 51 Application System 48 BMC_LNsCollection 47 Business Process 47 Business Service 47 CD ROM Drive 51 Cluster 48 Communication Server 48 Computer System 48 Configuration Management Agent 48 Connectivity Collection 47 Database 47 Database Server 49 Database Storage 52 Disk Drive 51 Disk Partition 52 DNS Server 49 File Server 49 File System 52 Firewall 49 Floppy Drive 51 FTP Server 49 Gateway 49 Hardware System Component 51 Hub 49 Input/Output Device 49 IP Connectivity Network 47 IP Connectivity Subnet 47 JBOD 49 LAN Network 47 Layer 3 Switch 49 LDAP Server 49 Load Balancer 49 Local File System 52 Logical System Component 52 Mail Server 49 Mainframe 49 Media 51 Message Server 49 Mobile User Device 49 Monitor 50 Operating System 52 Organization 47 Print Server 50 RAID Storage Device 50 Remote File System 52 Resource Server 50 Router 50 SAN Bridge 50 SAN Director 50 SAN Hub 50 SAN Router 50 SAN Switch 50 Security Server 50 Server 50
Index
405
Software 52 Software Server 50 Storage 50 Switch 50 System Resource 52 System Software 52 Tape Drive 51 Tape Library 51 Telnet Server 51 Transaction Server 51 UDDI Server 51 Uninterruptible Power Supply (UPS) 51 User Community 47 Virtual System 51 Virtual System Enabler 52 VMware 52 WAN Network 47 Web Cache 51 Web Server 51 Computer System component type 48 computing status, of a component 170 Conditional Find tab 93 conditional operators in alias formulas 106 configuration activities for administrators associating custom icons with service model component classes 204 Configuration Management Agent component type 48 configuration parameters AutomatedPublish (publishing server) 267 AutomatedPublishRetryPeriod 266, 267 InitEffectivelyMgmtData 266, 267 configuring BMC Impact Publishing Server CLI 272281 error tracing, BMC Impact Publishing Server CLI 281 Connectivity Collection component type 47 Console Navigation Tree add a component to 131 adding a folder 128 copying a folder 130 dockable window 128 moving a folder 129 permissions for folders 130 refreshing 132 removing a folder 130 renaming a folder 129 copy component instances 87 set options for 198 creating alias formulas 104 component instances 78 multiple copies of component instances 80 relationships 97 custom icons, associating with service model component classes 204 customer support 3
D
data classes BMC_BaseElement, BAROC definition 343 BMC_Impact 349 BMC_PROPOGATION_MAP 357 BMC_SIM_ALIAS 359 BMC_STATUS_COMPUTATION 173, 353 BMC_STATUS_PROPOGATION 355 extending 44 file location 342 mapping 358 relationship 342 service model relationships 349 service model, overview of 342 SEVERITY_TO_STATUS 358 status related 342 Database component type 47 Database Server component type 49 Database Storage component type 52 datasets BMC.ASSET 122 BMC.IMPACT.PROD 122 defined 66 for Atrium Publish environments 234 date and time formats, setting 197 decreasing relationship policy 100 deleting component instance 89 event alias associations 108 relationships 103 Views 134 Direct Feed for service model data 24 Direct Publish environments parameters for 298 direct relationship policy 100 discovery tools 78 Disk Drive component type 51 Disk Partition component type 52 DNS Server component type 49 dockable windows Console Navigation Tree 128 Find 90 Pan and Zoom 137 repositioning 140 Template 80 undocking 140 documenting extensions 207 drawing relationships 97 dynamic prioritization final priority 192 impacts priority 191 overview 63 priority propagators 191 self priority 182
406
E
editing component instances 85 event alias associations 108 in model/not in model setting 86 multiple component instances 87 multiple objects 85 relationships 102 embedded Help options 198 error exit codes for BMC Impact Publishing Server CLI 285 error messages modifying 128, 216 event alias associations creating 104 deleting 108 editing 108 testing 120 event classes 364 history 366 impact 360, 361, 362, 367 events associating to component instances 104 generating publishing 218 missing, described 38 monitoring 128 examples pclassinfo 290292 penv 298 pinit 303304 plog 305 plogdisplay 306 publish 323 exits 165, 283 expansion handles in relationships 138 exploring paths in relationships 138 exporting component instances 141 SIM class definitions from BMC Atrium CMDB 290 extending Common Data Model BMC applications and 202 BMC Impact Solutions and 202 documenting 207
filtering the results 91 relationships 99 Find, Advanced 92 Find, Conditional 93 finding component instances 89 relationships 90 Firewall component type 49 Floppy Drive component type 51 FTP Server component type 49 functions in alias formulas 107 in status computation 170
G
Gateway component type 49 General tab 80 generating publishing events 218 Go to Component button 92 grab hand in View 136
H
Hardware System Component component type 51 hiding component instance 88 dockable windows or View window 79 history event class 366 home cell about 231 home cell alias about 231 Hub component type 49
I
icons custom, associating with user-defined classes in SME 204 identifying critical events 37 impact event class 360, 361, 362, 367 IMPACTED component status, described 45 import service model data 141 important component 191 in model, defined 73 inactive relationship, defined 96 increasing relationship policy 100 info, action command for penv 295 init, action command for penv 295 InitEffectivelyMgmtData configuration parameter 266, 267 initializing cells with pinit command 303304 Input/Output Device component type 49 installing
F
file location of data classes 342 File Server component type 49 File System component type 52 files pcli.trace 281, 284, 285 pclient.conf 271, 272 pserver.trace 281 pserver.trace (configure) 281 Find command configuring results pane 91
Index
407
BMC Impact Publishing Server CLI on another computer 270272 IP Connectivity Subnet component type 47 IPS_CONFIG class 223 IPS_ERROR class 228 IPS_EVENT class 221 IPX Connectivity Network component type 47 not in model defined 74 setting in component instance 81
O
OK component status, described 45 Open Saved Finds button 90 open, action command for penv 295 opening, Views 133 Operating System component type 52 Options command 196 Organization component type 47 output file for sim2cmdb CLI command 160 Output Preview option 88
J
JBOD (Just a Bunch Of Disks) component type 49
L
LAN Network component type 47 Layer 3 Switch component type 49 LDAP Server component type 49 line weight, for relationships 197 lines styles, for relationships 197 Load Balancer component type 49 Local File System component type 52 log files setting preferences for 199 log, publishing viewing with plog command 305 logging on BMC Impact Service Model Editor 77 Logical System Component component type 52
P
Pan and Zoom dockable window 137 parameters for Arium Publish environments 295 for Direct Publish environments 298 Paste Multiple Components dialog box 87 pclassinfo command 289?? examples 290292 options 289290 pcli.trace 281 pcli.trace file 281, 284, 285 pclient.conf file 271 configuring Impact Publishing Server CLI 272 location 272 penv command 292 pinit command 301?? examples 303304 options, required 302 syntax 302 plog command 304?? examples 305 syntax 304 plogdisplay command 306?? examples 306 options 306 return codes 307 syntax 306 pposter CLI command 307 Print Server component type 50 priority propagators 191 product support 3 promotion all instances 123 deleting instances 89 guidelines 122 overview 71
M
Mail Server component type 49 Mainframe component type 49 Match Attributes box for event alias association 105 mc_root_internal.baroc 350 mc_root_redef.baroc 364 MC_SM_COMPONENT data class, BAROC definition 344 mc_sm_event_ mapping.baroc 343 mc_sm_object.baroc 343 mc_sm_root.baroc 343 MC_SMC_EVENT data class BAROC definition 360, 361, 362, 367 Media component type 51 Message Server component type 49 MINOR IMPACT component status, described 45 missing events 38 Mobile User Device component type 49 Monitor component type 50 mposter command 56 msend command 56
N
non-impact relationships, showing 140
408
requirements before 122 status message 124 step-by-step instructions 123 submitting 122 verifying status 125 promotion of service model 121 provider relationship, described 53 pscontrol stop command 318 options 318 syntax 318 pserver command 320 options 320 syntax 320 pserver.conf file configuration parameters 242 pserver.trace file 281 publish command 322?? command options 157, 321, 322 examples 321, 323 syntax 322 Publish History command 126, 215 publishing automated 72, 333 changing recommended actions 127, 216 viewing history 126, 215 publishing large service models 331 publishing log viewing with plog command 305 selecting 98 showing non-impact 140 state 55 state values 55 status propagation models 55 testing 120 updating 102 Remote File System component type 52 renaming Views 134 repositioning objects in a View 135 Reset button in Find 92 Resource Server component type 50 return codes plogdisplay 307 Router component type 50
S
SAN Bridge component type 50 SAN Director component type 50 SAN Hub component type 50 SAN Router component type 50 SAN Switch component type 50 save a search statement 90 component instances 83 Views 133 Security Server component type 50 selecting multiple objects 86 relationships 98 Server component type 50 service components types 47 service model class hierarchy 341 composition 43 data classes, overview of 342 defined 20 description of 20 Direct Feed 24 internals of 341 objects, access to 118 promotion 121 publishing large 331 service model components computing status of 170 status colors, default 45 status computation 46 status values 45 service model relationships data classes 349 defined 53 ServiceModelSet class attribute, calculation of relationship values 241
Q
query builder in Find 94 quick expansion arrows 79
R
RAID Storage Device component type 50 refresh View 139 regional preferences, setting 197 reinitializing a cell 246 relationship legend 140 relationship policy, options defined 100 relationships active 96 creating 97 define line styles for 197 deleting 103 drawing 97 example View 101 expansion handles 138 exploring paths 138 finding 90 inactive 96 legend of types of 140 model illustration 20
Index
409
services starting BMC Impact Publishing Server 212 set, action command for penv 295 setting options 196 regional preferences 197 SEVERITY_TO_STATUS data class 358 showing topology views 140 sim2cmdb.conf file 153 SMC_STATE_CHANGE data class BAROC definition 366 Software component type 52 Software Server component type 50 source file for pposter CLI command 309 starting BMC Impact Publishing Server 212 state_change.baroc file 366 status list of default values for components 45 Status and Alias tab 81 status computation functions 174 model 46 model anatomy 174 of components 46 status propagation models for relationships 55 in BMC Impact Service Model Editor 178 STATUS_COMPUTATION data class, BAROC definition 353, 354 slots 353, 354 stopping BMC Impact Publishing Server service 318 Storage component type 50 support, customer 3 Switch component type 50 syntax pclassinfo 289, 292 pinit 302 plog 304 plogdisplay 306 pscontrol stop 318 pserver 320 publish 322 System Resource component type 52 System Software component type 52 trace configuration file BMC Impact Publishing Server CLI 281 Transaction Server component type 51
U
UDDI Server component type 51 UNAVAILABLE component status, described 45 undocking dockable windows 140 Uninterruptible Power Supply (UPS) component type 51 UNKNOWN status described 45 user accounts views 133 User Community component type 47 user groups default rights 118
V
verifying promotion status 125 Views adjusting focus in 136 and user accounts 133 deleting 134 grab and move objects in 136 opening 133 refreshing 139 rename 134 reposition objects in 135 saving 133 setting appearance options 198 visual cues in 134 zoom 136 Virtual System component type 51 Virtual System Enabler component type 52 visual cues in a View 134 VMware component type 52
W
WAN Network component type 47 WARNING status, described 45 Web Cache component type 51 Web Server component type 51 weighted cluster status model 46 wildcards using with Find command 90
T
Tape Drive component type 51 Tape Library component type 51 technical support 3 Telnet Server component type 51 topology views configuring 200 showing 140
Z
zoom in View 136
410
Notes
*89019* *89019* *89019* *89019*
*91098*

Service Model

Hochgeladen von

Dokumentinformationen

Copyright

Verfügbare Formate

Dieses Dokument teilen

Dokument teilen oder einbetten

Freigabeoptionen

Stufen Sie dieses Dokument als nützlich ein?

Sind diese Inhalte unangemessen?

Copyright:

Verfügbare Formate

Service Model

Hochgeladen von

Copyright:

Verfügbare Formate

BMC Impact Solutions: Service Model Administrators 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 Impact Solutions: Service Model Administrators Guide

Understanding a service model created in BMC Impact Service Model Editor 65 66 66 70 71 71 71 73 73 73 74 75

BMC Impact Solutions: Service Model Administrators Guide

BMC Impact Solutions: Service Model Administrators Guide

BMC Impact Solutions: Service Model Administrators Guide

BMC Impact Solutions: Service Model Administrators Guide

BMC Impact Solutions: Service Model Administrators Guide

Service model overview

Chapter 1 Service model overview

Service model overview

Service model overview

BMC Impact Solutions: Service Model Administrators Guide

Sources of objects in a service model

Sources of objects in a service model

Source for service model objects BMC Atrium CMDB

BAROC source file

MRL rule BMC Performance Manager

tool direct feed source direct feed

Chapter 1 Service model overview

Sources of objects in a service model

Object source BMC Atrium CMDB

BAROC file with pposter CLI command

BMC Impact Explorer

Direct Publish Feed

BMC Impact Solutions: Service Model Administrators Guide

Rules for service model data modification and deletion

Rules for service model data modification and deletion

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

BMC Impact Service Model Editor BMC Impact Publishing Server

Chapter 1 Service model overview

Using BMC Performance Manager

Using BMC Performance Manager

Using Direct Feed

BMC Impact Solutions: Service Model Administrators Guide

Data overrides other data with a lower precedence if

Chapter 1 Service model overview

BMC Impact Solutions: Service Model Administrators Guide

Designing a service model

Designing a service model

Service model design process

Service model design process

BMC Impact Solutions: Service Model Administrators 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 Impact Solutions: Service Model Administrators Guide

Decomposing a business service

Core competencies Plan and develop products

Sprint Sales Logix

Designing a service model

Defining the service catalog

Defining the service catalog