If we look at SAP BTP we got a great set of different technologies and possibilities for us as developers to build meaningful and innovative applications, services, intelligent software and much more. For me as a Developer Advocate I was wondering what I could do to make the entry into this broad set of technologies a bit easier for one who might be new to SAP, has worked in only one of these technologies (like myself, when I was solely working on native app technologies) or even veterans within the SAP ecosystem who just want to see what kind of use cases are out there.
For all of you I am creating this blog post series which is a bit more extensive than just “How to deploy XYZ to SAP BTP”. As I am broadening my horizon and skillset within the SAP BTP ecosystem, I wanted you all to be able to follow along my learnings, AHA moments and of course the technical implementation of the use case I am going to introduce you with this Blog Post.
Coming along with a set of Blog Post, each of the posts will have a related SAP Tech Bytes episode following as well. Also the complete project will be available in the SAP Samples organisation on Github for you to collaborate and learn with.
In this introductory blog post I want to first show you where all the learning happens for you.
Bookmark the following links if you haven’t done that already!:
Alright now that we have that out of our way let’s talk about what I am actually trying to show you here 😁
The Developer Advocates Project: Use Case
While I was going through tutorials on the SAP Developer Center learning more about SAP HANA, SAP Cloud Application Programming Model and the SAP BTP, Cloud Foundry runtime my thoughts were going towards a possible use case I could implement to test and try out my newly learned skills.
What I came up with is the Advocates Service.
The Advocates Service is a CAP service being deployed on SAP BTP, Cloud Foundry runtime with a persistence connection to the SAP HANA Cloud. The service itself is holding information about the SAP Developer Advocates with all the information about the advocates being relevant to the SAP Community.
This service allows me to try out my newly learned skills and will open the possibility to implement different types of UI on top of it like an iOS native app, a SAP UI5 application, an AppGyver app or just simply extend the service itself with serverless functions on the SAP BTP, Kyma runtime.
The sample is nice as the code for the service is not overcomplicated but gives a good and real example on implementation scenarios you might face in your daily work:
Having a database with data and delivering that data over different endpoints to some UI or middleware layer.
If you’re interested in the tutorials I was working through you can find the list here:
- Setup Node.js to connect to SAP HANA
- Build a Business Application Using CAP for Node.js
- Combine CAP with SAP HANA Cloud to Create Full-Stack Applications
- Get Started with the SAP HANA Cloud
- Create an SAP HANA Database Instance Using the CLI
The Developer Advocates Project: Architecture
When we look at the architecture this should be pretty straight forward. The service itself is being deployed on the SAP BTP, Cloud Foundry runtime which connects to an SAP HANA Cloud database providing the data. The service itself will expose the data without authentication as the advocates information is public domain and only GET is available as of now.
At the moment there are no profile images available over the service but this will be implement later on via an object store within SAP BTP, Kyma runtime.
As of now two apps are thought for; A native iOS app written in SwiftUI using the SAP BTP SDK for iOS frameworks and an AppGyver app.
The architecture right now is high-level and can change as the project evolves. The architecture diagram will get updated accordingly in the upcoming blog posts.
The CAP service itself exposes the data over OData V4, V2 (OData V2 Adapter Proxy) and REST (CAP REST implementation).
Coming up Next
This was the introductory blog post covering a rough layout and plan for what I am going to build. The upcoming blog post will talk more about on how the implementation would look like of such a scenario.
In the next blog post I will introduce the CAP service itself, its implementation details, handling multiple endpoints as well as the learnings I had while implementing the service.
In the end we want to have the service implemented, deployed and connected to a User Interface for displaying the data.
With that Happy Coding and Stay Healthy!