Дождитесь ответа от пользовательского интерфейса в ABAP Odata
Я пытаюсь создать OData ABAP, который получает запрос, выполняет некоторые вычисления, а затем должен вернуть сообщение конечному пользователю и принять решение на основе ввода пользователя. Таким образом, служба OData должна быть приостановлена, прежде чем она получит ответ.
Есть у кого-нибудь хорошая идея?
Оцените ваш ответ. С Уважением!
Привет, Бека. Спасибо за ответ. 2 отдельных запроса - это вариант, но это означает, что одна и та же полезная нагрузка будет отправлена дважды. Так что я как бы искал другой вариант.
возможно, вы сможете подробнее объяснить свой запрос. в одном запросе это будет невозможно из-за асинхронной обработки NW Gateway. Поможет ли SuggestionHelp / LiveValues? Это похоже на помощь по значению, когда пользователь вводит значения, которые он получает автоматически (это предложение может быть привязано к службе odata). Если ваш расчет достаточно быстр, вы можете предложить значения в соответствии с вводом пользователя. Может ли это помочь?
Итак, из части пользовательского интерфейса я сделаю запрос с полезной нагрузкой. Полезная нагрузка обрабатывается в серверной части. После некоторой обработки серверная часть должна принять решение, удалять или не удалять некоторые записи. Решение должно приниматься на основе решения, принятого пользователем. Таким образом, серверная часть должна отправить обратно в пользовательский интерфейс сообщение и дождаться его ответа, не теряя данные из процесса. Таким образом, здесь не работает справка по предложениям.
Ответы 1
OData - это особый вид REST. REST не имеет гражданства. То, что вы хотите, - это состояние.
Хороший способ превратить этот поток с сохранением состояния в поток без состояния:
Отправьте первый запрос (REST: POST, OData: CREATE), который создает и сохраняет (!) Документ, представляющий вычисление и его результат. Этот первый запрос может вернуть результат вычисления, который будет представлен пользователю.
Затем выбор пользователя отправляет второй запрос, который обращается к ранее созданному документу (например, через GUID) и включает выбор пользователя. Это означает, что второй запрос не должен снова отправлять ввод вычислений и фактически не выполняет никаких вычислений; он изменяет только состояние существующего объекта.
Если впоследствии расчет больше не нужен, второй запрос может удалить его. Чтобы предотвратить утечку данных, удаление старых вычислений по прошествии определенного времени (например, 24 часов) может быть разумным шагом.
Для этого есть ограничение, я не могу хранить данные во второй таблице только для их хранения. Я думал о веб-сокете, но есть и некоторые ограничения. Спасибо за ваш ответ!
Веб-сокеты для этого не подходят. Вы по-прежнему будете вмешиваться в изменчивую транзакцию без сохранения состояния. Даже если бы технология позволила это сделать, это было бы некрасиво по замыслу со всеми видами плохих последствий, например хрупкость.
Если вы не можете сохранить данные, я бы просто повторил запрос. Или попросите первый запрос вернуть результат расчета и повторно отправить его во втором запросе. Зависит от того, насколько это должно быть безопасно.
Вы оценили использование вместо этого протокола связи с отслеживанием состояния? Например, материал, лежащий в основе ABAP WebDynpro, может лучше подходить для вашего случая использования.
Насколько я знаю, это невозможно. Вы можете разделить задачу на 2 отдельных запроса. 1. Вычислить запрос 2. Действие пользователя 3. Обработать действие пользователя Я думаю, что ваши требования больше походят на функциональный модуль RFC с удаленной поддержкой, который будет лучшим выбором. Надеюсь, это поможет.