update meep-applications typo and fix other typos

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`.

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

    > **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.

3. After performing the above, do the following:

    - Customize the YAML to hide unnecessary endpoints in the UI

## _meep-applications_ Configuration

To make the new service be properly recognizable by the MEC Sandbox frontend, it will need to be added in the `SysAppNames` variable in `AdvantEDGE/go-packages/go-applications/application.store.go` file. This will make sure that the new service is recognized as a service and not as an application instance.

To make the new service be properly recognizable by the MEC Sandbox frontend, it will need to be added in the `SysAppNames` variable in `AdvantEDGE/go-packages/meep-applications/application.store.go` file. This will make sure that the new service is recognized as a service and not as an application instance.

## Upgrade MEC Sandbox

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.

### 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 accroding to the developed emulation logic.

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.

### 5. Swagger UI for the new service

Follow these steps to validate successful Swagger UI generation for the new 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)

- [Useful K8s commands](#useful-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).

```

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.

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

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

Steps to implement server side emulation logic for multiple APIs:

As a next step, code included in the directory structure above will be added into AdvantEDGE's fork repository. See [Code Integration](./backend-integration.md#code-integration) for more details.

# Usefull K8s commands

# Useful K8s commands

This clause provide a set of usefull K8s command lines for debugging micro-service and demo applications.

This clause provide a set of useful K8s command lines for debugging micro-service and demo applications.

The commands (and their outputs) are just examples:

- <i>demo4sb</i> is the Sandbox named

- <i>meep-dai</i> is the DAI (MEC-016) micro-services.

- To retrieve list of pods

```bash

$ kubectl get pods -A

$ kubectl get pods --all-namespaces

```

- To retrieve pod descriptions such as internal IP address, Volumes...

```bash

$ kubectl describe pod meep-dai-8fb98975b-6jf9p -n demo4sb

$ kubectl describe pod meep-<mec_identifier>-<deploy_id>-<pod_id> -n <namespace>

```

- To retrive pod logs into a text file named out_dai.txt

- To retrieve pod logs into a text file named out.txt

```bash

$ kubectl logs meep-dai-8fb98975b-6jf9p -n demo4sb > out_dai.txt

$ kubectl logs meep-<mec_identifier>-<deploy_id>-<pod_id> -n <namespace> > out.txt

```

- To retrive pod's container logs into a text file named out_demo.txt

- To retrieve pod's container logs into a text file named out.txt

```bash

$ kubectl logs demo4-ue1-7f8c7d8746-9vv7m demo4-ue1 -n demo4sb > out_demo.txt

$ kubectl logs meep-<mec_identifier>-<deploy_id>-<pod_id> <container_name> -n <namespace> > out.txt

```