LESSON 46 LUW’S AND CLIENT/SERVER ARCHITECHERE

LUW’S AND CLIENT/SERVER ARCHITECHERE


An SAP logical unit of work (LUW) is a functionally complete set of steps within a business process in the R/3 System.

The process steps must be logically related.

SAP LUWs work on an all-or-nothing principle: Either all or none of its steps are carried out.

The business process to be mapped must be basic. For example, you would not have a single SAP LUW consisting of all of the steps between a customer processing an order and an invoice being produced. Instead, you would split this up into separate parts, each of which would then be represented in the R/3 System by its own LUW. What constitutes an "elementary" process depends on the overall process and how you have modeled it.

For further information, see the ABAP Editor Keyword documentation for the term transaction processing.

A database logical unit of work (LUW) is a non-separable sequence of database operations. At the beginning and end of the LUW, the database is in a consistent state.

The database LUW is either fully carried out by the database system, or is not carried out at all.

A database LUW is opened with every dialog step and by a database commit of the previous DB LUW.

The database LUW is closed with a database commit. It is only in the commit that the data is written to the database (after which it can no longer be reversed). Before the database commit, you can undo the changes using a database rollback. Here, the database is reset to the status that it had before the first change was made to the current DB LUW.

Data that has been written to the database permanently with a database commit cannot be rolled back.

Database LUWs allow you to encapsulate logically related actions from a business process. For example, when transferring sums of money in financial accounting, you must deduct an amount from one account and then add it to another account. Before and after the process, the data is consistent, but in between the two steps, it can be inconsistent.

The SAP R/3 System is based on the three-tier architecture of a client/server system. The three tiers are the database, application, and presentation server layers.

This architecture, along with the distribution of users' requests (user dispatching), leads to a highly efficient, cost-effective multi-user system.

The three-tier architecture means that a large number of users with low-cost desktop computers (with low performance) can be mapped to a small number of high-performance (and considerably more expensive) work processes on application servers. Each work process on an application server is assigned a work process on a high-performance database server.

Distributing user requests to work processes assigns individual clients at presentation server level to a work process for a particular period. In turn, the work process uses another work process in the database. After the work process has processed the user input in a dialog step, the user, along with the program context, is removed from the work process, which can then be used by another user.

The three-tier architecture is far more scalable than a "fat" client architecture, in which the Presentation and application levels run on one server. With three-tier architecture, the number of database users is considerably lower than the number of users active in the system. This has a positive effect on the behavior of the database.

The three-tier architecture of the R/3 System has certain consequences for process handling. When a work process is released for use by another user (client), an implicit database commit is triggered for the database process assigned to it (via a basis program).

Work processes on the application server and database are released before each user dialog. This Ensures that long user dialogs in which the system is "only displaying a screen" are not included in Database LUWs. The duration of the user interaction will be longer than the DB LUW duration.

Shorter database LUWs lead to less load on the database.

Implicit commits on the database are triggered whenever the work process has to wait.

This includes:

When the system sends a new screen
When the system sends a dialog message
When you make a synchronous remote function call (RFC)
When you use the CALL TRANSACTION or SUBMIT statement.

Using an SAP LUW to represent a business process chain usually involves user dialogs as well as the changes to the database. The aim of an R/3 transaction is to represent the information exchanged in the SAP LUW as an indivisible unit in the database. This means that an SAP LUW can only use a single database LUW.

Since SAP LUWs usually involve several database LUWs, you need to bundle the database changes in a single database LUW within your transaction.

LESSON 47 SAP LOCK CONCEPT

SAP LOCK CONCEPT:


If several users are competing to access the same resource or resources, you need to find a way of synchronizing the access in order to protect the consistency of your data.

Example: In a flight booking system, you would need to check whether seats were still free before making a reservation. You also need a guarantee that critical data (the number of free seats in this case) cannot be changed while you are working with the program.

Locks are a way of coordinating competing accesses to a resource. Each user requests a lock before accessing critical data.

It is important to release the lock as soon as possible, so as not to hinder other users unnecessarily.

Whenever you make direct changes to data on the database in a transaction, the database system sets corresponding locks.

The database management system (DBMS) physically locks the table entries that you want to change (INSERT; UPDATE, MODIFY), and those that you read from the database and intend to change (SELECT SINGLE FROM FOR UPDATE). Other users who want to access the locked record or records must wait until the physical lock has been released. In such a case, the ABAP program waits until the lock has been released again.

At the end of the database transaction, the database releases all of the locks that it has set during the transaction.

In the R/3 System, this means that each database lock is released when a new screen is displayed, since a change of screen triggers an implicit database commits.

To keep a lock set through a series of screens (from the dialog program to the update program), the R/3 System has a global lock table at the application server level, which you can use to set logical locks for table entries.

One application server contains this lock table and a special enqueue work process, which administers all requests for logical locks in the R/3 System. All logical lock requests of the R/3 System run using this work process.

You can also use logical locks to "lock" table entries that do not yet exist on the database (inserting new lines). You cannot do this with physical database locks.

For further information, see the ABAP Editor Keyword documentation for the term Locking.

Logical locks are generated when an entry is written in the lock table. You use function modules to do this.

You can only set a lock if the relevant table entry is not already locked.

