Integrations of third-party systems with Enterprise Alert, what is possible?

In my work with new and existing customers, I keep coming across the assumption that Enterprise Alert is not able to be integrated with certain third-party systems in order to receive and process events and fault messages from this system.

Basically, first of all, we have to say: We can integrate everything that communicates digitally in any way. We differentiate between 3 categories: our smart connectors, which were developed for two-way communication with selected third-party systems, our standard APIs and our custom integrations. My goal is to show you the options you have with Enterprise Alert, even if your third-party systems are not explicitly listed with us.

Smart-Connectors (No-Code)

We offer certified and secure plug & play connectors for leading ITSM and ITOM systems. The bidirectional integration enables closed alarm processes. Enterprise Alert also allows feedback in the ITSM system, for example to assign the incident to the employee who confirmed the alarm. In addition, the associated alarm is closed in Enterprise Alert if a fault in the ITSM system is closed. In this case, Enterprise Alert can stop the alerting process and inform you that the fault has been rectified.

You only have to enter certain access data for the third-party system, so that the smart connectors are de facto “no-code” connectors.

If you are using one of the following systems and want to integrate it with Enterprise Alert, you can expect little effort. In most cases only one user with the right rights is required. As of February 2021, we support connectors for the following systems:

• Microsoft System Center (SCOM, SCSM, SCO)
• IBM Tivoli and Netcool
• BMC Remedy and TrueSight
• MicroFocus (formerly HP) NOM (NNMi), OMi, Opsbridge, SMA and OO
• ServiceNow

The next version of Enterprise Alert (expected from April 2021) will offer additional “no-code” connectors.

Standard APIs (No-Code/Low-Code)

By standard APIs we mean all interfaces that, as the name suggests, are standardized and are part of every Enterprise Alert installation as standard. These interfaces include SNMP, CLI, File Interface, HTTP POST / GET, SOAP, REST, SMTP, OPC and Serial Bus / RS232.

It is these interfaces that de-facto enable integration with any third-party systems in IT, production, IoT and other areas. In most cases, the REST interface is used. We have started to document the integration of numerous third-party systems and you can find a constantly growing overview here.

SMTP

One of the most prominent APIs is definitely SMTP, as pretty much every system can send at least one e-mail, be it the SQL DB, which sends job results (can be done more elegantly), or WhatsAppGold , which mainly communicates via this interface. Our integrated SMTP server allows you to transfer mails directly to Enterprise Alert without having to rely on an additional mail infrastructure. Basically, the SMTP interface is also a “no-code” interface.

REST

REST follows closely as an API that is increasingly replacing other interfaces and making them obsolete. It is characterized by its ease of use and high flexibility. In our conversations with customers, we find more and more often that REST is an issue where modern cloud tools are also used. But also good, old friends like Nagios and Incinga offer REST as an option.

SNMP

The SNMP protocol is an “old”, but by no means obsolete protocol. It still has its place, especially in the area of ​​network monitoring. Enterprise Alert acts here as a trap receiver and thus allows SNMP traps to be received from the corresponding elements. We wrote this blog to simplify the use of the data provided.

Command Line Interface (CLI)

The Enterprise Alert Command Line Interface (CLI) can be used to send simple raw data (plain text) as well as parameterized events, which can then be evaluated in alert policies. The CLI is often used to integrate legacy applications or in-house developments into Enterprise Alert. The prerequisite for this is that a shell command for forwarding your events can be executed.

File Interface

Enterprise Alert offers you the option of reading files as events. These can either contain plain text or be in the Enterprise Alert XML schema. You can freely choose where this folder is located, local directory or UNC share, both are possible. We see such scenarios particularly often in highly secure environments with strictly separated networks. Usually the only way to exchange data there is via specially monitored shares that we can use. Or you just use the interface to simulate events.

Web Service

In addition to the REST interface, Enterprise Alert also offers an HTTP POST / GET and SOAP interface. This interface could also be seen as the forerunner of the REST API, but that doesn’t mean that it is obsolete. We keep finding that especially older systems or older versions cannot handle REST yet and are therefore dependent on alternatives, such as an older Solarwinds installation in this case . In such cases, Enterprise Alert can provide modern alerting without having to replace the entire monitoring solution.

OPC UA

We often see this interface in production-related scenarios, but now also increasingly in logistics. It allows Enterprise Alert to connect to Manufacturing Execution Systems (MES) in order to receive and alert a wide variety of production parameters. In Derdack Enterprise Alert we support the OPC UA (Universal Access) partial standard. You can find more information about OPC here.

Serial Bus / RS232

Perhaps not the most widely used interface, but Enterprise Alert also offers a solution for this niche scenario. Our serial RS232 interface is mainly used in facility management scenarios. The connector continuously reads data from RS232 interfaces. It can forward the read data to the Enterprise Alert kernel and trigger events if no data has been received within a configurable time frame (missing heartbeat). The opposite way is also possible here.

Programmable APIs

If you haven’t found anything to connect your system to Enterprise Alert, you will find it now. In general, we understand the programmable APIs to be our Application Programming Toolkit (APT) and our NodeJS module. Which of the two modules you use depends largely on your needs.

APT(Java Script und Visual Basic)

Scripting is a very powerful tool that cannot only be used to connect to third party systems. It can be used whenever more specific functions or workflows are required, e.g. B. to allow access to databases, files and other software components in the most flexible way possible. You can find an example here and we would be happy to provide you with our APT documentation if you are interested.

NodeJS

The big advantage of NodeJS is the open-source nature and the associated large community, which can provide you with many helpful tools and components for your project. An example of a NodeJS project we have developed is our S7 connector . This connector allows you to connect directly to PLC modules and to query the corresponding bit values. With the help of an associated database, it is then possible to generate understandable events that can then be alerted by Enterprise Alert.

Summary

As you can see, Enterprise Alert already offers numerous APIs for the integration of various systems from all conceivable areas – from railway organizations to water suppliers . Use the diverse integration methods provided by Enterprise Alert to consolidate event data from different systems and process them in a central alerting platform. This enables your company to react appropriately and purposefully to problems.

Enterprise Alert helps you to guarantee and implement ITIL-compliant alerting processes in accordance with your internal guidelines, without restricting your choice of systems and interfaces. Please let us know if this blog has helped you and if it has piqued your interest. We would be happy to demonstrate the extensive possibilities of Enterprise Alert in an online demo.