Ansicht
Dokumentation

ABENSHM_AREA_BASIC_PROPERTIES - SHM AREA BASIC PROPERTIES

ABENSHM_AREA_BASIC_PROPERTIES - SHM AREA BASIC PROPERTIES

SUBST_MERGE_LIST - merge external lists to one complete list with #if... logic for R3up   Addresses (Business Address Services)  
This documentation is copyright by SAP AG.
SAP E-Book

- Basic Properties of Areas

An area has the following basic properties:

  • Area name
The name of an area. This is also the name of the generated global area class and is therefore unique across the system are followed. It is recommended that the naming conventions for global classes use the prefix "CL_".
  • Area root class
The area root class is a global shared-memory-enabled class that has to be assigned to an area when it is defined. A non-empty area instance version must contain at least one instance of the area root class as a root object, from which the other objects are referenced. The attribute ROOT of an associated area handle is generated as a reference variable with the static type of the area root class.
  • Client-dependent area
An area can be identified as client-dependent. In this case, an area instance of the area is identified by a client identifier and not just by its name. In client-dependent areas, the area class methods always refer to the current client when accessing an area instance. In client-dependent areas, these methods have the additional input parameter CLIENT, which enables explicit access to other clients. If automatic area building is possible, it is not possible to set locks by specifying the client explicitly. In methods where this makes sense, the value of constant CL_SHM_AREA=>ALL_CLIENTS can be passed to CLIENT to execute it on all clients. In the standard setting, the runtime-dependent area properties are client-dependent. The system does no check whether a specified client actually exists in the system.
  • Automatic area building
There are three ways to set the automatic area building. Either there is no automatic area building (None), or the building is carried out using the current user (Using the current user) or a system user (Using the system user). When building a new area automatically, a new area instance is created automatically at the time selected in the area build type. As a prerequisite, an area constructor class must be specified in the dynamic area properties and the area is bound to the . If automatic area building is enabled and an area build type with server start is selected, the area constructor is executed at server start.
The system user denotes a technical user. It has the profile parameter rdisp/server_startup/user. The parameter's format covers the client and the user name. Since release , the system user is not required in the system. In this case, the current user is not logged on and a space is set for the user name in the parameter. For the server start, a system user is already available in the system client. This user can be used to build client-independent areas. In case of client-dependent areas, a user in the corresponding client is necessary, i. e. a user must exist in the client with the name of the system user. If the user does not exist, the building of the area is terminated with the runtime error SYSTEM_SHMCONSTR_LOGON_FAILED up to release . Since release , the runtime error can only occur if the area is client-dependent and the client does not exist or is locked. The user is always logged on with the default language. If the area that is to be built should be language-dependent, the language must be specified in the area instance names at the beginning of the are constructor using SET LOCALE LANGUAGE. Since the system user does not have special authorizations, the implementation of the area constructor must not contain any authorization checks. The use of the following statements results in the runtime error SYSTEM_SHMCONSTR_ILL_STATEMENT:

: Since release , RFC calls in the area constructor are not supported any more. Necessary authorization checks must be carried out when accessing data in the shared object area. The addition FOR USER in an AUTHORITY-CHECK OBJECT statement is allowed in the constructor, however, specifying the system user with this statement also results in the runtime error SYSTEM_SHMCONSTR_ILL_STATEMENT.
The area constructor is always executed with the system user so that the constructor has the same behavior when executed at server start and in case of a read request. The point in time at which the area building and the execution of the are constructor is to take place can be specified in the runtime settings.
  • Transactional area
An area instance version of a transactional area is not active immediately after the removal of a change lock using the method DETACH_COMMIT of the area handle, but only after the next database commit instead. Between the time when the lock is removed and the database commit is set up, the area instance version is displayed as specified in the layout. No new change locks can be set on the area instance and any read locks access the previous active version. In non-transactional areas, the state of the area instance version is immediately set to active when the method DETACH_COMMIT is executed.
Transactional areas enable data or objects in the area instance versions to join such areas with database content. To ensure that the reference between database content and shared objects is not damaged, changes to the shared objects should be made only in contexts in which the database changes were also made in the current application. In updates, for example, any changes to the shared objects should only be made while the corresponding update functional module is executed.





ABAP Short Reference   PERFORM Short Reference  
This documentation is copyright by SAP AG.

Length: 8973 Date: 20240329 Time: 132317     sap01-206 ( 198 ms )