SAP

It’s no surprise that SAP R/3, the most popular packaged Enterprise Resource Planning (ERP) application for the enterprise, is the packaged ERP application most Enterprise Application Integration (EAI) architects and developers will encounter. Architects and developers tend to be pragmatic. They know that most EAI products are driven by the need to move information in and out of packaged applications such as SAP R/3. So, accepting the necessity to link into these beasts, they decide to use them to their best advantage.

The upside of connecting to SAP is that, unlike many packaged applications, SAP has well-defined and well-tested interfaces built into it that adequately provide for sharing data and processes with the outside world. The downside is that these same interfaces are complex. Moreover, their architecture is confusing, there’s a dearth of information on how best to leverage them, and other technical issues remain unsolved. SAP is working on these issues, but don’t expect answers anytime soon.

In addition, there’s the problem of what to do with information once it’s wrenched out of SAP. Usually, EAI architects and developers will pass the information directly to a middleware layer (e.g., the application server or message broker), converting the information into something the target system understands. This transformation and transportation challenge needs solving, too. Finding the proper solution is more art than science.

Finally, there’s the question of SAP’s future. With the popularity of more open interfaces such as Java, Common Object Request Broker Architecture (CORBA), and COM, SAP is looking to provide uses for these interfaces that access their underlying system. While this is an opportunity for SAP to open access to their system, it’s important to consider how movement to these interfaces will impact a particular EAI solution. Often, the more traditional interfaces work now, but an upgrade to the newer interfaces will be necessary when they’re available. It doesn’t require a genius to see that this means having to do the integration work twice.

SAP, like most other packaged applications, was built as a monolithic solution — one never intended to communicate with the outside world. The subsequent addition of interfaces changed that. They first allowed SAP systems to communicate with each other, then allowed SAP to interact with many different types of systems.

The original SAP R/3 architecture didn’t contain these interfaces; they were added over several years. As a result, they often seem ill-conceived and poorly structured. For example, there are many ways to extract the same information from SAP. Selecting the method and manner to use is something of a crapshoot, with the correct choice not always obvious. A thorough knowledge of SAP, including data, process information, and business objects, is required for successful SAP use and manipulation.

The nirvana of SAP access rests in the hands of the EAI vendors, who are looking to place an abstraction layer on top of interfaces to SAP. The purpose is to hide the interface complexities from those who need to integrate SAP with other systems. SAP will appear like a set of business objects that applications can share. The result is a shift in burden from the EAI architect and developer to the EAI solution itself, which is where it belongs.

While the use of abstraction layers remains the ultimate goal, users today must deal with intermediary realities, including Application Program Interfaces (APIs) and middleware layers. They may be ugly, but they’re all that’s going to be available for awhile.

SAP uses a three-tier architecture comprised of a presentation layer, application server layer, and database layer (see Figure 1). SAP runs on smaller platforms and operating systems, including most popular flavors of UNIX and Windows NT. It’s possible to mix and match operating systems at the client, application server and database levels. This makes the SAP architecture flexible and scalable. SAP uses the Advanced Business Application Programming (ABAP/4) language, along with the ABAP/4 development workbench and toolset to configure and customize R/3.

Other basic services supporting R/3 include printing, security and communications. R/3 allows the interplay of applications, user interfaces and data. Standard interfaces, application interfaces, and open data formats allow movement of this information. These services are the foundation of SAP’s application integration capabilities.

SAP supports most major standards. These include the Transmission Control Protocol/Internet Protocol (TCP/IP), Structured Query Language (SQL), Object Linking and Embedding (OLE), X.400/500 and Electronic Data Interchange (EDI). SAP also supports its own Remote Function Call (RFC), which enables remote calling to SAP functions from other systems. RFC was originally built by SAP for use by other linked SAP systems. However, RFC has evolved into the primary interface for most EAI efforts.

CPI-C, an older middleware layer left over from the days of traditional IBM mainframes, is part of IBM’s System Application Architecture (SAA) of the late 1980s. Because CPI-C is included in ABAP/4, an ABAP/4 program can link to a CPI-C session. The program-to-program communication is always performed via an internal gateway that handles conversion of CPI-C communications to external protocols, including TCP/IP and LU6.2.

For asynchronous communications, SAP supports the notion of queues — allowing a system to create a queue for subsequent transmission to another SAP system. The Queue Application Programming Interface (Q-API) handles this. SAP can use this interface to receive information via standard batch processing. While some people view this practice as inelegant and outdated, it remains widely used.

While CPI-C and Q-API provide external communications mechanisms for SAP, many people find these “traditional” middleware mechanisms limiting because they don’t support SAP’s more advanced features, including RFC, which is included in the ABAP/4. RFCs remain the mechanism for accessing the SAP program interface. They provide a standard way to move all sorts of information in and out of SAP. Users can call RFCs from many platforms, development environments and applications. The R/3 automation software development kit provides RFC libraries and RFC Dynamic Link Libraries (DLLs), user dialogs and an error-processing facility. The software includes documentation and sample programs for RFCs that allow access to SAP processes and data from standard software such as MS Excel, PowerBuilder, Visual Basic, C++, and Java. Even more beneficial is the ability to access RFCs using “standard” Microsoft interfaces such as COM, COM+, and OLEDB.

RFC brings the reality of program-to-program communications to SAP, letting EAI architects and developers incorporate business objects across several platforms, programs and databases (see Figure 3). RFCs hide the layer of CPI-C calls (the actual communications mechanism SAP uses) from RFC users.

