Ваш код взят из раздела " Возможности запроса " упомянутой вами документации.
И я подтверждаю, что _ggTXcJdTEeCznlnpJMXHdQ
является частью примера , не то, что должно работать в вашей среде.
Механизм обнаружения является ключевым:
Клиенты не должны полагаться на указанные c URL или выполнить пути по математике на URL. Вместо этого они должны использовать цепочку обнаружения, предлагаемую RT C. Вот схема процесса поиска функций управления изменениями:
Документ root доступен на https://<server>:<port>/<app>/rootservices
.
В типичном тестовом стенде RT C это https://localhost:9443/jazz/rootservices
Извлеките этот документ и извлеките URL-адрес каталога управления изменениями (на который указывает rdf:about
) элемента oslc:ServiceProviderCatalog
Извлеките документ за этим URL-адресом. Он содержит список элементов ServiceProvider
, которые указывают на документы, содержащие фактические описания услуг.
В случае RT C для каждой области проекта имеется один элемент ServiceProvider
. Как правило, приложение будет использовать заголовок этого элемента, чтобы позволить пользователю выбирать между областями проекта.
Получите документ службы, на который указывает свойство rdf:about
элемента oslc:ServiceProvider
.
Этот документ содержит ссылки на службы и операции, такие как:
- Фабрики создания для создания новых рабочие элементы,
- возможности запросов, позволяющие запрашивать рабочие элементы,
- делегированные диалоговые окна пользовательского интерфейса для создания и выбора рабочих элементов и
- фильтры CLM, которые являются предварительно определенными запросами на рабочие элементы.
Только следуя этому пути обнаружения, вы получите фактический URL-адрес, который будет использоваться для запроса рабочего элемента.