ITC Server

I came across a FAQ document called Coexistence of ABAP and Java at SDN. Here there are some quatations.

My company is running ABAP systems. Do we have to completely move to the Java technology in the future?

Certainly not! The Java runtime, as a part of the SAP Web Application Server, is just an extension to the ABAP runtime and it obviously does not replace the ABAP technology. Rather, SAP applies the long-lasting experience gained with ABAP systems to the new Java/J2EE world. A good example illustrating the interaction of both Java and ABAP frameworks is the use of “Web Dynpro for Java” for generating modern web-based user interfaces and ABAP for providing the business logic.

Where should I store database tables of my combined ABAP/Java system?

Please keep the database storage of your Java- and ABAP-based components separate:

• ABAP components access database tables stored in the “ABAP” database schema.
• Java components access database data stored in the “Java” database schema.
• Best, there is one database instance keeping both ABAP and Java schemas, namely the database instance that is already pre-configured during the SAP Web AS installation.

Why does SAP provide a separate persistence framework for Java instead of simply enlarging the existing Open SQL for ABAP framework?

There are some major reasons why SAP has decided to introduce the separete Java persistence framework “Open SQL for Java”. Not surprisingly, the highest priority has been to preserve the well-proven stability and reliability of the database access from within ABAP applications - now running on the common SAP Web AS platform.

In addition, the alignment of the Open SQL twins differ a little bit. As SAP?s own framework, Open SQL for ABAP is perfectly tailored to achieve an efficient and reliable database access. In contrast, Java applications running on top of SAP Web AS will comply with J2EE and other popular Java standards. This results in slight differences in the database access area, for example in regard to supported portable data types, DML statements, and other ABAP-specific optimizations not available for Java.

Does SQL on the Java side feature the same expressiveness as SQL for ABAP?

Yes. The SQL set available to Java components is even more expressive. For example you can use Unions and expressions as well as queries in SET clauses of UPDATE statements.

Background: The supported, portable SQL set for Java, called “Open SQL Grammar” comprises a subset of the SQL 92 standard almost identical to the SQL 92 Entry Level limited to queries and changing (DML) statements. In addition, Open SQL Grammar contains some important JOIN variants (INNER JOINs and LEFT OUTER JOINs with slight limitations) as well as the SELECT … FOR UPDATE statement. You can use the SELECT … FOR UPDATE statement to select separate table rows with an exclusive database r/w lock. Please refer to the SAP Web AS documentation for a comprehensive description of the Open SQL Grammar.

Moreover, there is also a possibility of activating the whole SQL set supported by the proprietary JDBC driver. For example, you can switch the check-off for a specific statement. Namely, the Open SQL for Java framework is checking your code against Open SQL Grammar only if you use connection pools labelled “Open SQL”. If required, you could configure and access connection pools labelled “Native SQL” or “Vendor SQL”. In the both cases, your SQL statement gets forwarded “as is” to the target JDBC driver. Please note that we do not recommend this scenario because it affects the portability (and thus the valuable “out of the box” feature) of your database access implementation.

Because SAP strongly focuses on adhering to standards for Java, SQL for Java doesn?t support the proprietary SQL enhancements available in ABAP. Also, on the ABAP side there are some SQL statements available that are closely tied to the features of the ABAP language - for example the integration of high performing “internal” tables - not defined in the Java standards.

Does Java Dictionary provide the same built-in, pre-defined portable types as ABAP Dictionary?

No. For example, the types CUKY, QUAN, CLNT, and ACCP aren't available in Java. The types DATS and TIMS do not directly correspond to the JDBC types DATE and TIME (the types DATS and TIMS in the ABAP dictionary are simple; whereas the JDBC types DATE and TIME are mapped to timely database types). In contrast, the Java Dictionary types “date” and “timestamp” are not available in the ABAP dictionary.

Background: The built-in types of Java Dictionary map to standard JDBC types. They are proven to behave identically on each supported DBMS platform.

How can I view the content of the Java database schema?

There is nothing like a SE16 (of ABAP) in Java.

This entry was posted on Thursday, June 2nd, 2005 at 6:31 pm and is filed under . You can follow any responses to this entry through the RSS 2.0 feed. You can leave a response, or trackback from your own site.