Adding multiple messages in MIGO transaction via MB_CHECK_LINE_BADI

作者：郑德鼎约 6 分钟阅读更新日期：2024-02-22 2 年前更新标签：ABAP, MM, 开发, 物料管理

Ankit Maskara

November 21, 2018 3 minute read

524,852

Dear Community,

In this blog I would like to share an innovative approach to a very common problem of displaying multiple messages on line item checks in MIGO transaction.

The solutions explored included implementation of BADI’s – MB_MIGO_BADI and MB_CHECK_LINE_BADI. Details are below –

MB_MIGO_BADI – As most of us would know that this BADI is provided for the sole purpose of addition of custom sub screens to MIGO Transaction. Even though this BADI has a CHECK_ITEM method to return multiple messages (to ET_BAPIRET2) but it has a limitation that only five active implementations of this BADI can be there in any system. So, this is not a foolproof solution. So, I needed to look at alternate ways.

MB_CHECK_LINE_BADI – I explored this and implemented CHECK_LINE method. Then it was observed that this BADI is generally only used to display a single message to application log that too is issued via the MESSAGE statement.

But the requirement was of mutliple messages so, there was trouble.

Further debugging of standard code for SAPLMIGO, I realized that we have the application log handler in a private variable P_LOG_HANDLE of local class – LCL_MIGO_LOG but unfortunately this was not accessible in the CHECK_LINE method of MB_CHECK_LINE_BADI. One way could have been to use ABAP Memory and Export the log handler’s value to CHECK_LINE method’s implementation and then add messages to application log. This needed implicit enhancement and ABAP Memory (which is OBSOLETE). So, this was not a preferable solution.

Now, comes the innovative solution. On analysis of standard code, I observed that we have internal table EMSEG of program SAPLMBWL accessible in CHECK_LINE method. Standard uses the same table to fill messages in the application log. So, I filled this table with our validation messages and then standard code did the trick of adding them to application log and it got rendered suitably on MIGO screen.

I felt this was a hack but still a preferred solution as it did not warrant any kind of project approvals or usage of OBSOLETE techniques.

Code snippet –

" Local data

DATA:

lt_message TYPE bapiret2_t,

lt_emseg TYPE STANDARD TABLE OF emseg.

APPEND VALUE #( type = 'E' id = 'SY' number = 614 ) to lt_message.

APPEND VALUE #( type = 'E' id = 'SY' number = 615 ) to lt_message.

APPEND VALUE #( type = 'E' id = 'SY' number = 616 ) to lt_message.

LOOP AT lt_message ASSIGNING FIELD-SYMBOL(<fs_msg>).

APPEND INITIAL LINE TO lt_emseg ASSIGNING FIELD-SYMBOL(<fs_mseg>).

<fs_mseg>-msgid = <fs_msg>-id.

<fs_mseg>-msgno = <fs_msg>-number.

<fs_mseg>-msgty = <fs_msg>-type.

<fs_mseg>-msgv1 = <fs_msg>-message_v1.

<fs_mseg>-msgv2 = <fs_msg>-message_v2.

<fs_mseg>-msgv3 = <fs_msg>-message_v3.

<fs_mseg>-msgv4 = <fs_msg>-message_v4.

<fs_mseg>-line_id = is_mseg-line_id.

<fs_mseg>-global_counter = is_vm07m-global_counter.

ENDLOOP.

FIELD-SYMBOLS : <ft_emseg> TYPE ty_t_emseg.

ASSIGN ('(SAPLMBWL)EMSEG[]') TO <ft_emseg>.

IF <ft_emseg> IS ASSIGNED.

APPEND LINES OF lt_emseg TO <ft_emseg>.

ENDIF.

Sample Output –

Update: 19th June 2020 – I found another FM whihc offers an elegant way of getting all the BAL log handlers in memory.

FM is – BAL_GLB_SEARCH_LOG

Sample code snippet is below which will give a list of all log handlers in memory for a particular filter.

DATA: ls_log_filter TYPE bal_s_lfil,

ls_message TYPE bal_s_msg,

lt_log_handle TYPE bal_t_logh.

APPEND INITIAL LINE TO ls_log_filter-object ASSIGNING FIELD-SYMBOL(<ls_log_search_object>).

<ls_log_search_object> = VALUE #( sign    = if_slad_select_options=>C_SIGNs-including

option = if_slad_select_options=>c_options-eq

low = CONV balobj_d( '<SLG1 log object name>' ) ).

CALL FUNCTION 'BAL_GLB_SEARCH_LOG'

EXPORTING

i_s_log_filter = ls_log_filter

IMPORTING

e_t_log_handle = lt_log_handle

EXCEPTIONS

log_not_found = 1

OTHERS = 2.

Sincerely appreicate any feedback/comments/questions.

FollowLikeRSS Feed

Michelle Crapo

November 27, 2018 at 3:12 pm

Nice blog.

Like 1

Alert Moderator

Jelena Perfiljeva

November 27, 2018 at 4:38 pm

Please see the moderator note on this blog: https://blogs.sap.com/2014/09/30/assign-life-made-easy/

Like 1

Alert Moderator

Ankit Maskara

Blog Post Author

November 28, 2018 at 1:25 am

