396 Tivoli Business Systems Manager Version 2.1: End-to-End Business Impact Management
12.1 Automatic Business System View
The Business System View (BSV) creation performed by dragging and dropping
resources from the All Resources View hierarchy into the Business System
hierarchy works well for only a small number of resources. When the resources
to be inserted are in the order of hundreds, the drag-and-drop method becomes
time-consuming and error-prone.
This section discusses IBM Tivoli Business Systems Manager’s new feature,
Automatic Business System, that enables the automatic creation of Business
System Views.
12.1.1 Automatic Business Systems design
The Automatic Business System (ABS) enables the creation of a BSV without
using the drag-and-drop method from the console. Instead, a BSV is created
automatically based on a set of criteria defined in the configuration file. This
configuration file is discussed in 12.1.2, “Automatic Business Systems
configuration file” on page 397.
The process is configured using a command line utility from IBM Tivoli Business
Systems Manager database server. Eeveral tasks in SQL Server Agent must be
enabled and scheduled regularly to facilitate the ABS process.
The ABS processing schematic is shown in Figure 12-1.
Figure 12-1 ABS processing
absConfig.ksh
ABS Creation ProcessABS Discovery Process
Config file
Update ObjPathCache
alobListPattern
alobListCriteriaAlob
dynamic_object_create_path_detail
dynamic_object_create_path
evQueueObject
Object creation or update triggers
tI_EV<cid>_C
tU_EV<cid>_C
tU_EV<cid>_A
ObjPathCache
alobQueueCreateLOB
ev_auto_create_object_parm
ABS Table Purge
Chapter 12. Automatic Business System View creation 397
The command absConfig.ksh configures the Automatic Business System View
creation. It takes as input the configuration file and loads the necessary entries in
the database for all the ABS configuration criteria.
These configuration values are stored in these tables:
alobListPattern List of the pattern-matching attributes
alobListCriteriaAlob List of the criteria for a BSV creation
dynamic_object_create_path_detail Correlation between BSV path and the
criteria
dynamic_object_create_path List of paths needed to create the BSV
When the configuration is completed, the database starts to monitor the system
for creation or update of resources. Whenever a new resource is inserted or an
attribute of the monitored resources changes, the following takes place:
1. A trigger captures the modification, and the new or changed attribute data is
queued in the table evQueueObject.
2. The UpdateObjPathCache job running as scheduled (15 minutes by default)
updates the resource relationships in the table ObjPathCache.
3. The ABS Discovery Process job, scheduled every minute, checks the
evQueueObject table and, if the criteria provided in the last configuration file
have been met, populates the tables alobQueueCreateLob and
ev_auto_create_object_param with the new data. This job process only the
events with a ctime lower than or equal to the start time of the last successful
completion of the UpdatePathCache job. Events created after this time will be
queued until the next successful running of the UpdateObjPathCache job.
4. The ABS Creation Process job, scheduled every minute, processes the data
stored in the tables populated by the ABS Discovery Process job and creates
or updates the BSV.
5. The ABS Table Purge job, scheduled to run occasionally, removes data older
than 30 days from the tables used by the automated BSV processing system.
12.1.2 Automatic Business Systems configuration file
The ABS configuration file contains the information used by the ABS discovery
process to determine whether to modify the BSV structure for the created or
updated object. The information identifies all the resources that are eligible to
Attention: Loading a new configuration file completely replaces the old
configuration, but it keeps the existing Business System Views. These BSVs
may not be current and you may want to recreate all the BSVs.
398 Tivoli Business Systems Manager Version 2.1: End-to-End Business Impact Management
become part of Business System Views. The uniqueness of the configuration file
permits a fast inspection, modification, or reuse of the data.
The configuration file consists of five sections:
PatternList The list of all the operands that can satisfy the pattern.
Pattern The list of all the patterns with their attributes and the
logical conditions or operations that the attributes must
satisfy
CriteriaToPattern The list of the criteria used for the patterns and the
relationship between patterns within the same criteria
Path The list of all the BSVs that could be created and their
hierarchical order
CriteriaToPath The list of all BSVs that should be created when the
particular criteria is met
Every section is structured in table format with two or more columns. Each
section header line is followed by a field header line. As an illustration, we show a
very simple configuration file for a BSV with DB2 subsystem (D2SS) and IMS
subsystem (IMSS) resources in Example 12-1.
Example 12-1 Sample configuration file
PatternList
ListName Operand
PL_1 DB%
PL_1 D2%
Pattern
Pattern Class Attribute When Operator Operand1 Operand2
1 D2SS name Current LIKE LIST PL_1 %
2 IMSS name Current LIKE IMS% %
3 IMSS Path Current LIKE %SC66% %
CriteriaToPattern
Criteria Pattern PatternRelated
1001 1 1
1002 2 2
1002 3 2
Path
Path Level Name
PP_0_0 1 Remote Banking
PP_0_0 2
PP_0_1 1 Remote Banking
PP_0_1 2
Chapter 12. Automatic Business System View creation 399
CriteriaToPath
Criteria Path Level Pattern Variable Value
1001 PP_0_0 2 1 name <1:name>
1002 PP_0_1 2 3 name <3:name>
To interpret this configuration file, we start with the Path definition. Assign a name
for each path definition, its level, and its name. Use a different path name for
each type of object that you want to put in the same place. This sample puts DB2
subsystem and IMS subsystem objects under a BSV folder Remote Banking.
The columns for the Path section are:
Path A string representing the BSV that will be created but is
not seen outside the database.
Level The number of levels from the Business System
Container.
Name The name of the static business system folder. This does
not represent a physical object. Leave this field blank if
this level in the Path represents a dynamically created
object.
As we know that we want to put the DB2 subsystem and IMS subsystem under
Remote Banking, we have to associate each of them to a criteria. Typically for a
criteria, we use a large number. We assign them 1001 for DB2 subsystem
objects and 1002 for IMS subsystem objects.
For each criteria, we define a pattern or patterns that can be applied to an object
to test whether it matches the criteria. These patterns are defined in the Pattern
section and some information is located in the Pattern List section.
Let’s evaluate what we want to do:
? For the DB2 subsystem (cid = D2SS), we want all DB2 subsystems that
match either DB* or D2*. The first line in Example 12-1 on page 398 for
Pattern section reads:
1 D2SS name Current LIKE LIST PL_1 %
It defines a pattern for object D2SS (DB2 subsystem) that can match to
several patterns (or conditions). These pattern lists are defined in the Pattern
List section. PL_1 is the pattern list identifier that contains a match to DB%
and D2%. (As this uses SQL, % is a wildcard.)
? The IMS subsystem that we want is different, as its name begins with IMS*
and it must be located under the SC66 operating system. Therefore it must
match two patterns as shown in Example 12-1 on page 398:
2 IMSS name Current LIKE IMS% %
3 IMSS Path Current LIKE %SC66% %
400 Tivoli Business Systems Manager Version 2.1: End-to-End Business Impact Management
Pattern 2 identifies that the name field must start with IMS, and pattern 3
designates that the path must contain SC66.
PatternList definitions are:
ListName Provides the name for a pattern list. The name matches
the Operand1 column in the Pattern section when the
operator used is a LIKE LIST or a NOT LIKE LIST.
Operand A valid SQL pattern.
Pattern definitions are:
Pattern A unique integer identifier used in the CriteriaToPattern
section to identify the pattern for each criteria.
Class The four-letter code representing the internal IBM Tivoli
Business Systems Manager class name on which the
pattern test will be attempted.
Attribute The attribute of the Class that identifies the aspect of the
object class on which the pattern test will be performed.
When The version of the attribute value on which the test will be
performed. Can be current or previous.
Operator The operator type used to test the pattern. These are the
operands:
LIKE, NOT LIKE,=,<>,>,<,>=,<=,LIKE LIST, and NOT
LIKE LIST use only operand1.
BETWEEN, NOT BETWEEN, and EGREP use both the
operand1 and operand2.
Operand1 The first argument for the operator. For BETWEEN and
NOT BETWEEN, it is the first or lower argument in the
range. For IS, it is either NULL or NOT NULL. For LIKE
LIST and NOT LIKE LIST, it is the ListName in the
PatternList section. For EGREP, it is the first argument.
Operand2 The second argument for the operator, used for
BETWEEN, NOT BETWEEN, and EGREP. All other
operators should use a “%” character as a placeholder.
Now we can match the patterns with the criteria that we defined in the
CriteriaToPattern section. Pattern 1 is associated with criteria 1001 and patterns
2 and 3 are associated with criteria 1002. Definitions for CriteriaToPattern are:
Criteria A unique integer that identifies a group of patterns that
should be evaluated together.
..................Content has been hidden....................
You can't read the all page of ebook, please click here login for view all page.