In our previous blog post, “Mastering Complex Approvals: A Deep Dive into Wait Steps, Script Tasks, and API Integrations,” my colleague & SAP Mentor @mohit_bansal3 tackled a common but challenging business requirement: the “all-or-nothing” approval process.
We explored how SAP Build Process Automation, leveraging features like Wait Steps with API Triggering and workflow context updates via API, can handle scenarios where multiple approvals are needed simultaneously, and a single rejection stops the entire workflow.
We walked through a procurement example where both Department Managers and the Finance Department had to unanimously approve a request before it could proceed.
Now, in this second blog, we will demonstrate the step-by-step testing process for the solution we developed. This will allow you to understand the entire development flow more deeply, from concept to validation. Let’s dive into the testing for the previous blog’s implementation!
Handling Approval Outcomes: Positive and Negative Scenarios
The “All-or-Nothing” Positive Scenario : Lets Start the complete Testing Process
Let’s first explore the “positive scenario,” where every approver gives their stamp of approval. In this ideal outcome, once all required approvals are secured, the main workflow successfully completes its designated task. This seamless progression is the goal of our “All-or-Nothing” design, ensuring that every necessary check is performed before finalization.
Approval Process Triggering
As you know from our previous blog, for demonstration purposes, we created a simple form within SAP Build Process Automation (SBPA).
Main process upon submission of request: Context and log
You’ll notice two approvers listed, which will initiate two parallel workflows. We covered the specifics of these parallel workflows in a previous blog post. The determination of these approvers can come from a decision table or your own custom logic.
The key takeaway here is that we’ve dynamically fetched two approvers, demonstrating the adaptable nature of this step. it can handle any number of approvers.
Dynamically Triggering Secondary Workflows
We’re now kicking off secondary workflows dynamically, and the number of these workflows depends entirely on the number of approvers.
For our current scenario, since we have two approvers, this process will trigger two parallel secondary workflows.
Each of these workflows will then send an individual approval request directly to each approver’s My Inbox.
Dynamically Secondary Workflow Triggered via APIMy Inbox View
Here’s a quick look at My Inbox. For this demonstration, we’ve assigned the same approver.
That’s why you see two work items in this approver’s inbox. In a real-world scenario, these would be two separate workflow approval items, each in the respective approver’s inbox.
Crucially, the main workflow won’t complete until both approvals are in.
Workflow Progress After First Approval
The screenshot below shows the workflow log after the first approver has taken action. As you can see, the workflow isn’t complete yet; it’s waiting for the second secondary workflow to be actioned.
The main workflow will only move forward once both approvals are done.
But before we get ahead of ourselves, let’s examine the workflow log immediately after that initial approvals.
Updating the Main Workflow Context after each approval: SBPA API used as action
We’ll be updating the main workflow’s context after each approval and then comparing it against the total required count.
Here’s a quick glimpse of what happens to the workflow context once the first approval is complete.
You can see the “donecount” increasing, which we’ll use to compare against the total number of approvals needed.
We achieve this by updating the main workflow via its API, a process we’ve already covered in a previous blog post.
The Final Approval and Workflow Completion
Now, let’s go a step deeper and understand the flow when the second, and final, approver takes action.
Once they approve, you’ll see that the secondary workflow also completes, which then triggers the wait step in the main workflow.
This wait step is triggered via an API, a process we covered in detail in a previous blog post.
Understanding this particular use case of the wait step with an API is a critical aspect of this blog’s core message.
Workflow Context After All Approvals
Now, let’s carefully examine how the workflow context gets updated once all approvals are complete.
This is the crucial step that triggers the wait step and allows our main workflow to proceed.
In this scenario, the “donecount” becomes equal to the total number of required approvals, which in turn triggers the wait step API.
Handling Approval Outcomes: Positive and Negative Scenarios
so far We’ve explored the “positive scenario,” where all approvers green-light the requests, leading to the main workflow’s successful completion.
But what happens when an approver rejects a request?
Imagine a scenario where just one approver rejects. In such a case, the entire workflow must be rejected. My colleague, Mohit Bansal, detailed the design considerations for this rejection scenario in a previous blog post, so from a testing perspective, the approach remains similar.
However, in a rejection scenario, we need to take crucial additional steps:
Call the workflow cancel API: This immediately stops the main workflow.Cancel any remaining open instances of secondary workflows: This is critical for designing a robust, production-ready complex workflow. Without canceling these, you could have orphaned workflow instances consuming resources or causing confusion.
Here’s a quick look at how the system responds when any approver rejects: the main workflow is canceled, and all remaining open secondary workflow instances are also terminated.
We hope you enjoyed our blog series! We dove deep into complex workflow approval scenarios, exploring how to effectively leverage wait steps and workflow APIs to achieve robust “all-or-nothing” approval processes.
Please feel free to leave comments and share your thoughts. A big thank you to my colleague @mohit_bansal3 for his contributions, and stay tuned for more blogs on the latest innovations in this area!
Regards,
Adwait Fadnavis
In our previous blog post, “Mastering Complex Approvals: A Deep Dive into Wait Steps, Script Tasks, and API Integrations,” my colleague & SAP Mentor @mohit_bansal3 tackled a common but challenging business requirement: the “all-or-nothing” approval process.We explored how SAP Build Process Automation, leveraging features like Wait Steps with API Triggering and workflow context updates via API, can handle scenarios where multiple approvals are needed simultaneously, and a single rejection stops the entire workflow.We walked through a procurement example where both Department Managers and the Finance Department had to unanimously approve a request before it could proceed.Now, in this second blog, we will demonstrate the step-by-step testing process for the solution we developed. This will allow you to understand the entire development flow more deeply, from concept to validation. Let’s dive into the testing for the previous blog’s implementation!Handling Approval Outcomes: Positive and Negative ScenariosThe “All-or-Nothing” Positive Scenario : Lets Start the complete Testing ProcessLet’s first explore the “positive scenario,” where every approver gives their stamp of approval. In this ideal outcome, once all required approvals are secured, the main workflow successfully completes its designated task. This seamless progression is the goal of our “All-or-Nothing” design, ensuring that every necessary check is performed before finalization.Approval Process TriggeringAs you know from our previous blog, for demonstration purposes, we created a simple form within SAP Build Process Automation (SBPA). Main process upon submission of request: Context and log You’ll notice two approvers listed, which will initiate two parallel workflows. We covered the specifics of these parallel workflows in a previous blog post. The determination of these approvers can come from a decision table or your own custom logic.The key takeaway here is that we’ve dynamically fetched two approvers, demonstrating the adaptable nature of this step. it can handle any number of approvers. Dynamically Triggering Secondary WorkflowsWe’re now kicking off secondary workflows dynamically, and the number of these workflows depends entirely on the number of approvers.For our current scenario, since we have two approvers, this process will trigger two parallel secondary workflows.Each of these workflows will then send an individual approval request directly to each approver’s My Inbox.Dynamically Secondary Workflow Triggered via APIMy Inbox ViewHere’s a quick look at My Inbox. For this demonstration, we’ve assigned the same approver.That’s why you see two work items in this approver’s inbox. In a real-world scenario, these would be two separate workflow approval items, each in the respective approver’s inbox.Crucially, the main workflow won’t complete until both approvals are in.Workflow Progress After First ApprovalThe screenshot below shows the workflow log after the first approver has taken action. As you can see, the workflow isn’t complete yet; it’s waiting for the second secondary workflow to be actioned.The main workflow will only move forward once both approvals are done.But before we get ahead of ourselves, let’s examine the workflow log immediately after that initial approvals.Updating the Main Workflow Context after each approval: SBPA API used as actionWe’ll be updating the main workflow’s context after each approval and then comparing it against the total required count.Here’s a quick glimpse of what happens to the workflow context once the first approval is complete.You can see the “donecount” increasing, which we’ll use to compare against the total number of approvals needed.We achieve this by updating the main workflow via its API, a process we’ve already covered in a previous blog post.The Final Approval and Workflow CompletionNow, let’s go a step deeper and understand the flow when the second, and final, approver takes action.Once they approve, you’ll see that the secondary workflow also completes, which then triggers the wait step in the main workflow.This wait step is triggered via an API, a process we covered in detail in a previous blog post.Understanding this particular use case of the wait step with an API is a critical aspect of this blog’s core message.Workflow Context After All ApprovalsNow, let’s carefully examine how the workflow context gets updated once all approvals are complete.This is the crucial step that triggers the wait step and allows our main workflow to proceed.In this scenario, the “donecount” becomes equal to the total number of required approvals, which in turn triggers the wait step API.Handling Approval Outcomes: Positive and Negative Scenariosso far We’ve explored the “positive scenario,” where all approvers green-light the requests, leading to the main workflow’s successful completion.But what happens when an approver rejects a request?Imagine a scenario where just one approver rejects. In such a case, the entire workflow must be rejected. My colleague, Mohit Bansal, detailed the design considerations for this rejection scenario in a previous blog post, so from a testing perspective, the approach remains similar.However, in a rejection scenario, we need to take crucial additional steps:Call the workflow cancel API: This immediately stops the main workflow.Cancel any remaining open instances of secondary workflows: This is critical for designing a robust, production-ready complex workflow. Without canceling these, you could have orphaned workflow instances consuming resources or causing confusion. Here’s a quick look at how the system responds when any approver rejects: the main workflow is canceled, and all remaining open secondary workflow instances are also terminated.We hope you enjoyed our blog series! We dove deep into complex workflow approval scenarios, exploring how to effectively leverage wait steps and workflow APIs to achieve robust “all-or-nothing” approval processes.Please feel free to leave comments and share your thoughts. A big thank you to my colleague @mohit_bansal3 for his contributions, and stay tuned for more blogs on the latest innovations in this area!Regards,Adwait Fadnavis Read More Technology Blog Posts by Members articles
#SAP
#SAPTechnologyblog