The SAP transaction receives information on the success of a lock request from a return code sent via the EXCEPTION interface of the function module. In other words, the control is returned to the program using the function module. The ABAP program does not need to wait.

The SAP transaction can react appropriately by analyzing the return code.

Another user cannot gain access to work with the same table entries that are already locked.

Depending on the bundling technique in use for database updates), the program must delete the lock entries it generated using a lock module, or have them deleted indirectly (see unit Organizing Database Updates).

If the user terminates the program that generated the lock entries (usually a dialog program), the locks are released automatically (implicitly). You can do this by entering /n in the command field, or with the statements LEAVE PROGRAM, LEAVE TO TRANSACTION, and 'A' or 'X' Messages.

When you call an ENQUEUE function module, the dialog program tries to generate a lock entry.

The export parameters identify the table entry (or entries) that you want to lock.
The program that generates the locks (usually dialog program) analyzes the return code for lock requests and reacts accordingly.

If the lock could not be set; you should normally output an error message.

At the end of the dialog program, you can use the corresponding DEQUEUE function module to delete the entries from the lock table.

DEQUEUE function modules have no exceptions. If you try to release an entry that is not locked, this has no effect.

If you want to release all of the locks that you have set, at the end of your dialog program, you can use the function module DEQUEUE_ALL.

The lock table contains the lock arguments for each table (for lock arguments, see the following slide).

To display the lock table, use transaction SM12.

The entries in the lock table are standard. Locks are always set using the values of the key fields in a table. These form the lock argument.

You pass the values for the lock argument to the lock modules via their interface (function module IMPORT parameters).

If you fail to set any of these parameters, the system interprets it generically, that is, the lock is set for all table lines that meet the criteria specified in the other parameters. The client parameter is an exception to this rule, where the default client SY-MANDT applies.

Lock entries must be assigned to a lock mode.

There are three different lock modes:

Mode 'E' for write locks: This is set if you want to write data to the database (change, create, or delete).


Mode 'S' for read locks: This is set if you want to ensure that the data, which you are reading from the database in your program, is not changed by other users while the program is running. You do not want to change the data itself in your program.

Mode 'X' for write locks: Like mode 'E', mode 'X' is used for writing data to the database. The technical difference between mode 'X' and mode 'E' is that locks of mode 'X' are not accumulated while a program is being executed. (For further details, see the following pages).

If someone tries to lock the same data record again with a second program (different user), the various lock modes take effect as follows:

Write locks ('E' or 'X') mean that any lock attempts from other users are refused, irrespective of the mode in which the lock is attempted.

If a data record is locked in mode 'S' (shared), further locks in mode 'S' may be set by other users.

Lock attempts in other lock modes ('E' or 'X') are refused.

If you want to try to lock a data record more than once while a program is running (for example using a function module that you call up, which sets locks itself), the lock system reacts in the following way:

Mode 'E' write locks are not refused. Instead, a cumulative counter is incremented. The same applies to read locks (mode 'S').

If a data record is locked in mode 'E', a lock request generates a second lock, which is marked as a read lock.

If a data record is locked in mode 'S' and no further read locks are set by other users, a lock attempt in mode 'E' is possible. This generates a second entry in the lock table (for mode 'E').

If a data record is locked in mode 'X', all further lock requests are refused.

If you want to ensure that you are reading up-to-date data in your program (with the intention of changing and returning this to the database), you should use the following procedure for lock requests and database accesses in your program:

First, lock the data that you want to edit.

Then read the current data from the database.

In the next step, process (change) the data in your program and write this to the database.

In the final step, release the locks that you set at the beginning.

This procedure ensures that your changes run fully with lock protection and that you only read data that has been changed consistently by other programs (provided that these also use the SAP lock concept and follow the procedure described here).

Lock modules are created for lock objects and not tables.

Lock objects are maintained in the dictionary. Customer lock objects must begin with "EY" or "EZ".

A lock object is a logical object composed of a list of tables that are linked by foreign key Relationships. Lock modules are generated for these objects and enable common lock entries to be set for all tables contained in the lock object. This allows combinations of table entries to be locked.

The list of tables for a lock object consists of a primary table. Further table entries are referred to as secondary tables. Only tables with foreign key relationships to the primary table can be used as secondary tables.

With lock objects, you can assign different names for the parameters that describe the fields of the lock arguments for the lock modules. The names of the table fields (key fields of the tables) are proposed by the system.

You can specify the lock mode (a write lock 'E' or 'X' or a read lock 'S') for each table. These function as default values for the lock modules.

After you have assigned tables and default lock modes, lock objects must be generated.

When you activate a lock object, the system generates an ENQUEUE and a DEQUEUE function module.

These have the names ENQUEUE_ and DEQUEUE_ respectively.

If you want to ensure that you are reading current data in your program (with the intention of changing and returning this to the database), you should use the following procedure in your program for lock requests and database accesses:

1. Lock the data that you want to edit.
2. Read the current data from the database.
3. Process (change) the data in your program and write this to the database.
4. Release the locks that you set at the beginning.

This procedure ensures that your changes run fully with lock protection and that you only read data, which has been changed consistently by other programs (with the restriction that these are also using the SAP lock concept and following the procedure described).

