Как создать OData на основе RFC с несколькими таблицами в выводе?

Question

Я работаю над большим проектом на работе, который требует от меня создания OData для большого разнообразия удаленных вызовов функций. Я смог понять, как моделировать и создавать OData для простых RFC; однако я борюсь с более сложными RFC, которые используют несколько таблиц, а также с простым экспортом и импортом параметров.

Я хочу вывести эти таблицы, а также импортировать и экспортировать параметры через GetEntity и GetEntitySet всего одним вызовом. Я провел обширный поиск в Интернете, чтобы найти решения, но, похоже, лучшее решение - это переопределение RFC или многократный вызов OData, что не идеально.

Есть ли способ объединить несколько таблиц с несколькими записями в выводе? Когда я говорю «вывод», я имею в виду полученный XML-код из GetEntity / GetEntitySet.

Например, возьмите приведенное ниже поддельное определение RFC, которое принимает PERNR и выводит список прямых отчетов и структуру сведений о сотруднике.

ИМПОРТ

• PERNR

ЭКСПОРТ

• S_EMPLOYEE_DETAILS

ТАБЛИЦА

• T_DIRECT_REPORTS

Есть ли способ объединить таблицу, структуру и параметры импорта в один вывод?

Answer 1

Первое, что нужно понять, это то, что протокол OData не предназначен для работы исключительно как классические вызовы функций. Однако он основан на модели сущности / отношения. Таким образом, в вашем случае идентификатор является наилучшим для создания типа сущности с именем «Сотрудник» с соответствующими свойствами вашей структуры S_EMPLOYEE_DETAILS. С этим вы можете, например, реализовать метод GET_EMPLOYEE_ENTITY для извлечения одного экземпляра сотрудника через PERNR.

Следующее, что нужно сделать, это получить прямые отчеты этого сотрудника. Поскольку в вашем случае это отношение 1: N от Сотрудника к Сотруднику, вы можете создать свойство навигации под названием «DirectReports» с подходящим количеством элементов. Затем в вашем GET_EMPLOYEE_ENTITYSET вы можете вернуть экземпляры таблицы T_DIRECT_REPORTS (обратите внимание, что свойство навигации не пустое, и вы должны прочитать ключи родительского элемента!).

Получив эту работу, вы можете перейти к «передовому опыту» и реализовать метод GET_EXPANDED_ENTITY с заполнением предложений расширения, который, на мой взгляд, является предпочтительным способом, поскольку вам не нужно реализовывать два отдельных метода, и он рассматривается также быстрее (если произойдет много расширений).

Оба метода реализации могут быть вызваны через

GET EmployeeSet ('12345678')? $ Expand = DirectReports