In the following examples, relationship keywords are indicated in bold type.

Here is a ServiceSubscriber example:

ServiceSubscriber subscriber1 subscriptions service1 service2 
   BusinessProcess::bProcess1

This business service definition results in the creation of the ServiceSubscriber element subscriber1 and the ServiceOffering elements service1 and service2. The bProcess1 element will also be created as an instance of the class, BusinessProcess. The ServiceOffering class is not specified because the subscriptions keyword implies that these elements are instantiated from the ServiceOffering class.

The ServiceOffering example that follows uses similar logic:

ServiceOffering service1 subscribers subscriber1 subscriber2 Customer::customer1

This business service definition results in the creation of the ServiceOffering element service1 and the ServiceSubscriber elements subscriber1 and subscriber2. The customer1 element will also be created as an instance of the class, Customer. The ServiceSubscriber class is not specified because the subscribers keyword implies that these elements are instantiated from the ServiceSubscriber class.

When the relationship keyword is serves or servedby, the value of <class> is BusinessProcess, and the implied class for <related_instance> is also BusinessProcess:

BusinessProcess bProcess1 serves bProcess2 BusinessProcess::bProcess3
BusinessProcess bProcess1 servedby bProcess4

Here are some more Subscriber Type examples:

Organization organization1 subscriptions service1 BusinessProcess::bProcess1
BusinessUnit business_unit1 subscriptions service1 BusinessProcess::bProcess1
LOB lob subscriptions ServiceOffering::service1 BusinessProcess::bProcess1
Department department subscriptions service1 BusinessProcess::bProcess1
Customer customer subscriptions service1 service2 BusinessProcess::bProcess1

Additionally, Subscriber Type elements can be a part of or composed of other Subscriber Type elements. The syntax is:

Organization organization1 composedof BusinessUnit::business_unit1 
   Department::department1
LOB lob1 partof business_unit1 BusinessUnit::business_unit2

After a BusinessProcess instance is specified in the service.data.template file, it can be specified as a member of a ServiceOffering or HierarchicalGroup that is also defined in the service.data.template file:

ServiceOffering service1 members BusinessProcess::bProcess1 Host::H1
HierarchicalGroup group1 members BusinessProcess::bProcess1 Router::R1

A BusinessProcess may consist of SoftwareService elements or other logical elements that already exist in the topology:

BusinessProcess bProcess1 members SoftwareService::A1 SoftwareService::A2

For a complete example, the Organization, BusinessProcess, DatabaseServer, and SoftwareService elements and their relationships shown in the Business Services map are defined as follows:

BusinessProcess CRM servedby BusinessProcess::Accounting
BusinessProcess Accounting servedby BusinessProcess::Fulfillment
BusinessProcess Fulfillment servedby BusinessProcess::OrderManagement
BusinessProcess OrderManagement servedby BusinessProcess::DemandPlanning
Organization Acme subscriptions BusinessProcess::OrderManagement
BusinessProcess OrderManagement members SoftwareService::SAP
BusinessProcess Fulfillment members SoftwareService::FedExFulfillment
BusinessProcess Accounting members SoftwareService::OracleFinancials 
   DatabaseServer::SQLFinancialRepository
BusinessProcess CRM members SoftwareService::Siebel 
   DatabaseServer::SQLServerRepository

When dealing with large numbers of members in a ServiceOffering, it may become more practical to use HierarchicalGroups to represent a group of network elements. Groups may be defined in the service.data.template file along with the ServiceOfferings. The Service Assurance Manager Configuration Guide contains additional information on defining and importing HierarchicalGroups.