-[Upgrading an existing MEC Service](#upgrading-an-existing-mec-service)
This guide contains all the steps that need to be taken for introducing a MEC service as a new feature in the MEC Sandbox frontend and the AdvantEDGE backend.
@@ -59,4 +60,13 @@ There are three main aspects that need to be taken care of regarding MEC Sandbox
- Swagger UI integration
- Grafana dashboard for monitoring service-related metrics
See [Frontend Enhancement](./frontend-enhancements.md) for details on how to integrate the new feature into AdvantEDGE.
See [Frontend Enhancement](./frontend-enhancements.md) for details on how to upgrade the MEC Sandbox frontend for the new feature.
## Upgrading an existing MEC Service
The above sections are strictly related to adding a new service in the MEC Sandbox. However, there may be a need for updating an existing MEC service in the Sandbox as part of feature enhancements.
In that case, there are some aspects that need to be taken into consideration while upgrading an existing MEC Service API in MEC Sandbox for both frontend and backend.
See [Service Upgradation Guide](./service-upgradation.md) for details on how to upgrade an existing MEC service.
-[Changes in backend code](#changes-in-backend-code)
-[Data Models](#data-models)
-[NBI code](#nbi-code)
-[SBI code](#sbi-code)
-[Updating Tests](#updating-tests)
This guide documents all the aspects of an existing MEC service that need to be taken into account when upgrading a MEC service based on the version of its associated group specifications document. For example, upgrding MEC-012 RNI service in Sandbox according to the changes in ETSI GS MEC-012 specs between versions v2.1.1 and v2.2.1 would require following steps:
## Changes in the Specification Documents
1. Gather delta requirements by comapring the version of the MEC specs on which the service is currently based on in the Sandbox with the desired version of the specs.
2. Update the OpenAPI specifications (OAS) if they are not already available on Forge for the desired version.
## Code Generation from the latest OAS
This aspect requires careful deliberation as the automated code generation tools are used to generate code for the data models and HTTP methods of API endpoints specified in the OAS. Here we are using the tools to update the existing code. So manual validation of generated data models needs to be done. Furthermore, the code for HTTP methods can include changes that may have been made after the code-generation. Therfore, manual modifications need to be made to avoid any breaking changes in code.
* OAS for latest MEC APIs are based on OAS `3.1` version and there are not a lot of credible tools out there that support code generation for OAS `3.1`.
* Therefore, the OAS will need to be downgraded from OAS version `3.1` to `3.0`. Procedure for this is documented [here](development-guide.md#generating-server-and-client-side-code).
* It is advised to validate the downgraded OAS using Swagger UI and confirm if all the endpoints, HTTP methods, data models are being rendered in the UI properly.
* The OAS file `swagger.yaml` inside the service's code directory (under ./api folder) will need to be updated with the latest OAS. These two specs are not exactly the same as the `swagger.yaml` OAS contains some additional MEC-011 endpoints. Therefore, careful update of this file needs to be made as well.
## Swagger UI for MEC Sandbox Frontend
MEC Sandbox offers its users an option to make API calls to a MEC service using the Swagger UI from the browser. This browser client uses the OAS file of a specific MEC service for rendering its UI.
This file is hosted in the [MEC Sandbox frontend repository](https://forge.etsi.org/rep/mec/mec-sandbox) on Forge and needs to be updated according to the latest changes in the OAS for the desired version to which the service is being upgraded to.
Consult the [Swagger UI generation](backend-integration.md#swagger-ui-generation
) clause of the backend integration guide for further information.
## Client-side Code Update
In AdvantEDGE (backend for MEC Sandbox), all MEC services contains their clients in the form of Go packages. They are hosted in the `./go-packages` directory in [AdvantEDGE source code](https://github.com/InterDigitalInc/AdvantEDGE).
These packages are auto-generated client SDKs from OAS. Use the latest and validated OAS to update the client-side code automatically. No manual changes are required. See [client-side code generation](development-guide.md#client-sdk) for more information.
## Changes in backend code
MEC services are implemented as Go applications (placed in `./go-apps` folder [here](https://github.com/InterDigitalInc/AdvantEDGE)) in AdvantEDGE. These apps are deployed as microservices in a Kubernetes-native environment when AdvantEDGE is deployed for MEC Sandbox.
More information on this backend code can be found in the [development guide](development-guide.md).
Aspects that need to be addressed in the backend code are given below:
### Data Models
Data models (go structs) for the MEC service will need to be updated based on the models that were generated during code generation in [this step](#code-generation-from-the-latest-oas).
### NBI code
1. Handler functions for the HTTP methods of respective endpoints will need to be updated if there are any changes in the MEC specification documents for those endpoints.
2. In case new endpoints or HTTP methods or both are added in the desired specification version, handler functions will need to be written for them in the backend code.
3. Emulation logic and functional implementation will need to be added in backend for the newly added endpoints and HTTP methods respectively.
4.**Data model related changes in NBI code:**
- Validation checks for mandatory attributes in the incoming request
- Population of (mandatory) attributes while generating the response for a particular HTTP method
### SBI code
SBI code may need to be changed for two cases:
1.**Emulation Logic:** In case some emulation logic for a new endpoint or a method requires interaction with platform services or supporting packages through the application's South Bound Interface.
2.**Data model related changes in SBI code:** In case a standard data model being used in the SBI code has been changed in the MEC specification documents. New data model and its attributes need to be taken into accound wherever that data model is being used in the SBI code.
## Updating Tests
For each microservice, there are unit and tests written that test the functions in backend code. These tests sometimes use dummy input values based on standard data models for requests to validate the functionality of emulation logic.
Therfore, the tests will need to be enhanced if there are any changes in the updated version of MEC specification document regarding the data models that are being used in the tests.
