Matrix42 DDM - Matrix42 Professional Integration
Matrix42 DDM - Matrix42 Professional Integration
Introduction
This document provides a comprehensive overview of the Matrix42 Discovery & Dependency Mapping (DDM) integration with Matrix42 Professional (formerly known as Efecte).
The integration leverages the EIS integration service to facilitate seamless data transfer, enabling the automatic retrieval of discovered Configuration Items (CIs) and their relationships from DDM into Matrix42 Professional. By consolidating this data, the integration enhances visibility, dependency mapping, and centralized management of IT assets within the Matrix42 Professional solution.
The DDM plays a critical role in supporting key IT Service Management (ITSM) processes, including change management, problem management, IT Asset Management, and Configuration Management. By automatically discovering devices and mapping their dependencies, DDM ensures that the Configuration Management Database (CMDB) remains up to date with accurate and comprehensive information about the IT environment. This integration enables IT teams to assess the potential impact of changes, identify root causes of incidents, and maintain overall system reliability. Through these capabilities, the integration empowers organizations to improve efficiency, reduce risks, and deliver better IT services.
Architecture Overview
The architecture for the Matrix42 DDM to Matrix42 Professional integration consists of three main components. In the customer network, an agent is deployed to discover assets and their dependencies. This agent collects information from the environment and sends it to the DDM (Discovery and Dependency Mapping) module located in the M42 Public Cloud, where the discovered Configuration Items (CIs) and their relationships are processed. The data is then transferred via the EIS integration service, which facilitates seamless integration. Finally, the processed data is delivered to M42 Professional, ensuring an up-to-date and accurate CMDB with detailed dependency mapping for IT Service Management processes.
Integration Process Overview
The integration process for the Matrix42 DDM and Matrix42 Professional involves the following steps:
1. Start
- The integration process begins based on a predefined schedule
2. Configuration Reading
- The integration reads configuration settings from the service management tool (M42 Professional)
- The configuration includes filters (e.g., account and CI type) to define the scope of data retrieval and mappings to determine how fields from the source system correspond to fields in the target system.
3. API Call Fabrication
- The integration fabricates an API call to the source system (DDM) using the configuration settings.
- This API call fetches data from the source system, including Configuration Items (CIs) and their relationships.
4. Mapping
- The fetched data is processed and mapped according to the defined source-to-target mappings.
- Mappings are structured as sourcefield;targetfield pairs to ensure that data is correctly aligned between the source system and ESM.
5. Saving Data
- The processed and mapped data is saved to the service management tool ensuring proper storage and availability for subsequent processes or updates.
6. Pagination
- If the data fetched from the source system exceeds a single API call’s limit, pagination is used to retrieve the data in manageable chunks, ensuring complete data transfer.
7. End
- Once all data is successfully fetched, mapped, and stored, the integration process concludes, readying the system for the next scheduled run or manual initiation.
Use cases
- Fetching new and updated discovered assets from DDM to M42 Professional to the Device template on a recurring, scheduled basis
- Using filtering within the integration configuration for fetching specific configuration item (CI) types (e.g. exclude network devices, but include servers).
- Fetching the data relations between the discovered CIs
Not in scope
- Two-way integration: Data is not transferred from M42 Professional to DDM
- Support for legacy on-premise deployments
Prerequisites
- A Matrix42 DDM instance for discovering and mapping Configuration Items (CIs) and their dependencies.
- A Matrix42 Professional environment (formerly known as Efecte) for managing and storing discovered data.
- Access to the network containing the devices to be discovered, ensuring the agent can reach the target devices.
- For hybrid deployments using an EIS agent (where the EIS logic runs on the customer’s server), the customer must ensure that the necessary network ports are opened to enable communication between the agent and the relevant systems.
Data Mapping and Transformation
The tables below outlines the default mappings for each device type.
Server
| DDM Field | Target Field in M42 Professional |
| account_id | ddm_spm_account |
| ci_profile.last_seen | ddm_last_seen |
| ci_profile.macaddress | ddm_mac |
| ci_profile.notes | ddm_notes |
| ci_profile.os | ddm_os |
| ci_profile.serialno | ddm_serial_number |
| ci_profile.total_ram | ddm_total_ram |
| ci_profile.version | ddm_os_version |
| dns | ddm_dns |
| edge_device_id+DDM_id | host_name |
| edge_device_id | ddm_edge_device |
| DDM_id | ddm_id |
| ip | public_ips |
| logicalgroup | ddm_logical_group |
| servicegroup | ddm_service_group |
| status | ddm_monitoring_status |
Network device
| DDM Field | Target Field in M42 Professional |
| account_id | ddm_spm_account |
| ci_profile.last_seen | ddm_last_seen |
| ci_profile.macaddress | ddm_mac |
| ci_profile.notes | ddm_notes |
| ci_profile.os | ddm_os |
| ci_profile.serialno | ddm_serial_number |
| ci_profile.total_ram | ddm_total_ram |
| ci_profile.version | ddm_os_version |
| dns | ddm_dns |
| edge_device_id+DDM_id | host_name |
| edge_device_id | ddm_edge_device |
| DDM_id | ddm_id |
| ip | public_ips |
| logicalgroup | ddm_logical_group |
| servicegroup | ddm_service_group |
| status | ddm_monitoring_status |
VM Hosts
| DDM Field | Target Field in M42 Professional |
| account_id | ddm_spm_account |
| ci_profile.last_seen | ddm_last_seen |
| ci_profile.macaddress | ddm_mac |
| ci_profile.notes | ddm_notes |
| ci_profile.os | ddm_os |
| ci_profile.serialno | ddm_serial_number |
| ci_profile.total_ram | ddm_total_ram |
| ci_profile.version | ddm_os_version |
| dns | ddm_dns |
| edge_device_id+DDM_id | host_name |
| edge_device_id | ddm_edge_device |
| DDM_id | ddm_id |
| ip | public_ips |
| logicalgroup | ddm_logical_group |
| servicegroup | ddm_service_group |
| status | ddm_monitoring_status |
Delegates
| DDM Field | Target Field in M42 Professional |
| edge_device_id | ddm_edge_device |
| DDM_id | ddm_id |
| servicegroup | name |
CI Relations
The integration fetches the device information as well as the relationship information describing the relations between the devices. Users can view the relations as a list from the Device datacards, as well as from the Visual Analyzer.
Technical data model for presenting relations
DDM provides the relation information separately from the device information. The integration fetches the relationship information to the CI Relation template. This makes it possible to describe and present the relationships and their types in the service management tool.
The data model for the CI relations enables the service management tool to present the relations (as shown above in the screenshot of the Visual Analyzer).
- Devices are imported, including their relations to the CI relation datacards
- CI relations are imported with target CI information
- Automations (expressions) on the CI relation datacards populate the various reference attributes (e.g. Connects to, Contains, Related etc.) with relations to CI relation cards
This results in a human-readable data model that represents the actual configuration of devices and their relations.
Please note that the data model for the CI relation cards is rather abstract, and does not attempt to describe the actual data model of the CIs themselves.
More information about the supporting CI relation data model
Integration Configuration Datacards
The integration configurations are defined by Integration configuration datacards. This allows adjustments to the integration without modifying the EIS integration process.
Please note that the mappings for defining the CI relations are defined within the EIS integration process.
Data handling practices
Triggers
- Schedule-based, determined by EIS.
Schedule
- Once a day, at 00:00.
Error Handling and Logging
- Lightweight error handling: an automatic error email notification is sent to M42 Service Desk. The error handling practices defined by the EIS service description apply to this integration.
- If DDM does not return data, an error message is provided
- The integration is stopped in case of any error in the integration process
Security and Compliance
- Data encryption: HTTPS
- GDPR compliance: Not applicable, since no person data or other sensitive data is involved in the assets.
Architecture
- Test instances for DDM: N/A
- M42 Professional test and dev environments can be used in case the customer has such environments.
Deployment and Rollout
This section provides a concise overview of the key steps to implement the Matrix42 DDM integration effectively.
1. DDM Setup
- A dedicated DDM instance is deployed, with the edge device installed within your network to facilitate asset discovery.
- The edge device scans the network, identifying Configuration Items (CIs) and their interdependencies.
2. Network Configuration
- Secure network connections are established, including firewall adjustments as needed, to enable safe communication between components.
3. EIS Configuration Import
- Essential EIS configurations are prepared and imported to enable integration.
- If applicable, an EIS agent is installed and configured to facilitate operations.
4. API Access Configuration
- A dedicated API user is created, ensuring secure communication for the integration.
5. Data Model Preparation
- The data structure of your system is aligned to support seamless integration.
- This involves defining target attributes on device templates.
- Unified Template Approach: A single template supports various device types.
- Segregated Template Approach: Separate templates are maintained for each device type (e.g., Server, Network Device).
- Import and configure the integration template if not already available.
6. Testing and Validation
- Comprehensive testing is performed to confirm that all components function as expected and integration requirements are met.
7. Process Activation
- Integration processes are activated, allowing data to flow seamlessly between Matrix42 DDM and Matrix42 Professional.
Table of Contents