From 963830822c5cded7489f40142e36eed4a5679a06 Mon Sep 17 00:00:00 2001 From: Pelayo Torres Date: Tue, 6 May 2025 10:26:42 +0200 Subject: [PATCH 1/2] Event req documentation --- doc/event-req/event-req.md | 23 +++++++++++++++++++++++ doc/releasenotes.md | 12 ++++++++++-- mkdocs.yml | 1 + 3 files changed, 34 insertions(+), 2 deletions(-) create mode 100644 doc/event-req/event-req.md diff --git a/doc/event-req/event-req.md b/doc/event-req/event-req.md new file mode 100644 index 00000000..019801ed --- /dev/null +++ b/doc/event-req/event-req.md @@ -0,0 +1,23 @@ +# Event Reporting Information Feature + +The Event Reporting Information Feature represents the requirements of the subscription, allowing users to specify the type of subscription they want, the maximum number of notifications they wish to receive, or the desired expiration date of the subscription, among other details. + +## How it works + +To use this feature, the supported feature **enhancedEventReport** must be enabled. With this feature activated, the **eventReq** field can be used when creating a new event subscription, containing the following information for CAPIF: + +- **immRep**: Indicates an immediate report. If included and set to *true*, this specifies that periodic notifications that haven't been sent immediately for subscribed events should be sent. When a subscription is updated, all pending notifications are deleted, so it's very useful for receiving these notifications. + +- **notifMethod**: Represents the notification method, which can be *PERIODIC* for subscriptions that receive notifications at regular intervals, *ONE_TIME* to receive only one notification, and *ON_EVENT_DETECTION* which sends the notification when the event occurs. If no method is specified, the default method used is *ON_EVENT_DETECTION*. + +- **maxReportNbr**: Represents the maximum number of reports that can be sent before the subscription expires. It can be used with the *PERIODIC* and *ON_EVENT_DETECTION* methods, and if not specified, there is no limit. + +- **monDur**: Represents the date on which the subscription expires. If no date is specified, there will be no time limit. + +- **repPeriod**: Indicates the time interval in seconds between successive notification deliveries. It must be specified when the notification method is *PERIODIC*. + +Using these fields provides significant benefits, such as enabling precise control over event notifications or ensuring that users receive the information when they need it. This flexibility allows for optimized resource usage, as unnecessary notifications are avoided, and the subscription can be tailored to specific use cases, improving overall efficiency and user satisfaction. + +[OCF Web]: https://ocf.etsi.org/ "OCF Web" +[OCF Documentation]: https://ocf.etsi.org/documentation/ "OCF Documentation" + diff --git a/doc/releasenotes.md b/doc/releasenotes.md index 42eb4ea3..9ee66d09 100644 --- a/doc/releasenotes.md +++ b/doc/releasenotes.md @@ -4,11 +4,18 @@ #### **Added Event Filters** -- Check [Event Filter section](./event-filter/event-filter.md) - New filters for Event service subscriptions. - You can now specify from which API, AEF, or Invoker you want to receive the event notifications. - These filters are specified in the ***eventFilters*** of the subscription if the ***Enhanced Event Report*** feature of the ***Supported Features*** is activated. -- More detailed information about event filters can be found in [Event Filter]. +- More detailed information about event filters can be found in [Event Filter section](./event-filter/event-filter.md). + +#### **Added Event Reporting Information** + +- New Reporting Information for event subscriptions. + - Now, you can specify the type of subscription you want: periodic, when an event is detected or one-time. + - Fields have been added to allow setting a maximum number of notifications and the subscription expiration time. + - You can now immediately get periodic notifications that have not been sent. +- More detailed information about the Reporting Information can be found in [Event Reporting Information section](./event-req/event-req.md) ### **Testing** @@ -55,6 +62,7 @@ This will also helps on the restart issue on k8s deployed OpenCAPIF. - New [Vendor Extensibility section](./vendor-ext/vendor-ext.md) - New [API Status section](./api-status/api-status.md) - New [Dynamic Configuration section](./configuration/configuration.md) +- New [Event Reporting Information section](./event-req/event-req.md) #### Testplan - New tests related with [Api Status Feature](./testing/testplan/api_status/README.md). diff --git a/mkdocs.yml b/mkdocs.yml index aee26a19..d428168f 100644 --- a/mkdocs.yml +++ b/mkdocs.yml @@ -94,6 +94,7 @@ nav: - Api Status: ./api-status/api-status.md - Event Filter: ./event-filter/event-filter.md - Dynamic Configuration: ./configuration/configuration.md + - Event Reporting Information: ./event-req/event-req.md - SDK: - Introduction: ./sdk/sdk.md - Example Clients: -- GitLab From c479ea8d50ed59414af6f6fa9c7bd0d42d30c4e3 Mon Sep 17 00:00:00 2001 From: Pelayo Torres Date: Tue, 6 May 2025 10:48:36 +0200 Subject: [PATCH 2/2] Deleted some references --- doc/api-status/api-status.md | 2 -- doc/event-filter/event-filter.md | 2 -- doc/event-req/event-req.md | 2 -- 3 files changed, 6 deletions(-) diff --git a/doc/api-status/api-status.md b/doc/api-status/api-status.md index b1b97e25..d7c4a567 100644 --- a/doc/api-status/api-status.md +++ b/doc/api-status/api-status.md @@ -29,5 +29,3 @@ Both API Invokers and Providers can subscribe to the **SERVICE_API_AVAILABLE** a Additionally, if the *enhanced_event_report* function is supported, the API description could be received as event details in the eventDetails field if *apiStatusMonitoring* is also enabled. This will make it easier for event subscribers to know if any changes have been made to the API, such as a change in API availability to other AEFs. -[OCF Web]: https://ocf.etsi.org/ "OCF Web" -[OCF Documentation]: https://ocf.etsi.org/documentation/ "OCF Documentation" diff --git a/doc/event-filter/event-filter.md b/doc/event-filter/event-filter.md index 0596522b..e2db2106 100644 --- a/doc/event-filter/event-filter.md +++ b/doc/event-filter/event-filter.md @@ -32,5 +32,3 @@ Depending on the event you subscribe to, you can use one or more of these lists. In cases where 2 or 3 lists are specified simultaneously for an event, notifications will only be sent when there is at least one matching element in each of the subscription lists. For example, if you subscribe to the ***ACCESS_CONTROL_POLICY_UPDATE*** event using the ***apiIds*** and ***apiInvokerIds*** filter lists, you will only be notified when the access control policy update corresponds to an API in the ***apiIds*** list and an invoker in the ***apiInvokerIds*** list at the same time. -[OCF Web]: https://ocf.etsi.org/ "OCF Web" -[OCF Documentation]: https://ocf.etsi.org/documentation/ "OCF Documentation" diff --git a/doc/event-req/event-req.md b/doc/event-req/event-req.md index 019801ed..0aacd1b1 100644 --- a/doc/event-req/event-req.md +++ b/doc/event-req/event-req.md @@ -18,6 +18,4 @@ To use this feature, the supported feature **enhancedEventReport** must be enabl Using these fields provides significant benefits, such as enabling precise control over event notifications or ensuring that users receive the information when they need it. This flexibility allows for optimized resource usage, as unnecessary notifications are avoided, and the subscription can be tailored to specific use cases, improving overall efficiency and user satisfaction. -[OCF Web]: https://ocf.etsi.org/ "OCF Web" -[OCF Documentation]: https://ocf.etsi.org/documentation/ "OCF Documentation" -- GitLab