cancel
Showing results for 
Search instead for 
Did you mean: 
Read only

Task type in parallel processing

dschiener
Participant
0 Likes
1,229

Hi,

currently I am reseachring on parallel processing in ABAP.

The most solutions I found so far are based on asynchronous RFC calls. So far so good.

Also, in most cases, one talks about 'tasks' instead of 'jobs' or 'calls'.
Especially regarding the call `STARTING NEW TASK ...`


Unfortunately, for me it's not clear, what we are talking about on a technical layer...

Is a 'task' in general a 'background job" that runs on an application server?
Is there any transactional overview, like SM37, to see all created (and running) 'tasks"?
Is a 'task' a dialog process, so do I have to take care about the limit of dialog processes?

Maybe anyone can clearify.

BR

Accepted Solutions (0)

Answers (1)

Answers (1)

Sandra_Rossi
Active Contributor
0 Likes

The RFC task behind STARTING NEW TASK is like starting a User Session (same as if a user logins) to which you give a task name and so you may reuse it for another RFC call or close it (RFC_CONNECTION_CLOSE).

The RFC runs in a DIA workprocess.

It's not a background job (which runs in a BTC workprocess).

You may see the open tasks via SM04 (user sessions).

See there to understand the memory organization: https://help.sap.com/doc/abapdocu_latest_index_htm/latest/en-US/index.htm?file=abenmemory_organizati...

Concerning the limit of tasks, joker, it's not clear to me.

You may use pRFC (starting new task in destination group), you should not have this limit.

dschiener
Participant
0 Likes

@Sandra_Rossithank you for your reply.

As far as I know there is a system wide limit of processes that may be executed at one time. Regarding this limit I am wondering if it is possible to start as much dialog processes in parallel by using default syntax like STARTING NEW TASK to crash the system or if there is a fall back built in to prevent of this case. 

Furthermore I guess using dialog processes to implement parallelism won’t be such a good idea in case of longer running processes (e.g. 1 hour). Otherwise theses processes would block dialog user of logging in or using the system. Am I right?

In this case IN BACKGROUND UNIT could help out. 

BR

Sandra_Rossi
Active Contributor
0 Likes
There are no differences between dialog and background workprocesses, you may arrange how many workprocesses are assigned to DIA or BTC. That won't block users. You indicate the ratio of dialog workprocesses reserved to users (check the profile parameters). RFC runs in dialog tasks because they should be sized to run small units of work (like a dialog operation). bgRFC also runs via dialog workprocesses but you may select 3 priorities with each a different timeout (profile parameters again).