Expand +



Maximize the Benefits of Your SAP Components with Plug-Ins for

by Dr. Thomas Reiss | SAPinsider

January 1, 2001

by Dr. Thomas Reiss, SAP AG SAPinsider - 2001 (Volume 2), January (Issue 1)

As newer versions of components appear, there are more possible combinations, features, and capabilities. SAP accommodates these changes with each new version of the R/3 Plug-In. This article explains how R/3 Plug-Ins work, describes the class-leading integration they provide, and provides an overview of their technology and availability, along with additional references.

“The network is the computer” — the battle cry of the Internet Age. In other words, with networked systems, the whole is more than the sum of the parts. But as so many companies focus on the power of their networks, it’s important to remember that a network alone is useless if you haven’t achieved integration.

     In the world, customers are assured seamless integration across individual business components including:

  • Business Information Warehouse (BW)
  • Strategic Enterprise Management (SEM)
  • Logistics (LO)
  • Financials (FI)
  • Human Resource Management (HR)
  • Business-to-Business Procurement (BBP)
  • Customer Relationship Management (CRM)
  • Advanced Planner and Optimizer (APO)

     Integrating applications requires more than just having a messaging infrastructure. The applications also have to speak the same “language,” which means they must agree on the meaning of each and every parameter passed between the components. This is no mean feat when elaborate interfaces can contain more than 100 parameters.

     And in a networked world, individual components can be upgraded independently, as long as they continue to provide the old services. This is precisely the advantage that components provide: customers can upgrade one of their application components (CRM, BW, etc.) without upgrading the others, and without upgrading their existing SAP business solutions. With components, they all speak the same language, so you get semantic as well as technical integration out-of-the-box.

     And what about integrating components with existing SAP R/3 solutions, especially older releases like 3.1i? This is the job of R/3 Plug-Ins. The Plug-Ins for R/3 3.1i and up provide a set of modification-free interfaces to R/3 solutions that integrate these solutions with components. The Plug-Ins do not contain new application functionality; instead, they provide a window to existing SAP functionality, along with a component-specific integration technology.

     As newer versions of components appear, there are more and more possible combinations and more features and capabilities — and the “window” of SAP functionality gets larger. At SAP, we accommodate this with each new version of the R/3 Plug-In. The current version, PI 2000.2, has been available since November 2000. The new Plug-In versions work not only with the newest component releases, but also with already-existing releases currently in maintenance.¹

     This article explains how the R/3 Plug-Ins work, starting with a description of the class-leading integration they provide, then moves on to an overview of their technology and availability, and also provides references for additional information.


To build a foundation of cross-component (or cross-system) integration, the com-ponents must agree on their language, or semantics. A simple example is the reporting of sales and logistics activities for a particular customer, as shown in Figure 1. This process combines BW, CRM, and SAP Logistics Execution System (LES) capabilities.

     Using application components, various opportunities, quotations, and customer orders are processed in the CRM application component, which has its own database. Data for reporting is passed from CRM to BW, and the CRM component triggers the LES by passing the customer order to LES. LES then passes data on deliveries, etc., to BW for reporting.

     To get useful customer information out of BW, both CRM and LES have to agree on the meaning of entities such as “Delivered amount” or “Unit of measure,” and the values of entities such as “Unit Customer number.”

     For example, take two hypothetical components that were developed independently of one another: one uses the field “UOM” for “Unit of measure,” the other uses the field “UNITS.” To integrate the components, somebody needs to write code to link the field UOM with the field UNITS, since the components don’t know that UOM and UNITS both mean the same thing (“Unit of measure”). You can’t stop here, though. The UOM component might use the value “KG” to signify a kilogram, whereas the UNITS component might use “KGR.” In other words, additional coding is required to translate values from one component to those of another. components understand each other’s entities, since they are all developed on open Internet standards. The integration via Plug-Ins ensures that all components use the same values for entities like “Unit of measure” or “Customer number.”

     The following sections provide examples of integration scenarios across components, and then explain how data is synchronized between components such as FI, HR, etc., and other components, using SAP Plug-Ins.

Figure 1 The Importance of Common Semantics: Cross-Component Integration Between BW, LES, and CRM

Scenarios Using Plug-Ins

The Plug-In provides the necessary interfaces and technology to “initialize” newly installed components to keep them up to date. The Plug-In provides information about newly created objects or changes to existing objects (in real time, if needed), and also allows components to trigger processes or to change business objects within an SAP R/3 component. Let’s take a look at two examples of integration: one in APO and another in CRM.

