Atrium CI to IRM Integration

 
This topic explains the basics of how BMC-sourced data is discovered, stored and managed inside IRM. Note that due to the complexity of the topic and the number of different components in the IRM and BMC applications involved to achieve this, this section will not go into too much detail on each, but serve as a baseline from which you can further explore specific subtopics and workflows.
 
First, a brief overview of some BMC terminology relevant to this topic:
Configuration item (CI) - A physical, logical, or conceptual entity that is part of an IT environment and has configurable attributes, such as computer systems, buildings, employees, software, and business services. Each CI is stored in BMC CMDB as an instance of a CI class.
 
Class - Represents a type of CI or relationship stored in the CMDB. Each class equates to a database table or a BMC Remedy AR System form, and each instance of the class equates to an entry in the form or record in the table.
 
BMC_Collection - an abstract class which stores information about physical collections, such as subnets and LANs, and logical collections, such as roles and user communities.
 
BMC_ComputerSystem - the primary class used to model computers in an organization. This class stores CIs relating to collections of managed system elements.
 
BMC_Equipment - stores information about physical equipment that is not related to computing, which can include buildings, vehicles, and other facilities related items
 
BMC_Person - stores information about the people who manage and depend on the other CIs in an IT environment.
 
BMC_Organization  - can be used to represent an internal organization, operating company, business unit, tenant, customer, supplier, vendor, and manufacturer.
 
BMC_LAN, BMC_WAN - In the common data model, LANs and WANs represent an aggregate of the IP subnets. These networks are characterized by the physical and logical connections between the nodes on the network and the infrastructure network devices (switches, hubs) that enable the devices to communicate with each other.
 
Next, we review the different parts of and features in IRM used for viewing and managing CMDB CIs within the IRM system.
 
 

Discovery Integration Service

IRM has a Discovery Integration Service (DIS), which is a separate IRM microservice component written specifically for the BMC integration and contains most of the business logic required for the integration. The Discovery Integration Service can operate both reactively - taking action directly on the user's request -- or actively, taking action on its own, for example, during an ongoing sync operation.
 
For BMC, DIS is configured via the BMC Proxy Source object (click on the following link for separate sub-topics explaining configuration of the BMC Proxy Source in detail).
  • A Proxy Source is an abstraction for an IRM-external software system that is capable of generating Proxies.
  • A Proxy is simply a lightweight representation of an external object, within IRM. 
 
 

BMC Proxy Varieties

The BMC Proxy Source supports several Proxy Varieties, which are named directly after classes in the BMC CMDB Common Data Model:
  • BMC_ComputerSystem
  • BMC_Equipment
  • BMC_Person 
  • BMC_Organization 
  • BMC_LAN
  • BMC_WAN
 
The last three items are all subclasses of the abstract Collection class, which is used to make lists of objects in the Atrium CMDB. After being connected to a CMDB, DIS automatically creates Proxies for all three classes of objects in the CMDB “production” dataset.
 
CMDB supports multiple datasets (see image above), but by design, IRM only interfaces with the production dataset. This is consistent with BMC’s design, where other (non-production) datasets are either temporary staging areas (import datasets) or used for special purposes (sandbox dataset).
 
 

Proxies and Twin objects

An object appearing under any of the BMC Proxy Varieties is not a "full" IRM object, but a Proxy object, which is a simplified representation of an external object within IRM. Proxies from all Proxy Sources are listed in the Object Grid and their corresponding varieties appear in the Categories & Types tree.  Where possible, IRM correlates these objects to IRM Managed Objects and we say that the Proxy and the Managed Object are "twins".
 
IRM enables for each of the BMC Proxy Varieties to have a corresponding "twin" objects from a specific IRM Super Categories:
  • For BMC_ComputerSystem Proxies the twins are IRM Equipment objects
  • For BMC_Person Proxies, the twins are IRM Users
  • For BMC_Organization, BMC_LAN and BMC_WAN Proxies, the twins are IRM Groupings
 
 

Discovery Manager

The primary "unit" of synchronization for IRM's Discovery Integration Service is the BMC_Collection class. In IRM, the central place for the user to manage synchronization operations and BMC Collections is a special-purpose dialog called Discovery Manager.
 
Click on the following link for a detailed description of the IRM correlation and synchronization process.
 
The Discovery Manager shows a list of BMC Collections organized in a tree menu on the left, while the right side of the dialog lists all IRM Discovery Sets and Task Requests for a selected Collection.
  • A Discovery Set is a collection of Proxies generated from a single Proxy Source (BMC), from some subset of the data owned by that Proxy Source (BMC Collection).
  • A Task Request is an object that indicates to an operator to do some work in order for a workflow to proceed.  In a sense, a Task Request is something like a Ticket, but Task Requests are lower-level, can be generated automatically by IRM, and can be used in cases where tickets are not necessarily involved.
 
The dialog also enables additional features relevant to maintaining BMC data records displayed, such as, enabling the user to control the Lifecycle Stage of BMC Collections, as well as starting both Library (Type) and instance synchronization operations. More details about how this works and how to use the Discovery Manager dialog in general can be found here.