Когда использовать (украсить), что и почему - DefaultErpHttpDestination, DefaultHttpDestination?

Question

Использование java SAP Cloud SDK

Я должен использовать com.sap.cloud.sdk.s4hana.datamodel.odata.namespaces.outbounddeliveryv2.batch.OutboundDeliveryV2ServiceBatch.execute(HttpDestinationProperties destination) для выполнения некоторых обновлений в системе S / 4. Этот метод, execute принимает аргумент типа HttpDestinationProperties.

Поскольку мне нужен пункт назначения, я использую следующий код для получения пункта назначения:

HttpDestination destination = DestinationAccessor.getDestination("MyErpSystem").asHttp();

Так как HttpDestination расширяется HttpDestinationProperties, мы можем безопасно передать его на execute. Но согласно шагу 4 «Подключение к службе OData в Cloud Foun dry Использование SAP Cloud SDK» код для доступа к пункту назначения выглядит следующим образом:

ErpHttpDestination destination = DestinationAccessor.getDestination("MyErpSystem").asHttp().decorate(DefaultErpHttpDestination::new);

, а затем они передают это предназначение методу execute службы.

Мой вопрос таков: поскольку методы execute принимают аргумент типа HttpDestinationProperties, откуда мне знать, что я должен использовать DefaultErpHttpDestination ? То же самое относится и к DefaultHttpDestination.

У меня есть следующие вопросы -

1. Когда и зачем мне указывать пункт назначения в DefaultErpHttpDestination?
2. Когда и почему я должен обернуть пункт назначения в DefaultHttpDestination?
3. Почему я должен обернуть пункт назначения выше двух упаковщиков?

Answer 1

Это отличный вопрос!

Контекст:

• Конечно, вы можете продолжать использовать свой оригинальный подход:

  HttpDestination destination =
    DestinationAccessor.getDestination("MyErpSystem").asHttp();
  

  Это рекомендуемый способ для направлений для generi c конечной точки службы HTTP. Он загружает требуемые свойства назначения для HTTP-соединений, например, URL, Аутентификация, ...

---

• В руководствах мы описываем интеграцию с S / 4HANA Службы OData:

  HttpDestination destination =
    DestinationAccessor.getDestination("MyErpSystem").asHttp()
      .decorate(DefaultErpHttpDestination::new);
  

  Путем «декорирования» экземпляра HttpDestination свойствами ERP мы включаем дополнительные S / 4 связанные заголовки HTTP-запроса: sap-client и sap-locale , В описанной выше конфигурации эти значения считываются автоматически из службы destination - если они установлены.

---

Ваши вопросы (измененный порядок):

«Когда и зачем мне переносить место назначения в DefaultHttpDestination?»

DestinationAccessor#getDestination возвращает шаблон c Destination. Чтобы убедиться, что мы имеем дело с соединениями HTTP (а не RF C), вам нужно запустить #asHttp - как вы уже делаете. Получив экземпляр HttpDestination, вы можете запускать HTTP-запросы, такие как OData и REST . В зависимости от вашего варианта использования дополнительная упаковка не требуется.

Например, если вы собираетесь использовать конечные точки BAPI , вам нужно будет вместо этого запустить #asRfc. Этот метод проверяет различные свойства destination , чтобы убедиться, что все необходимые значения установлены.

"Когда и почему мне следует переносить место назначения в DefaultErpHttpDestination?"

Рекомендуется заключать адресата в DefaultErpHttpDestination, только когда вы имеете дело с конечными точками обслуживания S / 4 , и вы полагаетесь на пользовательские значения для sap-client и sap-locale. Обтекание может быть выполнено в любое время во время выполнения приложения, если это происходит до метода #execute(HttpDestinationProperties).

Если вы не хотите обернуть его во второй раз, вам нужно будет вручную управлять заголовки HTTP-запроса для sap-client и sap-locale.

«Зачем мне вообще оборачивать адресат выше двух оболочек?»

Это API контракт. Он гарантирует, что все необходимые свойства destination установлены правильно, прежде чем даже вызвать фактический запрос. Была предоставлена ​​(необязательная) ERP ароматизированная обертка целевого экземпляра, чтобы автоматически учитывались все свойства S / 4 .