Introduction
This blog guides through a SAP Build Process Automation use case in which my colleague remo_koetter39 and me automate device order approvals. remo_koetter39 will soon post a blog where he sums up our SAP Build RPA usability experiences.
Our use case considers the scenario that employees can order their technical devices via an UI created in SAP Build. The approval of these device order requests will be automated. Whether an auto approval can be performed depends on the price of the device: If a device price equals or is above EUR 500, approval has to be performed manually. Otherwise, SAP Build will approve automatically. Device prices are determined by searching for an ordered device in an Excel sheet. If a device is not found, prices will be estimated through Amazon web page.
We perform the following steps with SAP Build Process Automation:
- Employee orders a technical device via an UI.
- If device price is >= EUR 500.00, send approval request into SAP Inbox of responsible approver. Otherwise, auto approval is conducted.
- RPA part: Check the device price in an Excel document. If the ordered device is not found, open Amazon web page, search for device and use the price on Amazon web page as estimated price for business decision.
- Notify the employee about the approver’s decision via SAP Inbox.
- RPA part: If approved, open another Excel document (log file) and log the approved order of the device.
Business Process Workflow
As explained above, Desktop Automations are part of our use case, as they are integrated in our SAP Build workflow. This workflow is shown in figure 1 and will be explained in this section.
Figure 1
Business Process Trigger – Device Order Processing Form
Our workflow is initiated by a Device Order Processing Form that functions as process trigger. Employees who are ordering a device are asked to specify device name, employee name, expected delivery date, mail address of the responsible approver, order date and order number. Figure 2 shows an end user view of the Device Order Processing Form.
Figure 2
Desktop Automation – Find Device in Excel or on Amazon
The device name which was specified in the process trigger form is then taken as input in our first Desktop Automation to search for the corresponding device price.
First, we look up the device name in an Excel table (Figure 3), in which common devices are listed (STEP 1).
Figure 3
If the requested device is not found in this Excel table, we go on Amazon web page and search for the device name. We pick the first search entry and use its price for an estimation of the actual device price (STEP 2).
STEP 1:
We apply the activities Open Excel Instance and Open Workbook to open our Excel file with our listed devices. For setting up the Open Workbook activity, use path + name + file ending as workbookPath parameter.
“C:\Users\JohnSmith\Documents\Devices.xlsx”
As shown in Figure 4, we initialize certain variables that will be used in the subsequent WHILE-loop. We additionally read the first device of the table before entering the loop, to initialize the entry condition of our loop. Then we read device name after device name and compare each device name to the requested device (WHILE-Condition). For comparison, we use a variable (str_thisCell) that we have created before the loop. During the loop, we assign the output of Get Values (Cells) – in our workflow called Read Current Cell – activity to str_thisCell instead of simply using the output straight for comparison. We stop if the device name in a certain line matches with the name of the requested device.
Figure 4
If we find the requested device, we read the price that is written in the same line where we found it (left path in the next screenshot). The activity Assign float_thisPrice includes a conversion from string to float, performed with the JavaScript method parseFloat(). Remember closing the Excel instance when the task is completed.
STEP 2:
If the requested device was not found in the Excel, we open Amazon web page (right branch in the next screenshot), as shown in Figure 5, and search for the device name (upper web page Günstige Preise […]). We read the price of the first result (lower web page iPhone 11). Hereby remember, that you first have to declare an application within SAP Build and these two pages within the application. Afterwards you can insert them as so called screens.
Figure 5
Business Process – Approval and Rejection
After the device price was successfully identified, our workflow utilizes a condition to decide whether we proceed in an auto approval branch (device price less than 500) or in a manual approval branch (otherwise). This branch condition can be seen in Figure 6.
Figure 6
If our first Desktop Automation asserted that the device price is below 500, an Auto Approval Notification will be sent to the employee who initiated the process by ordering a device. The employee will be notified about the auto approval via SAP Inbox and requested to acknowledge device order information. This device order information is retrieved from the information which has been passed on through the process trigger form. Properties of the Auto Approval Notification can be seen in Figure 7 and Figure 8.
Figure 7
Figure 8
If our first Desktop Automation instead asserted that the device price is not below 500, an Approval Form (Figure 9, Figure 10) will be sent to the approver which was specified by the employee when initiating the process. This manual approval request incorporates all relevant device order information. Using SAP Inbox, the approver can either approve or reject the device order and has to leave a justifying message for the employee.
Figure 9
Figure 10
Figure 11 depicts, that if the approver has approved the device order, an Order Confirmation Form will be sent to the employee, and if the device order was manually rejected, an Order Rejection Form will instead be sent. These forms contain all relevant information, as well as the approver’s message to the employee.
Figure 11
Desktop Automation – Log Approved Orders to Excel
After the actual approval is completed, our second Desktop Automation is included in the workflow. This Desktop Automation logs device order details into a logging Excel.
Order details are passed as parameters. If we had an auto approval (device price < 500), Auto will be entered as approver name. As in the first Desktop Automation, we use the activities Open Excel Instance and Open Workbook to open our logging .xlsx-file.
We search for the first empty row. As shown in Figure 12, and similar to the last Desktop Automation, we iterate over the Excel table and check row by row if the cell of the device name is empty (cell value==null or cell value==“”). Once, we have found this empty row, we print all the order details into this row using Set Values (Cells) activity.
Figure 12
An exemplary logging Excel is shown in Figure 13.
Figure 13
The automation ends with closing the Excel instance (Close Excel Instance activity).
Deployment
Concerning the deployment of our SAP Build Process Automation Project, releasing the complete project successfully works but an error (Figure 14) occurred when deploying it.
Figure 14
Faultless design and test consoles (Figure 15) indicated that the deployment error did not result from any specific errors when building and implementing our workflow and automations.
Figure 15
No deployment errors occur when deploying projects which solely consist of our Desktop Automations. Successfully deploying these projects was only possible if these automations (which incorporate desktop agent actions) were not included in any processes.
Additionally, no deployment errors occur when deploying projects that only consist of processes. These processes do not include any automations.
No deployment errors occur when deploying projects which consist of processes that include automations with no or inactive desktop agent actions.
Finally, we noticed that our deployment error resulted from the fact, that, in our first Desktop Automation, two application modules were positioned directly one after another (Figure 16). This was identified as described in the following.
Figure 16
When we deactivated the first application module, deployment successfully worked. So, we reactivated the first application module and deactivated the second one. Deployment still worked. When we reactivated the second application module, so that both application modules are now active after both being deactivated alternately, deployment still successfully works for our complete and all-over project.
This indicates an internal SAP Build bug, as deployment success did not solely depend on the actual implementation. As seen in Figure 17, to avoid this bug, we positioned a random variable assignment between the two deployment-critical application modules.
Figure 17
Run the Application
After successfully deploying our project, we need to execute test runs of our deployed project triggered by the Device Order Processing Form. To employ our Desktop Automations, our Desktop Agent must be in Unattended Mode (Figure 18).
Figure 18
Further on, the Desktop Agent must be added in our Agent Management Menu, as shown in Figure 19.
Figure 19
When we open our process in the final deployed version, clicking on the trigger form provides a link to this trigger form (Figure 20), so that test runs can be initiated.
Figure 20
We open the link, fill in necessary information into the Order Approval Request Form (Figure 21) and click on submit.
Figure 21
Our first Desktop Automation will then investigate the device price. If a higher device price triggers a manual approvement, the respective Approve Sales Order form (Figure 22) will be sent to the inbox of the responsible approver, whose mail address was stated by us in the trigger form.
Figure 22
From there on, we proceed, so that in the end – if the device order was not rejected – we can finally find our logged device order in the excel log file. An example of this excel log file can be seen in Figure 23.
Figure 23
Conclusion
Our experiences using both, SAP Build Business Processes and SAP Build Desktop Automations, lead us to a similar conclusion as Gartner in their market research report Magic Quadrant about RPA from July 2022. Gartner recognizes a high completeness of vision but evaluates the ability to execute as upgradable.
Regarding functionalities promised by SAP, we think of SAP Build as RPA plus. It has common RPA capabilities extended with cloud-based Business Processes. Especially when already working with SAP systems, SAP Build can offer huge advantages compared to other RPA tools. Examples are integrations of SAP Inbox, SAP databases and many more.
Moreover, SAP Build’s Desktop Agent offers the capabilities to deploy less steps on-premise and to execute certain steps - that do not involve desktop activities (e.g. certain control structures such as business decisions or sending of messages to SAP Inbox) - in the cloud-based environment. This can prevent errors, since less interaction with the GUI is needed.
Nevertheless, SAP has to improve its executing abilities. Additional to development inconveniences, deployment and execution of SAP Build projects tend to be buggy and unreliable. Such issues concerning development ease and development flow are further described in remo_koetter39 upcoming blog post.
We believe that SAP Build contains great ideas. Consequently, we will keep an eye on this tool and consider implementing further projects to evaluate broader SAP Build capabilities, for instance integrating custom scripting. Summed up, we currently consider SAP Build as trendsetter and interesting alternative for smaller solutions with limited complexity.
- SAP Managed Tags:
