Veeva Vault Connector 1.3 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:

Headers
URI Parameters
Query Parameters

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 and HeaderName2, and header values HeaderValue1 and HeaderValue2, by using DataWeave expressions:
```
#[{'HeaderName1' : 'HeaderValue1', 'HeaderName2' : 'HeaderValue2'}].
```

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.