Developer Features in 26R2
Filters
Application Family
Tags
We are pleased to bring you the following additions and enhancements to Developer Portal features in 26R2.
Service Announcements
Section link for Service AnnouncementsService Announcements are changes that may affect existing integrations. Organizations should assess these features against their existing integrations and make updates where necessary.
Global API Header Changes
Section link for Global API Header ChangesWe are making the following changes to all Vault API versions starting with the 26R1.2 release:
- Status Line: Vault API will return a numeric-only status line. For example,
HTTP/1.1 200instead ofHTTP/1.1 200 OK. Integration logic must be updated to validate responses based on the numeric status code (integer) rather than searching for descriptive text strings like "OK." Per RFC 9112, the reason phrase is optional and deprecated in modern protocols. - Cache-Control: Vault API will no longer return the
Expiresheader. Integrations should use the explicitCache-Control: no-store, no-cachedirectives. Legacy clients that previously relied on the 1970 epoch date for cache invalidation must be updated to recognize modern Cache-Control headers. This ensures consistent data privacy across modern CDNs and browsers. - Vary: The header "Vary: Accept-Encoding" will be transmitted in lowercase format "vary: accept-encoding" to comply with HTTP/2 and HTTP/3 standards.
Support ExecuteAs for Documentaction
Section link for Support ExecuteAs for DocumentactionAdded @ExecuteAs support for DocumentAction entry points.
Additionally, DocumentActionContext.getDocumentVersions() now defaults to Java SDK Service Account instead of the Request Owner. Please review your implementations to ensure this shift in default permissions aligns with your security requirements:
- 26R1 Behaviour:
getDocumentVersions()runs as Request Owner by default - 26R2 Behaviour:
getDocumentVersions()runs as System by default
Query Profiler
Section link for Query ProfilerThis feature allows Admins and Developers to monitor VQL query performance with the new query profiling tool. Analysing the profile of queries is a key part in monitoring their performance and overall health, but previously this process has been challenging.
Now with Query Profiler, the results makes it easy to analyse the queries running in Vault, by looking at the data obtained during a profiling session. Users will need to start a profiling session where they will also be able to set filters on what kind of VQL queries should be included in the results. These filters include:
- Origin: filters where the VQL query originated from (API, SDK, or ALL)
- Targets: filters the specific Query Targets of the VQL query (e.g.: restricting to queries on
user__sys) - Result Count: filters queries to only be included if their result count is in a Min / Max range
- Query Time: filters queries to only be included if their execution time is in a Min / Max range
- Response Status: filters whether the query was a SUCCESS, FAILURE or if it received a WARNING
Hierarchy: VQL Relationship
Section link for Hierarchy: VQL RelationshipA new VQL relationship for hierarchy nodes allows Admins and Developers to see the ordering of hierarchical objects like EDL and EDL Item. Previously the order for these types of object records was only visible in the hierarchy viewer UI.
Vault Java SDK
Section link for Vault Java SDKSupport Paging for QueryService
Section link for Support Paging for QueryServiceThis feature allows pagination when running VQL queries in the Vault Java SDK, making it simpler for developers to return results of a specific size.
Previously, the QueryService was designed to return a Stream of results and explicitly did not support the VQL pagination clauses PAGESIZE and PAGEOFFSET.
Developers can add withPageSize(int) to the Builder, mirroring the VQL query syntax, and we have added new QueryPaginationResponse and QueryPageRequest interfaces.
RenditionService SDK
Section link for RenditionService SDKUsers can now query for information related to the structure of their document and its contained content using RenditionService. This includes information about the page count, page sizes, page crop, page rotations, contained bookmarks, and contained named destinations.
Enhancements to SDK DocumentService
Section link for Enhancements to SDK DocumentServiceA new set of DocumentService SDK methods for creating new documents, updating existing document versions, and deleting documents and document versions. New interfaces also add support for updating previous document versions, and creating new versions of documents not in migration mode, which are current gaps in the SDK.
The following new methods are added to the existing DocumentService interface:
batchCreateDocuments(DocumentBatchCreateRequest request);batchUpdateDocumentVersions(DocumentVersionBatchUpdateRequest request);batchDeleteDocuments(DocumentBatchDeleteRequest request);
The following existing methods will be deprecated from DocumentService:
createDocuments(List<DocumentVersion> documentVersions)deleteDocumentVersions(List<DocumentVersion> documentVersions)saveDocumentVersions(List<DocumentVersion> documentVersions)
Connection API Name Support for Integration Rule SDK
Section link for Connection API Name Support for Integration Rule SDKThis enhancement introduces the ability to retrieve integration rules using the Connection API Name rather than strictly requiring the connectionId. Using the new withConnectionName() method makes the code more portable, easier to read, and it simplifies the use for developers.
// Locate service
IntegrationRuleService integrationRuleService =
ServiceLocator.locate(IntegrationRuleService.class);
// Build request using API Name
GetIntegrationRulesRequest request =
integrationRuleService.newGetIntegrationRulesRequestBuilder()
.withConnectionName("verneo_clinical_conn__c") // Human-readable API Name
.build();SDK: Workflow Task Metadata & Completion
Section link for SDK: Workflow Task Metadata & CompletionWe are enhancing the WorkflowTaskService and WorkflowMetadataService to support programmatic workflow task completion. This new functionality allows developers to inspect the requirements (prompts) of a task instance and construct a completion request that satisfies those requirements.
Developers will be able to perform "discovery" to understand what inputs will be required (Task Level, Verdicts, Verdict Reason, Verdict Capacity, etc.) and then perform the "execution" by constructing a completion request.
Doctype Triggers: Add New Version Context Details
Section link for Doctype Triggers: Add New Version Context DetailsAdds new DocumentTypeCreateDraftExecutionContext and DocumentTypeCheckInExecutionContext interfaces to give doctype trigger developers the ability to differentiate how the new document version was created (Create Draft vs Check-In etc.).
Direct Data API
Section link for Direct Data APIDirect Data API: Additional Document Metadata in Workflow Extracts
Section link for Direct Data API: Additional Document Metadata in Workflow ExtractsThis release, we are adding existing document and version VQL fields to the Workflow Item (workflow_item__sys.csv) and Workflow Task Item (workflow_task_item__sys.csv) extracts in Direct Data files.