Friday, November 9, 2007

Dynamic images in Web Dynpro for Java

It’s a common problem displaying dynamic images in Web Dynpro 4 Java. The image widget takes only an URL as source argument, and not an byte array as you might expect.

There is two solutions to that problem, one is to store the images on the web serves file system an generate an URL based on the filename and location. This solution involves setting up a HTTP Alias in the WAS and manually maintaining the image cache in the file system of the WAS. How to set up the alias and make it work is documented in detail in the blog of Renjith Andrews called Creating an HTTP Alias in WAS. As the seems to be the common approach, I cannot recommend it since the overhead of maintaining the image cache will be to much to handle.

In stead I will suggest another approach where you do not need the local file system nor do you need to maintain the image cache. My recommendation is utilizing the IWDResourse.

The following little piece of code will show you how to translate a byte array of an gif image to an URL:

// get the image data from somewhere
byte[] data = new byte[1024];

// Create a cached web resource using the WDResourceFactory
IWDResource res = WDResourceFactory.createCachedResource
(data, "image.gif", WDWebResourceType.GIF_IMAGE);

String url = res.getUrl(0); // 0 means "AUTO"

For a JPEG image the process is the same but use WDWebResourceType.JPG_IMAGE as the last argument of the the call to the factory.

It is as simple as that. Since it is a cached web resource, you can add it to your context for storage while the application is running so you won’t have to waste CPU cycles to create the same IWDResource over and over again. Ad by adding it to the context it will get automatically cleaned up when the application session ends.

Working with SDM with limited rights

As a portal developer, it is usually the standard, that you have unlimited rights to the development server you are working on.

But what happens when this isn’t the case? Well - SAP has provided a client tool for connecting client side to the SDM, without having OS access to the server you are working on.

Thus they eliminated the need for hacking the installation out from the server You are working with.

The old way of doing this, would be to extract - and package the SDMinstallation yourself, but when working with a client where you cannot access the server’s filesystem, the new method is preferred.

To install the SDM locally, go to http://service.sap.com - and browse the following tree:

SAP Support Portal -> Downloads -> Support Packages and Patches -> Entry by Application Group -> SAP NetWeaver -> SAP NETWEAVER -> SAP NETWEAVER 7.0 (2004S) -> Entry by Component -> Developer Workplace -> SAP SOFTW. DELIV. MANAGER 7.00 -> #OS Independent

Find the support stack level you need, and you will get the client installation (add it to your download basket, and download it with SAPDownload manager).

The installation is a .jar file, which is kinda strange - because of what you need to do next.

Unpack the archive to a temporary folder, for example c:\temp.

Open up the folder, and launch the file “Install.bat”.

Accept all default values (press ENTER 7 or 8 times), and the installation script will start.

After it’s done, the sdm can now be launched from c:\sdm_home\remotegui.bat

And that’s it :-)