Versions Compared

Key

  • This line was added.
  • This line was removed.
  • Formatting was changed.

...

  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.  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)
      1. 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.
      2. 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. 
       . . /. TBC

EDM to NCMP

// Draw architecture diagram

...