JDBC DataSource Deployment in NWDS Subscribe

Oliver Kohl Print

Business Card Permalink
Company: MIBS GmbH
Posted on Apr. 17, 2007 01:31 AM in Application Server,
Enterprise Portal (EP), Java Programming, SAP NetWeaver
Platform
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 sap<db name>db
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.
<jdbc-1.x>
...
<password encrypted="false">mysecretpassword</password>
</jdbc-1.x>

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.
<data-source>
<description>DB for Supplier Portal App</description>
<data-source-name>SupplierPortalDB</data-source-name>
...
<sql-engine>Native_SQL</sql-engine>
...
</data-source>

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.

Oliver Kohl is a senior consultant and ABAP/Java developer for MIBS GmbH in
Mülheim/Germany.