Hi Jelena,

Thanks for educating me.

But I could not find any other suitable way apart from above barring the ABAP Memory & Implicit enhancmenet technique.

If you have any other experience please suggest.

Best Regards.

Like 0

Alert Moderator

Jelena Perfiljeva

November 28, 2018 at 3:30 pm

This is kind of a lose-lose situation. Personally, most likely I wouldn't pursue either option and just declare it not feasible. Stuff like this can't go to S/4HANA and it's something that the customers need to start considering.

If you're saying that BADI can return multiple messages but there is no way to display them then this would seem like an overlook to me that SAP should fix. With the SAP logo next to your name it seems you'd be in a good position to suggest that internally.

Like 1

Alert Moderator

Ankit Maskara

Blog Post Author

November 28, 2018 at 5:00 pm

Hi Jelena,

BADI cannot return multiple messages and all demo implementations of the BADI also are built to return a single message by issuing a Message statement but since the customer requirement needs multiple messages so, I proposed above approach.

Best Regards.

Like 0

Alert Moderator

Former Member

June 14, 2013 6 minute read

How to create a custom TAB for MIGO Item Details

71153,081

Dear all, I have implemented a custom tab in MIGO, you can follow the steps.

My requirement was to add a new tab named “Warranty” in MIGO.

Step1 : Create a custom table to store the data of “Warranty” tab

The first four fields should be the key fields, and the rest fields are your required custom fields.

Step 2: create a structure with the custom field you require on the MIGO.

Step 3: open structure GOITEM and append the same custom structure into it as shown below.

Step 4: Create another structure and append the table created in Step-1.

Step 5: Create a Table type of the structure created in step-4 as shown below.

Step 6: go to SE80 and create a program as shown below. This screen must contain two screen.

Step 7: SE19 -> Badi Name: MB_MIGO_BADI

Press Create Impl. Button and create Implementation: ZMIGO_WARRENTY as shown below.

Step 8: Create a Class : ZCLASS_MIGO_WARRENTY as shown below.

Step 9: Maintain the following attributes in your Class Interface as shown below.

Step 10: Write the following codes for the methods shown below.

(a) for IF_EX_MB_MIGO_BADI~INIT

METHOD if_ex_mb_migo_badi~init.
APPEND gf_class_id TO ct_init.ENDMETHOD.

(b) for IF_EX_MB_MIGO_BADI~PBO_DETAIL

METHOD if_ex_mb_migo_badi~pbo_detail.
DATA: wa_extdata  TYPE zst_warrenty.

DATA :gf_class_id TYPE migo_class_id.

gf_class_id = ‘ZCLASS_MIGO_WARRENTY’.

CHECK i_class_id = gf_class_id.

IF g_no_input IS INITIAL.

e_cprog = ‘ZSAPMZMM_MIGO_WARENTY’.

e_dynnr = ‘9001’. “External fields: Input

e_heading = ‘Warranty’(001).

ELSE.

e_cprog = ‘ZSAPMZMM_MIGO_WARENTY’.

e_dynnr = ‘9002’. “External fields: Display

e_heading = ‘Warranty’(001).

ENDIF.

g_line_id = i_line_id.

READ TABLE gt_extdata INTO wa_extdata WITH KEY line_id = g_line_id.
IF sy–subrc = 0 AND wa_extdata–mblnr IS NOT INITIAL AND wa_extdata–mjahr IS NOT INITIAL AND wa_extdata–zeile IS NOT INITIAL.
SELECT SINGLE * FROM ztb_warrenty

CLIENT SPECIFIED INTO CORRESPONDING FIELDS OF wa_extdata

WHERE mandt = sy–mandt

AND   mblnr = wa_extdata–mblnr
AND   mjahr = wa_extdata–mjahr
AND   zeile = wa_extdata–zeile.

SET PARAMETER ID: ‘ZWARANTY’ FIELD wa_extdata–zzwarnt,

‘ZWARBEGD’ FIELD wa_extdata–zzwbegd,

‘ZWARENDD’ FIELD wa_extdata–zzwendd.

ELSE.

SET PARAMETER ID: ‘ZWARANTY’ FIELD space,

‘ZWARBEGD’ FIELD space,

‘ZWARENDD’ FIELD space.

ENDIF.ENDMETHOD.

METHOD if_ex_mb_migo_badi~pai_detail.

e_force_change = ‘X’.ENDMETHOD.

(d) for IF_EX_MB_MIGO_BADI~LINE_MODIFY

METHOD if_ex_mb_migo_badi~line_modify.
DATA: ls_extdata  TYPE zst_warrenty.

IF cs_goitem–mblnr IS NOT INITIAL AND cs_goitem–mjahr IS NOT INITIAL AND cs_goitem–zeile IS NOT INITIAL.

ls_extdata–line_id  = i_line_id.
ls_extdata–mblnr    = cs_goitem–mblnr.
ls_extdata–mjahr    = cs_goitem–mjahr.
ls_extdata–zeile    = cs_goitem–zeile.
ls_extdata–zzwarnt  = cs_goitem–zzwarnt.
ls_extdata–zzwbegd  = cs_goitem–zzwbegd.
ls_extdata–zzwendd  = cs_goitem–zzwendd.
DELETE gt_extdata WHERE line_id = ls_extdata–line_id.