If you change the order of the four steps to Read -> Lock -> Change -> Unlock, you run the risk that the data read by your program will not be up to date. Your program can read data before another user's program writes changes to the database. This means that a user of your program will make decisions for entries that are not based on up-to-date data from the database. For this reason, you should always follow the recommended procedure.

Requesting a lock from a program is a communication step with lock administration. The Communication step requires a certain time interval. If your program sets locks for several objects, this interval occurs more than once.

By using so-called local lock containers, you can reduce these communication intervals with lock administration. To do so, collect the required lock requests of your program and send them together to lock administration.

The locks (delayed execution) can be collected when the lock modules are called. For this purpose, qualify the IMPORT parameter_collect with 'X'. The data transferred via the lock module interface is then registered in a list (lock container) as a lock request that needs to be executed.

The lock container can be terminated using the FLUSH_ENQUEUE function module and sent to lock administration.

When the lock orders of a lock container can be executed, the lock container is deleted.

If one of the locks in a container cannot be set, the function module FLUSH_ENQUEUE triggers the exception FOREIGN_LOCK. In this case, none of the registered lock requests is executed. The registered locks remain in the lock container.

You can delete the contents of an existing lock container with the function module
RESET_ENQUEUE.

The specified function modules have release status internally-released.

LESSON 48 ORGANIZING DATA BASE UPDATES

ORGANIZING DATA BASE UPDATES:


If your transaction executes database updates from the dialog program, you must bundle all of your database updates into a single dialog step (usually the last). This is the only way to ensure that your database changes are processed on the all-or-nothing principle.

With database changes from the dialog program, you must save the data you want to change in the global program data until the database changes are made. This data is written to the database with the status it had for the last dialog step.

With database changes from the dialog, your program must set and release SAP locks itself.

The following order is recommended:

Lock data
Read data
Update data on the database
Release locks

Note that the lock entries must be deleted by a program. To do so, you can either call up the lock modules of the object for releasing DEQUEUE_ or the function module DEQUEUE_ALL. For more detailed information, consult the function module documentation.

Database updates from the dialog can be executed in bundled form by using the special subroutine technique PERFORM ON COMMIT.

The statement PERFORM ON COMMIT registers the subroutine that has been called up. This will not be executed until the next COMMIT WORK statement is reached.

If the database updates are encapsulated in the subroutines, they can be separated from the program logic and relocated to the end of the LUW processing.

Each subroutine registered with PERFORM ON COMMIT is only executed once per LUW. calls can be made more than once (no errors); the subroutine, however, is only executed once.

From release 4.6 onward nested PERFORM ON COMMIT calls lead to a runtime error.

The COMMIT WORK statement carries out all subroutines registered to be executed and triggers a database commit (ends the DB LUW).

Unlike normal subroutines, those that you call using the ON COMMIT addition do not have an interface. They work instead with global data, that is, the values of the data objects at the point where the subroutine is actually run. This can also include Imports from memory.

The PERFORM ... ON COMMIT technique can also be used in the update. This will be discussed later.

For further information, see the ABAP Editor Keyword documentation for the term PERFORM.

Update techniques allow you to separate user dialogs from the database changes. Both are executed by different programs, which generally run in different work processes.

You work with a program that manages the user dialogs. It is referred to as a dialog program.

You use a so-called update program that updates the data received by the dialog program on the database. No dialogs run in the update programs.

Step 1: The dialog program receives the data changed by the user and writes it to a special log table.

The entries in this table function as requests. The data contained in the log table will be written to the database later by the update program.

A dialog program can write several entries to the log table.

The entries in the log table represent an LUW, in other words they will either be executed on the database together or not at all (all-or-nothing principle).

Step 2: The dialog program completes the logical data packet that was written to the log table. The SAP LUW finishes in the dialog part and informs the Basis system that a packet needs to be updated.

Step 3: A basis program reads the data associated with the LUW from the log table and supplies it to the update program.

Step 4: The update program accepts the data transferred to it and updates the database entries.

Step 5: If the update program runs successfully, a Basis program deletes all entries for the LUW from the log table.

In the event of an error, the entries remain in the log table and are flagged as errored.

The option of informing users by mail that an update action has failed can be set using the profile parameters rdisp/vb_mail_user_list and rdisp/vbmail.

The parameter rdisp/vbmail can be set to '0' (no mail is sent in the event of an error) or '1' (a mail is sent in the event of an error).

The rdisp/vb_mail_user_list parameter setting specifies who will be informed in the event of an error (rdisp/vbmail = 1) ($ACTUSER informs the user who generated the data record to be updated).

The monitor transaction for update orders is SM13.

The dialog program and the update program can be linked in various ways:

Asynchronously
Synchronously
Via a local update

Technical implementation of the update concept requires a so-called update program as well as the program that manages the user dialog. The update program tasks are carried out by special function modules called update modules.

Create an update function module by choosing the processing radio button property 'update module'.

Update modules, like other function modules, have an interface for transferring data. The interface for update function modules only includes IMPORTING and TABLES parameters. These must be typed using reference fields or structures.

Export parameters and exceptions are ignored in update modules.

The function module contains the actual database update statements.
The entries in the log file are generated from the dialog program. They are generated by calling up the associated update function module. The function module must be called using the addition IN UPDATE TASK. This ensures that the module is not executed immediately. Instead, the current data from the function module interface is written to the log table.

