vRealize Automation Approval Service API

Approval Service API Specification

What is the Approval Service REST API?

The approval service provides features for managing and tracking the human approval tasks associated with a service process/artifact in a provider realm. It also provides a record of the approval process when it completes.

The goal of the approval service is to provide a generic approval mechanism that any provider can use for any artifact, such as as a service or a resource action (which follows its own provider specified approval process).

Approval is agnostic to the business artifact it is attached to. There is no representation of the artifact within the approval service. The provider (client of the approval service) stores an identifier of an approval to manage the approvals associated with their artifact.

Typical Use Cases

You can use the approval service REST API to implement approval policies for your service or resource action. You can:

• Define multiple approval levels in which actions must be approved.
• Define approval policies that determine how an artifact is approved.
• Query information about the state of specified approvals and the values of data fields in schemas associated with the service or resource action.

Key Concepts

Approval Level

A level of approval that you define for your service. For each level, you can specify approval criteria.

Approval Modes

Each level supports two modes of approval:

• ANY - If any ONE of the users approves, the approval step is complete and the process moves to the next step; for example, from Level 1 to Level 2. After one approver has approved, the remaining approvers are not allowed to approve that level.
• ALL - All the approvers for the level need to approve. Each approver is assigned a workitem. The approval flow can only move on to the next step after ALL the approvers have approved.

Criteria

Approval criteria are specified in a JSON string of a com.vmware.vcac.platform.content.criteria.Clause object:

• Criteria should be set up based on the context that is defined by the corresponding com.vmware.vcac.core.approvals.domain.policy.ApprovalPolicyType##getClassId() and com.vmware.vcac.core.approvals.domain.policy.ApprovalPolicyType##getTypeFilter().

• The properties used in the criteria expression must be those of the client side object identified by the classId and typeFilter.

The CatalogItemRequest client object provides an example of how criteria are specified. A CatalogItemRequest has a criteria expression based on Request fields such as RequestedBy, CatalogItem, and so on, which are direct properties of the CatalogItemRequest class.

How the Approval Service Works

Overall High Level Flow

The approval process involves a simple chain of approval steps:

1. Currently, the approval service supports only a single series of approval steps.
2. Each step in the sequence can contain one or more users.
3. Approval flows from level1 to level2 to level3, and so on. The approvers in level2 do not receive an approval request until level1 is approved, and so on for other steps in the series.
4. If approvers in ANY level reject the request, the whole approval is rejected. This essentially short circuits the approval process.
5. When the final approval step is approved, the Approval instance goes into the APPROVED state.

Notes About Approval Level

1. These are referred to as Level N Approval. Each step is activated in sequence, i.e., Level1 Approval is active first, and after it is done, Level2 Approval is active, and so on.
2. The users in an approval step can be defined (during approval policy creation/definition) using three different methods, by referring to:
   • One or more actual users (hard coding the user ID).
   • One or more AD groups (static) and dynamic groups (composed of multiple AD groups and actual users).
   • The users from contextual data such as $request.owner or $request.owner.manager, and so on.
3. When a step is active, the users in that step are resolved, i.e., groups are expanded and contextual data expression is evaluated. The users in a step are not materialized until that step is active.
4. All the users within the step are notified of the pending approval.
5. If one of those users reject it, the Approval is short circuited and goes into the REJECTED state.
6. A level supports two modes of approval:
   • ANY - if any ONE of the users approves, then after the approval step is complete, the the process moves to the next step; for example, from Level1 to Level2. After one approver has approved, the remaining approvers are not allowed to approve that level.
   • ALL - All the approvers resolved in this level need to approve. Each approver is assigned a workitem. The approval flow can only move on to the next step after ALL the approvers have approved.

Notes About Criteria Associated with a Level

1. Each level has its own criteria that triggers approval from that level.
2. Criteria of every level will be evaluated in sequence.
3. Criteria is essentially a JSON string of a com.vmware.vcac.platform.content.criteria.Clause object.
4. Criteria should be set up based on the context which is defined by the corresponding com.vmware.vcac.core.approvals.domain.policy.ApprovalPolicyType##getClassId() and com.vmware.vcac.core.approvals.domain.policy.ApprovalPolicyType##getTypeFilter()
5. The properties used in the criteria expression must be those of the client-side object identified by the classId and typeFilter. An example is the CatalogItemRequest client object, whose criteria expression is based on Request fields such as RequestedBy, CatalogItem, and so on, which are direct properties of the CatalogItemRequest class.
6. The list of concrete Clauses are:
   • com.vmware.vcac.platform.content.criteria.AndClause
   • com.vmware.vcac.platform.content.criteria.OrClause
   • com.vmware.vcac.platform.content.criteria.NotClause
   • com.vmware.vcac.platform.content.criteria.ConstantClause
   • com.vmware.vcac.platform.content.criteria.Expression
   • com.vmware.vcac.platform.content.criteria.WrapperClause