Как переписать универсальный ODATA расширить функциональность обработки - PullRequest
0 голосов
/ 14 октября 2019

В настоящее время мы работаем над проблемами производительности с нашим предоставленным интерфейсом OData, поскольку UI5 выдает запрос на чтение с несколькими подключенными путями расширения. Из-за общей обработки запроса платформой это приводит к дополнительной обработке для каждого варианта расширения, которую мы должны предотвратить.

Читая блог по этой теме, кажется, есть способ переписать общую обработкукаким-то образом:

https://blogs.sap.com/2018/03/19/sap-cloud-platform-sdk-for-service-development-create-odata-service-7-more-navigation-read-create-expand-sqo/

В этом случае именно мы должны решить, можем ли мы позволить себе полагаться на функциональность FWK. Конечно, такая общая поддержка не может быть эффективной. Но для небольшого количества данных просто приятно получить его бесплатно. Следите за новостями, чтобы узнать, как переписать такую ​​универсальную FWK-функциональность с помощью собственной конкретной реализации.

Тем не менее, в этом блоге больше нет сообщений, и, просматривая структуру, моя единственная идея переписать это будетнастроить и использовать собственную реализацию com.sap.gateway.core.api.provider.data.IDataProvider, которая обрабатывает запрос нестандартным способом, хотя это будет огромным обходным путем.

Так что еслиесть какой-то более простой или более простой подход к перезаписи этой функциональности, который я пропустил?

ОБНОВЛЕНИЕ: Я был обновлен, чтобы создать пользовательский поставщик данных и зарегистрировать его в RuntimeDelegate после инициализации сервлета. Затем этот пользовательский поставщик данных будет проверять наличие пользовательских аннотаций в обработчике сопоставленных методов, чтобы узнать, следует ли обрабатывать раскрытие или нет. Если нет, то он просто будет читать сущность, но не будет выполнять его расширенное чтение. Это работает более или менее хорошо, но, конечно, отсутствует способ передать свойства, которые будут расширены в ReadRequest. Пока что только статическая реализация возможна для решения нашей проблемы с производительностью, но я бы с радостью намекнул, если есть другое, лучшее решение для этого ...

1 Ответ

1 голос
/ 16 октября 2019

На момент написания этой статьи лучшего подхода на данный момент не существует.

Добро пожаловать на сайт PullRequest, где вы можете задавать вопросы и получать ответы от других членов сообщества.
...