This document discusses preparing ABAP code for the cloud. It outlines questions to consider about an application's architecture and code quality, such as whether the code is optimized for SAP HANA and uses reuse tools. It also notes potential issues with legacy ABAP code like difficulty refactoring. The document then covers some differences when working with ABAP in the cloud, such as restricted APIs. It proposes architectural patterns for redesigning applications, such as applying clean code principles and breaking services into a reasonable API. Finally, it states that the biggest challenge is overcoming habitual thinking and knowing-doing gaps when redesigning software.

1. Is your ABAP Code
ready for the Cloud?
Tobias Trapp (AOK Systems)

2. • ABAP Legacy Code
• What Code Qualities do you need?
• A first look at ABAP Cloud Platform
• Antipatterns in ABAP Applications
• Patterns for Redesign
• Rethink your Application Architecture
Agenda

3. Lifting Up a Monolith to the Cloud?

4. Is the code running properly on HANA?
Is it using SAP NetWeaver reuse tools only?
Will it be easy to extract the code to from the
monolith and encapsulate as a Microservice?
Does the application have web interfaces?
How much time will it take to rewrite the UI?
First Questions

5. Will you have to change the code
quite often due to new
requirements?
Can you establish short release
cycles?
Do you have automated tests?
Does implementation of a new
release takes effort?
Central Questions

6. Problems with Legacy ABAP
Legacy applications are mature and contain
many good design patterns. But they can also
have problems:
• refactoring is difficult due to possible side
effects
• no chance to introduce unit tests
• redesign is problematic:
• historical code has not been deleted
• step-wise refinement approach makes it
difficult to isolate and reimplement a module

7. • Whitelisted APIs are a bit different:
• CL_ABAP_UNIT_ASSERT instead of CL_AUNIT_ASSERT
• CL_ABAP_CONV_CODEPAGE instead of CL_ABAP_CODEPAGE
• No SAP GUI
• CALL METHOD is still possible 
• Fiori UIs in Cloud Foundry
• EML is fun 
First Impression of ABAP Cloud
Environment

8. TowardsaNewArchitecture

9. The Pain with Customizing
• increases complexity
• difficult to test with unit tests
• difficult to separate customizing activities since changes are
written on the same transport request
• you will have to create your own customizing maintenance Uis
• no SM30 in the Cloud

10. Why I avoided Dynamic Calls and
used Redefinitions
typical pattern for checks:
• use an interface & call classes
dynamically f.e. from determinations
• two developers can work in parallel
• no code merge necessary especially in
validations in complex business objects
disadvantages:
• no where-used list
• code gets complex
• inflation of global classes

11. From System Tables to Attributes
I used it frequently and found some problems:
• statement sizes are limited (~150kb)
• there is no check for duplicate keys in during develop time:
you define primary keys and run the declaration
• this approach is not very comfortable to use compared to tables

12. What I Learned…
• Apply Clean Code Principles & Test Driven Development
• Get inspiration from Domain Driven Design
• Think „outside-in“: What Services does the application offer
• Break the set of services down to a reasonable API
• Redesign for the Cloud is also a chance for onPremise software
• We need ABAP Programming Patterns that make it easier to
work with branches
• You need a Health Check Infrastructure for your app

13. The Biggest Challenge
Habitual Brain
Knowing-Doing Gap

14. Credit
• Picture Credits to Stefan Kühn under license CC BY-SA 3.0.