ABAP developers have seen this platform mature over the last decade,
to the point that ABAP provides a highly integrated repository-based environment,
and even includes the tools — the ABAP Workbench’s Web Application
Builder, for one — to fully support fast and easy web development.
Then, with Release 6.20 of SAP Web Application
Server (Web AS), SAP delivered a companion Java runtime platform —
the SAP J2EE Engine. Now, with Web AS 6.30, SAP is working to bring some
of the design strengths and features of ABAP’s server-based environment
to a client-based integrated development environment (IDE) for Java. This
article introduces developers to the strides SAP is making — including
a brand-new, custom-made Java IDE — toward easier, more powerful
development tools for Java with the SAP J2EE Engine in SAP Web AS 6.30.
SAP’s Approach to Easy Java Development with SAP Web AS 6.30
Java developers generally prefer IDEs with a client-based environment,
residing on the local PC where they can implement their Java applications
and test them locally. Most Java IDEs also provide the tools, editors,
and wizards to help you develop applications that are strictly conformant
to the basic J2EE programming model, which typically divides enterprise
applications into several parts and corresponding technology: user
interface logic handled by JSP pages or servlets, business logic
implemented via Enterprise JavaBeans, and a database layer that
allows access to relational tables using JDBC or some higher-order persistence
model such as CMP.1
Thanks to SAP Web AS’s J2EE compliance,
there are Java IDEs on the market that can be used in conjunction with
SAP’s J2EE Engine. In Release 6.20, SAP offered add-ons, such as
the BAPI Browser, for these Java IDEs. However, there were some common
issues in SAP design scenarios that are not fully resolved within a pure
- Local development is fine. But if an application runs on a local developer’s
machine, it does not necessarily run on a central J2EE server shared
by several developers.
- Most Java IDEs get their Java sources from file-based versioning
systems that lack repository features, which makes distributed development
- Although you can provide add-ons to existing Java IDEs, these add-ons
typically do not get full control on the developer’s workspace.
- Many dependencies between the different parts of a Java application
— user interface, business logic, and database layer — are
not tracked automatically by current Java development environments.
Typically, in large projects, deploying incompatible archives to a J2EE
server can actually bring the whole J2EE server down.
It soon became clear that an integrated,
repository-based environment could not be fully realized simply as an
add-on to a Java IDE. However, most issues in this list are already resolved,
or simply do not arise, in a purely server-based environment such as ABAP.
As a result, SAP’s approach toward
achieving an integrated development environment in the SAP Web AS is to
take the strengths of a local, file-based designtime environment and combine
it with strong server-side integration comparable to the ABAP environment.
And, with SAP Web AS Release 6.30, SAP decided to develop its own Java
IDE, built on Eclipse (www.eclipse.org).2
The new SAP Java IDE is one key element
of SAP’s effort to make a better-handling and more powerful design
environment, touching all six major aspects of web development for Java:
- Web Dynpro for the user interface layer
- Portable database access for the database layer
- J2EE features that extend the business layer
- Java Dictionary for greater consistency of databases and user interfaces
- New infrastructure services — the Designtime Repository and
Component Build Service — for version control and automatic build
- Automatic configuration of the development environment
To start, consider the J2EE model’s user interface layer: JSP and
servlets do not provide the level of abstraction needed for powerful applications.
Most applications written in JSP are browser-dependent and difficult to
maintain. In a plain JSP application, layout and Java code are typically
mixed, making it really difficult to quickly adapt a user interface to
To address these concerns, SAP developed
a web user interface model called Web Dynpro, which runs inside SAP’s
J2EE Engine. Web Dynpro offers a model-driven, declarative approach to
web UI development. Many changes to Web Dynpro applications can be made
by modifying the model the application is based on — but without
having to rewrite the business logic, as you would with many plain JSP
SAP now also offers development tools designed
for the Web Dynpro implemented as Eclipse Plug-Ins. These plug-ins offer
a highly interactive and graphical user interface experience, including
an application modeler, Web Dynpro Perspective (see Figure 1),
that helps model Web Dynpros graphically.
||Modeler for the Web Dynpro
Portable Database Access
Just as the naive use of JSP can lead to unportable web user interfaces,
the direct use of JDBC is inherently database-dependent, leading to portability
problems of its own. One of the major milestones in ABAP technology was
the introduction of a portable database access layer though Open SQL.
Now, with Release 6.30, Open SQL is available for the Java technology
stack as well. Java applications can be written in a database-independent
fashion — whether using a direct relational interface or an object-based
interface such as CMP. All higher-order persistence models are piped through
the Open SQL for Java channel.
Here, too, SAP now offers support with
Eclipse Plug-Ins. From the tool-support side, a plug-in offers a precompiler
based on SQLJ to embed SQL statements in Java code directly, along with
a debugging environment where you can test your database access on the
embedded SQL level rather than on the compiled level.
The Business Layer
If you install Eclipse on your machine, you will find only the tool environment
for the standard edition of the Java 2 Platform (J2SE). From here, you
can write, test, and debug Java code, but without access to a J2EE server.
To integrate these functions into the J2EE Engine, SAP is currently developing
a J2EE perspective — also an Eclipse Plug-In — that allows you
to develop all parts of a typical J2EE application, including Enterprise
JavaBeans and enterprise archives, which are then ready for deployment
onto the local J2EE engine.
The J2EE perspective is the starting point
for deriving web services. Since Enterprise JavaBeans provide method interfaces,
it is quite natural to use this as a basis for web service definition
and proxy generation. However, since Enterprise JavaBeans should not be
exposed directly to the web, SAP’s J2EE perspective allows you to
derive web service definitions where only a set of methods is exposed
as the interface to the outside world.
The new Java Dictionary is another example of taking the ABAP approach
and developing its match on the Java side. In the ABAP world, the ABAP
dictionary is the central place for defining data type definitions, and
drives the activation of dependent development objects such as web dynpros
and the definition of underlying database tables. J2EE, on the other hand,
gives little information about database and user interface consistency.
The Java Dictionary helps to define central
data types and user interface services (input validation and value help)
that are used in Web Dynpro applications.
Java Development Infrastructure
The strength of ABAP’s development infrastructure is based on two
things: First, all development objects are centrally stored and versioned,
making it easy to identify the active version of each development object.
Second, if the active version is changed, the ABAP runtime environment
takes care to activate dependent development objects in what I like to
call a “lazy” fashion — that is, designed for the ease
of the developer. In ABAP, when the dependent development object is called,
the runtime environment instantly checks for consistency and will eventually
recompile the dependent development object. The environment takes care
of it for the developer.
It should be clear that this approach cannot
be followed in the Java environment. This would imply adding proprietary
extensions to the J2EE environment — a violation of the J2EE standard.
Instead, SAP has set up two infrastructure services that provide similar
programming ease: the Designtime Repository and a Component Build Service.
To overcome many of the limitations of file-based versioning systems,
SAP is developing a Designtime Repository for all kinds of development
objects required in the Java development process. Java sources,
XML files, etc., are stored in a hierarchy of files and folders
that are visible for client-side tools through the WebDAV and DeltaV
protocol. Each file or folder has its own version history. The definition
of workspaces allows you to group sets of files in a particular
version for a specific purpose (e.g., development, maintenance of
delivered releases, etc.).
Developers access the Designtime
Repository simply by checking out source files or synching files
for read access to their local hard disk. After local development
and test, they check their changes. The Designtime Repository manages
distributed versions and is capable of resolving version conflicts
when integrating changes from other workspaces.
Component Build Service
The Component Build Service is then responsible for producing runtime
objects for the sources in the Designtime Repository. The ultimate
design goal of the Component Build Service is to automate the build
process in an incremental fashion, comparable to activation of ABAP
Many Java build tools tend to build
everything from scratch, even when only a small change is made.
In a central test environment this means very long repair cycles,
since complete archives need to be rebuilt and redeployed to the
central server. A better approach is to manage the dependencies
between development objects directly.
With SAP’s component model for Java
programming, if a new Java source is created, the source must be assigned
to a development component (just as an ABAP program is assigned to an
ABAP package upon creation). Thus, development components are containers
for development objects — not only for Java sources, but also for
other categories, such as table definitions from the Java dictionary,
or Web Dynpro applications that consist technically both of XML files
and Java sources. Components may be nested to allow for structuring large
Java applications. Each component defines the elements that are visible
in “public” parts accessed by other components, much like ABAP
The assignment to components makes Java
applications much more maintainable and is the driver of the Component
Build Service. When a component is activated, the system checks where
dependent components need to be rebuilt. Only if all affected components
are (re)built successfully are they redeployed on a central server. This
strict approach ensures that only compatible archives are deployed on
Automatic Configuration of the Development Environment
Anyone who has worked on a Java project knows that setting up a consistent
environment on a local developer’s machine can take a serious amount
of time. Getting the right sources is usually done by accessing a central
versioning system; however, getting the supporting Java archives is typically
done manually by copying them from a build machine. This leads to situations
where different and often incompatible versions of development tools are
The solution to this problem in SAP Web
AS 6.30 is based on the compatibility of development components, with
compatible versions maintained in a central configuration. If a developer
starts his or her local Java IDE and checks out files that belong to a
given workspace, the IDE takes care to download any required archives,
or to update them if changes have been activated in the meantime. Thereby,
developers are notified, and the incompatibilities and inconsistencies
that are so difficult to track later in a central environment are removed
from the local environment. Figure 2 shows the Java development
process in SAP’s Java infrastructure.
||Development Process in SAP Web AS Java Infrastructure
SAP’s strategy toward a Java development environment for Release
6.30 of its Web Application Server is technically based on Eclipse technology,
and helps developers more fully leverage the J2EE standard. SAP delivers
plug-ins to Eclipse for all major aspects of web development, such as
Web Dynpro, EJB development, web services, and Java persistence.
SAP’s Java IDE is designed for a local,
PC-based development environment, but is embedded in a development infrastructure
that mediates between the local developer’s machine and the central
J2EE server by means of its central repository and its build and deploy
services. The component model for Java applications has many similarities
to the ABAP package concept, and provides the basis for many of SAP’s
infrastructure services, such as incremental activation of changes and
automatic configuration of the local IDE.
For More Information
Eclipse and Eclipse Plug-Ins will be delivered with SAP Web AS 6.30.
For further details, visit http://service.sap.com/technology.
2 Eclipse is
an open-source, Java-based framework for IDE development, based on technology
donated by IBM in 2001. Many independent Java tool vendors are now delivering
plug-ins for the Eclipse platform
Kessler joined SAP in 1992.
He is the Product Manager of the
ABAP Workbench and the SAP Java IDE
and is responsible for all rollout
activities. You can reach him via
email at firstname.lastname@example.org.