Technology Blogs by SAP
Learn how to extend and personalize SAP applications. Follow the SAP technology blog for insights into SAP BTP, ABAP, SAP Analytics Cloud, SAP HANA, and more.
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: 

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

quovadis
Product and Topic Expert
Product and Topic Expert
‎05-18-2022 1:03 PM




































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.







Pre-requisites:

Disclaimer:

  • The ideas presented in this blog are personal insights thus not necessarily endorsed by SAP.

  • I have no affiliation with any of the non-SAP brand names quoted in this brief.



  • Please note all the code snippets and gists are provided “as is”.

  • Images/data in this blog post is from SAP internal sandbox, sample data, or demo systems. Any resemblance to real data is purely coincidental.

  • Access to some online resources referenced in this blog may be subject to a contractual relationship with SAP and a S-user login may be required. Always refer to T&C.

Before we start...


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-... for further details.

Putting it all together. myLCNCLegoCarousel.


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.
















Base definition Get Collection Get a single record

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...





Personal insights


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:

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.


Conclusion.


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

 



Additional resources




Labels:
2 Comments
Labels in this area
Popular Blog Posts