update api_tag in Feature-Development-Guide

- To allow the `meep-virt-engine` service to deploy the new service's pod, the service should be added to the following sections:

  - `repo.sandbox.go-apps.meep-virt-engine.docker-data`

  - `repo.sandbox.go-apps.meep-virt-engine.sandbox-pods`

  >**NOTE:** These settings will enable the `meep-virt-engine` to deploy the new service by default upon each user sandbox creation. For configuring the new service to only get deployed upon selection of a certain network scenrio, see [Network Scenarios](./network-scenarios.md#adding-a-new-service-in-an-existing-network-scenario).

  >**NOTE:** These settings will enable the `meep-virt-engine` to deploy the new service by default upon each user sandbox creation. For configuring the new service to only get deployed upon selection of a certain network scenario, see [Network Scenarios](./network-scenarios.md#adding-a-new-service-in-an-existing-network-scenario).

- Add client for the new service in `repo.packages.go-packages` section (if one is available/required)

- Add information for the new service in the monitoring engine section `repo.sandbox.go-apps.meep-mon-engine.sandbox-pods`

Additionally for making the Swagger UI available in the Sandbox frontend for the new service, these steps need to be taken:

1. Copy the Swagger or OpenAPI specifications of the new MEC Service from backend (available under `mec-sandbox/go-apps/meep-<mec-identifier>/api/swagger.yaml`) to `mec-sandbox/config/api/` folder and rename the file from `swagger.yaml` to `<mec-identifier>-api.yaml`.

1. Copy the Swagger or OpenAPI specifications of the new MEC Service from backend (available under `AdvantEDGE/go-apps/meep-<mec-identifier>/api/swagger.yaml`) to `mec-sandbox/config/api/` folder and rename the file from `swagger.yaml` to `<mec-identifier>-api.yaml`.

    > **Note:** In case of multiple APIs, copy each Swagger or OpenAPI specifications of the new MEC Service from the backend (available under `mec-sandbox/go-apps/meep-<mec-identifier>/api/<api_tag_i>/swagger.yaml`) to the `mec-sandbox/config/api/<api_tag_i>/` subfolder.

    > **Note:** In case of multiple APIs, copy each Swagger or OpenAPI specifications of the new MEC Service from the backend (available under `AdvantEDGE/go-apps/meep-<mec-identifier>/api/<api_tag_*>/swagger.yaml`) to the `mec-sandbox/config/api/<api_tag_*>/` subfolder.

3. After performing the above, do the following:

2. After performing the above, do the following:

    - Customize the YAML to hide unnecessary endpoints in the UI

    - Add necessary license description in the `info` section

4. Add this location of OAS yaml in the `repo.sandbox.go-apps.<mec-identifier>.user-api` section of `.meepctl-repocfg.yaml` file

3. Add this location of OAS yaml in the `repo.sandbox.go-apps.<mec-identifier>.user-api` section of `.meepctl-repocfg.yaml` file

In addition to `.meepctl-repocfg.yaml` file, the following files will need to be updated when creating a new micro-service:

- `mec-sandbox/config/long-term-storage-repocfg.yaml`

After the correct network scenario is selected in the MEC Sandbox UI, make sure that the new MEC service is not being shown in the [box](../Sandbox-User-Interface/README.md#sbox04) under _MEC App. Instance IDs_.

### 3. Communication with the common message bus

Check the logs of the container running the microservice and see if it is sending and receving messages on the common message bus. If there is no logic for sending messages through SBI, at least the service should be receiving periodic "SCENARIO-UPDATE" messages for different events related to UE mobility etc.

Check the logs of the container running the microservice and see if it is sending and receiving messages on the common message bus. If there is no logic for sending messages through SBI, at least the service should be receiving periodic "SCENARIO-UPDATE" messages for different events related to UE mobility etc.

### 4. Successful responses from the service API

Send a request to one of the exposed endpoints of the new service using _curl_, _Postman_ or any other tool to verify that the service is returning valid responses through its NBI according to the developed emulation logic.

     |

     \____ go

            |

            \____ api_<api_tag_i>.go

            \____ api_<api_tag_*>.go

            |

            \____ api_unsupported.go

            |

            |

            \____ 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.

There may be multiple files for `api_<api_tag_*>` and `model_<model_name>` depending on the tags and component schemas in the OAS file used to generate the server stubs.

> Note: _i_ in _api_tag_i_ used to indicate any single API.

> Note: _*_ in _api_tag_*_ used to indicate any single API.

Steps to implement server side emulation logic for multiple APIs:

2. **Copying _API_ Folder**

   From the generated server stubs for each API, copy the `api/swagger.yaml` file to the corresponding `api/<api_tag_i>` sub-folder for multiple APIs scenario.

   From the generated server stubs for each API, copy the `api/swagger.yaml` file to the corresponding `api/<api_tag_*>` sub-folder for multiple APIs scenario.

> Note: _*_ in _api_tag_*_ used to indicate any single API.

3. **Copying _Go_ Folder**

   For multiple APIs scenario, create sub-folders with specific `<api-tag_i>` name under `server` folder for each API. Then copy `api_<api_tag_i>.go`, `api_unsupported.go` (if any), `model_<model_name>.go` and `README.md` files from each API `go` folder to its specific `<api-tag_i>` folder.

   For multiple APIs scenario, create sub-folders with specific `<api-tag_*>` name under `server` folder for each API. Then copy `api_<api_tag_*>.go`, `api_unsupported.go` (if any), `model_<model_name>.go` and `README.md` files from each API `go` folder to its specific `<api-tag_*>` folder.

4. **Modify _main.go_**

6. **Create the service handler file**

   Create `server/<mec-identifier>.go` and `server/<api_tag_i>/<api_tag_i>.go` files. The `server/<mec-identifier>.go` file will contain all the common handler functions for endpoints and the emulation logic for all the APIs in that service. And `server/<api_tag_i>/<api_tag_i>.go` file will contain all the handler functions for endpoints and the emulation logic for that specific service API.

   Create `server/<mec-identifier>.go` and `server/<api_tag_*>/<api_tag_*>.go` files. The `server/<mec-identifier>.go` file will contain all the common handler functions for endpoints and the emulation logic for all the APIs in that service. And `server/<api_tag_*>/<api_tag_*>.go` file will contain all the handler functions for endpoints and the emulation logic for that specific service API.

7. **Implement handler function for unsupported endpoints**

   In the `server/<api_tag_i>/api_unsupported.go` file (if 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:

   In the `server/<api_tag_*>/api_unsupported.go` file (if 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:

   ```go

   func notImplemented(w http.ResponseWriter, r *http.Request) {

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.

   Remove the previous code in each of the `server/<api_tag_*>/api_<api_tag_*>.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 (If required)**