...
<optional, assumptions are like decision made up front ie. everyone agrees on the answer but they are important to mention>
# | Assumption | Notes |
---|---|---|
1 | "fields" and "scope" are propriotary options or not in the scope of this anylysis. | |
2 |
Issues & Decisions
# | Issue | Notes | Decision |
---|---|---|---|
1 | Which operation(s) need support for multiple cm handles? |
if many what is the priority? | |
1 | Do we need to use same xpath (resourceIdentifierInQuery) for all cm handles or different for each cm handle ? | ||
2 | Which datasources ? | Do we need to support passthrough-only no-cached() data only ? or, alternatively, support operational/running (cached) data too ? | |
Endpoint url patterns? | Existing : /v1/ch/{cm-handle}/data/ds/{datastore-name} CPS Propossed : /v1/batch/data/ds/{datastore-name} ( include cm handles into payload / body and leave datastore into url) | ||
keep datastore, topic and optional parameters in the URL itself instead into body. | CPS prefers keep interface similaral as single cm handle interface (consistency and cost)&topic=topicParamInQuery | ||
3 | Impacts on DMI Plugin Interfaces
| ||
4 | How we are supporting multiple anchors into CPS-Core ?
| ||
5 | Response always Async ie. topic is compulsory ?
|
<Note. use green for closed issues, yellow for important ones if needed>
...
Implementation :
# | Steps | Notes | Decision |
---|---|---|---|
1 | Define new get operation "getResourceDataForCmHandles" into ncmp.yml | ||
2 | Implement org.onap.cps.ncmp.rest.controller.NetworkCmProxyController#getResourceDataForCmHandles with params below : final String datastoreName, | ||
3 | Impacts on DMI Plugin Interfaces
| ||
4 | How we are supporting multiple anchors into CPS-Core ?
| ||
5 | Response always Async ie. topic is compulsory ?
|
< we do not want to dictate the remainder of an analysis it will depend on the type of user story at hand>
...
Note : Overlap with Deutsche Telecom (check with Lee Anjella Macabuhay there is no overlap)