Skip to Content

In this post, I think about the new SAP Cloud Platform ABAP Environment, what it is, what it isn’t, and why I think it’s a great move.

A day or two ago this tweet appeared in my timeline, and it made me smile:

 

Last week, Harald Kuck announced the availability of the SAP Cloud Platform ABAP Environment, and it was followed up a day later by a second post from Karl Kessler: “SAP Cloud Platform ABAP Environment is live“. While it was rather a big event, it wasn’t that it came as a surprise – this is something that many of us have been looking forward to for a long time now. Nevertheless, it certainly provides me with lots to wonder about, which is a good thing.

I’d encourage you to read both Harald’s and Karl’s posts as they provide lots of information about the environment in general, and if you’re on Twitter, Jens Weiler is posting a series of tweets with the hashtag #ABAPPaaS, which are definitely worth keeping an eye on.

 

What ABAP has been

ABAP has been with us for a long time. When I think about what that exactly means, it turns out that it’s hard for me to be precise. On the one hand, ABAP is a language, a language that’s evolved over the years since its inception in the late 1980s (I remember writing early ABAP report constructs inside SYSIN DD statements in Job Control Language on a mainframe within an SAP R/2 installation back then).

But ABAP has meant more than that – at least perhaps subtly or implicitly. Arguably, to be an ABAP programmer has meant to build transactions and reports, from both a backend & frontend perspective, in an environment that is both design time & runtime. It has meant using editor tools & software logistics facilities that themselves are written in ABAP and also run within that same environment. Perhaps more significantly, when thinking about the new SAP Cloud Platform ABAP Environment, it has also largely implied SAP-specific user access mechanisms – SAPGUI of course, but also, latterly, the browser, with Web Dynpro ABAP constructions (although even here the main “mass” of UI execution remained within the ABAP stack itself).

 

Image result for yin yang

The yin and yang of backend and frontend

The advent of SAP Fiori and the outside-in programming approach where we now build our user interfaces not only with open standards but also to run outside the traditional ABAP environment – in the browser directly using toolkits like UI5 – heralded a new era.

Not only that, it introduced us, out of necessity, to new ways of working, to distributed source code control systems, to new editors, to the concept of deployment pipelines, and more besides. In parallel, we were seeing the rise in popularity of a new kind of editor environment for writing ABAP itself – the ABAP Development Tools (ADT) within the Eclipse editor framework*.

*a part of me still looks back with fondness at the Roscoe-style ABAP editor available via R/2 transaction TM38; but that’s perhaps a story for another time.

The pragmatic approach to building Fiori apps is to use the UI5 toolkit to build the frontend components, which in turn consume backend components written on the ABAP stack (or natively in HANA) and exposed through a wire protocol, where the wire is HTTP shaped and the protocol is often (though not always) OData flavoured.

So for the past few years, there’s been a lovely yin/yang balance between backend and frontend, both equally important and each complementary to the other.

 

The cloud, and extending SaaS solutions

Enter, stage left, software solutions such as SuccessFactors, S/4HANA Cloud, and more. What stage? Well, SAP Cloud Platform, of course. And what do businesses need in this new age of cloud solutions? The ability to extend, to bend and shape these cloud solutions to their own needs – while, crucially, not getting themselves into a situation where software upgrades cannot happen. So we come to in-app extensions which are purely within the confines of the SaaS solutions themselves, but also — and more significantly — to side-by-side extensions where new frontends and even new backends are required, melding standard functionality with custom features to provide business-specific solutions.

For these side-by-side extensions, we’re going to need a backend runtime and persistence layer. Somewhere to write our application logic, or our custom OData service, some place to run code that connects into the SaaS solutions via the connectivity fabric of SAP Cloud Platform using well-defined APIs. A place to call home, in other words.

Of course, in the SAP Cloud Platform context, we already have places to call home – look, for example, at the excellent Application Programming Model for SAP Cloud Platform that provides us with language and persistence layer agnostic support for building the core data and services that are needed. That’s for the Cloud Foundry environment.

 

ABAP in the cloud

But one thing that I’ve learnt about cloud in general, and SAP Cloud Platform in particular, is that it’s about choice. Yes, there are opinionated approaches to building stuff, but choice plays a big part, and for good reason. The combination of problem domains, existing software solution contexts, team availability, technology trajectory, skillset availability and a number of other factors means that there’s never a one-size-fits-all solution.