INSERT ls_extdata INTO TABLE gt_extdata.

ELSE.

ls_extdata–line_id  = i_line_id.
ls_extdata–zzwarnt  = cs_goitem–zzwarnt.
ls_extdata–zzwbegd  = cs_goitem–zzwbegd.
ls_extdata–zzwendd  = cs_goitem–zzwendd.
DELETE gt_extdata WHERE line_id = ls_extdata–line_id.

INSERT ls_extdata INTO TABLE gt_extdata.

ENDIF.ENDMETHOD.

(e) for IF_EX_MB_MIGO_BADI~RESET

METHOD if_ex_mb_migo_badi~reset.

CLEAR: gt_extdata,

g_no_input,

gs_exdata_header,

g_cancel,

g_line_id.ENDMETHOD.

(f) for IF_EX_MB_MIGO_BADI~POST_DOCUMENT

METHOD if_ex_mb_migo_badi~post_document.
DATA: wa_warrenty TYPE ztb_warrenty,

it_warrenty TYPE TABLE OF ztb_warrenty,

wa_mseg TYPE mseg,

wa_extdata TYPE zst_warrenty.

...

来源说明：本文内容由「Adding multiple messages in MIGO transaction via MB_CHECK_LINE_BADI.docx」整理生成，仅用于内部技术分享与学习交流。

ABAP Cheat Sheet 补充内容

以下内容整理自 SAP 官方 ABAP 速查表（主题：SAP LUW），作为本文的扩展补充资料。

Introduction

[!NOTE] The concept is relevant to both ABAP Cloud and classic ABAP, but some of the statements covered in the cheat sheet and the executable example are only relevant to classic ABAP.

This cheat sheet provides a high-level overview of the SAP LUW concept that deals with data consistency with a focus on SAP LUW-related statements, supported by an executable example to check the syntax in action.

When you run an application, you typically change data in a transaction, which may be temporarily stored in transactional buffers. This data may be temporarily inconsistent in the buffers, but it is important that the data be in a consistent state at the end of the transaction so that it can be saved to the database.

Consider the following example of transactional consistency:

A transaction consists of a money transfer from account A to account B, assuming the accounts are in the same bank and the data is stored in the same database.
Such a transaction represents a logical unit. The transaction is successful when the money is debited from account A and credited to account B.
This transaction may include other related tasks. Data may be loaded into a buffer, processed there, and become inconsistent during this time. It may also take a while for the whole process to be completed.
However, at the end of the transaction, all data must be in a consistent state so that the database can be updated accordingly. Or, if errors occur during the transaction, it must be ensured that all changes can be reversed. It must not happen that money is credited to account B without also updating the totals of account A. In such a case, the previous consistent state must be restored.

[!NOTE] - This cheat sheet focuses on classic ABAP and the unrestricted ABAP language version Standard ABAP. Hence, the links in this cheat sheet open topics in the ABAP Keyword Documentation for Standard ABAP. - The SAP LUW concept is also relevant to ABAP Cloud. The ABAP RESTful Application Programming Model (RAP) is the transactional programming model for ABAP Cloud. It comes with a well-defined transactional model and follows the rules of the SAP LUW. Find out more in this blog.

Terms

The following terms are related to the concept of the SAP LUW and try to give you some context about it:

Transaction
In a business context, a transaction describes a sequence of related and/or interdependent actions, such as retrieving or modifying data.
The result of the transaction is a consistent state of data in the database.

Logical unit of work (LUW)
Describes the time interval at which one consistent state of the database is transitioned to another consistent state.
Follows an all-or-nothing approach: It ends either with a single and final commit, which saves the changed data in the database, or with a rollback, which undoes all changes and restores the consistent state before the changes (for example, in the case of an error during the LUW). Either all data changes are committed, or none at all.
For an Application Server ABAP (AS ABAP), two types of LUWs come into play to achieve data consistency: Database LUW and SAP LUW (which is covered below).

Database LUW
Also called database transaction.
Is an SAP-independent mechanism for transactional consistency in the database.
Describes an indivisible sequence of database operations concluded by a database commit, that persists data to the database.
The database system either executes the database LUW completely or not at all. If an error is detected within a database LUW, a database rollback undoes all database changes made since the start of the database LUW.

Database commit
Marks the end of a database LUW in which changed data records are written to the database.
An important question for developers is how and when database commits and rollbacks are triggered (especially implicitly).
In AS ABAP, database commits can be triggered implicitly as well as by means of explicit requests.
Find more information here.

Implicit database commits. Among others, implicit database commits are triggered by:
Completing a dialog step in the context of dynpros
A dialog step describes the state of a user session between a user action on the user interface of a dynpro and the sending of a new screen layout, i.e. it covers logic implemented in the PAI of the current dynpro and PBO of the following dynpro
When the next screen is displayed, the program waits for a user action and does not occupy a work process during this time.
The next free work process is assigned to the program in the next dialog step.
A work process change requires and implicitly triggers a database commit.
Calling a function module in a synchronous (sRFC) or asynchronous remote function call (aRFC)
This is when the current work process passes control to another work process or system. Exception: Updates.
HTTP/HTTPS/SMTP communication executed using the Internet Communication Framework (ICF)
WAIT statements that interrupt the current work process
Sending messages (error messages, information message, and warning)

