Page History

...

1. NCMP will receive the Subscription Request from EDM in the form of an Event.
2. NCMP will be responsible for the below operations. ( Consumer Code for EDM Event )
   1. Since NCMP already knows the structure of the incoming subscription request it will map the incoming request to java object.
   2. Persist the request in the subscription-registry model which we already introduced.
3. NCMP ( Producer Code and Record the published time ) 
   1. Enrich the request with the additional properties and a proper dmiRequestId ( subscriptionId+subscriptionName+dmiServiceName)
   2. 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.
   3. 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 ).
      1. At this level we could have forwarded the event to multiple dedicated topics.
4. DMI-Plugin
   1. It will have a consumer code to listen from a particular topic.
   2. It will translate the event so that it is able to extract the important information from the event.
   3. 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.
   4. 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.
5. NCMP ( Consumer for DMI-Plugin Response ) 
   1. 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 ) 
   2.  . . /. TBC

EDM to NCMP

// Draw architecture diagram

...