Data Product delegates

The Data Product delegates wrap the multipart/form-data endpoints of the Collibra Data product REST API. Because Collibra API tasks do not support multipart requests, these delegates are the only way to call those endpoints from a workflow. For any other Data Contract API action, use the Collibra API task instead.

All three delegates are located in the com.collibra.dataproduct.workflow.delegate package and are available automatically with no additional configuration.

Each delegate writes the created or updated resource as a Map<String, Object> into the data_contract_result process variable so that downstream tasks or forms can consume it.

AddFromManifestDelegate

The AddFromManifestDelegate adds a new version to an already-initialized data contract. It parses the manifest ID and version directly from the uploaded manifest content, so you don't need any explicit contract reference.

Field name Type Required Description Example
manifest_content String Yes The manifest content in YAML format. The manifest ID and version are parsed from this content. Must be non-empty. kind: DataContract\nname: customer-360\nversion: 1.2.3\n...
manifest_id String No Override for the manifest ID parsed from the content. customer-360
data_contract_version String No Override for the version parsed from the content. 1.2.3
active Boolean No Set to true to make this version the active one. true
force Boolean No Set to true to overwrite an existing version with the same value. false

Output:

  • data_contract_result: The data contract with the newly added version, as a Map<String, Object>.

Properties:

  • Class: com.collibra.dataproduct.workflow.delegate.AddFromManifestDelegate
  • Calls: POST /rest/dataProduct/v1/dataContracts/addFromManifest

InitDataContractDelegate

The InitDataContractDelegate creates a new Data Contract asset and links it to its initial manifest. If no manifest is supplied, a template is generated from the associated Collibra content. Use this delegate as the first step in creating a new data contract.

Field name Type Required Description Example
governed_asset_id String (UUID) Yes The ID of the governed asset the new Data Contract asset attaches to. 019d19e1-3f74-7433-8532-522e14b5f587
domain_id String (UUID) No The ID of the domain in which the Data Contract asset is created. 01923a45-9e7c-7d8f-9f9f-3b8a2e7c1f4a
manifest_content String No The initial manifest content in YAML format. When omitted, a template is generated from the associated Collibra content. kind: DataContract\nname: orders\n...
manifest_id String No The manifest identifier inside the manifest document. orders
data_contract_version String No The initial version label for the data contract. 1.0.0
data_contract_name String No A human-readable name for the Data Contract asset. Orders Data Contract

Output:

  • data_contract_result: The newly created Data Contract asset with its initial manifest version, as a Map<String, Object>.

Properties:

  • Class: com.collibra.dataproduct.workflow.delegate.InitDataContractDelegate
  • Calls: POST /rest/dataProduct/v1/dataContracts

UploadDataContractVersionDelegate

The UploadDataContractVersionDelegate adds a new version to the version history of an existing data contract by explicitly targeting the asset ID of the contract.

Field name Type Required Description Example
data_contract_asset_id String (UUID) Yes The ID of the existing Data Contract asset to upload a new version to. 019d19e1-3f74-7433-8532-522e14b5f587
manifest_content String Yes The manifest content in YAML format for the new version. Must be non-empty. kind: DataContract\nname: customer-360\nversion: 1.2.4\n...
data_contract_version String No The version label. Falls back to the version declared inside the manifest if omitted. 1.2.4
active Boolean No Set to true to make this new version the active one. true
force Boolean No Set to true to overwrite an existing version with the same value. false

Output:

  • data_contract_result: The data contract with the newly uploaded version, as a Map<String, Object>.

Properties:

  • Class: com.collibra.dataproduct.workflow.delegate.UploadDataContractVersionDelegate
  • Calls: POST /rest/dataProduct/v1/dataContracts/{id}/versions

Using a Data Product delegate

Each delegate is configured as a service task in Workflow Designer.

  1. Add a Service Task at the point in the process where you want the delegate to run.
  2. Set the implementation type to Java class.
  3. Enter the fully qualified class name from the delegate properties into the Class field.
  4. Ensure every required input process variable is populated before the service task runs. The delegate reads variables by name, so the variable name must match the field name exactly. Common ways to populate variables:
    • From a User task form: Bind the form field value to {{variable_name}}. When you submit the form, the process stores the value under that name.
    • From a Script task: Use execution.setVariable("variable_name", value).
    • From the workflow starting asset for asset-scoped workflows: Capture ${item.id} in a script task, for example execution.setVariable("data_contract_asset_id", item.id.toString()).
    • From a previous Collibra API task: use the saveResponseParameters option to store the response under the required name.
  5. Consume the data_contract_result output after the service task. The delegate writes the response body to this variable as a Map<String, Object>. Typical follow-ups are:
    • Read fields in a downstream form using dot notation. For example: {{data_contract_result.id}} or {{data_contract_result.manifestVersion.version}}.
    • Pass values into another delegate or Collibra API task by reading the map and setting the required fields on subsequent variables.

Notes on input types

  • ID parameters, such as governed_asset_id, data_contract_asset_id, or domain_id are passed as strings. The delegates parse them and return an error if the value is missing or not a valid UUID.
  • The manifest_content parameter expects raw YAML text. The Collibra fileUpload form widget stores a file reference as an ID rather than file content, so workflows that source the manifest from a file upload field need a Groovy script task to resolve the reference with fileApi.getFileAsStream(fileId).getText("UTF-8") and write the result into manifest_content before the delegate runs.