View Source

SDN-R provider to access data from database and network for Clients.

APIs are

API	URL	Description
DataProvider RPC	/rest	FCAPS function
About	/about	Version info (format in Markdown, rendered by aboutPage in ODLUX)
GetYangSchema	/yang-schema	Provide collected yang specs (scheme-cache) Yang Download Service
ReadyServlet	/ready	Ready status of SDN-R GET /ready
mediator gateway	/ms	Proxy function to manage a Mediator Gateway
read-inventory-tree	/tree	Get device Inventory data from database ODLUX DB API Guilin Extension Istanbul data-provider improvements
userdata	/userdata	See: ODLUX DB API Extension for Userdata

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.

Entities:

connectionlog
faultcurrent
faultlog
eventlog
historicalperformance15min
historicalperformance24h
mediator-server
networkelement-connection
inventoryequipment
maintenancemode
guicutthrough (Move GUI cut through into server)

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.

Ready Service

GET /ready

response	description
200	no bundle in failure state, everything up and running
!200	at least one bundle is in failure state or not all bundles are in Active or Resolved state

Mediator Gateway Service

Reverse proxy functionality which forwards e.g.

GET /ms/{ms-server-db-id}/api/?task=getconfig

to

{mediator-server-url}/api/?task=getconfig

and forwards response from the server.