Попытка вызвать ид. документов из вызова API получения сведений о сущности (/{entity_type}/{entity_id}) не возвращает DocumentId вложения.

API внешнего утверждения позволяет клиентскому приложению запрашивать подробные данные идентифицированного документа с помощью конечной точки GET /{entity_type}/{entity_id}, специфичной для вида документа. Задачи (то есть класс DocumentTask) напрямую связаны с определенным типом данных, которым может быть документ (например, ContractAgreement или обычный документ), папка (класс WorkSpaceFolder) или рабочая область (класс ContractWorkspace).

Текущий дизайн этого API предоставляет только подробные данные, напрямую связанные с задачей. Таким образом, если он напрямую связан с документом, вы получите сведения о документе (например, DocumentID), а если он связан с рабочей областью, то получите сведения о рабочей области (поля заголовка). Рабочие области содержат документы, но поскольку задача связана с рабочей областью, а не с документом (из-за вложенности объектов), вы не получите этот идентификатор документа для задач, связанных с рабочей областью. Документация верна в том, что API поддерживает задачи, связанные с рабочими областями, но предоставляет только поля заголовка рабочей области и не все вложенные документы в рабочей области.

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

Целесообразным обходным решением для вызова DocumentIds является использование пользовательского шаблона ракурса в API аналитической отчетности по ид. проекта, а затем использование конечной точки документа API внешнего утверждения для вызова документа.

Вызвать ид. документа из API аналитической отчетности:

1. В API аналитической отчетности создайте пользовательский шаблон для вызова InternalId by ProjectId, типом документа является DocumentFact
   curl --location --request POST '{{runtime_url}}/viewTemplates/<имя_шаблона>?realm=<имя_объекта>' \
   --header 'apiKey: <ваш_api_key>' \
   --data-raw '{
   "status": "published",
   "documentType": "DocumentFact",
   "selectAttributes": [
   "LoadCreateTime",
   "LoadUpdateTime",
   "InternalId",
   "ProjectInfo",
   "Заголовок",
   "Описание",
   "DocumentType",
   "Статус",
   "CreateDate",
   "LastModified",
   "Ид. приложения"
   ],
   "filterExpressions": [
   {
   "name": "ProjectId",
   "field": "ProjectInfo.ProjectId",
   "op": "=",
   "defaultValue": NULL
   ≈
   ]
   ≈'
   
2. После создания пользовательского шаблона Analysis Reporting Synchronous API для извлечения данных
   curl --location --request GET '{{runtime_url}}/views/<имя_шаблона>?realm=<realm_name>&filters={"ProjectId":"<Project_Id>"}' \
   
3. Поле InternalId является идентификатором документа. Сохраните

Вызвать данные документа из API внешнего утверждения:

1. Использование конечной точки Get /Document указывает идентификатор документа
   https://openapi.ariba.com/api/sourcing-approval/v1/prod/Document/<InternalId>?realm=<имя_объекта>
2. Вы получите результат JSON документа с fileContent, расширение
3. Декодирование содержимого файла из кодировки Base64 и сохранение потока в соответствии с полем расширения (pdf, docx, xlsx и т. д.)

• API аналитической отчетности для стратегических и оперативных закупок
• API внешнего утверждения для выбора источника поставки и управления поставщиками
• OpenAPI: как добавить поля в пользовательский шаблон ракурса API отчетности?

Жизненный цикл и качество работы поставщиков > Жизненный цикл и качество работы поставщиков - Open API
Стратегические закупки > Стратегические закупки - API REST