Skip to Content

The next two  Blogs might be a bit boring for you. But that will not hinder me from telling you, which types of memory an ABAP program can access and what kind of data can be addressed there. I will start with the most general memory and will work my way down to the individual ones. If you prefer it another way around, you must read this Blog bottom up.

SAP System

The most general entity we have in an ABAP based SAP world is what was called R/3 System in ancient times. Let’s call it SAP System now. Technically, such a SAP System is based on the SAP Web Application Server ABAP (containing the former SAP Basis), which is part of SAP  NetWeaver.  From everywhere in such a SAP System, you can access the same persistent data of its central database.  But since a SAP System normally runs on several application servers, there is no transient memory that can be accessed from everywhere in the system. For that we have to step one level down.

Application Server

A SAP System is distributed among  one or more application servers. On each application server an instance of the SAP System is running. The common memory of an application server is its Shared Memory. Every ABAP program running on an application server has access to the Shared Memory. There are two ways of how you can access the Shared Memory from an ABAP program:

  • Before Release 6.40, you could only use the well known EXPORT and IMPORT statements to store and read data clusters in the Shared Memory. With the additions SHARED MEMORY or SHARED BUFFER, data clusters are stored in or read from so called application buffers of the Shared Memory. The two application buffers differ in respect to how the system behaves when reaching the memory limit. Data clusters in Shared Memory are stored in memory tables that reflect the structure of an INDX type database table.
  • As of Release 6.40, you can also store and access Shared Objects in the Shared Memory. Shared Objects are instances of shared memory-enabled classes that are stored in an area of the shared memory. An area in the Shared Memory is managed by an area class. The instances of an area class are used as area handles. In an ABAP program, you access an area and its Shared Objects via area handles. For example, a shared object is generated with the addition AREA HANDLE of statement CREATE OBJECT.

User Session

When  an user or an application (e.g. via RFC) logs on to a SAP system, he, she, or it connects to a certain application server where an User Session is created. The common memory of  an User Session is the so called SAP Memory. ABAP programs have access to SPA/GPA parameters stored in the SAP memory. SPA/GPA parameters (or SET/GET parameters) are set using SET PARAMETER and read with GET PARAMETER. Input fields on dynpro screens can be linked with SPA/GPA parameters. When a screen is called, the default values of such input fields are taken from the SAP Memory. When the screen is left, the field values are stored in SAP Memory (that’s why you always find the name of the last edited program in the input field of the ABAP

Editor SE38). SPA/GPA parameters are managed in the database table TPARA.

Main Session

For each User Session, at least one so called Main Session (or External Session) is created. In dialog processing, one User Session can manage up to six Main Sessions, where each Main Session is connected to a window on the screen. Additional Main Sessions are opened with the GUI function Create a new Session or with the addition STARTING NEW TASK during a remote function call (RFC). The memory area  of  a Main Session, that can be accessed from several ABAP programs is the so called ABAP Memory. You access the ABAP Memory with the EXPORT and IMPORT statements again. This time, you use the addition MEMORY ID. With that you store or read a data cluster with a specific id in the ABAP Memory. An ABAP Memory and its lifetime  is connected to a call sequence. A call sequence is created if you can return from a called ABAP program to the calling ABAP program. The respective statements are SUBMIT AND RETURN and CALL TRANSACTION. All programs of a call sequence have access to the same ABAP Memory. When a call sequence is finished, the respective ABAP Memory is deleted.

Internal Session

For each call of an ABAP program, a so called Internal Session is created in the Main Session. The Internal Session contains all the ABAP program’s own data and objects during the execution of the program. That’s what you mostly work with! (DATA, CREATE OBJECT and all that stuff!) Other ABAP programs (their

data, and their objects) can be loaded into the same Internal Session via external procedure calls (more about this in the next  Blog). An Internal Session lives as long, as its first ABAP Program (the main program) is executed. During call sequences, the respective internal sessions are stacked. You can stack maximally nine internal sessions.

Technical note: From a conceptual point of view it is always OK to speak of “loading programs into an Internal Session”. But technically, each Internal Session is subdivided into PXA and Roll Area. The PXA (Program Execution Area) is a shared memory for the byte codes of all programs running concurrently at any one time on an application server. Only the Roll Area is the memory that is actually reserved for the data and objects of each individual internal session. Just if anybody asks …

To report this post you need to login first.

12 Comments

