Overview of the Java Persistence Infrastructure 

The AS Java supports both relational and object persistence based on the following programming models:

●      Relational persistence: JDBC

Using Open SQL/JDBC in the Persistence Layer

●      Object-relational persistence: Java Persistence API (JPA) 1.0 and JDO

More information about JPA:

Overview of the Java Persistence API

Using JPA in the Persistence Layer

Java Persistence Infrastructure

All these programming models are based on a common persistence infrastructure within the AS Java. The infrastructure is built on an Open SQL engine that processes all SQL statements created anywhere within the Java server. The main tasks of the Open SQL engine are to achieve:

●      Portability of the Open SQL language subset across all database platforms supported by SAP

●      Performance optimizations through client-side data buffering

●      Easy maintenance by appropriate database-independent monitoring and tracing facilities.

Database Access Layers

The following figure provides an architectural overview of the available database access layers of the persistence infrastructure within the AS Java. The Open SQL engine consists of three layers that build on each other.

Database Access Layers of Open SQL Engine

Open SQL

The Open SQL is an SAP-proprietary database abstraction layer, which is designed to provide portability across various database platforms and performance optimizations through client-side data buffering. All SQL statements that are issued through this layer are automatically checked against the Open SQL grammar.

More information: Open SQL Grammar

The semantic checks performed by the Open SQL engine are based on catalog information, which is provided by a database-independent API (the catalog API) for all tables that have been defined and deployed using the Java Dictionary in the SAP NetWeaver Developer Studio. The Open SQL engine evaluates exactly the meta information provided by the Java Dictionary. Therefore, this layer relies on an exact structural correspondence between a table definition in the dictionary and the real structure of the table in the database. This correspondence is guaranteed if structural changes on database tables are exclusively performed through the deployment tool of the SAP NetWeaver Developer Studio. The structure of a database table must not be changed by native database means; otherwise Open SQL engine may use invalid metadata when accessing a table.

More information about Java Dictionary: Providing Java Dictionary Tables and Data Types

The portable SQL layer provides the following important features:

●      Table buffer

The purpose of the table buffer is to speed up database queries by keeping frequently requested rows of a database table in a client-side buffer. It is completely transparent to the application program – that is, to take advantage of the buffer, you are not required to write specific code. It is decided at design time in the Java Dictionary whether a certain database table is buffered or not, and if so, which parts of it are to be buffered.

More information: Table Buffer

●      SQL trace

This is an on-demand log of selected SQL statements issued against the database within the Open SQL for Java framework.

More information: Open SQL Monitors

●      Statement pooling

This feature improves performance by providing a cache of SQL statements that are used repeatedly.

More information: Statement Pooling

How to Use Open SQL

Using Open SQL access is only possible if your application tables are created with the Java Dictionary and are physically deployed in the system database schema of the AS Java. The system database schema can only be accessed using the preconfigured system DataSource.

To be able to benefit from the Open SQL features when working with your application data, you only need to deploy a DataSource alias together with your application. This DataSource alias should point to the system DataSource.

More information: Deploying Data Source Aliases

Since Open SQL works only with the system database schema, it cannot be used in migration scenarios, in which the applications you are porting to SAP NetWeaver access database tables in an external database. In this case, you should use either Native SQL, or Vendor SQL.

Native SQL

Native SQL provides direct access to the database and allows you to fully exploit the functionality of the underlying database system. Unlike the topmost layer of the Open SQL for Java framework, the Native SQL implementation performs no checks regarding the portability of SQL statements or JDBC methods. All method invocations are passed through to the underlying vendor JDBC driver unchanged. The implementation of the Native SQL is simply a wrapper around the vendor-specific JDBC driver, but also provides two important enhancements:

●      SQL trace

More information: Open SQL Monitors

●      Statement pooling

More information: Statement Pooling

How to Use Native SQL

To use Native SQL, you need to configure the <sql-engine> property of the deployment descriptor of the custom DataSource you are deploying.

More information: Working with Data Sources

Vendor SQL

The concept of vendor SQL implies a platform-specific database driver that comes either from the database vendor or from a third party. SAP supports a set of database drivers that have been thoroughly tested on the various database platforms.

Using Vendor SQL is configured using the same property of the DataSource as described for Native SQL above.