A new year is coming and so much did change in 2021 for me and for SAP Consultants & Developers like me. I had the chance to evolve and learn so many new things, technologies and discover new areas. Beside that, my passion to share knowledge and discuss with SAP Community members did grow and that’s the reason I wanna share today some insights of 2021 and how I did use and interact with rapidly changing SAP Cloud technologies and point you into the direction of some of my focused topics from 2021.
Some years back henning.heitkoetter did ask for beta-testers and feedback for the SAP Cloud SDK and I was one of the participants. Honestly, I was completely lost with the topic, technology, typescript and all around it. So I dropped the beta-test part and got rid of the topic. End of 2019 I started deep-diving into the world of nodeJs and by the end of 2020 I got in touch with typescript. From this point of view the SAP Cloud SDK wasn’t that much away anymore and I got back in touch with it. And I have to say ...
I love it!
It’s easy to adopt, very well documented and it provides a big bunch of functions out-of-the-box. It addresses a big range of use-cases and is flexible too. It’s exactly that kind of framework you’ll love more and more as you go.
I remember these times starting with nodeJs apps and setting up routines to grab ‘destination details’ and ‘bearer tokens’ to be able to realize an oData call later within something around 7 query parameters 😉 But it was the right path to start exactly this way. First the ‘greenfield-way’ and then the ‘framework-way’ - so I do understand what’s happening behind the SDK-Curtain.
I used the SAP Cloud SDK to extract data from oData endpoints from S/4 Cloud default-endpoints, pre-packed oData Virtual Data Model (VDM) from api.sap.com and in another project from R3 system where we had to generate the VDM on our own first. So these VDM services are dependencies from a nodeJs app. Example:
In both cases the SDK was the right choice to keep it as simple as possible and within typescript support you have a type-safety environment in your IDE and you can easily identify existing properties and functions from the VDM.
Get more details about the SDK here
The SAP Cloud Application Programming Model (CAP) is a great framework within a lot of libraries and out-of-the-box features like the SDK too. It’s great with best practices and it focuses on Core Data Services (CDS) and SDK features. But it’s not the tool of choice for everything like it’s getting advised sometimes.
Pure UI5 / FIORI apps do not require a CAP app as wrapper around. The SAP Approuter in a Cloud-Foundry container or the “HTML5 Application Repository Service” to run your UI5 app ‘serverless’ do exist and could be a better solution instead of a CAP app. Check out more here.
A short and easy microservice, to fetch the state of a business partner on S/4 and based on this state, start a workflow or send a notification - the SAP Cloud SDK within the business partner VDM (and maybe the workflow VDM) will be easier and faster for your target. I used ‘serverless’ FaaS for that - checkout the review here and the new way to deal with it here.
So like often in our life as human beings (and developer beings) - it depends on the use cases.
SAP is bringing so many different solutions and approaches to us as Customers / Consultants, it’s tough to differ between the solutions and efforts you’ve to spend. But it makes fun to discover every solution - if you have the time and energy for it - go for it!
Yes, it is true. XSUAA, UAA, oAuth v2, SAML, JWT ... all these buzzwords and relying topics are not that easy like they are getting propagated. That’s really something I have to take a lot of energy and time to consult and set up authority topics within customers. And as it is one of the topics you should start with meanwhile setting up the BTP, it’s often already ‘done’ if I am joining the project. So this topic requires a lot of hand-holding. Some blog posts I recommend for this topic are:
Demystifying XSUAA in SAP Cloud Foundry and Demystifying Approuter, XSUAA and IDP in BTP CF Environment. Both provide a good deep-dive into these topics and some required background-knowledge.
With armin.hatting I worked together in a project where he did use a XSUAA as JWT provider within API Management by setting proxies up with SAML Assertions. This approach gives you the capabilities to use an JWT token to authorize against CDS endpoints from a CAP app. A very clever approach to provide you the ability to use scopes to protect your CAP endpoints within API Management acting as central men-in-the-middle. Continue reading here.
I like VS Code and working locally (not with the BAS) and I know everyone has his own favorite. That’s fine because SAP is supporting all of it and at the end it does not depend on some IDE to get your work done. But as soon as the Cloud Connector is coming into the picture and you’re not in some kind of VPN and you do not have access to systems behind the Cloud Connector, you’ll have to use BAS to get the routing done for your OR you’re going to use ‘cf ssh’ within your CF-CLI. I really love this approach. It’s just 1 statement I need to fire and here I am having the Cloud Connector routes available within a glance. Nice! I will not miss it anymore - the time of mocking routes to backend-systems via APIM is done 🙂
Continue reading by checking out the documentation here and here for “debugging-online”
I am on my way to tick all checkboxes from tobias_steckenborn mind-map about how to become the perfect cloud developer - but it’s tough! The rapidly changing cloud world does require more free time as you’ll have.
So it’s time to focus on specific areas, technologies and use-cases ... Do you already have a plan for what to focus-on in 2022? Let the community (and me) know and share your plan and insights 🙂
My highlight in 2021: The SAP Cloud SDK
Some years back henning.heitkoetter did ask for beta-testers and feedback for the SAP Cloud SDK and I was one of the participants. Honestly, I was completely lost with the topic, technology, typescript and all around it. So I dropped the beta-test part and got rid of the topic. End of 2019 I started deep-diving into the world of nodeJs and by the end of 2020 I got in touch with typescript. From this point of view the SAP Cloud SDK wasn’t that much away anymore and I got back in touch with it. And I have to say ...
I love it!
It’s easy to adopt, very well documented and it provides a big bunch of functions out-of-the-box. It addresses a big range of use-cases and is flexible too. It’s exactly that kind of framework you’ll love more and more as you go.
I remember these times starting with nodeJs apps and setting up routines to grab ‘destination details’ and ‘bearer tokens’ to be able to realize an oData call later within something around 7 query parameters 😉 But it was the right path to start exactly this way. First the ‘greenfield-way’ and then the ‘framework-way’ - so I do understand what’s happening behind the SDK-Curtain.
I used the SAP Cloud SDK to extract data from oData endpoints from S/4 Cloud default-endpoints, pre-packed oData Virtual Data Model (VDM) from api.sap.com and in another project from R3 system where we had to generate the VDM on our own first. So these VDM services are dependencies from a nodeJs app. Example:
In both cases the SDK was the right choice to keep it as simple as possible and within typescript support you have a type-safety environment in your IDE and you can easily identify existing properties and functions from the VDM.
Get more details about the SDK here
CAP isn’t the solution for everything
The SAP Cloud Application Programming Model (CAP) is a great framework within a lot of libraries and out-of-the-box features like the SDK too. It’s great with best practices and it focuses on Core Data Services (CDS) and SDK features. But it’s not the tool of choice for everything like it’s getting advised sometimes.
Pure UI5 / FIORI apps do not require a CAP app as wrapper around. The SAP Approuter in a Cloud-Foundry container or the “HTML5 Application Repository Service” to run your UI5 app ‘serverless’ do exist and could be a better solution instead of a CAP app. Check out more here.
A short and easy microservice, to fetch the state of a business partner on S/4 and based on this state, start a workflow or send a notification - the SAP Cloud SDK within the business partner VDM (and maybe the workflow VDM) will be easier and faster for your target. I used ‘serverless’ FaaS for that - checkout the review here and the new way to deal with it here.
So like often in our life as human beings (and developer beings) - it depends on the use cases.
SAP is bringing so many different solutions and approaches to us as Customers / Consultants, it’s tough to differ between the solutions and efforts you’ve to spend. But it makes fun to discover every solution - if you have the time and energy for it - go for it!
The complexity of XSUAA + UAA
Yes, it is true. XSUAA, UAA, oAuth v2, SAML, JWT ... all these buzzwords and relying topics are not that easy like they are getting propagated. That’s really something I have to take a lot of energy and time to consult and set up authority topics within customers. And as it is one of the topics you should start with meanwhile setting up the BTP, it’s often already ‘done’ if I am joining the project. So this topic requires a lot of hand-holding. Some blog posts I recommend for this topic are:
Demystifying XSUAA in SAP Cloud Foundry and Demystifying Approuter, XSUAA and IDP in BTP CF Environment. Both provide a good deep-dive into these topics and some required background-knowledge.
APIM with XSUAA via SAML
With armin.hatting I worked together in a project where he did use a XSUAA as JWT provider within API Management by setting proxies up with SAML Assertions. This approach gives you the capabilities to use an JWT token to authorize against CDS endpoints from a CAP app. A very clever approach to provide you the ability to use scopes to protect your CAP endpoints within API Management acting as central men-in-the-middle. Continue reading here.
Local development and SSH
I like VS Code and working locally (not with the BAS) and I know everyone has his own favorite. That’s fine because SAP is supporting all of it and at the end it does not depend on some IDE to get your work done. But as soon as the Cloud Connector is coming into the picture and you’re not in some kind of VPN and you do not have access to systems behind the Cloud Connector, you’ll have to use BAS to get the routing done for your OR you’re going to use ‘cf ssh’ within your CF-CLI. I really love this approach. It’s just 1 statement I need to fire and here I am having the Cloud Connector routes available within a glance. Nice! I will not miss it anymore - the time of mocking routes to backend-systems via APIM is done 🙂
Continue reading by checking out the documentation here and here for “debugging-online”
Upcoming next
I am on my way to tick all checkboxes from tobias_steckenborn mind-map about how to become the perfect cloud developer - but it’s tough! The rapidly changing cloud world does require more free time as you’ll have.
So it’s time to focus on specific areas, technologies and use-cases ... Do you already have a plan for what to focus-on in 2022? Let the community (and me) know and share your plan and insights 🙂
- SAP Managed Tags:
1 Comment