Explicit database commits. For example, database commits can be triggered explicitly in ABAP programs in the following ways:
Using the relevant database-specific Native SQL statement
Using the ABAP SQL statement COMMIT CONNECTION
Calling the function module DB_COMMIT, which encapsulates the corresponding Native SQL statement.
Using the ABAP SQL statement COMMIT WORK. Note that the statement is particularly relevant to the SAP LUW as shown below. It also ends the SAP LUW.

Database rollback
Like a database commit, ...
a database rollback marks the end of a database LUW. Here, all modifying database operations are undone until the beginning of the LUW.
are triggered implicitly, as well as by explicit requests.
They are implicitly triggered, for example, by a runtime error or a termination message (message of type A).
For example, explicit rollbacks are triggered by:
Using the relevant database-specific Native SQL statement
Using the ABAP SQL statement ROLLBACK CONNECTION
Calling the function module DB_ROLLBACK, which encapsulates the corresponding Native SQL statement.
Using the ABAP SQL statement ROLLBACK WORK. Note that the statement is particularly relevant to the SAP LUW as shown below. It also ends the SAP LUW.

Work process
As a component of an AS ABAP AS instance, work processes execute ABAP applications. Each ABAP program that is currently active requires a work process.
AS ABAP uses its own work processes to log on to the database system. Different types of work processes are available for applications, including dialog, enqueue, background, spool, and update work processes.
As mentioned earlier, in dialog processing, a work process is assigned to an ABAP program for the duration of a dialog step. An application program can be divided into several program sections and, in the case of dynpros, into several dialog steps that are processed sequentially by different work processes.
For example, in the context of a dynpro, when a dialog step that is waiting for user interaction completes, the work process is released (for another workload) and a new work process is assigned. The current workload is persisted and resources are released. This approach requires an (implicit) database commit that ends the database LUW.
A work process can execute only a single database LUW. It cannot interfere with the database LUWs of other work processes.

⬆️ back to top

SAP LUW Overview

For an SAP LUW, the following aspects come into play:

Usually, an SAP LUW is started by opening a new internal session. The execution of programming units can be distributed among several work processes.
Database commits persist data in the database (especially implicit database commits when work processes are switched).
The all-or-nothing rule applies: All database changes that occur during a transaction constitute a logical unit of work. They must be committed together, or rolled back together in the event of an error.
This means that all database changes must be deferred and made in a final database commit (that is, in a single database LUW) at the end of a transaction - not in between.
To ensure data consistency, all database changes are bundled, for example, in temporary tables or transactional buffers, and then, at the end of the transaction, all changes are written to the database together in a single work process, that is, in a single database LUW with a single database commit. This can be done directly using ABAP SQL statements at this stage, or using bundling techniques - special ABAP programming techniques.

Using the above bank transfer as an example:

At the end of the transaction, the new totals of both accounts are updated (money is debited from account A and credited to B).
You cannot debit account A in one work process and then credit account B in a separate work process. When the work process changes, new totals would be available in one account, but not in the other.
Consider the consequences if an error occurs and the new totals for account B cannot be updated, and so on. You would no longer be able to easily roll back the changes. Consider prematurely updating the database and notifying the users or processing the data while the logical unit has not been successfully completed.

⬆️ back to top

Bundling Techniques

The following bundling techniques are available in Standard ABAP. This means that programming units are registered in different work processes, but are executed by a single work process. All database changes are put into one database LUW, and all changes are committed in one final database commit.

Using update function modules

Are specially marked, i.e. the update module property is marked
Can be given specific attributes to determine the priority with which they are processed in the update work process
Usually contain database modification operations/statements
CALL FUNCTION ... IN UPDATE TASK statements are used to register the update function modules for later execution; the actual execution is triggered by a COMMIT WORK statement

Example of a simple function module that has an importing parameter (a structure that is used to modify a database table). It simply shows a database modifying statement contained in a function module. The code alone does not distinguish it as an update function module. For example, check the example function modules from the imported repository that are used in the executable example. In ADT, right-click a function module and choose Open with → SAP GUI. In SAP GUI, choose the Attributes tab. The Update Module checkbox is selected.

  FUNCTION zsome_update_fu_mod
    IMPORTING
      VALUE(values) TYPE some_dbtab.

    MODIFY some_dbtab FROM @values.

  ENDFUNCTION.

