Computers-for-edu：An Advanced Business Application Programming (ABAP) Teaching Case
Todd A. Boyle
The Computers-for-edu case is designed to provide students with hands-on exposure to creating Advanced Business Application Programming (ABAP) reports and dialogue programs, as well as navigating various SAP Enterprise Resource Planning (ERP) transactions needed by ABAP developers. The case requires students to apply a wide variety of ABAP concepts, including basic ABAP syntax, OPEN Structured Query Language (SQL), internal tables, external files, ABAP events, user-defined tables, screens, menus, title bars, function keys, drilldown reporting, and elementary dialogue programming. The case makes a very good final project in an introductory ABAP programming course. For an advanced ABAP course, this case is useful for reviewing introductory ABAP concepts prior to moving on to more advanced ABAP programming elements such as object-oriented programming and advanced dialogue programming (e.g., database updates, logical units of work). This case can be easily extended to include additional dialogue programming and object-oriented elements by, for example, having students write dialogue programs with tabstrip controls to manipulate data in the user-defined tables.
Keywords: ABAP, Programming, SAP Reporting, SAP Education
This fictional case was developed in consultation with recent graduates of the Bachelor of Information Systems - Enterprise Resource Planning Major program at St. Francis Xavier University, Canada. Graduates involved in Advanced Business Application Programming (ABAP) were asked to identify the key ABAP skills they needed early in their career and the type of programming they were doing. The case was written keeping in mind these key skills and job expectations. To gauge the appropriateness of the case for use in an introductory ABAP programming course, an initial draft was presented to IS faculty as part of a 5-day SAP University Alliance ABAP workshop.
Recognizing the different configurations of SAP software used at universities, this case does not rely on existing SAP database tables. Instead, students create the database tables and data needed for the reports and dialogue program, thus minimizing the preparation needed by the instructor to use the case. The case that follows requires students to apply a wide variety of ABAP and database concepts, navigate the SAP system, and search the Internet or SAP help for additional sources of ABAP information.
2. THE CASE
Wow! What a meeting! You return to your cubical and think about what just happened. A meeting with the senior business analyst, systems analyst, programmer, and others to discuss the supplier subsystem, a system you will be responsible for programming! At last, your first project as a junior ABAPer for Computers-for-edu. As you look over the System Requirements Document you ask yourself "can I do this?" You take a deep breath and think about what you have learned in your ABAP and SAP courses: reports...check; dialogue programs...check; OPEN SQL...check; events...check; drilldown reporting!!!!...must have missed that class. In addition to these specific terms referenced in the meeting, you know that while working on MIS project there are a number of broader skills you will further develop, including:
* creating professional quality ABAP reports and dialogue programs
* database manipulating and file handling
* program testing and testbed creation
* identifying SAP and Internet resources to assist ABAP developers
* understanding industry expectations of junior ABAP developers
You have a meeting with the lead programmer in two weeks to present your programs. Reviewing the System Requirements Document and recalling today's meeting, you already have a good idea of what is expected from you in two weeks time. Specifically, three ABAP reports (with drilldown capabilities and/or custom input screens) and one dialogue program all retrieving data from four database tables that the DBA has allowed you to create. In addition to working programs, you will also need program documentation and descriptions, a printout of each program, screenshots of the output reports and input and output screens, forms, events, proof of good programming style, and a testbed and description (i.e., conditions triggered) of data. It is going to be a very busy two weeks!
Computers-for-edu, a medium-sized company focused on manufacturing and installing desktop computers for use in North American elementary, junior, and high schools, is undergoing major changes in their business processes and information systems. The company has recently been acquired by a large computer supplier and is to be integrated into their SAP system.
Computers-for-edu provides a wide range of products and services to schools including acquiring and installing specialized educational software, security devices, and specialized hardware to support students with physical challenges. The company not only manufactures the computers, but also designs and sets up the computer lab in the school, repairs or replaces faulty hardware, and periodically upgrades the computers. Computers-for-edu therefore offers an alternative to hiring a computer lab administrator and represents a complete lab solution for schools that cannot afford a dedicated systems person.
All of the components (i.e., parts and sub-assemblies) that go into building a computer are purchased from suppliers. As schools can customize the computers for their specific needs and budget, the company maintains an inventory of common parts and sub-assemblies thus allowing them to begin building the computers as soon as a customer order has been placed.
4. SYSTEM REQUIREMENTS DOCUMENT
As a newly hired junior ABAP developer, you have been assigned your first ABAP programming assignment as a member of the organization. Specifically, you have been assigned the task of developing the custom transactions and reports that Computers-for-edu requires for decision making regarding their key suppliers (i.e., the supplier subsystem). The supplier subsystem provides information to operations managers, inventory control clerks, and purchasing clerks on parts (e.g., part description, reorder point, reorder quantity, location) and part suppliers (e.g., company name, contact details, overall quality).
To make sure everyone understands what is required, a meeting has been scheduled with those involved with the supplier subsystem including, among others, you, the systems analyst, the business analyst, a representative from the new parent company, and the database administrator. A key objective of the meeting is to have the systems analyst present the technical, performance, and usability requirements from the System Requirements Document and have project stakeholders sign off on these requirements, so that you can begin programming. After attending the meeting and reviewing the System Requirements Document in detail, you are ready to begin working on the project. Below are some key points you highlighted from both the System Requirements Document and the meeting.
4.1 Database Tables
The system will get data from four database tables, specifically ZPART, ZWSLOC, ZPTQUAL, and ZSUPDTL. The ZPART table will store data on computer parts, such as the part number, a description of the part, inventory reorder point, and reorder quantity. The ZWSLOC table will store data regarding the physical location of these parts in the warehouses owned by the company.
Computers-for-edu acquires its parts from a number of major computer component suppliers. The company continuously monitors and tracks the quality of the parts it receives from each supplier, including delivery time, conformance to specifications, and defect rate. The delivery time, conformance to specifications, and defect rate for the parts from each supplier is summarized by a scoring system, with 10 being excellent and 1 being poor. Managers will routinely analyze this data when deciding who to buy key parts from. Data summarizing part quality will be stored in the ZPTQUAL database table. The ZSUPDTL database table will store data on the company's part suppliers, including the supplier name, supplier address, and the key contact within the company. The structures of these four tables are presented below.
As these tables do not exist in the database, they must be created before you can code your programs. This is normally the task of the database administrator (DBA). However, to provide you with as much exposure to the SAP system as possible, the DBA has instead permitted you to create these tables in the development environment (i.e., sandbox). As a result, before you can begin coding your reports, you are required to create the ZPART, ZWSLOC, ZPTQUAL, and ZSUPDTL tables using the ABAP data dictionary transaction (i.e., SE11 - ABAP DATA DICTIONARY). Other ABAP developers (i.e., ABAPers) in the company are working on writing the conversion programs to populate the tables with the required data. As they will not finish the conversion for some time, you will populate these tables with your own data so that you can adequately test each program. As a result, you will use the data browsing and entry transaction (i.e., SE16 - DATA BROWSER) to populate each table with test data.
4.2 Part and Check Report
The first report will display data from the parts table. The report will therefore contain data regarding part type (e.g., part ID, description), reordering information (i.e., reorder quantity, reorder point), and the location ID of the part. This data will be displayed and possibly printed from specialized hand-held devices used by inventory control clerks. As a result, the report will require page breaks after every 14 records.
In addition to this data, inventory control clerks would like to know the exact location of parts in the warehouse so they can do a physical count if they wish. As this information is only needed periodically, it will not be presented on the main report. Instead, the report will contain drilldown reporting capabilities. The drilldown sub-screen will contain details of where to find parts in the warehouse. If the user drills down too far, such as attempting to drilldown on the sub-screen, an error message will be displayed hi the message box. Figures 1, 2, and 3 are screenshots from the System Requirements Document illustrate what this report should look like.
4.3 Supplier Quality Report
The second report will present details regarding the quality of the parts Computers-for-edu receives from its five major suppliers. The report contains two sections. The first section presents the parts the company purchases from suppliers and their summary quality data (e.g., defect rate, delivery time, conformance to specifications). This section also contains the name of the supplier and a contact email address. Those parts types that are of low quality are to be highlighted in red. Computers-for-edu defines low quality as any of the defect rate, delivery time, or conformance to specification criteria having a score of less than five. Section one (i.e., line details) of the report will be used to help determine who to first acquire parts from.
Section two of the report (i.e., summary details) will provide summary information on the overall quality of the company's five major suppliers. This section of the report will contain the number of defective/bad parts for each of the five suppliers, and the average score of defective parts on each of the defect rate, delivery time, and conformance to specifications criteria. This section is used to identify any potential quality problems impacting a supplier regardless of part.
The user of the report will have the option of sorting section one of the report by part, supplier, or cost. In addition, users can choose to run section one of the report, section two, or both sections. The following screenshots from the System Requirements Document illustrate what the supplier quality report should look like the one shown in Figure 4.
4.4 Part Dialogue Program
Given the large number of parts the company requires, using the above reports is not feasible if the user is interested in examining a specific part from a specific supplier. As a result, a dialogue program is needed to permit the user to look up information on a specific part. The input screen of the dialogue program will ask the user for the part ID and supplier ID of the part they are interested in. This input screen will contain a push button, permitting the user to get details on that specific part.
In addition, an exit push button is needed to allow the user to exit the program without getting part details (i.e., in case the user entered the screen by accident). If the user enters an invalid part or supplier ID or if the specific part is not supplied by the requested supplier, an information message will be displayed. Figures 7 and 8, taken from the System Requirements Document, illustrate what the input screen should look like.In addition, should the user have an issue with the particular part (e.g., quality of the part) or supplier (e.g., contact name changed) information presented, they can enter their issue in the "concern" field. By pressing the concern push button, full details of the part and supplier (i.e., fields on the output screen), along with the user's concern, user's SAP ID (i.e., a SAP system variable), and the system date and time (i.e., also SAP system variables) will be written to a concern history file. Once the record is saved, an information message will be presented to the user, followed by the input screen.
In addition to using the pushbuttons, the user can enter another part, exit, or create a concern by using the drop down menus, function keys, or the exit (i.e., exit the transaction), back (i.e., go back to the input screen), and save (i.e., save the concern to the file) standard SAP icons. Figures 9, 10, and 11 illustrate the output screens.
4.5 Concern Report
The final report for the supplier subsystem will display the various user concerns regarding parts or suppliers. The junior inventory clerk, whose job it is to address the various concerns, will use this report. This report will read the concern history file and write part (i.e., id, description) and supplier (i.e., id, name, contact email) details, the associated user concern, the user that wrote the concern (i.e., SAP user ID), and the date and time the concern was written to the file. The main report is highlighted in Figure 13. In addition, the user can drill down on a record to get additional cost and quality information. As with the other drilldown report, should the user attempt to drill down on the sub-screen, an error message will be displayed. Figure 14 highlights the drilldown section of the report.
There are a wide variety of concepts besides those addressed in the case that can be introduced in an ABAP course, including basic objected-oriented concepts, SAPscript, and BAPIs. As each program in the case tests a wide variety of items, the instructor must introduce a fairly long list of concepts in order for students to complete the case within a reasonable timeframe.
A limitation of this case is that the instructor will need to make a decision early in the course as to whether or not to use this case, as it will influence to some degree the concepts they should focus on. To ensure that students can complete the case, the instructor will need to introduce basic ABAP syntax (e.g., declaring variables, logical control structures, computations, counters, etc.), internal tables, user-defined tables, OPEN SQL, events, external files, screen and menu painters, input screens, and simple dialogue programming. In addition, the instructor must ensure that students have at least some familiarity with the following SAP transactions:
* SE11 - DATA DICTIONARY (i.e., create the database tables)
* SE16 - DATA BROWSER (i.e., populate the database tables with data)
* SE38 - ABAP EDITOR (i.e., create the ABAP reports)
* SE80 - OBJECT NAVIGATOR (i.e., create the dialogue program)
* SE93 - MAINTAIN TRANSACTION CODES (i.e., create the transaction codes needed to add the programs to the favorites menu)
Earlier versions of this case have been used in introductory ABAP programming courses with positive results. Discussions with students found that the case gave them a broader picture of how individual ABAP concepts and programming components fit together. In addition, a number of students felt that the case gave them a better understanding and appreciation of systems integration and testing, such as how a bug in one program can influence other programs throughout the system (i.e., Programs 3 and 4).
SAP specific terms used in the case are defined below. These definitions are taken from the SAP Help Portal glossary: http://help.sap.com/
ABAP - Advanced Business Application Programming. The SAP programming language for application programming
ABAP Dictionary-Central information repository for application and system data. The ABAP Dictionary contains data definitions (metadata) that allow you to describe all of the data structures in the system (like tables, views, and data types) in one place. This eliminates redundancy.
ABAP Editor - Tool in the ABAP Workbench in which you enter the source code of ABAP programs and check their syntax. You can also navigate from the ABAP Editor to the other tools in the ABAP Workbench.
ABAP Objects - The ABAP runtime environment or the object-oriented extension of ABAP. ABAP Objects uses classes to create objects.
ABAP Workbench - The ABAP Workbench is a fully-fledged development environment for applications in the ABAP language. With it, you can create, edit, test, and organize application developments. It contains a range of tools including the Screen Painter, ABAP Editor, and Repository Browser.
Application Server - The level within the client/server architecture in which application logic runs.
Business API (BAPI)-standard interface in the R/3 System that allows the system to communicate with components of other business software suites.
Client - A unit within an R/3 System that is complete in a legal and organizational sense, and which has its own user masters and own tables.
Database - Set of data that is part of a database system and is managed by the database management system.
Database Table - Most databases that are used for business applications are based on the relational database model, in which the real world is represented by tables.
Dialog Module - Statement block that describes the different states (PBO, PAI, user input) of a screen. A module pool contains a set of dialog modules.
Dialog Program - A program that contains (or consists entirely of) dialog modules.
Event Block-A series of statements that are processed when a particular event occurs when a program runs or in selection screen and list processing. Each event block begins with an event keyword, and ends at the introductory keyword of the next event block.
Foreign Key - One or more fields in a table that occur as key fields in another table.
Global Data - Data that is visible throughout a program (and also in procedures that it calls).
Internal Tables - Data object consisting of a set of Unes with the same data type. There are different access types for internal tables: Sorted and unsorted index tables, and hashed tables, and also different Une types: Vectors, "real" tables, with flat structures, and deep tables. You should use internal tables whenever you need to use structured data within a program.
Join - A technique for Unking two or more tables. The tables involved must have at least one common column.
Key - Selected fields of a table used to identify table records. A key may be either unique or non-unique.
Local Data - Data that is only visible in the current program (including its subroutines) or procedure.
Menu Painter-A tool in the ABAP Workbench that allows you to create menus and assign functions to function keys and pushbuttons.
Open SQL - A set of statements that allows you to access the database from an ABAP program. Open SQL statements are fully portable to any of the database platforms supported by SAP. Open SQL is a subset of Standard SQL (without the DDL part), but also contains SAP-specific extensions.
Report - Executable program with a three-stage function: Data input, data processing, data output. Reports read and calculate using data from database tables, without actually changing it.
SAPscript-SAP text management and form printing tool. SAPscript consists of the following components: an editor for entering and editing text, styles and forms for designing the print layout, a composer, which is the central module for output formatting, a programming interface for integrating SAPscript components in your own application programs and programming the output-using forms.SAP Transaction-A dialog-driven program, or any program started using a transaction code.
Screen - A screen (also referred to sometimes as a dynamic program or "dynpro") consists of the screen itself and the flow logic, which controls how the screen is processed. You create both the screen and its flow logic in the Screen Painter.
Screen Painter - Tool in the ABAP Workbench, used to create screens and their flow logic.
Subroutine - A procedure that you define in a program using the FORM statement, and which you can call any number of times from any ABAP program using the PERFORM statement. When you call the subroutine, you can pass parameters to it. Subroutines are normally used locally, that is, called in the same program in which they are defined.
Transaction Code-A sequence of letters and digits starts an SAP transaction when you enter it in the command field. Transaction codes are normally used to start dialog-driven programs. However, you can also use them to start reports. You create transaction codes in the Repository Browser. They are linked to an ABAP program and an initial screen.
Variable-A named data object that you can declare statically using declarative statement, or dynamically while a program is running. They allow you to store changeable data under a particular name within the memory area of a program.