anchor.diff:  // Allow GitHub image rendering
   :imagesdir: ../../../images
   
  -OpenNMS provides very powerful and fine grained service assurance layer based on the PollerDaemon.
  +OpenNMS provides a very powerful and fine grained service assurance layer based on the PollerDaemon.
   The service assurance layer monitors and tracks the status of nodes, interfaces and services.
  -Events, alarms and outages are used to track and document the status of the managed elements.
  +Events, alarms and outages are used to track and describe the status of the managed elements.
   The status of a managed element can be determined based on events, alarms and outages.
   This approach treats every element of the system individually.
  -There is no concept of relations between different nodes or relations between services.
  -
  -The Business Service Monitoring feature adds the ability to model relations between managed elements.
  -It composes many managed elements into a hierarchically structured Business Service.
  -A Business Services represents the status of all its managed elements.
  -They provide a high level view of a composed service based on several managed elements.
  -The Business Service Monitoring feature does not affect the service assurance layer at all.
  +There is no concept of relations between different nodes or relations between services in the service assurance layer.
  +
  +The business service monitoring (bsm) feature adds the ability to model relations between managed elements.
  +It composes many managed elements into hierarchically structured business services.
  +A business service represents an high level status view of all its managed elements.
  +Business services provide a high level view on several managed elements.
  +The business service monitoring feature does not affect the service assurance layer at all.
   The alarm status of the managed elements is provided by the service assurance layer.
  -Business Services determine the status of the contained managed elements based on the alarm status provided by the service assurance layer.
  -The alarm status of the contained managed elements is correlated by the Business Service into its own operational-status.
  -The operational-status of a Business Service can be checked at any time.
  -If the operational-status of a Business Service is changing corresponding events are fired.
  -
  -////
  -TODO check for useful parts and work them into the introduction.
  -=== Business Service general use
  -A Business Service represents a high level view on a specific service.
  -This service is build up by many components of the IT-Infrastructure.
  -The operational-status of a Business Services depends on the individual status of all its components.
  -
  -Business Services are modeled on top of monitored IT-Infrastructure.
  -The service assurance it self is not affected by the Business Service.
  -To use Business Services the monitoring of the components has to be good to have a good Business Service representation.
  -The status of the components of a Business Service is determined by the OpenNMS core service assurance features.
  -The OpenNMS _Alarm_ concept is used to represent the status of the components.
  -Based on the _Alarms_ of its components the status of the Business Service is calculated.
  -////
  -
  -////
  -TODO check for useful parts and work them into the introduction
  -The Business Service Monitoring feature adds the ability to model logical structures on top of the existing monitoring.
  -Business Services correlate the status of managed elements into a higher level view.
  -Business Services can be composed by multiple monitored services or other Business Services.
  -////
  +Business services determine the status of the contained managed elements based on the alarm status provided by the service assurance layer.
  +The alarm status of the contained managed elements is correlated by the business service into its own operational status.
  +The operational status of a business service can be checked at any time.
  +If the operational status of a business service is changing corresponding events are fired.
   
   
   ==== The structure of a Business Service
  -Business Services can contain attributes, reductionkeys, references to monitored-services and other Business Services.
  -
  -
  -===== Reductionkeys as part of a Business Service
  -Business Services are built to correlate the alarm based status of managed elements into its operational-status.
  +Business Services can contain attributes, reductionkeys, references to monitored-services and other business services.
  +
  +
  +===== Reductionkeys as part of a business service
  +Business services are built to correlate the alarm based status of managed elements into its operational status.
   Business Services can contain a list of reductionkeys that are used to identify the relevant alarms to correlate.
  -Reductionkeys can be added to Business Services as plain text.
  -
  -
  -====== Monitored Services / IP-Services as part of a Business Service
  -Business Services can contain references to Monitored-Services (Node/Interface/Service combination).
  -A referenced Monitored-Service is called IP-Service in the Business Service.
  -IP-Serivces of a Business Service are interpreted as two reductionkeys:
  +Reductionkeys can be added to business services as plain text.
  +
  +
  +====== Monitored services / Ip-services as part of a business service
  +Business services can contain references to monitored-services (node/interface/service combination).
  +A referenced monitored-service is called Ip-service in the business service.
  +Ip-serivces in a business service are interpreted as two reductionkeys:
   
   * `uei.opennms.org/nodes/nodeLostService::%nodeID%:%ipAddress%:%serviceName%`
   -- This reductionkey matches the alarms fired if the monitored-service goes down.
  
positive.code: This kind of _PUT Request_ can be used to change the Business Service in general.
  The `business-service-id` used in the `url` has to match the `business-service-id` used in the body of the request.
  
  TIP: The list of Monitored-Services including ids can be queried via the Rest-API form `opennms/rest/ifservices`
  
  ===== Check operational-state
  `GET opennms/api/v2/business-services/$business-service-id/operational-status`
  This call provides the _operational-status_ of the business service.
  The result is on of the OpenNMS _severities_ in text representation.
  //TODO can Cleared or Indeterminate happen?
  (Critical, Major, Minor, Warning, Normal, Cleared, Indeterminate)
  
  ==== Business Service based on _Monitored Services_
  The most basic way to use a Business Service is to assign multiple Monitored-Services to it.
  The alarm based status of the Monitored-Services is then the basis of the Business Services status.
  The status of the Business Service then depends on the highest _severity_ of the _Alarms_.
  
  ==== Business Service based on _Reductionkeys_
  Add a Monitored Service
  Remove a Monitored Service
  
  ==== Business Service based on Business Services
  
negative.code: | `Set To`   | Uses a constant severity
  | `Ignore`   | Ignores the severity of the managed element
  |===
  
  The list of mapped status are then reduced into the operational status of the business service.
  For the reduction the following _reduce functions_ are available.
  
  .State calculation _reduce functions_
  [options="header, autowidth"]
  |===
  | Name            | Description
  | `Most Critical` | Uses the value of the most critical severity.
  | `Threshold`     | Uses the highest severity found more often than the given threshold.
  |===
  
  
  ===== Operational-status changes
  If a business service changes its operational status, an OpenNMS event is fired.
  The event is of the type `uei.opennms.org/bsmd/serviceOperationalStatusChanged`.
  The log message of the event contains the name of the business service.
  Additionally the previous operational status and the new operational status are included.
  This event has no node, interface or service associated.
  It also does not contain a reductionkey to cause any alarms.
  
  
  ===== The BusinessServiceDaemon
  Internally the business service monitoring features is driven by the business service daemon (bsmd).
  It is responsible for tracking the operational status of all business services and sending events in case of operational status changes.
  Every time the configuration of a business service is changed a reload of the bsmd configuration is required.
  This includes changes like the name of the business service or its attributes as well as changes regarding the reductionkeys, contained business services or Ip-services.
  
  A config reload is always initiated by an _uei.opennms.org/internal/reloadDaemonConfig_ event with the parameter `daemonName` set to `bsmd`.
  If the reload of the config is done an _uei.opennms.org/internal/reloadDaemonConfigSuccessful_ event is fired.
  
  .Options to trigger the config reload event
  - Use the `Reload` button on the `Manage Business Services` page in the admin section of the WebUI.
  - Send the  _reloadDaemonConfig_ event directly to trigger the reload
  * Use the send-event script
  