With the R/3 system you're running now, we went to great lengths to shield
you from various application interfaces. A developer working with an R/3
4.x system, for example, doesn't have to be concerned with the interface
between the R/3 core system and its modules such as FI, CO, or MM. We
made the changes to the R/3 core, and that was that. The inner workings,
from an interface perspective, were invisible. Nor did you have to be
concerned with relationships between modules, since all modules were delivered
in a single release. All that changes with R/3 Enterprise.
R/3 Enterprise, SAP's successor to the R/3
ERP solution, introduces a new architecture. At its core is a very stable
application platform that has been purposely decoupled from add-on components.
With this new architecture, SAP customers are able to integrate just the
modules and solutions they need and never have to tinker with the R/3 Enterprise
core - it remains virtually unchanged. These changes usher in a slew of
interfaces that will connect R/3 Enterprise to the add-ons you want.
As a result, developers will find themselves
taking a hard new look at both components and interfaces:
- Components: In previous releases, all modules were delivered
together, but with R/3 Enterprise, components can be activated separately.
As a result, each component must be able to verify that other required
components are present. This means that clear definitions and boundaries
between components take on a new importance.
- Interfaces: In previous releases, the application core logic
was modified to support an industry solution (PS, for example). Now
some industry solutions will be delivered as R/3 Enterprise Extensions
(see "A Brief Introduction to R/3 Enterprise"). The result
is that additional core interfaces will be required.
A Brief Introduction to R/3 Enterprise
The figure below shows the building blocks of the R/3 Enterprise
The core is based on technological foundation at the bottom, the
SAP Web Application Server Release 6.20. On the 6.20 technology
stack lies a small software layer, the Application Basis, which
contains all data definitions common for all applications, such
as Company Code.
On this is the R/3 Enterprise core. In the mid-1990s HR was decoupled
from Financials and Logistics (APPL), resulting in a small reuse
layer, APPL_TOOLS, that serves both APPL and HR. These components
are the only elements of the stable R/3 Enterprise core, which roughly
corresponds to a 4.6C application core.
At the very top are the structure packages (more on this later
in the article) for R/3 Enterprise Extensions, which could include
HR, Retail, and CFM, among others. (This set of add-ons is not necessarily
complete and is subject to change.) All Extensions are developed
independently from each other, but in the same system to ensure
that they can be integrated - whether a customer activates all Extensions
or only some of them.
Fortunately, two technologies are already
in place to help you design interfaces and build application components:
packages and Business Add-Ins. Both come with their own maintenance
transactions and are already well integrated into the Development Workbench.
While packages help ensure that software components
can check on the availability of other necessary components, Business Add-Ins
provide flexible interface techniques, so that a component, such as the
R/3 Enterprise core, can communicate in a flexible way with several Extensions
and other add-on components installed in the same system.
Packages and Business Add-Ins are based
on concepts as familiar as development classes and customer exits. While
these new technologies are the natural extension of their predecessors,
the emphasis here is on coupling independent software components, such
as R/3 Enterprise Extensions.
This article gives you a preview of how
packages and Business Add-Ins will work for you - and how you can begin
implementing some of these technologies now - as you look ahead to using
Rely on Packages to Ensure Complete and Well-Defined Components
Packages help to analyze the dependency of Extensions and other add-ons
and to structure the component-based architecture of R/3 Enterprise. In
fact, with R/3 Enterprise, all development classes are automatically "migrated"
to packages, and the term "development class" has actually been
substituted with the term "package" throughout the system. Figure
1 shows the new property dialog window for packages, the Package Builder,
available via transaction SE80 as of Release 6.10.
Packages are collections of development
objects (much like Java packages are collection of Java classes), but
in addition to classes or function groups they also contain development
objects from the ABAP Dictionary (e.g., table definitions, domains, data
elements). In fact, every object with an entry in the global object catalog
(table TADIR) belongs to a package.
Packages are thus the successors of development
classes, but with additional semantics regarding visibility and use access.
Some of the features of packages include:
The most obvious difference at first glance between development classes
and packages is the latter's nesting capability. As in the example in
Figure 2, every package (P) can contain other packages, which allows
for better grouping than a flat organization would permit.
You can combine several packages to form
a main package that does not contain individual development objects and
corresponds to a "software product." Several main packages form
a structure package, which will serve as a unit of maintainability (e.g.,
upgrade). Extensions will be delivered as structure packages, and the
components of R/3 Enterprise are all structure packages.
and Package Interfaces
To better support the use relation between software components that
offer certain services ("server packages") and their users ("client
packages"), each package has zero or more package interfaces
(IF), see Figure 3. With package interfaces, the names of development
objects (classes and tables) in the package are visible to external users.
||Packages and Package Interfaces
A use access is simply an enumeration of the package interfaces
that another package needs to have access. If a development object is
both defined as visible and declared as use access, a reference is valid
(see Figure 4). With use access you can quickly identify the packages
required by another package.
To ensure that your packages are structured
correctly, you can run checks to find violations of package boundaries.
However, don't be concerned about introducing artificial package boundaries
between application modules that already exist in your system. In R/3
Enterprise, references to already delivered development objects of the
R/3 core are generally allowed. It is references between Extensions for
R/3 Enterprise that are handled more strictly.
Use Business Add-Ins to Connect R/3 Enterprise and Components
Business Add-Ins, a technology based on ABAP Objects interfaces, are
designed as an interface technique so that a relatively stable component
can communicate flexibly with several components in the same system. This
makes them a good candidate for the outbound interfaces needed to link
the R/3 Enterprise core to Extensions and other components (see Figure
Recall that ABAP Objects interfaces are,
roughly speaking, a collection of "abstract" method signatures
that describe the type of data that is transferred back and forth when
one software component (such as the R/3 Enterprise core) calls another
component (such as an R/3 Enterprise Extension).
ABAP Objects interfaces strictly define
the coupling between software components. The compile-time environment
checks the validity of the method signatures and their proper use in the
calling environment, and likewise checks the callee side, to ensure that
all methods are implemented accordingly. (Compare this approach to earlier
techniques based on function modules, where the distinction between interface
definition and implementation is not as clear.)
Other new features in Business Add-Ins
developed since Release 4.6A, when they were introduced, include:
||SAP R/3 Enterprise Core Using a Publish and Subscribe
and Subscribe Scenarios
Establishing interfaces also allows for an implicit layer that offers "publish
and subscribe" communication scenarios, as shown in Figure 5. In these
scenarios, more than one software component is hooked onto the core that
responds to state changes and event notification typical of the R/3 Enterprise
core. Support for publish and subscribe was one of the major requirements
in Release 4.6, and now, with 6.10, it allows for changing of parameters
Allowing additional software components to hook into the core logic at predefined
places, as with publish and subscribe, is not new. Customer exits already
offer an easy way to find the places to enhance a standard solution to the
customer's specifications. However, they do not permit you to couple more
than two software layers.
With SAP Web Application Server 6.10,
Business Add-Ins were updated to extend screens. Now an application programmer
is free to call an empty subscreen and register this call in the Business
Add-In Manager (transaction SE18), and a subsequent software layer can
implement this screen using a function group.
If you already have customer exits in place, migrating to Business Add-In
definitions is quite simple. Once a customer exit is migrated, a corresponding
step in SPAU allows the customer to migrate its implementation after the
upgrade. If the customer exit is not migrated, the existing implementation
still remains active. However, note that SAP won't deliver new customer
exit definitions in the future.
In addition to the various industry approaches, SAP R/3 and modules
such as HR are available in many different country versions. To separate
the different implementations from each other, Business Add-Ins allow
you to define filter criteria, or filter types, that enable multiple
implementations of a given interface.
Filtering has been available since R/3
4.6A, but additions have been made to support structured filter
types to identify combinations of industry solutions and country versions.
Business Add-Ins and Packages provide the flexible interface and component
technology required for the R/3 Enterprise core to communicate with several
Extensions in the same system.
As you look ahead, it will serve you well
to begin using customer exits, migrating to Business Add-Ins, and familiarizing
yourself with packages to take full advantage of the flexibility of R/3
To help developers acquaint themselves
with these technologies, both topics were covered in the hands-on session
presented at SAP TechEd 2001 entitled "Overview of New Workbench
Detailed information will also be available
in the online help of transaction SE18 (Business Add-Ins) and transaction
SE21 (Package Builder).
It should be clear, however, that some restrictions apply when invoking
several software components through Business Add-Ins. No assumptions can
be made in which such components are called, and only data that is disjointed
for the different Extensions can be communicated back.
Karl Kessler joined SAP in 1992. He is the Product Manager of the ABAP
Workbench and is responsible for all rollout activities. You can reach
him via e-mail at email@example.com.