This leads me to think about the fact that there are different environments on SAP Cloud Platform, all with solid purposes. The two main environments that come to mind of course are Neo and Cloud Foundry. But last week’s announcement means now that we have another environment to add to the choice – ABAP.

In the context of backend and frontend, in the context of extending existing SaaS solutions, and building net new apps, the SAP Cloud Platform ABAP Environment is one which is appealing to organisations as well as individuals who have a significant skills investment in ABAP, and to whom it makes sense especially to build their future, which may still be hybrid (keeping some on-prem ABAP stack systems to look after core processes), using a homogenised language skills layer.

 

icon of product

 

But as the saying goes, it’s not your grandfather’s ABAP. That much is clear, and for good reason. It’s a chance to modernise the language by removing defunct constructs. It’s a move away from that blurred combination of design time tools, language and, frankly, proprietary UI technologies. It’s focused on building backend solutions, from complex custom application logic that’s either standalone or working in conjunction with services available via SaaS Software Development Kits (SDKs) such as the S/4HANA Cloud SDK, to simple OData services that can be consumed elsewhere.

I’m not just talking about OData, of course. As I mentioned in a previous Monday morning thoughts post on milestones, the Internet Communication Manager, and its user-space layer in the form of the Internet Communication Framework (ICF), is a thing of beauty, and allows us, as masters of the ABAP stack (on-prem as well as in this new cloud-based environment), to build all sorts of HTTP-based services.

What’s more, these days we have Core Data Services (CDS) on the ABAP stack to allow us to declaratively build data models and annotate them for consumption (think metadata extensions and use thereof by Fiori elements mechanisms) and the whole RESTful ABAP programming model to support us here too.

So with the new ABAP in the cloud, don’t think in the traditional mindset about ABAP List Viewer (ALV) based reports, or even any sort of dynpro based solution. Don’t think about your users connecting to your cloud-based ABAP systems with SAPGUI. You won’t even be connecting yourself with SAPGUI – you’ll be using the ADT with Eclipse, and, gosh, eschewing the venerable SE11 for declarative, code-based data definitions! Moreover, you’ll be using modern tools (think abapGit and more) for your all your software logistics needs. Think backend services, think extending cloud solutions, think future.

 

Wrapping up

These thoughts here are based on wonder, and there’s still lots to wonder about (so don’t fret, Mr Waits). It’s early days for the SAP Cloud Platform ABAP environment, and the journey ahead is one that we should travel together. There are still areas that need ironing out, for sure, but I for one am looking forward to taking my first steps.

 

This post was brought to you by Pact Coffee’s Planalto, and the stiffness of joints that are a result of a classic fall on my run yesterday.

 

Read more posts in this series here: Monday morning thoughts.

 

To report this post you need to login first.

10 Comments

