Merge branch 'OCF-Doc80-include-developments-of-capif-interconnection-in-release-notes' into 'develop'
Resolve "Include developments of CAPIF interconnection in release notes"
Closes #80
See merge request !82
@@ -12,9 +12,23 @@ To run CAPIF APIs locally using docker and docker-compose you can use run.sh scr
```
./run.sh -h
Usage: ./run.sh <options>
Usage: ./run.sh [environment] [options]
environment Optional. Environment name to use (e.g. dev, prod).
If not specified, 'dev' will be used by default.
Options:
-c : Setup different hostname for capif
-m : Launch monitoring service
-a : Setup different hostname for vault
-R : Setup different hostname for register service
-s : Run Mock server. Default true
-m : Run monitoring service
-l : Set Log Level (default DEBUG). Select one of: [CRITICAL, FATAL, ERROR, WARNING, WARN, INFO, DEBUG, NOTSET]
-r : Remove cached information on build
-v : Set OCF version of images
-f : Services directory. (Default $SERVICES_DIR)
-g : Gitlab base URL. (Default $REGISTRY_BASE_URL)
-b : Build docker images. Default TRUE
-h : show this help
```
This script builds and runs all services using docker images, including mongodb and nginx locally and in the background, and imports ca.crt to nginx. By default monitoring is not activated and Nginx is deployed use **capifcore** as a hostname.
@@ -53,12 +67,19 @@ NOTE: You can use different flags if you only want to stop some of them, please
OpenCAPIF Interconnection is a new functionality designed to enable seamless communication and service integration between multiple Common API Framework (CAPIF) domains, following the 3GPP specifications for CAPIF-4 and beyond. This implementation represents the first version of interconnection capabilities within the OpenCAPIF ecosystem.
### Implementation Approach
This implementation adheres to the 3GPP Common API Framework specifications while addressing areas where the standards provide limited definition or flexibility. We have adapted and extended the specification-defined interfaces to accommodate the specific architectural requirements of OpenCAPIF, ensuring compatibility with existing deployments while enabling cross-domain service discovery and invocation.
### Key Features
-**Cross-Domain Service Connectivity**: Facilitates secure communication between CAPIF domains with standardized authentication and authorization mechanisms
-**Service Discovery and Registration**: Enables services to be discovered and registered across interconnected domains following 3GPP guidelines
-**Adaptive Implementation**: Custom implementations for specification gaps, designed to be interoperable and extensible for future standard updates
### Specification Compliance and Extensions
Our approach balances strict adherence to 3GPP standards with pragmatic engineering solutions. Where the 3GPP specifications do not fully define implementation details, we have made informed design decisions that:
- Maintain backward compatibility with existing OpenCAPIF implementations
- Follow the architectural principles established by 3GPP
- Provide clear extension points for future standardization updates
- Ensure robust security and reliability across domain boundaries
New developments perform to include new functionality for this release. Current work include:
- Creation of new Helper API to manage CAPIF interconnection.
- Develop initial logic to publish APIs AFTER successfull CAPIF interconnection.
- New way to read configutation yaml files inside microservices, allowing forwarding to local variables. This changes also HELM scripts at configuration map file.
- New simple test to request CAPIF interconnection at Robot tests.
- Local scripts improved in order to allow interconnection tests with local deployments.
#### **CAPIF Open Discover Service**
Added implementation of **CAPIF_Open_Discover_Service_API** to support open discovery of published APIs.
@@ -31,6 +41,9 @@ For security reasons:
- Fix the check of the Docker version in the run.sh
- Simplify check of vendor extensibility attributes in Discover API
- Fix way to check if robot image is present to run testing scripts. (remote and local tests)
- Local scripts now support environments and multiple deployment of local instances, with 2 dev purpouses environments.
- New run_capif_interconnection_environment.sh, created to raise 2 environments locally to test capif interconnection.
- Local testing scripts now check is destination hosts are reachable by host.
#### **Allow same apiName across different AEFs**
@@ -56,6 +69,8 @@ Additionally, this change includes minor improvements such as correctly setting
- 2 New tests added to [OCF Publish API test plan documentation], related with apiName.
- Changed name of capif_api_provider_management-10 to Update Registered Api Provider Without SuppFeat field
- Updated expected **ProblemDetails**`detail` and `cause` error messages in test plan documentation for Discover, Events, Invoker Management, Provider Management, and Publish services to align responses with current certificate and ID validation behavior.
- New test plan section related with OpenCAPIF Interconnection.
- New OpenCAPIF Interconnection section under features section.
At this documentation you will have all information and related files and examples of test plan for this feature.
## Feature Description
The **CAPIF Interconnection** is a helper service within **OpenCAPIF**, allowing CAPIF Adminstration to manage the interconnection between OpenCAPIFs instances in order to create a OpenCAPIF Federation.
This test plan validates the lifecycle of the capif interconnection.
---
## Test Case 1: Interconnection 2 CCF
**Test ID**: `interconnection-1`
**Description**:
This test case verifies that the **Superadmin** can initiate the OpenCAPIF interconnection between instances.
**Pre-Conditions**:
* The **CAPIF** helper service is deployed and reachable.
* Superadmin credentials (`SUPERADMIN_USERNAME`) are provisioned.
* The database is in a clean state (no rules existing).
**Execution Steps**:
1. Authenticate as **Superadmin**.
2. Send a **GET** request to `{apiRoot}/helper/api/getCcfId` to obtain CCF_ID.
3. Send a **POST** request to `{apiRoot}/helper/interconnection/interconnect` with body [interconnection body]
