SDN-R provider to access data from database and network for Clients.
APIs are
| API | Description |
|---|---|
| DataProvider RPC | FCAPS function |
| About | Version info |
GetYangSchema | Provide collected yang specs (scheme-cache) |
ReadyServlet | Ready status of SDN-R |
| mediator gateway | |
| read-inventory-tree | Analysis of inventory data. See ODLUX DB API Guilin Extension |
DataProvider RPC
The bundle data-provider is the Web-API for our Database to read, write, update and delete data. The reason for this is the abstraction and exchangeability of the database (currently elasticsearch). Its provided data is specified in the data-provider.yang in the submodule data-provider-model. Each datatype is so called Entity.
Guilin extension: ODLUX DB API Guilin Extension
Entities:
- connectionlog
- faultcurrent
- faultlog
- eventlog
- historicalperformance15min
- historicalperformance24h
- mediator-server
- networkelement-connection
- inventoryequipment
- maintenancemode
- guicutthrough
Guidance for data-provider.yang → onap gerrit ccsdk/features sdnr/wt/data-provider/provider/src/../yang
- each Entity is defined in Entity enum
- enum values which are used in Entities (so not the enum 'Entity' itself) should start with an capital letter, because the serialization of Opendaylight works a little bit different from the basic jackson serialization. Important for camel case filtering
- each Entity definition will also be implemented in parallel as a container to force auto-code-generation of a builder class for this interface for java, e.g.:
container maintenance {
presence "false";
description
"builder";
uses maintenance-entity;
}
- for timestamp values use yang:date-and-time datatype
- add property id to Entity to map the database id into this
- each Entity gets at least a read-{EntityName}-list rpc, e.g.:
rpc read-maintenance-list {
description
"Get list of maintenance entries according to filter";
input {
uses entity-input;
}
output {
container pagination {
uses pagination-output-g;
description
"The pagination details used by the provider to filter the data.";
}
list data {
uses maintenance-entity;
description
"The output data as list of maintenance entities.";
}
}
}
- for a rpc read-{EntityName}-list request the input looks always the same:
grouping entity-input {
list filter {
key "property";
leaf property {
type string;
description
"The property (parameter, column, field) identifier.";
}
leaf filtervalue {
type string;
description
"The filter information for the corresponding property.";
}
description
"List with filter criteria. Not listed means all.";
}
list sortorder {
key "property";
leaf property {
type string;
description
"The property (parameter, column, field) identifier.";
}
leaf sortorder {
type SortOrder;
description
"The definition of the sort order for the corresponding property.";
}
description
"List with sort order. Not listed means default";
}
container pagination {
leaf size {
type uint32 {
range "1..max";
}
default "20";
description
"Number of entries to be delivered";
}
leaf page {
type uint64 {
range "1..max";
}
default "1";
description
"Number to be used to calculate starting entry to deliver";
}
description
"An object defining the pagination details.";
}
description
"An object class defining a request input entity.";
}
- this result into a json e.g. like this:
{
"input":{
"filter":[
{
"property":"node-id",
"filtervalue":"Si*"
}
],
"sortorder":[
{
"property":"node-id",
"sortorder":"ascending"
}
],
"pagination":{
"size":10,
"page":1
}
}
}
The entrypoint for the data-provider is the DataProviderImpl class (org.onap.ccsdk.features.sdnr.wt.dataprovider.impl.DataProviderImpl). Its just handling all the nested services and other provided servlets. The most important part is the DataProviderServiceImpl (org.onap.ccsdk.features.sdnr.wt.dataprovider.impl.DataProviderServiceImpl). This is implementing the Service for the rpc-requests defined by the data-provider.yang so the handler for all our webrequests for the database.