ABAP Quick - Processing in a new task

Table of contents

• Requirements
• Example
• Start
• Commit
• Rules
• Conclusion

In some cases you want to execute a computationally heavy process asynchronously, an additional process should be started and the whole thing should not have any performance impact on the current process. To do this, you use an asynchronous task that runs in its own LUW and, in contrast to the main process, can take its time. In this article, we'll go into the prerequisites and show you how to start the process.

 

Requirements

So that we can execute a process asynchronously, we need a function module in the first step. In addition, it must also be RFC-enabled. The function module should run in a separate process, similar to an update module. There are therefore the following additional requirements for the function block:

• RFC-enabled function module
• Only parameters with VALUE data transfer
• No parameters with exporting or changing

 

Example

Such a function module could now look like this, using three importing parameters that we will work with later.

FUNCTION Z_TEST_FOR_BACKGROUND_PROCESS
  IMPORTING
    VALUE(ID_USER) TYPE SYUNAME
    VALUE(ID_NUMBER) TYPE I
    VALUE(ID_TEXT) TYPE STRING.

  " Implement some code
ENDFUNCTION.

 

If you work with Eclipse, you should not forget to mark the function module as RFC-enabled. To do this, you will find the "Specific" tab on the "Properties" view. Here you can set the Processing Type to RFC.

 

Start

To call the function module in your processing, a simple CALL FUNCTION is sufficient, as you do with normal function modules. You must also specify the addition IN BACKGROUND TASK so that the RFC function module is started in the background and assigned to its own LUW with AS SEPERATE UNIT. The use of the addition DESTINATION is optional; if no value is specified, the destination NONE is used.

CALL FUNCTION 'Z_TEST_FOR_BACKGROUND_PROCESS'
  IN BACKGROUND TASK AS SEPARATE UNIT
  EXPORTING
    id_user   = sy-uname
    id_number = 23
    id_text   = `Some example text`.

 

Commit

Depending on where you are in your process, you may need to issue a COMMIT to start the process. If you call the function module as above, it will first be registered for processing, but no processing will take place yet. The next COMMIT WORK then starts processing and the process.

Here are a few examples of how it could be solved:

• BADI implementation - A commit is set here after successful processing and a rollback is processed in the event of an error. No additional commit has to be implemented or a commit can lead to an error in the processing of the standard.
• OData Service - During the execution of a function, an asynchronous process should also be started; a commit must be set for this after the call.

 

Hint: If you test the OData via the SAP Gateway Client without a commit, the processing will work, if it is called via a Fiori application it will no longer work. So it's best to always implement a COMMIT WORK here.

 

Rules

Since the function module starts in its own LUW, you can no longer access the data of the original session, but you can use all importing parameters and read your own data. Your commit or rollback only affects your data, so that you can work normally from standard processes. However, you should note that if the original process should then roll back, your process will not notice it.

 

Conclusion

With our little tip, you should now be able to implement asynchronous processing from your own programs and from the standard. So that processing starts properly, always think of a commit work and whether it makes sense at this point.