Skip to Content
Technical Articles
Author's profile photo Siarhei Pisarenka

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.

image

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

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:

image

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="http://xml.sap.com/2002/10/metamodel/dictionary" xmlns:IDX="urn:sap.com:DtDictionary.DtLogicalDictionary:2.0"
     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>

Assigned tags

      2 Comments
      You must be Logged on to comment or reply to a post.
      Author's profile photo Former Member
      Former Member
      Very nice article! Which profiler did you use to detect the bottleneck?

      Best Regards,
      Andreas

      Author's profile photo Siarhei Pisarenka
      Siarhei Pisarenka
      Blog Post Author
      Hi Andreas

      Thanks for your interest...

      I used JProfiler 5.1 (http://www.ej-technologies.com/products/jprofiler/overview.html) for the purpose. It was enough to evaluate only CPU time. Actually I was restricted to the profiler used in the company 🙂

      Regards, Siarhei