-[Unit tests for the new micro-service](#unit-tests-for-the-new-micro-service)
-[System tests for the new micro-service](#system-tests-for-the-new-micro-service)
-[Integration tests for the new micro-service](#integration-tests-for-the-new-micro-service)
-[Executing a test campaign](#executing-a-test-campaign)
-[System tests for the new micro-service](#system-tests-for-the-new-micro-service)
-[Adding Documentation for an API/Service](#adding-documentation-for-an-apiservice)
-[Dockerization](#dockerization)
-[Creating a Dockerfile](#creating-a-dockerfile)
-[Usefull K8s commands](#usefull-k8s-commands)
This guide gives a high-level overview of all the steps that need to be taken for introducing a new MEC Service in the MEC Sandbox. It documents the overall development-related aspects that need to be covered while introducing a new service in the AdvantEDGE backend. The integration aspects for feature-development are listed in [Backend Integration](./backend-integration.md).
@@ -229,6 +231,201 @@ meep-<mec-identifier>
\____ <mec-identifier>.go
```
### Server-side (multiple APIs)
After the server stubs have been generated for each APIs separately (see [server stubs](#server-stubs)), the folder structure for single API will be something like the structure shown below:
```
meep-<mec-identifier>
|
\____ main.go
|
\____ api
| |
| \____ swagger.yaml
|
\____ go
|
\____ api_<api_tag_i>.go
|
\____ api_unsupported.go
|
\____ logger.go
|
\____ model_<model_name>.go
|
\____ README.md
|
\____ routers.go
```
There may be multiple files for `api_<api_tag_i>` and `model_<model_name>` depending on the tags and component schemas in the OAS file used to generate the server stubs.
Steps to implement server side emulation logic for multiple APIs:
1.**Creating new folder structure**
The folder structure for multiple APIs will be something like the structure shown below:
```
meep-<mec-identifier>
|
\____ main.go
|
\____ api
| |
| \____ <api_tag_1>
| | |
| | \____swagger.yaml
| |____ <api_tag_2>
| |
| \____swagger.yaml
|
\____ server
|
\____<api_tag_1>
| |
| \____ api_<api_tag_1>.go
| |
| \____ api_unsupported.go
| |
| \____ model_<model_name>.go
| |
| \____ README.md
|
\____<api_tag_2>
| |
| \____ api_<api_tag_2>.go
| |
| \____ api_unsupported.go
| |
| \____ model_<model_name>.go
| |
| \____ README.md
|
|
\____ routers.go
|
\____ logger.go
```
2.**Copying _API_ Folder**
According to the multiple APIs folder structure, `swagger.yaml` file present under `api` folder of each single API is added in their corresponding `api/<api_tag_i>` sub-folder for multiple APIs scenario.
3.**Copying _Go_ Folder**
According to the multiple APIs folder structue, sub-folders are added with specific `<api-tag_i>` name under `server` folder for each API. Now copy `api_<api_tag_i>.go`, `api_unsupported.go`, `model_<model_name>.go` and `README.md` files from `go` folder of each single API folder structure to its specific `<api-tag_i>` folder for multiple APIs scenario.
4.**Modify _main.go_**
Remove the code in _main.go_ file of multiple API folder structue and add the following function(s) to it:
- _main()_: This will be the main function which calls the other functions to initialize the service
- Add an anonymous function inside the _main()_ function which will initialize the service
- Add another anonymous function inside the _main()_ function which will initialize the metrics endpoint
**NOTE:** Observe the _main.go_ files in existing AdvantEDGE / Sandbox services to validate your code.
5.**Copy and Modifying Routers**
Firstly, copy the `router.go` file of any single API folder structure to `router.go` of multiple API folder structue. Then keep on adding the routes in `route` array structure from `router.go` file of other APIs in this file.
Now, in the `server/routers.go` file, make the following changes:
- Add new handler for `/api` and `/user-api` endpoints for Swagger UI
- Remove `/sandboxname` before each endpoint in the _routes_ if it appears
- Import the `AdvantEDGE/go-packages/meep-metrics` package and add the `MetricsHandler()` handler function for the metrics for Grafana dashboard.
> Other MEC services in AdvantEDGE can be referred to for implementing the above changes.
6.**Create the service handler file**
Create a `server/<mec-identifier>.go` and `server/<api_tag_i>/<api_tag_i>.go` files. This `server/<mec-identifier>.go` file will contain all the common handler functions for endpoints and the emulation logic for the service while `server/<api_tag_i>/<api_tag_i>.go` will contain all the handler functions for endpoints and the emulation logic for the specific service APIs
7.**Implement handler function for unsupported endpoints**
In the `server/<api_tag_i>/api_unsupported.go` file (if it exists), for each of the handler functions, replace the previous code with `notImplemented(w, r)` and add this function in the `server/<mec-identifier>.go` as follows:
8.**Separate handler function(s) for the endpoints**
Remove the previous code in each of the `server/<api_tag_i>/api_<api_tag_i>.go` file and replace it with a handler function. Implement all those handler functions in the `server/<mec-identifier>.go` file.
9.**Implement SBI Communication Logic**
The new MEC service will need to communicate with other AdvantEDGE/Sandbox services to, for example, get updated scenario information via South Bound Interface (SBI). To do this, create a `server/sbi` folder and create a `<mec-identifier>-sbi.go` file in it. Implement all the communication and initialization related logic of SBI in this file. This will include communication with the message queue and Redis cache from where it will obtain the necessary information.
Initialization of the SBIs and logic for receiving information from them will need to be implemented in the `server/<mec-identifier>.go` file. Communication with SBI will be initiated as soon as the MEC service (or service pod) is up and running.
> Other MEC services in AdvantEDGE can be referred to for implementing the SBI communication logic.
10.**Creating _go.mod_ and _go.sum_ files**
Run the following commands to create the _go.mod_ and _go.sum_ files:
```sh
go mod init github.com/InterDigitalInc/AdvantEDGE/go-apps/meep-<mec-identifier>
go mod tidy
```
After doing the above steps, the files will look something like the file/folder structure shown below:
```
meep-<mec-identifier>
|
\____ main.go
|
\____ go.mod
|
\____ go.sum
|
\____ sbi
| |
| \____ <mec-identifier>-sbi.go
|
\____ api
| |
| \____ <api_tag_1>
| | |
| | \____swagger.yaml
| |____ <api_tag_2>
| |
| \____swagger.yaml
\____ server
|
\____<api_tag_1>
| |
| \____ api_<api_tag_1>.go
| |
| \____ api_unsupported.go
| |
| \____ <api_tag_1>.go
| |
| \____ model_<model_name>.go
| |
| \____ README.md
|
\____<api_tag_2>
| |
| \____ api_<api_tag_2>.go
| |
| \____ api_unsupported.go
| |
| \____ <api_tag_2>.go
| |
| \____ model_<model_name>.go
| |
| \____ README.md
|
\____ <mec-identifier>.go
|
\____ routers.go
|
\____ logger.go
```
### Client-side
During the phase of code generation (see [code generation](#generating-server-and-client-side-code)), two stubs of code are generated:
1. The server code (see clause [Server stubs](#server-stubs))
