Skip to Content


This blog must be used with care. As the SAP Note

SAP Note 1273124 onAsynchronous Callback Limitations 

explains Web Dynpro Objects are not thread safe so you can run into side effects when you start manipulating the same objects in multiple threads. So make sure you program thread safe and synchronize access to shared objects.

Thanks to Reshma Nair of SAP product management for pointing that out.



 Nowadays CPUs do not seem to get faster but instead to increase in the number of cores.

When you look into the task manager of your application server you see it uses a lot of memory but the CPU is pretty idle.

From wikipedia we get the following definition: 

Traditionally, computer software has been written for serial computation. To solve a problem, an algorithm is constructed and implemented as a serial stream of instructions. These instructions are executed on a central processing unit on one computer. Only one instruction may execute at a time—after that instruction is finished, the next is executed.[6]

Parallel computing, on the other hand, uses multiple processing elements simultaneously to solve a problem. This is accomplished by breaking the problem into independent parts so that each processing element can execute its part of the algorithm simultaneously with the others. The processing elements can be diverse and include resources such as a single computer with multiple processors, several networked computers, specialized hardware, or any combination of the above.


Concurrent Calls to the backend

The most time intensive tasks in my Web Dynpro applications are actually calls to the backend. Especially when you do many backend calls  in a sequential manner, executing calls in parallel can speed up the process. I have had that case in a complicated Web Dynpro Application that had to load data from the database, several BAPIs and some Web Services. Execution time was very poor.

Using Threads

If you want to do things concurrently in java you need to use the Thread  class. 

The thread has the run method, that takes the code that you want the thread to perform.

You start a Thread by calling the start method of the Thread. The start method immediately returns and the Thread is alive and executes its run method in the background.

To actually wait until a thread has finished its execution you call the join method of the thread which blocks until the thread has finished its execution (run method).

Here is an example:

List parallelTasks = new ArrayList();
parallelTasks.add( new Thread1());
parallelTasks.add( new Thread2());
//.. add more tasks
//Start all threads
for (Iterator iter = threads.iterator(); iter.hasNext();) {
Thread thread = (Thread);
//Wait until all threads are finished
for (Iterator iter = threads.iterator(); iter.hasNext();) {
Thread thread = (Thread);
try {
//join means wait until thread finishes
} catch (InterruptedException e) {
//can be ignored

The problem with parallel calls in Web Dynpro

Well this seems easy. You can use the pattern above for anything in your java programs to introduce parallel computing. At the end I will show a generic class that encapsulates this in a simple way.

But when you try to introduce parallelization in Web Dynpro like initializing several Web Dynpro components concurrently or doing RFCs calls in parallel you will get some weird error messages.

The reason for that is a bit tricky to understand. Web Dynpro uses the current thread itself to carry around certain state. If you start to create several threads from the main thread that context is not available in the newly created threads and therefore things like opening RFC connections does not work.

But here is a simple work around:

You need to pass this state information to the new threads as well. The Thread information is called the Web Dynpro Task and lives as long as the thread lives. The web dynpro runtime starts the task and cleans it up after execution.

So the work around is just to pass the reference of the current Web Dynpro task to the new threads.

final ITask currentWdTask = TaskBinder.getCurrentTask();
Thread myThread1 = new Thread(){
public void run(){
//do whatever you want ...

Thread myThread2 = new Thread(){
public void run(){
//do whatever you want ...
//wait for finishing


This already works quite well but there are some pitfalls you must be aware of.

  • Messages reported by the IWDMessageManager in the other threads are swallowed. This makes troubleshooting more complicated.
  • Exceptions in the threads are not visible and cannot be handled in the main thread.
  • The threads opened are not taken from the threadpool of the server. If you overuse this pattern you can potentially open more threads than the VM can handle. So please use it wisely.
  • As I explained earlier, Web Dynpro objects are not thread safe so please avoid manipulation the same Web Dynpro objects in concurrent threads. See also SAP Note 1273124

The first problem you have to keep in mind in your programming style, as I have no quick solution for that. Maybe somebody could replace the message manager in the current Web Dynpro Tasks and then collect all the messages and report them back after execution. But I have not done any serious research on that.

The second problem is easier to handle. I have prepared a little utility class called the ParallelTaskMaster that wraps the execution of the threads and collects all exceptions when they occur and throws them in the end. Probably you could do the same thing for messages by handing around a message pipe that each thread can write to.

The ParallelTaskMaster class

Example of using the ParallelTask Master

The method master.executeParallel() starts the parallel tasks, collects the exceptions and throws them in the end.
I have also included the method master.executeSequential() for debugging. You can use this method to check if the performance really improves when you use concurrent execution compared to sequential execution.

Outlook to SAP Web Dynpro 7.20

From Reshma I get the following outlook:

“Also I would like to draw your attention to our new features in 7.20 which supports Asynchronous Web Dynpro Views.

The 7.20 release allows you to embed asynchronously running Web Dynpro application into Web Dynpro component.

Partial Screen Update– It allow rendering of screen although not all processing has finished on server side and

incrementally update/inject missing UI parts without blocking user interaction. Asynchronous view can provide preliminary UI content

Progress Monitor– provide visual feedback while waiting for asynchronous sever response.


Disclaimer: This is part of our roadmap presentation for Web Dynpro Java and can be subject to change and may be changed by SAP at any time for any reason without notice.”

To report this post you need to login first.

Be the first to leave a comment

You must be Logged on to comment or reply to a post.

Leave a Reply