Posts Tagged ‘CDM’

TBSM multiple event identifiers

Friday, August 14th, 2015

This blog entry will explain on how to set up and use multiple event identifiers in IBM Tivoli Business Service Manager 6.1.1 FP3 and previous releases.



The official documentation doesn’t say much about multiple event identifiers.


So let’s do a quick summary of what we can:
– we can set multiple event identifiers in incoming status rule
– we can set multiple event identifiers in EventIdentifiersRules.xml or any artifact of category eventidentifiers in XMLtoolkit


But how to make sure they would match and do know they do match?



Multiple event identifiers in Incoming status rules are logically associated like there was logical AND operator between them:



















So this definition of CAM_FailedRequestsStatusRule_TDW rule should be understood: all rows returned by CAM_RRT_SubTrans_DataFetcher will affect my service if data returned in the following fields has the following values:



Same time, if I have multiple values for same label, it means OR.
For incoming status rule like:

































So my instance expects that CAM_BSM_Identity_OMNI rule can catch all events with two alternative BSM_Identity values:

– MyApp#t#MyTrans#s#MySubTrans OR
– MySubTrans(5D21DD108FD43941892543AA0872D0EA)-cdm:process.Activity


If we’re looking at EventIdentifierRules.xml, there’s a concept of policies and rules, for example:

<Policy name=”ITM6.x”>
<Rule name=”ManagedSystemName”>
<Token keyword=”ATTR” value=”cdm:ManagedSystemName”/>
<Mapping policy=”ITM6.x” class=”%” />

You can have many policies mapped on many classes (which can be mapped on many templates) and you can have many rules within every policy.


In our case, for ITCAM Tx subtransactions class we have one policy with many rules:

                         <Policy name=”CAM_SubTransaction_Activity”>
<Rule name=”CAM_GetBSM_Identity”>
<Token keyword=”ATTR” value=”cdm:ActivityName” />
<condition operator=’like’ value=’%#s#%’ />
<Rule name=”CAM_GetApplicationName” field=”APPLICATION”>
<Relationship relationship=’cdm:uses’
<Relationship relationship=’cdm:federates’
<Token keyword=”ATTR” value=”cdm:ActivityName” />
<Rule name=”CAM_GetTransactionName” field=”TRANSACTIONS”>
<Relationship relationship=’cdm:uses’
<Token keyword=”ATTR” value=”cdm:Label” />
<Rule name=”CAM_GetSubTransactionName” field=”SUBTRANSACTION”>
<Token keyword=”ATTR” value=”cdm:Label” />
<condition operator=’like’ value=’%#s#%’ />


and one mapping of that policy on a class:
<Mapping policy=”CAM_SubTransaction_Activity” class=”cdm:process.Activity” />


But one class has many policies mapped on them:
<Mapping policy=”CAM_Transaction_Activity” class=”cdm:process.Activity” />
<Mapping policy=”CAM_SubTransaction_Activity” class=”cdm:process.Activity” />
<Mapping policy=”CAM_TT_Object” class=”%” />


Means, every mapping of a policy on a class is like element of logical OR operation. And every rule is a logical element of logical AND operation with other rules within same policy.

It is all conditional, because here comes additional aspect of field parameter of <Rule> tag.


The field parameter.

The field parameter in rule in policy in EventIdentifier enables that rule will be used only in case of having such field with such a name also in Incoming status rule specified as service instance name field.


So there’s no AND operator between those rules in policy in EventIdentifierRules.xml which haven’t been specified in Incoming Status Rule in template.


On another hand, there won’t be any value assigned to service instance name fields selected in Incoming Status Rule in Template A if corresponding fields haven’t been configured in rules of policies mapped on class (mapped on Template A in CDM_TO_TBSM4x_MAP_Templates.xml) in EventIdentifierRules.xml/



You need two places to go to and configure your event identifiers:
Templates and incoming status rules / numerical rules / text rules – Service Instance Name Fields

  1. XMLtoolkit artifact EventIdentifierRules.xml (or any custom artifact from category eventidentifiers) – field parameters in rules defined within policies

Additionally, don’t forget: your policies defined in eventidentifiers artifacts must be mapped on CDM or custom classes that have mapping definition stored in CDM_TO_TBSM4x_MAP_Templates.xml and map on the same template that has the incoming status rule (numerical/text rule) you want with the Service Instance Name fields you want.

Otherwise your events or KPIs fetcher in fetchers won’t affect your service tree elements and you will not be showing correct status or availability on dashboards and your outage reports will also miss data and will generate false monthly results!

Drop me a note if you experience any troubles reading this article or trying to apply what’s written here, thanks!


Business Service Composer – pain in the… artifact?

Friday, March 22nd, 2013

I’ve been starting actively using Business Service Composer for creating my service trees in TBSM It’s really powerful tool, that helps you doing a lot of things with service structure, regardless component CDM classes (or any classes in any namespace, regardless their origin), however with one big glitch – it’s a huge step back in single administration console approach by deselecting TIP to be portal of choice in Tivoli and using Java GUI instead. There are two conveniences:

– If you really want to enjoy BSC GUI – don’t use it via ssh tunnel from within your Putty session to TBSM server (MS Windows users). Loosing focus on buttons or just selected menu items is so frequent that more times it doesn’t work and confuses than it works ok. It’s a nightmare, let’s put it straight. Just run it on your local workstation instead, it will save you a lot of nerves and time.

– But – once you run it on your desktop, you’ll have to come over the pain of updating project files via SCP (Windows users) there and back again in order to upload any single change to your static resources or policies.

It would probably be better if you run it all mounted locally from a remote site, where projects directory remains already in the right place for xmltoolkit script to pick it up and load it to artifacts without all that copy nightmare.

This is it. Powerful, conditionally usable, still some way from a nice tooling. And has nothing to do with TBSM Service Editor. Confusing? We have application descriptors and templates to model a dependency of CIs to applications first, then we have some functions of TADDM GUI, then we have BSC and at the end we have TBSM Service Editor. Confusing? It all works and has special use, but I’d have piece of a better advice for development. And I promise to share it.