Device Broker Support

Overview

This page explains the role of Itential Automation Gateway (IAG) in facilitating the device broker functionality within Itential Platform. The topics that will be covered include:

• Key features of the device broker
• The specific API calls it supports
• How the Automation Gateway translates these calls into actionable tasks through Ansible roles

Benefit of using a device broker

As organizations increasingly rely on a variety of network devices, having a standardized approach to managing them is essential. The device broker functions as an intermediary that enables effective communication between applications and various network devices, regardless of their native API capabilities.

Key aspects and functionality

The device broker is an abstraction layer in Itential Platform that allows applications (such as Configuration Manager) and workflows to send requests and receive responses from network devices, including those that do not provide a native API. It defines a set of common API calls (i.e., getDevice, getConfig, runCommand, etc) to standardize interactions with diverse device types through different interfaces.

The table below shows the mapping from the device broker call to the adapter function that implements the Ansible role.

Role of Automation Gateway

Automation Gateway implements the device broker calls through the Automation Gateway Adapter. When a device broker API call is made, the adapter maps that call to an Ansible role using the Automation Gateway API. The Ansible roles are responsible for executing the logic required to fulfill the broker API request - such as retrieving device configuration, running commands, or checking device state.

Role Selection & Execution Flow in Automation Gateway

When a device broker call is made, Automation Gateway follows a specific sequence to select and execute the appropriate Ansible role for the target device.

1. Device Selection:
   • The process begins by selecting the device from Automation Gateway’s inventory.
2. Ansible Native Module Path:
   • If the device inventory includes the ansible_network_os variable and its value matches a supported device OS (such as IOS, Junos, NX-OS, etc), Automation Gateway loads and executes the corresponding predefined Ansible role.
   • These roles use device-specific modules provided by the Ansible community to interact with the device.
   • This is the preferred and most fully integrated path, enabling the use of all Automation Gateway and Platform features
3. Netmiko Path:
   • If ansible_network_os is not set, or if it does not match a supported device OS, but the inventory includesnetmiko_device_type (or provider.device_type), Automation Gateway will use an Ansible role that implements the generic Netmiko Ansible module.
   • The Netmiko module provides support for a wide range of devices via SSH, even if there is no native, device specific Ansible module
4. Custom Role Path:
   • If neither ansible_network_os nor netmiko_device_type/provider.device_type are set, Automation Gateway attempts to load a custom role.
   • The custom role is mapped to the value of ansible_network_os (which should be a unique, non-standard value for your custom device/role).
   • These custom roles are user-extensible and reside in a directory specified in the IAG configuration as the "Extended Device Role Path".

Sequencing is summarized in the table below. This approach ensures that Automation Gateway can support a wide range of devices out-of-the-box, while also allowing users to extend support to new or custom devices by creating their own custom Ansible roles.

Summary Table

 
For information on connecting to devices using SSH, see the Connectivity Support page.