#[{'HeaderName1' : 'HeaderValue1', 'HeaderName2' : 'HeaderValue2'}].
Veeva Vault Connector 1.4 Additional Configuration Information - Mule 4
Invoke Rest API
The Invoke Rest API operation sends the Mule message payload as the request body.
In addition to the request body, you can configure the following using a DataWeave script or expression:
Configure a Header
-
In Anypoint Studio, head to General > Request > Query Parameters.
-
Click the plus icon (+) to add headers to the request.
For example, you can add header names
HeaderName1
andHeaderName2
, and header valuesHeaderValue1
andHeaderValue2
, by using DataWeave expressions:
Configure a URI Parameter
Configure a URI parameter when you want to use a placeholder, such as /objects/documents/{doc_id}
, in the path of your request.
-
In Anypoint Studio, type a placeholder enclosed in curly brackets in the Path field.
-
Select URI Parameters.
-
Click the plus sign (+) to enter a name and value.
Configure a Query Parameter
-
In Anypoint Studio, head to General > Request > Query Parameters.
-
Click the plus icon (+) to add a parameter to a request. Type a name and value for the parameter or use a DataWeave expression to define the name and value.
Sending Form Parameters in a POST Request
To send parameters in a POST request:
-
In General > Request, select the POST method.
-
In Body, construct the payload of the Mule message.
-
Enter the names and the values of the parameters to send, for example, for application/x-www-form-urlencoded:
#[output application/x-www-form-urlencoded --- {'key1':'value1', 'key2':'value2'}]
-
In multipart/form-data, ensure that the Content-Type value contains a boundary attribute with the same value as the DataWeave output as shown, for example
multipart/form-data; boundary=abcdefg
.%dw 2.0 output multipart/form-data boundary='abcdefg' --- { parts: { file: { headers: { "Content-Disposition": { "name": "file", "filename": attributes.fileName }, "Content-Type": payload.^mimeType }, content : payload }, name__v: { headers: { }, content: 'Test Document' }, type__v: { headers: { }, content: 'Trial Management' }, subtype__v: { headers: { }, content: 'Meetings' }, classification__v: { headers: { }, content: 'Kick-off Meeting Material' }, lifecycle__v: { headers: { }, content: 'Base Doc Lifecycle' }, study__v: { headers: { }, content: '0ST000000000301' }, comments__c: { headers: { }, content: 'Test Document' } } }
-
Connector Operations SUCCESS and FAILURE Response
Veeva Vault Connector operation responses are based on the Veeva Vault API success or failure responses with an error.
The connector returns a SUCCESS
response at HIGH LEVEL
and SUCCESS
or FAILURE
at LOW LEVEL
. This means the connector operation is successful but some document or object records failed to create or update due to some irrelevant metadata being passed in the request.
Examples
SUCCESS with a SUCCESS response:
{ "responseStatus": "SUCCESS", "data": [{ "id": 239026, "name__v": "E22611234--38483", "responseStatus": "SUCCESS" }, { "id": 239025, "name__v": "Kick-off Meeting Material Updated12341234--81032", "responseStatus": "SUCCESS" } ] }
SUCCESS with a FAILURE response:
{ "data": [ { "external_id__v": "TEST-238924", "rendition_type__v": "imported_rendition__c", "id": 238924, "responseStatus": "FAILURE", "minor_version_number__v": 1, "errors": [ { "type": "INVALID_DATA", "message": "Document not found [238924/0/1]." } ], "major_version_number__v": 0 }, { "external_id__v": "TEST-238925", "rendition_type__v": "imported_rendition__c", "id": 238925, "responseStatus": "FAILURE", "minor_version_number__v": 1, "errors": [ { "type": "INVALID_DATA", "message": "Document not found [238925/0/1]." } ], "major_version_number__v": 0 } ], "responseStatus": "SUCCESS" }
Veeva Vault Connector operations throw an exception when Veeva Vault APIs return a FAILURE
response, for example:
FAILURE with an ERROR response
{ "responseStatus": "FAILURE", "errors": [ { "type": "INVALID_DATA", "message": "Unknown relationship [reviewer__v]" } ] }
Upon receiving the FAILURE
response from the Veeva Vault APIs, the connector operations throw an exception, which is caught in the Error Handling component within the Mule flow:
********************************************************************************** Message : An error occurred from the Veeva Vault API. Error Code: INVALID_DATA. Original Error Message: Unknown relationship [reviewer__v]. Error type : VEEVAVAULT:INVALID_DATA **********************************************************************************
The following error codes are caught in the Error Handling component:
-
VEEVAVAULT:API_LIMIT_EXCEEDED
-
VEEVAVAULT:ATTRIBUTE_NOT_SUPPORTED
-
VEEVAVAULT:INACTIVE_USER
-
VEEVAVAULT:INVALID_DATA
-
VEEVAVAULT:INVALID_DOCUMENT
-
VEEVAVAULT:INSUFFICIENT_ACCESS
-
VEEVAVAULT:MALFORMED_URL
-
VEEVAVAULT:METHOD_NOT_SUPPORTED
-
VEEVAVAULT:NO_PERMISSION
-
VEEVAVAULT:OPERATION_NOT_ALLOWED
-
VEEVAVAULT:PARAMETER_REQUIRED
Streaming and Pagination
With the exception of Download Document, all connector operations return an input stream as a payload, with respective results based on operation output. Because of this, by default Mule applies streaming strategies. See Mule Streaming Strategies for more details. The streaming strategies configuration fields are in the Advanced tab of the connector operations.
The following operations in the connector provide a pagination mechanism based on Mule standard pagination.
-
Get Documents
-
Get Object Records
-
Query
-
Get Audit Details
While using the paginated operations, make sure to include a For-Each/Splitter
element to retrieve each object. The pagination operations have Fetch Size and Batch Size fields.
-
Fetch Size
A limited number of records that can be retrieved in a single page. The operation returns the pages with the fetch size number of JSON object records.
In some cases, Veeva APIs auto-calculate the fetch size (number of records on each page) based on record size and the calculation exceeds the standard record size. The operation returns calculated records on each page. -
Batch Size
The number of pages to return in each batch. Each page contains the fetch size number of records. The operation returns a number of records (metadata in JSON format) per batch, and is calculated like in the following example:
Fetch Size set as *1000* Batch Size set as *10* If the total records in the vault are *100,000*, then: Number of pages = Total records/Fetch Size = 100000/1000 = 100 pages. Number of pages per batch = Number of pages/Batch Size = 100/10 = 10 pages per batch. Number of Records per batch = Number of pages per batch * Fetch Size = 10 * 1000 = 10,000 records. Therefore, the number of records returned per batch would be 10,000 records.
The repeatable streams measure the buffer size in byte measurements. When handling objects, the runtime measures the buffer size using instance counts.
In non-repeatable streams, connector operations return streams as the number of records per batch. Repeatable streams return all records at once, so when calculating the in-memory buffer size for repeatable auto-paging, you need to estimate how much memory space each instance takes to avoid running out of memory.
Next Step
After you complete configuring the connector, you can try the Examples.