Dealing with databases on SAP NetWeaver Java stack is is usually done by using JDBC. Each installation of an app server has a standard db schema named sapdb which SAP encourages you to use for your applications via OpenSQL , SAP's database abstraction layer for Java. There are a couple of advantages that you get by using OpenSQL, e.g. support for Java Dictionary (which lets you deploy your table definitions and data types from NWDS), Table Buffer, Statement Pool, SQL Checker and SQL Trace. Further by using SQLJ, part of the OpenSQL framework, you get compile time checks for your SQL statements and that's one thing we all really like in ABAP, do we?

In order to connect to this standard schema you would probably use a resource reference to connect from EJB like this:

java.sql.DataSource ds =
  (java.sql.DataSource) jndiCtx.lookup(“java:comp/env/datasourceRef”);

When connecting from outside of EJB you should use a DataSource Alias (DSA) instead. You define a resource reference and DSA as parts of your application. By that your application is easy portable once you need to move it to a new database instance or schema. You'll find more on this in the DataSource Alias FAQ.

Welcome to RL

When you find yourself in a situation where you can't use the standard schema, you'll face a couple of problems you may wouldn't expect.

1. OpenSQL is only supported in the standard schema. Each additional schema has to use either Native_SQL or Vendor_SQL. That means you'll loose a couple to many of the advantages mentioned before, because they are only supported in OpenSQL.

2. It may not always easy for a developer to get the necessary access to the server for setting up a new DataSource and as a developer being dependent from an administrator isn't always desirable.

There are a couple of ways to create a new DataSource and most of them need an administrator account or direct access to the servers file system.

1. Probably best know procedure is to use our all favorite admin tool Visual Administrator, a rich client but you'll need an admin account for that. (docs@help.sap.com ).

2. Second best known is probably the web based version using NW Administrator but to get access to it you'll face the same hurdles as with VA. (docs@help.sap.com ).

3. For the ones who prefer to use a shell there is the MAKE_DATA_SOURCE from DBPOOL. Be sure to have file system access on the server here. (docs@help.sap.com ).

4. There is a fourth way to deploy your new DataSource as a part of your application. The only thing you need here is the SDM password that you probably already have for your usual deployments. The official documentation is a little weak on that point. So let's take a look at the necessary steps for this task.

DataSource Deployment

A DataSource definition used in a NW Java stack is described by a XML file that is based on a data-sources.dtd. You can generate a proper data-sources.xml file from this DTD definition. Another way is to create a new DataSource in Visual Admin under Services->JDBC Connector and export it as shown below.

That way you already have the necessary information filled into the right place. Just make sure to set for the +password +tag the attribute encrypted to +false +and provide the right password.

Next you have to store both files data-sources.dtd and data-sources.xml into the META-INF directory inside your Enterprise Application Project so that they will get deployed as part of your .ear archive.

That's it and with your next deployment you'll find your new created DataSource on your app server. Access to it is the same as for a DSA.

The Sad Part

One thing to keep in mind is that when you go with an alternative db schema you can't use Open_SQL anymore because this is only supported for the standard schema as mentioned already above. You therefor have to switch to Native_SQL, which has to be configured in your DS definition like this.

Another option is to use Vendor_SQL but you should do this unless you have some good reasons and know exactly what you're doing. You can find more about the differences in this SDN article.

Welcome to part 2 in our series about the extensibility of NetWeaver Developer Studio (NWDS) through plug-ins.

In the Pimp Up My NWDS Part 1 I showed up a way to install and manage additional plug-ins in NWDS without modifying the standard file structure to much. This approach gives you more flexibility when doing an upgrade and also helps you maintaining the same set of plug-ins for two different NWDS installations on the same machine, e.g. for NetWeaver04 (6.40) and NetWeaver2004s (7.0).

In this part I want to show you a plug-in that will check your code using static code analysis to give hints to possible bugs and anti patterns and inefficient code. This way it will help you write better and often faster code.

PMD

