ошибка «Дублирующийся ресурс» после того, как я создал 2 транспортных запроса в CDS

Question

Я создал два транспортных запроса (TR) для одного и того же проекта, внося изменения в представления CDS, после чего появляется дублирующаяся ошибка ресурса с кодом ошибки 400, и я не могу получить какие-либо данные в своей таблице UI5.

Я перенес изменения, которые были заблокированы в новом TR, в старый TR, но он по-прежнему выдает ту же ошибку.

Сбой HTTP-запроса400, неверный запрос, {"error": {"code": "/ IWBEP / CM_MGW_RT / 030", "message": {"lang": "en", "value":" Duplicate resource "}," innererror ": {" application ": ...

Answer 1

Прежде всего: Дважды проверьте, нет ли на самом деле дублирующего ключа , прочитав базовое представление SQL (аннотированное в определении CDS @AbapCatalog.sqlViewName), используя транзакцию se16 (н / ч).

Если в представлении SQL действительно нет дубликатов, ошибка может быть вызвана различными ошибками в структуре ABAP CDS.Эти ошибки чаще всего появляются после того, как вы изменили источник / определение CDS.Вот несколько из них:

• Открытые транзакции segw и обновляют структуру сущности , щелкая правой кнопкой мыши «обновить все».

  .

• Затем нажмите красно-белый пляжный мяч , чтобы восстановить классы MPC / DPC.

  

• То, что на самом деле делает красно-белый пляжный мяч, это объединение измененной структуры с существующими классами.Щелкните правой кнопкой мыши по проекту и выберите «Создать среду выполнения» , чтобы действительно заново сгенерировать все объекты среды выполнения.

  

• Иногда в обзоре сущностей есть кнопка очистки .Щелкните по нему.

• В транзакции /iwfnd/gw_client выберите Метаданные → Кэш очистки → В обеих системах

  

• Очистка кэша работает достаточно хорошо для представлений OData, которые были созданы вручную из типов ABAP в segw, но Core Data Services все еще могут кэшироваться.Если ничего из вышеперечисленного не помогло:

  • выйдите из системы и войдите снова
  • перезапустите транзакцию
  • подождите час или два

• Попробуйте вручную проверить сбойный запрос OData непосредственно в /iwfnd/gw_client.Вы можете активировать вход в систему /iwfnd/traces, чтобы дважды проверить, как на самом деле выглядят запросы вашего клиента.

• Проверьте ваш клиент OData.Может быть, он внутренне кеширует $metadata?

• Проверьте, что запрос на перенос был успешно обработан, используя, например, транзакцию se10.Транспорт / Импорт в другую систему может быть заблокирован из-за длительных запросов SADL .Убейте их, используя sm50, если необходимо.