To specify a measurement of a monitor which will be taken into account for SLA calculations, these steps can be followed:

1. Go to the SLA definition.

2. Go to Define KPIs section.

3. Select the SiteScope Monitor CI associated to the metrics that should be measured and edit the KPI on the left panel.

4. Introduce the name of the measurement in the Measurement type field.

Example:

If SiteScope measurement is called status, the word status should be introduced.

5. Start the SLA if it is a new SLA or recalculate it if it is a new one.

Partition Manager runs every hour, 24 times a day. PM likes to sleep a lot, it wakes up every hour to do its job and goes back to sleep again (snooze mode).

It depends on what changes were made, if configuration changes were done, then a restart is a good idea so it can reload them. Each time Partition Manager starts, it needs to reload PM_CONFIG. If a restart is not done, the maximum waiting time is one hour.

The Extensibility guide describes how to validate the mapping rules using an XML schema.

The Extensibility guide explains the creation of a complete topo sync package using an example.

NOTE : This guide does not describe uCMDB basics and relies on quite some uCMDB know-how. (E.g. what are ci-types, what are the key attributes, etc.). The OMi Extensibility guide is the right place to describe these uCMDB basics.

Creating custom Content Pack requires uCMDB know-how, therefore it’s hard or even impossible to create a SyncPackage, if one doesn’t know what to map where.

It’s possible to map configuration item types to RTSM views using the RTSM Modeling Studio, so that views are available for selection and use in the Health Top View pane.

Comprehensive details about how to create new CI types, and how to work with the concepts of the RTSM, are described in the HP Business Service Management Modeling Guide.

This guide (Modeling.pdf) is part of the standard BSM documentation.

When configuring Business Availability Center (BAC) or Business Service Management (BSM), Gateway’s (GW) in a load Balancing mode, we need to configure a remote shared folder in the network to use it for Offline/Online data used by reports as recommended by the Deployment Guide.

Sometimes the user needs to run BSM Service as "Local System account" for security reason or when the shared folder belongs to a different domain then BAC/BSM machines.

Since BAC/BSM run as a service, it is possible to make the shared directory accessible when the Operating System (OS) starts by sharing the remote Folder and Grant to BAC/BSM host the full control privilege, by adding it with $ symbol at the end: "servername$" then give him full credential.

Edit Local Machine policy using the MMC console and add the user "NT Authority\System" as part of the users that may Logon as a service on the Local machine.

Try to connect to see if BSM has access to the directory after configuring apache as described in the Deployment Guide.

The above example is for "Local System account" but it’s the same for any different user.

Depending on the type of monitor being deployed and type of topology being sent, the errors in the bac_integration.log can be varied. Some examples of these errors are:

1. For a “Dynamic Disk Space” monitor sending its Default (Multiple) topology:

