anchor.diff:  ----
   * Use the `Manually Send an Event` page of the WebUI located in the admin section to send the event.
   
  -- TODO Rest-API??
  +- Use the Rest-API to perform a `POST` request to `opennms/api/v2/business-services/daemon/reload`.
   
   ==== Business Service Rest-API
  -Every aspect of the Business Service Monitoring feature can be controlled via a Rest-API.
  -The Rest-API for Business Services is located at `opennms/api/v2/business-services`.
  -It supports _JSON_ and _XML_ content to represent the Business Services.
  +Every aspect of the business service monitoring feature can be controlled via a Rest-API.
  +The Rest-API for business services is located at `opennms/api/v2/business-services`.
  +It supports _JSON_ and _XML_ content to represent the business services.
  +The responses of the Rest-API contain location elements.
  +The location elements provide references to urls to navigate to.
  +
   TIP: Please check `http://www.opennms.org/wiki/ReST` for an overview of the OpenNMS Rest-API.
  +
  +WARNING: The _JSON_ support has problems at the moment. Use the _XML_ format for now.
   
   The Business Service model for the Rest-API has the following basic structure:
   
  
positive.code: -- This reductionkey matches the alarms fired if the entire node providing the monitored-service goes down.
  
  
  ===== Attributes as part of Business Services
  ////
  TODO add this part as soon as the attributes are used.
  Each Business Services can contain a set of key value attributes.
  ////
  
  
  ==== The operational-status of a Business Service
  //TODO this will change drastically during the 5th development sprint.
  The operational-status of a Business Service is correlated to the highest alarm status of the elements it contains.
  This approach of state calculation is called `Most Critical`.
  If a Business Service contains another Business Service the operational-status of the included Business Service is interpreted as an alarm status.
  The set of status for the operational-status is defined by the OpenNMS severities.
  
  .State calculation _reduce functions_
  [options="header, autowidth"]
  |===
  | Name            | Description
  | `Most Critical` | Uses the value of the most critical severity.
  |===
  ////
  TODO not implemented for now (part of the upper table)
  | `Threshold`     | Uses the highest severity found more often than the given threshold.
  ////
  
  ////
  TODO not implemented for now
  .State calculation _map functions_
  [options="header, autowidth"]
  |===
  
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
  