CAP. The new Web Dynpro Java.

Before the ReCap 2023 event I already had the title of this blog post ready. I was waiting for the event to decide if I will put a ! or ? at the end of the title. Depending on this decision I’d have decided how to write the content and to put the focus on. Either way, there would have been indications that CAP is at a crossroads where its future will be decided.

Considering the 5 stages of grief, in both cases the post would have been somewhere between denial and bargaining. The ! for the case that the decisions taken increase the risk of CAP going to be the next Web Dynpro Java (WDJ). Outlining the hope that maybe SAP is just not aware of the situation, and it is still not too late to take some actions. Actions must be taken by SAP to stop CAP going to share the faith of WDJ. The post could have been a successor to my Licence to kill post. The ? for the case that the event shows that SAP and the community do understand the risks of the current direction and that actions are already taken to ensure that CAP won’t be the next WDJ. But still: the risk is of CAP going down the WDJ path is not eliminated. The future will decide, but not all hope is lost.

In the end, it wasn’t neither ! nor ?. As you can see, I settled with a simple period (.). The decision to go with the . is maybe the most fatal decision. SAP is doing what SAP is doing, and that’s not necessarily the best for a product, developers or customers and users. Yet, that’s how it is. From the 5 stages, I moved directly to the final one: acceptance. No hope, no doubt, no call to action, nothing. CAP is the new Web Dynpro Java.

For those that know what WDJ is, you can now stop reading and come to your own conclusions. If you wonder what WDJ is or why CAP is the new WDJ, please continue reading. For everyone that wants a short overview of WDJ, I wrote a post about the history of WDJ.

Benefits of CAP

Listening to SAP when it comes to CAP features and benefits, some of the points raised are: easy, cheap, flexible, and cloud. All of these are true, no doubt. An additional benefit is that CAP is cool. Its coolness enables to CAP to bring non-SAP developers to the SAP world. Isn’t it perfect for enabling JavaScript developers and bring them to the SAP universe? Isn’t it making life easier as it allows to extend SAP products without having to invest in core SAP (e.g. ABAP or S/4HANA upgrades)? Its home is cloud / SAP BTP. Short: Isn’t CAP simple? Yes and no. Of course, CAP is simple. It offers many features out of the box that other frameworks do not offer, or in the same level of quality. Just because it offers some features out of the box, it does not mean it is simple or the product of choice.

Reality bites

Developing with CAP is to model data. Modelling isn’t easy, it means to understand the business model. This is one of the main SAP developers’ capabilities. Knowing how to code in JavaScript, TypeScript and Node.js or using Express does not implicitly mean to know how to create a model. To understand business data. Some things can be taken e.g. from Spring or JPA, but still: value helps, business relationships, this is not what you can or should expect every developer to know. The annotations you can add to your CDS model are extensive, to say the least. How SAP does work or what are the best practices for modelling in the SAP world: this is SAP specific. Extending OData services, exposing OData (to lesser degree also Graph), Fiori as UI. On top BTP and Cloud Foundry: that’s not the normal technology stack you find outside SAP. Under the hood, there are a lot of things to learn. You need to know how to model an app, how all the syntax works together. Ignoring Fiori might be an option, but one of the beautiful features of CAP is that if you know how things work, you automatically get a web app. With draft. With i18n. No additional coding needed. But modelling, connecting entities, ensuring that authentication works, constraints, and adding custom logic is not easy. Looking at some presentations streamed live at ReCAP, you can see that writing a CAP application is not easy. People that work with CAP day-in, day-out struggle with the details of CAP modelling and programming.

Good news: CAP is moving to open source. But without a plan why. So far, the reason is: because we can. At the panel the discussion was also about open sourcing and database support. You should assume that all of this is done to go to where the developers are. To leave the closed SAP world, to open up. But: these things are done to bring developers to BTP. To take them away from where they are now – non-SAP, Azure, AWS – to SAP and BTP. Why push them to BTP? Why not use what CAP offers to let the developers work where they want? Is someone really thinking that CAP adoption will increase when developers and customers first must learn BTP? Enforce them to learn what SAP thinks cloud is?

