Building blocks of modern ABAP development
Coming from a more traditional software engineering background, the world of (on premise) ABAP development can seem incredibly archaic with best practices that have been made obsolete years or even decades ago in the industry. While SAP is actively working on bringing ABAP development into the 21st century, the adoption of these newer tools remains relatively low.
This blog tries to give some pointers on the practices required for a modern ABAP development environment and deployment pipeline.
Eclipse
SAP has made it very clear that the main IDE for ABAP development is now Eclipse and that they have stopped investing in SE80 and the ABAP Workbench.
In general, more features are being added to Eclipse (better code completion, better refactoring support, etc.) and there are things simply not available in the SAP GUI, for example the ability to work with CDS views or the new ABAP RESTful Programming Model.
Another advantage of Eclipse is that it supports UI5 development as well along with the ABAP features, so both frontend and backend development is accessible from the same IDE.
Getting used to Eclipse takes a little bit of time after years spent with the ABAP Workbench but it’s relatively quick to get comfortable with and the extra tools and features can significantly improve developer productivity.
Automated unit tests
While ABAP Unit has been around for about 15 years, it gained very little traction initially. To be fair to ABAP developers though, the tooling wasn’t very good in the beginning – an xUnit implementation without the appropriate easy-to-use mocking libraries is of limited use after all.
But SAP has improved the toolset significantly in the past few years by adding the ABAP Test Double Framework for mocking class interfaces and the CDS and Open SQL Test Double Frameworks more recently for mocking CDS views and database artifacts. While there is still room for improvement here and these frameworks are not as powerful as their counterparts in other languages, the difference is night and day and writing unit tests has become a lot easier with increased productivity.
Learning to write unit tests properly and adopting Test Driven Development (TDD) requires a cultural shift and has a learning curve but it results in increased software quality and pays dividends in the long run.
Automated static code checks
A lot of programming errors can be caught early by static code checks which are often utilized in continuous integration scenarios. For ABAP, the most frequently used tools to achieve this are the Code Inspector and the ABAP Test Cockpit.
It is recommended to set up both with customized variants and rules and make them run automatically so that developers and reviewers are notified about errors and warning as early as possible.
Automated change control and deployment
One of the big pain points in ABAP development is the transport system. While the rest of the software world moved to distributed version control systems like Git and Mercurial a long time ago, ABAP changes are still based on transports (for now, see the next point), are inherently centralized and are based on object locking. This can seriously hinder productivity, slow down development and makes it very hard to manage changes in a safe manner.
For this reason, extra tools are essential to ensure safe and correct deployment of changes between environments with automated conflict checks, resembling CI/CD pipelines. The age of manual deployments through STMS based on Excel sheets are definitely over.
The future: ABAPGit
This is probably the most speculative point in this article but worth mentioning as there are signs that it will be very relevant in the future. ABAPGit is now officially endorsed by SAP and can manage ABAP development objects in Git repositories and deploy them into a NetWeaver backend.
While originally ABAPGit was created to enable code sharing for open source ABAP projects, in theory it is perfectly possible to set up a Git based ABAP development workflow for on premise development too.
In this scenario, all ABAP development objects would be tracked by a Git repository. Each ABAP developer would have their individual development system (possibly containerized with Docker) and they would be doing development on their own local working copies.
Best practices are yet to emerge in this area, but the possibilities are endless. Clearly there is big potential in adopting a distributed version control model for ABAP development and it would undoubtedly result in a huge productivity boost.
One step at a time
Of course, trying to adopt too many changes at once can be challenging and could even result in a disaster if the members of the team are not fully on board, hence a more gradual approach is recommended.
If you don’t currently use any of the tools and techniques mentioned in the article, starting with automated code checks and slowly moving towards automated deployment is probably a good first step as these don’t require a lot of initial investment and/or cultural adjustments and are very easily shown to be beneficial.
Recent moves by SAP definitely suggest that ABAP is here to stay. Its ecosystem is now evolving rapidly so building a development team culture where new tools and recommendations are constantly researched and evaluated is more important than ever.
Putting the Dev in DevOps
Although the DevOps automation tools we create at Basis Technologies aren’t only for developers, there plenty of benefit to be gained from their adoption (Dev being a big part of DevOps, after all). For example, they allow you to automatically check conflicts and dependencies, and call tools like Code Inspector to validate your code, before releasing to QA. Our testing tool even gives you the means to ‘shift testing left’ and run regular regression tests on new code without worrying about scripts, test data management, external interfaces and all the things that would normally stop you. If you’d like to know more about how our customers use our tools to streamline SAP development, request a demo here.
