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

APIs are

APIURLDescription
DataProvider RPC/restFCAPS function
About/aboutVersion info (format in Markdown, rendered by aboutPage in ODLUX)

GetYangSchema

/yang-schemaProvide collected yang specs (scheme-cache) Yang Download Service

ReadyServlet

/ready

Ready status of SDN-R

GET /ready

mediator gateway/msProxy function to manage a Mediator Gateway
read-inventory-tree/tree

Get device Inventory data from database

userdata/userdataSee: 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

responsedescription
200no bundle in failure state, everything up and running
!200at 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.

  • No labels