Akos Szalay

I would never do a CAP project without TypeScript, it’s a nightmare. Although I’m a fan of TypeScript, use it for UI5 as well since it’s been available. Never understood the negativity about it. I think it’s also easier for ABAP devs to get their head around it if things are typed.

Seems reasonable and it still holds that multiplying zero is still zero

That’s also true. But lately most of my consumption of these articles has been through AI, so I was wondering if that’s the case for others. But a lot of it (and LinkedIn) feels AI generated.

Does it have to do with people just using AI to scan the posts instead of reading them as well?

As a developer, I fully support this. Make AI do the boilerplate stuff.

It's more of an argument to use good practices to avoid nasty surprises in the future - and clean up existing messes. Not all innovation is good though - the Zeppelin was very innovative for example, but didn't turn out so good.

And not only will it be hard to migrate, but also more and more expensive to maintain, as the skills will be rarer (COBOL?). ABAP developers are already the oldest of any developers on average, so legacy ABAP skills will be hard to come by in a relatively short time

I'm not defending SAP here - their messaging is often confusing and changes too frequently. I remember when Floorplan Manager was going to be the future. As for a functioning codebase, sure, but technical debt should be periodically addressed, otherwise the code will be difficult to maintain

You should be able to easily create a RAP wrapper around your legacy functions containing your business logic. The only time when that's not possible is where the logic was not properly separated from other stuff. Which is where remediation is needed. That's the tech debt I'm talking about

The only issue I have with RAP is how verbose it is, and how many objects are required to create a service, compared to CAP. But as far as ABAP goes, they've done a good job. The issue comes when integrating with incorrectly created legacy objects (like some BAPIs).

I think companies often make a mistake of focusing solely on SAP messaging when evaluating new technologies, without evaluating the merit of the technologies themselves. If you look at the actual technology, you can see that RAP is actually good, whereas BOPF was not.

You're right, I was focused on BOPF as it was used for Fiori apps. It was indeed an earlier technology, which they've cobbled together with CDS to make something like RAP, but very difficult to use.

then it's not legacy code, it's technical debt. Which should be removed because it creates a maintenance liability, and higher maintenance costs (and maintenance is 85% of software cost).

As in: if your business logic is not entangled with data read/write and UI presentation logic, it can easily be dropped into a RAP app with minimal effort. If your developers followed best practices regarding LUW and SOC which haven't changed in 30 years, it should be fine. If they haven't, well...

BOPF is based on CDS. But it was a sticking plaster approach which was excessively difficult to work with. RAP applies the same principles but built into the language so it’s easier to work with. The end result in both cases is odata. Neither work well with (bad) old code.

They are a liability. SAP’s relative inability to work well with the wider world has long been a pain point for every organisation and developer. From a cost perspective the requirement for very specialised developers is certainly a liability.

Well-written code from 30 years ago is still easily reusable within RAP. It’s only incorrectly written code that’s not reusable. It’s all well and good to be compatible but it shouldn’t hamstring modern devs, which it’s currently doing

I’d argue that those things were only necessary because better technology was not available. Also consider that oData has been available in SAP for about 10 years. So you could rebuild your backend with RAP without touching your UI if your odata endpoint doesn’t change

Perhaps this is also an opportunity to remove some custom development and instead take advantage of new standard features.

SAP has so far maintained extreme backwards compatibility, which is not at all common. Software in general requires constant investment to maintain and upgrade to meet new standards. It should also be reviewed periodically whether it’s necessary at all.

I’d say those things were technical debt the moment they were created. If they are difficult to migrate to RAP, they were initially not written the correct way (and this includes much of SAP standard). I understand the frustration, but this is part of software development.

Still it has to be done. It’s nothing but technical debt

This… is terrible. Please let us move away from legacy and embrace the 21st century

Because RAP is actually good unlike those other things? Once you get used to it it actually becomes way easier to work with than traditional ABAP. Personally I feel like anything that delays the full transition to RAP is a net negative in the long term.

Cat: You don't understand, you must let me out into the world, I yearn to be free and unfettered by domesticity

Same cat five minutes later: WHY DID YOU BANISH ME TO THE FROZEN REALMS OF THE OUTER WORLD THERE IS NOTHING BUT A WASTELAND THERE HOW DARE YOU SIR

Is it a question of capability or will?

Finally 🎉

BE FREE, PEOPLE

This is also true, however I think too much choice is just as bad as too little, as it makes everything fragmented and can be overwhelming. It becomes daunting for new devs and raises the barrier to entry. It also makes skills less transferable as everyone is using something different