Table of Contents |
---|
References
Jira | ||||||
---|---|---|---|---|---|---|
|
Assumptions
Assumption | Notes | Sign-off | |
---|---|---|---|
1 | One client can have multiple subs | ||
2 | Topic is setup correctly (by clients) and NCMP will have write access | Maybe not by client but definitely NOT NCMP responsibility | |
3 | CM Events contain CM Handle IDs (and NOT alternate IDs) so the correct subscriptions can be identified | This could change in the future but has lower priority |
Issues & Decisions
Issue | Notes | Decision | |
---|---|---|---|
1 | Choose alternative for forwarding | Alternatives
| kieran mccarthy and Toine Siebelink Option 3 further expanded as functional requirements 2 & 3 |
2 | Even if clients specify the topic upon subscription creation, can multiple client share the same topic? | Only applies to alternative #3 above | kieran mccarthy NO, see also assumption 1 |
3 | Characteristics wil be discussed after functional delivery and some performance test | Kakfa is assume NOT to be a limiting factor |
Requirements
Functional
Interface | Requirement | Additional Information | Signoff | |
---|---|---|---|---|
1 | Client-defined topic | Topic used for forwarding notification should be based on the client-id which can be extracted from the subscription-id | Need to agree and document the format of the subscription-id Proposed by CPS "<topic-name>---<unique-id>
eg. a client then would create (or own) a topic 'our.cm-channel' then by convention they can create subscription ids like so:
'our.cm-channel---0001' 'our.cm-channel---0002' 'our.cm-channel---4g-cell-subscription' 'our.cm-channel---5g-cell-subscription" | tbc, kieran mccarthy / Csaba Kocsis to review and come back |
2 | Client-defined topic | Client application shall ONLY receive notification they subscribed on | ||
3 | Client-defined topic | Client application shall not see notification they did not subscribed on | ||
4 | Client-defined topic | agreed NOT to support this for performance reasons and clients can always create multiple subs. if needed |
Error Handling
Scenario | Expected Behavior | Notes | ||
---|---|---|---|---|
1 | Subscription ID format not correct i.e. cannot extract out a valid topic name | |||
2 | topic does not exist | |||
3 | no write access to topic | |||
4 | cannot find subscription based on cm handle/path in event |
Characteristics
Parameter | Expectation | Notes | Signoff | |
---|---|---|---|---|
1 | incoming CM notification change events | 150M Events / day | ~1,736 Events / second! per NCMP instance! | |
2 | outgoing CM notification change events | 200M Events / day | caused by overlapping subscriptions | |
3 | NCMP shall support horizontal scaling to support >> 150M CM notification change events (Daily) |
| ||
4 | NCMP shall support processing CM notification change events with the following subscription profile :
| This breakdown does NOT really affect NCMP performance and does not need to be 'mocked' or simulated exactly for testing purposes BUT we should test with multiple subscription and 1 out of 3 events wil go to 2 different topics (as per #2) | ||
5 | Consider Peak load ? ie. 100M events in 1h |
Overview
Solution Proposal
- NCMP (currently) listens to all CM Data Notifications (on an 'internal' topic
- NCMP queries its own persistence service to find out which Client(s) are interested in the notifications A-10 and/or B-52