DataMiner now natively supports OpenConfig

Did you know that as of version 10.3.3 DataMiner natively supports OpenConfig, a vendor-neutral and open standard for network configuration and telemetry? This means that you can have quick and easy access to a flexible and efficient network management solution that empowers you to optimize your network operations and improve overall network performance.

In this blog post, we will explain how we integrate OpenConfig support in our connectors and how this differs from the traditional approaches.

Different connector architecture

If you’re familiar with our connector architecture, you may know that they are XML-based definitions that describe how to communicate with a data source and how to map the data to parameters. We support different types of connectors, such as SNMP or HTTP, in the XML schema with specific tags or attributes. The device communication logic is handled by processes like SLSNMPManager and SLPort respectively.

However, for OpenConfig we have taken a different approach. Instead of modifying the XML schema and extending the existing processes, we have introduced the DataMiner Extension Module (DxM) CommunicationGateway that will handle the communication with an OpenConfig data source.

The DxM hosts the “gRPC client”, which is the protocol used by OpenConfig to exchange data between devices and controllers. The DxM also implements the logic to authenticate with the device, subscribe to data streams, parse the data according to the YANG models, and send it back to the connector.

So, the connector remains an XML-based definition but it no longer contains any device-specific logic. Instead, it relies on QActions to interact with the DxM. The QAction needs to find an available DxM, connect to it, request the data from the device by referring to paths in a YANG model, and store the incoming values in the connector’s parameters.

Visual representation of the new connector architecture

Easy to use thanks to communication middleware

Although this new architecture may seem more complex, we have streamlined its usability by integrating a communication middleware with a DataMapper that handles most of the hard and repetitive work.

This middleware is provided as a NuGet package that you can reference in your QActions. The NuGet package contains classes and methods that abstract away the details of the DxM communication and the YANG model parsing, allowing you to focus on your connector’s specific business logic.

Benefits of the OpenConfig connector architecture

This architecture has several advantages over the traditional approaches:

• It decouples the connector definition from the device communication logic, making it easier to maintain and update.
• It allows us to leverage existing libraries and frameworks that are widely used and supported by the industry, such as gRPC and YANG.
• It enables us to reuse the same DxM for multiple connectors that share the same data source type, reducing resource consumption and improving performance.