Currently, SAP offers two full-blown integration platforms: SAP NetWeaver Process Integration (SAP NetWeaver PI) and SAP Business Connector (SAP BC). Both of them understand the SAP-specific network protocol Remote Function Call (RFC) as well as standard network protocols such as HTTP, FTP, and email. Also, both of them can process the SAP-specific data formats defined by BAPIs and IDocs as well as standard XML data formats.

In previous years, SAP NetWeaver PI had been regarded as the successor of SAP BC, while the future of SAP BC had been a bit uncertain. However, starting with SAP BC 4.8 (which was released in Q3 2008), SAP committed to a definite maintenance cycle: SAP BC 4.8 is guaranteed to be supported until December 2017. This makes SAP BC a reliable option for integration scenarios again. Investments in SAP BC solutions no longer run the risk of quickly becoming obsolete and can again be run on up-to-date operating systems in a well-supported way.

Both platforms, SAP NetWeaver PI and SAP BC, provide similar functionality (although each one has a small number of features that the other one does not support). Therefore, users are often confused as to which one they should choose in a particular situation. I will discuss the architecture and the strong and weak points of these two solutions. I will give you recommendations for which one to use in which situations or when you are better off using neither one, but a direct, low-level integration instead. Here, direct integration means integration via RFC components — such as SAP Java Connector (SAP JCo), .NET Connector, or SAP NetWeaver RFC SDK — or via the HTTP stack built into the SAP R/3 Kernel.

This article is for system administrators or solution architects who need to solve the task of integrating or synchronizing an SAP back-end system with an external data source of any kind (e.g., in-house legacy systems, a customer’s or vendor’s system, Web sites, or another SAP system outside the company’s firewall). It aims to provide definitive criteria that enable you to make a well-founded decision about which integration technology to use for your current integration task.

When Not to Use an Integration Platform

Before I go into the details of comparing SAP NetWeaver PI and SAP BC, let’s stop a moment and consider whether the integration platform approach is the right one for you. Under certain circumstances, a solution using a direct low-level point-to-point communication may be more appropriate. These circumstances are:

