Workflow template properties for custom approval processes

Custom approval processes are based on workflow templates which are created in an open source application called Flowable. This topic describes the start form properties for the templates that are compatible with the Access request for data product workflow.

Following are the required start form properties for a workflow template that is compatible with the Access request for data product workflow type.

Id Name Type Expression Description
business_justification Business justification string The business justification the subscriber provided when requesting access
order_id Subscription ID string The ID of the CAMS asset list that represents the subscription
order_requester Subscription requester string ${cpd:conf('{"cpd_type":"cpd_user"}')} The user that made the request to subscribe to the data product. The expression will display the value as a user instead of as a user ID.
dp_owner Product owner string ${cpd:conf('{"cpd_type":"cpd_user"}')} The owner of the data product. The expression will display the value as a user instead of as a user ID.
dp_name_with_version Data Product Name with Version ID string The name and version of the data product.
dp_assignees Data Product Assignee string ${cpd:conf('{"cpd_type":"cpd_user"}')} This field is currently not used but is still required.
group_assignees Group Assignees string This field is currently not used but is still required.
dp_id Product ID string The ID of the data product.
description Description string The description of the data product.
order_details Subscription details string ${cpd:conf('{"cpd_type":"url"}')} A link to the subscription details. The expression will display the value as a URL instead of a string.
product_details Product details string ${cpd:conf('{"cpd_type":"url"}')} A link to the data product. The expression will display the value as a URL instead of a string.

Making API calls to internal services

Follow these steps to make a call to internal services using the authentication of the last user who acted on the workflow. This can be used to approve or reject data access requests and other APIs as needed.

Follow these steps to make a call to internal services:

  1. To make an HTTP call in Flowable, add an HTTP Service Task.
  2. The base URL for all internal calls using this method is https://cpd-internal. To accept or reject a request, use https://cpd-internal/v2/asset_lists/${order_id}.
  3. Add Cpd-Use-Current-User: true to the list of headers in place of adding an authorization header.
  4. Add an execution listener to the HTTP Service Task. Set the event to start and set the value to ${cpdInternalHttpExecutionListener} for the delegate expression.
  5. For approving or rejecting data access requests, the body of the request takes the following values:
  • If the request has been approved, set the body to: [{"op": "replace", "path": "/state", "value": "ready_to_deliver"},{"op": "add", "path": "/message", "value": "comment"}].
  • If it has been rejected, set the body to: [{"op": "replace", "path": "/state", "value": "rejected"},{"op": "add", "path": "/message", "value": comment}]
  • Replace comment with a string value that the user will see as the reason for the approval/rejection.

When the task is triggered, the API is called using the authentication of the user that last acted on the workflow. The last authenticated user can be the last person to act on a task in the Task Inbox, or it could be the person who triggered the creation of the workflow. Only certain users can make the HTTP call to change the state of a subscription.

Authorizing users to change the state of a subscription

You must authorize the users who can change the state of a subscription that uses the approval process for access. To select which users can change the state of the subscription, follow these steps:

  1. An HTTP Service Task that changes the state of a subscription must be preceded by a user task.
  2. The ID of the user task that triggers a subscription state must have the prefix state-change-.
  3. The user task with the ID prefix state-change- must not have any assignments. Thus, the Assignee, Candidate users, and Candidate groups fields must all be empty.
  4. When creating a workflow configuration with this template, set a list of users or user groups as the assignees for the user tasks with the state-change- prefix.

The list of users and user groups are authorized to change the state of a subscription for a data product that uses the approval process based on this workflow.