Get Started with the
Business Enterprise Server (BES)

One of the core components of our AIOps platform the Business Enterprise Server (BES).  Enables IT providers to meet the challenges presented by large quantities of events and performance metric data produced throughout an ever-changing enterprise infrastructure. It goes an important step further by relating these technology events to the business services they impact. Interlink Software has developed BES, a set of software tools that fuse real-time event management and service level management.


What BES Provides

BES provides automated service impact analysis of events from your existing Infrastructure, Application and Business Services monitoring tools.


It enables you to focus on critical, service threatening faults immediately, and often without the need for manual intervention. It does this by automatically associating the real-time events with the relevant service-definition and service level agreement (SLA) information stored throughout your enterprise, whether that information resides in an ASCII file, an Asset data-store, or any type of database.


In this way, BES determines how technology faults will impact business processes, services, and customers.

Key Concepts

When you deploy BES into your environment the following core components are installed


  • BES Application
  • BES Console
  • Business Service Dashboard


These components enable you to build your environment and view enterprise and service management data in real-time.


Event processing functionality within the BES architecture comprises the following:


  • Normalization
  • Transformation
  • Enrichment
  • Correlation
  • Service Modelling
  • Automation


Value is added as data passes through the processing chain as depicted in the diagram below.


BES Application

BES provides the core services for collecting messages and processing alerts that enable a user to monitor and manage an enterprise or service.


The components of a BES Application:


  • AlertServer
  • BES Application Programming Interface (BESApi)
  • Database
  • Database Interface (dbi)
  • EventDaemon
  • Message Channels


AlertServer

The AlertServer is the main process within BES that performs the following:


  • Distributes alerts received from the message channels to BES clients
  • Suppresses, creates, or changes alerts based on defined correlation criteria
  • Manages the impact of technology alerts and tracks the alerts against service level agreements
  • Saves alerts to a file to ensure that no alerts are lost if one or more clients of AlertServer is unavailable


API (BESApi)

The BESApi is the interface between the BES Application and the BES clients such as ASI, the Business Service Dashboard and the BES Console.


Database

The database stores data for alerts, users, user groups, and services. The database, is installed on the same server as the BES Application.


Database Interface (dbi)

The dbi is a client of the AlertServer and provides the interface between BES and the database. The dbi receives alerts and update alerts from the AlertServer for storing in the database.


EventDaemon


The EventDaemon is a client of the AlertServer that provides synchronization between alerts generated by BES and any connected third party systems (for example, Tivoli Enterprise Console or HP Network Node Manager).


The EventDaemon forwards action events to the third-party application through the message channel connection program. Action events are user action performed on an alert associated with a third-party application, such as assignment or closure.


Message channels

Message channels collects events from managed sources and transform them into alerts.


A message channel is composed of:

  • A connection program that retrieves messages from a source; a source can be a log file, a third party system, or a program
  • An optional transformer that the user creates to modify collected messages; message modification can take the form of removal, replacement, or the addition of characters
  • The BES POWERpack transformer that creates alerts from the events and passes them to the AlertServer for distribution to connected clients


Business Service Dashboard

The Business Service Dashboard is a web client, launched via Internet Explorer, that delivers real-time, end-to-end views that enable a user to visualize service availability, performance, capacity, and security of their enterprise and service management environment.


Business Service Dashboard has two distinct roles available to select when you log on: the service dashboard and the admin console.

BES Console

The BES Console provides the following modules that are used to create alerts and services:


  • SMARTView - Create rule sets that define the alerts that are created (Normalization)
  • Enrichment - Enrich created alerts with meaningful information (Enrichment)
  • SMARTEvc - Close sympathetic alerts that document an event already documented in another alert (Correlation)
  • SMARTSla - Create services and define their availability based on the underlying technology alerts (Service Modelling)
  • SMARTEvm - Create automation policies that automate tasks based on predefined conditions documented in an alert (Automation)


Admin Console

The Admin Console provides administrative functions that you perform to set up the basic environment:


  • Creation of message channels that collect event messages
  • Creation of users and user groups that specify the functions that are accessible within the BES environment
  • Definition of the time zone under which BES operates
  • Retention period of alerts stored in the BES database and the AlertServer
  • Enablement or disablement of event correlation


Transformation

BES Transformers are used to:


  • Pre-format events to make SMARTView normalization rules easier to build
  • Simplify find/replace functionality
  • Strip unwanted events if this cannot be done at the source


Considerations when creating custom transformers:


  • Always use the supplied ISS templates as a starting point, ensuring consistent logging functionality
  • Load any lookup tables into memory, with auto refresh to save channel downtime
  • Avoid external calls to scripts unless they are infrequent – an external call for every event will place a large overhead on the event stream processing and hinder throughput
  • Keep the transformers as simple as possible – the more logic and complexity, the greater the overhead


Consideration when deciding whether to create a new transformer or use a SMARTView normalization rule:


  • When the incoming raw events are not easy to parse, or would require complex rule pattern-matching, consider creating a transformer to pre-normalize these events. This will simplify the raw events for easier rule building in SMARTView


For example: Tandem events are across multiple lines, so a transformer is essential.


Enrichment

The enrichment module in the console has been withdrawn from the BES Console and the functionality replaced by the Service Engine.

Enrichment adds meaningful information to normalized event streams.

The Service Engine enables a user to create an enrichment policy that defines the information that is added to an alert based on content already defined in an alert.

Meaningful information that can be added is based on customer needs such as the geographical location of a managed source or the person to contact when a managed source is unavailable.

Correlation

The SMARTEvc module enables a user to create a correlation pathway that defines the relationship between dissimilar events and automatically closes alerts that are a result of an event that is already documented in another alert.


For example, if a router fails, alerts are produced for all the systems that are connected to the router and the router itself. When event correlation is enabled on BES, the user sees only the router failure alert and not the alerts that are produced by the connected systems.

Service Modelling

The SMARTSla module in the console has been withdrawn, and the functionality replaced by the Service Engine.

Service Modelling defines the end-to-end visual representation of an IT service and the key business processes of the service.

Services are usually composed of several applications, middleware, and network component parts.

A service is the end-to-end technology infrastructure that enables one, or many business processes to be performed.



Service modelling enables a business to:


  • Understand how IT failures or problems affect key business processes
  • Track the business processes against service level availability definitions (SLAs)
  • Report on SLAs and help to resolve IT problems before they impact the service being provided to customers


Once defined, a service model will typically contain a hierarchy of elements, each representing a business process or function of an IT service. Each of the individual elements contains Business Rules that define precisely which IT technology components underpin each process in the enterprise.


The Business Rules control how configuration or asset data is filtered to extract the correct technology components for each process from external configuration data.

Automation

Automation Tasks are created using the SMARTEvm module.

Automation policies trigger tasks, such as recovery actions, from alerts created in BES.


Tasks have a predefined action and a predefined condition.


A predefined action can be the:


  • Modification of an alert’s severity or timeout value
  • Execution of a script
  • Creation of a message
  • Enablement or disablement of an automation policy
  • Suppression of an alert
  • Close of an alert
  • Escalation or de-escalation of an alert


A predefined condition can be based on time or message text contained in an alert. A message-based condition is used to identify a problem documented in an alert (for example, disk space is full or a router is down). A time-based condition is used to identify a schedule for an action that is not a result of a problem documented in alert (for example, generating a report or backing up your database).