Installing Connectors
Before reading this document, it is important to understand how the Integration Platform module is configured and define the future use of the information imported from third-party applications. Setting Up the Integration Platform provides more information.
The Integration Platform
The ASM Core Integration Platform encompasses three capabilities that require specific connectors to act as an interface between the Integration Platform and the third-party vendor application:
The Federated Configuration Management Database (CMDB) enables integration with third-party applications that discover and manage wide range of resources or persons, and then imports those resources into the CMDB.
The Event Management platform allows ASM Core to capture events produced by network monitoring tools and then log calls or create requests in relation with these events.
The Inbound/Outbound Actions capability enables third-party applications and ASM Core to trigger predefined actions into the opposite system.
Connectors
Each connector is a .NET assembly that is developed to support a specific version of the third-party application for which the connector provides an interface. Typically, each application requires its own connector to provide the common interface. However, these connectors are also designed to be highly customizable.
The ASM Core connectors can be classified in two broad categories:
Connectors that ensure communication to third-party resources and persons discovery and management application. These connectors plug into the Federated CMDB component of the Integration Platform.
Connectors that allow third-party tools to perform actions inside ASM Core or that enable ASM Core to trigger actions in third-party application.
Federated CMDB Connectors
Several third-party applications are used within organizations to discover, catalog and manage a wide range of physical and virtual resources and persons. ASM Core sites that run these applications often need to represent these resources and persons as CMDB items and persons within their ASM System. The Federated CMDB provides some periodic retrieval and synchronization capabilities designed for resources and persons imported from third-party applications.
A Federated CMDB connector:
Establishes a connection with the third-party application.
Declares available resource and link types, as well as their properties.
Retrieves resources or persons and their properties, as well as the linkage information between resources.
A Federated CMDB connector only provides data to the Federated CMDB, after which the ASM Core code analyzes and imports data into the CMDB. It does not create, update, or delete CMDB items, create discrepancy reports, process ASM Core screens or use ASM Core SQL queries or HTML templates.
The Federated CMDB connector is a read-only interface to the third-party application data. Therefore, the connector is not required to:
Perform actions on external sources or resources
Update external resources so that they are synchronized with the ASM Core CMDB
The Federated CMDB can use any number of connectors, which users are free to develop. Each third-party application requires a specific connector because the way in which data is stored and exposed is different for each application. Therefore, the connectors vary for each application and each connector uses a different technology. Some of the technologies that have been used include:
SQL
LDAP
SOAP/HTTP/Web Services
A particular connector has also been created to read source exported data from comma separated value (.CSV) files.
The methodology for accessing data exposed by an application is the methodology that the tool vendor recommends.
Event Management and Inbound/Outbound Actions Connectors
Event Management connectors or Inbound/Outbound Actions connectors present characteristics and settings that are very specific to the function they perform. This is particularly obvious for the Inbound/Outbound Actions connectors, whose functionalities strongly rely on the third-party capabilities.
From a technical point of view, these connectors are more likely to use API and Web Services to communicate. The definition of operation period also follows a different approach. For Federated CMDB connectors, operation schedules need to be set up by an administrator. These schedules have to specify a precise running time and a possible recurring pattern. For an Event Management or Inbound/Outbound Actions connector, these timing and recurring notions are irrelevant: the connector is either continuously running, or is switched off by an analyst (provided the analyst has appropriate credentials). They cannot be activated according to a predefined schedule.
Event Management requires a constant monitoring of the third-party events in order to log calls or create requests in a timely manner. As for Inbound/Outbound Actions connectors, the actions they handle can be triggered by appropriately designed workflows, which can be created at any time. This makes it impossible to forecast when the connector will be called into action. Hence, the continual background operation of these two types of connectors is required.
Difference between the Use of Event Management and Inbound/Outbound Actions Connectors
An Event Management connector only allows a third-party network monitoring tool to create calls and/or log requests in ASM Core. This behavior does not require a lot of settings as it is quite rigid in the proposed outcomes, that is, calls and requests creation.
An Inbound/Outbound Actions connector allows the third-party application or ASM Core to perform diverse actions on one another. In this sense, it is more bidirectional and generic. These actions have to be predefined in both systems before any work can begin. This flexibility in defining actions on both sides results in a higher number of settings.
Both Event Management and Inbound/Outbound Actions capabilities adhere to special communication protocols composed of precise transactions in order to ensure efficient communication throughout the lifecycle of an event or an action. These two protocols are illustrated below.
The Integration Platform Guide contains more information about these protocols.
Authentication and Login Credentials
Some connectors allow actions to take place in the third-party application or in ASM Core. For these actions to take place successfully, the connector ensures that the rights of the person specified in the connector source details are sufficient to perform the requested action. For example, triggering a job in Network Configuration Manager requires the login ID and password of a Network Configuration Manager user who possesses the proper rights to trigger a job. Similarly, one ASM System can create calls or requests in a second ASM System only if the rights of the person entered in the connector source details are appropriate (in this case, IPK and Change Management rights, respectively).
Version of Third-party Applications
Connectors are standard components of ASM Core and some of them require a particular license key to be specified in the server console. Moreover, each of these connectors has been developed against one or several specific versions and configurations of a particular third-party application. This information is documented for each connector.
Many applications rarely alter their data schemas drastically between releases. In most cases, a connector will be compatible with obsolete and future versions of a particular application. However, it is necessary to test the connector against the particular version. In instances where inconsistencies between versions exist, variations can often be accommodated by modifying the connector configuration file.
Similarly, larger applications are often divided into various suites and editions that include different subsets of the application components. A site may be running one or more of these variants depending on their business needs. Often these variants share a common data schema or at the very least share the same means to access that data. So, a single connector can often be used across multiple variants with only minor changes to the configuration file.
Installing Connectors
The following connectors are already installed with ASM Core, so the installation instructions are not relevant:
Microsoft Active Directory Connector
Novell eDirectory Connector
ASM to ASM Connector
Generic Database Resources Connector
MS SQL Table Entity Connector
MS SQL Table Event Connector
MS SQL Table Lookup Connector
MS SQL Table Outbound Action Connector
Atlassian JIRA Connector
Alemba® External Process Connector
Alemba® Stored Procedure Connector
CSV Connector
The EMC Smarts Service Assurance Manager (SAM) connector installation process differs from all the other connectors. See Service Assurance Manager Connector for more information.
All files for the connectors come standard with ASM Core. However they will not appear in the Integration module until the steps below are followed. The except are the connectors listed above.
Take the following steps to install all other connectors.
You may need to run an IIS reset to stop unnecessary processes that will prevent the installation from running. Go to Start > Run, and type iisreset. Be aware of other users before doing an IIS reset.
Open the ASM Core Server Console.
For each system, right-click the system name. From the menu that appears, select Database Tasks > Run Custom SQL Script .
In the Run Custom SQL Script dialog box, navigate to the Config folder in your system directory
Select the appropriate SQL installation script. For example, to install the CSV Connector select Infra.Connector.CSV.Install.scp
Open the file to run the script.
Select No when prompted if other any other scripts need to be executed. The Server Console then parses the query files. When completed, close the Server Console.
Go to Start > Run, and type
iisreset.Select OK. This completes the installation of the connector that is now ready for use within ASM Core.
Installation with Powershell
For Servers without Server Console, you can install using Powershell. Installation of the connector with PowerShell involves the command Invoke-SQLScript
**You must install the AlembaUtils function to use the Invoke-SQLScript command. See Administration Using Powershell for more information.
Access the Application Server for ASM.
Open Powershell and execute the following (replace [system name] with the name of your system):
Invoke-SQLScript -System [system name]- Alemba.Connector.Azure.DevOps.Install.scp ".\script.sql
Additional Considerations
You need the permission Integration Setup in the General Access Security Role, to configure and use the Microsoft Azure DevOps Connector.
To create calls in ASM from work items in Azure DevOps, the DevOps project must have Service Hooks configured for ASM.
Specifying Connection Parameters
The Connector service must be running so that the connector operates properly.
Connecting with a SQL Database Connector
Most applications store their data in a relational database. These databases are also called SQL databases because they can be queried by using the Structured Query Language (SQL). Other examples of SQL databases include Oracle, Access, MySQL, DB2, and Sybase. Connectors that interface with a third-party application’s SQL database typically use ODBC.
SQL databases are not to be confused with Microsoft SQL Server, which is a specific example of a relational database.
To establish a connection between ASM Core and a third-party application, three common connection parameters are required. They are:
DB Connection
The connection string that specifies the database server
DB Login ID
This and the password are credentials that authenticate the connector against the database
DB Password
This and the Login ID are credentials that authenticate the connector against the database
Some connectors require an additional connection parameter DB Type. This is required in those cases where a connector is expected to interface with more than one kind of relational database. For example, LANDESK can use either an Oracle or an SQL Server database. Although most SQL databases are very similar, each one can support different variants of SQL syntax and require different logic to perform operations. Specifying a DB Type instructs the connector to use a particular SQL syntax and logic to communicate with the application.
When configuring a source by using an SQL Database Connector, consult the administrator of the third-party application or the Database Administrator or both to determine the server location, catalog, credentials, and any other relevant database parameters to access the data source.
Some applications use an embedded database — that is a database that is stored locally among the application files and managed by the application itself. This approach can be limited because the connector has to access the embedded database files directly by presenting some network and security hurdles to be cleared. Such applications frequently offer a data export utility, whereby data can be periodically exported to a more accessible data source such as an SQL Server or Oracle, which can make the data more accessible.
Note the following when attaching the connector to an exported data source:
The data will be as up-to-date as the most recent data export.
If more frequent scans than the scheduled data exports are scheduled, they would perform redundant work.
Specifying a Connection String
The syntax of a database connection string varies in relation to the data source.
Here is an example of SQL Server connection string by using SQL Server authentication that uses Login ID and Password provided in the appropriate fields:
Server=Server;Database=Catalog;Persist Security Info=True
Here is the same string when Integrated Security is activated:
Server=Server;Database=Catalog;IntegratedSecurity=SSPI; Persist Security Info=True
Here is an example of Oracle connection string by using Login ID and Password provided in appropriate fields:
Persist Security Info=True;DataSource=Server TNS Entry;Extended Properties="PLSQLRSet=1"
DB Login ID and DB Password can also be incorporated into the connection string. However, it is recommended that the password is stored in the dedicated DB Password field where it can be stored in an encrypted format.
Last updated
Was this helpful?