evillord666 / cassette Goto Github PK

Необходимо реализовать тесты в отдельном профиле (functests) - application-functests.yml (ЭТУ ЗАДАЧУ РЕАЛИЗОВАТЬ ПОСЛЕ РЕАЛИЗАЦИИ ПРОФИЛЕЙ)

Методология работы тестов должна быть следующей при КАЖДОМ тесте:

1. Создается новая БД перед тестом
2. В БД создается структура БД (таблицы, индексы, констрэйнты)
3. Создаются начальные данные в виде sql-скрипта и вставки этих данных в виде insert инструкций. Это ДОЛЖЕН быть ЕДИНЫЙ скрипт для всех тестов (должен располагаться в src\main\resources\data\db_test_data.sql)
4. Выполняет тестирование работы с моделью (чтение, сохранение, удаление) при этом особое внимание следует уделить заданию значений по умолчанию, установки связей (Null | не Null) и тестирования каскадности (удаление, обновление). Тестирование моделей осуществляется через их репозитории IBrokerTypeRepository и IBrokerRepository
5. Удаление (дроп) БД

Подготовить набор:

• классов моделей entity (пакет cassette.application.model.entities). Каждый класс модели должен иметь суффикс Entity
• репозиториев (пакет cassette.application.model.repositories) Каждый интерфейс репозитория должен иметь суффикс Repository

Кроме того необходимо создать агрегирующий интерфейс, в котором нужно создать контракт для получения интерфейсов всех репозиториев (IDbContext) и его имплементацию RockNRollDbContext (ну типа живи быстро, умри молодым, дело в том, что Scope этой имплементации - Request)

Рекомендуется подготовить VirtualBox виртуальную машина с Linux ОС (например, Mint)
Необходимо ее оснастить:

• Java (13)
• Mysql
• Maven & Gradle
• Brokers (Kafka & Rabbit & Active Mq)

После завершения реализации DTO необходимо подготовить:

1. классы фабрик BrokerTypeFactory и BrokerFactory в пакете factory для конструирования DTO из Entity
2. классы api контроллеров BrokerTypeController (/api/brokertype) и BrokerController (/api/broker) для выполнения CRUD-операций с типами брокеров и брокерами

Требования к методам:

• GET /api/{resource} для получения коллекции брокеров
• GET /api/{resource}/id для получения ресурса по id
• POST /api/{resource} для создания экземпляра ресурса
• PUT /api/{resource}/id для редактирования экземпляра ресурса
• DELETE /api/resource/{id} для удаления экземпляра ресурса

При создании, обновлении и удалении ресурса все операции необходимо вынести в классы -менеджеры (создать пакет managers) для управления ресурсами - BrokerTypeManager и BrokerManager

Необходимо разработать схему БД с учетом того, что приложение должно выполнять следующие функции:

1. Подключение к брокерам сообщений: RabbitMq, Apache Kafka , Active Mq
2. Получение списка топиков, создание/удаление топиков
3. Очистка сообщений из очередей
4. Формирование сообщения и возможность отправки его как броадкастом, так и определенному адресату

Для этого в БД необходимо хранить информацию о брокерах и настройках подключения к ним, сообщения (вероятно, необходимо еще хранить и список адресатов). Поскольку сами сообщения могут быть большими (десятки мегабайт), необходимо сохранять их в файловой системе. Также для каждого сообщения необходимо хранить статус. Кроме того одно сообщение можно отправлять разным брокерам, поэтому это также нужно учесть при проектировании схемы.