2012-10-10 20:52:21,995 [TopologyReporterSender] (TopologyReporterSender.java:393) ERROR – failed to run main topology agent. topologyCommand=TopologyCommand{commandType=RUN_SCRIPT, destinationData=<destination><destinationData name="class_type_id">1</destinationData><destinationData name="u_iConnectionId">1600736</destinationData><destinationData name="monitor_logical_name">Test_DDS_01</destinationData><destinationData name="measurements_to_eti_map" /><destinationData name="monitor_full_path">1600715</destinationData><destinationData name="is_report_default_hi">true</destinationData><destinationData name="logging_option">logAllData</destinationData><destinationData name="parent_group_name">Shrey_Test</destinationData><destinationData name="host_type">nt</destinationData><destinationData name="class_real_name">Dynamic Disk Space</destinationData><destinationData name="id">00000000000000000000000000000000</destinationData><destinationData name="domain_name">DefaultDomain</destinationData><destinationData name="monitor_description"></destinationData><destinationData name="monitor_properties">com.mercury.infra.xdr_utils.prop_bag_array@1602c39c</destinationData><destinationData name="file_system" />

…..

java.lang.Exception: Failed Running script :filesystem_topology.py

at com.hp.ucmdb.discovery.probe.services.dynamic.core.TopologyTablesProcessorUtil.processDestinationTables(TopologyTablesProcessorUtil.java:176)

at com.hp.ucmdb.discovery.probe.services.dynamic.core.TopologyDynamicService.process(TopologyDynamicService.java:37)

at com.hp.ucmdb.discovery.probe.agents.topology.MainTopologyAgent.run(MainTopologyAgent.java:487)

at com.mercury.sitescope.integrations.bac.topology.TopologyReporterSender.send(TopologyReporterSender.java:380)

at com.mercury.sitescope.integrations.bac.topology.TopologyReporterSender.run(TopologyReporterSender.java:330)

at java.lang.Thread.run(Thread.java:722)

Caused by: Traceback (innermost last):

File "<string>", line 2, in ?

File "filesystem_topology", line 26, in DiscoveryMain

AttributeError: module ‘system_lib’ has no attribute ‘createFileSystemFromMap’

at org.python.core.Py.AttributeError(Py.java)

at org.python.core.PyObject.__getattr__(PyObject.java)

2. For a “Script” monitor sending “Business Application” topology

2012-09-14 13:38:13,073 [TopologyReporterSender] (TopologyReporterSender.java:393) ERROR – failed to run main topology agent. topologyCommand=TopologyCommand{commandType=RUN_SCRIPT, destinationData=<destination><destinationData name="class_type_id">1</destinationData><destinationData name="u_iConnectionId">600568</destinationData><destinationData name="monitor_logical_name">prospero test script</destinationData><destinationData name="monitored_selected_ci_changed">true</destinationData><destinationData name="measurements_to_eti_map" /><destinationData name="monitor_full_path">600001.600012</destinationData><destinationData name="prev_organization_attr" /><destinationData name="is_report_default_hi">false</destinationData><destinationData name="logging_option">logOnlyThresholdsMeasuremnts</destinationData><destinationData name="parent_group_name">Test</destinationData><destinationData name="cur_key_attributes" /><destinationData name="host_type">unix</destinationData><destinationData name="class_real_name">Script</destinationData><destinationData name="id">00000000000000000000000000000000</destinationData><destinationData name="domain_name">DefaultDomain</destinationData><destinationData name="monitor_description"></destinationData><destinationData name="monitor_properties">com.mercury.infra.xdr_utils.prop_bag_array@1cc8130</destinationData>

…

java.lang.Exception: Failed Running script :user_defined_topology.py

at com.hp.ucmdb.discovery.probe.services.dynamic.core.TopologyTablesProcessorUtil.processDestinationTables(TopologyTablesProcessorUtil.java:176)

at com.hp.ucmdb.discovery.probe.services.dynamic.core.TopologyDynamicService.process(TopologyDynamicService.java:37)

at com.hp.ucmdb.discovery.probe.agents.topology.MainTopologyAgent.run(MainTopologyAgent.java:487)

at com.mercury.sitescope.integrations.bac.topology.TopologyReporterSender.send(TopologyReporterSender.java:380)

at com.mercury.sitescope.integrations.bac.topology.TopologyReporterSender.run(TopologyReporterSender.java:330)

at java.lang.Thread.run(Thread.java:722)

Caused by: Traceback (innermost last):

File "<string>", line 2, in ?

File "user_defined_topology", line 32, in DiscoveryMain

AttributeError: module ‘common_lib’ has no attribute ‘getProductName’

at org.python.core.Py.AttributeError(Py.java)

at org.python.core.PyObject.__getattr__(PyObject.java)

This is a known defect when integrating SiteScope 11.20 with BSM 9.1x. The problem is that, BSM 9.1x contains .py and .py.11 files in the sitescope.zip package used for the integration. SiteScope is supposed to use the .py.11 files for topology generation. However, it ends up using the older .py files instead. This leads to failures when generating topology.

Fix the sitescope.zip package to contain only .py.11 script files:

You can use the fixed sitescope.zip package attached here or you can generate the fixed zip package manually using the steps below:

a. From BSM UI > Admin > RTSM Administration > Administration > Package Manager, navigate to the sitescope.zip package

b. Right click > Export package > Save on your local server

c. Extract sitescope.zip and, from sitescope/discoveryScripts, remove all .py files. It should only contain .py.11 files.

d. Zip the file -> make sure you zip only the contents of the sitescope folder and not the sitescope folder itself. That is, the structure inside the zip file should NOT be sitescope.zip -> sitescope -> actual folders. It should be sitescope.zip -> actual folders. Retain the name sitescope.zip for the fixed zip package.

Deploy the fixed zip package via BSM UI > Admin > RTSM Administration > Administration > Package Manager. Click on Deploy packages to server (from local disk).

Confirm that new .py files are automatically downloaded into SiteScope’s discovery\scripts folder.

Confirm that no more script related exceptions occur in the bac_integration.log file

P.S. The original out-of-the-box sitescope.zip package will still be available for reference in the DPS server – <HPBSM>\odb\conf\factory_packages\sitescope.zip