SAP R/3 - A General Overview

In order to perform development using SAP R/3 in any shape or fashion, it's imperative to first gain some understanding of the purpose and functionality of SAP R/3 - a task that has always been a major hurdle for any Visual Basic programmer. As there is a lot of confusion about terminology and concepts when it comes to SAP R/3, one of the primary objectives of this chapter is to clarify the most important concepts and help a Visual Basic programmer to not get lost in this conceptual nebula. I have attempted to separate the things that we will use in programming, and things that you can find in the literature and in documents available from the SAP web site.

The SAP R/3 System

Let's define the SAP R/3 system itself: SAP R/3 is a self-sufficient, real-time, multi-user, client-server and multi-platform modular ERP information system that emulates virtually every aspect of a modern enterprise. SAP R/3 allows a certain degree of customization while enforcing a variety of strict data integrity driven rules. It has its own internal programming language (ABAP/4) and uses a variety of database back-ends (SQL Server, Oracle, Informix, etc.). SAP R/3 implemented event-chains and data objects well before event driven programming became a reality. Another way of looking at what SAP R/3 has to offer is to remind ourselves of an important functionality that every business depends on - decision making based on data processing. This is exactly what SAP R/3 does - it offers multi-dimensional views of data for various reporting purposes. SAP R/3's implementation of the enterprise workflow and the stimulus-response paradigm allows it to implement virtually every conceivable business scenario. We'll begin to explore the SAP R/3 system by dissecting our definition. SAP is Self-Sufficient SAP R/3 doesn't need any companion software to function (although it obviously needs a correctly set-up operating environment and communications). It comes complete with a bulletproof GUI front-end and other peripheral components. Another strong benefit of using SAP R/3 is that it's highly version compatible. In other words, different releases and revisions of SAP R/3 will cooperate just fine - if you want to upgrade just one module, that's not a trivial task, but it is possible. SAP is Real-Time This is one of the most important characteristics of SAP R/3. It has been historically developed as a real-time application that doesn't require any batch processing to perform transactions. Every data modification in SAP R/3 triggers an immediate chain of events, and these in turn run transactions to perform other necessary data modifications. For example, if you enter a sales order, it will affect inventory and accounting data immediately. Don't get the impression that just because SAP R/3 is a real-time system, it doesn't have scheduling functionality for processes. It does have such functionality. SAP is Multi-User SAP R/3 allows multiple concurrent logins governed by the licensing. It has a very solid security system and allows you to manage users. The important point is that SAP R/3 encapsulates the back-end RDBMS so completely that it doesn't delegate any user rights or other issues to the RDBMS - it does it all internally and transparently to the user. SAP is a Client-Server System SAP R/3 is a case study on how to implement true client-server systems. It is a very powerful and resource consuming system and, to minimize network traffic and load on client workstations, it implements a really tiny client that doesn't process much itself. The Internet Explorer on my workstation demands more resources than the SAP R/3 front-end. SAP was first developed for mainframe systems that don't have "client workstations". This is an alien concept for the majority of Visual Basic programmers, who learnt Visual Basic as their first programming language, using Microsoft Windows as OS and personal computers as hardware specification. We got used to the fact that any monitor with a GUI is connected to a full capacity PC, not all that different from the server computer.

At the beginning of the Visual Basic era, the emphasis was on client-side processing. In the server-side processing based mainframe world, the terminal was nothing more than the monitor and the keyboard, and all processing was carried out by the system on the mainframe. Mainframe 'clients' were so tiny and dumb that they only acted as entry points for the system. SAP R/3 adopted this paradigm: it is a thin-client, fat-server system. This is implemented as a three-tier client-server system:

A front-end An Application Server layer that implements all functional logic A database server that implements data storage