Depending on your use case, you can run the update work process in several ways:
Synchronous update: The calling program waits until the update work process has finished. The COMMIT WORK statement with the AND WAIT addition triggers a synchronous update in a separate update work process.
Asynchronous update: The calling program does not wait for the update work process to finish. The COMMIT WORK statement triggers an asynchronous update in a separate update work process.
Local update: The update is performed immediately in the current work process in a separate internal session and not in a separate update work process. This is true regardless of whether COMMIT WORK is used with AND WAIT or not. By default, the local update is deactivated at the start of each SAP LUW. If required, you can activate local update for an SAP LUW using the SET UPDATE TASK LOCAL statement before registering the update function modules.

    "--------------------- Synchronous update ---------------------
    DATA(st_a) = VALUE some_type( ... ).

    ... 

    "Registering the update function module specified in uppercase letters
    CALL FUNCTION 'ZSOME_UPDATE_FU_MOD' IN UPDATE TASK 
        EXPORTING values = st_a.

    ...

    "Triggering the synchronous update
    COMMIT WORK AND WAIT.                              

    "--------------------- Asynchronous update ---------------------
    DATA(st_b) = VALUE some_type( ... ).

    ... 

    CALL FUNCTION 'ZSOME_UPDATE_FU_MOD' IN UPDATE TASK 
        EXPORTING values = st_b.

    ...

    "Triggering the asynchronous update
    COMMIT WORK.

    "--------------------- Local update ---------------------
    
    "Before update function modules are registered.
    SET UPDATE TASK LOCAL.

    DATA(st_c) = VALUE some_type( ... ).

    ... 

    CALL FUNCTION 'ZSOME_UPDATE_FU_MOD' IN UPDATE TASK 
        EXPORTING values = st_c.

    ...

    "The update will be synchronous no matter if you use the COMMIT WORK 
    "statement with or without the addition AND WAIT.
    COMMIT WORK.
    "COMMIT WORK AND WAIT.

[!NOTE] If a runtime error occurs during the update, the update work process executes a database rollback, and notifies the user whose program created the entries.

Using remote-enabled function modules

Also in this case, the bundling is done through function modules.
They are also specially marked as remote-enabled function modules.
For example, you can register them for later asynchronous execution in the background and through the RFC interface (background Remote Function Call (bgRFC)). With this technology, you can make calls in the same or different ABAP systems.
More information:
SAP Help Portal documentation about RFC
CALL FUNCTION ... IN BACKGROUND UNIT
Note the background processing framework (bgPF) as a successor technology

Using subroutines

Subroutines (that are no longer recommended for use ⚠️) can be registered for later execution.

They are registered with the PERFORM ... ON COMMIT statement. These subroutines are executed when a COMMIT WORK statement is called.
An addition is available to control the order of execution.
Similarly, a subroutine can be registered "on rollback" with PERFORM ... ON ROLLBACK. These subroutines are executed when a ROLLBACK WORK statement is called.
When executed:
In the current work process, before update function modules.
When they are registered in an update function module with ON COMMIT, they are executed at the end of the update. This happens in the update work process for non-local updates, and in the current work process for local updates.

⬆️ back to top

Related ABAP Statements