Why use RFCs when it’s possible to go directly to the database? There are many reasons to do so; the most compelling is transactional integrity. It’s too dangerous to read and write directly to the SAP database without using the application server, which controls access to the data and enforces database integrity. For example, updating customer information within SAP could mean invoking a single transaction that’s linked to several hundred tables. Without using the transaction contained on the application server, it’s necessary to update each table in the same order, ensuring that the data is in the proper format. While it’s certainly possible to do that, it’s easier and safer to update and access information using the application server layer.

RFCs ensure transactional integrity by making sure calls execute in the same order and program context. RFCs also guarantee that a single RFC isn’t invoked more than once and that the status of an RFC call is continuously accessible.

RFCs are synchronous calls by nature (recall, they’re really RPCs). It’s, however, possible to use queues to place requests for RFCs for later processing or to process when the SAP server returns to life. It’s also possible to leverage other middleware to make RFCs asynchronous. Message-brokering technology is particularly valuable in this regard.

RFC technology is really a middleware technology meant to interface with other middleware. As a result, while it’s possible to use an RFC to access an SAP system directly, it’s more common to bind RFCs to a more traditional middleware layer, such as MOM, distributed objects or application servers. Links to RFCs don’t occur magically. Usually, they have to be created from scratch or leveraged from an SAP adapter that may come with the middleware.

The heart of EAI access to SAP is Application Link Enabling (ALE) technology. ALE can combine business processes with middleware. It provides a robust distributed architecture for SAP, giving transparent distributed access to both SAP data and processes. ALE is also essential for moving information to non-SAP systems and, ultimately, for supporting the entire EAI effort.

ALE allows EAI architects and developers to set up application modules and databases at various sites and then bind the sites at both the business process and data levels. They make several SAP sites appear to be a single, monolithic system.

ALE also allows external systems to access SAP. This benefit results from “tricking” ALE into thinking that it’s communicating with other SAP systems. In this way, ALE can understand and route data required to support a business process. ALE lets EAI architects, developers and clients achieve integration as well as distribution of applications and data. SAP provides ALE technology with a set of tools, programs, data definitions and methodologies EAI developers or vendors can apply to unlock information from traditional SAP systems.

Intermediate Document

An Intermediate Document (IDOC) is a structured information set providing a standard format for moving information in and out of an SAP system. It represents a concept similar to EDI, but IDOC is not a standard. It’s possible to invoke an RFC at the SAP level and get an IDOC as a result. That IDOC becomes a basis to structure a message that’s transported through a standard middleware layer. For example, most message brokers can convert an IDOC into another format a target system can understand and process.

IDOCs contain a control record, data record and status record (see Figure 4). Each IDOC is a single SAP business object. The control record contains several fields with information about the IDOC such as its type, sender and receiver. The data record contains the application data; the status record contains information on the state of the document.

As a single business object, an IDOC may contain only one shipment document. This represents both an advantage and limitation of IDOC. While easy to use (due to the simplicity of having only one business object per IDOC), many IDOCs will have to be sent and received to support real-time integration.

Business Application Program Interfaces (BAPIs) provide an object-oriented mechanism to get at the underlying, proprietary SAP middleware technology such as RFCs (see Figure 5). Besides providing access to the data and processes, a BAPI allows access to the SAP business objects held in the Business Object Repository (BOR), encapsulated in their data and processes. In other words, a BAPI provides a layer of abstraction above the primitive interfaces SAP provides.

To use a BAPI method, an application program needs to know how to call the method, such as its structure and parameters. The BAPIs in the R/3 system work as function modules, all of which are held in the Function Builder. Each function module underlying a BAPI supports the RFC protocol and is assigned as a method to an SAP business object in the BOR.

The importance of BAPIs resides in the power they give developers to provide SAP access from many different tools and technologies. For example, using the BAPI interface makes it easy to build applications that can gather information from SAPs without having to drop down to primitive function calls. However, a BAPI doesn’t provide everything needed to access SAP as a true set of objects. For example, a BAPI provides access to only a few functions. Nevertheless, BAPIs are expanding their reach daily.

The SAP repository contains most of its business engineering information, including business models, programs and objects. The R/3 repository is also the container for all R/3’s application information, including development and design information. The repository comprises the business- and application-related metadata and provides a means to explore the features and functions of an SAP system that yield better integration.

The advantage of using the SAP repository is the ability to discover as much as possible about the SAP system targeted for integration. This knowledge enables the EAI architect and developer to automatically link SAP with other systems at the business object (method level) or data level, without having to create a common set of functions.

Although using the SAP repository requires a more sophisticated level of EAI, the ability to react automatically to changes to the source or target SAP system makes a compelling argument for going to that next level. Many who are integrating SAPs have leveraged the repository to intelligently integrate the system. The real value of this approach will come from vendors looking to create EAI solutions that link deeply into SAP. Currently, the SAP adapters are more at the RFC level and don’t take into account the repository content.

SAP is a dynamic ERP and is constantly evolving into new, more marketable products. This will only drive the need for additional integration and will certainly add to the already formidable challenge of integrating SAP. For example, SAP is going to sell Web-delivered application services — so there’s no need to host your own copy of SAP. While this provides a low-cost alternative to hosting your own SAP R/3 system (which runs in the millions of dollars), the integration complexities of this approach have yet to be considered.

SAP will be part of most EAI efforts that involve an ERP. Fortunately, many people have already been down this road and cleared a trail of approaches, interfaces and technology that make it possible to move information in and out of SAP. The question is, “How much is SAP going to change to accommodate the new interest in EAI?” As SAP matures, it has to provide better interfaces than it does now. Currently, most SAPs accomplish this in such a way that they reach a wider set of technologies. Ultimately, ERPs may all have standard connections, allowing ERP systems to appear as databases, Java objects, or distributed objects. If that occurs, ERP systems such as SAP will be able to be bound seamlessly with existing enterprise applications. That’s exactly where they’ll have the most value.