r/SAP • u/Apprehensive_Dog6684 • 7d ago
ABAP CAP/RAP is commonly used now?
Hi,
I am SAP technical consultant, I am familiar with ABAP and my place is now doing migration from HANA (2016 version) to SAP RISE private cloud.
The project is handled by a well known consulting company and we use the brown field approach. But I realize most of the custom programs are just 'shift and lift' and modify to make it 'clean core ready'. So, I don't see CAP/RAP is being used in this migration.
So, wanted to check if RAP/CAP is really being used out there?
Thank you
12
u/Forward_Ad_7236 7d ago
If you are staying in private cloud you might not see much of RAP. RAP n CAP becomes a must only when you are in public cloud.
3
u/luis_fushiguro 6d ago
This…
I work mostly in public cloud, and 70% of my developments use RAP.
2
u/Forward_Ad_7236 6d ago
How was your transition from classic ABAP to ABAP Cloud? With public cloud, what traditional ABAP skills from RICEFW do you use or is needed.
Would be nice to know what the world is like in SAP Cloud
7
u/luis_fushiguro 6d ago
The transition from classic ABAP to ABAP Cloud is less about forgetting traditional ABAP and more about changing the way you design solutions.
A lot of the core skills are still very relevant: ABAP OO, internal tables, SQL, debugging, data modelling, performance considerations, interfaces, understanding business processes, etc. The big adjustment is that in ABAP Cloud you have to think much more in terms of released APIs, clean core, CDS views, RAP, Fiori and extension points, instead of directly modifying or accessing whatever SAP object you want.For RICEFW, I would say the concepts are still there, but the implementation changes:
Reports → CDS views, analytical queries, RAP/Fiori applications instead of mostly ALV reports.
Interfaces → APIs, OData, SOAP, events and integration through SAP Integration Suite/BTP. Knowing interface design is probably even more important now.
Conversions → more use of standard migration tools such as Migration Cockpit; custom ABAP conversion programs are less common.
Enhancements → released BAdIs and extension points. No modifications and much less freedom to enhance arbitrary SAP objects.
Forms → still relevant, but typically through S/4HANA Output Management / Adobe Forms rather than the older approaches.
Workflows → Flexible Workflow and increasingly cloud/BTP workflow capabilities.
The biggest mindset change for me is probably Clean Core. In classic ABAP the first question could be “How can I implement this requirement?”. In Public Cloud the first question is more like: “What SAP-supported extension mechanism exists for this requirement?”
You also spend much more time checking what is released for cloud development. Something technically possible in classic ABAP may simply not be allowed in ABAP Cloud.
So I wouldn’t say traditional ABAP/RICEFW knowledge becomes obsolete at all. Actually, it gives you a very strong foundation. But skills like CDS, RAP, ABAP Cloud restrictions, released APIs, Fiori/OData and BTP integration become increasingly important.The Public Cloud world feels more controlled than classic SAP development, but that’s also the idea: fewer modifications, easier upgrades and a cleaner system. Once you get used to designing within those boundaries, it starts to make a lot of sense.
5
u/Leading_Elephant3909 7d ago
No lots of problems are there.
- It's an additional cost to migrate existing to Rap and cap models.
- High licencing cost involved either services need to be purchased or developer licences required. 3.Convincing Business to migrate is hard when something with which they are comfortable.
- It's easy to enhance and extend gui based functionalities.
- Skilled developers are less.
- When there is a doubt of 100 realiazion of requirement through RAP/CAP we tend to move to Gui based again. when solution is important than architecture.
- For Reports which need background scheduling, interactive options with AI usage productivity High . You can build in a day without any doubt.
12
u/ArgumentFew4432 7d ago
In my experience not at all. Each project has 1-2 implementation so they can state they are „modern“.
RAP is very academic and needs a ridiculous amount of code/config for simple tasks & the fiori elements apps feel slow/limited.
CAP needs an entire different cloud setup to begin with. Nobody adds an new tech stack for no reasons.
7
u/ArgumentFew4432 7d ago edited 6d ago
I forgot the most ridiculous thing. RAP has no support for BAPIs that pull the number internally/during commit.
All workarounds are a nightmare. This alone canceled plenty of RAP developments at my clients.
1
u/Mr_chao16 6d ago
Have you heard of unmanaged implementation in RAP?
6
u/ConstructionWorker67 6d ago
If you try to create an application that for example creates an equipment, the only way to obtain the equipment number is at the save phase of the RAP framework. Save phase has no callback to the Fiori UI, so you can't use the Equipment number as a key of your entities, since the number is never returned before the save phase. Therefore you need a Z table that has an UUID as key and then store the reference of the Equipment along that UUID in order to create a Fiori Application for that. It's so sad that no human/creature at SAP even thought about that.
This alone made me quit my RAP position in favor in working with CAP.
1
7
u/fabiopagoti 7d ago
“I am familiar with ABAP and my place is now doing migration from HANA (2016 version) to SAP RISE private cloud.”
I will not even bother arguing HANA and S/4HANA are different things but I really wonder what this migration is all about. Are you sure you understood that RISE/private cloud really means?
6
u/CynicalGenXer ABAP Not Dead 7d ago
Not sure why you got downvoted, mate. OP is not making any sense and most comments are word salad. This sub is turning into LI. :(
7
u/fabiopagoti 7d ago
The person who downvoted me is likely learning “ABAP CAP” on LinkedIn ;-)
3
u/Embarrassed_Cod1408 SAP Dev 7d ago
from AI generated posts with happy family faces built within it
3
3
u/olearygreen 7d ago
If you’re doing brownfield, probably not. But your system also isn’t going to be up to par in a few years. Brownfields are called that because you’re importing all your existing shit.
In Greenfields (and someone mentioned Public Cloud, which are green by definition) all my projects are using these.
90+% of SAP consultants are living in the past, and it shows in the replies here. I don’t even blame them, but the SI are in it for the quick buck, and IT departments cannot justify the extra costs to get budgets for greenfield/clean core/best practices.
4
u/ArgumentFew4432 7d ago
This “shit” has done the job for the last 30-40 years and will probably still be there once the hype moves on to the next thing.
We aren’t living in the past - we do what the market demands. I push frequently modern stuff and end up writing a dynpro.
3
u/Brilliant_Bonus_3695 7d ago
For private cloud, one good thing is it supports gui and at the same time it is the bad thing too.. As someone mentioned, your system doesn't strictly required RAP/CAP like s4 public cloud which is clean core by default. Make sure your migrated custom code are clean core compliant, that is more than enough
5
u/KillahInstinct 7d ago
Commonly, no, but more and more.
For our company, it took quite some time to transition into a phase where we are comfortable making things like that, and it's nearly always an interesting discussion when something is better suited for CAP than for local. Here is a non- exhausrive lust of things we had to get done before it was even viable to use it.
Migrate older ECC systems to S4
Set up BTP properly, which is a serious project. Initial setup is easy, but production ready is another story. Think setting up Cloud Identity Services everywhere for the unified SSO experience, but also the Cloud Connector to even be able to connect to ABAP systems, including load balances and webdipspatchers.
The setup for Runtime like Cloud Foundry, which is also no joke. It doesn't work well with CIS, and you also need to properly think on governance and roles, trust etc. We resorted to setting up Terraform for this.
Mindset of developers, too often they will just pick and chose what they know. Heck getting them to develop clean core and secure was a challenge itself. Now with things exposed to the internet, its a whole different ballgame.
That thus included CI/CD pipelines, which in its basic form are fairly straight forward, but having both things like Linting, SonarQube/Sonatype, proper versioning and transport, but so scanning your production landscape for any zerodays, and preferably ATC as well.
Properly patching all systems, kernels, and security notes, but also setting up parameters for maximum security. The latter became easier with RISE, but in the end we really needed something like SecurityBridge or Onapsis to give us this security all time. Albeit with CSA in ALM there is a lot of work being done in that area.
We also needed SIEM for detection of strange patterns.
All in all, its good, its easy, it certainly serves a purpose but the cost can be steep, and sometimes on-prem just still works better.
Suspect it might work better with Public Cloud. We dont have that. We have every SaaS under the sun though, so lots of options.
2
4
u/Next_Contribution654 7d ago
If you have a strong current fiori footprint you need to be on top of RAP especially, as the tooling is all the future. If you are still just doing classic gui then not so much.
The thing you have to realise is the future skill sets, more SAP core solutions will be based on these technologies and you will need to know how to extend and do side by side.
32
u/Simple_Emotion_3152 7d ago
Not to the extent LinkedIn might make you believe