Versions Compared

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

4
#IssueNotes Decision
1Do we need a analysis template?is convention for (new) developers to guide them

Luke Gleeson and Toine Siebelink  agreed we do to have consistent pages 

2This is an open issue3Possible Topic Names (TBD)Possible '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 TBD (-forwarded)DMI Plugins2 ResponseTBD (forwardedresponse)NCMP3 OutcomeTBD (-outcome-response)
#SourceDestinationContentTopic NameDestination
1Client AppsNCMPSubscription Create Eventcm-avc-subscription
2NCMPDMI Plugins

Forwarded Subscription Create Event

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

SERVICE-

NAME}


3DMI PluginsNCMPForwarded Subscription Create Event Responsedmi-ncmp-cm-avc-subscription
4NCMPClient Apps

Implementation Details

...

Subscription Create Event Outcomecm-avc-subscription-response

Implementation Details

...


Testing Details