This course provides a dive into the concepts of classes, abstract/exception classes, interfaces, events and event handlers, SAP Application Log, dynamic method calls, the use of Run Time Type Services (RTTS), and the ABAP Unit testing framework.
The ABAP Unit testing tool is a framework that drastically improves code quality by allowing the programmer to embed test classes directly into an object being developed. This course, SAP ABAP Objects: Advanced Programming Techniques, serves as a follow-up from the earlier “Introduction to ABAP Objects: Concepts and Class Builder” course. The first portion of this course will provide a deeper dive into the concepts from the introductory course. First, using some real-world business scenarios as examples, sample applications are built using base classes, abstract classes, interfaces, events, and event handlers. Error handling & recovery using exception classes is covered in great detail. All of the provided examples are built using a reliable framework that reinforces best practices for coding. Next, you will cover the various tools and APIs that are available within the ABAP environment to improve code quality and productivity. The SAP Application Log is explored and describes how to create Application Log objects, how to write Application Log entries, and how to subsequently retrieve the entries for program analysis and trouble- shooting. Finally, you will discover one of the most powerful tools in the ABAP environment - Run Time Type Services (RTTS). Using this framework, the course shows how to analyze the composition of simple or complex anonymous data objects at run-time, and how to build data-driven processing routines based on the object metadata. In addition, we demonstrate how to use RTTS to dynamically construct custom data objects as needed during program execution. By the end of this course, you will know, step-by-step, how to write test classes and execute unit tests.
About the author
About the author
Dorian is an SAP Technical Consultant / Business Process Expert with over 20 years experience of Systems and Application programming, specializing in SAP Mobile Solutions.
Course Overview (Music playing) Hello, I'm Dorian Salmon. Welcome to my course ABAP Objects: Advanced Programming Techniques. I'm an SAP Technical Consultant with SOA-Connect. I've been working with SAP and ABAP since 1995 and created the Introduction to ABAP Objects course that you may have already taken. This course is a natural progression from the earlier introductory course and starts off by taking a detailed look at how and when to use different types of objects to solve a variety of real-world business problems. The first half of the course consists of a deep dive into base classes, abstract classes, interfaces, events and event handlers, and error management using exception classes. You will also be shown a reliable framework that can be used to create programs using ABAP objects that reinforces best practices for coding. In the second half of the course, we explain how to use various tools and APIs that are available within the ABAP environment to improve code quality and productivity. We show how to create your own application log objects and write application log entries that subsequently be retrieved to help with program analysis and troubleshooting. One of the most powerful tools within ABAP is the run time type services, otherwise known as RTTS. You will learn how to determine a structure of anonymous data objects at runtime to build data-driven processing routines, how to dynamically create custom data objects as needed during program execution, and how to make dynamic method calls. We also cover ABAP unit, a testing framework built into the ABAP environment that drastically improves code quality by allowing the programmer to embed test classes directly into an object that is being developed. I hope that you'll join me to learn even more about the SAP ABAP environment with the ABAP Objects: Advanced Programming Techniques course at Pluralsight.
Getting Started Hello, I'm Dorian Salmon. I'm going to show you a variety of advanced level approaches to ABAP objects programming that you can use to solve many complex business problems. At the end of this course, you will have a good understanding of the different ways that objects can be reused and when to reuse each one. You will have learned some powerful techniques for writing dynamic code and creating data objects at runtime. You will also have seen several ways to handle and report error conditions and how to incorporate automated test routines into your programs and classes. As a result of learning these skills, you'll be able to produce highly efficient and very maintainable code in very little time. Let's get started with a review of different objects that we can use. When developing a new program using ABAP objects, the first decision we must make is do we need a local or global class? Then as we develop each component, we must decide if that component is a static or instance component. Assuming we decide that a new global class is most suitable for our needs, we can reuse an existing class of our inheritance, create a new class, which may or may not be reused in the future, create a new abstract class intended specifically for reuse, or create a specialized class for specific functionality, such as a test class. Other objects that are commonly used are interfaces, exception classes, and test classes. We will be working with all of these objects over the duration of this course.
Exception Classes In this module, you will learn how to manage program errors using exception classes. What exactly are exceptions? They are events that interrupt execution of programs because it is not possible to continue processing in a meaningful way. Exceptions fall into two categories. Treatable or catchable exceptions can be processed using try catch exception handlers. As long as a suitable handler is provided, this exception category is non-fatal. Non-treatable exceptions cannot be caught or handled. When these exceptions occur, they result in a short dump. Exceptions in this category are typically caused by serious system events, such as running out of memory or addressing an unassigned field symbol. The ABAP documentation shows the treatable and non-treatable exceptions that may be raised by a statement. This is a portion of the documentation for the assigned statement. It lists the treatable and non-treatable exceptions that should be anticipated for the statement. In this module, we will be discussing only treatable exceptions. Here is the sequence of handling exceptions after they are triggered. First a matching exception object is looked for any enclosing try catch exception handle block. If a match is not found in an enclosing exception handler, or no handler has been defined, the interface of the current module is searched for a matching exception object. If found, then the exception is propagated to the calling module. If no match is found in the current module interface, then the exception object is still propagated to the calling module, but converted to an object of type CX_SY_NO_HANDLER.
Application Log In this module, we will have a detailed look at how to program events. First of all, what is an event in the ABAP programming world? It is a software message indicating that something has happened. Events typically fall into two categories. Most commonly, programmers work with the user generated category, mouse clicks and function key presses while a user is interacting with an application. The other less common category is that of API generated events, such as a file being dropped into a folder or a batch job completing. Whether generated by a user or an API, the sequence for processing an event is identical. Initially, all possible events that can occur must be defined. The definition consists of the event name and optional parameters. For instance, a click event would have parameters that describe exactly what was clicked, maybe an object reference or a row and column location. For each defined event, a corresponding piece of code to be executed must be linked to the event. This code is referred to as an event handler. The linking of the handler to the event is referred to as registering the handler. At some point in a running application, a defined event is triggered either by user interaction or a software API. This step in the process is referred to as raising an event. Once the event has been raised, the registered event handler is executed to respond to the raised event.
Abstract Classes In this module, we will be working with the SAP application log. The application log provides an infrastructure for collecting messages during the execution of an application, saving the messages in the database, then later on displaying them in the form of a log. The application log is used for temporary storage. Messages are purged at regular intervals by batch jobs. Purged messages are either permanently deleted or archived using archiving object BC_SBAL. So what is the purpose of an application log? The answer is found by looking at the different ways that messages are sent by applications and their lifespan. Programs can output messages in the form of pop-ups or status line messages at the bottom of the screen. The lifespan of these messages is the time between the message appearing and the user clicking a button in the case of a pop-up, or the next message being generated in the case of status line messages. To preserve messages past the execution of a program, they can be sent to spool output using the write statement. Once the program terminates, the message output is written to the system principle. However, unless specific action is taken to preserve the output, principle data is automatically deleted by the system after a period of 7-10 days. Messages written to the application log have an indefinite lifespan. They will remain in the log until explicitly purged. Even when purging is automated using batch jobs, their attention span is typically a minimum of 90 days and will often be longer. As well, logs can also be archived instead of purged, which can result in a lifespan of years. Another consideration is the practical message size. Of the three possibilities, the application log is best suited for managing large messages for diagnostic purposes.
ABAP Unit One of the least favorite aspects of a developer's job is testing. Mainly testing is done at the end of development, and in the case of large complex objects, can result in the need to rework methods that in turn adversely affect other areas of code. The ABAP unit framework can take a lot of pain out of the test cycle. Let's see how this is possible. So what is ABAP unit? As the name suggests, it is a unit test tool that works on small modularized sections of code. The ABAP unit framework is directly integrated into the ABAP environment. The unit tests are implemented as local ABAP class methods. In most cases, a single class is used, but for complex development objects, the tests can be divided into multiple classes when necessary. There are many benefits to using ABAP unit for testing. All of the tests are written in ABAP. There is no new scripting tool to learn. The test code is actually part of the development report or class object, so it's easily accessible. You can develop the test code while doing development. If you create a method that you think may be a potential error source, you can immediately write a unit test method that will test the logic of the newly developed code. You can create test data at the same time that you develop code and unit tests. This means that you can progressively test new code as soon as it is developed instead of waiting until the development is complete to test against live data. If new functionality is added during maintenance cycles, additional unit test code can also be immediately added to make sure that errors aren't inadvertently introduced with the new code. Even though the test code coexists with the development code in the same object, it is not possible to execute ABAP unit tests in a production system. This guarantees that no security breaches are introduced via test code and there is no added performance overhead.