Отправьте запрос PUT / GET / POST в JHipster за одну транзакцию

#jhipster

#jhipster

Вопрос:

Я новичок в Jhipster, и у меня проблемы с пониманием некоторых его функций. Следовательно, вот мой вопрос.

У меня есть следующие два микросервиса. Микросервис 1 (MS1) имеет следующие структуры данных на Java:

 Lead {
Customer customer;
Deal deal;
}

Customer{
Integer phoneNumber;
etc...
}

Deal{
Integer value;
etc...
}
  

Микросервис 2 (MS2) — это база данных, созданная JHipster.
В базе данных есть только следующие таблицы SQL :

 CUSTOMER
LEAD
  

Когда в микросервисе 1 происходят изменения, я отправляю 2 отдельных запроса PUT с MS1 на MS2.

  • сначала запрос на обновление КЛИЕНТА через /customer API в MS2
  • если обновление в порядке, отправьте запрос на обновление DEAL /deal API в MS2

Для успешного обновления для потенциальных клиентов, отправки запросов клиенту, сделки все должно быть в порядке. Если обновление одной таблицы завершается неудачей, все должно завершиться неудачей.

Следовательно, я хотел бы избежать отправки 2 отдельных запросов, чтобы избежать случая, когда запрос КЛИЕНТА в порядке, а запрос на сделку по какой-либо причине не выполняется. Если возможно, я хотел бы отправить одну транзакцию через API, например, /lead который обрабатывает две таблицы..

Каков наилучший способ добиться этого, не создавая дополнительную таблицу для LEAD? например, слой / сервис, который я должен сгенерировать с помощью Jhipster. Если возможно (но не обязательно), я бы хотел не касаться кода, который часто обновляется. (например, Клиент, сделка)

Пожалуйста, любезно направьте меня к документации, если она уже существует. Их довольно сложно понять, поэтому я не уверен, что какой-либо текущий конкретно решает эту проблему. Спасибо.

Ответ №1:

Это распространенная проблема при непосредственном предоставлении объектов JPA из CRUD REST API. Ваша модель сохранения не обязательно должна быть вашей моделью API.

Если 2 объекта связаны и должны быть обновлены в рамках одной транзакции, это означает, что они должны быть обновлены одним атомарным запросом API.

Итак, вы могли бы определить новый ресурс с помощью DTO, объединяющего ваши 2 объекта, предоставляемые новым API, который вы бы кодировали вручную (поэтому нет необходимости в дополнительной таблице).

Поскольку вы используете архитектуру микросервисов, у вас может возникнуть аналогичная ситуация и между MS1 и MS2, и здесь вы не сможете использовать транзакцию, тогда вам может потребоваться выполнить исправление.

Комментарии:

1. Чтобы уточнить, вы имеете в виду, что я должен создать новую сущность jhipster, которая сама по себе не имеет полей, но имеет отношения с Customer и Deal. Конечным результатом является то, что у меня есть объект Lead java, объект LeadDTO java и т. Д. Для модели API. Но как я могу убедиться, что модель сохранения не содержит этого вновь созданного ведущего объекта? Есть ли конкретный файл, который я должен удалить после генерации кода?

2. Нет, я не думал использовать jhipster entity , потому что это, вероятно, создало бы больше вещей, чем вам нужно (вам не нужна настойчивость), и их удаление может привести к ошибкам, я просто думал реализовать это вручную, внедрив ресурс, DTO и сервис. Не перегружайте генерацию кода en.wikipedia.org/wiki/Law_of_the_instrument