An SAP LUW is usually started by opening a new internal session. The statements to end an SAP LUW have already been mentioned above: [COMMIT WORK [AND WAIT]](https://help.sap.com/doc/abapdocu_latest_index_htm/latest/en-US/index.htm?file=abapcommit.htm) and ROLLBACK WORK.

COMMIT WORK [AND WAIT]

Closes the current SAP LUW and opens a new one.
Commits all change requests in the current SAP LUW.
Among other things, this statement triggers ...
the processing of all registered update function modules.
the update work process and the local updates in the current work process.
a database commit for all currently open database connections, which also terminates the current database LUW.
Note that COMMIT WORK triggers an asynchronous, COMMIT WORK AND WAIT a synchronous update.

ROLLBACK WORK

Similar to COMMIT WORK statements, this statement closes the current SAP LUW and opens a new one.
Among other things, this statement ...
causes all changes within an SAP LUW to be undone, that is, all previous registrations for the current SAP LUW are removed.
triggers a database rollback on all currently open database connections, which also terminates the current database LUW.

[!NOTE] - COMMIT WORK vs. COMMIT WORK AND WAIT in ABAP Cloud - Both COMMIT WORK and COMMIT WORK AND WAIT are valid syntax options in ABAP for Cloud Development. - However, the functionality of COMMIT WORK and COMMIT WORK AND WAIT - and also SET UPDATE TASK LOCAL - is primarily applicable in classic ABAP, where update function modules, among others, are available. These function modules are not applicable in ABAP Cloud. - In ABAP Cloud, local updates are always enforced implicitly and automatically, meaning that updates occur in the same work process and are always synchronous. - Consequently, in ABAP Cloud, COMMIT WORK and COMMIT WORK AND WAIT behave identically, rendering the choice between the two irrelevant. - Typically, COMMIT WORK in ABAP Cloud returns a value of 0 for sy-subrc, while other values would result in a runtime error. - In the context of RAP, when committing in a RAP transaction, refer to the notes about COMMIT ENTITIES here. - Notes on database connections: - The database interface uses the standard connection of the current work process to access the standard database by default. - Optionally, database accesses can also be made by using secondary connections to secondary databases or by using service connections to the standard database. The secondary connections are usually used by technical components. For example, they are used for caches, traces, logs, and so on. - The implicit database rollback is performed on all database connections that are currently open. - Within the SAP LUW, database changes and commits are allowed on service connections or through secondary database connections.

⬆️ back to top

Concepts Related to the SAP LUW

The following concepts are related to the SAP LUW to ensure transactional consistency. They are not discussed in detail here. For more information, see the links.

Authorization concept

In an SAP system, you need to protect data from unauthorized access by making sure that only those authorized to access it can see and modify it.
Authorization to access data can be set. Before a user can perform certain operations in your application, you need to implement authorization checks.
Since ABAP SQL statements do not trigger any authorization checks in the database system, this is even more important. Database tables may be accessed without restriction using these statements. Conversely, not all users in a system are authorized to access all data available to ABAP SQL statements.
Thus, it is up to the programmer to ensure that each user who can call the program is authorized to access the data it handles.
More information:
Authorizations
AUTHORITY-CHECK

Lock concept

The database system automatically sets database locks when ABAP SQL statements are called to modify database table entries.
These locks are implemented by automatically setting a lock flag, which can only be set for existing database table entries.
After a database commit, these flags are removed.
As a result, database locks are not available for more than one database LUW, which must be considered in the context of an SAP LUW, since multiple database LUWs may be involved. Therefore, the lock flags that are set in a transaction are not sufficient. For the duration of an entire SAP LUW, a lock on database entries must remain set.
This is where the SAP lock concept comes into play, which is independent of the automatic database locks. It is based on lock objects.
Lock objects ...
are repository objects that are defined in the ABAP Dictionary.
specify the database tables in which records are to be locked with a lock request.
contain the key fields on which a lock is to be set.
When a lock object is created, two lock function modules (ENQUEUE</em>... and DEQUEUE_...) are automatically generated. They are executed in a special enqueue work process. When a record is locked during a transaction (by the enqueue function module), a central lock table is filled with the table name and key field information. Unlike database locks, a locked entry in a lock object does not necessarily have to exist in a database table. Also, the locking must be done proactively, i. e. there is no automatic locking. You must make sure that the application implementation checks the lock entries.
At the end of an SAP LUW, all locks should be released, either automatically during the database update or explicitly when you call the corresponding dequeue function module.
More information:
SAP Locks
Note the information on the CL_ABAP_LOCK_OBJECT_FACTORY class that is related to this context here.

[!NOTE] For more information about related topics in RAP, see the sections Authorization Control and Concurrency Control in the Development guide for the ABAP RESTful Application Programming Model.

⬆️ back to top

The SAP LUW in ABAP Cloud and RAP

A limited set of ABAP language features is available in ABAP for Cloud Development (restricted ABAP language version). The limitations include the fact that the above bundling techniques are not available. Note that the local update is enabled by default in ABAP Cloud.

In fact, RAP is the transactional programming model for ABAP Cloud. And RAP comes with a well-defined transactional model and follows the rules of the SAP LUW. At the end of an SAP LUW in RAP, database modification operations should be performed in a final step in the RAP late save phase by persisting the consistent data in the RAP transactional buffer to the database.

There are RAP-specific ABAP EML statements for commit and rollback:

COMMIT ENTITIES implicitly triggers COMMIT WORK. Furthermore, COMMIT ENTITIES provides RAP-specific functionality with various additions. These EML statements implicitly enforce local updates with COMMIT WORK, or COMMIT WORK AND WAIT if the local update fails. Therefore, the update is either a local update or a synchronous update, but never an asynchronous update.
ROLLBACK ENTITIES: Resets all changes of the current transaction and clears the transactional buffer. The statement triggers ROLLBACK WORK.
Find more information in the ABAP cheat sheet about EML.

⬆️ back to top

Controlled SAP LUW

The controlled SAP LUW is an enhancement to the SAP LUW concept, available in both ABAP Cloud and classic ABAP.
It introduces a check mechanism to detect violations of transactional contracts to guarantee transactional consistency.
Such contracts specify which ABAP statements and operations are allowed and which are not allowed in a transactional phase.
In this way, applications can be made more robust and the SAP LUW can be made more tangible.
Violations that are detected result in a runtime error (or are logged).
There are mainly two transactional phases: modify and save.
In RAP, these two phases are set implicitly, and they are subdivided as follows (see more information in the EML cheat sheet and the RAP guide):
modify
RAP interaction phase
RAP early save phase
save
RAP late save phase
Using the static methods modify and save of the CL_ABAP_TX class, you can activate the transactional phases explicitly.
The controlled SAP LUW is automatically and implicitly supported by newer ABAP concepts such as RAP (i.e. the transactional phases are implicitly active when RAP handler methods are called), background Processing Framework (bgPF), and local consumption of RAP business events.
Furthermore, transactional contracts define where (i. e. in which transactional phase) a classified API, such as a method of a class, can be used. The classifications start with IF_ABAP_TX_..., for example, IF_ABAP_TX_SAVE, and are, in the case of methods, typcially included as types in the local types of the class (CCDEF include, Class-Relevant Local Types tab in ADT). The classifications detail out and restrict the scope of use, so as not to use a classified API in phases where not allowed. Follow the links below for more information.
Example of a classified API: Open the class CL_BCS_MAIL_MESSAGE (which is used for sending emails). In ADT, go to the Class-Relevant Local Types tab, and find classifications for methods, for example, the send_async method. Calling this method in the modify transactional phase results in a violation. You can also get information about the transactional contract using the F2 information in ADT. In the case of the method mentioned, choose F2 on send_async (... cl_bcs_mail_message=>create_instance( ... )->send_async( ). ...) to view the transactional contract information.
Regarding the concrete restrictions and for more information, follow the links.
Examples for violations, such as database modifications. They are only allowed in the save transactional phase because the data being processed in the modify phase may be inconsistent:
Database modification (e.g. MODIFY dbtab FROM @row.) performed when the modify transactional phase is active.
Database modifcation in a RAP handler method implementation. Here, the modify transactional phase is active by default.
Database modifcation in a RAP event handler method implementation when the save transactional phase has not been activated explicitly. Note: When RAP event handler methods are called, they are started in the modify transactional phase. Modifying a database right away there, without the activation of the save phase, means a violation.
Calling a classified API in a phase where not allowed, such as ... cl_bcs_mail_message=>create_instance( ... )->send_async( ). ... (classified with IF_ABAP_TX_SAVE) in the modify transactional phase.
More information:
Controlled SAP LUW in the SAP Help Portal
ABAP Keyword Documentation (Standard ABAP):
Restrictions in Transactional Phases
API Classifications
Restrictions in RAP Handler and Saver Methods

Example using CL_ABAP_TX:

...

*&---------------------------------------------------------------------*
*& Activating the modify transactional phase
*&---------------------------------------------------------------------*

cl_abap_tx=>modify( ).

"The following database modification statement is not allowed in the
"modify transactional phase. In certain contexts, e.g. in ABAP Cloud,
"the runtime error BEHAVIOR_ILLEGAL_STMT_IN_CALL occurs.
MODIFY zdemo_abap_carr FROM TABLE @( VALUE #(
    ( carrid = 'XY'
      carrname = 'XY Airlines'
      currcode = 'EUR'
      url =  'some_url' ) ) ).