Never underestimate the hurdle BTP is. Deploying a CAP works just fine and absolutely without problems. Until it does not. At that point, deleting the whole (sub) account turns into a very valid option. Finding skilled people in the BTP area is a challenge and SAP does not make it easy. If you ever had the fun experience of onboarding to BTP free tier, you know: hell no. The SAP delivered experience is unique. Just be happy that you do not have to use a pigeon to send a fax to SAP. You still must beg to be added at some random time as a BTP customer, not to mention to end the account. The thrill each month when SAP sends you the bill for free tier, because, well, you never know if SAP decided to ignore the free tier part and charge you $$$. Of when they decide to tell you that the 0 $ bill you got months ago isn’t valid any longer and they now want you to pay for the free tier service. Welcome to SAP. BTP free tier is the proof that SAP has absolutely no idea how cloud works, or what the internet is. Actual cloud companies deliver on their promise and offer a great experience. That’s where the target groups of possible CAP developers are, that’s where CAP should be. But no. Focus for CAP is on BTP. Would be interesting to know how many developers that start a new app on AWS or Azure know that CAP exists. And if they knew, would they consider or use it for their project. So far, I’d go for: the CAP developers you find are either already in the SAP world or were already very close to it.

The knowledge about CAP could be higher. That it is not is SAP’s decision. Instead of opening it up, bringing it to the non-SAP world, it is seen as a tool to bring developers to SAP. To bring them on the SAP technology stack. That’s fine. The logic behind this rational makes sense. In case you have a product that is so good that people want to use it, they will come. Just remember that a good product is not all it needs. It must be embedded in an easy to consume way. I am not convinced that SAP is an easy to consume offering. With CAP being deeply embedded in the SAP offering, it is not easy to consume.

Offering support for databases like PostgreSQL or CosmosDB is the right choice, but then CAP needs to be where the (non-SAP) developers are: AWS, Azure, etc. Basically everywhere, just not BTP. However, when you start a new web app project at Azure, CAP is not an option. Microsoft offers quick start guides and runtimes for Node.js and Express. Technologies very well known by CAP. But some hints, documentation, or examples to not just start a Node.js app, but to start a project using CAP? No. But that’s how SAP wants it to be.

From an SAP point of view, all of this makes sense. SAP employees can use CAP on BTP without having to pay for it. They have better (exclusive?), internal access to CAP resources. Adoption of CAP lives at SAP. Several apps are developed and operated there. Easy when you do not have to pay for running them. Which is a problem: as a customer, you must pay to run CAP where SAP wants you to run it: BTP. The BTP runtime, database, domain name, etc. is not for free. Setting up the whole technology stack and knowledge for what? Maybe 2 or 3 CAP apps? While there are valid use cases, be curious. Especially when you have RAP available, be it on premise or in the cloud. With RAP available, and If your architect is promoting CAP, maybe you should get a new architect. The number of SAP solutions sold to customers that depend to a large part on CAP is small. In that regard it is like HANA XS. Hyped, but where is the commitment by SAP? Up to which degree does SAP bind its future and portfolio on CAP? Until then, CAP serves as a great topic at events.

CAP and WDJ

Here we have many aspects that CAP has in common with WDJ.

• It is seen as a way to bring developers to SAP.
• It comes with its very own technology stack.
• The runtime BTP is considered cool.
• It offers many features out of the box.
• It is hyped by SAP.
• It has adoption internally at SAP.
• CAP features are pushed mostly by internal demand.
• For some parts, WDJ was even better positioned as CAP. SAP delivered many WDJ apps to customers.

These points put CAP very close to WDJ when it comes to dealing with it. As WDJ, it is a technology from SAP for SAP. As WDJ, customers are forced to do a high investment into the SAP stack. And just like with WDJ, CAP depends on SAP. So, what happens when tomorrow SAP decides to pull the plug on CAP? For sure, it will stay around for next decade(s). Just like WDJ, you can build your career around a single technology. At the panel held at ReCap 2023, one question was: who here is a JavaScript developer that entered the SAP world via CAP? The response from the audience was indescribable. I think it is safe to say: that developers come to SAP through CAP is at the same level as it is with WDJ. Is the commitment to CAP worth the effort? For SAP, abandoning CAP has the same impact as abandoning WDJ had. Some troubles and headache. Mainly regarding communications and customer relationships. But the SAP core offering is independent of this. The impact of deprecating CAP would be even less a problem than with WDJ.

