There is a link between C-D and C-E.There is an alert say "Wire failure" which if it comes on component D must affect component C of service A and if it comes on component E must affect component C of service B.Identical templates and services are used for component C of services A and B for now.Is this scenario possible to be implemented in TBSM or is it that if the alert comes on either of D or E that component C of both service A and B will be affected....?Please help me out with this..if there is any possible solution.

Attachments

Re: Complex rule/functionality required from TBSM

‏2013-05-14T17:02:34Z

This is the accepted answer.
This is the accepted answer.

Hi,

I think there are a couple of key questions I must first ask to understand the scenario. Will there be a single service instance with a display name of C, or will there be 2 service instances (unique names required), each having display name C? If there is only a single instance displayed in more than one branch of your tree, then the single status would always be shown everywhere C is shown in the tree. So I think you will need multiple instances of C in order to show a different status.

When you say there is a dependency for C on D, I would expect the tree to be 3 levels, like A -> C -> D and B -> C -> E. Sorry if I have misunderstood how you want to set this up. With a 3 level tree, and 2 instances of C, I believe you can have the desired behavior. D and E would need different templates, each with a rule for handling the alert that changes its status. The 2 instances of C can have the same template, but there would be 2 good, bad, marginal aggregation rules, one specific to each "child template" -- that is the templates associated with D and E respectively.

Not sure I have quite the answer you want, but I think the key statement is that with a single instance of any service you will always see the same status, no matter the context defined by the parent service of that service.

Re: Complex rule/functionality required from TBSM

I think there are a couple of key questions I must first ask to understand the scenario. Will there be a single service instance with a display name of C, or will there be 2 service instances (unique names required), each having display name C? If there is only a single instance displayed in more than one branch of your tree, then the single status would always be shown everywhere C is shown in the tree. So I think you will need multiple instances of C in order to show a different status.

When you say there is a dependency for C on D, I would expect the tree to be 3 levels, like A -> C -> D and B -> C -> E. Sorry if I have misunderstood how you want to set this up. With a 3 level tree, and 2 instances of C, I believe you can have the desired behavior. D and E would need different templates, each with a rule for handling the alert that changes its status. The 2 instances of C can have the same template, but there would be 2 good, bad, marginal aggregation rules, one specific to each "child template" -- that is the templates associated with D and E respectively.

Not sure I have quite the answer you want, but I think the key statement is that with a single instance of any service you will always see the same status, no matter the context defined by the parent service of that service.

Hi Randy,
Thanks for the quick reply but you have got some details wrong.The template used for instance D and E is the same.The relationship is A->C,A->D and B->C,B->D.There are 4 templates in total -Template1(used for A),Template2(used for B),Template3(used for C),Template4(used for D,E).The instances C,D,E have their own individual behavior in addition to this one alert "Wire failure" that has dependency.So if this alert comes on D it has to affect C of Service A and if it comes on E it has to affect C of Service B.The instance C used is the same in both services A as well as B.In this case there is only one instance and multiple instance with same display name may be possible but if there are thousands of such instances,doing this will be cumbersome.Can you suggest any solution for this...?

Re: Complex rule/functionality required from TBSM

Hi Randy,
Thanks for the quick reply but you have got some details wrong.The template used for instance D and E is the same.The relationship is A->C,A->D and B->C,B->D.There are 4 templates in total -Template1(used for A),Template2(used for B),Template3(used for C),Template4(used for D,E).The instances C,D,E have their own individual behavior in addition to this one alert "Wire failure" that has dependency.So if this alert comes on D it has to affect C of Service A and if it comes on E it has to affect C of Service B.The instance C used is the same in both services A as well as B.In this case there is only one instance and multiple instance with same display name may be possible but if there are thousands of such instances,doing this will be cumbersome.Can you suggest any solution for this...?

TBSM does not support a solution where there is only one instance of C that will have different attributes depending on the parent service. TBSM will have this single instance of C in memory and thus attributes like "overall status" will be reflected on the service C no matter where it is displayed in the service hierarchy.

The other question would be how to make alerts for D and E affect a peer service C when there is no dependency between C and D,E. This rules out the standard TBSM propagation/aggregation rules and I suspect this would require custom policy code in a rule or output expression. I will forward this question to another developer who may have additional input.

Re: Complex rule/functionality required from TBSM

TBSM does not support a solution where there is only one instance of C that will have different attributes depending on the parent service. TBSM will have this single instance of C in memory and thus attributes like "overall status" will be reflected on the service C no matter where it is displayed in the service hierarchy.

The other question would be how to make alerts for D and E affect a peer service C when there is no dependency between C and D,E. This rules out the standard TBSM propagation/aggregation rules and I suspect this would require custom policy code in a rule or output expression. I will forward this question to another developer who may have additional input.

There is a link between C-D and C-E.So if this link breaks between C-D an alert will come on D and similarly if this link breaks between C-E an alert will come on E,this is the reason that I wanted to show particular C instance as affected.

Re: Complex rule/functionality required from TBSM

‏2013-05-16T12:34:57Z

This is the accepted answer.
This is the accepted answer.

Hi,

If you want to use the same instance for C in each of the 2 hierarchies, you might be able to do what you want by having a rule in C's template that depends on D and a separate rule in C's template that depends on E. Since D and E belong to the same template (Template4) you'd need to have 2 rules in Template4- where one rule (RuleD) gets affected by D's event and the other rule (RuleE) gets affected by E's event. Then back up in C's template, you could have one rule (RuleCD) that depends on RuleD in Template4 and another rule (RuleCE) that depends on RuleE of Template4. Then you could have A's template depend on RuleCD and B's template depend on RuleDE and the status would propagate as you want.

If you have a single rule in Template4 for events for both D and E then you could probably configure policy rules in C's template to propagate depending on the particular instance of Template4 that is affected, but that would be more complicated.