Micro-services structure

The organization in micro-services of the scheduler application consists of 4 parts: Front-end, Back-end, Database and Connection.

Front end : The front-end is an developed under React. The front-end will receive data in JSON format from the back-end and will be rendered in Html to display on the browser.

Backend : The back-end consists of multiple services:
- “Task Service”: service allowing generic management of tasks. Tasks can be tasks in a project, a delivery, a ticket issue...
- “Validation Service”: validation task management service that is often generated after the end of a task from the “Task Service”
- “Pattern Service”: task structure backup service that can be used in the future to regenerate the same types of tasks. A task can be transformed like a model, and conversely it can be generated from a model.
- “Task Dependency Service”: the service takes care of the relationships between tasks. A task may require information from one or more tasks, so these tasks must be completed before this task begins.
- “Notification Service”: the service supports all notifications, whether by e-mail or otherwise. For example, a notification can be triggered when information about a task changes. All affected persons will be informed of the changes.
- "ScheduleBot": the service is a bot that will be used to schedule tasks.
- "ArchiveService": the service is used to archive tasks.

Database : Each service has an independent database, except for the notification service. I used the Hsql database (HyperSql Database). It is a relational database written in Java. Its advantage is lightness and therefore has a fast multithreading engine.

Connection : Connection services include all services that support communication between front-end and back-end, and communication between micro-services.
Between the front-end and the back-end, a flux API interface is developed with Node-Red. From this interface, incoming and outgoing http connections are managed. All information about requests and responses is logged through this interface.
At the entrance of the micro-services, an API gateway is developed with Spring Cloud Gateway. All changes of direction are controlled by this service.
Microservices can communicate with each other through the Eureka registration server. All services will register with the Eureka server to know the addresses of others. Thanks to this server, we can deploy several instances on several addresses for a service.
Some events do not require an immediate response to the front-end, they will be put in a message queue to be processed later by the dedicated service. We used Kafka for the messaging platform. A service can register as a "producer" and/or a "consumer". The "producer" produces the message and the "consumer" uses the message.

Class diagram

Task status change procedure

Task state change is an important element in this application. Some statuses of the validation and the task are linked, so they require corresponding updates. Communication of state changes is done via Kafka.
To begin the flow of state changes, the starting point is to create a task whose state is “INITIATED”. The task is then declared in progress by the manager, its status therefore changes to “IN_PROGRESS”. Then the status can only be set to "PAUSED" or declare that the task is finished, so its status will change to "FINISHED".
From its “FINISHED” state, a message is sent to Kafka and the validation service will receive this message. If a validation is marked, the validation service will initiate a validation task corresponding to the requested task. The validation is in the "INITIATED" state and the originating task is in the "WAITING_FOR_VALIDATION" state.
When the validator declares its start of validation processing, the validation switches to "IN PROGRESS" and the task switches to "IN_VALIDATION". The validation can then be set to "PAUSED", "VALIDATED" or "REJECTED", so the task will also respectfully change "VALIDATION_PAUSED", "VALIDATED" and "REJECTED".
If the validation is refused, a new task will be created from the rejected task. All subtasks are also regenerated. We return to the starting point.

Spring Boot Dependencies

Example Java code of task creation

React Dependencies