For every CALL FUNCTION ... IN UPDATE TASK statement in the dialog program, the system generates an entry in the log table containing the name of the update function module and the associated parameters.

All of the update requests in an SAP LUW are stored under the same update key (VB key). The update key is a unique key.

When the system reaches the next COMMIT WORK statement, a log header is generated for the corresponding log entries, concluding the set of update entries for that SAP LUW. The log header contains information on the dialog program that wrote the log entries, as well as information on the update modules to be executed.

As well as the header entry, the ABAP command COMMIT WORK ensures that the dispatcher process is informed about the availability of a further update packet.

In a dialog consisting of several steps, you can store multiple entries in the update log table that are then processed following the ABAP COMMIT WORK command.

However, you may also need to delete the update requests of the current SAP LUW using a ROLLBACK WORK statement.

In a ROLLBACK WORK statement, the system:

Deletes all form routines registered using PERFORM ON COMMIT
Deletes all database update requests from the log
Triggers a rollback on the database, followed by a database commit
Starts a new SAP LUW

With relation to database changes already completed in the dialog, the ROLLBACK WORK statement means that all changes in the current database LUW are undone.

The ROLLBACK WORK statement deletes all lock entries generated up to now from the dialog program.

The ROLLBACK WORK statement does not affect the program context, in other words all data objects (program-specific objects and objects from function groups that may be used) remain unchanged, and they are NOT reset.

You can generally only reset the data objects of your program by ending the dialog program.
Therefore, you should not use the ROLLBACK WORK statement directly. Instead, trigger an implicit rollback by sending a termination message (type A). This ensures that all of the data from the program is also reset when the program terminates.

The task of an update module is to pass the requests for database updates to the database and to evaluate their return codes.

If the database cannot successfully complete an update; the update function module must be able to react.

If you want to trigger a database rollback in the update task, you can use a termination message. This triggers an implicit database rollback.

The rollback ends the update task. The log entry belonging to the SAP LUW is flagged as containing an error. The termination message is also entered in the log.

The system sends an express mail to the relevant user, telling him or her that the update was unsuccessful. You can examine the log entry by using Transaction SM13.

You may not use the explicit ABAP statements COMMIT WORK or ROLLBACK WORK in an update module.

If your program is to run using locks, you must record the locks in the lock table. These are inherited by the update modules with the ABAP command COMMIT WORK and can then no longer be accessed by the dialog program.

To ensure that the update modules run with the protection of locks, the lock entries must not be released before the COMMIT WORK.

You do not need to release the locks explicitly in the update modules, since they are automatically released at the end of the update process by a basis program.

The locks are also released if one of the update modules triggers a database rollback by sending a termination message.

If the update modules allow failed update requests to be reprocessed (see V1 update), you should note that the data in the database tables at the point of reprocessing may be different from that at the point of the failed update attempt. Reprocessing failed update requests is only useful if the data to be updated is not dependent on the database status (e.g. writing of a document failed because of a table space overflow).

Failed update requests are reprocessed without locks.

In asynchronous update, the dialog program and update program run separately.
The dialog program writes the update requests into the log table VBLOG in the database.

You conclude the dialog part of the SAP LUW with the COMMIT WORK statement. A new SAP LUW immediately starts in the dialog program, which can carry on processing user dialogs without interruption. The dialog program does not wait for the update program to finish.

The update program is run on a special update work process. This need not be on the same Server as the corresponding dialog work process.

The SAP LUW that began in the dialog program is continued and then closed by the update Program.

The log table VBLOG can be implementing as a cluster file in your system, or be replaced with the transparent tables VBHDR, VBMOD, VBDATA, and VBERROR.

Asynchronous updates are useful in transactions where the database updates take a long time and the "perceived performance" by the shorter user dialog response time is important.

Asynchronous update is the standard technique for dialog processing.

The entries that have a HEADER can be analyzed in SM13.

In local update, the update functions are run on the same dialog process used by the dialog program containing the COMMIT WORK statement.

To do this, you must include the SET UPDATE TASK LOCAL statement in the dialog program.
The effect of this is that update requests are kept in main memory rather than being written into table VBLOG in the database.

When the system reaches the COMMIT WORK statement, the corresponding update modules are processed in the dialog work process currently being used by the dialog program. If all of the update modules run successfully, a database commit is triggered. If not, a database rollback occurs.

Once the update function modules have been processed, the dialog program resumes with a new SAP LUW.

The SET UPDATE TASK LOCAL flag can only be set if no other update requests were generated for the same LUW before the program was called up.

The SET UPDATE TASK LOCAL flag is effective until the next COMMIT WORK or ROLLBACK WORK command.

With synchronous updates, the dialog program waits for the end of the update modules. The dialog program does not begin to process the new SAP LUW until the update modules have terminated.

To switch from asynchronous to synchronous update, use the AND WAIT addition in the COMMIT WORK statement.

The entries that have a HEADER can be analyzed in SM13.

Asynchronous update is useful in transactions where subsequent user dialogs do not depend on the database updates being made immediately. Once the update task has been called, control returns directly to the user.

Local update is particularly useful for processing dialog transactions in the background. There is no contact with the database table VBLOG, and if the program is running alone on the server, local update is faster than either synchronous or asynchronous update. If, as is the usual case, several users are using the server, the speed of the program depends on the total server load.

