BLOGS

SAP Appgyver – un véritable couteau suisse des APIs.

May 18, 2022

There is a growing demand from businesses to expose functionality both selectively and securely to either domain and ad-hoc users. Using either public or custom-built APIs.

Thus the focus is on having Appgyver to help satisfy the growing demand in terms of productivity and a consumer-grade approach to business applications.

As a part of the SAP community LCNC challenge, this brief is to showcase how to consume 3rd party REST APIs with SAP Appgyver, by leveraging its built-in Data integration capabilities.

Recently, I have demonstrated this approach against one of the publicly available banking APIs exposed by S/4HANA Public Cloud application.

This time I shall describe how this can be done in a consumer-grade scenario against a 3rd party Rebrickable API that gives access to LEGO collections database.

An aerial view of SAP Appgyver Data integration capabilities.

SAP Appgyver offers a so-called “zero lock-in” approach to data. In other words data never hits Appgyver backend servers.

All one needs to get done is to expose required functionality with either ODATA or REST APIs.

Undeniably, the built-in support for REST and ODATA API DataSources is one of the sweetest spots with SAP Appgyver.

Good to know:

  • with ODATA APIs Appgyver will likely automatically recognise all entities and populate attributes.
  • with REST APIs each endpoint may need to be implemented as a separate data source
  • there is a built-in HTTP Request function flow that may be used to implement bespoke handling of REST API endpoints
  • fetch API is supported in java script function flows

Please refer to https://docs.appgyver.com/appgyver-academy/core-lessons-complete-guide-to-composer-pro/core-lessons-3-data-and-integrations for further details.

Step1. The Rebricable APIs and CORS policy.

The Swagger documentation of the API is offered in the openapi format here: https://rebrickable.com/api/v3/swagger/?format=openapi

Worth mentioning the rebrickable APIs are already CORS enabled.

Thus you can go directly to step3.

Step2 (optional). myLego API proxy (SAP API Management)

However, even if the API endpoints could be consumed directly in Appgyver, I still opted for using an API proxy instead.

The reason behind that is that I strongly adhere to the paradigm of the separation of duties between an API provider and a consumer app.

Furthermore, I could also handle relatively easily the URL redirect when calling the rebrickable API endpoints from Appgyver.

Here go the implementation steps of myLego API proxy with API Management.

  • Create a new REST API proxy and then import the API swagger definition.
  • Add a security policy with the access key and URL redirect.
  • Deploy and enjoy.

Step3. myLCNCLegoCarousel web application (SAP Appgyver)

The initial motivation behind this app was not that much the challenge but rather our latest family visit to Legoland.

Following the LCNC challenge guidelines, myLCNCLegoCarousel is a web application. And as such, it can be deployed to any HTML5/Fiori host.

At the same time, I made sure it is still compatible with mobile devices (e.g. it can be run on a mobile device via SAP Appgyver Preview app).

Let’s start with the data model.

Then we can have different views (pages with ui components, or custom composite components and even global canvas page without ui controls) and logic flow controllers (function flows) for instance:

a page with ui with some relatively complex controlling flow

inside a component template editor….

inside a global canvas page…

and voila…

A few observations from my personal and professional  experience using SAP Appgyver to develop web applications.

APIs

During my learning journey with Appgyver I came to a conclusion that in many cases I would be better off with implementing API request logic outside of Appgyver.

Towards this end I personally use a lot API Management, including with the non-SAP public, free APIs or otherwise custom APIs, or alternatively rely on kyma/k8s functions as API endpoints as well.

The usage of API Management is not mandatory (albeit is very convenient). What really matters is that APIs endpoints are well defined and this is best achieved through the industry standard openapi specification.

You may have a look at a couple of my blogs where I explain the above approach:

  • HERE Location Services with SAP API Management and Kyma functions | SAP Blogs
  • Astronomy Picture of the Day. With no-code. | SAP Blogs
  • myBank with SAP S/4HANA Cloud, APIM and Appgyver | SAP Blogs

Application changes tracking. Code versioning and sharing.

I have been using Appgyver to create frontend extensions to SAP LOB applications (with the focus on S/4HANA on premise and Cloud). Have been through a few bumps on the road with the runtime regressions etc.

However today my main question is: What would be Appgyver planned approach to application changes tracking?

As of today, after reaching a stable development milestone, I typically need to duplicate my app to continue the development on the app replica, so on so forth. but this is relatively cumbersome.

Also to keep track of changes I need to take screenshots and manually maintain a github repo with the screenshots and their description.

Last but not least, I hope you enjoyed reading this blog.Please provide your feedback in the comments section below.

  • Please always refer to this one pager SAP help page with all the pointers to Appgyver resources
  • SAP Appgyver Roadmap: https://roadmaps.sap.com/board?range=CURRENT-LASTPRODUCT=73554900100800003801#Q1%202022
  • SAP AppGyver Academy: https://docs.appgyver.com/appgyver-academy
  • Troubleshooting FAQ: Troubleshooting — FAQ – AppGyver

Related Posts