The SAP R/3 front-end takes advantage of the Windows OS, but it still only marshals requests to the server and displays results to the user. SAP R/3 offers robust component management capabilities and behaves very well under Windows. It doesn't halt I/O devices, doesn't freeze an interface and doesn't drain all resources from your PC. Another advantage of the SAP R/3 thin-client architecture is that the same front-end component works with different versions and releases of the SAP R/3 server - it has backward compatibility. This is a result of the SAP R/3 strategy to not change a function's interface for the server component. That strategy will be explored in more detail once we get into BAPI programming. SAP is Multi-Platform This is the area where SAP R/3 really shines. This book is for Visual Basic programmers and the OS is obviously Windows. However, SAP R/3 Unix installations outnumber Windows installations. (Note that when I refer to the Operating System that SAP R/3 is installed on, I mean the SAP R/3's system, not its GUI front-end.) As more and more new installations are using Windows NT as the platform of choice, I suspect we'll soon seen Windows NT take over as the main OS for SAP R/3. Many Unix based software components are still inaccessible to Visual Basic programmers, because Unix is not a COM environment. However, the SAP R/3 architecture and design make it possible to communicate with the SAP R/3 from virtually any platform, using any language that is capable of making a function call. This SAP R/3 feature bridges a cross-platform development gap that always haunts Visual Basic programmers. One of the few "last resort" types of arguments that Visual Basic's opponents have is that Visual Basic programs can only run on Windows, and are therefore limited. SAP R/3 is capable of accepting remote function calls from a Windows environment while being on a Unix or other non-COM compliant operating system. SAP is Modular SAP R/3 can be looked at as a collection of logical business modules. Each module implements a certain segment of an enterprise - for example, Financial Accounting, Logistics, or Material Management. I purposely use the word logical to introduce modules, because the physical implementation of SAP R/3 is beyond the scope of this book. To an external programmer, the physical implementation of any particular SAP R/3 functionality is transparent. All modules are closely interconnected and they share information and data integrity concepts.

SAP R/3 and Data Storage

We've seen that the core of SAP R/3 comprises programs that implement a very specific segment of an enterprise. Each module is a big system in itself, and it requires a good knowledge of a business component to successfully use and program a module. The areas covered are accounting and controlling, production and materials management, quality management and plant maintenance, sales and distribution, human resources management, and project management. For example, Materials Management handles the creation of new materials and other inventory related functionality. Sales Orders are created from Sales and Distribution. The important point is that those two modules work in close cooperation. The Sales and Distribution module will not let you create a Sales Order for a material that doesn't exist in the Materials Management module.

All these modules access data in the back-end RDBMS used by the SAP R/3 installation via a well-defined business and data integrity rules layer. The most interesting characteristic of SAP R/3 is that all the data is subjected to validation rules, and these rules are applicable across SAP R/3 as a system. In other words, if the data being entered make sense for the module they're being entered from, but are invalid for some other module, the data will be rejected. This takes an enormous burden off an external programmer who is creating programs to load data into SAP R/3. It happens because the SAP R/3 has various entry points for the inbound data, but all data are channeled through the same validation, regardless of the source. If SAP R/3 had validation only for data entered directly, all external programs would have been forced to mirror SAP R/3 rules. Those not familiar with the SAP R/3 can take my word on this, or ask an SAP R/3 expert: mirroring SAP R/3 business and integrity rules externally is tantamount to rewriting SAP R/3 itself. Another very interesting thing about SAP R/3 has always been the way it relates to its own back-end database. SAP R/3 uses various database management systems, depending on the user's choice or OS limitations. Regular information systems use some kind of RDBMS and can have a very creative application layer around their back-end databases. However, these databases remain standard in terms of access and management. For SAP R/3 (and all other releases of this product), the back-end database is completely shielded from external access. If, for example, you install SAP R/3 with Microsoft SQL Server, its database will not become your regular database for you to execute stored procedures or directly access data objects. SAP R/3 completely encapsulates its data storage and won't allow external applications to directly access its data. This is an absolute must for something of the complexity of SAP R/3, otherwise it wouldn't be able to guarantee data integrity. SAP R/3 implements many check tables that contain lists of all possible values for predefined fields. For example, you can't enter a value for the Country - e.g. USA - if it doesn't exist in one of the check tables. The SAP R/3 GUI will present you with a dropdown selector for the fields that have predefined values or values that can be selected from some other list. After all the selections are made, SAP R/3 will perform all necessary validations that involve different modules to ensure integrity of data. You can't, for example, sell merchandise that doesn't exist in the inventory, or to an unknown customer.

The SAP R/3 Internal Environment

All these rules and routines are implemented as ABAP Function Modules. ABAP (or Advanced Business Application Programming Language) is a proprietary SAP programming language - it is not used anywhere else. You can think of it as a scripting language or an SAP R/3 VBA. SAP R/3 acts like a host engine for this language, and you can feed an ABAP module into SAP R/3 and trigger its execution. To have one more parallel, we can compare this setup to ASP technology the script is not compiled into executable components and requires Microsoft Internet Information Server or Personal Web Server to run. ABAP is, to some extent, related to COBOL. It's easy for COBOL programmers to learn as a language, but the whole concept of SAP R/3 has always made it hard for anybody to actually utilize it. Even if you master the syntax of ABAP, you're still not likely to be able to use it effectively, because the language is very specific to the internal SAP R/3 functionality. This is the reason that ABAP programmers are in demand and compensated beyond industry standards. Because of SAP R/3's narrow scope of availability, you can't learn it unless you work with it. The real value of an ABAP

programmer is in their understanding of particular SAP R/3 business modules and their interoperability. The majority of these function modules can't be freely modified, because they comprise the core of SAP R/3's functionality. SAP has very cumbersome licensing policies and procedures that govern development for SAP R/3 and usage of it. Additionally, SAP R/3 implements special mechanisms and procedures to modify code or to apply service packlike fixes, and you can't bypass these mechanisms. I won't elaborate on this here, as it is way beyond the scope of this book. SAP R/3 implements an ABAP editor that allows you to create user programs. This editor lacks many of the modern code editor's features, but it lets you create the code - and that's all you need from a code editor anyway. The ABAP programming facilities also let you see the code for the SAP R/3 function modules that already exist in the system. It's important to understand that, while most of SAP R/3 is developed in C++ and C, ABAP is SAP R/3's internal scripting language. This is just like MS Access, which hosts VBA but is not developed in it. This paradigm allows SAP R/3 to enforce a strict developmental architecture for its internal needs. Because no other programming language works in SAP R/3, it can maintain universal ABAP based data types, logic and all other programming language constructs. All SAP R/3 data objects are accessible via the ABAP Workbench Data Dictionary facility. Data objects may be as simple as a field or as complex as a table. From the standpoint of learning SAP R/3 and developing applications in Visual Basic, the most important feature of the Data Dictionary is the ability to drill down the hierarchy of a data object. This exercise reveals the complexity of the internal SAP R/3 data architecture. It demonstrates that the data object may include other data objects as parts of it, and so on. All eventually comes down to a physical field in the back-end database, but the path may be long and complex. All data objects are closely integrated with function modules. Data objects are available for function modules; function modules do not comprise data objects. Function modules carry out data manipulations. Instead of having data validation and business rules hot-wired to triggers on the database level, SAP R/3 implements a much more flexible and technically correct method of the client component - interacting with the application layer, not directly with the database. This is an obvious design choice, made necessary because SAP R/3 supports many different DBMS's. A pictorial representation of this architecture is shown below:

This architecture provides an opportunity to encapsulate all the code needed for any given business module and treat the business module as an object itself. This concept requires a more detailed exploration.

Introduction to the SAP Front-End

So far, we've not seen any screen shots of the SAP R/3 front-end GUI. This was so as not to distract you from the conceptual paradigm of SAP R/3 as a system. However, now that you've almost finished Chapter 1, it's appropriate to start to familiarize ourselves with the SAP R/3 front-end GUI component. This section should not be looked on as an SAP R/3 tutorial - it's not. The aim is simply to break the initial barrier for a Visual Basic programmer - I've got the SAP R/3 frontend, now what? The initial reflex of any Windows user or Visual Basic developer is to find some kind of GUI component "attached" to implemented functionality. Because we're used to Windows' intuitive GUI implementation, it's natural to start learning from the GUI. To reproduce illustrations from this chapter you need:

Access to the SAP R/3 release 4.5A (4.0 will not be different from this perspective) Correctly installed SAP R/3 front-end software on your workstation. (The version used here is 4.0B. Refer to instructions in Appendix A.) A valid account for the SAP R/3 Note that data displayed on these screen shots might be different from what you see. If you have installed the SAP front-end component on your workstation you are most likely to have the SAP Frontend 4.x element under the Start | Programs group on your desktop. You should have an SAPlogon in that group:

Select the SAPlogon element, and you should see something like the following:

Then select the SAP R/3 installation you want, and logon. If you don't have the SAPlogon choice, or it's blank, ask your SAP programmer or administrator to help you with it. The first screen you will see is the login screen, which is presented to you upon successful connection of the front-end client to the SAP R/3 server:

After successful login, you should be presented with the SAP R/3 main screen:

Note the top-level menu items - these are related to the business modules that comprise the system. The SAP R/3 front-end software, like any GUI, reflects the internal functionality. What we are going to see is a visual representation of our discussion on SAP R/3 modules earlier in the chapter. Until now, they were very abstract and might have made little sense. Now we can see the implementation of these modules, and other SAP R/3 functionality. I have already referred to the Financial Accounting module: now we'll look at the first couple of screens that SAP R/3 will offer you in this module. Start by selecting Accounting. Then follow the Financial accounting | Accounts receivable menu choices as illustrated:

You should see the following screen:

Intuitively, you can guess that Accounting deals with account receivables, and those who pay you are your customers. This feeds directly into our discussion about how SAP R/3 implements enterprise and business functionality. You are obviously going to have customers, and therefore SAP R/3 provides you with the functionality to perform all operations involving customers. And as we have discussed, SAP R/3 logically groups functionality into modules, and modules are exposed to the user via the GUI component: To get into the Customers screen, select the Master records | Display menu items:

After you select the Display function, you will be presented with the following screen: Insert Image 9 This is a customer information display screen that allows you to search for a particular customer using different criteria. This exercise was supposed to give Visual Basic programmers an initial glimpse of the SAP R/3 system, and to illustrate the SAP R/3 front-end tool.

Summary
In this chapter, we introduced SAP R/3 as a system. We looked at some of the problems encountered in enterprise programming, and how SAP R/3 is used by modern enterprises. We outlined the conceptual, and to some extent technical, details of SAP R/3. One of the most important concepts introduced is that of SAP R/3 business objects and how they are used to emulate an enterprise. We also started to learn how and why SAP R/3 is being integrated with Microsoft Windows products, in particular Visual Basic. Finally, we introduced the SAP R/3 front-end GUI component. In the next chapter, we will expand our view of SAP R/3 as an implementation of an enterprise. We'll continue to explore business objects and BAPIs, and their relation to technologies familiar to Visual Basic programmers. We will address the similarities between SAP R/3 business objects and COM objects. We will also continue our gradual introduction to the SAP R/3 front-end component, and display some of the internal implementation of SAP R/3.