Role-based requirement approvals in SAP Cloud ALM with external workflows in SAP BPA

[danielbolz]

Objectives

This SAP blog post gradually outlines how workflows can be used to extend the approval process of requirements by retrieving team roles from an SAP Cloud ALM project. The workflow management system used in this blog post is the SAP Build Process Automation (abbr. SAP BPA) running on SAP BTP.

Prerequisites

• You have already provisioned an SAP Cloud ALM tenant and SAP Build Process Automation system, which are both running in your SAP BTP system landscape.
• The connection between SAP Cloud ALM and SAP Build Process Automation was already established via Destinations, Webhooks and Subscriptions to transmit Task API data bidirectionally. If this is not yet done, please review the previous SAP blog post to implement all necessary steps.
• Additionally, an SMTP mail server destination is configured in your SAP BTP subaccount to receive emails from SAP BPA.
• A Desktop Agent to execute the automated workflow on SAP BPA is already installed on your local computer.
• You have been assigned at least the role collections ProcessAutomationAdmin and ProcessAutomationDeveloper in your SAP BTP subaccount.

Procedure Overview

• Define a custom project team role in SAP Cloud ALM.
• How the workflow solution design looks like in SAP BPA.
• Overview about which REST APIs are needed and how they work.
• How to fetch members of a project role in the subsequent workflow.

Define project team role in SAP Cloud ALM

In the first step, you must go to your SAP Cloud ALM project and add another custom project role which should be called “Requirement Approver”. Following that, this new custom role must be assigned to your project in the Teams tab. Afterwards, assign the corresponding users who should review the requirement later by accepting or rejecting the approval document in SAP BPA. I have assigned two demo users here, however there could be multiple and different approver roles per project.

Workflow Solution design

Let’s focus on the design of the workflow solution in SAP BPA. At the beginning of the process, a trigger is initiated by an event from SAP Cloud ALM that requests the requirement’s data. The outputs of the API trigger are automatically synchronized with the process attributes in SAP BPA. The task details of the requirement are retrieved from SAP Cloud ALM via an HTTP GET method. The task is being identified by its ID via the API connection.

On the level of the second step, the attribute “projectID” which was transmitted via the API from SAP Cloud ALM, must be specified as input variable in the step details. The other two variables “RoleName” and “TeamName” must be manually entered since these aren’t transferred via the API. Those variables will be checked in the subsequent workflow (see next chapter), whether they match.

Following this step, the workflow then checks in a branch condition whether the submitted list from the subsequent workflow is empty, in which the users of the project role “Requirement Approver” from SAP Cloud ALM would normally have been listed. Additionally, the branch condition assesses if the requirement status has been set to “In Approval”. Here, the technical name of the requirement status, coming from the API, must be stated.

If one of the two branch conditions hasn’t been met, e.g. if the requirement has the status “Blocked”, the workflow will abort, and an error email will be forwarded to the user who triggered the approval workflow. The approval or rejection of the requirement will be issued via an HTTP POST method to set the status of the task accordingly.

Continuing in the workflow structure, the corresponding approver(s) will receive an email to proceed to the SAP Build Process Automation Inbox. From there they must complete the Requirement Approval document and either approve or reject the requirement manually.

Overview of Rest APIs and their usage

Reading multiple members of a project role from SAP Cloud ALM works by using several REST API interfaces provided from the SAP Business Accelerator Hub. The relevant API are SAP Cloud ALM Tasks and SAP Cloud ALM Projects.

First, the Task API provides the necessary data record which includes the Project ID and is essential to fetch all teams of an SAP Cloud ALM project. This team in SAP Cloud ALM contains multiple project roles, however only the own created “Requirement Approver” project role is relevant. After given the reference from the Task API to the Project ID, all roles of the given PMO team must be finally read out. The assigned users of the project role “Requirement Approver” are listed with their email address in the transmitted Team Roles API.

How to fetch members of a project role

After given this high-level overview about how project roles can be read out with the usage of REST APIs, I would like to focus on some deeper insights into the step “Get Members of Role in Team” from the Workflow Solution Design.

The subsequent process workflow starts by defining an action, which calls all teams of the transmitted project id via API. An empty list will be created to save all the found project members later. After that, the workflow loops through each team of the given project from SAP Cloud ALM and checks if the current team’s name is equal to the team’s name (= “PMO Team”) specified in the parameter section from the Workflow Solution Diagram.

In the affirmative case which highlights that the PMO team was found in the SAP Cloud ALM project, another action is triggered to get all the project roles of this PMO team.

Another for-loop decision traverses through all the roles of the PMO team and checks if the input (= “Requirement Approver”), is found and meets the expected value. Based on this decision, the empty list will be filled with the user’s email address. As soon as the desired project role is found, the for-loop should end the workflow.

Let’s also talk about the termination mechanism. For instance, if the “Requirement Approver” project role wasn’t found in the SAP Cloud ALM team, because it wasn’t either created or no users were maintained in a project role, then several abortions were inserted to prevent an endless loop.

Result

After triggering the request approval status of the requirement in SAP Cloud ALM, the users of the project role “Requirement Approver” will receive an email asking them to review the requirement.

They will get forwarded to the SAP BPA Inbox, where the respective stakeholder can review the and either approve or reject the requirement.

The result of the requirement review process will be updated in SAP Cloud ALM.

Conclusion

For organizations requiring a more customized workflow solution for their requirements in SAP Cloud ALM together with SAP Build Process Automation, my SAP Consulting department offers a consulting service, which can assist in implementing advanced configurations for workflows. Please contact us via the following email to ask about the workflow integration solution: alm.consulting@sap.com.

With these upcoming developments, SAP Cloud ALM is set to become an even more powerful tool for managing workflows and approvals, offering enhanced flexibility and automation capabilities.