...
| # | Issue | Decision | Notes/Jira | ||||||||
|---|---|---|---|---|---|---|---|---|---|---|---|
| 1 | What topic to use for client? | To be supplied by cient | Topic provided by client as a parameter which will be injected into our environment and used for asynchronous requests sent back to client. | ||||||||
| 2 | What topic to use for private DMI-NCMP? | e.g. ncmp-async-private but decision needs to be made with current best practices. | |||||||||
| 3 | Are adding a new REST endpoint for async or modifying an existing endpoint? | /ncmp/v1/data/ch/123ee5/ds/ncmp-datastore:*?topic=<topic-name> | Agreed To facilitate asynchronous requests to DMI we will need to either create a new endpoint or modify existing endpoint to include /async flag. The second solution may not be backwards compatible. However creating a new endpoint solely for a flag is also not ideal. We could add async to list of options (but this might interfere with the purpose of /options. Additionally, considered adding a new endpoint for async which simply re-routes the response to the original endpoint while adding the logic for OK response to the client. However, would this lead to a change in the schema? If so, would this be backwards compatible?
| ||||||||
| 4 | Agree URL for async once #2 is clarified | /ncmp/v1/data/ch/123ee5/ds/ncmp-datastore:*?topic=<topic-name> | CPS R10 Release Planning#NCMPRequirements #11. Based on this additional path parameter we no longer require additional /async flag in url. | ||||||||
| 5 | Passthrough request need to be able to handle different response types (using accept header) but the async option would have a fixed and possibly different response type. | We should, by default, be able to accept multiple contnet-types. | CPS R10 Release Planning#NCMPRequirements #11. | ||||||||
| 6 | Should we create a standalone app to demo or are tests sufficient? | Yes, standalone app would be helpful, along with traditional tests. | CSIT tests may require more involved effort - perhaps we could add standalone app to nexus and use it as part of CSIT test? | ||||||||
| 7 | Do we need to persist the generated requestID? | No | We should be be stateless | ||||||||
| 8 | What mechanism should we use for the payload? Event?, Header?, | This needs clarification | |||||||||
| 9 | Error Reporting | Out of scope | |||||||||
| 10 | CSIT Testing | Will this be required to add to CSIT tests? If so, client app will need to be created and stored in gerrit for cloning during setup phase. |
Proposed Diagram
...
| draw.io Diagram | ||||||||||||||||||||||
|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|
|
Rest Endpoint with Async Flage
To facilitate asynchronous requests to DMI we will need to either create a new endpoint or modify existing endpoints to in /async flag. See Issues/Decisions.
...
<ncmp>/v1/ch/PNFDemo/data/ds/ncmp-datastore:passthrough-running?resourceIdentifier=stores:bookstore
|
...
Kafka config & Implementation
...
| Code Block | ||||||
|---|---|---|---|---|---|---|
| ||||||
kafka:
image: confluentinc/cp-kafka:6.1.1
container_name: kafka
ports:
- "19092:19092"
depends_on:
- zookeeper
environment:
KAFKA_BROKER_ID: 1
KAFKA_ZOOKEEPER_CONNECT: zookeeper:2181
KAFKA_ADVERTISED_LISTENERS: PLAINTEXT://kafka:9092,CONNECTIONS_FROM_HOST://localhost:19092
KAFKA_LISTENER_SECURITY_PROTOCOL_MAP: PLAINTEXT:PLAINTEXT,CONNECTIONS_FROM_HOST:PLAINTEXT
KAFKA_OFFSETS_TOPIC_REPLICATION_FACTOR: 1 |
Response types for Passthrough
Will we be able to handle everything "as-is"?
TODO: Clarify what the response type will be e.g. Object, String, JSON
Future (or alternative)
...
What are Futures?
...
| Jira | ||||||
|---|---|---|---|---|---|---|
|
To facilitate demo and testing of this functionality a new standalone app will be required to act as client.