Category: ABAP

ABAP

  • SAP RAP Architecture

    Preface – This post is part of the SAP ABAP RAP series.

    Introduction

    THE SAP ABAP RESTful Application Programming model (RAP) supports the efficient end-to-end development of SAP OData based SAP Fiori services and Web APIs intrinsically optimized for SAP HANA on SAP BTP (Business Technology Platform) ABAP environment or on-prem SAP S/4 HANA.

    Architecture Overview

    The below rough version of SAP RAP Architecture depicts the major functionalities that we can utilize:

    What is SAP RAP

    The below figure displays the major artifacts you have to deal with while developing the OData services using the SAP ABAP RESTful Application Programming model. It depicts the bottom-up approach that illustrates the application development flow.

    SAP RAP Architecture

    Figure 1: SAP ABAP RAP Architecture Overview

    The SAP ABAP RAP is three-layered architecture: Data Modelling and Behaviour; Business Services and; Service Consumption. Let’s see briefly.

    Data Modelling and Behaviour

    The base layer of RAP is DATA Modelling and Behaviour. Here, we define the business object models, query definitions and their transactional behaviour. Taking an example of a simple SAP Fiori based application, we define the database table and expose the data using CDS. As soon as the CDS for the root entity is created, we define the transactional behaviour also.

    Business Services

    In the middle layer, the OData exposer is done in two steps: the first step is where the protocol service scope definition of relevant data entities is defined, and the second step is data binding to the OData model. For example, we have 50 CDS views relevant to Sales-Order but we want only 1 view to be exposed to the outside world. This scenario can be achieved via this layer. (See Figure 2)

    Design-time artifacts

    Figure 2: Design-time artifacts

    Service Consumption

    The topmost layer is the Service Consumption layer. Here, an OData Service can be exposed as a UI service which can be consumed by SAP Fiori or Web API, that can later be consumed by any client.

    Illustration of OData Service consumption by SAP Fiori UI and WEB API

    Figure 3: Illustration of OData Service consumption by SAP Fiori UI and WEB API

  • Introduction to SAP RAP: ABAP RESTful Application Programming Model

    Preface – This post is part of the SAP ABAP RAP series.

    Introduction

    SAP has introduced various programming models helping the organizations via development of efficient applications that meets their business needs. Over time, with changing requirements and technologies, these programming models have evolved from DYNPRO and list programming models for SAP GUI based applications to WEB DYNPRO model for web-based applications and thereafter to SAP ABAP programming model for SAP Fiori.

    While SAP ABAP programming model for SAP Fiori is a key advantage in terms of evolving landscape, flexibility and efficient modelling for SAP Fiori, SAP HANA; lacks certain criteria like simplicity and typed access to business entities which seems to be the basic need for application development. Here RAP, a new programming model by SAP, fills the gap.

    SAP ABAP RAP provides the intrinsic approach to build SAP Fiori based applications that are optimized for S/4 HANA and can run over on-premise as well as on the cloud.

    Evolution of ABAP programming model

    Let’s take a look at how programming models are changed over the years:

    Evolution of ABAP programming modelFigure 1: The evolution of the ABAP Programming model

    Traditional ABAP programming model

    The traditional ABAP programming models include Classical ABAP Programming- such as DYNPRO and list programming for SAP GUI based applications and business servers and WEB DYNPRO for web-based applications. This model was designed for a traditional on-prem environment.

    ABAP Programming model for SAP Fiori

    The model is based on CDS, BOPF and SAP Gateway. It reduces the complexity with advanced SEGW option reference data source (RDS) to expose the scope of the CDS model to an OData service.

    Additionally, it supports service to transactional applications. To enable transactional services we need to provide the special annotation that links the CDS model to the corresponding BOPF framework model which supports transactional oriented behaviour via artifacts:  validations, determinations and actions.

    Both CDS and BOPF are different in nature and as they both are modelling frameworks; you must need to maintain both in parallel. CDS is a typed framework that is embedded in ABAP design time and runtime where type checking is done at design time, in contract BOPF is very generic and most of the errors happen at runtime which is difficult to debug. Also, while developing a typical standard application, many artifacts are created which adds to the complexity while implementation or changing model parts. To overcome this limitation of the ABAP Programming model for SAP Fiori, SAP ABAP RAP model was introduced.

    SAP ABAP RESTful Application Programming model

    SAP ABAP RESTful Application Programming Model (RAP) was introduced by SAP Cloud Platform ABAP environment and is available with 1808 release and higher.

    The RESTful Application Programming model is built on the top of the semantic data model (CDS) and the transactional services are exposed in behaviour definition and implementation in implementing behaviour class. It also allows adapting the existing applications to be modelled which is intended to be used over a long time.  You can start from scratch (greenfield implementation) or you can reuse existing business logic (brownfield implementation).

    One can develop the following end-to-end scenarios:

    • SAP Fiori service
    • Service consumption
    • Web APIs

    What is SAP RAP?

    In simple words, SAP RAP is a new way to develop Fiori Applications based upon HANA features. This programming model uses ABAP programming methodology.
    It uses the following:
    1. ADT (ABAP Development Tools in eclipse or HANA Studio): This is used to develop tasks

    2. CDS (Core Data Services in eclipse or HANA Studio): This is used for the implementation of business object layer

    3. A New Framework: This is used to handle business logics. It generates web APIs that can be consumed by Fiori or any other applications.

    The rough diagram of SAP RAP is shown below:

    What is SAP RAP

    This programming model looks very similar to the classical ABAP OData and CDS based UI5 Development. This programming model will replace the old way of developing apps via OData SEGW and BOPF.

  • SAP BOPF (Business Object Processing Framework)

    Preface – This post is part of the Object Oriented ABAP series.

    Introduction

    Every year, more than 1 million custom objects are created by various industries using SAP ABAP technology. All these custom objects starts as a fresh requirement and needs the same monotonous approach of development. SAP hence came up with a new framework in SAP ABAP which focuses upon the individual business logic, rather than expending efforts on the development of application infrastructure. This framework in known as Business Object Processing Framework or SAP BOPF.

    What is SAP BOPF

    SAP BOPF is an Object Oriented ABAP based framework that provides a set of generic services and functionalities that helps to standardize, modularize and speed up the development process. A BOPF is capable of managing the entire life cycle of business objects as well as covers all the aspects of the business application development.

    In simple words, BOPF replaces the work of SE24 class builder with all the custom CRUD operation. It acts as the transaction/application layer in SAP architecture. With the help of ABAP CDS (Core Data Services) it can be exposed directly over HTTPS and used via UI5 Applications.

    SAP BOPF Architecture

    A BOPF simplifies the entire business process by dividing it into small entities. The business object in BOPF is represented as a hierarchical tree of nodes. While each node includes a set of business logic attributes.

    SAP BOPF Basic Architecture

    Here, each of the business logic attributes signifies a specific business logic part. In the diagram we have shown all the elements that are part of a Node of a BOPF:

    SAP BOPF Architecture

    The elements shown above are:

    1. Action: It is an important entity and is used to implement a service of Business object. It is responsible for all the actions the node performs.
    2. Alternative Keys: All the instances of BOPF are controlled via the keys as key plays important role during CRUD operation. Mainly the keys are GUID or UUID, hence it gets important to have alternative value that are human readable.
    3. Association: It is used to associate a node with another one.
    4. Authorization Checks: It is used to manage Authorization at node level.
    5. Determination: It is used to perform automatic execution of codes based on the trigger conditions.
    6. Query: It is the part where business queries are maintained.
    7. Validation: It is the part where validation related to the node is maintained.

    Important BOPF Transaction Codes:

    • BOBF: It stands for Business Object Building framework. Remember, it is not BOPF unlike the name of the framework.
    • BOB: It stands for Business Object Builder
    • BOBT: It stands for BO Test
    • BOBX: It stands for Business Object Enhancement Workbench

    Advantages of SAP BOPF

    SAP BOPF comes with given advantage:

    • It standardize, modularize and speed up the development process.
    • With the help of BOPF, we get the entire application infrastructure and integration of various development components for free.
    • BOPF allows us to rapidly build the applications on a stable and customer-provided infrastructure.
  • Business Add-Ins in SAP (SAP BAdI)

    Preface – This post is part of the Object Oriented ABAP series.

    Introduction

    SAP as a solution for any enterprise workflow is one of the best product available in the market. It almost covers all the possible scenarios of any business. Still, based on the requirement of the customer, a developer has to enhance the existing code. For that the developer needs to add their own code within the SAP source code. Every year SAP rolls out its new version of source codes in the form of updates. It means whatever programs or reports you are using, it gets updated yearly. In this scenario, the developer may lose their changes. To fix this issue, SAP provides some enhancement techniques which can be used to enhance the code in such a way that it is preserved for every update. One such type of enhancement is Business Add-Ins. In this article we will explore more about the concept of SAP BAdI in detail.

    What is a SAP BADI

    SAP BADI is an object oriented enhancement option where the enhancement is made with the help of reusable objects and added within the source code with the help of predefined hooks.

    How to use SAP BADI

    A BAdI is created using Enhancement spot under transaction SE80. The name of a BADI should always start with BADI_ for standard BADIs and ZBADI_ for custom BADIs.

    A BAdI can be re-implemented using two elements i.e. GET BADI and CALL BADI.

    Types of BAdIs

    SAP provides given three ways of BAdIs Implementation:

    1. Single-Use BAdI: This type of BAdIs have no filters and are called once.
    2. Multiple-Use BAdI: This type of BAdIs allow multiple implementation
    3. Filter BAdI: A filter in BAdI helps a developer to select among multiple BAdIs with the help of filters.

    Advantages of SAP BAdIs

    Following are the scenarios where a BAdI implementation is useful:

    • A customer wants to enhance his product, but modification in source code is not desired. This is easily achieved with the help of BAdIs.
    • Different country and industry have different business cases for same product. This is easily achieved using multiple BAdI implementation.
    • A customer can do add their codes after delivery. The customer with the help of BAdIs can implement their own codes in the BAdIs objects later.
  • Design Patterns in SAP ABAP

    Preface – This post is part of the Object Oriented ABAP series.

    Introduction

    In software development world, every project requires a specific flow of code to achieve its target. After the growth of Information Technology, it was observed that many of the process across various domains and business remains same. For example, the way a user sign in and sign out. These common scenarios are now achieved using a design pattern. In this article we will try to explore Design Patterns in SAP ABAP.

    Design Patterns in SAP ABAP

    In SAP ABAP, a design pattern is a general, reusable solution to a generic and common issue. In reality it is not a finished solution to implement rather it is a template for how to solve a specific problem that can be utilized in many different scenarios.
    In SAP ABAP, design patterns are considered as the best practices, an ABAPer can use to solve common problems while designing a product.

    Following are the design patterns available in SAP ABAP:

    • MVC (model, view, controller) pattern
    • Singleton pattern
    • Factory pattern
    • Builder pattern
    • Observer pattern
    • Visitor pattern
    • Lazy initialization pattern
    • Template method
    • Strategy pattern
    • Decorator pattern
    • ABAP-specific examples
    • Anti-patterns

    We will explore these individually in different articles.

    Advantage

    A design patterns comes with a lot of advantage. Following are a few of them:

    • Almost all the design patterns are object oriented and hence can be reused in multiple projects
    • With a pre-defined flow, they provide more accuracy and transparency to the project architecture and design
    • Design patterns prove to be the only solution for some of the project requirements

    Limitations

    With so many advantages, there are some limitations and criticism too of design patterns. Following are a few of them:

    • Many design patterns are either obsolete or are a part of newly developed frameworks
    • Inappropriate use of SAP ABAP design patterns seems to increase the complexity of the program
    • Design patterns are sometimes considered as Syntax. Well, it is not and can be amended as per the project requirement
    • A design pattern comes with complexity and low reusability costing more time in executing a program. It is advisable to only use a design pattern if it really serves the needs
  • Exception and Error Handling in ABAP Reports

    Preface – This post is part of the ABAP Beginner series.

    Introduction

    A programmer always tries to code in such a way that his code is bug free and full proof. But there are certain scenarios, where his codes can fail. In such case, if the coder already knows the scenarios, then he handle them in form of Error handling. But, in case of situations, where an error can be generated due to unknown situations and left un-handled can cause serious dumps. For these scenarios, we have exception handling in SAP. In this article we will explore all scenarios of Exception and Error Handling in ABAP Reports

    Exception and Error Handling in SAP ABAP Reports

    As discussed above, a coder is required to handle known issues as well as intended error messages. These messages are shown to user in the output via MESSAGE statement.

    Different ways to catch Errors/Exception

    ABAP provides various ways to catch errors in an ABAP program.

    1. Using System Variable

    The simplest way is to use their system variables.

     SY-SUBRC EQ  0. "This statement indicates that an operation completed successfully.
     SY-SUBRC NE  0. "This statement indicates that an operation has failed.

    This way works directly if the entire code of report was process within the same program. It means, it cannot catch an error directly in case you have processed a Function Module or ABAP Class statements. For those entity, we need to raise exception from their end, and then exception can be handled in the report and processed accordingly.

    1. Catching Errors based on Exception

    In case, we implement a function module or method of a class, then it is important to raise exception from these classes and then we can catch these exceptions in report and show respective error.

    For Example:

    CALL FUNCTION 'Test_Function'
    
         EXPORTING
    
              DELIMITER =   ':'
    
              STRING        =   lv_string
    
         IMPORTING
    
              HEAD           =   lv_head
    
              TAIL             =   lv_tail
    
         EXCEPTIONS
    
              NOT_FOUND   =  1
    
              OTHERS       =   2.
    
    
    
    
    CASE SY-SUBRC.
    
         WHEN 1. ...
    
    // Show Error Message
    
         WHEN 2. ...
    
    // Show Error Message
    
         WHEN OTHER.
    
    // Show Error Message
    
    ENDCASE.

     

    1. Using TRY CATCH ENDTRY

    In case an exception is raised via a method of class, or an unexpected exception is raised, in these cases, we use TRY CATCH functionality of SAP ABAP. This is one of the best full proof way to handle all types of exceptions.

    Example:

    TRY.
    
         //Call your class or function module here
    
    CATCH CX_SY_ZERODIVIDE INTO O_REF. // The exception you have raised there
    
         MESSAGE “Your Error Message”.
    ENDTRY.

     

    Different ways to show Messages

    1. Using ABAP Statement

    Syntax:

    MESSAGE ‘<Enter Your Text here>’ TYPE ‘Enter the type of Message here’.

     

    Types of Message

    ABAP provides the following 6 types of messages:

    Message Type Meaning Explanation
    A Termination This message is shown during program termination.
    E Error This message is shown during Error.
    I Information This message is used to show any information.
    S Success This shown in the status of the Output screen.
    W Warning It behaves like an error message.
    X Exit It causes a short dump with error message.

     

    1. Using Predefined Function Modules

    ABAP provides following function modules that can be used to store, format and show messages altogether:

    Function Module Usage
    MESSAGES_INITIALIZE To Initialize the messages.
    MESSAGE_STORE To Store the messages to be displayed.
    MESSAGES_SHOW To Display all the messages together on a pop up
    FORMAT_MESSAGE To Format the messages
    HR_DISPLAY_ERROR_LIST To display all the error messages

    Example:

    1. Using Message Statement
    MESSAGE 'This is an error message' TYPE 'E'.

     

    1. Using Multiple functions to store and show messages:
    " It is Initialized only initially...
    * Initialize your messages
      CALL FUNCTION 'MESSAGES_INITIALIZE'
        EXCEPTIONS
          log_not_active       = 1
          wrong_identification = 2
          OTHERS               = 3.
    
    "One by one append all your messages here
          PERFORM store_messages USING 'E'
                                       w_pn
                                       w_batch2
                                       w_werks
                                       ' '
                                       w_msgno.
    
    FORM store_messages USING p_msgty
                              p_msgv1
                              p_msgv2
                              p_msgv3
                              p_msgv4
                              p_txtnr.
      IF p_msgty EQ 'E'.
        w_err_fg = 'X'.
      ENDIF.
    * Store all your messages meant to be displayed
      CALL FUNCTION 'MESSAGE_STORE'
        EXPORTING
          arbgb                  = 'ZCCH001'
          msgty                  = p_msgty
          msgv1                  = p_msgv1
          msgv2                  = p_msgv2
          msgv3                  = p_msgv3
          msgv4                  = p_msgv4
          txtnr                  = p_txtnr
        EXCEPTIONS
          message_type_not_valid = 1
          not_active             = 2
          OTHERS                 = 3.
    
    ENDFORM.                    " STORE_MESSAGES
    
    "In the end fetch all your message and show them altogether
    * This displays all the messages in a popup
      CALL FUNCTION 'MESSAGES_SHOW'
        EXPORTING
          show_linno         = ' '
        IMPORTING
          e_exit_command     = wa_exit_command
        EXCEPTIONS
          inconsistent_range = 1
          no_messages        = 2
          OTHERS             = 3.
    

     

    1. Using HR_DISPLAY_ERROR_LIST
    DATA:
    
    it_error        TYPE STANDARD TABLE OF HRERROR,"TABLES PARAM
    
    wa_error     LIKE LINE OF it_error .
    
    DATA(ld_no_popup) = 'some text here'.
    
    DATA(ld_no_print) = 'some text here'.
    
    DATA(ld_no_img) = 'some text here'.
    
    DATA(ld_no_msgno) = 'some text here'.
    
    DATA(ld_linesize) = '123 '.
    
    DATA(ld_listheader) = 'Check type of data required'.
    
    DATA(ld_colheader) = 'Check type of data required'.
    
    DATA(ld_hidemsg) = 'some text here'.
    
     
    
     
    
    "populate fields of struture and append to itab
    
    append wa_error to it_error.
    
    .
    
    CALL FUNCTION 'HR_DISPLAY_ERROR_LIST'
    
    * EXPORTING
    
    *   no_popup =                   ld_no_popup
    
    *   no_print =                   ld_no_print
    
    *   no_img =                     ld_no_img
    
    *   no_msgno =                   ld_no_msgno
    
    *   linesize =                   ld_linesize
    
    *   listheader =                 ld_listheader
    
    *   colheader =                  ld_colheader
    
    *   hidemsg =                    ld_hidemsg
    
    * TABLES
    
    *   error =                      it_error
    
      EXCEPTIONS
    
        INVALID_LINESIZE =           1
    
        .  "  HR_DISPLAY_ERROR_LIST
    
    IF SY-SUBRC EQ 0.
    
      "All OK
    
    ELSEIF SY-SUBRC EQ 1. "Exception
    
      "Add code for exception here
    
    ENDIF.

     

  • Difference between SAP BDC, BAPI and OData

    Preface – This post is part of the Differences in ABAP for Interviews series.

    Introduction

    SAP has always been all about data. Since its evolution, SAP has deployed so many ways to play around data. It is also important for any business to access, transfer and store its data from internal and external sources. Keeping these things in mind, SAP has introduced (in different timelines) different ways to process data transfer. In this article, we will be focusing upon three of them as well the difference between SAP BDC, BAPI and OData.

    SAP BDC

    SAP BDC stands for Batch Data Communication, is an application interface framework, used to process batch input sessions resulting into batch data transfer. They are also simply called Batch Input.

    SAP BAPI

    SAP BAPI stands for Business Application Programming Interface, are RFC function modules that enables external applications to access, process, migrate and store data in SAP. External applications mainly communicate with SAP using HTTP gateway.

    SAP OData

    SAP OData is a web gateway that converts SAP business data into a REST API. This REST API is capable of performing Create, Read, Update and Delete (CRUD) operations using HTTP gateway.

    Difference between SAP BDC, BAPI and OData

    SAP BDC SAP BAPI SAP OData
    BDC is the old method of moving legacy data to SAP. BAPI is the new Interface based system for data manipulation. SAP OData is an open source based API tool to perform activities over SAP data.
    BDC is transaction oriented, hence where transactions run to extract data mainly from text file. BAPI is interface oriented, hence data is processed via standard interfaces. OData is API based on Object oriented methods, hence data is processed via API calls.
    BDC is based upon reports. BAPI is based upon RFC. OData is based upon REST.
    Good for uploading mass data internally. Good for connecting SAP system to others. Good for connecting SAP systems to UI5 and other UIs.

     

  • Difference between Enhancement point and Enhancement spot

    Preface – This post is part of the Differences in ABAP for Interviews series.

    Introduction

    Every year SAP provides a new update to its platform. All the SAP standard programs are designed in such a way that it meets almost all the requirements of a user of a particular sector. But sometimes, there comes a requirement that user wants something else that SAP program is providing. In this case, the simplest way is to modify the source code to meet the requirement. But the disadvantage in doing so is that the modification is erased as soon there is an update. To fix this issue, SAP introduced something called Enhancement framework. These enhancements are added in form of small hooks also known as Enhancement points. In this article we will discuss the difference between Enhancement point and Enhancement spot.

    Enhancement Point

    Enhancement points are the position in a SAP ABAP program where enhancement are made. The enhancements, when complied with the current source code work as if it was a part of the source code.

    Enhancement Spot

    All the enhancements can be added as per the SAP framework guidance or directly by the developer (explicitly). These positions available to a developer is termed as Enhancement options.

    When the enhancement is made based upon the developers choice, then these information are required to be stored in a container with their positions. These containers are termed as Enhancement Spot.

    Difference between Enhancement point and Enhancement spot

    Enhancement Point Enhancement Spot
    It is mainly predefined locations in SAP ABAP. It is mainly explicit and created by developers.
    It is placed with the help of ENHANCEMENT-POINT statement. It is placed with the help of SAP Enhancement Wizard in SE80.
    Enhancement point basically contains codes. Enhancement Spot basically contains the positions of Enhancement Options or Enhancement points.

     

  • Difference between Singleton Class and Persistent Class

    Preface – This post is part of the Differences in ABAP for Interviews series.

    Introduction

    SAP OOABAP provides different types of classes to handle different types of scenarios. Some of the classes are the part of SAP Design patterns to perform a specific type of workflow, whereas others are there to perform core functions. In this article we will compare two of them. Let us discuss the difference between Singleton Class and Persistent Class in SAP ABAP.

    Singleton Class

    Sometimes there is a need to instantiate an object at a time, that means only one instance is required at one point of time. This is a very common requirement while designing an application. To achieve such a scenario, there is one concept of ‘Singleton Pattern’ or ‘Singleton Class’ in OOABAP.

    A class is said to be a singleton class if it can have the utmost one instance only.

    Persistent Class

    Before going for persistent class, let’s first discuss the meaning of ‘persistent’.  A data is said to be persistent if it can be preserved beyond the runtime of program.

    For a session, ABAP program stays in local ABAP memory till the runtime of that program. To store it permanently, we use persistence service (implemented by persistence class).

    Difference between Singleton Class and Persistent Class

    Singleton Class Persistent Class
    It can have only one instance. It can have multiple instances.
    It cannot store data beyond runtime. Data can still persist beyond runtime.
    It is used for functions like single sign-on and logger. It is used for functions like booking system where particular transaction blocks a seat/item.

     

  • Difference between Enhancements and BADI

    Preface – This post is part of the Differences in ABAP for Interviews series.

    Introduction

    Every year SAP provides a new update to its platform. All the SAP standard programs are designed in such a way that it meets almost all the requirements of a user of a particular sector. But sometimes, there comes a requirement that user wants something else that SAP program is providing. In this case, the simplest way is to modify the source code to meet the requirement. But the disadvantage in doing so is that the modification is erased as soon there is an update. To fix this issue, SAP introduced something called Enhancement framework. In this article we will discuss the difference between Enhancements and BADI.

    Enhancements in SAP ABAP

    As discussed earlier, SAP introduced Enhancement framework to enhance a particular piece of source code. To keep these process easy and flexible, SAP provides certain area where these enhancement codes can be added. These are called “hooks”. The best part of these enhancements is that they behave like the actual code and at the same time, they are transported separately among the different landscapes.

    BADI in SAP ABAP

    Earlier, we have seen that we were able to add code into the source code and transfer the same to different landscapes. SAP later created a new type of enhancement framework which uses Object Oriented concepts. This new Enhancement technique, thus, was created in form of class and objects and was available for reuse.

    BADI stands for Business Add-Ins. They are object oriented based enhancement techniques that can be reused.

    Now let us discuss the difference between Enhancements and BADI.

    Difference between Enhancements and BADI

    Standard Enhancements BADI
    A standard Enhancement technique can be used only once. A BADI can be used any number of times.
    They are not object oriented. They are purely object oriented.
    They are easy to implement. It is the most sophisticated enhancement.
    These are mainly changed only by developer. The BADI codes are separated from the source code, hence customer too can do further implementations using BADI.