Само приложение должно называться как и этот репо - cassete. Для SpringBoot есть инициализатор при работе инициализатора нужно сконфигурировать приложение т.о., чтобы оно использовало Gradle скрипт для сборки, СУБД Postgres, Liquibase (для миграции использовать консольную утилиту: https://github.com/Wissance/SpringUu/blob/master/tools/generateMigration.ps1).

При конфигурировании вариант для сборки через Gradle, но также нужно добавить сборку через maven и проверить, что приложение собирается в запускаемый jar (spring-boot-starter)

По аналогии с задачей #15 необходимо подготовить интерфейс и имплементацию (скоуп Request) для:

• управления брокером (получение списка очередей, наличия сообщений в очередях, управление очередями: создание/модификация/удаление), очистка очереди от сообщений (как одного конкретного, так и целиком)
• чтение сообщения из очереди (с параметром , позволяющим удалить при чтении)
• отправка сообщения в очерь(набор очередей) и бродкастом (см. предварительное предложение реализации в задаче по ссылке выше)

Параметры подключения к брокеру - передавать в конструкторе класса, имплементирующего интерфейс

В рамках данной задачи необходимо проверить гипотезу о работоспособности данных методов, а также рассмотреть/предложить другие варианты. Инструмент для отправки сообщений по расписанию будет описан в отдельной задаче

Для каждого entity-класса за исключением базовой entity необходимо реализовать набор DTO для последующего использования в контроллерах Web API:

• AccountEntity
• BrokerTypeEntity
• BrokerEntity
• MessageStatusEntity
• MessageEntity

Необходимо в пакете DTO добавить класс DtoTags для того, чтобы форматировать имена полей JSON в формате undderscore, например:

{
    "broker_type": {
        "id": 1,
        "name": "kafka"
    }
}

В данном компоненте должна выполняться работа с отдельными брокерами сообщений внутри Callable-воркеров, которым на вход передаются данные необходимые для:

• создание экземпляра сервиса подключения к Kafka / ActiveMq
• отправка сообщений в брокер

Данный компонент, вероятно, должен быть синглтоном, внутри него должен выполняться регулярный поток, завершающийся вместе с приложением. Этот компонент работает следующим образом : проверяет наличие сообщений, которые нужно отправить (ну или анализирует расписание отправки и текущее время), если сообщения есть использует один из ранее созданных воркеров (их число должно быть ограничено настройками) , выбирает свободный воркер и передает в него всю нужную информацию, а воркер в свою очередь выполняет отправку сообщения

После завершения реализации DTO необходимо подготовить:

1. класс фабрики AccountFactory в пакете factory для конструирования DTO из Entity
   класс api контроллера AccountController (/api/account) для выполнения CRUD-операций с учетными записями брокеров

Требования к методам:

GET /api/account для получения коллекции учетных записей (УЗ), хеши возвращать не нужно
GET /api/account/id для получения УЗ по id
POST /api/account для создания УЗ (здесь мы передаем пароль в открытом виде)
PUT /api/account/id для редактирования УЗ (здесь мы передаем пароль в открытом виде)
DELETE /api/account/{id} для удаления УЗ, при удалении брокер не должен удаляться

При создании, обновлении и удалении УЗ все операции необходимо вынести в класс -менеджер (создать пакет managers) AccountManager

Также нужно создать класс сервис, выполняющий генерацию хэша, хэш не хуже HmacSha256, но можем рассмотреть и др. варианты. Кроме того в приложении должна задаваться приправа в application_{profilename}.yml и дефолтная приправа в application.yml. работает это так: сохраняемый в БД хэш = приправа + хэш пароля

Необходимо реализовать тесты в отдельном профиле (functests) - application-functests.yml (ЭТУ ЗАДАЧУ РЕАЛИЗОВАТЬ ПОСЛЕ РЕАЛИЗАЦИИ ПРОФИЛЕЙ)

Методология работы тестов должна быть следующей при КАЖДОМ тесте:

1. Создается новая БД перед тестом
2. В БД создается структура БД (таблицы, индексы, констрэйнты)
3. Создаются начальные данные в виде sql-скрипта и вставки этих данных в виде insert инструкций. Это ДОЛЖЕН быть ЕДИНЫЙ скрипт для всех тестов (должен располагаться в src\main\resources\data\db_test_data.sql)
4. Выполняет тестирование работы с моделью (чтение, сохранение, удаление) при этом особое внимание следует уделить заданию значений по умолчанию, установки связей (Null | не Null) и тестирования каскадности (удаление, обновление). работа с моделью тестируется через ее репозиторий - IAccountRepository
5. Удаление (дроп) БД

Необходимо создать интерфейс и имплементацию со скоупом Request

ДАННЫЙ ИНТЕРФЕЙС является ПРЕДПОЛОЖИТЕЛЬНЫМ и, ВОЗМОЖНО, он что-то не учитывает. В любом случае необходимо проанализировать какие возможности у нас есть для управления самим брокером и отправки и получения сообщений

public interface IKafkaMessageBroker {
    // Управление топиками
    List<TopicInfo> getAllTopic();
    TopicInfo createTopic(String name);
    Boolean deleteTopic(String name);
    updateTopic(String oldName, String newName);
    Long countTopicMessages(String topicName);
    // Интерфейс чтения и отправки сообщений
   Boolean send(List<String> topics, String message);
   Boolean sendBroadcast(String message);
   MessageData receive(String topicName, Long number, Booleab deleteOnReceive);
}

где:

• TopicInfo - класс, который в себе содержит информацию о имени топика и его партишионе
• MessageData - класс, описывающий сообщение и его метаданные

Нам не подойдет использование Kafka из spring, т.к. в любой момент времени мы можем иметь сколько угодно подключений к разным брокерам Kafka (насколько я понял в Spring мы можем использовать только один).

Для управления брокером сообщений необходимо использовать Kafka Admin API (пример смотри здесь - https://www.logicbig.com/tutorials/misc/kafka/admin-api-getting-started.html)

Параметры подключения к брокеру - передавать в конструкторе класса, имплементирующего интерфейс

В рамках данной задачи необходимо проверить гипотезу о работоспособности данных методов, а также рассмотреть/предложить другие варианты. Инструмент для отправки сообщений по расписанию будет описан в отдельной задаче

Необходимо добавить возможность конфигурирования приложения черз yml файлы, при этом наиболее общие настройки должны быть вынесены в src\main\resources\application.yml, а более специфичные в src\main\resources\application_{profilename}.yml

У нас будут следующие профили ({profilename}):

• local
• develop
• production
• functests
• inegrtests

Необходимо проверить, что при старте приложения подхватывается нужный профиль, для этого предлагается создать дополнительный api контроллер InfoController (/api/info) и реализовать в нем метод GET /api/info

Этот метод должен возвращать на данном этапе следующую информацию:

• профиль - имя профиля
• используемую БД (класс драйвера, URL сервера БД и имя используемой БД)

Также в рамках этой задачи необходимо подготовить DTO - ApplicationInfoDto в пакете dto и фабрику ApplicationInfoFactory