We are pleased to bring you the following additions and enhancements to Developer Portal features in 24R3.
Service Announcements are changes that may affect existing integrations. Organizations should assess these features against their existing integrations and make updates where necessary.
Release Date: 24R3.2; December 18, 2024
Over the next several releases, Veeva is upgrading the Vault Java SDK to Java 17. Java 17 includes optimizations that can improve performance and efficiency compared to Java 8, allowing for reduced resource usage.
In this release, Vault is auto-enabling Java 17 compilation in all Vaults, with the option to temporarily disable Java 17 if code incompatibilities are found. When enabled, Vault compiles new SDK code deployments with Java 17 instead of Java 8. This means that enabling Java 17 does not automatically test your custom code for compatibility, as existing code is not recompiled. To test your code for compatibility with Java 17, redeploy any existing custom code to recompile with Java 17.
When Java 17 is enabled:
Learn more about how to upgrade your code to Java 17, including solutions to common Java 17 compilation errors.
Release Dates:
See the full release schedule for more information about these release dates.
Release Date: 24R3.2; Dec 18, 2024
Beginning with the 25R1 release, we will be modifying the set of TLS 1.2 cipher suites supported by Vault servers, removing weak cipher suites, and adding support for TLS 1.3. These changes may affect some custom integrations, but not users accessing Vault with a supported browser. Changes begin rolling out for Limited Release users with version 24R3.2.
All customers and partners with affected integrations will be contacted directly by Developer Support.
Learn more about Veeva Vault cipher suite changes.
Release Date: December 18, 2024
Customers can now create custom user interfaces hosted in Vault. Custom Pages are written using JavaScript, allowing users to choose from various frameworks and libraries, as well as the Java SDK. This allows you to create specialized user interfaces for specific use cases, such as purpose-built forms, without standing up external infrastructure.
Custom Pages can be accessed by users in a Tab and are secured with Permission Sets. Custom Page code and configuration is stored and managed in Vault using the same model Vault Applications use to create Pages on the Vault Platform.
Global changes are features that affect multiple product areas or affect Vault holistically. For example, new functionality accessible through both the Vault REST API and the Vault Java SDK.
Roll-up fields are defined on a parent object and create a calculated value by performing either a count, sum, max, or min of child object record values. Additionally child records may be conditionally included or excluded from the selected calculation through a filter expression. The roll-up calculation runs on the child records when they are updated, deleted, or added. Learn more about the user and admin-facing functionality of this feature in the Vault Help release notes.
Vault calculates roll-up fields synchronously, like a trigger, for up to 100 child records. Parent records with more than 100 child records on any roll-up relationship(s) are processed asynchronously. Vault considers an update to a roll-up field a change on the parent record (captured as System or System on Behalf Of for asynchronous and synchronous cases respectively), updating the Last Modified Date and Audit Trail accordingly; however, a roll-up field update does not cause Vault Java SDK triggers to execute.
In MDL, roll-up fields now include several new attributes, namely rollup('true'), rollup_relationship_name, rollup_source_field, rollup_function, and rollup_filter_criteria.
You can set roll-up fields using Record Migration Mode but they otherwise behave as read only. When you configure a roll-up field, it only calculates its value after creation, when an event occurs on the child records associated with it.
This release brings the following changes to the Vault Java SDK for roll-up fields:
ObjectFieldMetadataType Enum now includes ROLLUP as an option to represent a rollup object field. ObjectRollupFieldType captures the supported return types for a roll-up field: CURRENCY, DATE, DATETIME, NUMBER, PERCENT.ObjectRollupFieldFunctionType enum captures the supported return types for a roll-up field: COUNT, MAX, MIN, SUM.ObjectRollupFieldExpressionMetadata interface extends ExpressionMetadata and returns any configured filter expressions.ObjectRollupFieldMetadata interface provides access to metadata on a given roll-up field.As part of this feature, we are introducing additional attributes to the Picklist component type’s MDL. The new system_managed attribute will indicate that customers cannot:
However, customers may be able to change the labels of the picklist values, activate or inactivate them, and change the sequencing depending on the nature of restrictions placed on system and standard picklists
As part of this feature picklist values will now be returned via picklist APIs and SDKs sorted ascendingly based on their designated order (MDL order attribute). Picklist values that possess the same order value will be sorted in the order they were configured.
As part of this feature, a new type of picklist value dependencies has been established that exists on the picklist, as opposed to on the field that leverages the picklist which is how they have historically been expressed within the system. Learn more about the user and admin-facing functionality of this feature in the Vault Help release notes.
Picklists that have dependencies defined will present a new controlling_picklist MDL attribute that details the picklist upon which the current one is dependent. In addition to the controlling picklist attribute on the picklist, the Picklistentry subcomponents will contain a new controlling_entries MDL multi-value attribute that details which values on the controlling picklist the dependent picklist’s value is dependent upon.
Vault REST API features added in 25R1 only affect API v25.1, unless otherwise noted.
Document Migration Mode now supports Document Relationships when using Vault Loader (UI and CLI) and the Vault REST API. This feature brings performance enhancements in Vaults where there is internal processing logic for creating and updating document relationships.
To optimize the performance of the Validate Session User API, starting in v25.1 the response only includes attributes stored in Vault. For example, the endpoint no longer returns the domain name and domain status. Previous versions of the API are unaffected by this change, but developers are encouraged to upgrade to v254.13 to optimize performance.
This new endpoint will allow developers to manage the SDK Debug Logs via the REST API, which can be used by external tools or to simply download the files without accessing the UI.
Get All Debug Logs
GET /api/{version}/logs/code/debug
Get Single Debug Log
GET /api/{version}/logs/code/debug/{id}
Download Debug Log Files
GET /api/{version}/logs/code/debug/{id}/files
Reset Debug Log
POST /api/{version}/logs/code/debug/{id}/actions/reset
Delete Debug Log
DELETE /api/{version}/logs/code/debug/{id}
Create Debug Log
POST /api/{version}/logs/code/debug/
We have changed the way Migration Package (VPK) logs are attached to a package. Previously, each log file was a separate attachment. From this release, there is a single attachment, with each new log added a new version.
Additionally, the Retrieve Package Deploy Results API now includes a URL to download a ZIP file containing all data deployment success and failure logs.
With this release, non-system-managed picklists can contain up to 2,000 active values, while the maximum amount of picklist values that can be submitted for multi-value picklist fields is limited to 100 picklist values. Developers need to correct any array or data limit they may have used for the previous picklist entry and multi-value fields.
List Items at a Path now returns the file_content_md5 that was returned on upload. This gives an easy way to maintain data integrity when using File Staging.
As of this release, we will no longer support the Standard Metrics: Create Document Update Job endpoint for PromoMats Vaults.
This feature streamlines procedure management in Vault by allowing for a Vault-level library of global Procedure Definitions that can be used to create Procedure Templates. Learn more about the user and admin-facing functionality of this feature in the Vault Help release notes.
With this feature, a Populate Procedure Definitions endpoint is now available to create Procedure Definitions for a specific study.
POST //api/{version}/app/clinical/payments/populate-procedure-definitions
With this release, you can use the new TRIM() VQL function with Picklist fields in the SELECT statement. This function removes the trailing namespace suffix from a picklist value name, such as __sys __v, or __c. This transforms the query response for picklist names from picklist_value__c to picklist_value.
From this release, developers can set the errors node of the Custom Web API’s response using the webApiContext.newWebApiFailureResponseBuilder().This allows developers to create response patterns consistent with system and standard Vault APIs.
SDK developers now have access to Query Describe metadata when using Query Service to execute and validate VQL queries. Developers can leverage this to understand the data type of the fields returned.
The PicklistRequest.Builder is enhanced so that developers can pass a language when constructing their picklist request builder. With this feature, it is now possible to retrieve picklist labels in a specified language, instead of the Vault’s base language or the user’s language.
Word Formatted Outputs is a new feature that allows admins to design formatted outputs using a Microsoft Word file instead of an Adobe XFA PDF file as the input file. Learn more about the user and admin-facing functionality of this feature in the Vault Help release notes.
This feature has added the input_file_type and output_format attributes to the Formattedoutput component type’s MDL. Existing Formattedoutput components will be migrated to the new model upon release. Vault still accepts any VPKs and MDL components using the old model and converts them to the new model upon deployment.
This feature enables enhanced formatting options, such as the addition of logos or text styling, allowing developers to create signature page templates without Adobe XFA technology.
To support this feature, the Signaturepage component has the following new attributes that store the HTML for the appropriate parts of the signature page:
header_richtextsignature_block_richtextfooter_richtextA new schema_version system-managed attribute has also been added to the MDL to identify whether a Signaturepage uses the existing or new enhanced formatting options. .
Upon release, existing basic templates will have their rich text attributes populated with data translated from existing values in header_01, header_02, signature_block_01, signature_block_02,footer_01, and footer_02, as applicable.
When schema_version is 0, existing attributes header_01, header_02, signature_block_01, signature_block_02, footer_01, and footer_02 will be used when generating signature pages using that template. Otherwise, rich text attributes will be used.
Any VPKs and MDLs using the old header, signature block, and footer attributes will still be accepted. When schema_version is 0, richtext fields will be auto-populated with data translated from those fields upon execution. The same applies if schema_version is not0` as long as no value is provided in the corresponding richtext attribute.
A circular dependency between Quality Teams and formatted outputs when deploying configuration using a VPK has been resolved by introducing a new component and subcomponent: Qualityteamlifecycleassociation and Qualityteamrolelifecycleassociation. Existing Quality Teams will be migrated to the new components automatically upon release.