Synchronous update is useful in transactions where you want to use the advantages of update techniques (logging, opportunity to reprocess failed update requests), but where subsequent user dialogs nevertheless do depend on the results of the update. One particular application for this technique is in "transactions within transactions" - where one transaction uses other transactions as modularization units (CALL TRANSACTION ).

When you use this method, you can determine in the call the update technique that you want the transaction to use. For further information, see the keyword documentation in the ABAP Editor for the term CALL TRANSACTION.

Update function modules can be separated into two groups. The group determines when the function module is processed: Function modules that are classified as V1 can be further divided into two subclasses: Start immediately or Start immediately, no restart. V2 function modules are processed asynchronously after all V1 update modules have finished running.

If you have used the Start immediately (V1) option, you can update any records that contained errors manually, using Transaction SM13. If you use the Start immediately, no restart (V1) option, this is not possible. V2 update function modules (Start delayed) can always be manually updated.

V1 update function modules do not normally run using the SAP lock concept. In other words, the V1 update program is executed with the protection of the locks from the dialog program.

Any lock entries are released at the end of the V1 update. V2 update function modules always run without logical locks.

You can also classify an update module using attribute 'Coll. run' (collective run). This option is used SAP internal only (special form of V2 update, asynchronously, start via program RSM13005).

The flow diagrams discussed up to now all deal with V1 updates.

Update requests for V2 update modules are also generated by the dialog program.

V1 update modules generate update requests in table VBLOG in synchronous and asynchronous update, and in main memory in local update.

V2 update modules generate entries in VBLOG and always run asynchronously.

V1 update modules are handled by the system with priority and are executed before the V2 update requests.

V1 updates can be performed synchronously, asynchronously, or locally.

V2 update function modules are not processed until all V1 update function modules have been successfully processed.

The V2 update function modules run in a separate DB LUW. They are executed in a V2 update work process. If there are no V2 update work processes set up in your system, the V2 update function modules run in a V1 update work process.

Once all of the V2 update function modules have been executed successfully, the V2 update requests are deleted from VBLOG.

If an error occurs in a V2 update function module to which the function module reacts with a termination error message, the system triggers a database rollback. All of the V2 changes in the SAP LUW are undone and an error flag is set in table VBLOG for all of the V2 update requests.

V2 update function modules run without SAP locks.

The division between V1 and V2 update function modules allows you to set 'high priority' and 'low priority' updates.

V2 update function modules are used for low-priority tasks, such as writing statistics to the database.

The locks generated in the dialog program are usually inherited by the V1 update modules when the update takes place. This is controlled by the SCOPE interface parameter of the lock modules. When SCOPE = 2, the V1 update programs inherit the locks that are set in the dialog program.

2 is the default setting for SCOPE when you call a lock module.

You do not need to release the locks explicitly in your program, since they are automatically released at the end of the V1 update process.

The locks are also released if one of the V1 update modules triggers a database rollback by sending a termination message.

An SAP LUW maps updates, which are logically related and usually involve several dialog steps, to a database LUW. The database updates are encapsulated via update modules.

SAP LUWs are supported specifically by R/3:

Locks (Scope = 2)

The CALL FUNCTION IN UPDATE TASK call mechanism

The command COMMIT WORK

Type 'A' or 'X' dialog messages.

An SAP LUW can be divided into three phases (three-phase model).

Dialogs, user entries, and their input checks take place in phase 1. Calls of update modules are not allowed here, since they might be registered more than once during an error dialog (E message).

Phase 1 ends when the first update module is called. The data to be updated must be held in global program data during phase 1.

Preparations for database updates take place in phase 2. Phase 2 begins when the first update module is called and ends with the COMMIT WORK statement. The system must now respond to any errors with a type 'A' or 'X' dialog message. The COMMIT WORK that concludes phase 2 should only be set at the top level if call hierarchies are used, since the lower-level modularization units in the hierarchy are not aware of the status of the program context.

The database updates are performed in phase 3. The system must always respond to any errors in phase 3 with a type 'A' or 'X' dialog message. This leads to a ROLLBACK of the complete database LUW as well as a termination of the update.

Local update processing is activated using the ABAP command SET UPDATE TASK LOCAL. The update type can only be changed if it is processed before the first update module is called.

With local updates, the update modules are executed in the dialog work process that is currently performing the SAP LUW.

As is the case with synchronous updates; the user must wait while the update modules are being executed.

Local updates should be used for:
Transactions that are carried out in the background (batch) (CALL TRANSACTION USING)
Exception: If UN buffered number assignments and higher parallel processing is requested at the same time.

Dialog transactions with very few database changes (3 - 5 statements) for which the dialog behavior is not critical.

Note that the fewer the number of users making changes simultaneously, the better the response time of the database.

Synchronous updates are triggered by the ABAP statement COMMIT WORK AND WAIT. With a synchronous update, the update modules are executed in an update work process.

Unlike asynchronous updates, the dialog part of the transaction is stopped while the update modules are being executed.

The success or failure of the update is displayed in system field sy-subrc once the update has been completed.

For every action on the database that prompts table updates, the record to be changed is locked physically by the database. The same applies if you are reading with SELECT ... FOR UPDATE.

Other users cannot change the same data for the duration of the lock.

