SAP Builders Blog Posts
Learn from peers about their low-code journey and write your own blog posts to share your thoughts and experiences as you become an SAP Builder.
cancel
Turn on suggestions
Auto-suggest helps you quickly narrow down your search results by suggesting possible matches as you type.
Showing results for 
Search instead for 
Did you mean: 

Real-World API Calls to S/4HANA (CRUD) from SAP Build Apps

Dan_Wroblewski
Developer Advocate
Developer Advocate
‎2023 Dec 21 2:08 PM
3,181

We've all seen how to quickly connect to S/4HANA from SAP Build Apps, and to display a list of sales orders or business partners – see here, here and here, as examples. But what about creating, updating and deleting records. What about handling the complex associations of S/4HANA APIs? And what about handling the many rules within those APIs?

dan_wroblewski_0-1703439174659.png

I have created a simple app to show off how to to build a real-world app. The app does the following:

  • Displays a list of business partners.
  • Displays all the current addresses for a specific business partner.
  • Lets the user
    • Create a new address
    • Update an existing address.
    • Delete an existing address.

The app is basic, but it's meant to show in general how to handle API calls, including all the CRUD operations as well as the underlying business rules of the data.

I have provided the following:

 

What could go wrong with the API?

Business partners is a very simple API, so what kind of problems could happen?

Working on this simple demo I learned a lot about this API:

  • You cannot delete an address if it is labeled as the default address (AddressUsage = XXDEFAULT).
  • If you add an address to a business partner with no addresses, that address must be labeled as the default address, but if you are adding an additional address, that address CANNOT be labeled as the default address.
  • There are all types of conditions for the data. For example, if you add an address from the United Kingdom, it must include a postal code (Postal codes are not needed for the US or Sweden)

So you must handle these situations in your app. Below I try to show ways to deal with these issues.

Our 3 screens

In our app, we build 3 pages. The first is a list of business partners:

dan_wroblewski_2-1702911603869.png

The second is a list of addresses for a particular business partner (red indicates the default address):

dan_wroblewski_4-1702911762293.png

The third is a form for updating an address or creating a new address:

dan_wroblewski_3-1702911632072.png

Data Setup

I have a destination set up to S/4HANA Cloud with permission to the Business Partners API. I do 2 things:

  • I enable BusinessPartners and BusinessPartnerAddress.
  • In BusinessPartnerAddress, I expand the embedded entity AddressUsage, as I need to know if an address is the default address.

dan_wroblewski_3-1702906191317.png

Screen 1

This is a pretty typical list screen, with a List Item component, whose Repeat with property bound to the data variable.

The Component tap event simply opens the addresses page, sending in the selected business partner ID:

dan_wroblewski_4-1702906387690.png

Screen 2

The addresses screen is also a simple list, but this time there are some cool features:

  • Instead of a simple List Item component, we wrap the component and a delete icon into a container, and then use the Repeat with property of the container.
    dan_wroblewski_5-1702906573321.png
  • On click of the delete icon, we check if the address is the default address. If it is, we alert the user that it cannot be deleted. dan_wroblewski_6-1702906716954.png
  • We use a formula to change the color of the default address. We edit the container's style, and for the background, we select to create a new color under Local Palette, and then select formula.
    dan_wroblewski_7-1702906932293.png  

 

 

IF(IS_EMPTY(repeated.current.to_AddressUsage.results),"","rgba(196,63,63,0.3)" )​

 

 

The formula checks if the AddressUsage is set (to XXDEFAULT); if so, it sets the color to red. 

dan_wroblewski_8-1702907022993.png

  •  Finally, we set 2 logic flows, one for the New Address button (to create a new address) and one for the click on an existing list item (to edit an existing address). For each we need to send in BP ID, Address ID, and whether this address needs to be marked as the default address. dan_wroblewski_0-1702907340248.png

Screen 3

This page contains the form for either creating a new address or updating an existing one.

A lot of the heavy lifting is done by the data variable. We create a New variable (essentially, just an empty variable with the data schema) for Address data. And we create a logic to set its values.

dan_wroblewski_0-1702907963554.png

The logic checks if we are updating an existing address. If yes, we retrieve the data for that address. Either way, we then set the fields of the data variable with a formula.

And at the end of the logic, either for create or update, we check if the address will be / is the default address. If yes, we add the AddressUsage flag.

All the form fields are bound to our data variable.

dan_wroblewski_0-1702910251151.png

And the logic of the Save button just checks if we are updating or creating a new field, performs the appropriate flow function, and then navigates to the main addresses page (Screen 2).

dan_wroblewski_1-1702910376025.png

The take-home lessons

The main thing that's required when working with SAP Build Apps and SAP backend data is that you really have to understand the business logic and the API structure in order to make a good app.

It would help if SAP Build Apps was able to display the backend error messages so that the app can explain what went wrong when errors occur (and I'm sure that will be solved soon).

 

 

 

 

 

 

 

 

9 Comments
Labels in this area
Popular Blog Posts