Page History

...

• Datetime 

  • Data in last X hours 
  • Data after a particular DateTime Data before a particular DateTime ( To be supported in version 1)
  • Data between a date range
  • Last X network data
• DataTypes in CPS Core

  • Dataspace & schema-setset ( To be supported in version 1)

  • Dataspace & anchoranchor ( To be supported in version 1)
  • Dataspace & multiple anchors - To improve performance, if there is a need to fetch data for multiple anchors.
  • Dataspace
• Payload ( To be supported in version 1)
  Payload

  • Based on a field or subsection

    or field

    in the payload, the entire path from the root must be provided. These criteria

    do

    need schema-set to be fixed to search in the same set of anchors. The details of the format is defined later. 

  We will implement only the basic APIs first and will add complex ones when required. 

  ...

  • Temporal database stores full information in the payload ( CPS-192: Design data store for Temporal Service). 
  • It is possible that data stored for the different timestamps is the same, especially if the payload is used to filter data.
  • Data in the response body will always contain the entire payload data.
  • If the payload is passed as XPath, it is not expected to support all cps-path query and XPath functionalities. 

  Proposed APIs

  ...

  Return data entries for an anchor after the specified Datetime, which matches the payload format.

  ...

  Return data entries based on provided schema-set after the specified Datetime, which matches the payload format.

  Approach 1 - GET

  In the GET APIs, all the filtering parameters are passed as query parameter. 

  The payload can be passed as JSON or XPath. But, XPath is more concise and more readable than JSON when passed as a query parameter. 

  ...

  Payload Filter Format

  The filter can be provided on any field at any level, but it is important to provide the entire path from the root. The below mention JSON is used as an example to explain the filtering format

  Code Block
  collapse true
  { "idNearRTRIC": "1", "labels" : [ "cps", "ran"], "nestedObject": { "id": "4", " "attributes": { "gNBDUId": 4.0, "gNBDUName": "gnduserver4", "gNBIdLength": 32.0 } }, "GNBDUFunction": [ { "idGNBDUFunction": "5", "NRCellDU": [ { "idNRCellDU": "13905", "attributes": { "nRPCI": 12.0, "nRTAC": 310.0, "cellLocalId": 13905.0 } }, { "idNRCellDU": "14655", "attributes": { "nRPCI": 12.0, "nRTAC": 310.0, "cellLocalId": 14655.0 } } ], "attributes": { "gNBDUId": 5.0, "gNBDUName": "gnduserver5", "gNBIdLength": 32.0 } } ] }

  The filtering scenarios and the format to be used for each is defined below:

  No	Type of field	To be search	Format
  1	Top-level field	idNearRTRIC
  2	The field inside another object	nestedObject → id
  3	String collection field at the top level	labels
  4	Field inside a collection	GNBDUFunction → idGNBDUFunction

  Proposed APIs

  Currently, we are not supporting all the filtering criteria defined in the overview. The below list defined the query parameters which can be used for all the endpoints.

  Data by Anchor Name

  URL: GET /dataspaces/{dataspace-name}​/anchors/{anchor-name}​

  Example: GET /dataspaces/{dataspace-name}​/anchors/{anchor-name}​?after=2021-03-21T00:00:00-0:00&

  ...

  payload=/device/port/interface[

  ...

  status=up and type=type1]&maxSize=500

  ...

  Supported Query Parameter apart from other parameter

  1. after - timestamp ( ISO Format) to consider date created after the specified Timestamp
  2. payload - to define data filtering criteria

  Date by Dataspace and Schema-set

  URL: ​GET /dataspaces/{dataspace-name}/schema-sets/{schema-set}

  Supported Query Parameter apart from other parameter

  1. after - timestamp ( ISO Format) to consider date created after the specified Timestamp
  2. payload - to define data filtering criteria

  Example: GET

  ...

  /dataspaces/{dataspace-name}/schema-sets/{schema-set}?after=2021-03-21T00:00:00-0:00

  No	Purpose
  1	Return data entries for an anchor after the specified Datetime, which matches the payload format.
  2	Return

  Return all the

  data entries based on provided schema-

  set after

  set after the specified

  epoch in nanoseconds

  Datetime, which matches the payload format.

  Response Body

  name	type
  nextRecordsLink	string	added only if there are remaining records to be fetched for the query.
  previousRecordsLink	string	added only if it is not the first set of records.
  records	list	contains one record for each timestamp that meets filtering criteria. It contains header information along with data.

  ...

  Code Block

  { "nextRecordsLink": "cps-temporal/api/v1/dataspaces/{dataspace-name}/anchors/{anchor-name}?after=2021-03-21T00:00:00-0:00&maxSize=500&pointInTime=2021-04-21T00:00:00-0:00&index=2", "previousRecordsLink": "cps-temporal/api/v1/dataspaces/{dataspace-name}/anchors/{anchor-name}?after=2021-03-21T00:00:00-0:00&maxSize=500&pointInTime=2021-04-21T00:00:00-0:00&index=0", "records": [ { "timestamp": "1234567788889", // TODO change the format "dataspace": "my-dataspace", "schemaSet": "my-schema-set", "anchor": "my-anchor", "data": { "status" : "UP" } } ] }

  ...

  • Provides the ability to cache data based on URL. It is not relevant as data can change based on when the API is called. 
  • Can provide links for the next record and previous record link in the response itself.
  • pointInTime can have the current timestamp as the default value because we can add it in the next record and previous record link as a part of the response.

  ...

  • If the payload filter condition becomes longer, it will not fit within the GET URL length limit. - TODO mention it somewhere ( Assumptions / Limitations / ? )

  Questions

  1. Should we disable caching or ask the user to pass the pointInTime parameter value?

  Approach 2 - POST

  As we are query data, POST is not intuitive but the search can be considered as a resource with different filtering criteria. We need only one API as the filtering criteria will be provided in the body, which allows the payload to be big if required.

  API URL: cps-temporal/api/v1/filters?maxSize=1000&index=1 

  Request Body

  Code Block
  { "dataspaceName": "dataspace-001", "anchorName": "anchor-001", "schemaSetName": "schemaset-001", "after" : "2021-03-21T00:00:00-0:00", "pointInTime": "2021-04-21T00:00:00-0:00", // mandatory "payload": { "status": "UP" } }

   Response Body

  Code Block
  [ { "timestamp": "1234567788889", "dataspace": "my-dataspace", "schemaSet": "my-schema-set", "anchor": "my-anchor", "data": { "status": "UP" } } ]

  Pros:

  • The payload can be big and we will still be able to support it.

  Cons

  ...

  1.  

  Open Items