...
| # | 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> | 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. | |||||||||
| 11 | Async Request Option using Messaging | Out of scope | See: AsyncRequestOptionusingMessaging |
Proposed Diagram
...
| draw.io Diagram | ||||||||||||||||||
|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|
|
...
| Type | Method | Ease of implementation | Recommend |
|---|---|---|---|
| UUID | | Easy | Y |
| Custom | We generate our own | Medium - Hard | N |
| HTTP Request ID |
Async Request Option using Messaging
...
(Out of Scope)
...
This was for a future completely message driven solution (for now we start with a REST request that will generate an async message eventually. In future we could also send a message that will trigger the same.TODO: Clarify what is intended in this section
Demo/Test
...
Existing Groovy tests exist for Kafka in cps-service/src/test/groovy/org/onap/cps/notification
...