...
# | Assumption | Notes |
---|---|---|
1 | "fields" and "scope" are proprietary options or not in the scope of this analysis. | |
2 |
The Big(ger) Picture
Gliffy Diagram | ||||||||
---|---|---|---|---|---|---|---|---|
|
Issues & Decisions
# | Issue | Notes | Decision |
---|---|---|---|
1 | Which operation(s) need support for multiple cm handles? |
if many what is the priority? | |
2 | Do we need to use same xpath (resourceIdentifierInQuery) for all cm handles or different for each cm handle ? | ||
3 | Which datasources ? | Do we need to support passthrough-only no-cached() data only ? or, alternatively, support operational/running (cached) data too ? | |
4 | 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 similar as single cm handle interface (consistency and cost) Existing : ...&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 ?
|
...