Attempting to retrieve Document Ids from Get Entity Details API (/{entity_type}/{entity_id}) call does not return the DocumentId of the attachment.

Pre-requisites:

• Must have Analytical Reporting API enabled on your realm
• Must have External Approval API enabled on your realm

The feasible workaround to retrieve the DocumentIds is to use a custom viewTemplate on Analytical Reporting API by ProjectIds, then use External Approval API document end point to retrieve the document.

Get the Document Id from Analytical Reporting API:

1. On Analytical Reporting API create a custom template to fetch InternalId by ProjectId, document type is DocumentFact
   curl --location --request POST '{{runtime_url}}/viewTemplates/<template_name>?realm=<realm_name>' \
   --header 'apiKey: <your_api_key>' \
   --data-raw '{
   "status": "published",
   "documentType": "DocumentFact",
   "selectAttributes": [
   "LoadCreateTime",
   "LoadUpdateTime",
   "InternalId",
   "ProjectInfo",
   "Title",
   "Description",
   "DocumentType",
   "Status",
   "CreateDate",
   "LastModified",
   "AclId"
   ],
   "filterExpressions": [
   {
   "name": "ProjectId",
   "field": "ProjectInfo.ProjectId",
   "op": "=",
   "defaultValue": null
   }
   ]
   }'
   
2. Once the custom template is created, Analysis reporting Synchronous API to Fetch the data
   curl --location --request GET '{{runtime_url}}/views/<template_name>?realm=<realm_name>&filters={"ProjectId":"<Project_Id>"}' \
   
3. The field InternalId is the Document Id. Save it

Get the document data from External Approval API:

1. Using the Get /Document endpoint specify the Document Id
   https://openapi.ariba.com/api/sourcing-approval/v1/prod/Document/<InternalId>?realm=<realm_name>
2. You will receive a JSON result of the document with fileContent, extension
3. Decode fileContent from Base64 Encoding and save the stream according to the extension field (pdf, docx, xlsx, etc)

External Approval API allows the client application to request the details of an identified document, using the GET /{entity_type}/{entity_id} endpoint specific to the document type of interest. Tasks (that is DocumentTask class) are linked directly to one specific type of data which can be a document (like ContractAgreement, or regular Document), folder (WorkSpaceFolder class) or a workspace (ContractWorkspace class).

The current design for this API would only give you the details of the data that is directly linked to the task. So if it is directly linked to a document, then you would get the document details (like DocumentID) and if it is linked to a workspace then you would get the workspace details (header fields). Workspaces contain documents but since the task is linked to the workspace and not to the document (due to the nesting of objects) then you won’t get those document ID for workspace-linked tasks. The documentation is correct in that the API supports tasks linked to workspaces, but it only gives workspace header fields and not all the nested documents within a workspace.

From a design perspective, If you linked the task directly to the workspace, it means you do not need the user to review any specific document and only need the user to review the contract on a header-level perspective. If you need a user to review specific documents, then you could create tasks specifically linked to those documents.

• Analytical Reporting API for Strategic Procurement and Operational Procurement
• External approval API for sourcing and supplier management
• OpenAPI: How do I add fields to the Reporting API Custom viewTemplate?

Strategic Sourcing > Strategic Sourcing - REST API
Supplier Lifecycle & Performance > Supplier Lifecycle & Performance - Open API