APO Integration

In Figure 2, the Plug-In allows LES’s stock, delivery, and transportation information to be seamlessly integrated with APO. The Plug-In passes various types of information to SAP APO:

  • Periodically, it passes common data on plants, products (materials), and customers.
  • In real time, it passes capacity information (current stock, production orders, planned orders, and purchase orders for selected products at selected plants).
  • In real time, it passes requirements information (from customer orders, etc.) for selected products and plants.

     As a result, APO knows which customer wants which product and when, and is able to provide advanced available-to-promise (ATP) information. In addition, production planning (via PP/DS) can take place in APO. The results of these plans are then passed to the Plug-In, where production orders, planned orders, purchase requisitions, or purchase orders are created.

Figure 2 Cross-Component Integration with APO and LES

Semantic mapping between the R/3 data model and those of other components is provided by SAP. This is the most difficult part of system integration, and you get it automatically, at no extra cost, when combining components using the Plug-In.

CRM Integration

The Plug-In passes the following information to CRM 2.0B:

  • Periodically, it updates configuration table values.
  • In real time, it updates common data on products (materials and services) and customers.

     Customer orders can be created or changed in CRM. They are then passed in real time to the Plug-In, where customer orders are created in LES.

     For CRM Mobile Sales, the Plug-In can initialize the CRM consolidated database with customer orders, and then provide real-time updates for new or changed customer orders in the application components for LES, FI, and HR.

     If a customer requires available-to-promise (ATP) functionality, CRM can provide this by calling APO BAPIs to make inquiries about the availability of products and place them in reserve. These calls take place line-item by line-item while the user enters the order into the SAP CRM solution. CRM then passes this information on to the Plug-In, which in turn synchronizes the customer order with SAP APO, so that the reserved amounts in SAP APO are correct for both CRM and R/3.

Semantic Integration

The scenarios I have described work out-of-the-box. System settings such as IP addresses for destinations need to be set up, and, of course, applications must be configured so that the processes fit customer requirements (e.g., choosing which products need to be sent to SAP APO). But the semantic mapping between the R/3 data model and the data models of the other components is provided by SAP. This is the most difficult part of system integration, and you get it automatically and at no extra cost when combining components using the Plug-In.

Initial Load: Configuration Data, Common Data, Operational Data

When installing a new component in a site with an existing R/3 installation, the new component needs to synchronize itself with the R/3 installation before it can start operation. This is called initialization, and is done by starting an initial load.

     Depending on the component you are installing, the Plug-In will extract different configuration data, common data (products, customers, etc.) and operational data (planned orders, customer orders, financial information, etc.) and send this data to the component.

Updated and Changed Data

Once the components have been initialized, they need to be kept up-to-date when changes in R/3 take place — for example, when new orders are created or when existing orders are changed. In the case of BW, this is done periodically. The Plug-In keeps track of changes and sends these changes to BW periodically. In the case of SAP APO and CRM, these changes are sent in real time via events (more on this in the next section). This means that an application like SAP APO will always know the exact status of the stock/requirements situation, which allows it to provide ATP services.

Plug-In Technology

The Plug-In is installed onto an existing R/3 system as a modification-free piece of software. It comprises ABAP coding and Data Dictionary objects, such as interface definitions and database tables for integration purposes. The Plug-In contains:

  • New interfaces to the R/3 system, allowing components to access R/3 data and services
  • Coding that can be triggered by events built into R/3 support packages
  • Component-specific messaging technology for managing the data transfer between the Plug-In and the specific component (APO, BW, etc.)


The real-time transfer of changes to business objects is triggered by “events” built into SAP transactions. To allow real-time transfer of updates to components, or earlier releases, SAP has incorporated these events into R/3 support packages. These are implemented using Business Transaction Event (BTE) technology.

     A BTE is like a customer exit (which allows a customer to add coding to the SAP system without modifying SAP code) but with the advantage that SAP and partners can also supply coding that is triggered by the event. So, when an R/3 system does not have a Plug-In installed, the events are fired, but nothing happens — there is no coding to be triggered by the event. In a system with the Plug-In, the Plug-In coding is triggered by the event (see Figure 3). If the Plug-In has been configured to send data to an attached component, it will do so; otherwise, again, nothing happens.

Figure 3 Business Transaction Events (BTEs)

     Two kinds of events are supported:

