Skip to Content

class=”sapTxtSml” style=”font-weight: normal;”>

After tiring application build times and running into issues during performance testing , we derived some conclusions on how Adaptive RFCs models should be used within a Web Dynpro application. Hope this would be useful for others ,because the points below weren’t obvious to us when we started off.

1.)Connection usage

You have the option to create model objects for each Remote Function module or

alternatively the option to encapsulate multiple proxy objects under one model object by

selecting multiple Function Modules during the import. The biggest advantage in doing this

is connection sharing , typically the framework creates exclusive connections for each model

objectand so if I had a set of say 5 function modules for a screen, the that would mean 5

connections as long as the screen is presented. This is if the model object is created with


But if the proxy objects are connected under one model object then only connection is

created and shared accross all proxy objects. This should probably be the case if the calls

are sequential.


Fig 1

Fig 2

class=”sapTxtSml” style=”font-weight: normal;”>
Fig 1 shows explicit proxy objects for each Function Modules. Fig 2 shows how proxy objects are grouped.

class=”sapTxtSml” style=”font-weight: normal;”>

2.)Separting model objects into a separate DC

It is a better strategy to separate models into another dc and expose them as public parts

. Typically models are objects that least change during development especially if the

interfaces have been defined thoroughly. Since during buildtime it is optional to build

dependant components, the component that hold the models can be excluded from the build

thereby reducing build time as well as deploy time.

3.) Connection life time

I have been successful in using only two types of Model scopes APPLICATION_SCOPE ,TASK_SCOPE. These scopes determine the life time of the model objects and thereby affects the connection lifetime.

Model objects created with the APPLICATION_SCOPE have their instances persisted as long as the application is alive,in real world terms as long as the application hasnt timed out, or has’nt been navigated away or till the point before browser closure.

Model objects created with the TASK_SCOPE have their instances persist only during the life time of the call,so if you where viewing SM04 you would see an instant creation and closure of a connection.

The Service Contoller pattern within Web Dynpro helps in easy mapping of model nodes to controller and also generates the model initializatiion and execution code.
Typical code sample for initialization would be.




Model objects initialized in this manner would have the default scope of APPLICATION_SCOPE.Scope overriding is possible during initialization time by specifying the scope during intialization


CompanyCodeList compCode = (CompanyCodeList)WDModelFactory.getModelInstance(CompanyCodeList.class, WDModelScopeType.TASK_SCOPE);

Bapi_Companycode_Getlist_Input bapIn = (Bapi_Companycode_Getlist_Input)




Weirdly the connection dropping behaviour for APPLICATION_SCOPE is noticeable only if the Connection Timout setting(Available in the Web Dynpro Content Administrator) it set to 0.
Any other value here makes the connections resident and halves them at some regular intervals even after a browser close.


There is a way by which Model objects can share connection between them and thus avoiding creation of multiple connections.This is by using the setConnection provider method. Thus if you have a Master model defined you can pass the model object into other model objects through their setConnectionProvider(IWDDynamicRFCModel arg0) method. This will allow model objects to share connections.

5.) Record locking

It is possible for Web Dynpro to lock records using standard SAP provided Function modules. But to ensure that the record remains locked it is necessary reserve the connection that was used for locking and be made unavailable for other models and also the connection should remain open as long as the lifetime of the screen. This becomes similar to locking records through SAP Gui . This can be easily achieved by having separate models for locking RFCs defined with APPLICATION_SCOPE and isolating its connection by not grouping with other model objects.

To report this post you need to login first.


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

  1. Manuel J. Schaffner
    We are using a technical user to connect to the backend system because the application is run in the  anonymous context of the portal.

    When using APPLICATION_SCOPE there is one connection opened for every RFC-module and it is being kept until the timeout from the backend, causing a lot of inactive connections being generated – this is because the session handling in the portal is not the same for anonymous users and authenticated users. We then decided to use TASK_SCOPE and this works perfect.

    More information is also available at:
    Disconnect method
    How to close a model object connection for Adaptive RFC?

  2. M. Geuze
    Hi Pran Bhas,

    I am very anxious if you know an answer on the following question:

    If two model objects with different proxy objects are using the same JCo destination if they are sharing the connection.

    So are model objects always using there own connections or share they there connections with other model objects which are using the same JCo destination.

    Kind regards,



Leave a Reply