To reduce the lock duration on the database, you should use the following rule to program the database updates carried out by the update modules:

First, new table entries should be created. These present the smallest 'problem' for the other users.

You should then perform table updates that are not critical to performance. As a rule, these are the tables that are accessed 'simultaneously' by as few users as possible.

Tables that are central resources in the system (which many users access at once) should always be changed as late as possible.

To lock the central tables (performance critical) for as short a time as possible, you can use PERFORM uprog ON COMMIT in the update.

For this purpose, encapsulate the changes to the central tables in FORM routines and call these up in the update using PERFORM ON COMMIT. The FORM routines are then not executed until the last update module has been processed.

After the last update module has been processed; a program executes the ABAP command COMMIT WORK, which then performs the FORM routines registered in the update

LESSON 50 AUTHORISATION CHECKS

AUTHORISATION CHECKS


The authorization concept uses authorization objects and authorizations.

Authorization objects are repository objects and are maintained in the ABAP Dictionary. They consist of a name and up to ten logically-related fields that are used in the authorization check. Authorization objects define a logical grouping of fields whose values will be used in the authorization check. The above example uses the authorization object S_CARRID, which combines airline (CARRID) and activity (ACTVT, with the four possible values create, change, display, and delete).

An authorization for an authorization object is a concrete set of values for the fields of an Authorization object.

Authorizations are grouped by profiles (business activities), which are assigned to users in their user master records.

For further information, see the ABAP Editor Keyword documentation for the term Authorization concept.

In an authorization check, you specify the object and values that the user needs in an authorization in his or her user master record.

In our example, we want to check whether the user has authorization for the object S_CARRID in which the field CARRID (airline) has the value 'LH' and the field ACTVT (activity) has the value '03' for 'display'. The activity codes are listed in tables TACT and TACTZ and are also documented in the relevant authorization objects.

In the AUTHORITY CHECK, you must specify all fields of the object, otherwise, the return code will be unequal to zero. If you do not want to perform a check for one field, enter DUMMY in the field.

The most important return codes for the AUTHORITY-CHECK statement are:
0: The user has an authorization with the correct values.
4: The user does not have the required authorization.
8: You did not list all of the fields in the authorization object, so the check was unsuccessful.

For a full list of all return codes, see the keyword documentation in the ABAP Editor for AUTHORITY-CHECK.

You can only enter single fields after the FIELD addition, not selection tables. However, there are function modules that can perform an AUTHORITY-CHECK for all values in a selection table.

Use the model for the AUTHORITY-CHECK in the ABAP Editor. This model inserts all names of the authorization object fields.

The R/3 System contains tools that help you to administer authorizations and assign them to user master records.

Authorizations are always assigned to a user using authorization profiles.

Authorization profiles consist of a set of authorizations and are used to administer authorizations that are required for a particular activity (work center description).

When you call a transaction using its transaction code, a system program starts to perform automatic authorization checks.

Firstly, a system program checks whether the transaction is listed in the table TSTC and whether it is locked. Using the entries in the TSTC table, the system program determines the name of the ABAP program and the number of the first screen.

Next, the system program uses the authorization object S_TCODE to see whether the user is authorized to use the transaction.

After that, it checks whether a particular field of an authorization object is assigned to the Transaction. The user calling the transaction must have an authorization for the authorization object listed in table TSTCA in his or her user master record that also contains the values Specified in table TSTCA.

If the user has this authorization, the system starts the transaction. If not, the transaction is not started, and the system displays an error message.

After this, the authorization checks in the ABAP program (AUTHORITY-CHECK) are processed.

LESSON 49 COMPLEX LUW PROCESSING

COMPLEX LUW PROCESSING:

In an ABAP program, there are two ways of executing another program synchronously:
Terminate the current program and start the other program (SUBMIT , LEAVE
TO TRANSACTION )

Call the other program without terminating the other program. The calling program is
Interrupted, and the system returns to it when the program that it has called is finished (CALL TRANSACTION, SUBMIT AND RETURN, CALL FUNCTION).

You can only use SUBMIT and SUBMIT AND RETURN to start executable programs (program type 'Executable program', formerly program type '1').

You use LEAVE TO TRANSACTION and CALL TRANSACTION to start programs that have a transaction code.

You use CALL FUNCTION to execute a function module.

The executed commands differ with regard to the visibility of program data in the calling program and the called program, and in their behavior with regard to LUW processing.

With the SUBMIT statement, you start programs that are directly executable programs.

The addition VIA SELECTION-SCREEN is used to send the selection screen of the program (if the program has a standard selection screen).

To return to the calling program after the program has finished, use the addition AND RETURN.

Calling an executable program allows you to use a logical database to read data.

For further information, see the keyword documentation in the ABAP Editor for SUBMIT.

You can execute ABAP programs with a transaction code using the statement CALL TRANSACTION . When the program that you called has terminated, the system continues processing the calling program.

If the transaction that you call in the CALL TRANSACTION statement uses update techniques; you can determine which technique it should use (synchronous or asynchronous) using the FUNCTION parameter in the call.

To exit an ABAP program, use the LEAVE PROGRAM statement. If you use this statement in a program that you have called using CALL TRANSACTION or SUBMIT AND RETURN, the system returns to the calling program. Otherwise, the system returns to the application menu from which you started the program.

