ABAP Unit - Software architecture

Table of contents

• Requirements
• Architecture
• Data
• Conclusion

In this arcticle we want to describe the architecture of the future as it currently looks from our point of view. There are a few points to consider when thinking about what applications and software in the SAP environment should look like in the next few years.

 

Requirements

So what points need to be considered for the future? One should take a look at the current and past techniques that are used.

• Report design (classic and object-oriented)
• Design of applications (MVC pattern)
• Application testability
• API design with OData Services
• Reusability of accesses (DAOs)
• Clean Code

 

In contrast to the classic applications, in recent years more and more techniques have been adopted from common software development and should also be used in ABAP development.

 

Architecture

Now that you've learned a lot about the design of testable applications in this book and the advantages of global classes in testing, the architecture will be a little clearer and easier to understand.

 

Basically, the global class is the focus of the architecture here. All components that are developed are designed for reuse in order to build on central aspects of Clean Code and its principles. All other components in the hierarchy, such as reports, RFC function modules or OData services, only serve as envelopes for calling the class. The logic is thus encapsulated on a global level and can be reused at any point. This architecture also ensures that each class has its own unit test, which then also provides the full functionality of the ABAP Unit.

You should first think about such an architecture and, with every development, keep in mind the advantages of this architecture. Here are a few examples why you should make yourself such a circumstance:

• You implement a few validations in a report to check entries against certain tables and data. You can not only need this validation in a report, but also in an input interface (RFC function module), an OData service or another report.
• You access data from a table and update its content. If you only do this locally in your report, then the next implementation in a function module will be duplicated, as this function was not properly encapsulated. A central point for access to the table is worthwhile here.

 

For all of these examples, you can also implement ABAP unit tests and ensure stable APIs for your applications. You will have to worry less about extensions in the future.

 

Data

Access to the database can be mapped with DAOs (Data Access Objects). This gives you a single point of access for the table and does not map the logic for access twice. Authorization checks and locking concepts only need to be implemented once. The object can also be released for access by other applications.

If there is a relationship between tables that are dependent on one another, then a DAO should no longer be used. This is more of a business object, there are other technologies, such as:

• BOPF - Business Object Processing Framework
• RAP - ABAP Restful Application Programming Modell

 

At this point you should opt for RAP if the new architecture is already supported in your system. Otherwise, you can also switch to BOPF in order to map a clean and consistent business object.

 

Conclusion

With a clean architecture and rules for managing source code, code reuse in the system improves. Due to the possibility of automated testability and tests, errors can also be easily uncovered during development. Above all, coordination and support within the development team and finding a common path are important.