You are viewing an old version of this page. View the current version.

Compare with Current View Page History

« Previous Version 28 Next »

Introduction

Although the PoC will only implement a few of the possible Java API methods it is important to have a good detailed view of the structure and naming of this interface going forward and document it.

Acceptance Criteria for Proposed Java Interface:

  1. Should follow ONAP or wider best practice
  2. Documented on ONAP Wiki
  3. Discussed and agreed within CPS Team
  4. Discussed and agreed with wider community


Currently we are considering 3 'separated' Java APIs or 'groups' of methods:

  1. Models (add, list)
  2. Data (CRUD)
  3. Queries

Jira Ticket:

CCSDK-2871 - Getting issue details... STATUS

Jira Backlog:

https://jira.onap.org/secure/RapidBoard.jspa?rapidView=223&view=planning.nodetail&selectedIssue=CCSDK-2912&issueLimit=100


External Resources

https://wiki.onap.org/display/DW/Data+Representation

https://wiki.onap.org/display/DW/Interface+style


Open Issues/Decisions

#

Description

Details

Decisions

1Should the java interface take in one (JSON) objects(like REST interface) or a few individual fields in a signature? 

Mapping the request body to an object


2Input streams or files?Toine has a preference for input stream.Use input stream.
3

API uses (generated) ID's or customer provided names
If names are used should we return IDs at all?

Using ID would mean client has to get/cache ID's all the time.

Maybe the Java API should use names like the REST API does.

anchors & nodes - may need ID


Create methods should return the objects created.

Should throw an exception if it already exists.


All ID's generated should be in the response.

If we return it we also need methods to use the ID.

If we update the java API to use ID, we should also update the rest API.


Create methods will be void.

Create methods could return false if already exists.


4Should a user be able to update/override/delete a dataspace, module, module set? (of the same revision)Business logic to check on create if it already exists. If it exists we do not create it.

CPS provides the following interfaces:

Interface Name

Interface Definition

 Interface Capabilities

Consumed Models

Model InterfaceBehavior interface that represents cps modules.
  1. Create a module set
  2. Add modules to a module set
  3. Read all modules
  4. Validate modules
  5. Upgrade a module set (individual module upgrade)
  6. Create a module set and validate it against a module reference (using a separate SPI)
Yang models that are broken into fragments.
Data Interface

Behavior interface that represents CPS data.

  1. Create a node under an anchor.
  2. Delete a dataspace
  3. Create a dataspace
  4. Create an anchor
  5. Read an anchor of a particular node
  6. Read an anchor in a namespace and dataspace
  7. Read all anchors for one dataspace
  8. Delete an anchor for a namespace in a dataspace
  9. Associate an anchor to a module set
  10. Associate an dataspace to a anchor
  11. Read all dataspaces
  12. Create a node under another node.
  13. Associate an a node to a anchor

Query InterfaceProvides the capability to query CPS data using XPaths.
  1. Read the parent of a node that matches an xpath expression
  2. Read all nodes under an anchor point
  3. Read the anchor of a node
  4. Read all nodes that match a schema node identifier

Query Builder InterfaceProvides the capability to query CPS data using restrictions from a query builder (see open issue 1).


  • No labels