References
// put in related JIRA tickets and the reference here.
Assumptions
# | Issue | Notes | Decisions |
---|---|---|---|
1 |
Issues & Decisions
# | Issue | Notes | Decisions |
---|---|---|---|
1 |
Overview
// End to end solution in plaintext can be put in here.
- NCMP will receive the Subscription Request from EDM in the form of an Event.
- NCMP will be responsible for the below operations. ( Consumer Code for EDM Event )
- Since NCMP already knows the structure of the incoming subscription request it will map the incoming request to java object.
- Persist the request in the subscription-registry model which we already introduced.
- NCMP ( Producer Code and Record the published time )
- Enrich the request with the additional properties and a proper dmiRequestId ( subscriptionId+subscriptionName+dmiServiceName)
- Save the dmiRequestId in the distributed map along with the current-time. ( we can call it published time ) . This will be useful at a later point in time.
- Now forward the subscription request to the dmi-plugins based on the incoming target cmHandles we have. ( Since we have the information that which dmi-plugin is responsible for which cmHandle , we can figure this out ).
- At this level we could have forwarded the event to multiple dedicated topics.
- DMI-Plugin
- It will have a consumer code to listen from a particular topic.
- It will translate the event so that it is able to extract the important information from the event.
- DMI-Plugin is responsible to talk to the underlying Nodes it is managing inorder to register the subscription ( i.e provide the predicate information ) NOTE : We will skip this part in the onap-dmi-plugin implementation.
- DMI-Plugin will respond back with the response as accepted / rejected. We will have a response format which will be discussed in the dedicated place.
- NCMP ( Consumer for DMI-Plugin Response )
- We should continuously be checking if the published time has elapsed for that subscription response and we don't have to wait before sending the response back to the consumer. ( possibly we can discuss a solution using TTL feature )
- The incoming message will have the dmiRequestId which we can match in the map and check if the timer condition is satisfied ( i.e if the message arrives before the configured time and there are other pending requests , then we wait)
- if we contact multiple dmi plugins and all respond back within time then we collect the response from all of them and send a collective response.
- if we contact multiple dmi plugins and none of them respond back within time then we respond as and when we recieve the response from them.
EDM to NCMP
// Draw architecture diagram
// Show input and output schema
// Any logic if we want to discuss and make decision
NCMP to DMI-Plugins
// Draw architecture diagram
// Show input and output schema
// Any logic if we want to discuss and make decision
DMI-Plugins to NCMP
// Draw architecture diagram
// Show input and output schema
// Any logic if we want to discuss and make decision
NCMP to Client-Apps
// Draw architecture diagram
// Show input and output schema
// Any logic if we want to discuss and make decision