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.
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.
When you deploy BES into your environment the following core components are installed
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:
Value is added as data passes through the processing chain as depicted in the diagram below.
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:
The AlertServer is the main process within BES that performs the following:
The BESApi is the interface between the BES Application and the BES clients such as ASI, the Business Service Dashboard and the BES Console.
The database stores data for alerts, users, user groups, and services. The database, is installed on the same server as the BES Application.
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.
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 collects events from managed sources and transform them into alerts.
A message channel is composed of:
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.
The BES Console provides the following modules that are used to create alerts and services:
The Admin Console provides administrative functions that you perform to set up the basic environment:
BES Transformers are used to:
Considerations when creating custom transformers:
Consideration when deciding whether to create a new transformer or use a SMARTView normalization rule:
For example: Tandem events are across multiple lines, so a transformer is essential.
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.
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.
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:
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 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:
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).
Thank you for registering for Interlink News and Articles. If required, you can locate our privacy policy here
Oops, there was an error sending your message.
Please try again later.
Registered in England No. 3183538 VAT GB 693 613 610
© 2025 Interlink Software Services Ltd. All rights reserved. All product names, logos, and brands are property of their respective owners.
All company, product and service names used in this website are for identification purposes only. Use of these names, logos, and brands does not imply endorsement.