Skip to Content
Personal Insights
Author's profile photo Daniel Wroblewski

Unboxing: Application Backends in SAP Build Apps (Entities)

I wanted to give a quick “unboxing” of the new application backend feature – which lets you build your own backend data models and to define functions that run in the cloud. I will start with the data modeling (aka, “Entities”) part. Next week I will unbox the functions part.

[Yes, this feature has been commonly referred to as “Visual Cloud Functions”, and the term does appear in the UI inside the Data tab and in the documentation but it is most visibly called “backends” and VCF seems to refer to only part of the feature, so for this blog post I’ll refer to it as application backends.]

Also note there is really nice documentation for the feature.

 

Basic Benefits

Before going into what’s in the box, lets ask, “What’s in it for me?”

Without this feature, I needed to access a CAP service, HANA database or any external data store to get my data, and use that data store to share information among the many users. I do have on-device storage, but of course, that data was not shared.

Now I can create an application that has its own backend, like a real app, all without dealing with CAP, HANA or any other database.

 

Creating Data Entities

Creating data entities is pretty intuitive. I created the entities based on the model defined in the  AD180 virtual workshop for SAP TechEd.

  1. The SAP Build lobby, you click Create → Build an Application → Application Backend, and give your backend a name, like StoreFront.

  2. In the home page, you can click Create New and enter a name to create a new entity.

  3. And finally, click the new entity, and click Add New to add fields to the entity.

Pretty straightforward. Note the data types that are supported here, not all the types as in the UI designer.

Extended Entities

In addition to “regular” entities, you can build “extended” entities, basically views of a existing regular entity. In addition to simply getting the records of the source entity, you can:

  • Hide certain fields.
  • Create calculated fields using the standard SAP Build Apps formula editor.

So, using the data model from the workshop, I created an extended entity based on the product entity and hid the original product field (which is a list of product names), and created a new product field that contains the same data but removes duplicates.

Here’s the extended entity fields, showing the hidden field and the new calculated field:

And here’s the definition for the calculated field, basically a JavaScript formula:

If you click on the formula, you get the regular formula editor, without all the usual variables, but with access to the source entity data and all the functions.

 

Deploying the Backend

Every time you make a change to your backend (either entities or functions) and want it to be available to your SAP Build apps you need to deploy it.

It’s all pretty simple, except that everytime you want to see/test your change – even if just to add data – you must deploy and each deployment for me took around a minute. To me that was a little annoying.

If the change doesn’t cause problems, you just click on Review and Deploy, and you will see the version number.

But if you make a change that might break the front-end app – like remove a field – it will tell you.

If you decide to deploy the change, you will get a list of possible breaking changes that you made. Below, I removed a field, so if a UI was using that field it would cause a problem in that app.

Above, for example, I hide the field “product” in the extended entity, so any UI using that field would not work.

Click History to see a history of your changes.

Select one to revert back to that version. That version is now loaded but not saved, so if you want to keep that version, just save and redeploy.

 

Enabling the Backend from the UI

Enabling the backend is similar to enabling destinations.

Go to the Data tab, and click Add Integration → Cloud Functions.

You will see your backends, and you can select one.

Finally, inside, you can see the entities and functions available. You can select one, and then click Enable Data Entity.

Notice that you can select Data Entities and Cloud Functions tabs to view either of those objects.

 

Accessing the Backend from the UI

Finally, we want to access the data. This is done just like any other data source.

Add a data variable based on that data source.

Then use it as any other data variable, for example, attaching to a component’s Repeat with property.

What’s really nice is if a “breaking” change is made to the backend, then when I next edit an app that uses that backend, I will automatically get a notice that the backend was changed and listing the breaking changes.

 

Some Thoughts

People are already asking about additional features – e.g., Excel upload, access to the data outside of SAP Build Apps (service creation). The feature only just came out, so I assume it will rapidly evolve and improve, with composition of entities, additional data types like files, user-based roles, more SQL-like control, and basically more like a regular database.

But we have to remember that development has to add whatever features and still keep it a low-code tool, one that continues to be easy to use and designed for business users.

I think 2023 will bring a lot of cool stuff. Let’s keep a look out together.


See all my blogs and connect with me on Twitter / LinkedIn

 

Assigned Tags

      7 Comments
      You must be Logged on to comment or reply to a post.
      Author's profile photo Sergio Guerrero
      Sergio Guerrero

      Daniel, thank you for sharing this blog. 2023 indeed is starting with a lot of great content, cool stuff and promising technologies.  your blog seems very simple and straight forward to create Entities.

      Since this is not using CAP or HANA, where do the entities live? are these entities created per project? or can they be shared as part of a multi project initiative? I notice there is version control on the entities, is that controlled via a git repo or something different? can multiple developers work on the same project but different entities?

      Author's profile photo Thomas Madsen Nielsen
      Thomas Madsen Nielsen

      Hi Daniel Wroblewski

      I'm also interested in knowing the answer to the questions asked by Sergio Guerrero and additionally I would like to ask a question that is perhaps a little off topic.

      I know the main topic is how to handle data without a back-end SAP system, but I just noticed that you mention CAP services and not RAP services.

      You write "Without this feature, I needed to access a CAP service, HANA database or any external data store" so my question is this:

      Is it possible to consume Odata web APIs build on top of CDS views (for example with ADT for Eclipse) in "SAP Build App" to create, read, update data?

      And by the way - happy new year.

      Thomas Madsen Nielsen

      Author's profile photo Sergio Guerrero
      Sergio Guerrero

      hi Thomas Madsen Nielsen any OData service should be consumable by SAP Build Apps. You just have to configure the Data tab (or Destination) with the OData service details (same applies for REST APIs)

      Author's profile photo Daniel Wroblewski
      Daniel Wroblewski
      Blog Post Author

      Thomas Madsen Nielsen Sergio Guerrero The backend technology I am less familiar with but I will get you an answer. I was using a CAP service but it was a publically available service. I don't know of any such limitations, except for on-premise services via cloud connector (which is expected to be enabled soon. I will get someone to answer these questions.

      Author's profile photo Marc Huber
      Marc Huber

      Sergio Guerrero The SAP Build Apps Backend project creates a postgres database that runs on BTP. You can also share the backend that multiple developers can work on the same backend project. You can also reuse the backend in different frontend applications.

      Author's profile photo Jay Adnure
      Jay Adnure

      Hi Marc Huber  - Postgres database for no code database?

      Author's profile photo Mustafa Bensan
      Mustafa Bensan

      Hi Marc Huber

      What is the reason for using a PostgreSQL database instead of SAP HANA Cloud?  I would have thought SAP HANA Cloud would have been the more obvious choice and also considering that the PostgreSQL on SAP BTP service has been retired.

      Regards,

      Mustafa.