PMD finds possible problems and shortcomings in your programs by analysing the Java source code. It does this by using a set of rules that you can run on your programs source code to find unused variables, unnecessary object creation, empty catch blocks, and so forth. Rules in PMD are defined in an extensible way that let’s you write your own rules specific for your organization or project.

PMD is already covered in a Analysing your Java code with PMD so I won’t go into many details but show you how to use it in NWDS. If you want to get deeper knowledge about PMD there is also a book PMD Applied written by one of its lead developers, Tom Copeland.

As most of today’s plug-ins PMD is currently developed for Eclipse 3.x but there is one brave hero still maintaining an Eclipse 2.x version named pmd-eclipse-2.3 that is only one minor version behind the official release. You can get it at PMD’s official download site. After downloading follow the instructions for installation covered in Pimp Up My NWDS Part 1.

Correctly installed PMD will give you two ways to check your code in NWDS. One way is to trigger the code checks manually against single files, folders or projects. Therefore you have to select a node or element in the Navigation view. Right click the element and the resulting context menu will show an entry PMD with several subentries. Select Check Code With PMD to start it.

The other way is to enable PMD in the project properties. Here you can also define a specific rule set for you project. This way code analysis will executed each time a file is added or saved.

The results of the code check will be displayed in the Tasks view or in the special PMD Violations view, which gives a more tailored display and more specific filtering options.

The PMD Violations view gives a more detailed view on the detected problems. It includes e.g. a severity level for each entry to help you prioritize your pending violations or filter the displayed entries. In case you don’t remember the cause of the violation you can also get more detailed information for each of the violated rules by selecting Show Rule from the context menu for an entry.

Either if you use PMD for your own project or if you introduce coding standards into an organisation it is a good practice to tailor the number of rules to the specific needs. In a project this set can be defined by a joint decision and then imported into each single NWDS.

To configure a NWDS global rule set (project specific rule sets can be defined in the project properties) open the Preferences window and go to the PMD->Rules Configuration entry. Here you can see a list of all the available PMD rules. From this list, you can go through the rules, adjust priorities, modify any of the other rule-specific properties, or remove any rules you don't need. If necessary export your defined set and import it to any other NWDS.

That’s basically all you need to know about PMD in an NWDS environment. Let’s hope that the Eclipse 2.x version will be maintained another couple of month (or years?) until we get our hands dirty in a New York (a.k.a. NetWeaver 7.1) project.

Checkstyle and Findbugs

There are two other well knows tools that can help you in your development process in a similar way like PMD.

Checkstyle by Oliver Burn also analyses your code, like PMD, using the Java source. There is an Eclipse plug-in available named CheckClipse. Even though you still find a compatible 2.x version on the download page it won’t be maintained anymore and is frankly two years old now. But maybe you like it and give it try anyway or use the stand alone version.

Code analyser FindBugs by Bill Pugh takes a different approach on this topic. It examines your class or JAR files looking for potential problems by matching your bytecodes against a list of bug patterns. Checking is also done using a set of rules but because it works on the bytecode the results of course very different from what you would get with PMD or Checkstyle. Sadly the Eclipse 2.x plug-in situation is the same as with Checkstyle so if you want to try it out in NWDS you have to deal with an old version from 2004 or use the stand alone version.

Conclusion

PMD and similar tools can help you significantly reduce the time and afford involved in code reviews. All code conventions and best practices, which can be described by rules, can automatically be verified in the development process. Seamlessly integrated into your IDE they popup if necessary and get out of the way otherwise. On the other hand any automated code analysis won’t replace human code reviews, as there will always be errors that can’t be detected by machine analysis.

That’s it for part 2 of Pimp Up My NWDS. The last thing that’s missing is to point you to a nice weblog by Maksim Rashchynski The Story About How 2 Eclipse Plugins helped me to make a lot of points on SDN forum were he talks about JadEclipse and JAR Class Finder, two plug-ins which helped him getting points in the forms. Thanks Maksim!