Who's General Failure and why's he reading my disk? | ||
| --Anonymous | ||
It is no surprise that SAP R/3, the most popular packaged ERP application for the enterprise, is the packaged ERP application that most EAI architects and developers will encounter. Architects and developers tend to be pragmatic people. Knowing that most EAI products are driven by the need to move information in and out of packaged applications like SAP R/3, they figure that, unable to break free from having to link into these beasts, they might as well learn to use them to their best advantage.
As with most things, connecting to SAP has an upside and a downside. The upside is that, unlike many packaged applications out there, well-defined and well-tested interfaces are built into SAP that adequately provide for the sharing of data and processes with the outside world. Of course, the downside is that these same interfaces are complex, their architecture is confusing, information is lacking as to how best to leverage them, and various other technical issues still require resolution. SAP is working toward resolving these issues but don't expect answers anytime soon.
In addition to these problems, there is the problem of what to do with the information once it's been wrenched out of SAP. In most cases 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 that's understood by the target system. This transformation and transportation difficulty needs to be solved as well. At this point, finding the proper solution is more an art than a science.
Finally, there is the question of SAP's future. With the popularity of more open interfaces such as Java, 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 is important to consider just how the movement to these interfaces will impact a particular EAI solution. In many instances, the more traditional interfaces can be used now, but an upgrade to the newer interfaces will be necessary when they're available. It doesn't require a genius to see that that's having to do the integration work twice.
SAP, like most other packaged applications, was built as a monolithic solution never intended to communicate with the outside world. The later addition of interfaces changed that. They first allowed SAP systems to communicate with each other and then allowed SAP to interact with many different types of systems.
The original SAP R/3 architecture did not contain these interfaces. They were, in fact, 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. Coming to a decision as to the exact method and manner 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 the only insurance that allows for the successful use and manipulation of SAP.
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 (see Figure 14.1). The purpose of this abstraction layer is to hide the interface complexities from those who need to integrate SAP with other systems. As a result, SAP will appear like a set of business objects, sharable among applications. The result is a shift in burden from the EAI architect and developer to the EAI solution itself—where it belongs.
While the use of abstraction layers remains the ultimate goal, users today must deal with intermediary realities—APIs and middleware layers. Although they may be ugly, they're all that's going to be available for a while.
SAP uses a three-tier architecture comprised of a presentation layer, an application server layer, and a database layer (see Figure 14.2). SAP runs on smaller platforms and operating systems, including most popular flavors of UNIX and Windows NT. It is possible to mix and match operating systems at the client, the application server, and the database levels, making the SAP architecture both 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.
The other basic services supporting R/3 include printing, security, and communications. In addition to these services, R/3 allows the interplay of applications, user interfaces, and data. The movement of this information is provided through the use of standard interfaces, application interfaces, and open data formats. These services constitute the basis of SAP's ability to integrate applications. We will explore these services further later in this chapter.
SAP supports most major standards including TCP/IP, SQL, OLE, X.400/500, and EDI. It 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, as time has gone on, RFC has become the primary interface for most EAI efforts. We will discuss this in more detail later in this chapter.
SAP provides an advanced repository that contains a description of all metadata, modules, and processes. This information includes screen forms, business rules, and the location of application servers. In the SAP scheme, all applications are extracted from the repository and sent to the connected application servers, providing automatic updates for system upgrades.
The SAP clients are very thin, very terminal-like. The client communicates with the application server and presentation server and simply provides the interface to the end user. One such SAP client is a GUI that supports Windows 98/2000, Windows NT, OS/2, OSF/Motif, and Apple Macintosh.
The application server is able to perform all of the application and interface processing, in addition to providing such rudimentary transaction-processing features as load balancing and fail-over. The R/3 architecture allows the application tier to uncouple from the presentation and data tiers.
The database simply provides a location for data storage. It handles data access through the use of SAP SQL, which is, at its heart, a standard SQL called from within the ABAP/4 toolset. Because relational database systems offer different subsets of standard SQL functions, the ABAP/4 toolset supports SQL at two levels: SAP SQL and native SQL. The database interface translates SAP SQL into the native SQL dialect. It is possible to use either of these two levels (see Figure 14.3). It should be noted that most relational databases such as Oracle, Informix, and SQL Server work with SAP R/3.
SAP uses traditional and proprietary middleware layers. Program-to-program communications are implemented with older Common Programming Interface for Communications (CPI-C). RFCs are the most prevalent mechanism to mine SAP processes and data. The other layers, such as Java and COM access, are really nothing more than wraparound RFCs.
CPI-C, an older middleware layer left over from the days when traditional IBM mainframes roamed the earth, is part of IBM's System Application Architecture (SAA) of the late 1980s. The CPI-C is included in ABAP/4, allowing an ABAP/4 program to link to a CPI-C session. The program-to-program communication is always performed via an internal gateway that handles the conversion of CPI-C communications to external protocols, including TCP/IP and LU6.2.
If asynchronous communications are required, it is useful to know that SAP supports the notion of queues, allowing a system to create a queue for transmission to another SAP system at a later time. This process is handled by the Queue Application Programming Interface (Q-API). SAP is able to use this interface to accept information into the system through standard batch processing. Although some people judge this practice as inelegant and outdated, the simple fact remains that it's still in wide use today.
While CPI-C and Q-API provide mechanisms that allow SAP to communicate with the outside world, many people find these "traditional" middleware mechanisms limiting and unable to 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 procedural approach for moving all sorts of information in and out of SAP.
RFCs are callable from a multitude of platforms, development environments, and applications. The R/3 Automation Software Development Kit provides RFC libraries and RFC DLLs (Dynamic Link Libraries), user dialogs, in addition to an error-processing facility. Documentation and sample programs for RFCs are included in this software, allowing 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 other, more "standard" Microsoft interfaces such as COM, COM+, and OLEDB.
RFC brings the reality of program-to-program communications to SAP, allowing EAI architects and developers to incorporate business objects across several platforms, programs, and databases (see Figure 14.4). RFCs hide the layer of CPI-C calls (the actual communications mechanism used by SAP) from those using RFCs.
The question remains: "Why use RFCs when it is possible to go directly to the database"? While there are many reasons to do so, the most compelling is transactional integrity. It is simply too dangerous to read and write directly to the SAP database without using the application server, which controls access to the data and thus enforces database integrity. For example, simply updating customer information within SAP could mean invoking a single transaction that is linked to several hundred tables. Without using the transaction contained on the application server, it would be necessary to update each table in the same order, making sure that the data is in the proper format. While it is certainly possible to do all this, why not take the easier and safer route of updating and accessing information using the application server layer, using RFC? Without question, doing so is the safest bet.
RFCs ensure transactional integrity by making sure calls are executed in the same order and within the same program context. In addition, RFCs guarantee that a single RFC is not invoked more than one time and that the status of an RFC call may be accessed at any given time.
RFCs are synchronous calls by nature (recall, they are really RPCs). It is, however, possible to use queues to place requests for RFCs for later processing or to process when the SAP server returns to life. It is also possible to leverage other middleware to make RFCs asynchronous. Message-brokering technology is particularly valuable in this regard. We'll discuss this aspect of message-brokering technology in Chapter 18.
At base, RFC technology is really a middleware technology meant to interface with other middleware. As a result, while it is possible to use an RFC to access a SAP system directly, it is more common to bind RFCs to a more traditional middleware layer, such as MOM, distributed objects, or application servers (see Figure 14.5). It is important to bear in mind that the links to RFCs don't magically occur. In most cases those links will have to be created from scratch—or leveraged from a SAP adapter that may come with the middleware.
With a knowledge of what's going on behind the scenes, we can turn our attention to the heart of EAI access to SAP. The beating heart of EAI access to SAP lies within the Application Link Enabling (ALE) technology, a technology that's able to combine business process with middleware. ALE provides a robust distributed architecture for SAP, providing transparent distributed access to both SAP data and processes. The ALE architecture is also essential for moving information to non-SAP systems and, ultimately, 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 the data levels (see Figure 14.6). In other words, they make several SAP sites appear to be a single monolithic system.
In addition to simple data exchange between SAP systems, 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 is able to understand and route data required to support a business process.
ALE provides a competent mechanism that enables EAI architects, developers, and clients to achieve integration as well as the distribution of applications and data. SAP provides ALE technology with a set of tools, programs, data definitions, and methodologies that EAI developers or vendors may apply to unlock the information from traditional SAP systems.
ALE is comprised of three layers: the application layer, the distribution layer, and the communications layer.
The application layer provides ALE with an interface to the R/3 application. This is needed in order to send or receive messages to and from the SAP system you're attempting to integrate. The distribution layer, applying a predetermined set of rules, filters and converts the messages containing the information that is being moved in and out of the SAP system. This is required due to the different releases of SAP (R/2 and R/3). (This is not a substitute for transformation engines, such as message brokers, that make short work of EAI.) The communications layer carries out the communications between systems, both asynchronously (for the transmission of data) and synchronously (for the transmission of control information). The tRFC (transactional RFC) mechanism allows for the real-time exchange of information.
An IDOC (Intermediate Document) is a structured information set providing a standard format for moving information in and out of a SAP system. In this regard, it represents a similar concept to EDI, but IDOC is not a standard. It is 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 are able to convert an IDOC into another format so it may be understood and processed by a target system.
IDOCs contain a control record, a data record, and a status record (see Figure 14.7). 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, and 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), a large number of IDOCs will have to be sent and received in order to handle real-time integration.
BAPIs provide an object-oriented mechanism to get at the underlying proprietary SAP middleware technology, such as RFCs (see Figure 14.8). In addition to providing access to the data and processes, a benefit once only possible by means of specific methods, 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 that SAP provides.
To use a BAPI method, an application program simply needs to know how to call the method, such as its structure and parameters. The BAPIs in the R/3 system are implemented as function modules, all of which are held in the Function Builder. Each function module underlying a BAPI supports the RFC protocol and has been assigned as a method to a 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 are able to gather information from SAPs without having to drop down to primitive function calls. However, a BAPI does not provide everything needed to access SAP as a true set of objects. For example, a BAPI provides access to only a limited number of functions. That said, it is important to note that BAPIs are expanding their reach with every day.
The SAP repository, as mentioned previously, 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 a SAP system in order to provide better integration.
The advantage of using the SAP repository is the ability to discover as much as possible about the SAP system that is to be integrated. 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 as a mechanism to intelligently integrate the system. The real value of this approach will come from vendors who are looking to create EAI solutions that link deeply into SAP. Currently, the SAP adapters are more at the RFC level and do not take into account the content of the repository.
It's important to note that SAP is a dynamic ERP and is constantly morphing into new, more marketable products. This will only drive the need for additional integration and will certainly add to the already formable challenge of integrating SAP. For example, SAP is going to sell Web-delivered application services for mid-market companies. Thus, there is no need to host your own copy of SAP. While this does provide 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.
It's a given that SAP will be a part of most EAI efforts where an ERP is involved. 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 currently has, if it is to successfully open up. At this time, most SAPs accomplish this in such a way that they reach a wider set of technologies. In the end, 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—which is exactly where they'll have the most value.