• Very high performance is essential. Using an integration platform always means an additional communication step in between the sending system and the receiving system. This of course increases the overhead. By using a direct communication between the SAP system and the external system, you can eliminate this extra hop and achieve maximum performance.
• Only a few interfaces (function modules, IDocs, Web services) are needed. When using a direct communication, custom code (ABAP code on the SAP system side or Java, C#, or C/C++ code on the external side, or both) is required for every interface in use. In many cases, you can eliminate the need to write custom code by using an integration platform and its built-in automatic tools. However, setting up, customizing, and maintaining an integration platform also induces a certain amount of effort. If you plan to use only a small number of interfaces, you ought to consider whether the effort of setting up an integration platform is more significant than the effort of writing the necessary custom code for these few interfaces.
• The external system does not support a standard communication protocol, but can easily be extended. In this case, there is no other choice than to use one of SAP’s communication libraries (SAP JCo for Java applications, the .NET Connector for C# applications, or the SAP NetWeaver RFC SDK for native applications) and plug it into the external system. Both integration platforms require some kind of standard protocol to be supported on the external side, and if this is not the case, it may be a significant effort to enable the integration platform to communicate with the external system.

Two Strategies for Direct Communication

For a direct communication between the SAP system and an external system, two strategies are possible:

Strategy 1. If the external system provides an HTTP-based interface, you can use the HTTP stack of the SAP Kernel to exchange plain HTTP requests, SOAP messages, or Web service requests between the two systems. Both directions are possible (i.e., the SAP system can act as an HTTP client as well as an HTTP server). In this case, ABAP coding is necessary on the SAP system side. For more information, refer to “Internet Communication Framework” and “SOAP Runtime for SAP NW AS” in the SAP online library.

Strategy 2. If the external system can be extended, or if a small custom program can be written that understands the external system’s data format, then you can use SAP JCo, the .NET Connector, or the SAP NetWeaver RFC SDK to exchange RFC requests between the two systems. Again, both directions are possible here. In this case, Java, C#, or C/C++ coding is necessary on external side. For more information refer to the SAP Connectors Homepage.

When to Use an Integration Platform

You should use an integration platform, if:

• You can take advantage of its many built-in tools, such as the monitoring capabilities, the data mapping tools, or the predefined communication tools. In many cases the integration platform allows sending or receiving HTTP or RFC requests without any coding necessary on SAP system or external side.
• A large number of external systems need to be connected to the SAP system, or a large number of interfaces need to be used. Often it is possible to write some custom code once on the integration platform and then reuse it for all connected external systems. This is much easier than extending each of the external systems separately. Also, monitoring the message flow is easier when using an integration platform.
• The external system and the SAP system are separated by a firewall. When using direct communication in such a scenario, the firewall needs to be opened to allow the external system access to the SAP system. This poses a certain security risk. In this case, it is advisable to insert an integration platform between the external system and the SAP system. The integration platform can then be placed in the demilitarized zone (DMZ), and the firewall needs to be opened only for communication between the (trusted) integration platform and the SAP system. Or, you can place the integration platform inside the firewall and the external system only needs to be granted access to the integration platform instead of to the SAP system. For scenarios like these, SAP BC provides a special feature called Reverse Invoke, which increases security even more.
• You don’t want to develop any custom code. In many standard scenarios, an integration platform allows you to set up a connection between an SAP system and an external system just by customizing and perhaps creating a few graphical mappings and definitions. This is perfect if you don’t have development know-how (ABAP, Java, C#, C/C++) at your disposal.

Now that you know whether or not you should use an integration platform, let’s compare the two solutions SAP is offering in that field.

Strengths of SAP BC

SAP BC has become a very mature and well-documented integration platform. Its main assets are simplicity and robustness. In particular, the following points deserve special attention.

Hardware and Installation

SAP BC is a single-stack system with a very lean internal architecture, as opposed to SAP NetWeaver PI, which consists of a Java stack, an ABAP stack, and an additional database. Consequently, a small SAP BC installation can run on a 256 MB desktop PC and successfully cope with low data volume scenarios, while an SAP NetWeaver PI installation needs at least two to three powerful servers.

Additionally, SAP BC can be installed in just a few minutes, and the installation process does not require any expert know-how: the installer does everything automatically, and if you spend 15 minutes reading the installation guide, the chance of error is minimal. In contrast, installing an SAP NetWeaver PI system is quite a major effort and requires experienced consultants.

Customizing and Administration

What was observed with regard to the installation continues in the area of customizing and administration: both learning (where you need to customize what) and the actual customizing are a matter of minutes and quite intuitive. Therefore, within one hour you can go from a blank machine to a fully functional SAP BC installation with connectivity to an SAP back end and to an external HTTP/FTP/email server. In contrast, an SAP NetWeaver PI system is very complex — setting it up requires expert know-how.

Development

Another aspect of the SAP BC’s lean internal architecture is that its concepts are easy to learn and use. Consequently, a developer who is unfamiliar with SAP BC can get up to speed quickly. Also, the development of new functionality is straightforward and does not take much time. The code is active immediately, so no extra deployment is necessary. In an SAP NetWeaver PI system, however, both the initial learning of the necessary concepts as well as the application of these concepts when doing the actual coding are more tedious.

Architecture and Performance

In the preceding sections, I discussed SAP BC’s internal architecture and the advantages it provides for installation, customizing, and development. Here are the details of that architecture and its benefits.

First of all, SAP BC is written mostly in Java (with a few low-level modules written in C). In contrast, SAP NetWeaver PI consists partly of ABAP components and partly of Java components. This has two consequences:

• The ABAP and the Java stack both need their own memory. Therefore, the memory footprint (memory consumption in idle state) of an SAP NetWeaver PI system is several times higher than that of an SAP BC system. Consequently, there is less memory left for the actual processing of messages, resulting in a smaller maximum message size compared to an SAP BC system with the same hardware. Also, because of the higher memory consumption, the garbage collectors (ABAP and Java) need to run more often than the SAP BC Java garbage collector, resulting in higher CPU load.
• Communication between two programming languages is always slow, so whenever data needs to be shifted from ABAP to Java or vice versa, it slows down the system.

The next important design feature of SAP BC is its internal data format. In SAP BC, when the current payload is passed from one mapping step to the next (or from one adapter to another), only a four-byte reference is passed around. The next step or adapter continues to work on the same data object as the previous one.

SAP NetWeaver PI, however, was designed with message brokering in mind: an XML message is received, transformed in some way, and then forwarded to the final receiver. Therefore, XML is used as an internal data format. When message processing consists of a simple one- or two-step process, this is the optimal way of doing things. However, once the data mapping and communication requirements become more complex, this design induces additional overhead. Whenever the payload needs to be passed from one step to the next, the current data object is serialized into an XML document (which is time- and memory-consuming) and the XML stream is passed to the next step where it is parsed again to recreate the data object (another time- and memory-consuming process).

I’ll illustrate this with a simple example. Suppose an IDoc is to be received from an SAP system, mapped into a third-party data format, digitally signed, and finally sent to the external receiver as a MIME message via email. In this case, in SAP BC you have two expensive data conversions: in the beginning, the IDoc is converted into SAP BC’s internal data format (one conversion), then all three steps (mapping, digital signature, and forwarding the message to the email adapter) are performed on that internal data object. In the end, the data object is converted to a MIME message (second conversion).

In a typical SAP NetWeaver PI application, the same process requires seven expensive data conversions: two when the data enters and leaves SAP NetWeaver PI (just like in the SAP BC case) and then five more when the data enters and leaves the mapping engine, enters and leaves the component performing the digital signature, and enters the email adapter. As these conversions are quite expensive (memory, as well as CPU-wise), they have a negative effect on the overall performance.

The final design difference I want to mention is that SAP BC is designed as a plain old Java application with a very lean component hierarchy. In contrast, the Java parts of SAP NetWeaver PI run inside a J2EE engine and therefore suffer from a very high component hierarchy. A message needs to go through many abstract layers, containers, frameworks, and delegations before it finally reaches the point where the actual work is done. This is illustrated very descriptively by comparing a typical exception stack trace from SAP BC with one from SAP NetWeaver PI. In SAP BC, the stack from Thread.run() to the point where the actual work is done is about 30-50 lines long. In SAP NetWeaver PI, it is several hundred lines long. This also takes its toll on CPU and memory.

In normal, uncomplicated scenarios, the performance of SAP BC and SAP NetWeaver PI is about the same. However, in complex scenarios, the difference described above will make itself felt. One example I encountered in practice was the ELSTER scenario (online tax declaration process in Germany), which has been implemented almost identically on both platforms. The ELSTER process is fairly complex because it requires several different steps to be applied to the payload: the request data is zipped, encrypted, digitally signed, base64-encoded, and mapped into a special XML format. The response data coming back from the federal server needs to go through the inversed chain of steps. At one client site, both solutions were installed and the performance was measured. The solution running on SAP BC 4.7 was more than 10 times faster than the corresponding solution on SAP NetWeaver PI 2.0, despite the fact that the SAP NetWeaver PI system was running on more powerful hardware. This is certainly an unusual scenario, but if you plan to implement similarly complex solutions, you should definitely take these performance considerations into account.

Features Not Found in SAP NetWeaver PI

SAP BC provides a number of capabilities that cannot be found in SAP NetWeaver PI. These are:

• Web automation. SAP BC offers a few services for crawling through Web sites and extracting data from them in an automated way. This is useful in a number of scenarios, for example, for real-time extraction of product and price information from online catalogues.
• Multi-step logical units of work (LUWs). SAP NetWeaver PI was designed primarily for asynchronous message routing. Therefore synchronous LUWs consisting of more than one step cannot be implemented via SAP NetWeaver PI. This means that many BAPIs, which require an additional BAPI_TRANSACTION_COMMIT or BAPI_TRANSACTION_ROLLBACK at the end of the transaction, cannot be used from an SAP NetWeaver PI system. SAP BC fully supports multi-step LUWs.
• Inclusion of custom C/C++ components. In addition to the graphical mappings, XSL Transformation (XSLT) mappings and Java components found in SAP NetWeaver PI, SAP BC also allows you to create custom C/C++ components.
• Reverse invoke (RI). RI is used quite often to achieve higher security in the following scenario: an external partner needs online access to your SAP system, but you don’t want to open the firewall protecting that system. In that case, you would set up a landscape as shown in Figure 1.

Figure 1

Network landscape in an RI scenario

The outer firewall needs to be opened for HTTPS connections from the external client to the host on which the RI SAP BC is running. The inner firewall remains completely closed to connections from the outside — it only needs to allow opening connections from the internal SAP BC host to the RI SAP BC host (from the inside to the outside). The internal SAP BC now opens a TCP/IP connection to the RI SAP BC in the DMZ. That connection can be secured via SSL if necessary. The RI SAP BC verifies that the connection indeed comes from the internal SAP BC, using SSL certificates and IP address verification. This connection now remains active permanently.

Whenever the RI SAP BC receives an HTTPS request from the outside, it sends the data to the internal SAP BC through the established TCP/IP connection. The internal SAP BC then processes the request, accessing the SAP system’s data as necessary. This setup is as secure as it can get.

Strengths of SAP NetWeaver PI

After a lot of praise for SAP BC, I’ll now show you some use cases for which an SAP NetWeaver PI system is preferred.

Web Service Support

SAP BC’s Web service stack was implemented in 2001. Except for a few enhancements and bug fixes, it has not been updated since then. This means that complex Web services using the latest standards might run into problems on SAP BC. (For a list of known limitations see SAP Note 853824.) Simple Web services work with SAP BC, but once the interfaces get more complex and advanced, you are better off using SAP NetWeaver PI, whose Web Service stack is always kept up-to-date.

Persistence, Queuing, and “Store and Forward” Capabilities

SAP BC was designed primarily as a “man-in-the-middle” in synchronous scenarios, so it does not have a persistence component or a queuing engine. It relies on the two communication partners to keep track of the transaction status and to resend failed transactions.

In many cases this is fine — the tRFC/qRFC queues in the SAP back-end system can take care of status management, queuing, and resending. However, this means that the SAP back end always has to start the entire process. Whenever the SAP system triggers a message, the external receiving system has to be available at the same time. If you want to send something to an external system that is online only sporadically, and you don’t want to keep all messages inside the SAP system until they can finally be delivered successfully, you are better advised to use SAP NetWeaver PI’s store and forward capabilities. SAP NetWeaver PI was designed for asynchronous message routing, so this is one of its key capabilities.

Abstract, High-Level Modeling Tools

SAP BC can be viewed primarily as a low-level technical tool. Its main concepts are about communication protocols and data formats. Conversely, SAP NetWeaver PI also offers an abstract high-level view on things and provides tools for Business Process Modeling. If used with care, this can simplify things considerably: you just define the high-level business rules and the necessary code is generated automatically. However, keep in mind that if you only have the abstract business view of things and lose the low-level technical view, you may find yourself completely lost if something isn’t working as it should. It can take weeks of debugging before you find out what went wrong and why.

Cooperative Development and Code Versioning

The SAP NetWeaver PI system contains a full-fledged code revision control system. In contrast, SAP BC has nothing of the kind. SAP BC has a rudimentary locking mechanism, which prevents two developers from editing the same object at the same time, and that’s it. This is sufficient for projects where development is done by a small team. For larger projects (especially where development teams are distributed over different locations) you either need to set up a third-party code revision control system (such as Perforce, Concurrent Versions System [CVS], or Microsoft Visual SourceSafe) or use SAP NetWeaver PI and its built-in code control.

Support for ABAP Components

In SAP NetWeaver PI, mappings or other processing steps can easily be developed in ABAP, while SAP BC provides no ABAP support at all. Therefore, if your development team has mainly ABAP expertise, SAP NetWeaver PI should be your tool of choice.

Recommendations

I once read the recommendation that for scenarios with small- or medium-sized data volume, you should use SAP BC, while for larger scenarios you should use SAP NetWeaver PI. I disagree. Because of its superior performance, SAP BC excels over SAP NetWeaver PI, especially in complex, high-volume scenarios. In addition, with release SAP BC 4.8, SAP BC also supports 64-bit hardware and can therefore use the same heavy-duty hardware as SAP NetWeaver PI.

Rather than making the data volume the most important criterion in your decision process, you should think along the following lines. First of all, I outlined a number of features that one platform supports and the other doesn’t. So the first question to ask yourself is: “Will my project need one of these particular features”? If yes, the choice has already been made for you. Otherwise you should ask, “Does my development team already have know-how for one platform or the other”? If they know neither one, this would be a point in favor of SAP BC because it is much easier to learn.

Also, team size may be a factor. SAP BC can help you quickly achieve results with a small team. However, if this is going to be a huge, long-running development project with large distributed teams, you may find that developing the project on SAP NetWeaver PI may be more efficient.

The next factor is performance. If your scenario requires only simple mappings or one-step processes, the performance of SAP BC and SAP NetWeaver PI is comparable. However, once the mappings start to get more complex or if multiple steps are required to process the data, SAP BC starts to show significantly better performance. If speed is critical in your scenario, this is another point in favor of SAP BC.

Finally, who is going to run and maintain the solution? An SAP NetWeaver PI system needs a full-time, qualified administrator to take care of it. In most cases, you need to assign a full position for this task. Administrating an SAP BC solution is not much effort and can usually be taken over by your existing IT personnel if you give them a few days to study the documentation.

Ulrich Schmidt

Ulrich Schmidt joined SAP in 1998 after working in the field of computational algebra at the Department of Mathematics, University of Heidelberg. Initially, he was involved in the development of various products used for the communication between SAP R/3 systems and external components. These products include the SAP Business Connector, which translates SAP’s own communications protocol RFC into the standard Internet communications protocols HTTP, HTTPS, FTP, and SMTP, as well as pure RFC-based tools, such as the SAP Java Connector and RFC SDK. Ulrich gained insight into the requirements of real-world communications scenarios by assisting in the setup and maintenance of various customer projects using the above products for RFC and IDoc communications.

You may contact the author at u.schmidt@sap.com.

If you have comments about this article or publication, or would like to submit an article idea, please contact the editor.