Skip to content
Snippets Groups Projects
Commit 32e2af70 authored by guillecxb's avatar guillecxb
Browse files

Merge remote-tracking branch 'origin/develop' into... 

Merge remote-tracking branch 'origin/develop' into OCF-Doc36-documentation-how-to-manage-dynamic-configuration-2
parents 24bcf4b0 ebfc621d
No related branches found
No related tags found
1 merge request!38Resolve "Documentation how to manage dynamic configuration"
Hide whitespace changes
Inline Side-by-side
doc/releasenotes.md
+ 9
− 1
View file @ 32e2af70
......@@ -4,11 +4,17 @@
#### **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].
### **Testing**
- New Event Filter test suite with 8 tests. [Event Filter test suite](./testing/testplan/event_filter/README.md)
### **Technical Debt Solved**
#### **Hardening on startup scripts for services interacting with Vault**
......@@ -32,6 +38,7 @@ This will also helps on the restart issue on k8s deployed OpenCAPIF.
#### **Vendor Extensibility**
- Check [Vendor Extensibility section](./vendor-ext/vendor-ext.md)
- Publish API:
- On publishing a service API, **SupportedFeatures** is read and checked whether VendExt feature is enabled.
- When VendExt is enabled, vendor-specific fields are searched and stored in the db inside the ServiceAPIDescription object
......@@ -87,12 +94,14 @@ This will also helps on the restart issue on k8s deployed OpenCAPIF.
#### **Api Status feature**
- Check [API Status section](./api-status/api-status.md)
- New logic to support ***API Status*** feature on Publish and Events Services.
- Events API:
- Event internal notifications between services improved to accomplish specification.
- On event subscription **SupportedFeatures** is read and stored in db to accomplish specification.
- Also **SupportedFeatures** is checked before send event notification, in order to accomplish specification, sending **eventDetails** and related information according to ***enhanced_event_report*** and ***apiStatusMonitoring*** supported features activated.
#### Remote Scripts
New scripts developed to help on remote deployment, configuration and testing. All this script are stored under helm/scripts in capif repository.
......@@ -365,4 +374,3 @@ This Release also includes a Robot Test Suite for all those services and a Postm
[New Registration Demo]: https://www.youtube.com/watch?v=sn-tN6eRvv8 "New Registration Demo"
[CICD Wiki]: https://labs.etsi.org/rep/ocf/community/-/wikis/OCF-CICD "CI/CD Wiki"
[Upgrade Release 17 to 18 Wiki]: https://labs.etsi.org/rep/ocf/community/-/wikis/3GPP-Release-18-upgrade "Upgrade Release 17 to 18 Wiki"
[Event Filter]: ./event-filter/event-filter.md "Event Filter"
doc/testing/testplan/README.md
+ 1
− 0
View file @ 32e2af70
......@@ -15,3 +15,4 @@ List of Common API Services implemented:
## Features
* [Vendor Extensibility](./vendor_extensibility/README.md)
* [Api Status](./api_status/README.md)
* [Event Filter](./event_filter/README.md)
doc/testing/testplan/api_events_service/README.md
+ 4
− 3
View file @ 32e2af70
......@@ -453,6 +453,7 @@ At this documentation you will have all information and related files and exampl
2. body [event subscription request body] with:
1. events: **['SERVICE_API_UPDATE']**
2. supportedFeatures: binary 0100 -> string **4**
3. **eventFilter** set to apiId from published API.
3. Use **Invoker Certificate**
7. Update published API at CCF:
......@@ -850,7 +851,7 @@ At this documentation you will have all information and related files and exampl
1. Send **POST** to **https://{CAPIF_HOSTNAME}/capif-events/v1/{subscriberId}/subscriptions**
2. body [event subscription request body] with:
1. events: **['SERVICE_API_INVOCATION_SUCCESS','SERVICE_API_INVOCATION_FAILURE']**
2. eventFilter: only receive events from provider's aefId.
2. eventFilter: Not present.
3. supportedFeatures: binary 0000 -> string **0**
3. Use **Invoker Certificate**
......@@ -925,7 +926,7 @@ At this documentation you will have all information and related files and exampl
1. Send **POST** to **https://{CAPIF_HOSTNAME}/capif-events/v1/{subscriberId}/subscriptions**
2. body [event subscription request body] with:
1. events: **['SERVICE_API_AVAILABLE','SERVICE_API_UNAVAILABLE']**
2. eventFilter: only receive events from provider's aefId.
2. eventFilter: Not present.
3. supportedFeatures: binary 0000 -> string **0**
3. Use **Invoker Certificate**
......@@ -1001,7 +1002,7 @@ At this documentation you will have all information and related files and exampl
1. Send **POST** to **https://{CAPIF_HOSTNAME}/capif-events/v1/{subscriberId}/subscriptions**
2. body [event subscription request body] with:
1. events: **['SERVICE_API_UPDATE']**
2. eventFilter: only receive events from provider's aefId.
2. eventFilter: Not present.
3. supportedFeatures: binary 0000 -> string **0**
3. Use **Invoker Certificate**
......
doc/testing/testplan/common_operations/README.md
+ 102
− 0
View file @ 32e2af70
......@@ -110,6 +110,103 @@ The steps to register a new user at Register Service are:
![Flow](../../../images/flows/07_Invoker_Onboarding.png)
## Subscribe to Events
Subscription to an Event by any entity (Invoker, Provider or other CCF), will ensure when subscription is matched one event will be sent to notification destination present on subscription creation.
### How to create a subscription
In order to create a subcription, customer must setup some different parameters.
#### Basic Subscription
Basic subcription will be used when Enhanced_event_report feature is not active at supportedFeatures attribute at [event subscription request body], this means this kind of subcription:
* Won't be filtered by eventFilters.
* Reporting specific requierements won't be enable (eventReq).
* Response will only contains basic information without eventDetail.
With this in mind, customer must select next parameters:
##### Events to subscribe
Select event or events to subscribe. Check from next list:
| Event | Description | Status |
| :-------------------------------- | :--------------------------------------------------------------------------------------------------------------------------------------- | :-------------: |
| SERVICE_API_AVAILABLE | Events related to the availability of service APIs after the service APIs are published. | Implemented |
| SERVICE_API_UNAVAILABLE | Events related to the unavailability of service APIs after the service APIs are unpublished. | Implemented |
| SERVICE_API_UPDATE | Events related to change in service API information. | Implemented |
| API_INVOKER_ONBOARDED | Events related to API invoker onboarded to CAPIF. | Implemented |
| API_INVOKER_OFFBOARDED | Events related to API invoker offboarded from CAPIF. | Implemented |
| SERVICE_API_INVOCATION_SUCCESS | Events related to the successful invocation of service APIs. | Implemented |
| SERVICE_API_INVOCATION_FAILURE | Events related to the failed invocation of service APIs. | Implemented |
| ACCESS_CONTROL_POLICY_UPDATE | Events related to the update for the access control policy related to the service APIs. | Implemented |
| ACCESS_CONTROL_POLICY_UNAVAILABLE | Events related to the unavailability of the access control policy related to the service APIs (NOTE). | Implemented |
| API_INVOKER_AUTHORIZATION_REVOKED | Events related to the revocation of the authorization of API invokers to access the service APIs. (NOTE). | Implemented |
| API_INVOKER_UPDATED | Events related to API invoker profile updated to CAPIF. | Implemented |
| API_TOPOLOGY_HIDING_CREATED | Events related to the creation or update of the API topology hiding information of the service API after the service APIs are published. | Not Implemented |
| API_TOPOLOGY_HIDING_REVOKED | Events related to the revocation of the API topology information of the service API after the service APIs are unpublished. | Not Implemented |
**NOTE**: 3GPP Common API Framework release 19 specs not specify further details (e.g event filters) for this event.
##### Notification Destination
* Set ***notification destination*** at [event subscription request body] with the endpoint to be reached by CCF when an event matches.
#### Enhanced Subscription
Enhanced will be the requiered subscription if customer needs one or more next functionality:
* Filter events. (eventFilters)
* Setup some reporting requirements. (eventReq)
* Get more detailed information when event notification is received (eventDetail on response)
If that is the case, then [event subscription request body] must setup supported features with Enhanced_event_report feature active (feature 3)
With this feature active, customer can send eventFilter and EventReq with required information.
##### Event Filter
We can include an array for each suscribed array with desired eventFilter to be applied, but we need to keep in mind not all events allows all filters, take a look to next table:
| Event | Event filter allowed |
| :-------------------------------- | :----------------------------- |
| SERVICE_API_AVAILABLE | apiIds |
| SERVICE_API_UNAVAILABLE | apiIds |
| SERVICE_API_UPDATE | apiIds |
| API_INVOKER_ONBOARDED | apiInvokerIds |
| API_INVOKER_OFFBOARDED | apiInvokerIds |
| SERVICE_API_INVOCATION_SUCCESS | apiIds, apiInvokerIds, aefIds. |
| SERVICE_API_INVOCATION_FAILURE | apiIds, apiInvokerIds, aefIds. |
| ACCESS_CONTROL_POLICY_UPDATE | apiIds, apiInvokerIds. |
| ACCESS_CONTROL_POLICY_UNAVAILABLE | - |
| API_INVOKER_AUTHORIZATION_REVOKED | - |
| API_INVOKER_UPDATED | apiInvokerIds |
| API_TOPOLOGY_HIDING_CREATED | - |
| API_TOPOLOGY_HIDING_REVOKED | - |
##### Event Req
Currently not implemented
### Steps to Perform operation
1. Perform [invoker onboarding] or [provider registration]
2. Event Subscription:
1. Send **POST** to **https://{CAPIF_HOSTNAME}/capif-events/v1/{subscriberId}/subscriptions**
2. body [event subscription request body]
3. Use **Invoker Certificate** or **AMF Provider Certificate**
### Checks to ensure provider registration
1. Response to Event Subscription must accomplish:
1. **201 Created**
2. The URI of the created resource shall be returned in the "Location" HTTP header, following this structure: **{apiRoot}/capif-events/{apiVersion}/{subscriberId}/subscriptions/{subscriptionId}**
3. Response Body must follow **EventSubscription** data structure.
[user_registration_body]: ./user_registration_body.json "User Registration Body"
[user_getauth_response_body_example]: ./user_getauth_response_body_example.json "User GetAuth response Body Example"
......@@ -118,5 +215,10 @@ The steps to register a new user at Register Service are:
[provider request body]: ../api_provider_management/provider_details_post_example.json "API Provider Enrolment Request"
[event subscription request body]: ../api_events_service/event_subscription.json "Event Subscription Request"
[invoker onboarding]: #onboard-an-invoker "Invoker Onboarding"
[provider registration]: #register-a-provider "Provider Registration"
[Return To All Test Plans]: ../README.md
doc/testing/testplan/event_filter/README.md 0 → 100644
+ 562
− 0
View file @ 32e2af70
# Test Plan for Event Filter Feature
At this documentation you will have all information and related files and examples of test plan for this feature.
## Test Case 1: Invoker subscribed to SERVICE_API_AVAILABLE, SERVICE_API_UNAVAILABLE and SERVICE_API_UPDATE events filtered by apiIds
**Test ID**: ***event_filter-1***
**Additional Tags**: ***mockserver***
**Description**:
This test case will check an invoker can subscribe to SERVICE_API events and filter them by apiId.
**Pre-Conditions**:
* Invoker is previously registered and onboarded.
* Two providers registered and with APIs published.
* **Mock Server is up and running to receive requests.**
* **Mock Server is clean.**
**Execution Steps**:
1. Register and onboard ***Invoker***
2. Register ***Provider 1*** and publish ***service_1*** api:
1. Setup provider with Two AEFs.
2. Publish ***service_1*** with:
1. Two AEFs. (aef_id_1 and aef_id_2)
2. apiStatus empty list.
3. supportedFeatures 020.
3. Register ***Provider 2*** and publish ***service_2*** api:
1. Publish ***service_2*** with:
1. apiStatus with AEF Id (aef2_id_1)
2. supportedFeatures 020
4. Discover APIs by Invoker:
1. filter by aef_id_1
2. Only one api will be obtained, store apiId at api_id.
5. Subscribe to events:
1. Events: ***SERVICE_API_AVAILABLE, SERVICE_API_UNAVAILABLE, SERVICE_API_UPDATE.***
2. EventFilter: ***[apiId], [apiId], [apiId].***
3. supportedFeatures: ***C***
6. Update service_1 api:
1. apiStatus with ***aefIds*** present on ***Provider 1***.
2. SupportedFeatures set to ***20***
7. Remove Provider 1
8. Remove Provider 2
**Expected Results**:
Mock Server received messages must accomplish:
1. **Three Events have been received**.
2. Validate received events follow **EventNotification** data structure, with:
1. **SERVICE_API_AVAILABLE**:
1. EventDetail include serviceAPIDescriptions with same Service API description Modified with apiStatus containing aefIds of provider 1
2. **SERVICE_API_UPDATE**:
1. EventDetail include serviceAPIDescriptions with same Service API description Modified with apiStatus containing aefIds of provider 1
3. **SERVICE_API_UNAVAILABLE**
1. EventDetail include serviceAPIDescriptions with same Service API description Modified with apiStatus containing aefIds of provider 1
---
## Test Case 2: Invoker subscribed to SERVICE_API_AVAILABLE, SERVICE_API_UNAVAILABLE and SERVICE_API_UPDATE events filtered by not valid filters
**Test ID**: ***event_filter-2***
**Additional Tags**: ***smoke***
**Description**:
This test case will check all error response related with wrong filtering options when invoker subscribes to SERVICE_API events.
**Pre-Conditions**:
* Invoker is previously registered and onboarded.
* Two providers registered and with APIs published.
**Execution Steps**:
1. Register and onboard ***Invoker***
2. Register ***Provider 1*** and publish ***service_1*** api:
1. Setup provider with Two AEFs.
2. Publish ***service_1*** with:
1. Two AEFs. (aef_id_1 and aef_id_2)
2. apiStatus empty list.
3. supportedFeatures 020.
3. Register ***Provider 2*** and publish ***service_2*** api:
1. Publish ***service_2*** with:
1. apiStatus with AEF Id (aef2_id_1)
2. supportedFeatures 020
4. Discover APIs by Invoker:
1. filter by aef_id_1
2. Only one api will be obtained, store apiId at api_id.
5. Subscribe to events:
1. Events: ***SERVICE_API_AVAILABLE, SERVICE_API_UNAVAILABLE, SERVICE_API_UPDATE.***
2. EventFilter: ***[aefIds], [empty], [empty].***
3. supportedFeatures: ***C***
6. Subscribe to events:
1. Events: ***SERVICE_API_AVAILABLE, SERVICE_API_UNAVAILABLE, SERVICE_API_UPDATE.***
2. EventFilter: ***[empty], [aefIds], [empty].***
3. supportedFeatures: ***C***
7. Subscribe to events:
1. Events: ***SERVICE_API_AVAILABLE, SERVICE_API_UNAVAILABLE, SERVICE_API_UPDATE.***
2. EventFilter: ***[empty], [empty], [aefIds].***
3. supportedFeatures: ***C***
8. Subscribe to events:
1. Events: ***SERVICE_API_AVAILABLE, SERVICE_API_UNAVAILABLE, SERVICE_API_UPDATE.***
2. EventFilter: ***[empty], [empty], [apiInvokerIds].***
3. supportedFeatures: ***C***
**Expected Results**:
We will receive one error after each Event subscription:
1. Response to first subscription:
1. ***400 Bad Request***
2. ProblemDetails Body with:
1. title: ***Bad Request***
2. status: ***400***
3. detail: ***Bad Param***
4. cause: ***Invalid eventFilter for event SERVICE_API_AVAILABLE***
5. invalidParams: ***[{ param:eventFilter, reason: The eventFilter aef_ids for event SERVICE_API_AVAILABLE are not applicable }]***
2. Response to first subscription:
1. ***400 Bad Request***
2. ProblemDetails Body with:
1. title: ***Bad Request***
2. status: ***400***
3. detail: ***Bad Param***
4. cause: ***Invalid eventFilter for event SERVICE_API_UNAVAILABLE***
5. invalidParams: ***[{ param:eventFilter, reason: The eventFilter aef_ids for event SERVICE_API_UNAVAILABLE are not applicable }]***
3. Response to first subscription:
1. ***400 Bad Request***
2. ProblemDetails Body with:
1. title: ***Bad Request***
2. status: ***400***
3. detail: ***Bad Param***
4. cause: ***Invalid eventFilter for event SERVICE_API_UPDATE***
5. invalidParams: ***[{ param:eventFilter, reason: The eventFilter aef_ids for event SERVICE_API_UPDATE are not applicable }]***
4. Response to first subscription:
1. ***400 Bad Request***
2. ProblemDetails Body with:
1. title: ***Bad Request***
2. status: ***400***
3. detail: ***Bad Param***
4. cause: ***Invalid eventFilter for event SERVICE_API_UPDATE***
5. invalidParams: ***[{ param:eventFilter, reason: The eventFilter api_invoker_ids for event SERVICE_API_UPDATE are not applicable }]***
---
## Test Case 3: Provider subscribed to API_INVOKER_ONBOARDED, API_INVOKER_OFFBOARDED and API_INVOKER_UPDATED events filtered by invokerIds
**Test ID**: ***event_filter-3***
**Additional Tags**: ***mockserver***
**Description**:
This test case will check subcription to all API_INVOKER events by one provider.
**Pre-Conditions**:
* Provider is previously registered.
* **Mock Server is up and running to receive requests.**
* **Mock Server is clean.**
**Execution Steps**:
1. Register ***Provider 1***.
2. Subscribe to events:
1. Events: ***API_INVOKER_ONBOARDED***
2. EventFilter: ***No filter.***
3. supportedFeatures: ***C***
3. Register and onboard ***Invoker 1***
4. Register and onboard ***Invoker 2***
5. Subscribe provider to events:
1. Events: ***API_INVOKER_ONBOARDED, API_INVOKER_OFFBOARDED, API_INVOKER_UPDATED***
2. EventFilter: ***[empty], [apiInvokerId1], [apiInvokerId2].***
3. supportedFeatures: ***C***
6. Update Invoker 1:
1. Setup new notificationDestination at invoker.
7. Update Invoker 2:
1. Setup new notificationDestination at invoker.
8. Remove Invoker 1.
9. Remove Invoker 2.
**Expected Results**:
Mock Server received messages must accomplish:
1. **Four Events have been received**.
2. Validate received events follow **EventNotification** data structure, with:
1. **API_INVOKER_ONBOARDED**:
1. EventDetail include apiInvokerIds with apiInvokerId of provider 1
2. **API_INVOKER_ONBOARDED**:
1. EventDetail include apiInvokerIds with apiInvokerId of provider 2
3. **API_INVOKER_UPDATED**:
1. EventDetail include apiInvokerIds with apiInvokerId of provider 2
4. **API_INVOKER_OFFBOARDED**
1. EventDetail include apiInvokerIds with apiInvokerId of provider 1
---
## Test Case 4: Provider subscribed to API_INVOKER_ONBOARDED, API_INVOKER_OFFBOARDED and API_INVOKER_UPDATED events filtered by not valid filters
**Test ID**: ***event_filter-4***
**Additional Tags**:
**Description**:
This test will check API_INVOKER events subscription by Provider with not valid filters.
**Pre-Conditions**:
* Provider is previously registered.
**Execution Steps**:
1. Register ***Provider 1***.
2. Register and onboard ***Invoker 1***
3. Register and onboard ***Invoker 2***
4. Subscribe provider to events:
1. Subscription 1
2. Events: ***API_INVOKER_ONBOARDED, API_INVOKER_OFFBOARDED, API_INVOKER_UPDATED***
3. EventFilter: ***[aefIds], [empty], [empty].***
4. supportedFeatures: ***C***
5. Subscribe provider to events:
1. Subscription 2
2. Events: ***API_INVOKER_ONBOARDED, API_INVOKER_OFFBOARDED, API_INVOKER_UPDATED***
3. EventFilter: ***[empty], [aefIds], [empty].***
4. supportedFeatures: ***C***
6. Subscribe provider to events:
1. Subscription 3
2. Events: ***API_INVOKER_ONBOARDED, API_INVOKER_OFFBOARDED, API_INVOKER_UPDATED***
3. EventFilter: ***[empty], [empty], [aefIds].***
4. supportedFeatures: ***C***
7. Subscribe provider to events:
1. Subscription 4
2. Events: ***API_INVOKER_ONBOARDED, API_INVOKER_OFFBOARDED, API_INVOKER_UPDATED***
3. EventFilter: ***[empty], [empty], [apiIds].***
4. supportedFeatures: ***C***
**Expected Results**:
1. Response to first subscription:
1. ***400 Bad Request***
2. ProblemDetails Body with:
1. title: ***Bad Request***
2. status: ***400***
3. detail: ***Bad Param***
4. cause: ***Invalid eventFilter for event API_INVOKER_ONBOARDED***
5. invalidParams: ***[{ param:eventFilter, reason: The eventFilter aef_ids for event API_INVOKER_ONBOARDED are not applicable }]***
2. Response to second subscription:
1. ***400 Bad Request***
2. ProblemDetails Body with:
1. title: ***Bad Request***
2. status: ***400***
3. detail: ***Bad Param***
4. cause: ***Invalid eventFilter for event API_INVOKER_OFFBOARDED***
5. invalidParams: ***[{ param:eventFilter, reason: The eventFilter aef_ids for event API_INVOKER_OFFBOARDED are not applicable }]***
3. Response to third subscription:
1. ***400 Bad Request***
2. ProblemDetails Body with:
1. title: ***Bad Request***
2. status: ***400***
3. detail: ***Bad Param***
4. cause: ***Invalid eventFilter for event API_INVOKER_UPDATED***
5. invalidParams: ***[{ param:eventFilter, reason: The eventFilter aef_ids for event API_INVOKER_UPDATED are not applicable }]***
4. Response to fourth subscription:
1. ***400 Bad Request***
2. ProblemDetails Body with:
1. title: ***Bad Request***
2. status: ***400***
3. detail: ***Bad Param***
4. cause: ***Invalid eventFilter for event API_INVOKER_UPDATED***
5. invalidParams: ***[{ param:eventFilter, reason: The eventFilter api_ids for event API_INVOKER_UPDATED are not applicable }]***
---
## Test Case 5: Provider subscribed to ACCESS_CONTROL_POLICY_UPDATE event filtered by only apiId, only invokerId and both
**Test ID**: ***event_filter-5***
**Additional Tags**: ***smoke***, ***mockserver***
**Description**:
This test case will check subcription to ACCESS_CONTROL_POLICY_UPDATE event by one provider.
**Pre-Conditions**:
* Two Providers are previously registered and published APIs
* Two invoker are previously registered.
* **Mock Server is up and running to receive requests.**
* **Mock Server is clean.**
**Execution Steps**:
1. Register ***Provider 1*** and publish ***service_1*** api:
* Store apiId1
2. Register ***Provider 2*** and publish ***service_2*** api:
* Store apiId2
3. Register and onboard ***Invoker 1***
* apiInvokerId1
4. Register and onboard ***Invoker 2***
* apiInvokerId2
6. Subscribe to events:
1. Subscription1
2. Events: ***ACCESS_CONTROL_POLICY_UPDATE***
3. EventFilter: ***[apiId1].***
4. supportedFeatures: ***C***
7. Subscribe to events:
1. Subscription2
2. Events: ***ACCESS_CONTROL_POLICY_UPDATE***
3. EventFilter: ***[apiInvokerId1].***
4. supportedFeatures: ***C***
7. Subscribe to events:
1. Subscription3
2. Events: ***ACCESS_CONTROL_POLICY_UPDATE***
3. EventFilter: ***[apiInvokerId2] and [apiId2].***
4. supportedFeatures: ***C***
8. Create Security Context Between Invoker 1 and provider 1 exposed API.
1. Store acl_provider_1
9. Create Security Context Between Invoker 2 and provider 1 exposed API.
1. Store acl_provider_1 (array will contain 2 values)
10. Create Security Context Between Invoker 1 and provider 2 exposed API.
1. Store acl_provider_2 (array will contain 2 values)
11. Create Security Context Between Invoker 2 and provider 2 exposed API.
1. Store acl_provider_2 (array will contain 2 values)
**Expected Results**:
1. **Eight Events have been received** for 3 different subscriptions.
2. Validate received events follow **EventNotification** data structure
3. **Subcription 1**:
1. **ACCESS_CONTROL_POLICY_UPDATE**:
1. EventDetail include accCtrlPolList with apiId1 and apiInvokerPolicies with Security Context between invoker 1 and provider 1 (acl_provider_1[0])
2. **ACCESS_CONTROL_POLICY_UPDATE**:
1. EventDetail include accCtrlPolList with apiId1 and apiInvokerPolicies with Security Context between invoker 2 and provider 1 (acl_provider_1[1])
3. **ACCESS_CONTROL_POLICY_UPDATE**:
1. EventDetail include accCtrlPolList with apiId2 and apiInvokerPolicies with Security Context between invoker 1 and provider 2 (acl_provider_2[0])
4. **ACCESS_CONTROL_POLICY_UPDATE**:
1. EventDetail include accCtrlPolList with apiId1 and apiInvokerPolicies with Security Context between invoker 2 and provider 2 (acl_provider_2[1])
4. **Subcription 2**:
1. **ACCESS_CONTROL_POLICY_UPDATE**:
1. EventDetail include accCtrlPolList with apiId1 and apiInvokerPolicies with Security Context between invoker 1 and provider 1 (acl_provider_1[0])
2. **ACCESS_CONTROL_POLICY_UPDATE**:
1. EventDetail include accCtrlPolList with apiId1 and apiInvokerPolicies with Security Context between invoker 1 and provider 1 (acl_provider_1[0])
3. **ACCESS_CONTROL_POLICY_UPDATE**:
1. EventDetail include accCtrlPolList with apiId2 and apiInvokerPolicies with Security Context between invoker 1 and provider 2 (acl_provider_2[0])
5. **Subcription 3**:
1. **ACCESS_CONTROL_POLICY_UPDATE**:
1. EventDetail include accCtrlPolList with apiId2 and apiInvokerPolicies with Security Context between invoker 2 and provider 2 (acl_provider_2[1])
---
## Test Case 6: Provider subscribed to ACCESS_CONTROL_POLICY_UPDATE event filtered by aefId
**Test ID**: ***event_filter-6***
**Additional Tags**:
**Description**:
This test will check ACCESS_CONTROL_POLICY_UPDATE event subscription by Provider with not valid filters.
**Pre-Conditions**:
* One Provider is previously registered.
**Execution Steps**:
1. Register ***Provider 1***.
2. Subscribe to events:
1. Subscription1
2. Events: ***ACCESS_CONTROL_POLICY_UPDATE***
3. EventFilter: ***[aef_ids].***
4. supportedFeatures: ***C***
**Expected Results**:
1. Response to subscription:
1. ***400 Bad Request***
2. ProblemDetails Body with:
1. title: ***Bad Request***
2. status: ***400***
3. detail: ***Bad Param***
4. cause: ***Invalid eventFilter for event ACCESS_CONTROL_POLICY_UPDATE***
5. invalidParams: ***[{ param:eventFilter, reason: The eventFilter aef_ids for event ACCESS_CONTROL_POLICY_UPDATE are not applicable }]***
---
## Test Case 7: Provider subscribed to SERVICE_API_INVOCATION_SUCCESS and SERVICE_API_INVOCATION_FAILURE filtered by apiId, invokerId, aefId and all of them
**Test ID**: ***event_filter-7***
**Additional Tags**: **smoke**, **mockserver**
**Description**:
This test will check all possible filters options allowed for SERVICE_API_INVOCATION_SUCCESS and SERVICE_API_INVOCATION_FAILURE.
**Pre-Conditions**:
* Two Providers are previously registered and published APIs
* Two invoker are previously registered.
* **Mock Server is up and running to receive requests.**
* **Mock Server is clean.**
**Execution Steps**:
1. Register ***Provider 1*** and publish ***service_1*** api:
* Store apiId1
* Store aefId1
2. Register ***Provider 2*** and publish ***service_2*** api:
* Store apiId2
* Store aefId2
3. Register and onboard ***Invoker 1***
* apiInvokerId1
4. Register and onboard ***Invoker 2***
* apiInvokerId2
6. Subscribe provider 1 to events:
1. Subscription 1
2. Events: ***SERVICE_API_INVOCATION_SUCCESS, SERVICE_API_INVOCATION_FAILURE.***
3. EventFilter: ***[apiId1], [apiId1].***
4. supportedFeatures: ***C***
7. Subscribe provider 1 to events:
1. Subscription 2
2. Events: ***SERVICE_API_INVOCATION_SUCCESS, SERVICE_API_INVOCATION_FAILURE.***
3. EventFilter: ***[apiId1], [apiId1].***
4. supportedFeatures: ***C***
8. Subscribe provider 1 to events:
1. Subscription 3
2. Events: ***SERVICE_API_INVOCATION_SUCCESS, SERVICE_API_INVOCATION_FAILURE.***
3. EventFilter: ***[apiId1], [apiId1].***
4. supportedFeatures: ***C***
9. Subscribe provider 1 to events:
1. Subscription 4
2. Events: ***SERVICE_API_INVOCATION_SUCCESS, SERVICE_API_INVOCATION_FAILURE.***
3. EventFilter: ***[apiId1], [apiId1].***
4. supportedFeatures: ***C***
10. Subscribe provider 1 to events:
1. Subscription 5
2. Events: ***SERVICE_API_INVOCATION_SUCCESS, SERVICE_API_INVOCATION_FAILURE.***
3. EventFilter: ***[apiId1], [apiId1].***
4. supportedFeatures: ***C***
11. Subscribe provider 1 to events:
1. Subscription 6
2. Events: ***SERVICE_API_INVOCATION_SUCCESS, SERVICE_API_INVOCATION_FAILURE.***
3. EventFilter: ***[apiId1], [apiId1].***
4. supportedFeatures: ***C***
12. Subscribe provider 1 to events:
1. Subscription 7
2. Events: ***SERVICE_API_INVOCATION_SUCCESS, SERVICE_API_INVOCATION_FAILURE.***
3. EventFilter: ***[apiId1], [apiId1].***
4. supportedFeatures: ***C***
13. Send Log entry by provider1:
1. apiNames: [service_1]
2. apiIds: [apiId1]
3. aefId: aefId1
4. apiInvokerId: apiInvokerId1
5. results: [200, 400]
6. Store body to **request_body_log_1**
14. Send Log entry by provider2:
1. apiNames: [service_2]
2. apiIds: [apiId2]
3. aefId: aefId2
4. apiInvokerId: apiInvokerId1
5. results: [200]
6. Store body to **request_body_log_2**
15. Send Log entry by provider2:
1. apiNames: [service_2]
2. apiIds: [apiId2]
3. aefId: aefId2
4. apiInvokerId: apiInvokerId2
5. results: [200]
6. Store body to **request_body_log_3**
16. Send Log entry by provider1:
1. apiNames: [service_1]
2. apiIds: [apiId1]
3. aefId: aefId1
4. apiInvokerId: apiInvokerId2
5. results: [400]
6. Store body to **request_body_log_4**
**Expected Results**:
1. **Thirteen Events have been received** for 7 different subscriptions.
2. Validate received events follow **EventNotification** data structure
3. **Subcription 1**:
1. **SERVICE_API_INVOCATION_SUCCESS**:
1. EventDetail include invocationLogs with **request_body_log_1**
2. **SERVICE_API_INVOCATION_FAILURE**:
1. EventDetail include invocationLogs with **request_body_log_1**
3. **SERVICE_API_INVOCATION_FAILURE**:
1. EventDetail include invocationLogs with **request_body_log_4**
4. **Subcription 2**:
1. **SERVICE_API_INVOCATION_SUCCESS**:
1. EventDetail include invocationLogs with **request_body_log_2**
2. **SERVICE_API_INVOCATION_SUCCESS**:
1. EventDetail include invocationLogs with **request_body_log_3**
5. **Subcription 3**:
1. **SERVICE_API_INVOCATION_SUCCESS**:
1. EventDetail include invocationLogs with **request_body_log_1**
2. **SERVICE_API_INVOCATION_SUCCESS**:
1. EventDetail include invocationLogs with **request_body_log_1**
3. **SERVICE_API_INVOCATION_SUCCESS**:
1. EventDetail include invocationLogs with **request_body_log_2**
6. **Subcription 4**:
1. **SERVICE_API_INVOCATION_SUCCESS**:
1. EventDetail include invocationLogs with **request_body_log_2**
2. **SERVICE_API_INVOCATION_SUCCESS**:
1. EventDetail include invocationLogs with **request_body_log_3**
7. **Subcription 5**:
1. **SERVICE_API_INVOCATION_SUCCESS**:
1. EventDetail include invocationLogs with **request_body_log_3**
8. **Subcription 6**:
1. **SERVICE_API_INVOCATION_FAILURE**:
1. EventDetail include invocationLogs with **request_body_log_4**
9. **Subcription 7**:
1. **SERVICE_API_INVOCATION_SUCCESS**:
1. EventDetail include invocationLogs with **request_body_log_3**
---
## Test Case 8: Event Filter present with Enhanced_event_report feature not active.
**Test ID**: ***event_filter-8***
**Additional Tags**: **smoke**
**Description**:
This test will check event subscription by Invoker with eventFilter attribute but without Enhanced_event_report feature active.
**Pre-Conditions**:
* Invoker is previously registered and onboarded.
**Execution Steps**:
1. Register and onboard ***Invoker***
2. Subscribe to events:
2. Events: ***SERVICE_API_AVAILABLE, SERVICE_API_UNAVAILABLE, SERVICE_API_UPDATE***
3. EventFilter: ***[empty], [empty], [empty].***
4. supportedFeatures: ***0***
**Expected Results**:
1. Response to subscription:
1. ***400 Bad Request***
2. ProblemDetails Body with:
1. title: ***Bad Request***
2. status: ***400***
3. detail: ***Bad Param***
4. cause: ***Event filters provided but EnhancedEventReport is not enabled***
5. invalidParams: ***[{ param:eventFilter, reason: EnhancedEventReport is not enabled }]***
---
[service api description]: ../api_publish_service/service_api_description_post_example.json "Service API Description Request"
[service api description patch]: ../api_publish_service/service_api_description_patch_example.json "Service API Description Patch Request"
[publisher register body]: ../api_publish_service/publisher_register_body.json "Publish register Body"
[invoker onboarding body]: ../api_invoker_management/invoker_details_post_example.json "API Invoker Request"
[provider request body]: ../api_provider_management/provider_details_post_example.json "API Provider Enrolment Request"
[provider request patch body]: ../api_provider_management/provider_details_enrolment_details_patch_example.json "API Provider Enrolment Patch Request"
[invoker onboarding]: ../common_operations/README.md#onboard-an-invoker "Invoker Onboarding"
[provider registration]: ../common_operations/README.md#register-a-provider "Provider Registration"
[event subscription request body]: ../api_events_service/event_subscription.json "Event Subscription Request"
0% or .
You are about to add 0 people to the discussion. Proceed with caution.
Finish editing this message first!
Please register or to comment