GRC
HR
SCM
CRM
BI


Article

 

A Preview of Component Technology in R/3 Enterprise

by Karl Kessler | SAPinsider

January 1, 2002

by Karl Kessler, SAP AG SAPinsider - 2002 (Volume 3), January (Issue 1)
 

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 core.

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 R/3 Enterprise.

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:

Figure 1 Package Builder

Nesting

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.

Figure 2 Package Nesting

Visibility 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.

Figure 3 Packages and Package Interfaces

Use Access

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.

Figure 4 Use Access

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 5).

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:

Figure 5 SAP R/3 Enterprise Core Using a Publish and Subscribe Scenario

Publish 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 as well.1

Customer Exits

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.

Customer Exit Migration

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.

Filtering

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.

Summary

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 Enterprise.

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 Tools."

Detailed information will also be available in the online help of transaction SE18 (Business Add-Ins) and transaction SE21 (Package Builder).


1 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 karl.kessler@sap.com.

An email has been sent to:






More from SAPinsider



COMMENTS

Please log in to post a comment.

No comments have been submitted on this article. Be the first to comment!


SAPinsider
FAQ