Skip to Content
Technical Articles

Effective WebDynpro Applications: Dictionary Optimization

“Let make applications faster…”

Here I’m going to discover some aspects of Java Dictionary usage in our WebDynpro application. The story is actual at least for NW 7.0.

Common application Java Dictionary seems to be a good idea

In our case we had a common Dictionary DC with lots of simple types declared. The number of simple types were about 80. All the types were referenced by a set of WebDynpro components (more then 10). The components referenced the dictionary DC and used the types in its controllers’ contexts.


Component structure with a common Java Dictionary at design-time

Having such a Local dictionary with common simple types brings the following positive aspects to the application architecture.

  • Consistency of UI fields behaviour and lengths.
    In the type characteristics we declared the basic format properties – Max Lengths for all String types and Format patterns for Date types. This guarantied identical field validation rules and lengths across all the UI components.
  • Saved time, money and consistency in a translation process.
    Each textual label should be translated to another language just one time.

Though such heavy Java Dictionary causes a bad performance

Let me try to explain why it’s so. The bottleneck related to a big Java Dictionary (Local Dictionary) could be seen with help of any tool for Java profiling.

In the case with our application I ran Java profiler and I found out that more then 50% of the initial time of an application opening for a business user formed by the phase of simple types loading. In other words, loading of simple types from Local dictionary referenced by WebDynpro components is a really time consuming task, directly proportional to the number of referenced types.

The figure below shows a small extract from the invocation stack trace which happens at a time of WebDynpro component creation for any user session. (do not pay attention on a the absolute numbers and the numbers of method invocations, because they are very relative):

<image was deleted by SCN3.0 migration>

Invocation stack of a WebDynpro component initialization: includes slow reading of simple types from XML

Analysis of the Java profiler results allowed to arrive to the following conclusions:

1. Every time a WD component is being created it tries to load all the referenced  simple types (structures) declared in Local Dictionaries directly from .dtsimpletype (.dtstructure) files. This is very slow because in fact *.dtsimpletype (*.dtstructure) represents XML and all the XML files are being parsed again and again for each user session.

2. Neither Local Java dictionaries nor its content (simple types and structures) are cached by WebDynpro framework. Just not cached(!)

So mainly the potential problem with a performance here is caused by the fact that Local Java Dictionaries are not cached anyhow at runtime. When I got to the point I was wondered, because I was sure that, for instance, RFC Model types were cached. Article

Metadata Cache invalidation for Webdynpro Adaptive RFC Models

is exactly about the dictionary cache. And in the article is even explained how the cache can be reset.

Further analysis allowed to see the key difference between RFC Model dictionary and Local dictionary – Model dictionary has a proper name and Logical System name assigned. The logical system name is nothing but name of WebDynpro JCo destination. And the WebDynpro dictionary cache is working only with named dictionaries (it keeps dictionary name-to-dictionary instance mapping inside).

At the same time Local dictionaries are always unnamed. The fact gives the idea how we can speed up Local Dictionary usage – we need to give it a name and put it in the WebDynpro dictionary cache somehow.

Step 1: Move Java Dictionary from Dictionary project to WebDynpro project (optional)

Well, first of all I had done it because I could do it. In our case we had not got any tables in the dictionary. So our simple types and structures were only referenced by WebDynpro components, not by dictionary tables. In the case they can be easily moved to some dedicated common WebDynpro DC (existing or specially created for the purpose).

There is one helpful thing to know and the thing is not explicitly mentioned in SAP documentation. Dictionary project is not the unit deployable on NW AS server ❗ This means that all the simple types and structures declared in Dictionary project can be only deployed to a server within any WebDynpro DC which references the dictionary.

This means that the same simple type (structure) can have several identical copies deployed on a server if the Dictionary DC is referenced by more then one WebDynpro DCs. The same compilation (JAR) with simple types (structures) can be transported within several parent WebDynpro components:


Common Dictionary DC not participate in deploy-time/runtime processes

Such a specific way of dictionary deployment has some consequences:

  • If you change something in the existing dictionary you have to rebuild/redeploy all the WebDynpro components that use the dictionary. In other case the change will not be visible to all parts of the application.
  • Now it’s clear why Local Dictionary types/structures are not cached by WebDynpro framework. Simply because at runtime there can be several application class-loaders for the same type or structure.

If we move all the dictionary types/structures from Dictionary project to WebDynpro project the deployment scheme will change from distributed to a central one:


Common dictionary located in WebDynpro DC at deploy-time/runtime

Again, the step is not obligatory for the next two steps. I have not checked this explicitly, but I think the cache will work with types located in Dictionary project too.

Step 2: Convert Local dictionary to named Logical dictionary

Since we cannot create a named dictionary with means of NWDS (model dictionary can only be created as a part of Import Model wizard), let do it manually on the file system’s level. The procedure we are going to do is opposite to the procedure described in blog Copying Adaptive RFC Model Dictionary types (NWDS 7.0)  (Copying Adaptive RFC Model Dictionary types (NWDS 7.0)). We will convert Local Dictionary to named Logical Dictionary whereas the blog is about Model Dictionary -> Local Dictionary transformation.

<DtLogicalDictionary logicalSystemName="XAPP_DDIC_SYS_NAME" name="XAPP_DDIC"
     package="com.epam.test.ddic" masterLanguage="en"
     xmlns="" xmlns:IDX=""
     mmRelease="6.30" mmVersion="2.0" mmTimestamp="1083659731299" > 
  1. Reload+Rebuild your Dictionary project (or WebDynpro project if it’s a location of your dictionary).
  2. After this you’ll see the following changes with the dictionary:
    1. A new logical dictionary will appear.
    2. All your types/structures will be moved from a local dictionary to new logical dictionary:

<next text was deleted by SCN3.0 migration>

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