Versions Compared

Old Version 10

changes.mady.by.user Halil Cakal

Saved on

compared with

New Version Current

changes.mady.by.user Halil Cakal

Saved on

Key

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

...


Subscription Creation Events Handling

Assumptions

#AssumptionNotes
1Forwarded Subscription Event
communicates asynchronously.  (NCMP to DMI Plugins)  Thus, it is not required to wait for a single request to be responded. For example, NCMP has not to wait a response when Forwarded Subscription Event has been published into a topic, e.g. RequestXXX.2Forwarded Subscription Event Responses communicates
Responses communicate asynchronously.  (from DMI Plugins to NCMP) 

It is the same as above note. The Forwarded Subscription Event Responses published into a different topic, e.g. ResponseXXX.

3The NCMP component need to keep the Request ID that is belong to each Kafka message and the timestamp when the message is published into RequestXXX topic. 4


2
The NCMP component should
consume messages periodically from ResponseXXX topic, and create Subscription Create Outcome message. 5The NCMP component should publish Subscription Create Outcome message into another topic in which
create a Subscription Event Outcome message and publish it into the topic (cm-avc-subscription-response) for Client Apps consumed from
.

Issues & Decisions

Topic Names (TBD)
#IssueNotes Decision
1Possible

Toine Siebelink , Luke Gleeson , Sourabh Sourabh  and Lee Anjella Macabuhay  

'timeframe' period for timeoutNCMP to Client Apps response timeout

30 sec.

2Response in a single step (as of now)from DMI to NCMP responses

Is the ACK would be required? No

DMI-Plugin would publish actual response to NCMP

3Response schema should be decided

from DMI to NCMP response schemas should be decided for single step response

Should DMI Plugins detail cm-hande IDs in response? Yes

Accept or Decline


4Subscription event outcome schema should be decided

from DMI to Client Apps

  • Possible options for initial response and further updates
     
    1. Status only: COMPLETED / PARTIALLY_COMPLETED
    2. List of accepted CM Handle IDs
    3. List of declined CM Handle IDs

We include : 

  1. Status only: COMPLETED / PARTIALLY_COMPLETED
  2. List of accepted CM Handle IDs
  3. List of declined CM Handle IDs

Note : Avoid for wild card * (for all cm handles)

2Possible 'timeframe' period to consume Forwarded Subscription Create Event ResponsesTBD for timeframe

Possible Topic Names

1Forwarded DMI Plugins2 ResponseNCMP3 Outcome
#SourceDestinationContentTopic NameDestination
1Client AppsNCMPSubscription Create EventTBD (cm-avc-subscription-forwarded)
2NCMPDMI Plugins

Forwarded Subscription Create Event

ncmp-dmi-

TBD (

cm-avc-subscription-{DMI-DATA-

forwarded

SERVICE-

response)

NAME}


3DMI PluginsNCMPForwarded Subscription Create Event Responsedmi-ncmp-TBD (cm-avc-subscription-outcome-response)Client Apps

Implementation Details

  1. The NCMP component could utilize a Hash Map to store request_id and timestamp the time that message is published into the topic mentioned in #1 → Possible Topic Names
  2. In order to calculate the Subscription Create Outcome Message, the NCMP component should consume response messages from the topic mentioned in #2 → Possible Topic Names
    The NCMP component should consume messages as per the timeframe periods, and compare request ids with the ones that already kept in that Hash Map at step 1.
  3. If the incoming request id is found in the Hash Map, the total time elapsed could be calculated via timestamp (responses read) minus timestamp from Hash Map (for related request id).
  4. The NCMP can populate Subscription Event Outcome report, and publish it to the topic mentioned in #3 → Possible Topic Names 

Testing Details

Ref: Component Diagram

...

4NCMPClient AppsSubscription Create Event Outcomecm-avc-subscription-response

Implementation Details


Testing Details

...