We are pleased to bring you the following additions and enhancements to Developer Portal features in 22R2. REST API features added in 22R2 only affect API v22.2, unless otherwise noted.
Release Dates:
Vault is scheduled to rollover the signing certificate used to sign SAML Single Sign-on requests and Spark messaging connections. There is no expected downtime.
Your IT organization must ensure that the new certificate is configured on your Enterprise Identity Provider system prior to the New Certificate Rollover Event on April 29, 2022. Please ensure that your Spark messaging integrations do not cache the old certificate. Failure to utilize the new certificate by this date may cause login issues for SAML users, and Spark messaging integrations may fail.
Learn more about the action required for the certificate rollover process in Vault Help.
Beginning in 22R1.2, Vault is upgrading from HTTP/1.1 to HTTP/2 as the default protocol to shape and optimize traffic before it passes through the network to the user.
HTTP/1.1 is still supported, so no immediate action is required. However, Vault will assume all clients can leverage the HTTP/2 protocol. To avoid potential performance degradation, we strongly recommend reviewing your configurations and policies to ensure proper HTTP/2 support.
If an end-user’s configuration does not support HTTP/2, both the browser and server fall back to HTTP/1.1. For example, a firewall, VPN configuration, or browser policy setting could downgrade HTTP/2 traffic to HTTP/1.1. They may also classify it as unknown TCP traffic. This may negatively impact Vault performance, so we recommend upgrading to HTTP/2 as soon as possible.
Release Date: May 6, 2022
Individual users may now only make one asynchronous call to retrieve login audit data at a time. For example, https://myvault.veevavault.com/api/v21.3/audittrail/login_audit_trail will only accept one request per user at a time when the return type CSV is requested.
View the Retrieve Audit Details endpoint in the v22.2 REST API Reference.
Starting in API v22.1, the Document Field Metadata API now applies field-level security to the API results. If the field is hidden for the API user, the field will not be returned in the API. If the field is read-only, the editable attribute will be false.
This enhancement means the queryable attribute can now be used to accurately detect whether the field is accessible in VQL by the currently authenticated API user.
The Vault Loader Multi-File Extract API now provides trailing zeroes in the CSV export for number and currency fields.
The feature introduces a new SDK interface that allows developers to retrieve document field and document type metadata. Document types can be retrieved by type, subtype, classification, and document type detail ID, and document fields can be filtered by name, document type, status, and requiredness. Learn more in the Javadocs
Custom code from the Vault Java SDK now runs as the new Java SDK Service Account user rather than the System user. This new user appears in the Users & Groups Admin tab and audit trails. Vault does not include this user in license counts. Existing code is unaffected by this change.
This feature provides support for Custom and Vault tokens in VQL queries executed using QueryService. Developers can populate a prepared query using strongly typed values for Boolean, Date, DateTime, Number, String, and List of String, and QueryService will format the values as required by VQL syntax. Vault tokens are also supported in Vault API v22.2+. Learn more about Token Request for Query Builder.
Developers can now get the file size of email attachments sent to Vault using the getFileSize() method. This method returns the size in bytes of these email attachments for emails ingested using the EmailProcessor interface. Learn more in the Javadocs.
Developers can now set the Reply-To address for email notifications in NotificationService. The new setReplyToByPersonId() and setReplyToByUserId() methods in NotificationParameters allow developers to set the Reply-To by Person ID or User ID, respectively. Learn more in the Javadocs.
With this feature, we’ve aligned the behavior of blank Description fields. Previously, description fields intentionally left blank were sometimes null and sometimes an empty String. Beginning in 22R1.2, if a description field is left empty, the field will always be explicitly set to an empty String. This means developers may now see API or MDL responses which used to be description() are now returned as description(''), and should adjust integrations as necessary.