This blog helps No-Code enthusiasts and curious pro-code developers to get a glimpse into the potential of No-Code/Low-Code technologies and see how quickly a use case can be put into action.
At the annual Hackathon event held by SAP called Hack2Sol (Hack to Solution) I had the pleasure to attend as a trainer and assist my customer in developing a real-life use case. The event takes place over days; the first 2 days are dedicated to understanding the pain points of my team and creating a prototype with the design thinking toolset. The remaining days take place in the AppHaus in Heidelberg in Germany, where the magic happens: With the assistance of an ambitious team of trainers (SAP and non-SAP) we close ourselves off from our normal daily schedule and focus on developing our prototype.
In the end each team (six in total) presents their solution to the other contestants and jury, some in a Hollywood ready manner! Also, a winner is crowned but more about that later…
Now in a nutshell: What did my team accomplish?
After last year’s TechEd buzz around the SAP Build platform, it comes as no surprise that this Hackathon was going No-Code – taking to the test if SAP Build Apps has what it takes to keep up with Pro-Code. Besides SAP Build Apps my team used other SAP Cloud Platform services such as Business Application Studio (BAS) and SAP Build Process Automation (part of the SAP Build Platform) to develop our use case.
In the design thinking phase, we laid out specifically how the architecture of our solution would look like:
Let’s talk about the use case: My team’s company is a manufacturer that operates worldwide and uses SAP in an extensive manner. Just like in any company the topic of maintaining SAP authorization for each user is of great importance and with a high number of employees the authorization process has been tested to its limits many times.
The status quo of the role-request and -approval process was described as dissatisfactory. Too many tools are intertwined in a complicated manner and the UI made it difficult for users to find the roles that are associated to their branch or working area. Instead, a user could only gain role pre-selections by inheriting all the roles of a colleague. As a consequence, the roles a new employee attains through inheritance accumulate over time which poses a security risk.
In conclusion, the process was anything but easy. Therefore, our solution would be named “EasyAuth”.
It all starts with a good plan. The team carefully sketched out in which way the old process can be improved: what are essential steps in the process, which once are future capabilities, how does our data model look like, which tool will cover which process step, and in the end: what can we accomplish in only 2,5 days of developing?
Our backend would follow the framework of the Cloud Application Programming Model (CAP). This poses a great test-case because it will be exposed as an OData service, just like the actual deployment would be based on OData from the customers backend. Within Business Application Studio, also a BTP Service, you can generate a CAP project from a template. Even more helpful is the graphical data modeler, which helped us to directly recreate our UML via drag-and-drop and form settings. The code is being generated simultaneously to our visual model.
We provided the data very conveniently via csv files, which was totally sufficient for our test case. While all that sounds fairly simple, a Citizen Developer might have difficulties defining the needed Core Data Services to then expose the entities via OData, as coding knowledge is needed. As seen in our tech architecture model we need to create a destination in the BTP for our deployed CAP services to access the backend from our SAP Build Apps. By enabling the BTP Authentication in SAP Build Apps, the just created destinations can be accessed to start working with the data in the app.
As the backend is central for a successful development project, this took us quite some time. Now, let’s get wild in SAP Build Apps!
Let’s see what we came up with:
There are two login screens, one for the requestor of the role and one for the approver of the role. For the test case we worked with global variables to verify the credentials, for the real-life case a SSO integration would take place.
For the affected user search my team implemented a value help. For this case we wrote a formula with a SELECT statement, that would only display the items that correspond with the search input of the user.
The center piece of the UI is the overview page of all roles. An important function was the drop-down selection to filter the roles by company code and functional area. The options within the dropdown menu are mapped with a formula function from the original data source. Therefore, the options are always up to date if the values in the data source change. For this test case the default view of the list is the unfiltered collection of all data records. Thanks to the logic canvas, a trigger could be defined which will filter the displayed data collection according to the option that the user has selected.
One advantage of SAP Build Apps is the fact that almost every component setting can be configured with a formula function which opens the door for more individualization. You can even set a formula on the background color which we did in a few cases. One way to do that is to formulate an IF statement that looks up the status and depending on the value sets the HEX color code.
After the user selected all the needed roles and pressed “confirm input” the approver can view the selected roles and decide on whether to confirm or reject the requests:
The user can view the status of his request at all times:
In the scope of this event, we moved the approval process to SAP Build Apps while in the future this is planned to take place in process automation. So far, we managed to establish an integration and successfully send test data to process automation. It is planned to trigger a workflow inside process automation as soon as a request is sent. After that the approver receives an e-mail notification about a new request which will then be done via a formula in process automation.
As one of the contestants put it quite aptly “In order to use SAP Build Apps you need to THINK like SAP Build Apps”. For example, if you wish to include a table in your app and the standard component is not sufficient for your need, you might have to drag-and-drop a bunch of row- and cell-containers and set a “repeat data item” on one row. Another example: if you wish to work with data from your integration, you must set “data variables” on each page. And where does one find those variables anyway???
After working with this platform for some time, these developing steps make total sense. But what I realized while developing with my team of “newbies”, is that the initial understanding is not as intuitive as one might believe. Especially if C++ is on your daily menu. With a tool like this you don’t possess the almighty power and you need to learn how to work within the bounds of the platform to create a valuable solution.
With “EasyAuth” we proudly landed the second place of the Hackathon! The winning team came up with an incredible solution called “Bookfinder” and developed a book lending app with a scanner function where the user could get information on a book and, among other functionalities, lend and return it. This team even finalized a workflow integration with process automation and an integration to their own SAP system! This outperformance received even my final vote.
All in all, everyone was impressed with the capabilities of No-Code tools, the great potential they bear to improve a stale process and what a small group of dedicated minds can accomplish in just a few days!
Further reads:
Create SAP Build App to Trigger Workflow | Tutorials for SAP Developers
Jumpstart & Grow as You Go | CAPire (cloud.sap)
At the annual Hackathon event held by SAP called Hack2Sol (Hack to Solution) I had the pleasure to attend as a trainer and assist my customer in developing a real-life use case. The event takes place over days; the first 2 days are dedicated to understanding the pain points of my team and creating a prototype with the design thinking toolset. The remaining days take place in the AppHaus in Heidelberg in Germany, where the magic happens: With the assistance of an ambitious team of trainers (SAP and non-SAP) we close ourselves off from our normal daily schedule and focus on developing our prototype.
In the end each team (six in total) presents their solution to the other contestants and jury, some in a Hollywood ready manner! Also, a winner is crowned but more about that later…
Now in a nutshell: What did my team accomplish?
Hack – the technologies we used
After last year’s TechEd buzz around the SAP Build platform, it comes as no surprise that this Hackathon was going No-Code – taking to the test if SAP Build Apps has what it takes to keep up with Pro-Code. Besides SAP Build Apps my team used other SAP Cloud Platform services such as Business Application Studio (BAS) and SAP Build Process Automation (part of the SAP Build Platform) to develop our use case.
In the design thinking phase, we laid out specifically how the architecture of our solution would look like:
To – the problem my customer faced
Let’s talk about the use case: My team’s company is a manufacturer that operates worldwide and uses SAP in an extensive manner. Just like in any company the topic of maintaining SAP authorization for each user is of great importance and with a high number of employees the authorization process has been tested to its limits many times.
The status quo of the role-request and -approval process was described as dissatisfactory. Too many tools are intertwined in a complicated manner and the UI made it difficult for users to find the roles that are associated to their branch or working area. Instead, a user could only gain role pre-selections by inheriting all the roles of a colleague. As a consequence, the roles a new employee attains through inheritance accumulate over time which poses a security risk.
In conclusion, the process was anything but easy. Therefore, our solution would be named “EasyAuth”.
Solution – what we came up with
It all starts with a good plan. The team carefully sketched out in which way the old process can be improved: what are essential steps in the process, which once are future capabilities, how does our data model look like, which tool will cover which process step, and in the end: what can we accomplish in only 2,5 days of developing?
Our backend would follow the framework of the Cloud Application Programming Model (CAP). This poses a great test-case because it will be exposed as an OData service, just like the actual deployment would be based on OData from the customers backend. Within Business Application Studio, also a BTP Service, you can generate a CAP project from a template. Even more helpful is the graphical data modeler, which helped us to directly recreate our UML via drag-and-drop and form settings. The code is being generated simultaneously to our visual model.
We provided the data very conveniently via csv files, which was totally sufficient for our test case. While all that sounds fairly simple, a Citizen Developer might have difficulties defining the needed Core Data Services to then expose the entities via OData, as coding knowledge is needed. As seen in our tech architecture model we need to create a destination in the BTP for our deployed CAP services to access the backend from our SAP Build Apps. By enabling the BTP Authentication in SAP Build Apps, the just created destinations can be accessed to start working with the data in the app.
As the backend is central for a successful development project, this took us quite some time. Now, let’s get wild in SAP Build Apps!
Let’s see what we came up with:
There are two login screens, one for the requestor of the role and one for the approver of the role. For the test case we worked with global variables to verify the credentials, for the real-life case a SSO integration would take place.
For the affected user search my team implemented a value help. For this case we wrote a formula with a SELECT statement, that would only display the items that correspond with the search input of the user.
The center piece of the UI is the overview page of all roles. An important function was the drop-down selection to filter the roles by company code and functional area. The options within the dropdown menu are mapped with a formula function from the original data source. Therefore, the options are always up to date if the values in the data source change. For this test case the default view of the list is the unfiltered collection of all data records. Thanks to the logic canvas, a trigger could be defined which will filter the displayed data collection according to the option that the user has selected.
One advantage of SAP Build Apps is the fact that almost every component setting can be configured with a formula function which opens the door for more individualization. You can even set a formula on the background color which we did in a few cases. One way to do that is to formulate an IF statement that looks up the status and depending on the value sets the HEX color code.
After the user selected all the needed roles and pressed “confirm input” the approver can view the selected roles and decide on whether to confirm or reject the requests:
The user can view the status of his request at all times:
In the scope of this event, we moved the approval process to SAP Build Apps while in the future this is planned to take place in process automation. So far, we managed to establish an integration and successfully send test data to process automation. It is planned to trigger a workflow inside process automation as soon as a request is sent. After that the approver receives an e-mail notification about a new request which will then be done via a formula in process automation.
The challenges
As one of the contestants put it quite aptly “In order to use SAP Build Apps you need to THINK like SAP Build Apps”. For example, if you wish to include a table in your app and the standard component is not sufficient for your need, you might have to drag-and-drop a bunch of row- and cell-containers and set a “repeat data item” on one row. Another example: if you wish to work with data from your integration, you must set “data variables” on each page. And where does one find those variables anyway???
After working with this platform for some time, these developing steps make total sense. But what I realized while developing with my team of “newbies”, is that the initial understanding is not as intuitive as one might believe. Especially if C++ is on your daily menu. With a tool like this you don’t possess the almighty power and you need to learn how to work within the bounds of the platform to create a valuable solution.
Congrats to the winning team!
With “EasyAuth” we proudly landed the second place of the Hackathon! The winning team came up with an incredible solution called “Bookfinder” and developed a book lending app with a scanner function where the user could get information on a book and, among other functionalities, lend and return it. This team even finalized a workflow integration with process automation and an integration to their own SAP system! This outperformance received even my final vote.
All in all, everyone was impressed with the capabilities of No-Code tools, the great potential they bear to improve a stale process and what a small group of dedicated minds can accomplish in just a few days!
Further reads:
Create SAP Build App to Trigger Workflow | Tutorials for SAP Developers
Jumpstart & Grow as You Go | CAPire (cloud.sap)
- SAP Managed Tags:
