Service template model: Example 1

This topic describes an example template model, templates with incoming status rules, and templates with aggregation rules.

You can create dependencies for each service type. Figure 1 shows a simple service template model example that explains how template dependencies work. This model contains a hierarchy of service templates where the highest level service template depends on the status of the subservices below it. In this case, the status of the services is based on ObjectServer events.

Figure 1. Simple service model example 1

Table 1 describes the dependencies for the example service model in Figure 1.

Table 1. Service model dependencies (1 of 2)
Template	Service instances	Dependent rules	Incoming status rules
`WebApp`	`customer1`	Status of `Webserver` services.	None.
`WebServer`	`webserver1` `webserver2` `webserver3`	Status of `Database` services.	Netcool/OMNIbus events as defined in `WebServer` template.
`Database`	`database1` `database2`	Status of `DNSServer` services. Status of `AuthServer` services.	Netcool/OMNIbus events as defined in `Database` template.
`DNSService`	`dnsserver1`	None.	Netcool/OMNIbus events as defined in `DNSService` template.
`AuthServer`	`authserver1`	None.	Netcool/OMNIbus events as defined in the `AuthServer` template.

Templates with Incoming Status rules

The service templates in Figure 1 within the dotted line rectangle include rules that evaluate events from Netcool/OMNIbus. The dependencies for these templates are based on the incoming events. These dependencies are called incoming status rules. For example, the templates for the DNS and the authentication servers evaluate service-related events from Netcool/OMNIbus. The status of these two servers affects the status of the two databases and the three web servers because they require these two servers to function properly. Accordingly, you could add both incoming and aggregation rules to the Database and WebServer templates.

Templates with Aggregation rules

The status of the database servers affects the status of the web servers. The status of all these servers, in turn, affects the status of service instances tagged with the WebApp service template. The status of services tagged with the WebApp template are based on the status of the services tagged with the other templates in the service model, such as Database and AuthServer. WebApp does not depend on the incoming events directly. These dependencies are defined with aggregation rules within the template. These rules aggregate the status of multiple child services to determine the status of the parent service.

You need to model these types of dependencies for your network in the TBSM console to monitor the service status in the Service Editor.