**Here we will describe most important files/packages in the server**
**Here we will describe most important files/packages in the server**
**1. ClientApi**
**1. ClientApi**
- Here we have the api that allows the client to interact with the server, each ressource is described by a route when the client choose a ressource he sends a request to an URL `\ressource` where the path is as for example: imagine yourself the client you are using the application and you chose to send a package
- Here we have the api that allows the client to interact with the server, each ressource is described by a route when the client choose a ressource he sends a request to an URL `\ressource` where the path is as for example: imagine yourself the client you are using the application and you chose to send a package
this action triggers the ressource demand to send a package i.e the URL will be `/demand` for a new demand and `\demand\[id]` when you confirm/cancel a demand.
this action triggers the ressource demand to send a package i.e the URL will be `/demand` for a new demand and `\demand\[id]` when you confirm/cancel a demand.
- The controllers that uses the different routes are to be find in [`server/clientApi/controllers/DemandsController.js`](https://gitlab.cluster.ensisa.uha.fr/devcolis/colis/-/tree/dev/server/clientApi/controllers)
- The controllers that uses the different routes are to be find in [`server/clientApi/controllers/DemandsController.js`](https://gitlab.cluster.ensisa.uha.fr/devcolis/colis/-/tree/dev/server/clientApi/controllers)
> why do we have an [id] :question: well it's simple when you create a demand you either confirm or cancel it , so we will need an id to identify the specific demand , one thig we didn't mention is that when you create a demand the request add a collection demand in mongodb doing so we have automatically have an id that will allow us to fetch and confirm/cancel a specific demand
> why do we have an [id] :question: well it's simple when you create a demand you either confirm or cancel it , so we will need an id to identify the specific demand , one thig we didn't mention is that when you create a demand the request add a collection demand in mongodb doing so we have automatically have an id that will allow us to fetch and confirm/cancel a specific demand
**2. Controllers**
**2. Controllers**
- in the [Controllers]() package we have what we will need to schedule `scheduler` and to interact with the supervisor using the robotAPI.
- in the [Controllers]() package we have what we will need to schedule `scheduler` and to interact with the `robot server` using the robotAPI.
> We call the controllers using [CRON](https://www.digitalocean.com/community/tutorials/nodejs-cron-jobs-by-examples) tasks.
> We call the controllers using [CRON](https://www.digitalocean.com/community/tutorials/nodejs-cron-jobs-by-examples) tasks.
- The management of the schedulers wasn't processed in this project if you want to know more about schedulers go [here](https://svn.ensisa.uha.fr/redmine/projects/colis/wiki/Server_Scheduler),
- The management of the schedulers wasn't processed in this project if you want to know more about schedulers go [here](https://svn.ensisa.uha.fr/redmine/projects/colis/wiki/Server_Scheduler),
- The [robotAPI.js](https://gitlab.cluster.ensisa.uha.fr/devcolis/colis/-/blob/dev/server/controllers/vehicle/robotAPI.js) file contains the functions of HTTP requests to the various supervisors.
- The [robotAPI.js](https://gitlab.cluster.ensisa.uha.fr/devcolis/colis/-/blob/dev/server/controllers/vehicle/robotAPI.js) file contains the functions of HTTP requests to the robot sever.
- The source file: [robotControllers.js](https://gitlab.cluster.ensisa.uha.fr/devcolis/colis/-/blob/dev/server/controllers/vehicle/robotController.js) contains vehicle management. it Updates the vehicle with supervisor information
- The source file: [robotControllers.js](https://gitlab.cluster.ensisa.uha.fr/devcolis/colis/-/blob/dev/server/controllers/vehicle/robotController.js) manages the robot vehicle’s workflow and status by:
1. Updating Planning: It adds new activities, verifies the vehicle’s state, notifies about each activity’s status, removes completed activities from the queue, and moves to the next one.
**3. Schema**
2. Status Synchronization: Updates the vehicle status received from the robot server and saves any changes.
- Here we the Schema that we will use to question our Mongodb. In the root of our folder we will find the main entities. You will see two other folders:
3. Error Handling: Catches and logs any errors to keep the process stable.
-**_3.1 enum_**
**3. Schema**
- Here we the Schema that we will use to question our Mongodb. In the root of our folder we will find the main entities. You will see two other folders:
Contains the values that can be taken by certain fields, as well as some information on them.
-**_3.2 subSchema_**
-**_3.1 enum_**
The entities which are used but which do not correspond to documents stored in MongoDB (typically, sub-documents with a particular schema). This approach allows methods to be associated with sub-documents that allow them to be easily manipulated. Among these sub-documents are those that correspond to the activities.
Contains the values that can be taken by certain fields, as well as some information on them.
> All the activities are defined in the ActivityInternal Folder and extends from [ActivitySchema](https://gitlab.cluster.ensisa.uha.fr/devcolis/colis/-/blob/dev/server/schema/subSchema/ActivityInternal/ActivitySchema.js).
-**_3.2 subSchema_**
> Each activity must be declared in [schemaVehicle.js](https://gitlab.cluster.ensisa.uha.fr/devcolis/colis/-/blob/dev/server/schema/schemaVehicle.js)
The entities which are used but which do not correspond to documents stored in MongoDB (typically, sub-documents with a particular schema). This approach allows methods to be associated with sub-documents that allow them to be easily manipulated. Among these sub-documents are those that correspond to the activities.
An activity has two functions (which do not have to be necessarily implemented)
-`_onExecute (vehicle)` which executes the activity for the given vehicle.
> All the activities are defined in the ActivityInternal Folder and extends from [ActivitySchema](https://gitlab.cluster.ensisa.uha.fr/devcolis/colis/-/blob/dev/server/schema/subSchema/ActivityInternal/ActivitySchema.js).
-`_onFinished (vehicle)` which executes a code before moving on to the next activity
> Each activity must be declared in [schemaVehicle.js](https://gitlab.cluster.ensisa.uha.fr/devcolis/colis/-/blob/dev/server/schema/schemaVehicle.js)
> Each activity has an `onDate` field which corresponds to the start date of the activity (`null` if as soon as possible) and `isEnded` which is set to true if the activity is completed (it will then be deleted after a call to `_onFinished` by vehicle management).
An activity has two functions (which do not have to be necessarily implemented)
-`_onExecute (vehicle)` which executes the activity for the given vehicle.
-`_onFinished (vehicle)` which executes a code before moving on to the next activity
> Each activity has an `onDate` field which corresponds to the start date of the activity (`null` if as soon as possible) and `isEnded` which is set to true if the activity is completed (it will then be deleted after a call to `_onFinished` by vehicle management).
**4. Seeds**
You will find the json files necessary to populate the Mongodb `Véhicules``ROI` (region of interest) `Paths` and `Users`
> :warning: do not change the name of this folder , if you want to edit the json files you have to respect the schema described in the principal [`Schema`](https://gitlab.cluster.ensisa.uha.fr/devcolis/colis/-/tree/dev/server/schema) scripts
**4. Seeds**
>
> :warning: Another thing , if you changed the map in the [configuration.json](https://gitlab.cluster.ensisa.uha.fr/devcolis/colis/-/blob/dev/docker/komnav/bin/configuration.json)
You will find the json files necessary to populate the Mongodb `Véhicules``ROI` (region of interest) `Paths` and `Users`
you will have to do the same thig to the `ROI.json` and `paths.json` files (while of course respecting the schema)
> :warning: do not change the name of this folder , if you want to edit the json files you have to respect the schema described in the principal [`Schema`](https://gitlab.cluster.ensisa.uha.fr/devcolis/colis/-/tree/dev/server/schema) scripts
**5. Utils**
>
> :warning: Another thing , if you changed the map in the [configuration.json](https://gitlab.cluster.ensisa.uha.fr/devcolis/colis/-/blob/dev/docker/komnav/bin/configuration.json)
In this folder you will find some tools ( a Mailer to send some email `ParamsManager` stores some parameters necessary to establish connections
you will have to do the same thig to the `ROI.json` and `paths.json` files (while of course respecting the schema)
\ No newline at end of file
**5. Utils**
In this folder you will find some tools ( a Mailer to send some email `ParamsManager` stores some parameters necessary to establish connections
**6. RobotServerApi**
- Here we have the api that allows the `robot server` to interact with the `server`.
- The [RobotServerApi.js]
(https://gitlab.cluster.ensisa.uha.fr/devcolis/colis/-/blob/dev/server/robotServerApi/RobotServerApi.js) provides HTTP request functions that allow the robot server to communicate with the colis server `server`, sending requests to update and retrieve vehicle information as needed using the `robotController.js`.
- The [RobotServerApiEntity.js]
provides HTTP request functions enabling the robot server to communicate with the colis server, specifically to retrieve vehicle planning and the demands associated with it.