...

*&---------------------------------------------------------------------*
*& Activating the save transactional phase
*&---------------------------------------------------------------------*

cl_abap_tx=>save( ).

"In this phase, database modifications are allowed.
MODIFY zdemo_abap_carr FROM TABLE @( VALUE #(
    ( carrid = 'XY'
      carrname = 'XY Airlines'
      currcode = 'EUR'
      url =  'some_url' ) ) ).
...

⬆️ back to top

More Information

The RAP Transactional Model and the SAP LUW (Development guide for the ABAP RESTful Application Programming Model)
SAP LUW in the ABAP Keyword Documentation
Controlled SAP LUW as an enhancement of the SAP LUW concept

⬆️ back to top

Executable Example

After the import of the repository, proceed as follows:

Find the program in ADT using the search by choosing CTRL + SHIFT + A.
Enter zdemo_abap_sap_luw and open the program.
Run the program by choosing F8.

[!NOTE] - The examples in the main branch of the ABAP cheat sheet repository are designed to be imported into the SAP BTP ABAP Environment. For Standard ABAP, you can find examples (such as zdemo_abap_sap_luw) in the other branches of the repository. - The executable example ... - demonstrates the SAP LUW using classic dynpros to provide a self-contained and simple example that highlights the considerations regarding implicit database commits, without putting the spotlight on dynpros. Note that classic dynpros are outdated for application programs. New developments should use web-based UIs, such as SAP Fiori UIs. - covers the following topics in simple contexts: - Demonstrating synchronous update, asynchronous update, and local update triggered by COMMIT WORK, COMMIT WORK AND WAIT, and SET UPDATE TASK LOCAL using update function modules. - Demonstrating the statements PERFORM ... ON COMMIT and PERFORM ... ON ROLLBACK using subroutines. - does not claim to include meaningful dynpros with meaningful dynpro sequences and is not intended to be a role model for proper dynpro design. - is not intended to solve concrete programming tasks. You should always work out your own solution for each individual case. - is only intended to demonstrate a selection of keywords and visualize SAP LUW-related syntax in action on a high level. - is explained in more detail in the expandable section below. Click to view the details. - Dynpros cannot be created in ABAP Cloud. As mentioned earlier, RAP is the transactional programming model for ABAP Cloud. It comes with a well-defined transactional model and follows the rules of the SAP LUW. See the links in the More Information section. - The steps to import and run the code are outlined here. - Disclaimer

🟢 Click to expand for more information

The example demonstrates the SAP LUW using dynpros and bundling techniques with update function modules and subroutines. In the dynpros, you can select various options that determine how the program runs. It covers the following aspects:

Demonstrating synchronous update, asynchronous update, and local update triggered by COMMIT WORK, COMMIT WORK AND WAIT, and SET UPDATE TASK LOCAL using update function modules.
Demonstrating the statements PERFORM ... ON COMMIT and PERFORM ... ON ROLLBACK using subroutines.

The selection options follow this pattern:

First dynpro:

The SAP LUW is started.
The entries in a database table are displayed. There are four entries in total.
After you have selected an option to continue with either the update task, or the update task and perform a local update, or subroutines, an update function module or subroutine is registered to delete all entries from the database table.

Second dynpro:

You can create a new database table entry by making entries in input fields displayed on the dynpro.
When the program continues, it registers an update function module or subroutine that inserts the new entry into the database table.

Third dynpro:

The SAP LUW is ended. You have several options for ending the SAP LUW.
In addition to the COMMIT WORK and COMMIT WORK AND WAIT statements, you can use ROLLBACK WORK to roll back the changes.
Another option is to deliberately make the current SAP LUW fail. If a type A message is triggered, the SAP LUW is also terminated.

