Степень детализации веб-сервисов с SAP-проектом?

Question

В проекте, который входит в качестве третьего приложения поверх SAP, чтобы расширить его функциональность через веб-сервисы SOAP, мне интересно, как следует определять сами веб-сервисы; мы должны реализовать десяток веб-сервисов, которые достигают простых & атомных действий или очень мало веб-сервисов, которые берут кучу параметров и делают все.

Я заинтересован в обратной связи & предложения с учетом:
- рабочая нагрузка на SAP NetWeaver слоя (количество одновременных веб-сервисов)
- третье обслуживание приложение
- SAP Web-сервисы по обслуживанию
- сетевой нагрузки (с учетом SOAP enveloppes & запросы HTTP)
- любое другое соображение, я не думал о

Благодарности

OB.

Answer 1

Как и прежде всего, при определении интерфейса веб-службы, в основе которой лежит идея о том, что крупнозернистые услуги, как правило, более уместны, чем занятые мелкозернистые службы.

Это, во-первых, потому, что накладные расходы каждого вызова сравнительно велики, поэтому предпочтительнее меньше круговых поездок. (Например, GetName, GetAddress, GetPhoneNumber и GetPersonInfo)

Во-вторых, если есть логика, мы хотим, чтобы сервис владел им. Мы не хотим, чтобы каждому клиенту нужно было знать порядок, в котором можно вызвать мелкозернистые методы. В противном случае мы заканчиваем дублирование логики в каждом клиенте.

У меня есть статья here, в которой подробно рассматриваются такие вопросы.

Answer 2

Насколько важна рабочая нагрузка на уровне сети SAP netweaver. Этого не должно быть. Сервер приложений sap abap - это уже зрелая платформа, с которой вы столкнетесь. Он отлично масштабируется и может принимать любую нагрузку, если в процессоре что-то есть (что он использует эффективно).

Таким образом, вопрос связан скорее с сетевыми накладными расходами и обслуживанием. Как и djna, я считаю, что грубый - это путь. Но в этом нет ничего особенного.

Answer 3

Я бы просто пошел по дороге, что SAP проложил: начиная с создания CRUD, как мелкозернистые услуги. Когда вы просматриваете SAP Enterprise Services Wiki, вы обнаружите, что большинство услуг, предоставляемых SAP, имеют мелкозернистую структуру.

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

Уверенный, производительность - это соображение, но, как написано выше: инфраструктура корпоративных услуг - это оболочка для проверенного временем двигателя ABAP, и этот быстрый.