SolarWinds Connector
This section of the documentation contains technical specifications about the connector that is implemented to link ASM Core and the SolarWinds systems listed below.
This section of the documentation contains technical specifications about the connector that is implemented to link ASM Core and the SolarWinds systems listed below.
Including:
The name of the .NET assembly file
Connection methodology
The resource and link types that can be discovered on the application
The attributes of each resource and link types that can be imported into the ASM Core Configuration Management Database (CMDB)
Server & Application Monitor
Virtualization Manager
Network Performance Monitor
For compatibility and version support details, refer to the ASM Connector Matrix.
The table below provides a description of the SolarWinds connector.
The table below provides a description of the SolarWinds connection parameters.
This connector permits extensions to the schema through customization of the configuration file. The possible customizations are listed below. However, the customizations are not limited to these:
New resource types
New resource properties
New link types
The connector has the facility to trace information. The data can be obtained through Polling tracing or Application tracing.
The resource types available for mappings are:
Nodes
Virtual Clusters
Data Centers
Nodes are the only SolarWinds link types that are exposed by the connector by default.
This section provides information about the Event Management capability of the SolarWinds connector.
The purpose of this functionality is to:
Automatically transpose alerts generated by SolarWinds into ASM Core calls or requests.
Maintain the consistency of the information held in the item created in ASM Core.
The operation of this functionality relies on the connector monitoring the SolarWinds alerts in order to detect any new alerts. When such event occurs, the Integration Platform automatically compares the attributes of the new alert against some user-defined criteria. In case criteria are met, the platform proceeds with the creation of a call/problem or a request depending on the user settings.
From a practical point of view, SolarWinds alert attributes can be mapped to ASM Core fields. This mapping is used when creating a new call or request.
As the alert is updated, the connector ensures that these modifications are properly transmitted to the related ASM Core item. The current behavior of ASM Core, upon receipt of such updates and notifications, depends on the Event Mapping settings that are configured in ASM Core.
Eventually, physical actions on the network will be taken to fix the issue and the SolarWinds alert will be marked as Inactive or will disappear from its queue. This fact will also be transmitted to the relevant ASM Core item and the final result (Call Updated, Call Closed and so on) will again depend on the Event Mapping settings in ASM Core.
The following use case describes the scenario where an organization sets up integration between ASM Core and SolarWinds. In this scenario, ASM Core is responsible for Service Desk and Change operations and SolarWinds is responsible for issuing alerts.
The use case scenario in the previous section, and more generally the Event Management operation of the connector, rely on a particular communication protocol between the two systems. This protocol is composed of different transactions that are detailed below.
The transactions and their descriptions are listed below.
The table below defines some business rules that specifically apply to the SolarWinds integration.
There are no business rules for the other transaction types.
Check the following items when setting up the Event Management functionality of the SolarWinds Connector:
Ensure that the Event Management checkbox is selected in the Integration Platform settings window.
Ensure that the SolarWinds Connector is installed and the check boxes in the Events and Visible columns are selected in the Integration Connectors window.
Ensure that a SolarWinds source is defined in the Integration Source window.
Ensure that a SolarWinds Event mapping is defined in the Event screen. This mapping should at least specify the action to be performed (log call/create request) when a notification is carried over, as well as the template to be used for this action.
If the Event Management checkbox in the Integration Platform administration screen is selected, the Event Management functionality starts running as soon as a proper Event mapping is completed and saved. When starting, the connector immediately connects to the SolarWinds system and logs a call/request for every alert that is present and fulfills the criteria that are implemented in the Event mapping. This can lead to a large number of calls/requests being created when activating the Event Management functionality.
One solution to avoid this behavior is to include in the Event criteria setting an item based on the Triggered Date Time attribute. For example, you could plan to “go live” with Event management on a precise date and, as a consequence, specify that the value of Triggered Date Time has to be after this date before any action can be triggered in ASM Core.
The table below lists all the SolarWinds alert attributes that are exposed by the connector.