To initiate a transaction with the transaction code , use the LEAVE TO TRANSACTION statement. This does not allow you to return to where the transaction was called from.
This statement has the same effect as entering /n in the command field.

For further information, see the keyword documentation in the ABAP Editor for CALL and LEAVE.

You can encapsulate dialogs in reusable function modules.

If you call up a screen within a function module, this screen belongs to the program of function group SAPL of the function module.

ABAP memory

A logical memory model illustrates how the main memory is distributed from the view of executable programs. A distinction is made here between external sessions and internal sessions .

An external session is usually linked to an R/3 window. You can create an external session by choosing System/Create session, or by entering /o in the command field. An external session is broken down further into internal sessions. Program data is only visible within an internal session. Each external session can include up to 20 internal sessions (stacks).

Every program you start runs in an internal session.

All "squares" with rounded "corners" displayed in the status diagram represent a set of data objects in the main memory.

The data in the main memory is only visible to the program concerned.

CALL TRANSACTION and SUBMIT AND RETURN open a new internal session that forms a new program context. The internal sessions in an external session form a memory stack. The new session is added to the top of the stack.

When a program has finished running, the top internal session in the stack is removed, and the calling program resumes processing.

The same occurs when the system processes a LEAVE PROGRAM statement.

LEAVE TO TRANSACTION removes all internal sessions from the stack and opens a new one containing the program context of the calling program.

The ABAP memory is initialized after the program is called. In other words, you cannot transfer any data to a program called with LEAVE TO TRANSACTION via the ABAP memory.

SUBMIT replaces the internal session of the program performing the call with the internal session of the program that has been called. The new internal session contains the program context of the called program with which it is performed.

When a function module is called, the following steps are executed:

A check is made to establish whether your program has called a function module of the same function group previously.

If this is not the case, the system loads the associated function group to the internal session of the calling program as an additional program group. This initializes its global data.

If your program used a function module of the same function group before the current call, the function module that you have called up at present can access the global data of the function group. The function group is not reloaded.

Within the internal session, all of the function modules that you call from the group access the global data of that group.

If, in a new internal session, you call a function module from the same function group as in internal session 1, a new set of global data is initialized for the second internal session. This means that the data accessed by function modules called in session 2 may be different from that accessed by the function modules in session 1.

You can call function modules asynchronously as well as synchronously. To do so, you must extend the function module call using the addition STARTING NEW TASK ''. Here, '' is a symbolic name in the calling program that identifies the external session, in which the called program is executed.

Function modules that you call using the addition STARTING NEW TASK '' are executed independently of the calling program. The calling program is not interrupted.

To make function modules available for local asynchronous calls, you must identify them as executable remotely (processing type: Remote-enabled module).

For further information, see the keyword documentation in the ABAP Editor for CALL FUNCTION.

There are various ways of transferring data between programs that are running in different program contexts (internal sessions).
You can use:

(1) The interface of the called program (standard selection screen, or interface of a
subroutine, function module, or dialog module)
(2) ABAP memory
(3) SAP memory
(4) Database tables
(5) Local files on your presentation server.

For further information about transferring data using database tables and the shared buffer, refer to the keyword documentation in the ABAP Editor for the terms EXPORT and IMPORT.

For further information about transferring data between an ABAP program and your presentation server, refer to the documentation for the function modules WS_UPLOAD and WS_DOWNLOAD.

Function modules have an interface, which you can use to pass data between the calling program and the function module itself (there is also a comparable mechanism for ABAP subroutines). If a function module supports RFC, certain restrictions apply to its interface.

If you are calling an ABAP program that has a standard selection screen, you can pass values to the input fields. There are two options here:
By using a variant of the standard selection screen in the program call
By passing actual values for the input fields in the program call

If you want to call a report program without displaying its selection screen (default setting), but still want to pass values to its input fields, there is a variety of techniques that you can use.

The WITH addition allows you to assign values to the parameters and select-options fields on the standard selection screen.

If the selection screen is to be displayed when the program is called, use the addition: VIA SELECTION-SCREEN.

Use the pattern button in the ABAP Editor to insert a program call via SUBMIT. The structure shows you the names of data objects that you can complete with the standard selection screen.

For further information on working with variants and further syntax variants for the WITH addition, see the key word documentation in the ABAP Editor for SUBMIT.

You can use SAP memory and ABAP memory to pass data between different programs.

The SAP memory is a user-specific memory area for storing field values. It is available in all of the open sessions in a user's terminal session, and is reset when the terminal session ends. You can use its contents as default values for screen fields. All external sessions can access SAP memory. This means that it is only of limited use for passing data between internal sessions.

The ABAP memory is also user-specific, and is local to each external session. You can use it to pass any ABAP variables (fields, structures, internal tables, complex objects) between the internal sessions of a single external session.

Each external session has its own ABAP memory. When you end an external session (/i in the command field), the corresponding ABAP memory is released automatically.

To copy a set of ABAP variables and their current values (data cluster) to the ABAP memory, use the EXPORT TO MEMORY ID statement. The (up to 32 characters) is used to identify the different data clusters.

If you repeat an EXPORT TO MEMORY ID statement to an existing data cluster, the new data overwrites the old.

To copy data from ABAP memory to the corresponding fields of an ABAP program, use the IMPORT FROM MEMORY ID statement.

