What are the components of an intent type?
Intent type components
An intent type provides the logic for the creation of an intent, and for the execution of that intent. When a user creates an intent from the intent type, a Create Intent form launches requesting the required inputs. The YANG model, Target, and View components define the form. The Script and Resources components provide the logic required to realize the intent.
For detailed information about intent type design, see the intent types tutorial on the Network Developer Portal.
An intent type consists of the following components. The components appear as tabs in the Create and Edit forms.
GENERAL
The GENERAL tab includes the following panels.
General
The General panel shows the basic information about the intent type, for example, the name, version, labels and lifecycle state.
The Mapping Engine indicates the JavaScript engine used to create the intent type.
The Labels field lists the labels applied to the intent type. Labels are used to filter and group intent types. An intent type can have one or multiple labels.
If an intent type is compliant with a set of format requirements, such as Service Management, a label must be used to indicate what the intent type is configured for. For example, for an intent type to be imported by Service Management, it must have a ServiceFulfillment label.
The Live state retrieval check box dictates whether intent state attributes will be updated in the intent details on demand or when the intent is synchronized. Enable the check box to update state attributes on demand.
The Composite check box indicates a composite intent type.
The Build field displays the build number of the intent type from the intent type code. For Nokia-created intent types, the format is release_x.y.z where the numbers x.y.z are used for version control. The x number is the Version parameter in NSP. For example, if you install an intent type with the build number 22.9_2.1.1, the intent type version will be 2, regardless of whether you have a version 1 in your system.
Policy
The Policy panel indicates the priority of the intent type and the targeted device. Policy configuration in the intent type helps NSP administer mass operations correctly.
The priority is used by NSP to determine the order of execution. An intent belonging to an intent type with a smaller priority number is executed by NSP before an intent belonging to an intent type with a bigger priority number. Setting the priority can ensure, for example, that port configurations are performed before the configuration of services that will require the ports.
The targeted device is used to allocate jobs so that only one job is executed at one time per device. This prevents delays and job timeouts due to a job attempting to run on a resource that is blocked by another job.
The targeted device is defined in JSON format using intent-type, targets, yang, inherit, and function names.
It can be defined in the following ways:
-
target component of the current intent:
"targetted-device": [ {
"target-component": "device-name"
}]
-
target component of a dependent intent:
"targetted-device": [ {
"intent-type": "l2-infra", (empty or omitted indicates this intent type)
"target-component": "device-name"
}]
-
leaf of the YANG of the current intent:
"targetted-device": [ {
"intent-type": "l2-infra", (empty or omitted indicates this intent type)
"yang": "fiber:fiber/pon-port/device-name"
}]
-
same devices as a dependent intent:
"targetted-device": [ {
"inherit": "true",
"intent-type": "device-fx"
}]
-
in special cases, we can use special logic in JavaScript:
"targetted-device": [ {
"function": "getTargettedDevices"
}]
Migration
The Migration panel is displayed for intent types with a version number greater than 1. The migration table shows the configured migration and rollback paths between versions of the intent type.
TARGET
The target attribute of the intent type is used to uniquely identify any intent created from the intent type. The definition must be in JSON format.
The target attribute is made up of one or more target components.
All attributes are optional: the only requirement is that the intent is uniquely defined.
When an intent is created, the target components are displayed as input fields in the intent creation dialog. NSP uses the user inputs to create the target value.
The following table describes the target attributes.
The following sample shows the structure of a target component definition.
Sample target
The following sample creates a target component:
{
"target-component": [
{
"i18n-text": "Service Name",
"name": "service-name",
"pattern": "[A-Za-z0-9_]{1,}",
"value-type": "STRING",
"order": 1
}
]
}
You can include more than one target component, if needed. The target value separates the two components with a hash; for example, service#port.
The sample target component is displayed in the form as shown in Figure 4-1, Form with Sample target and Sample YANG. The user input becomes the target attribute.
YANG
The YANG panel provides an abstraction for the instance of the intent type.
The following types of arguments are supported:
-
Configuration arguments: attributes where the user needs to provide a value
-
State arguments: attributes where the intent type reports relevant state information
The YANG model must extend the Nokia IBN YANG definition. The arguments must use the ibn:configuration container.
SCRIPT
The SCRIPT tab contains the realization logic of the intent type. This tab contains the programming required for the intent configuration to be performed.
The script contains an intentObject and needs to implement some predefined functions. When a user triggers an action, the predefined functions are called by the framework to fulfill the task. These methods have implementation specific to an Intent type.
The following functions are optional.
-
Validate runs at the time an intent is synchronized, either at or after intent creation. If the intent input fails the validation condition, the intent cannot be synchronized.
-
Reconcile is the opposite of a synchronize function. It will pull the configuration from the associated object and update the intent configurations to match it.
Script engines
NSP uses the Nashorn JavaScript engine by default. The GraalJS JavaScript engine is also available.
GraalJS supports some ECMAScript features and capabilities that are not available with Nashorn. For more details, see the Network Intents information on the NSP Developer Portal.
Sample script
The following sample shows a basic script structure.
var RuntimeException = Java.type('java.lang.RuntimeException');var prefixToNsMap = {"ibn" : "http://www.nokia.com/management-solutions/ibn",
"nc" : "urn:ietf:params:xml:ns:netconf:base:1.0",
"device-manager" : "http://www.nokia.com/management-solutions/anv",
};
var nsToModule = {"http://www.nokia.com/management-solutions/anv-device-holders" : "anv-device-holders"
};
function synchronize(input) {var target = input.getTarget();
var config = input.getIntentConfiguration();
var topology = input.getCurrentTopology();
//Retrieve the network state, it exists in the input argument.
var networkState = input.getNetworkState().name();
var customNetworkState = input.getCustomRequiredNetworkState();
logger.info("######### NETWORK STATE "+ networkState);//If the network state is 'custom' then we must look in the customRequiredNetworkState property to get the actual state
if(networkState === 'custom'){ logger.info("######### CUSTOM NETWORK STATE "+ customNetworkState);result.setSuccess(true);
return result;
}
function audit(input) {var report = auditFactory.createAuditReport(null, null);
// Code to audit goes here
return report
}
function validate(syncInput) { var contextualErrorJsonObj = {};var intentConfig = syncInput.getJsonIntentConfiguration();
// Code to validation here. Add errors to contextualErrorJsonObj.
// contextualErrorJsonObj["attribute"] = "Attribute must be set";
if (Object.keys(contextualErrorJsonObj).length !== 0) {utilityService.throwContextErrorException(contextualErrorJsonObj);
}
}
/*
RECONCILE
The return object that is expected from a reconcile is ReconcileOutput
ReconcileOutput POJO defined like below
updatedIntentConfiguration - filled when the intent configuration can be adapted
updatedStateXML - filled when the Intent State can be adapted
alignmentState - filled if intent needs to be aligned state after reconcile
updateDependents - whether dependent intents to be updated
syncDependents - whether dependent intents to be synched
topology - filled if there is change in Topology / Intent Dependency , XtraInfo
*/
function reconcile (input){var reconcileOutput;
var topologyXtraInfo = null;
var topologyXtraInfo = null;
var target = input.getTarget();
var topology = input.getCurrentTopology();
var targettedDevice = input.getTargettedDevices();
var networkState = input.getNetworkState();
var customRNS = input.getCustomRequiredNetworkState();
var intentConfigXml = input.getIntentConfiguration();
//Here we are changing the configuration
var testStringNode = intentConfigXml.getElementsByTagName("test-string").item(0); if(testStringNode.getTextContent() == 'reconcile'){ testStringNode.setTextContent("reconcile");}
var updatedConfig = domUtils.documentToString(intentConfigXml);
if (networkState == "delete") { logger.info("Reconcile intent with input networkState {}", networkState); throw new RuntimeException("Reconcile with required-network-state as 'delete' is not possible");}
if (networkState == "suspend") { logger.info("Reconcile intent with input networkState {}", networkState);return new ReconcileOutput(null, null, "false", false, false, null);
}
//Return for reconcile
return new ReconcileOutput(updatedConfig, null, "true", false, false, null);
}
RESOURCES
The RESOURCES tab shows the list of resource files required to realize the intent. The resources are a library of files that the intent type can access.
Different intent types that target similar system configurations often use similar logic. The use of resource files allows the common logic pieces to be stored as framework and mapping files, and loaded when the intent runs.
The resource files can be in various formats, for example, YANG, JavaScript, or JSON.
The GraalJS script engine supports folders in the Resources library.
To configure resource libraries, click 
More, Resource Management at the top of any view in the Network Intents path.
For detailed information about resource file creation, see the Network Intents tutorial on the Network Developer Portal.
FORM
The FORM tab shows how the Create Intent dialog is displayed when the user creates an intent. NSP implements a schema file to generate and preview the form. Choose a schema form in the Schemas drop-down to preview the form implemented by the schema form selected.
Intent types that are instantiated within Network Intents use the default schema form. Other schema forms, created from viewConfig files, may be available for intent types used by other applications.
Figure 4-1: Form with Sample target and Sample YANG
VIEWS
The VIEWS tab shows the list of view files available to the intent type. View files are used to augment the YANG to create the input form the user will see when creating an intent, or when using intent-based configuration in another application.
Nokia-signed intent types, which are installed using Artifacts, cannot be edited except to add, delete or modify view files.
The list of files includes:
-
viewConfig files: a viewConfig file defines the changes to make to the attributes in the intent type YANG to define the fields that will appear in the input form and their properties. For example, if the YANG declares that the intent creation form will contain two string fields, a viewConfig file can provide names for the fields.
The NSP creates a default viewConfig file based on the YANG. A developer can make changes to the default or configure additional viewConfig files.
-
schema forms: the schema form is automatically generated from the viewConfig file. NSP implements the schema form to create the input form.
-
view.settings files: the view.settings file is automatically generated. It provides a link to the module and container defined in the intent type YANG to identify the YANG entry point.
For detailed information about View file configuration, see the ViewConfig section of the Network Intents tutorial on the Network Developer Portal.
Parent and child viewConfig files
A viewConfig file can be attached to another as a child. The child file inherits all the attributes and rules configured in the parent file.
The child file can add attributes or overwrite attribute values and rules.
For example:
-
The parent file augments one attribute: attr1. The title of attr1 is set to Parent.
-
The child file augments two attributes: attr1 and attr2. The title of attr1 is set to child and attr2 is set to child2.
On the FORM panel, if you choose the parent schema form, one attribute is changed. The title is Parent. If you choose the child schema form, two attributes are changed. The titles are child and child2.