You must be Logged on to comment or reply to a post.

  1. Paul Tomlinson

    The part that really comes out for me is:

    So with the new ABAP in the cloud, don’t think in the traditional mindset about ABAP List Viewer (ALV) based reports, or even any sort of dynpro based solution”.

    As a developer now it is key that you think of the backend as an API source, using backend ABAP to offer up services as API’s.

    Extending that further, all SAP systems, whether on-premise or in the cloud, need to be seen as an API source.

     

     

    Paul

    (2) 
    1. DJ Adams Post author

      Thanks for the comment, Paul, and yes, spot on. A key purpose in the life of the SAP Cloud Platform ABAP Environment is to enable the creation and serving of APIs, APIs that then become part of the cloud-based solutions that we’re building out.

      (0) 
  2. Martin Fischer

    Hi DJ,

    very good blog post again and as always food for thoughts!

     

    Despite the question if ABAP on SCP will be a commercial success for SAP, there are two aspects why I think it’s a good move:

    • there are no excuses anymore for ABAP developers to not care about PaaS development and the architectural constraints it brings with it. Furthermore on SCP only modern ABAP will work. So finally for all ABAP developers to start learning!
    • it’s a driver of innovation for the ABAP language and run time. Hopefully the innovations will also make their way back to the on prem world, at least some of them!

     

    (1) 
    1. DJ Adams Post author

      Totally agree, Martin (and thanks for the comment). Yes, as Graham Robinson mentioned in his classic post from 2012 “A Call to Arms for ABAP Developers“, which even today surfaced in a discussion on Twitter, an ABAP developer’s [learning] work is never done, and the advent of ABAP in the cloud, with a true focus on what’s good (and a discarding of what was not so good) is a perfect opportunity and catalyst for a new concerted education effort (modulo trial access, of course!).

      I’m also excited to see the innovations being driven by this initiative; what’s more, the icing on the cake would be to see those innovations arrive in trial ABAP stacks for private consumption at some stage (I’m prompted to write this based on a brief conversation earlier today with Matt Harding on this) … this would be ideally with some access to that connectivity fabric, perhaps via the next version of the SAP Cloud Connector?

      Going to brew another coffee to think about that some more 🙂

      (1) 
  3. Nabheet Madan

    Thanks DJ Adams sir as always for the great post, I started my career in ABAP(Once an ABAPer always an ABAPer🙂) and when i learnt how this web world work, i was astonished. All of sudden you have server side language and client side languages. They were all new to me as primarily for ABAPer’s it was always both, I could make frontend as well as backend by pure ABAP only.

    So that is where I actually got interested in Open source, client/server side etc. With the coming of SAPUI5, it was thinking that ABAP will sooner or later settle for being the server side after all these years of being able to serve both client as well as server side.

    Now with the kind of features being available in initial version of ABAP in cloud, it quite clear that it will now be the server side, where quickly you can get your data exposed via Odata etc.

    Am i right in saying this.. looks like ABAP -> Server side like PHP etc.

    Nabheet

    (1) 
    1. DJ Adams Post author

      Hi Nabheet, thanks for your thoughts. Indeed, once an ABAPer, always an ABAPer. There are certain languages that seem to stay with you, get under your skin, and never leave. The same is true for me with ABAP too, and I think I can say the same thing about Perl. I still think in Perl, sometimes, or at least in the data structures that Perl opened my eyes to.

      Calling ABAP server side? Sure, I think that works.

      (0) 
  4. Jakob Marius Kjær

    It sure is an interesting time we live in. One small comment on your blog, I might have mistaken you, but you mention the abap environment is a third environment next to neo and CF. I read Karl Kesslers blog as the abap environment lived in the CF stack.

    It leaves an exciting thought stream in my mind on how development projects will be in the future. I’m thinking all service development happening in the cloud and the connectivity and interaction with the backend is happening via rfc and cds views. So both the actual odata and ui5 development will now happen on the cloud. It will be exciting to see how customers will adopt this. Not sure what they will say about the pricing especially if you need multiple tiers. But I’m all in for the idea. “keep the core clean!”

    (2) 
    1. DJ Adams Post author

      Keep the core clean, indeed! Thanks Jakob for your thoughts. Interesting that you pick up on the environment count. Whenever I’ve looked at diagrams, ABAP has been a third box, rather than beneath CF, but that could easily have been my misinterpretation. It’s hard anyway to be precise about what an “environment” is, anyway – and my brain, at least, thinks as ABAP as a 3rd environment only really for convenience reasons – a separate deployment and runtime target.

      Like you, I’m looking forward to the prospect of a cleaner core with a nicely defined role and context for service development. Cheers!

      (1) 
  5. Dominik Ritter

    Good morning,

    One question if I may: just starting to look around in the new world of development trying to understand where and how to begin that journey.

    As a traditional SAP In-house Consultant who started working in SAP ECC, then going to SAP SCM (APO and SNC) and now working again mainly in ECC that journey can be tough. We do not have the dedicated developer role, furthermore, it is a mixed role of all the module stuff combined with ABAP developments (Z-reports, enhancements with BAdIs and user exits and so on).

    Recently we signed on to that fancy “new” SAP Cloud Platform. Out of curiosity, I raised the hand because I need a user in that brave new world.

    The last days I thought “oh look, there is ABAP in SCP” reading all that announcements. After logging on to the SAP Cloud Platform cockpit I expected to find somewhere something related to that ABAP announcement. I was hoping to do a “Hello World” in SCP.

    But if I understood correctly we need a whole new “platform” or subscription? Am I right?

    We have:

    Environment:
    Neo
    Provider:
    SAP
    Europe (Rot)
    Description:
    Development Platform
     
     

     

    (1) 
    1. DJ Adams Post author

      Hey Dominik – nice one. “Raising your hand”, as you say, is the first step, and a good one!

      You don’t need a whole new platform, but access is dependent on your subscription. I’m not an expert in this area, but if the (global) account you have is a productive one (rather than a trial), then at this time the best thing to do is to talk with your AE – the ABAP environment is available via subscription or CPEA agreement and will show up in a subaccount that has the corresponding ABAP quota assigned.

      That said, while there’s no open trial at the moment, the team is looking at developer-friendly ways to get access. Watch this space and good luck with your journey!

       

      (0) 

Leave a Reply