The fields, structures, internal tables, and complex objects in a data cluster in ABAP memory must be declared identically in both the program from which you exported the data and the program into which you import it.

To release a data cluster, use the FREE MEMORY ID statement.

You can import just parts of a data cluster with IMPORT, since the objects are named in the cluster.

In the SAP memory, you can define memory areas (SET/GET parameters, or parameter IDs), which you can then address by a name of up to 20 characters.

You can fill these memory areas either using the contents of input/output fields on screens, or using the ABAP statement:
SET PARAMETER ID '' FIELD .
The memory area with the name now has the value .

You can use the contents of a memory area to display a default value in an input field on a screen.

You can also read the memory areas from the SAP memory using the ABAP statement GET PARAMETER ID FIELD . The field then contains the value from parameter .

The link between an input/output field and a memory area in SAP memory is inherited from the data element on which the field is based. You can enable the set parameter or get parameter attributes in the input/output field attributes.

Once you have set the Set parameter attribute for an input/output field, you can fill it with default values from SAP memory. This is particularly useful for transactions that you call from another program without displaying the initial screen. For this purpose, you must activate the Set parameter functionality for the input fields of the first screen of the transaction.

You can:

(1) Copy the data that is to be used for the first screen of the transaction to be called to the parameter ID in the SAP memory. To do so, use the statement SET PARAMETER immediately before calling the transaction.
(2) Start the transaction using CALL TRANSACTION or LEAVE TO
TRANSACTION . If you do not want to display the initial screen, use the AND
SKIP FIRST SCREEN addition.
(3) The system program that starts the transaction fills the input fields that do not already have default values and for which the Get parameter attribute has been set with values from SAP memory.

The Technical information for the input fields in the transaction you want to call contains the names of the parameter IDs that you need to use.

Parameter IDs should be entered in table TPARA. This happens automatically if you create them via the Object navigator.

Programs that you call using the statements SUBMIT , LEAVE TO TRANSACTION , SUBMIT AND RETURN, or CALL TRANSACTION run in their own SAP LUW, and update requests receive their own update key.

When you use SUBMIT and LEAVE TO TRANSACTION , the SAP LUW of the calling program ends. If no COMMIT WORK statement occurred before the program call, the update requests in the log table remain incomplete and cannot be processed. They can no longer be executed. The same applies to inline changes that you make using PERFORM … ON COMMIT.

Data that you have written to the database using inline changes is committed the next time a new screen is displayed.

If you use SUBMIT AND RETURN or CALL TRANSACTION to insert a program and then return to the calling program, the SAP LUW of the calling program is resumed when the called program ends. The LUW processing of calling and called programs is independent.

In other words, inline changes are committed the next time a new screen is displayed. Update requests and calls using PERFORM ... ON COMMIT require an independent COMMIT WORK statement in the SAP LUW in which they are running.

Function modules run in the same SAP LUW as the program that calls them.

If you call transactions with nested calls, each transaction needs its own COMMIT WORK, since each transaction maps its own SAP LUW.

The same applies to calling executable programs, which are called using SUBMIT AND RETURN.

The statement CALL TRANSACTION allows you to

Shorten the user dialog when calling using CALL TRANSACTION USING .

Determine the type of update (asynchronous, local, or synchronous) for the transaction called. For this purpose, use the addition CALL TRANSACTION USING UPDATE 'update_mode', where update_mode can have the values a (asynchronous), L (local), or S (synchronous).

Combining the two options enables you to call several transactions in sequence (logical chain), to reduce their screen sequence, and to postpone processing of the SAP LUW 2 until processing of the SAP LUW 1 has been completed.

When you call a function module asynchronously using the CALL FUNCTION STARTING NEW TASK ' ' statement, it runs in its own SAP LUW.

Programs that are executed with a SUBMIT AND RETURN or CALL
TRANSACTION statement starts their own LUW processing. You can use these to perform nested (complex) LUW processing.

You can use function modules as modularization units within an SAP LUW.

Function modules that are called asynchronously are suitable for programs that allow parallel processing of some of their components.

All techniques are suitable for including programs with purely display functions.

Note that a function module called with CALL FUNCTION STARTING NEW TASK is executed as a new logon. It, therefore, sees a separate SAP memory area. You can use the interface of the function module for data transfers.
Example: In your program, you want to call a display transaction that is displayed in a separate window (amodal). To do so, you encapsulate the transaction call in a function module, which you set as to Remote-enabled module. You use the function module interface to accept values that you write to the SAP memory. You then call up the transaction in the function module using CALL TRANSACTION AND SKIP FIRST SCREEN. You call the function module itself asynchronously.

Type ‘E' locks for nested program calls may be requested more than once from the same object. This behavior can be described as follows:
Lock entries from function modules called synchronously increment the cumulative counter, And are therefore successful.
Lock entries from programs called with CALL TRANSACTION or SUBMIT

AND
RETURN is refused. The object to be locked by the called program is displayed as already Locked by another user.

Programs that you call using SUBMIT or LEAVE TO TRANSACTION cannot come into conflict with lock entries from the calling program, since the old program ends when the call is made. When a program ends, the system deletes all of the lock entries that it had set.

Lock requests belonging to the same user from different R/3 windows or logons are treated as lock requests from other users.