WDA decided the faith of WDJ. WDA made it so much easier to develop web applications compared to WDJ. Same now with RAP. CAP had a sweet spot when RAP was not widely available, and its features limited. Between 2019 and 2021 CAP had some good chances to take off. But for this to happen, CAP would have been freed from the SAP limitations. Not focusing on internal demand. Not on BTP, not on making it work best with SAP. Better would have been an independent unit, or even company, focused on CAP in general, on non-SAP scenarios. Didn’t happen. As a result, RAP gained more features throughout the years and is now widely available. If a customer has a recent S/4HANA system available: RAP is there. Cloud? It’s there. A remaining vantage of CAP is the costs for running it for side-by-side scenarios. Ignoring additional admin costs, just the runtime costs, it is cheaper than a Steampunk server for one RAP app. The more RAP apps are developed by the ABAP developers, situations changes and the reasons to use CAP are getting less and less. As said above: if you have RAP available, and your architect demands to use CAP, replacing the architect is a valid option.

As RAP development is done in ABAP, just as with WDA, companies can upskill their existing developers to the next generation. A new developer entering SAP can already onboard learning how SAP really works and even with the initial learning effort higher, over the years it will bring an even higher benefit for the company. And to the developer. There is no break in technology. The additional effort of getting CAP and S/4HANA get to work together is eliminated. Without CAP and BTP, this is not just one level of complexity eliminated, it’s a whole technology stack eliminated. The benefits of using RAP over CAP are tremendous for both customers and developers. The sweet spot for CAP in the current SAP world will become smaller and smaller. After 2030, RAP will be available at almost all SAP customers. They will get it out of the box. Without having to install or manage any other technology on top. The will from SAP to change drastically the positioning of CAP is not existing. SAP is happy in having a tool that is used internally, that is driven by internal demand, whose roadmap and future is decided internally. That’s just like with WDJ. Just without the WDJ based apps delivered to customers.

In the year 2030

It is hard to make predictions. Nevertheless, I would be very much surprised if CAP will be widely used as one of the go-to technologies after 2030. The above points and decisions taken by SAP make it appear unrealistic that CAP will have a great and bright future. SAP internal politics can have an unforeseeable impact. What happens when the board and senior management changes? Will CAP survive or the budget be cut and investment stopped? I guess it will fade out, just be an additional alternative to use. Maybe not every SAP customer will have an S/4HANA or Steampunk system, but still wants to use BTP. For that handful of customers CAP will be around. For all other customers it will be ABAP and RAP. As WDA “killed” WDJ, RAP will decide the faith of CAP. Or: already decided its faith?

You wonder why already? One of the sweet spots for CAP is currently to use it as a mock or rapid prototyping tool for Fiori Elements. Creating a basic OData v4 service for a Fiori Elements app is super easy with CAP. And this is done because either the project needs to wait for a S/4HANA system including RAP made available/installed/configured, or wait until the ABAP and RAP developer is available to start coding. The moment SAP releases a super easy to use RAP OData modeler tooling, or modeler to mockdata to RAP service helper that can be used for the FE middleware mockserver, usage of CAP will decrease drastically. When one of the main use cases of a technology is to serve as a placeholder until the real tool can be used, well, that is not a good sign for the placeholder.

Learning and using CAP is not as easy as it should be. The barriers mounted by SAP are high. CAP’s home is BTP and BTP is not as attractive as SAP thinks it is. BTP apps or extension apps is just a tiny fraction of use cases it could serve. Nevertheless, that’s the focus of CAP. It’s focuse is on the SAP world, on internal demand that comes mostly from SAP. The outcome of this defines how it is used in the SAP world; closing the circle. It is exceeding in being a mock tool until the real service is written. For the years to come, it will be a nice tool to use as plan B or C when the task is to write an app in the SAP world. I guess it will end up in the long list of technologies once hyped, still available, little usage, little benefit, just like WDJ, Kapsel SDK, HANA XS/C/A, or from the ancient times: Visual Composer.