The AS Java supports both relational and object persistence based on the following programming models:
● Relational persistence: JDBC
● Object-relational persistence: Java Persistence API (JPA) 1.0 and JDO
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.
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
The topmost layer of the Java persistence infrastructure is designed to provide portability across various database platforms. All SQL statements that are issued through this layer are automatically checked against the 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 so-called 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.
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
● Open SQL Monitors
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
● Open SQL Data Browser
This is a tool for viewing the content of database tables residing in the JDBC System DataSource.
More information: Open SQL Data Browser
● Statement pooling
This feature improves performance by providing a cache of SQL statements that are used repeatedly.
More information: Statement Pooling
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 DataSource Aliases
Given the fact that 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 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:
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 DataSources
The concept of vendor SQL implies the database 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.