During program execution, logs are collected and eventually written to a database table (also using an update function module or subroutine). These logs document the progress of the transaction with various pieces of information. These include work process information, SAP LUW key retrieval, and transaction state retrieval (using methods of the CL_SYSTEM_TRANSACTION_STATE class).

If the program is not terminated immediately and the SAP LUW has ended, another program is called that displays a dynpro.

Fourth dynpro (part of a new program that is started):

The database table entries and logs are displayed.
If the transaction was successful, a single entry (the one created during the execution of the previous program) should be displayed for the modified database table, as well as the entries of the log table.
Note that a helper class is available for this example. Methods perform various tasks, such as retrieving work process information.

Notes on the various options for checking out the SAP LUW:

Asynchronous update with COMMIT WORK: Immediately after the COMMIT WORK statement, a SELECT statement is executed, retrieving all the entries of the database table. In this case, the number of the retrieved entries should be the number of the original database table entries, i.e. 4 entries, and not 1, demonstrating the asynchronous update. The current number of records is displayed in a message. Result: The database table is deleted and a single new entry is added.

The log shows the value 1 for the transaction state after the update task is executed and the update function modules are called.

Synchronous update with COMMIT WORK AND WAIT: Immediately after the COMMIT WORK AND WAIT statement, a SELECT statement is executed to retrieve all the entries in the database table. In this case, there should be one entry instead of four to demonstrate the synchronous update. The current number of records is displayed in a message.
Local update using a SET UPDATE TASK LOCAL statement: Once the local update is enabled, it does not matter whether you choose COMMIT WORK or COMMIT WORK AND WAIT in the next step. It will be a synchronous update, so the number of current database table entries displayed in the message will be 1 in both cases. The log will show the value 1 for the transaction state after the SET UPDATE TASK LOCAL statement has been executed.
Rolling back changes: Although update function modules or subroutines are registered, none of them affect the database. All changes are rolled back. Result: The database table is not deleted, no new entry is created. The original content of the database table should be displayed.
Causing a failure in the current SAP LUW: An update function module intentionally includes a statement that causes a runtime error if not caught (zero division). All changes are rolled back implicitly. If the local update is active, you should be informed of the problem directly. The program is terminated. In this case, you can check the database table entries that remain unchanged. You can also use transaction ST22 to display the runtime error that occurred. In the case of a non-local update, you should receive a mail in the Business Workplace informing you of the problem in the SAP LUW. The original content of the database table should be displayed on the next screen. In this case, you can also check transaction ST22 for the runtime error.
Terminating the program with an error message of type A: This option only indicates that if such a message is generated, the program is terminated and all changes are implicitly rolled back. In this case, you may want to check the database table entries that remain unchanged.
Using subroutines:
Note that subroutines are considered obsolete and should no longer be used. This is to demonstrate the effect as a bundling technique in an SAP LUW. Selecting this option triggers the registration of subroutines for commit (to delete the database table entry, insert a newly created entry, insert entries in the log table) and rollback (the subroutine in the example does not do anything specific; it is just to demonstrate that the subroutine is called in the event of a rollback).
When you select the commit options, the subroutines registered with ON COMMIT are executed in the current work process.
Choosing COMMIT WORK or COMMIT WORK AND WAIT has the same effect: When these statements are called and a SELECT statement follows, the number of database table entries is 1 in both cases.
If the rollback option is selected, the subroutine registered with ON ROLLBACK is executed in the current work process.
The transaction state in the log is 1 for ON COMMIT or ON ROLLBACK when the corresponding subroutines are called.
Note that registered subroutines cannot have a parameter interface, so no parameters can be passed in this type of bundling. Therefore, data can only be passed through external interfaces, such as ABAP memory. In this example, the database table entry created is passed to and from ABAP memory using EXPORT and IMPORT statements. The subroutines do not implement the writes themselves, but instead call methods of a class.
The following aspects are valid for all selected options regarding the logs:
Before the commit is triggered (in the last PAI), the transaction state shows the value 0 for all retrieved transaction states.
The work process information may change due to the fact that database commits are triggered when completing a dialog step. So you might expect different numbers there, but not necessarily. The new free work process can also be the same as the one before it was freed. However, there will be no different work process information for the update. The numbers will be the same because the update is performed in a single work process.
Before calling the program that displays database entries and the log, the SAP LUW key is the same throughout the transaction. It does not change until a new SAP LUW is opened. See and compare the last entry for the SAP LUW key in the log that is retrieved for the program submitted.

来源说明：本节内容来源：SAP-samples/abap-cheat-sheets (GitHub)，原作者 SAP。原 Markdown 文件：17_SAP_LUW.md。版权归原作者所有。

Adding multiple messages in MIGO transaction via MB_CHECK_LINE_BADI

相关文章

ABAP Cheat Sheet 补充内容

SAP LUW

Introduction

Terms

SAP LUW Overview

Bundling Techniques

Related ABAP Statements

Concepts Related to the SAP LUW

The SAP LUW in ABAP Cloud and RAP

Controlled SAP LUW

More Information

Executable Example