...
| Jira |
|---|
| server | ONAP Jira |
|---|
| columnIds | issuekey,summary,issuetype,created,updated,duedate,assignee,reporter,priority,status,resolution |
|---|
| columns | key,summary,type,created,updated,due,assignee,reporter,priority,status,resolution |
|---|
| maximumIssues | 20 |
|---|
| jqlQuery | key = CPS-828 |
|---|
| serverId | 425b2b0a-557c-3c0c-b515-579789cceedb |
|---|
|
Issues/Decisions
...
| # | Issue | Decision | Notes/Jira |
|---|
| 1 | What topic to use |
? proposed ncmp-async-xxxTopic provide by client?! | | 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? | ncmp-async-private |
|
| 3 |
2 | 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? | Jira |
|---|
| server | ONAP Jira |
|---|
| serverId | 425b2b0a-557c-3c0c-b515-579789cceedb |
|---|
| key |
|---|
|
|
|
| 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 |
CPS-830 | 3 | Agree URL for async once #2 is clarified | 4 | 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. |
5 | How many messages are we expecting at peak time?| 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? |
8 | | No | We should be be stateless |
Will cps-temporal require the requestID?
Proposed Diagram
...
| draw.io Diagram |
|---|
| border | true |
|---|
| |
|---|
| diagramName | CPS-821 |
|---|
| simpleViewer | false |
|---|
| width | |
|---|
| links | auto |
|---|
| tbstyle | top |
|---|
| lbox | true |
|---|
| diagramWidth | 7711211 |
|---|
| revision | 56 |
|---|
|
Rest Endpoint with Async Flag
...
| Code Block |
|---|
| language | java |
|---|
| title | Thread Example |
|---|
| collapse | true |
|---|
|
int number = 20;
Thread newThread = new Thread(() -> {
System.out.println("Factorial of " + number + " is: " + factorial(number));
});
newThread.start(); |
| # | Type | Pros | Cons | Recommend |
|---|
| 1 | Future | Futures return value |
| Y |
| 2 | Thread |
| threads does not return anything as the run() method returns void. We could possibly implement mechanism to trigger a response but this is unnecessary as futures do this | N |
RequestID Generation
...
| Type | Method | Ease of implementation | Recommend |
|---|
| UUID | String uniqueID = UUID.randomUUID().toString();
| Easy | Y |
| Custom | We generate our own | Medium - Hard | N |
| HTTP Request ID |
|
|
|
Async Request Option using Messaging
...