You must be Logged on to comment or reply to a post.

  1. Scott Barden
    I was (mistakenly) under the impression that shared objects were cross-application server.

    If they are limited to am application server only then I wonder what there benefits are over the pre-6.40 shared memory approach?  Is it mainly that they are OO-friendly and have a surrounding management layer?

    Cheers,
    Scott

    (0) 
    1. Horst Keller Post author
      Scott,

      the great benefit of Shared Objects compared to the old EXPORT/IMPORT approach is, that it is copy free!

      Once you connected to a shared object in Shared Memory via an area handle, you can work with this object and its data exactly in the same way as you would work with data in your Internal Session. No need to import into your program’s own data objects any more.

      Regards

      Horst

      (0) 
      1. Scott Barden
        Thanks for the response Horst, I see the advantage.

        I hope you don’t mind but I’ve added some unrelated questions that perhaps you might be able to cover in future posts?

        1) Will it ever be possible to expand macros when debugging?  This would be a very useful option.

        2) What is the reason for disallowing static variables inside methods (most often flags to indicate database access has already been done)?  I understand that the equivalent can be achieved with instance attributes – but this can unnecessarily bloat the attribute list and increases the scope of the variable.

        3) Will ABAP Objects support virtual attributes, where set/get access to the attribute invokes private methods instead?

        Cheers,
        Scott

        (0) 
        1. Horst Keller Post author
          1) Counter question: Do you know any debugger that can debug macros? – OK, the ABAP Debugger could, but it takes time to develop things. After all, the new ABAP Debugger debugs conversion routines now. Debugging macros might also come sometime.

          2) If you mean simple static variables as defined with STATICS inside a procedure, this would be not such a good idea. Those variables would be bound to their method and not to an instance. An instance calling the method would find the value as it is left from the preceding call of any other instance. I guess what you would like to have are a kind of method bound private instance attributes of the class. Yes, one could think about that.

          3) Virtual attributes are already under discussion in the ABAP Objects group for some time. Comes time, maybe comes features …

          (0) 
          1. Scott Barden
            1) True, but then how many other languages are as good at business programming as ABAP? 🙂  I just figure that if the “compiler” can expand the code for syntax checks, then the same should be true for the debugger.

            2) Yes, it would of course be necessary for such statics to be bound to the instance where the corresponding method is not, err…, static.

            3) I was waiting from R/2 4.4B (when I started) to R/3 4.5 to be able to reference data elements directly in my ABAP code.  I can wait for this too!

            Cheers,
            Scott

            (0) 
  2. Klaus Meffert
    We currently have a problem with the internal session maximum of 9. Not about the number of 9 but with the fact that after reaching this limit, the SAP system reports an error in the status line and quits the transaction completely. Do you know anything to do about (except giving the advice that can be found in sap notes to avoid opening that much modi….)?

    Is it possible intercepting SUBMIT calls (that produce new internal sessions in our case) in a way that checks the current number of internal sessions and if the maximum is near to be reached reports a warning to the end-user?

    (0) 
  3. Iksang Kim
    Hi, I read your report well.

    We developing some business logics under SAP-EP 6.0.

    Business requires call reports program in EP using some parameters.
    We Develop 3 Objects(2 RFC Functions, 1 Report) for this Requirement.

    First RFC Functions set parameter value using “Export Shared Buffer” and 2nd RFC Function get parameter value using “Import Shared Buffer” and Report program submit program already developed.

    But, this process rarely executed.
    We eagered to solve the problem for 1 week more, but could’t find the cause and corret the probelm.

    Would you mind if I ask your advise ?

    1st : Export to Shared Buffer Function
      DATA : B_RISK LIKE YRMS_SIMS_RISK.
      B_RISK-BUKRS = P_BUKRS.
      B_RISK-RISK_KEY = P_RISK_KEY.
      MOVE P_JOB_DATE TO B_RISK-JOB_DATE.
      EXPORT B_RISK TO SHARED BUFFER INDX(AR) ID P_RISK.

    2nd : Import to Shared Buffer Function
      DATA : B_RISK LIKE YRMS_SIMS_RISK .
      IMPORT B_RISK FROM SHARED BUFFER INDX(AR) ID P_RISK.
      MOVE B_RISK TO S_RISK.
      APPEND S_RISK.
      DELETE FROM SHARED BUFFER INDX(AR) ID P_RISK.

    3rd : Sumit Report Program.
    REPORT  YRMS_305 NO STANDARD PAGE HEADING.

    DATA : S_RISK LIKE YRMS_SIMS_RISK OCCURS 0 WITH HEADER LINE,
           P_RISK LIKE YRMS_FI01-TEXT_KEY,
           REP_NAME(20),
           P_BUKRS LIKE YRMS_FI01-BUKRS,
           P_JOB_TERM  LIKE YRMS_003-JOB_TERM,
           P_JOB_DATE  LIKE SY-DATUM.
    DATA : BEGIN OF RISK_KEY ,
           RISK_1 LIKE YRMS_003-RISK_1,
           RISK_2 LIKE YRMS_003-RISK_2,
           RISK_3 LIKE YRMS_003-RISK_3,
           END OF RISK_KEY.
    RANGES : S_DAY FOR YRMS_201-JOB_DATE,
             S_WEEK FOR YRMS_201-JOB_DATE,
             S_NA FOR YRMS_201-JOB_DATE,
             S_MONTH FOR YRMS_201-JOB_DATE.

    *– Get buffer data
    CONCATENATE ‘RISK_’ SY-UNAME INTO P_RISK.
    CALL FUNCTION ‘Y_RMS_SIMS_GET_RISK’
         EXPORTING
              P_RISK = P_RISK
         TABLES
              S_RISK = S_RISK
         EXCEPTIONS
              OTHERS = 1.

    *– Set Memory
    *.. Company Code
    READ TABLE S_RISK INDEX 1.
    EXPORT P_BUKRS FROM S_RISK-BUKRS TO  MEMORY ID ‘RISKBUKRS’.

    RISK_KEY = S_RISK-RISK_KEY.
    P_JOB_DATE = S_RISK-JOB_DATE.
    P_JOB_DATE = P_JOB_DATE – 1.

    SELECT SINGLE JOB_TERM INTO P_JOB_TERM FROM YRMS_003
    WHERE RISK_1 = RISK_KEY-RISK_1 AND RISK_2 = RISK_KEY-RISK_2 AND
           RISK_3 = RISK_KEY-RISK_3.
    IF P_JOB_TERM = ‘M’.
      CONCATENATE S_RISK-JOB_DATE(6) ’01’ INTO S_RISK-JOB_DATE.
      P_JOB_DATE = S_RISK-JOB_DATE.
      P_JOB_DATE = P_JOB_DATE – 1.
    ENDIF.

    *.. Job Term¿¡ µû¸¥ ½ÇÇàÀÏÀÚ¸¦ memory¿¡ set.
    CASE P_JOB_TERM.
      WHEN ‘D’.
        EXPORT S_DAY-LOW    FROM P_JOB_DATE  TO MEMORY ID ‘SDATE’.
        EXPORT S_DAY-HIGH   FROM P_JOB_DATE  TO MEMORY ID ‘EDATE’.
      WHEN ‘W’.
        EXPORT S_WEEK-LOW   FROM P_JOB_DATE  TO MEMORY ID ‘SDATE’.
        EXPORT S_WEEK-HIGH  FROM P_JOB_DATE  TO MEMORY ID ‘EDATE’.
      WHEN ‘M’.
        EXPORT S_MONTH-LOW  FROM P_JOB_DATE  TO MEMORY ID ‘SDATE’.
        EXPORT S_MONTH-HIGH FROM P_JOB_DATE  TO MEMORY ID ‘EDATE’.
      WHEN ‘N’.
        EXPORT S_NA-LOW     FROM P_JOB_DATE  TO MEMORY ID ‘SDATE’.
        EXPORT S_NA-HIGH    FROM P_JOB_DATE  TO MEMORY ID ‘EDATE’.
    ENDCASE.

      CONCATENATE ‘YRMS_’ S_RISK-RISK_KEY INTO REP_NAME.
      SUBMIT (REP_NAME) AND RETURN.

    (0) 
  4. Anonymous
    Hi,

    COuld you explain what you mean by “external procedure calls” ?

    When you explain about internal session, you say “Other abap programs (their data and their objects) can be loaded into the same internal session (via external procedure calls) more about this in the next Blog”

    In abap geek 6 you say also that a function group is loaded by means of an external procedure call.
    Do you mean by a call function ?

    Thanks in advance for more explanations,
    Marie

    (0) 
    1. Horst Keller Post author
      Hi Marie,

      an External Procedure Call is a procedure call from another ABAP program of the same ABAP-based SAP system. The first time one of its procedures is called, the required program is loaded into the internal session of the calling program – if not already there. Apart from in the case of class pools, event LOAD-OF-PROGRAM is triggered.

      You can call the following external procedures of the same ABAP system:

      – Public methods of global classes in class-pools visible at the calling position – that is, public methods in all programs, protected methods in subclasses, and private methods in friends of the classes.

      – The static methods of local classes visible at the calling position, in case the name of the class is specified dynamically via an absolute type name.

      – The instance methods of local classes visible at the calling position, in case a reference variable with a reference to the class exists in the calling program.

      – All function modules in function groups

      – All subroutines in executable programs, module-pools, function groups and subroutine pools

      The last two points are the classical procedures already known before ABAP Objects.

      Kind regards

      Horst

      (0) 
  5. Arto Pihlaja

    Could you please edit this blog series and make it legible?

    In the meantime, for those that try to read this, copy the text to a separate file, add a <html> tag on top, and save with suffix .html

    Still, this series is great and certainly worth the maintenance!

    (0) 

Leave a Reply