Publish & Subscribe events: The interfaces for these events have no return parameters, so any number of subscribers can be triggered by the one event. These events are typically triggered when an object is created or changed.

Process events: The interfaces for these events have return parameters, so only one subscriber can be triggered by the event. For example, the ATP function in APO is called using a process event, since the confirmed quantities need to be passed back to the caller. For example, here are some of the process events used for connecting to APO:

  • Create/change/delete customer order
  • Create/change/delete planned order
  • Convert planned order
  • Create/change/delete production/ process order
  • Goods receipt for production/ process order

     As new events are needed to support newer component releases, SAP will include them in support packages. These events are always documented as notes in OSS and can be manually applied by a customer. These are especially helpful to customers who have an already heavily modified system and cannot move up to higher support-package levels. For more information on this process, see OSS note 167914.


The integration technology used to link the Plug-In to the application components for APO, B2B, BW, and CRM is optimized for each of these components. In all cases, messaging is built using an RFC (remote function call). BW uses the tRFC (transactional RFC), and the other components use the qRFC (queued RFC).

     In a sense, although tRFC is the one labeled “transactional,” tRFC and qRFC are actually both transactional. In both cases, the data passed from the sending system to the receiving system is stored in the sending system in the same LUW (logical unit of work) as the application data, and the transport layer ensures that the data is passed to the receiving system. If the receiving system is not available or is busy, the call to the receiving system is periodically repeated until it is successfully executed. The transactional nature of this process means that if the update of the application tables fail, the message store will not be updated, and vice versa; in addition, it guarantees “once-only” delivery.

     In fact, the qRFC is actually an enhanced tRFC, with the additional ability to guarantee the order of delivery. The qRFC allows the calling program to specify a queue name when calling the destination system, and the qRFC transport layer guarantees that all calls with the given queue name are executed in the same order that they were committed to the database. This is essential when using event-triggered transfer of changes, so that the order of changes is kept.

     The qRFC has been retrofitted to R/3 3.1i and up via support packages.²


The new Plug-In supports the newest releases of the application components for APO, B2B, BW, CRM, and SEM, in addition to the older releases. In other words, the new Plug-In contains all the functionality of the old Plug-In, with the support for the components listed above.

     New Plug-In releases are shipped approximately every six months.³ SAP provides Plug-In support packages for each new Plug-In release. In addition to the release in November 2000, look for a new release (PI 2001.1) in 2001.

Broadening Your Window of SAP Functionality

Newer SAP releases contain more application functionality than the older releases, and hence the “window” that integrates new releases and existing applications expands with each Plug-In release. For example, the overall functionality covered by PI 2000.1 used with Release 4.6C would obviously be, in total, bigger than the “window” provided by PI 2000.1 used with 3.1i.4

     With, you achieve automatic, out-of-the-box semantic integration across components — not just a reliable, high-performance technical integration, but an integration where the components can talk to each other in the same language.

     Plug-Ins extend that same integration to your earlier applications. Plug-Ins can be installed on R/3 components with sufficiently high support package levels, and support packages are provided regularly for each new Plug-In. New Plug-In releases are provided regularly. As you expand the window between and SAP R/3, you also support additional integration requirements of your components.

For More Information

For further information about Plug-Ins, please visit our home page at the SAP Service Marketplace:

     If you have questions that the home page doesn’t address, you can use the OSS component XX-PI to get your questions answered.

     R/3 support packages can be found in OSS under SAP-Service -> SAP Patch Service, or in SAPNet under Support -> SAP Online Corrections, where customers can download the support packages.

¹ One excpetion is SRM 2.0A. The latest Plug-In, PI 2000.1, is designed to work with CRM 2.0B and up.
² Please refer to for more details.
³ PI 99.2 was shipped mid-November 1999. PI 2000.1 was shipped mid-May 2000, and PI 2000.2 shipped in November 2000.
4 For example, CRM Mobile Service only works with SAP R/3 4.5B and up, since the older R/3 releases do not contain this degree of "customer service" functionality.

Tom Reiss joined SAP AG in 1993, became a founding member of the ALE development team in 1994, and took over responsibility for ALE in 1996. Since then, he has been responsible for various aspects of distributed systems and application component integration within SAP, including responsibility for the R/3 Plug-Ins. He is currently Vice President for CRM Component Integration. Tom holds a Ph.D. in Engineering (Computer Learning) from the University of Cambridge, England.

An email has been sent to:

More from SAPinsider


Please log in to post a comment.

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