Versions Compared

Version Old Version 8 New Version Current
Changes made by

Halil Cakal

Halil Cakal

Saved on

Key

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

...


Subscription Creation Events Handling

Assumptions

<optional, assumptions are like decision made up front ie. everyone agrees on the answer but they are important to mention>

#AssumptionNotes
1
Forwarded 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.2
Forwarded Subscription Event Responses
communicates
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


2The 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

#IssueNotes Decision
1Possible Topic Names (TBD)

Toine Siebelink , Luke Gleeson (Unlicensed) , Sourabh Sourabh  and Lee Anjella Macabuhay  

2Possible 'timeframe' period to consume Forwarded Subscription Create Event ResponsesTBD for timeframe'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)

Possible Topic Names

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

Forwarded Subscription Create EventTBD (

ncmp-dmi-cm-avc-subscription-{DMI-DATA-

forwarded

SERVICE-

response)

NAME}


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

Implementation Details

...

Subscription Create Event Outcomecm-avc-subscription-response

Implementation Details


Testing Details