Itential Automation Platform

On this page:

Architecture

The Itential Automation Platform (IAP) is a multi-tiered solution that integrates with your existing IT systems and enables a unified view of workflows across multi-domain network environments.

Design Studio - Allows users to rapidly build workflows, templates and forms used in network automation. Pre-built artifacts for common use cases are also available.

Management Applications - Provides a client-side user interface to enable automation across operations, configuration, policy and orchestration management.

Intelligence Engine - Intelligent automation can identify what's on the network and provide that intelligence (data) to any of your existing tools for monitoring, compliance, configuration and maintenance.

Broker - Provides a common interface for various adapters and gives access to a range of data from across the entire network.

Adapters - Allows IAP to integrate and communicate with third-party APIs. You can also create your own adapter in the Itential Platform through Adapter Builder.

Itential Automation Gateway - The Itential Automation Gateway is a standalone application that “sits on top” of Ansible®, an open source platform from Red Hat®, to manage and enhance roles, modules and playbooks.

Itential NSO Manager - The Itential NSO Manager is a standalone application that improves operability with Cisco® Network Services Orchestrator (NSO).

IAP Architecture

Architecture

The tiered architecture of IAP consists of various layers that enable interoperable flexibility and network integration. Integration takes place via REST APIs that reside above the business logic layer. These APIs expose the full functionality contained in the business logic layer to both IAP and third party applications.

Layer Description
Application User interfaces and additional business logic that is not provided by the business logic layer.
Business Business logic that is reusable across applications.
Broker and Adapter Abstractions and integrations with southbound entities. Supplies important core functionality.

Application Directory Structure

IAP applications that include both server-side and client-side code.

The following is an example application directory structure.

Application Directory Structure

Application Layer

The application layer provides client-side user interface code. Each application is loaded as a module into IAP at run-time. In addition to managing user interactions, the application layer ensures user interactions are appropriately applied to the system by making API calls to the business logic layer. An application, and its business logic, are tightly coupled.

The following is an example of the components relevant to this layer.

Application Layer Structure

The following table includes descriptions of directories relevant to this layer.

Directory Description
img Images loaded by the client browser.
scripts Code that is executed by the client browser.
style Client-side styling.
views Client-side view code.

Business Logic Layer

The business logic layer provides re-usable business logic. Each application loaded into IAP adds a business logic module. Every method defined in this layer has a REST API interface allowing a consumer to invoke calls from the user interface, IAP applications like Workflow Engine, or any external third party integration.

Each business logic program uses various brokers and adapters to perform its duties.

Note: Care should be taken to adhere to the standards of a REST API interface when performing business logic design.

The following is an example of the components relevant to this layer.

Business Logic Layer

The following table includes descriptions of files relevant to this layer.

File Description
cog.js Node.js code that executes on the IAP server.
pronghorn.json Exposes server-side JavaScript functions and workflow tasks.

Adapter Layer

The adapter layer allows IAP to communicate with third party APIs. The responsibility of the adapter is to return normalized data objects to IAP based on the results of third party calls. To reference an object-oriented analogy, the adapter represents the class component of the interface-class relationship. Many adapters can support a single broker. For example, adapters for NSO, OpenDaylight, and ONOS can support the device broker.

IAP loads all adapters as modules during startup and before loading the application modules. Each Adapter will contain a minimum of three files.

  • package.json
  • pronghorn.json
  • src.js

Broker Layer

The broker layer provides a common, abstracted interface for related adapters. It fundamentally establishes the set of available function calls to be implemented in adapters. To use an object-oriented analogy, a broker can be thought of as an interface definition of the interface-class relationship. A broker typically has a one-to-many relationship with adapters. Another responsibility of the broker layer is to ensure consistency between data models across various adapters.

IAP currently supports the following brokers.

  • AAA
  • Compliance
  • Device
  • Fault
  • Instance
  • Inventory
  • Method
  • Notification
  • Performance
  • Persistence
  • Service
  • Topology

All broker implementations live in the pronghorn-core/brokers directory. Each broker consists of a minimum of two files.

  • pronghorn.json
  • src.js

The pronghorn.json file is used to define the possible broker calls.

{
  "id": "DeviceBroker",
  "type": "Broker",
  "methods": [
    {
      "name": "locateDevice",
      "summary": "",
      "description": "",
      "input": {},
      "output": {}
    }
  ],
  "encrypted": false
}

The pronghorn.json file may contain configuration for all brokers.

{
    "brokerProps": {
        "device": [
            {
                "id": "Mock Device",
                "type": "MockDevice",
                "properties": {
                    "groups": [
                        "circle, square, triangle"
                    ],
                    "deviceCount": 1
                }
            }
        ]
    }
}

The src.js file provides the broker's implementation.

/* global log */
/* global adapterClasses */
const util = require('util');
const fs = require('fs');
const Discovery = require('@itential/itential-utils/Discovery').Discovery;
const discovery = new Discovery();
const Broker = discovery.require(__dirname + "/../broker.js", pronghornProps.pathProps.encrypted);
var getNamespace = require('continuation-local-storage').getNamespace;
var namespace = getNamespace('itential.pronghorn');

/**
 * Device Broker
 * @constructor
 * @param {object} adapters - Array of adapters used as providers.
 */

const DeviceBroker = function (adapters, model) {
  Broker.apply(this, arguments);
  this.devices = {};
  this.groups = {};
  this.device_map = {};

  adapters.forEach(function (adapter) {
    if (adapterClasses[adapter.type]) {
      this.providers[adapter.id] = new adapterClasses[adapter.type](adapter.id, adapter.properties);
    }
  }, this);
};

util.inherits(DeviceBroker, Broker);

/**
 * Find the host for a given device
 * @memberof DeviceBroker
 * @param device {string} - unique name of the device
 * @param callback {function} - Callback to be called when this function completes
 */
DeviceBroker.prototype.locateDevice = function (device, callback) {
  this.getDevices(function (devices) {
    let location = null;
    devices.forEach(function (element) {
      if (device == element.name) {
        location = element.host;
      }
    }, this);
      callback(location);
  });
}