sappress abap objects application

Thorsten Franz, Tobias Trapp

ABAP Objects: Application Development from Scratch

Bonn � Boston

211_Book.indb 3 8/5/08 10:39:34 AM

Contents at a Glance

1 Introduction ................................................................ 17

2 Designing Application Systems .................................. 23

3 Application Object ...................................................... 51

4 Classes, Interfaces, and Exceptions ............................ 113

5 Application Architecture ............................................. 135

6 Application Layer ........................................................ 187

7 GUI Programming ....................................................... 229

8 SAP Business Partner .................................................. 331

9 Application Programming Techniques ........................ 391

10 Information Acquisition .............................................. 447

A Managing Development Projects ................................ 465

B Bibliography ................................................................ 487

C List of Quotations ....................................................... 491

D Authors ........................................................................ 493

211_Book.indb 5 8/5/08 10:39:35 AM

7

Contents

Preface ......................................................................................... 15

1 Introduction ................................................................. 17

1.1 About this Book ............................................................ 181.2 Sample Application and Technical Prerequisites ............ 21

2 Designing Application Systems ................................... 23

2.1 Requirements ............................................................... 242.1.1 Requirements Analysis as a Process ..................... 242.1.2 Functional Requirements .................................... 252.1.3 Non-Functional Requirements ............................ 252.1.4 Limits of Functional and Non-Functional

Requirements ..................................................... 342.1.5 System Specification ........................................... 37

2.2 General Architectural Considerations ............................ 392.2.1 Product Families: Separating Frames and

Content .............................................................. 392.2.2 Metadata ........................................................... 442.2.3 Generative Programming .................................... 462.2.4 Model-Driven Architectures ............................... 48

2.3 Using the Standard SAP System .................................... 49

3 Application Object ....................................................... 51

3.1 What Is an Application Object? .................................... 523.2 Modeling the Application Object at the Database Level 56

3.2.1 Structured Entity Relationship Model ................. 563.2.2 Data Modeling at the ABAP Dictionary Level ...... 61

3.3 Implementing Object Persistence .................................. 753.3.1 Necessity of Database Access Layers ................... 763.3.2 Object Services ................................................... 803.3.3 Inheriting Persistent Classes ................................ 853.3.4 Accessing Dependent Tables ............................... 88

211_Book.indb 7 8/5/08 10:39:35 AM

8

Contents

3.3.5 Query Service ..................................................... 923.3.6 Developing a Separate Persistence Service .......... 933.3.7 BAPI Access Methods ......................................... 94

3.4 Transaction Concept ..................................................... 953.4.1 Special Techniques of the Classic Transaction

Concept ............................................................. 983.4.2 Object-Oriented Transaction Concept ................. 99

3.5 Best Practices ................................................................ 1023.5.1 Creating Primary Keys ......................................... 1023.5.2 Modeling the Application Object in

the ABAP Dictionary .......................................... 1043.5.3 Service Functions for Persistent Objects .............. 1043.5.4 Saving Unstructured and Semi-Structured Data ... 1073.5.5 Further Considerations ....................................... 1103.5.6 Key Transactions ................................................. 111

4 Classes, Interfaces, and Exceptions ............................. 113

4.1 Advantages of ABAP Objects ........................................ 1144.1.1 Defining Constants in Classes and Interfaces ....... 1154.1.2 Function Groups versus Objects .......................... 1154.1.3 Events ................................................................ 116

4.2 Exceptions .................................................................... 1164.2.1 Classic and Object-Oriented Exceptions .............. 1174.2.2 Assertions ........................................................... 1204.2.3 Exception Handling ............................................ 121

4.3 Basic Principles of Object-Oriented Design ................... 1224.3.1 Dependency Inversion ........................................ 1234.3.2 Open-Closed Principle ........................................ 1244.3.3 Inheritance and the Substitution Principle .......... 1264.3.4 Testability Using Unit Tests ................................. 127

4.4 Classic Modularization Units ......................................... 1304.4.1 Function Modules .............................................. 1304.4.2 Reports .............................................................. 130

4.5 Best Practices ................................................................ 1324.5.1 General Considerations for Object-Oriented

Design ................................................................ 1324.5.2 Key Transactions ................................................. 133

211_Book.indb 8 8/5/08 10:39:35 AM

9

Contents

5 Application Architecture .............................................. 135

5.1 Requirements for Application Architecture .................... 1355.2 Software Structuring from a Technical Perspective ......... 1375.3 How To Structure a Software System ............................. 141

5.3.1 Taking Account of the Business Structure ............ 1415.3.2 Identification of Layers ....................................... 1445.3.3 Dividing Applications into Sub-Applications ....... 1455.3.4 Creating Basic Components ................................ 1465.3.5 Dependency on SAP Standard Components ........ 1475.3.6 Structure of the Sample Application ................... 147

5.4 Package Concept .......................................................... 1485.4.1 Package Interfaces and Checks ............................ 1505.4.2 Visibility of Package Interfaces ............................ 1535.4.3 Structure Packages and SAP Software

Components ....................................................... 1545.4.4 Excursion: Compatibility Problems ...................... 1575.4.5 Excursion: Naming Conventions and

Namespaces ....................................................... 1595.5 Composition of Packages .............................................. 161

5.5.1 Runtime Configuration of Software Components ....................................................... 162

5.5.2 Using Enhancements to Implement Interfaces .... 1675.5.3 Event-Based Interfaces ........................................ 170

5.6 Best Practices ................................................................ 1795.6.1 Architecture Documentation .............................. 1795.6.2 Characteristics of Package Splitting ..................... 1805.6.3 Interface Design ................................................. 1825.6.4 Package Check Mode ......................................... 1835.6.5 Outlook .............................................................. 1855.6.6 Key Transactions ................................................. 185

6 Application Layer ......................................................... 187

6.1 Application Logic .......................................................... 1886.1.1 Implementing the Application Object ................. 1906.1.2 Separation of Object and Process ....................... 193

211_Book.indb 9 8/5/08 10:39:35 AM

10

Contents

6.2 Customizing .................................................................. 1966.2.1 Basic Principles ................................................... 1976.2.2 Technical Customizing ........................................ 198

6.3 Search Services ............................................................. 2046.4 Workflows .................................................................... 209

6.4.1 Sample Scenario: Resubmission on a Specific Date ................................................................... 211

6.4.2 Key Transactions ................................................. 226

7 GUI Programming ........................................................ 229

7.1 Ergonomic Examples and Dialog Standards ................... 2307.1.1 SAP R/3 Style Guide ........................................... 2317.1.2 Ergonomic Examples ........................................... 2317.1.3 Menu Standards ................................................. 2337.1.4 Screen Layout and User Guide ............................ 233

7.2 Table Maintenance Dialog and View Cluster ................. 2387.2.1 Generating and Enhancing Table Maintenance

Dialogs ............................................................... 2397.2.2 View Clusters ..................................................... 2507.2.3 Tips for Handling Maintenance Views and View

Clusters .............................................................. 2587.3 Area Menus .................................................................. 2587.4 Object-Oriented Screen Programming ........................... 261

7.4.1 Pros and Cons of Subscreens ............................... 2617.4.2 Subscreens as a Modularization Unit .................. 2627.4.3 Encapsulating with Screens ................................. 2637.4.4 Message Handling with Screens .......................... 2637.4.5 BUS Screen Framework ....................................... 2647.4.6 Advantages of Object-Oriented Screens .............. 2667.4.7 Uses for the BUS Screen Framework ................... 2677.4.8 Normal Screens and Modal Dialog Boxes ............ 2677.4.9 Defining Flow Logic ............................................ 2697.4.10 Creating Instances .............................................. 2707.4.11 Calling Screens ................................................... 2717.4.12 Sequence of Processing Events ........................... 2717.4.13 Defining Your Own Screen Logic ......................... 2737.4.14 Setting Titles and GUI Statuses ........................... 273

211_Book.indb 10 8/5/08 10:39:35 AM

11

Contents

7.4.15 Handling User Inputs .......................................... 2737.4.16 Collecting and Issuing Error Messages ................ 2777.4.17 Embedding the Business Application Log ............ 2807.4.18 Table Controls and ALV-Grids ............................. 2837.4.19 Screens with Subscreen Areas ............................. 2837.4.20 Defining Subscreens .......................................... 2857.4.21 Data Transfer Between Screen Fields and

Screen Class ....................................................... 2867.4.22 Tabstrips ............................................................. 2877.4.23 For Advanced Users: Selection Screens

and Screen Painter .............................................. 2947.4.24 Selection Screens in Conjunction with the BUS

Screen Framework .............................................. 3007.4.25 Outlook .............................................................. 306

7.5 Web Dynpro ................................................................. 3067.5.1 Basic Principles ................................................... 3077.5.2 Creating a Sample Application ............................ 3107.5.3 Modification-Free Extensions Using Dynamic

Programming ...................................................... 3177.6 Best Practices ................................................................ 327

7.6.1 Choosing the Right GUI Technology .................... 3277.6.2 Software Factors ................................................. 3287.6.3 Key Transactions ................................................. 329

8 SAP Business Partner ................................................... 331

8.1 Background Information ............................................... 3318.1.1 The Creation of SAP Business Partner .................. 3328.1.2 Conceptual Overview ......................................... 3338.1.3 First Impression .................................................. 334

8.2 Business Partner Extension ............................................ 3368.2.1 Example of an Extension ..................................... 3368.2.2 Maintaining the Application ............................... 3388.2.3 Maintaining the Data Set .................................... 3398.2.4 Maintaining Tables ............................................. 3398.2.5 Maintaining Field Groups ................................... 3408.2.6 Views (Transaction BUS3) ................................... 3418.2.7 Sections (Transaction BUS4) ............................... 343

211_Book.indb 11 8/5/08 10:39:35 AM

12

Contents

8.2.8 Screens (Transaction BUS5) .............................. 3438.2.9 Screen Sequences (Transaction BUS6) ............... 3458.2.10 BP Views (Transaction BUSD) ........................... 3458.2.11 Creating Role Categories and Roles .................. 3458.2.12 ZVHM_BUPA Function Group .......................... 3478.2.13 Screen 0100 ..................................................... 3488.2.14 Events .............................................................. 3498.2.15 BDT Naming Conventions ................................ 3638.2.16 Testing the Extension ........................................ 3648.2.17 Troubleshooting ............................................... 3668.2.18 Summary .......................................................... 369

8.3 SAP Locator Extension .................................................. 3698.3.1 Introduction to the SAP Locator ....................... 3698.3.2 Aim of the Extension ........................................ 3708.3.3 Transaction LOCA_CUST ................................... 3708.3.4 Definition of the Hierarchy ............................... 3748.3.5 Creating an Append Search Help ...................... 3758.3.6 Creating the Elementary Search Help ................ 3768.3.7 Assigning the Search Help to the Append

Search Help ...................................................... 3768.3.8 Creating a Function Group ............................... 3778.3.9 Creating a Search Screen .................................. 3778.3.10 Form Routine to Initialize the Search ................ 3808.3.11 Form Routine to Get Search Fields ................... 3808.3.12 Form Routine to Set Search Fields .................... 3818.3.13 Form Routine To Create the Screen Object ....... 3818.3.14 Creating a Function Module ............................. 3828.3.15 Creating a Local Search Class ............................ 3848.3.16 Providing the Search ID in the Locator

Customizing ..................................................... 3868.3.17 Testing the Search ............................................ 3878.3.18 Summary .......................................................... 388

8.4 Key Transactions ........................................................... 388

9 Application Programming Techniques ......................... 391

9.1 Implementing the Application Log ................................ 3929.1.1 Log Recipients .................................................. 3939.1.2 Log Research as a Business Process ................... 393

211_Book.indb 12 8/5/08 10:39:35 AM

13

Contents

9.1.3 Business Application Log (BAL) ......................... 3959.1.4 BAL Data Model ............................................... 3969.1.5 Application Programming Interface (API) .......... 3969.1.6 Example: Creating and Displaying a Log ........... 3979.1.7 Example: Saving the Log ................................... 3999.1.8 Transaction Concept ......................................... 4019.1.9 Enriching Logs .................................................. 4039.1.10 Saving Complex Data ....................................... 4129.1.11 Using Additional Callbacks in the Display ......... 4159.1.12 User-Defined Buttons ....................................... 4169.1.13 Deleting and Archiving Logs ............................. 4179.1.14 Summary .......................................................... 4179.1.15 Additional Information ..................................... 417

9.2 Parallel Processing of Applications ................................ 4179.2.1 Use case ........................................................... 4189.2.2 Prerequisites .................................................... 4209.2.3 Asynchronous Remote Function Call (aRFC) ..... 4249.2.4 Parallelization with Background Jobs ................ 4379.2.5 Parallelization with the Parallel Processing Tool

BANK_PP_JOBCTRL ......................................... 4399.2.6 Summary .......................................................... 4449.2.7 Additional Information ..................................... 444

9.3 Key Transactions ........................................................... 445

10 Information Acquisition ............................................... 447

10.1 SAP Service Marketplace ............................................... 44710.1.1 SAP Help Portal ................................................ 44710.1.2 SAP Support Portal ........................................... 44810.1.3 SAP Developer Network ................................... 448

10.2 ABAP Keyword Documentation .................................... 45010.3 SAP Design Guild .......................................................... 45110.4 Internal Workings of AS ABAP ...................................... 451

10.4.1 Debugging ....................................................... 45110.4.2 Information Sources in the SAP System ............ 45310.4.3 Runtime Analysis .............................................. 45410.4.4 Database Trace ................................................. 45710.4.5 Environment Analysis ....................................... 458

211_Book.indb 13 8/5/08 10:39:35 AM

14

Contents

10.5 Knowledge Management .............................................. 45910.6 Key Transactions ........................................................... 461

Appendices .......................................................................... 463

A Managing Development Projects ............................................ 465A.1 Roles in Development Projects ..................................... 465

A.1.1 The Role of the Chief Software Designer ............. 465A.1.2 Frameworks and Tools ........................................ 466

A.2 Quality Management .................................................... 467A.2.1 Risk Management ............................................... 467A.2.2 Development Guidelines .................................... 469A.2.3 Code Inspections and Enhancement of the

Code Inspector ................................................... 470A.2.4 Creating a Documentation .................................. 480A.2.5 Enabling a Check ................................................ 481A.2.6 Software Test ...................................................... 482A.2.7 Documentation .................................................. 483A.2.8 Key Transactions ................................................. 486

B Bibliography ........................................................................... 487 C List of Quotations .................................................................. 491 D The Authors ........................................................................... 493

Index ............................................................................................. 495

211_Book.indb 14 8/5/08 10:39:35 AM

51

“Objects serve two purposes: They promote understanding of the real world and provide a practical basis for computer implemen-tation.” (James Rumbaugh)

Application Object3

The paradigm of object orientation means that software is seen as a quantity of discrete objects that have a data structure and data behavior. This perspective is completely natural at the application design level, because this approach can be used to map the business entities of the conceptual design. Object-oriented programming involves creating an equivalent to the business entities in each case, such as invoices or docu-ments. The following are characteristic features of an object designed and programmed in this way:

An EE object identity can be defined: An object exists but once and must be uniquely identified.

An object has properties that are encoded in EE attributes. These are defined in ABAP by ABAP Dictionary data elements.

Objects also have behaviors that are encoded as EE methods.

Objects of the same type (in terms of the same attributes and behav-EE

ior) are categorized. They are instances (or also copies) of a class. In the sample application presented here, the central objects are instances of a vehicle class.

Classes have a hierarchical structure through EE derivation. Derived classes are more specific than their predecessors. The basis classes are therefore true generalizations.

Object orientation helps you implement business processes flexibly, because you can keep several instances of business entities in an inter-nal session at the same time. This lets you implement methods that can compare, copy, or possibly consolidate these instances.

Paradigm of object orientation

Implementing business processes flexibly

211_Book.indb 51 8/5/08 10:39:41 AM

52

3 Application Object

In this chapter, you will learn about the techniques required to do this. For the Vehicle Management sample application, you will design an application object at the semantic level and create a data and object model.

In Section 3.2, Modeling the Application Object at the Database Level, we will discuss the mapping of the data model at the database level in detail. Section 3.3, Implementing Object Persistence, deals with imple-menting object persistence, as the name suggests. For example, how are ABAP objects saved to the database? We will introduce different types of database access layers, where the focus will be on Object Services. The SAP transaction concept is illustrated in Section 3.4, Transaction Concept, because you must thoroughly understand databases and SAP transactions for developing and using database access layers. The chapter concludes with Section 3.5, where we present best practices for all topics already discussed. This section will also describe specific topics, such as using change documents for persistent objects, for which you will need a num-ber of the techniques developed in this chapter.

What Is an Application Object? 3.1

At the core of typical applications for SAP systems is a relatively complex application object whose data is saved to one or more tables and which contains specialized methods that can be used to manipulate the applica-tion object. Typical examples include business entities such as customer, invoice, document, or delivery.

How do you identify application objects? In almost all cases, the appli-cation object results from the product idea, whereby the application will need to manage a central business entity. If a system specification is object-oriented, you will find application objects for object-oriented analysis.

In addition, more than one application object may exist in an application system, in which case it is useful to modularize the application into sub-applications. This is the topic of Chapter 5, Application Architecture.

You find application objects by breaking down an overall object model into logical parts. This procedure is the key to every successful modeling

Object-oriented analysis

211_Book.indb 52 8/5/08 10:39:41 AM

53


process. Instead of being analyzed in the overall model, each more com-plex system is initially identified in submodels of greater cohesion.

VehicleEquipment

Assembly

1 *

1

*

OperationProducer

0.. 1

*

1

1

Application ObjectFigure3.1

There are two central application objects in this sample application, vehi-cle and request. Figure 3.1 illustrates the strategic structure of the Vehicle application object in Unified Modeling Language (UML). The semantics are as follows:

A vehicle is normally assigned to exactly one operation where it is allowed. When a vehicle changes the operation to which it is assigned in an orga-nization group, it temporarily might not be assigned to any operation. In fact, there is a time frame the user should also be able to recognize.

A vehicle has exactly one producer. To map the producer data, you can access the SAP Business Partner available on every SAP system. To map this producer, you can easily access the standard SAP system and cre-ate a field on the vehicle that you can use to refer to a business partner number.

A vehicle has a number of equipment parts, such as the type of passenger information (for example the recorded announcement of stops). How-ever, this also includes fittings like seating, paintwork, and advertising (for example side panel, or full wrap advertising). You should model the equipment parts as independent objects. There is no provision made to enable you to assign a fitting to another vehicle.

Vehicles have assemblies. Unlike the equipment, they have a serial num-ber, year of production, and so on. You should be able to assign assem-blies to another vehicle.

Example of an application object

211_Book.indb 53 8/5/08 10:39:42 AM

54


The object-oriented analysis is followed by the design phase, where the object model that is used as the basis for the implementation is also developed. While the object-oriented analysis returns a domain model of the application, the result of the object-oriented design is a class model and sequence diagrams. Here, you should consider the class model and the requirements for database persistence, which must satisfy each busi-ness application object.

Different procedures exist in software technology for designing objects. Some software designers design an object model first and then develop a data model from this object model. However, the reverse is also possible, that is, you can design a data model and develop an object model based on it. Advocates of agile methods often favor incremental procedures. That is, for example, if you make modifications to the object model you will also need to make modifications to the data model, and vice versa. Agile methods in ABAP development are certainly a major challenge. If you choose this option, you will need detailed knowledge of the refac-toring options of the ABAP Workbench, but should also be aware of the implications of a structural change to transparent tables.

The procedure is as follows:

Starting with the class model from the analysis phase, you design the 1. application object.

You then develop the data model at the database level, starting with 2. the attributes and object model relationships.

Finally, you implement the object persistence, meaning you map the 3. object at the database level.

There are two advantages to this procedure: First, the focus early in the design phase is on the database model. You will be able to ensure in good time that it is optimized in terms of access paths, satisfies revisory fac-tors, and can be found easily in the archive. Second, you can implement the object persistence using the Object Services of the ABAP Workbench.

In the following text, we will discuss the aspects you must take into account when designing application objects, such as the granularity of the object model.

Object-oriented design

Procedure

Advantages

211_Book.indb 54 8/5/08 10:39:42 AM

55


In most cases, the application object is not an instance of an individ-ual class, but instead consists of compositions and associations to other classes. Examples include header and item data that you frequently find in SAP ERP applications. It may prove useful to implement these types of compositions at the level of structured data types, rather than using a wide variety of classes, and therefore use the options of internal tables and, if necessary, also deeper data structures. This lets you reduce the number of runtime objects as well as easily access quantities of object attributes as internal tables. This approach is particularly beneficial in performance-intensive applications. This procedure is often used in EDI processes, where, for example, the Data delivery (external) application object has a quantity of raw data in an external data format that cannot be implemented as an independent object. In fact, after typing this raw data and instancing a new Data delivery (internal) application object, you must not model temporary data, such as address components (which may involve you having to update the master data at a later stage) as separate objects.

In the next step, you should try to use business objects from the standard SAP system. You must define a producer for a vehicle in the sample appli-cation. It would be useful here to map the possible business partners as SAP Business Partners and include the business partner number as a ref-erence in an attribute in the Z_CL_VEHICLE class. An example of the class model obtained using this approach is shown in Figure 3.2.

Z_ CL_ VEHICLE

- PRODUCER

Z_ CL_ EQUIPMENT1

*

Z_CL _ COMPANY0..1*

Z_ CL_ ASSEMBLY

0..1

*

Design of an Application ObjectFigure3.2

Granularity of the object model

Using business objects from the standard SAP system

211_Book.indb 55 8/5/08 10:39:42 AM

56


The Z_CL_VEHICLE class has an attribute that specifies a business partner number in the producer role.

Not all attributes of an object must have a one-to-one correspondence to a field in a database table. In addition to database attributes that repre-sent the fields of assigned database tables, do you also want virtual attri-butes that will be calculated, or read from other tables? In this case, you do not need to take the corresponding attributes into account in the data model. After you have finished designing the application object, you can begin modeling it at the database level.

Modeling the Application Object 3.2at the Database Level

The database design is a key component of every business application. You can develop it based on a model for object-oriented design. Alter-natively, you can develop a semantic data model, implement it based on the ABAP Dictionary, and derive an object model from this. You will learn about this procedure in conjunction with the Structured Entity Relationship diagram in Section 3.2.1.

You must be particularly thorough when creating data models. It is dif-ficult to modify the data model of an application that is already live because you have to write comprehensive conversion programs. If you have just archived live data, the effort required will be even greater, because you will have to check the effect on archiving objects (Transac-tion AOBJ) when a modification is made.

You focus on two aspects when modeling data: the data model must enable you to access data efficiently and have a simple structure so that it can be evaluated by DataSources for SAP NetWeaver BI, or enable you to display archives using methods of the standard SAP system.

Structured Entity Relationship Model3.2.1

You can use the SAP Data Modeler integrated into the ABAP Workbench to create data models. Figure 3.3 shows a small portion of the SAP_10130 SAP Business Partner data model . This example also illustrates that you can use data models to document existing applications.

Virtual attributes

Two aspects

211_Book.indb 56 8/5/08 10:39:42 AM

57

Modeling the Application Object at the Database Level 3.2

Partial SAP Business Partner Data ModelFigure3.3

Unlike the Entity Relationship diagram, the Structured Entity Relationship diagram (SERM) consists of directional arrows. An arrow means that the target entity depends on the source entity in terms of the relationship of a header record to item records. An item record can therefore only exist if a header record exists (this is called existence dependency). In this case, the letter “H” above the arrow stands for “hierarchical”. The double or single arrowheads indicate that several entities, or only one single entity, participate(s) in the relationship. A single line signifies that the relation-ship is optional, meaning that an element may also be missing on the target side.

You call the Data Modeler from Transaction SD11, but it is also inte-grated into the ABAP Workbench. You can display data models or their entity types in Transaction SE80 under Business Engineering • Data Models or Business Engineering • Entity Types.

You will use the Data Modeler to develop an SERM diagram from the design model shown in Figure 3.2. You will create a data model called ZVEHICLE first.

Data Modeler

211_Book.indb 57 8/5/08 10:39:42 AM

58


You will set up a ZVEHICLE business object in Chapter 6, Application Layer; therefore, it will be useful to assign the data model using this approach.

To do this, you will create entity types for all classes:

EE The ZVEHICLE entity type corresponds to the vehicle data.

ZOWNEREE defines the assignment of a vehicle to a company. A vehicle is only assigned to one company at a time; you can use the time frame to map different transfers of vehicle ownership.

ZEQUIPMENTEE represents the equipment data. Like ZOWNER, this has a hierarchical (that is, existence-based) dependency on the vehicle entity type, although no time dependency is involved here.

ZASSEMBLYEE represents assemblies. These have a referential relation-ship to the vehicle entity (letter “R” above the arrow). Letter “C” (for “conditional”) specifies a conditional relationship. This modeling demonstrates that an assembly can also exist without a vehicle if it is removed from one vehicle and built into another vehicle later.

Figure 3.4 shows the data model, visualized by the SAP Data Modeler.

Vehicle Data ModelFigure3.4

Creating entity types

211_Book.indb 58 8/5/08 10:39:42 AM

59


You can create this data model using the ABAP Workbench by fi rst creat-ing the entity types displayed in the fi gure. Other documentation options are also available here, for example, you can create SAPscript texts for all entities and for the data model. For each entity type, defi ne detailed relationships (using the button of the same name or (F6)) to other enti-ties that correspond to the arrows shown in Figure 3.4. You still have to assign the entity types to the data model using the Hierarchy button, as you can see in Figure 3.5. You can still subsequently move the entities if you think that the positioning selected by the Data Modeler is unclear.

Data Model EntitiesFigure3.5

You will fi nd the Data Modeler in the SAP Library under the keyword Data Modeler (BC-DWB-TOO). The SAP SERM model also provides other relationship types (aggregating and external) and specializations for modeling inheritances. You can also create submodels, hierarchically nest them, use external relationships to refer to them and link data models to business objects to ensure that you achieve an integrated description of the application object, consisting of object behavior and object data, in the SAP system. SERM models are generally quite suitable for data modeling composite objects, because they are in the third normal form in terms of database theory.

Normalization can be seen as optimizing the data model, which results in redundancies and anomalies being avoided when you access databases.

Creating data models

Data models of business objects

211_Book.indb 59 8/5/08 10:39:43 AM

60


We will not be able to discuss the theory of normal forms as it is beyond the scope of the book.

The SAP Data Modeler enables you to assign entity types to ABAP Dic-tionary elements such as transparent tables or views. This means that you can link SERM models to the database model. Mapping the SERM model in the ABAP Dictionary is the topic of Section 3.2.2, Data Model-ing at the ABAP Dictionary Level.

Knowledge about database normalization is an important basis for each data modeling, as well as an essential requirement here. Information about this topic can also be found in every book about databases.

Normalized data models correspond to the semantic data model from the business blueprint, and SAP SERM models are usually already in the third normal form. Normalized data models do not have any redun-dancies and no anomalies occur for database operations. However, they are not optimized in terms of database access. In this type of optimi-zation, you specifically narrow down the most common requests, and also accept redundancies in the data model, to minimize the number of requests. You achieve this by keeping fields in database tables redundant and saving the results of calculations (such as aggregated values at the database level) in the database. The following forms of denormalization are widely used in SAP development:

EE The most common form of denormalization is keeping attributes redundant. You usually save the last and first names of business part-ners or classification criteria from other tables.

For temporary data, you can duplicate tables for which you expect EE

large data volumes. If these tables are distributed to different parti-tions at the database system level, parallel access can be accelerated. You can use Customizing to control which tables to select for which transaction data.

If you are sure that a number of attributes will not be populated in EE

most cases, you can create a separate table for them and create the corresponding records only as required.

Normalization

Forms of denormalization

211_Book.indb 60 8/5/08 10:39:43 AM

61


Denormalization

The following rules apply for optimization of the database model:

You must not use denormalizationEE lightly; Denormalization is only useful for optimizing frequently-performed access to databases.

Denormalization is often avoided for write-only applications to prevent EE

change anomalies.

Read-only applications are often considerably denormalized to prevent EE

joins, aggregations, and calculations at the database level.

Data Modeling at the ABAP Dictionary Level3.2.2

The ERM and SERM data models are characteristically semantic. You must develop a data model out of them that consists of transparent tables. The relevant aspects required for this are described in the following text, and include defining primary and foreign keys, indexes, database locks, sav-ing unstructured data, and so on.

Primary Key

Each transparent table contains one primary key with a unique con-straint. Two table rows must have different primary keys. Master and transaction data should also contain the client in the primary key to ensure that the application system has multitenancy capabilities.

To create primary keys, you can define either specialized or technical keys. A specialized key is created by the attributes that define the iden-tity of an object as a whole. You must use specialized keys with caution because if the specialization changes, or if you discover that the key has been modified, extensive recoding will be necessary.

Number ranges enable you to generate keys for application objects. This also allows you to store specialized information in the keys by defining subobjects and including fiscal years. You define number ranges in Trans-action SNRO. Note the following when using number ranges:

Specialized componentsEE Specialized components in a number range help persons responsible when they are processing business objects, because they can memo-rize these components, if necessary. Specialized components also sup-

Unique constraint

Number range objects

211_Book.indb 61 8/5/08 10:39:43 AM

62


port developers and support. Under no circumstances should a pro-gram evaluate these specialized components because this would cause the disadvantages of specialized keys to be inherited. There can be exceptions if you want to merge data from different SAP systems as part of a merge project. However, this requires assigning the numbers disjointly in the different systems, which involves additional coordi-nation effort.

Assigning external numbersEE You should assign the numbers outside of the SAP system using an external number assignment. These types of cases are common for migration projects or external data transfers from other systems.

Deactivating bufferingEE If you want assigned numbers to have the character of a document, you must deactivate main memory buffering to ensure that the num-bering is consistent, even if the Logical Unit of Work (SAP LUW) were to terminate. A logical unit of work (or SAP transaction) is a sequence of related database operations, which are discussed in detail in Sec-tion 3.4, Transaction Concept. For more information about number range buffering, refer to the SAP Number Range Buffering (BC-CST-NU) section in the SAP Library.

Assigning a numberEE The NUMBER_GET_NEXT function module accesses the database and requires a certain amount of access time for activated main memory buffering.

Maintaining interval statusesEE Each customer must maintain the statuses of number range inter-vals. The statuses cannot usually also be delivered with the software, because the current values are also transferred in this way. This often makes no sense in the target system, or is even risky if you want to install the software again.1

1 You can, of course, use a report to set the initial statuses of the number ranges by manipulating the transparent NRIV table. However, this approach is extremely risky, because multiple uses mean that the uniqueness of the numbers may no longer be possible. Consequently, you may no longer be able to determine primary keys. We therefore advise you to always write these programs as securely as possible to eliminate the risk of statuses being reset that have already been maintained.

211_Book.indb 62 8/5/08 10:39:43 AM

63


You create number range objects in Transaction SNRO, as shown in Fig-ure 3.6. In this case, you defi ne a domain for the number length, buffer the numbers in main memory, and specify to issue a warning if only ten percent of the numbers are still available.

Creating Number Range ObjectsFigure3.6

After creating the number range object, you create the intervals. Inter-vals must not overlap; exceptions are only allowed if there is a reference to the fi scal year. If you assign a number, you must specify an interval where the generated numbers should be located. Alternatively, you can specify that the numbers roll back. This means that when you start an interval the numbers are assigned again from the beginning as soon as the upper limit is reached (Transaction SNUM, see Figure 3.7). You can

Transaction SNRO

Intervals

211_Book.indb 63 8/5/08 10:39:44 AM

64


also identify intervals as “external”. In that case, the number is assigned by the user or an external system. This type of number range intervalcan also contain alphanumeric characters if this is allowed by the domain used. You can use the NUMBER_CH ECK function module to check whether a number belongs to a certain number range interval.

Creating Number Range IntervalsFigure3.7

You can also classify number ranges according to fi scal year . You can clas-sify number range objects by subobjects. In the example, you can create a separate domain for different request types and assign your own inter-vals for each characteristic value.

Other structuring is also possible, using number range groups . The stan-dard example in Materials Management is the MATERIALNR number range object for the material master, for which the material type (MTART data element) determines the number range interval using Table T134(which is specifi ed in the number range object).

You will fi nd plenty of examples of this procedure in the SAP ERP envi-ronment. However, we advise against overdoing this by assigning num-bers with too many specialized aspects. We will use a negative example to confi rm this: Assume that you assign numbers for different materials depending on the vendor. As a result, you receive a key (either struc-

Fiscal years

Number range groups

211_Book.indb 64 8/5/08 10:39:44 AM

65


tured or concatenated as a fixed-length string) that contains a year, the domain value depending on the vendor, the interval number, and the actual number. You must first make sure that none of the parts of the key for specialized processes are evaluated in the application. If this is actually the case, there may be a risk of nasty surprises if the specializa-tion changes, for example, if two vendors merge. Experience shows that the risks of complex number range objects together with subobjects and groups outweigh the advantages in most cases, unless sophisticated data modeling was maintained.

For more information about number ranges, refer to the SAP Library under BC Extended Applications Function Library • Number Ranges.

Global Unique Identifiers (GUIDs) enable you to generate technical keys. Using GUIDs makes using number ranges effortless, and you get a purely technical key that enables you to merge data from different live instances of the application system again. You create GUIDs using the GUID_CREATE function module of the SYGU function group. As of Release 7.0, GUIDs have the benefit of distribution properties, which means that you can easily receive packaging options as part of parallel processing. We also recommend this key assignment for application objects that are used in cross-system processes and for which uniqueness is therefore essential. We examine this aspect in Section 9.2.2, Prerequisites, as part of paral-lelization strategies.

Based on experience, GUIDs are not suitable for display in screens. They are also not user-friendly for the person responsible; numbers are easier to use.

Defining External Keys

You can define external keys in the ABAP Dictionary but they are not represented by external keys in the database. Consequently, you cannot guarantee the referential integrity of the dataset using database tools.

However, this does not mean that you should forego defining exter-nal keys. You use them to document the data model of the applica-tion system. You can also use external key relationships to implement

Global Unique Identifier (GUID)

211_Book.indb 65 8/5/08 10:39:44 AM

66


(F4) help and input checks on dialog boxes. You can generate complete maintenance dialogs specifically for maintaining Customizing tables and simple master and transaction data, as you will see in Chapter 7, GUI Programming.

Mapping Inheritance

Different options are available for expressing the inheritance of classes at the database level. You can use separate tables for each class and map the entire hierarchy in a single table:

Mapping an entire class hierarchy in one tableEE The advantage of mapping an entire class hierarchy in a table is that one class can be converted easily into another class. This is the case in the example here when a vehicle changes its type. Database queries are also usually easy to organize. However, the disadvantage is that often, a lot of memory space is wasted in the database because not all attributes are required in every class. Perhaps more annoying than the waste of memory space is the lack of transparency: You cannot easily identify to which class attributes belong.

Mapping a class to a tableEE Mapping a class to a table comes closest to object-oriented modeling. In addition, you can change each class irrespective of other classes, and delete and add attributes as you wish. The disadvantage of this approach is that the number of database tables is very high, and access can be complicated. The effort required also increases if you want to add attributes to or delete them from all tables when you modify the data model. Queries can be very complex when you have a wide range of tables.

In many business applications, inheritance relationships are expressed by different composition relationships to other objects. For example, the parent class is usually abstract and represents the header data of an entity. The different derived classes all have the same header data but may have different item data. The problem of mapping inheritance does not arise in these situations.

Options

Inheritance relationships

211_Book.indb 66 8/5/08 10:39:45 AM

67


Locks

You use database locks to ensure that several internal sessions (users or jobs) do not access the same object at the same time, which could cre-ate inconsistent statuses, or situations where only data written by the last person would be saved. What effects could not having locks have? The first is lost modifications. When two programs read a value from the database in a local variable in parallel and change and write this value back, the last transaction that made modifications overwrites the modi-fications made by the previous transaction. Even if only one transaction writes data, while another transaction accesses read-only data, you will not be able to rule out inconsistencies in the second transaction. You must also protect reading processes against writing processes.

Dirty reads are another problem. If a transaction is working on an entry and later executes a ROLLBACK WORK, written entries will be reset again in the meantime. If another process is using this data before it is “released” by COMMIT WORK, there is a risk that invalid data will be used.

Locks can have different granularities. For example, you can lock single records, but you can also lock entire tables or use different lock con-cepts, namely optimistic and pessimistic locks. The pessimistic lock con-cept involves locking a database before each access, whereas the optimis-tic lock concept means that you generally forego database locks and use a time stamp to check whether a record has changed in the meantime. This saves time and effort required to manage database locks. Isolation levels of the database management system are closely associated with this.

ABAP development also has a lock concept that is not based on database locks and is described in the SAP Library under The SAP Lock Concept (BC-CST-EQ). Here, you manage locks in main memory on an enqueue server that exists on the central instance of the SAP system or on a separate server. If a work process is not running on the instance of the enqueue server, a lock request is sent through the dispatcher and the message server. Nevertheless, managing these locks does not require as much effort as managing database locks, because you manage them in main memory.

INSERT, UPDATE, MODIFY or SELECT ... FOR UPDATE set database locks for database modifications only. This type of database lock is held until

Dirty reads

ABAP lock concept

Deadlocks

211_Book.indb 67 8/5/08 10:39:45 AM

68


the next database commit, but not necessarily until the end of the LUW. These locks can be the cause of deadlocks if other processes access the same data and each process is waiting for the other process to release the lock again.

However, there are other differences between SAP locks and database locks. You can also create SAP locks for records that do not yet exist in the database. You must use SAP locks when you work with updates, because the database modifi cations are only implemented in the update and no database locks can exist beforehand.

You create lock objects in Transaction SE80, as shown in Figure 3.8. For example, create a somewhat more complex lock object for which you can lock several tables of an application object, that is, the equipment parts for a vehicle (ZEQUIPMENT table) and the owner (ZOWNER table). As a result, additional lock parameters are created for the components of the primary key of all tables involved.

Creating a Lock ObjectFigure3.8

SAP locks and database locks

Creating lock objects in the

ABAP Workbench

211_Book.indb 68 8/5/08 10:39:45 AM

69


Secondary Tables with Lock Objects

If you create the primary keys of the dependent tables in such a way that they contain the primary key fields of the original table, and if you also define foreign key relationships, you can include the dependent tables as secondary tables in the lock object and also lock these tables. If this is not the case, you may have to define additional lock objects for dependent tables.

You generate an enqueue module for a lock object. This enqueue module has several standard parameters. The mode parameter speci-fies the lock mode. Some lock parameters you use to specify the area to be locked include the _scope parameter, which describes the inter-action of locks and updates. You can use the wait parameter to con-figure the number of repeat attempts and the _collect parameter to buffer the lock requirements locally in a lock container before the FLUSH_ENQUEUE function module collects and transfers them into the lock table.

The following lock modes exist:

EE The exclusive lock (“E” lock mode) can be requested several times per session by the lock owner but there must be no shared or exclusive locks from other lock owners. Exclusive locks cumulate and must be released again several times.

The EE exclusive but not cumulative lock (“X” lock mode) can be requested only once in the internal session, provided there are no exclusive or shared locks from the same lock owner or other lock owners.

EE You can have several shared locks (“S” lock mode) in parallel but there must be no additional exclusive locks. You can use shared locks to protect displayed data records from being modified.

Optimistic locksEE are shared locks you can convert to exclusive locks by calling a lock with the “R” lock mode. In that case, other existing locks will be invalidated.

Enqueue modules

Exclusive lock and exclusive but not cumulative lock

Shared locks

211_Book.indb 69 8/5/08 10:39:46 AM

70


Optimistic Lock Concept

Because the optimistic lock concept is relatively new, we will explain it in more detail at this point. SAP’s optimistic lock concept sets shared locks, and therefore protects against modifications (provided other optimistic locks were not converted into exclusive locks). The SAP optimistic lock concept is suitable if different processes set shared locks, of which only a small number actually want to modify data later. This is the exact analogy for the lock con-cept from classic database development. There, you forego database locks and use time stamps to query whether a modification occurred in the mean-time.

You call the lock module as shown in Listing 3.1.

DATA: ls_msg TYPE scx_t100key,

CALL FUNCTION ‘ENQUEUE_EZVEHICLE’ EXPORTING mode_zvehicle = iv_enqmode mode_zequipment = iv_enqmode mode_zowner = iv_enqmode id = lv_id _scope = iv_scope _wait = iv_wait EXCEPTIONS OTHERS = 3.IF sy-subrc <> 0. ls_msg-msgid = sy-msgid. ls_msg-msgno = sy-msgno. ls_msg-attr1 = sy-msgv1. ls_msg-attr2 = sy-msgv2. ls_msg-attr3 = sy-msgv3. ls_msg-attr4 = sy-msgv4. RAISE EXCEPTION TYPE zcx_locking_error EXPORTING textid = ls_msg.ENDIF.

Calling a Lock ModuleListing3.1

The central component of this listing is the call for the generated ENQUEUE_EZVEHICLE lock module, to which you transfer four parameters: the lock mode in the IV_ENQMODE parameter with the “E” default value, the IV_

211_Book.indb 70 8/5/08 10:39:46 AM

71


SCOPE parameter with the “2” default value and the IV_WAIT parameter with the SPACE default value because generally, you will want to repeat unsuccessful lock attempts.

You can also use this lock object to delete the dependent tables, because no values are transferred for the NR and TIME parameters, which, together with the ID, create the primary key of the tables involved.

The “2” value of the SCOPE parameter is the default value for updates and causes the lock to be forwarded to the update process.

If locks are not transferred to the update and deleted there, you must remove them. You do this similarly to the way you set locks using gen-erated function modules. The following sample source code shows the sequence of the call:

CALL FUNCTION ‘DEQUEUE_EZVEHICLE’ EXPORTING mode_zvehicle = iv_mode mode_zequipment = iv_mode mode_zowner = iv_mode id = lv_id _scope = iv_scope _synchron = iv_synchron.

The iv_synchron parameter used here means that the lock module might wait until the entry is actually deleted from the lock table. However, this is only useful in a few cases; therefore, you use a method to make this parameter optional when the removal of a lock is being encapsulated, and set SPACE as the default parameter.

Indexes and Buffering

Two techniques for accelerating read database access include buffering and using database indexes. Buffering and using indexes are two mutu-ally exclusive concepts. In one case, you want to keep table contents in main memory; in the other, your objective is to be able to access the database efficiently. Buffering is a difficult topic for which you should refer to SAP-specific literature such as SAP Performance Optimization Guide by Thomas Schneider (SAP PRESS, 2008). However, we have compiled

Removing locks

Accelerating read database access

211_Book.indb 71 8/5/08 10:39:46 AM

72


the most important features you need to be aware of with regard to buffering:

ABAP SQL commands exist that read past the table buffer.EE

Buffered items are held at the level of the application server and must EE

be synchronized with one another. This means it can take some time until a database modification appears on another application server.

Based on experience, buffering is most suitable for small transparent tables that have only a few entries and are not modified very often, for example, Customizing tables or some types of master data.

You can define database indexes in the ABAP Dictionary. Because you need resources to manage these indexes, you should only create them for the relevant access paths. These are often known at design time; oth-erwise you should determine them using runtime analysis (Transaction SE30). For more information, see ABAP • Analysis Tools • Runtime Analysis in the SAP Library.

Disadvantages of Indexes

The time an index saves when reading is lost when writing. Inserting many individual data records is particularly intensive when you have to maintain the indexes each time. When you load data into SAP NetWeaver BI, you therefore delete the indexes before writing and create them again when all data is loaded into the system. Even if you use these strategies in application programming only in the rarest of cases, you should always consider this factor and define database indexes as economically as possible. You should also use bundling techniques, which we discuss in Section 3.3.1, Necessity of Database Access Layers.

These tools and Transaction ST30 (global performance analysis) are used to determine runtime gains on live systems. For example, you can store tables, which are often accessed in parallel, on different disks. However, you can generally only perform these types of optimization for a specific live system.

NULL Values

Transparent tables can contain NULL values. They can be tricky for the uninitiated because at first glance (for example, in Transaction SE16),

Suitability

Determining runtime gains

211_Book.indb 72 8/5/08 10:39:46 AM

73


they are difficult to differentiate from initial values. If you load a data record with NULL values into a working area using SELECT, initial values will also appear in the corresponding fields. You can only access NULL values in the WHERE condition using SELECT if you use IS NULL; the IS INITIAL check or the check for inconsistencies with another value will not work.

Before you learn how to create NULL values, we will explain the seman-tics of these values. A NULL value can represent an unknown value. For example, an object can have a certain characteristic but you do not know it at the moment. NULL values can map non-existing values. A typical situation is where you cannot use an attribute in a specific case.

However, a NULL value can also mean that you do not know whether a value exists. Every employee experiences the standard example of this situation when their company telephone system is being changed and their old number is no longer valid. There is a transition period where the employee may not know whether there is a new number or, if there is a new number, he may not yet know it.

How do you create NULL values? In the ABAP Dictionary, you can spec-ify whether you want every column of a transparent table to be filled with initial values or NULL values. In the second case, NULL values are added when you create a new column or insert entries using a view that does not contain these fields.

There are limited benefits to NULL values for an ABAP programmer because they have no equivalent in ABAP. NULL values are implicitly converted into INITIAL values when loaded into working areas or inter-nal tables so you cannot tell whether there was a NULL value. This is why these values are often used only temporarily after structural modifi-cations in the ABAP Dictionary, when a new column has to be converted by a migration report that must decide between entries that have not yet been processed and entries processed by the initial content.

Archiving

Not many applications delete business data; for auditing and legal rea-sons, deleting data is not supported. Instead, deletion indicators are set for the business objects to be deleted and these objects will be excluded

Semantics

Benefits

211_Book.indb 73 8/5/08 10:39:46 AM

74


from future searches and processing. This increases the volume of data in the database, response times for database queries rise, backups take longer, and sometimes you have to get new hardware for the database server. The best way to prevent this is to avoid data and to delete tempo-rary data. If you have exhausted these options, you will have to archive data. For more information, refer to the example given in the SAP Library under CA-ARC Archiving.

SAP provides an API for archiving functions with the Archive Development Kit (ADK). You can define archiving objects for an application object. You create write, read, and delete programs for these archiving objects, which write the data to be archived into an archive file, evaluate this data in a second process, and then delete it from the database. Archive indexes are created in the process. These are transparent tables that contain the object key of the objects to be archived, a reference to the archive file, and the item in the file, from which the object can be read. For the sake of com-pleteness, we must mention that XML archiving is also possible. In this case, you create an XML document for each document to be archived and save it in a file. The scale of the data to be archived increases because of the XML markup. You can use methods of the standard SAP system to search in the archive index and look for corresponding data in a view similar to the Data Browser, that is, perform a direct access. It is unusual to restore data to the live system after it has been archived.

How to handle archiving in detail is beyond the scope of this book; therefore, we will only refer to the factors that can affect the data mod-eling of the application:

Archiving criteriaEE Are there simple criteria you can use to decide when you want an application object to be archived? You must ensure that there are no references of active application objects to archived objects. This could cause the program to behave incorrectly.

Archive searchEE What criteria should you use to be able to search for database enti-ties in the archive? Should the most important attributes be displayed in the archive index to ensure that direct access to the object you are looking for is not necessary? Assuming that direct access is required, are the methods of the Archive Information System (Transaction SARI)

Archive Development Kit

211_Book.indb 74 8/5/08 10:39:46 AM

75

Implementing Object Persistence 3.3

in the standard SAP system sufficient, or do the separate dialogs have to be archive-enabled?

Modifications to the data modelEE Should you expect modifications to the data model? Can you make these modifications in such a way that you do not have to modify the archiving programs? Will you need to modify archived data?

Implementing Object Persistence3.3

In the previous sections, you have seen how you can model application objects at the database level. Some developers question why additional development work is required. Is it not enough to access the database using Open SQL and manipulate individual table entries? Do additional wrappers not mean increased development effort, reduce performance and make programs more complicated? These arguments may apply in individual cases but generally turn out to be hazardous design errors. Specifically, the problem is that, in most cases, you can no longer reverse the conversion of Open SQL calls scattered in the application. This argu-ment applies in particular when other applications access the database tables without access layers.

In the following sections, we will first explain the need to encapsulate access to the application object. You will then implement an access layer for the modeled application object using Object Services. Finally, we will discuss when it makes sense to implement your own persistence mechanisms.

You need the following services to be able to use persistence mechanisms easily and efficiently:

Management serviceEE You must ensure that several, possibly contradictory, runtime objects do not exist in the same internal session. This type of management ser-vice should also contain a cache to enable you to access the managed objects more quickly.

Search serviceEE A management service should also have a Search service that enables you to search for objects based on specialized criteria and load them

Design errors

Management service and search service

211_Book.indb 75 8/5/08 10:39:46 AM

76


into main memory. A search should also be able to return only a con-stant number of objects to enable you to work in packages if you have large sets of objects.

Necessity of Database Access Layers3.3.1

Database access layers are an old and established concept. They were previously implemented by BAPI interfaces, which you still require if you want data to be read by Remote Function Call (RFC) or Web services, or to be manipulated. However, there are also much simpler reasons for implementing database access layers:

Transaction mechanismsEE One important reason is the transaction mechanism itself. If you only work with Open SQL access without using update techniques, this means that the data is irreversibly saved to the database each time an implicit commit is performed. Where dialog applications are con-cerned, you are therefore not in command of transaction control and cannot guarantee data consistency. This also applies in batch pro-grams. In a batch program, you cannot execute any more RFCs for accessing data in external systems or for the internal parallelization of the processing, because these implicitly perform a database commit.2 This also makes it more difficult to enhance the programs. An implicit commit must not be performed in any enhancement by a BAdI imple-mentation. To avoid these unwanted consequences, you would have to buffer the database modifications and persist them at the end of the LUW, which already very closely reflects a database access layer.

Subsequent processes EE Another problem with explicit database access is caused by the fact that you cannot implement any new subsequent processes for data modifications for the application system. If we assume that, for rea-sons of revision security, you want to write change documents for certain fields, replicate these changes by Application Link Enabling (ALE), or provide the delta queue when connecting to SAP NetWeaver

2 The same problem can occur when you debug, because database commits are also performed there. If you save data to the database without updates, the debugging of the application is risky because inconsistencies may occur.

Object-oriented access layers

211_Book.indb 76 8/5/08 10:39:46 AM

77


BI, you must add these functions to all of the points in programs that conduct database updates. You must not include subsequent processes in the area of data replication. Loose event linkages (for example, for starting workflows) are also possible. These are presented in Section 5.5.3, Event-Based Interfaces, under the keyword Publish & Subscribe interfaces. In practice, you will no longer be able to perform a subse-quent implementation into a live application, unless you perform a complete redesign.

RobustnessEE Implementing a database access layer can also make an application more robust. For professional reasons, you are often not allowed to write any values into a table, but rather the programs must require minimum data plausibility in order to work. A typical example is a situation where certain fields are not allowed to contain any initial values; filling these fields with the wrong values equates to an error situation. You cannot assume that everyone who fills the database tables is fully aware of these conditions. Therefore, it is absolutely essential that you explicitly encode these conditions in one location and check them before the INSERT.

ModularizationEE Hiding details about the data model is another important reason for creating an access layer. Developers often want to have the freedom to modify and optimize a data model in the future if performance problems were discovered in mass tests. If this means that you have to adjust SQL calls at every location where a database is accessed, you will find it very difficult to modify the data model because the appli-cation system is not sufficiently modularized.

Checking authorizationsEE You may require specific authorizations to read sensitive data. For example, if a VIP indicator is set for customer-related master data, only users with special authorizations can have full access to this data. In such a case, data access modules must perform certain autho-rization checks and may not necessarily offer all data. You cannot currently avoid bypassing the programming of data access modules. However, by defining package interfaces, you can find out through the Code Inspector whether interfaces were bypassed in the program-

211_Book.indb 77 8/5/08 10:39:46 AM

78


ming (see Chapter 5, Application Architecture). In Release 7.0 you can use dynamic SELECT statements or generated programs to avoid defined database access functions in package interfaces and access tables directly. You can use the Code Inspector to check the use of these potentially “dangerous” commands.

Alternatively, you have situations where you do not want to use a data-base access layer:

You want to create a report for a user department that will determine EE

entries according to specified criteria in one or more tables and out-put them in an ALV grid.

EE As part of a migration you want to load a dataset into the SAP system in as short a time as possible.

In some tables, you have to modify certain data records and fill addi-EE

tional attributes. You can do this using an XPRA program when mak-ing an ABAP Dictionary modification to a table structure.

Within data archiving, you have to write large quantities of data into EE

an archive file within a short time frame, and then delete this data in the database and create search indexes.

Even if the examples indicate that you often work directly with Open SQL tools in the database in mass process, you should not make this procedure the norm. There is also no reason to impose severe restric-tions at the development phase of an application system already, simply because implementing a database access layer requires conceptual and implementation effort.

You can drastically reduce the implementation effort by using Object Services. Strangely, object-oriented access layers have a bad reputation that is entirely unfounded. This poor reputation is based on the fear that an object could be too finely detailed, resulting in lots of individual database operations in mass processes, drastically affecting performance. However, there are solutions to this problem in the form of bundling techniques.

The standard SAP system‘s Object Services use bundling techniques using generic update tasks. The data to be modified is collected and transferred as a binary-formatted table to an update module that accesses

Migration

Are there reasons against Object

Services?

Bundling techniques

211_Book.indb 78 8/5/08 10:39:46 AM

79


the database dynamically. This procedure shows that you can perform mass modifications through a framework and completely hide it from the user.

If you use your own persistence mechanisms, you can save the modi-fications to be updated in an ABAP class or in the global memory of a function group and then execute the PERFORM … ON COMMIT command to implement them as mass inserts into a form routine of a function group. In this case, we specifically recommend that you use the non object-oriented PERFORM … ON COMMIT construction and not the modern variant by creating an on_commit method as the event handler for the TRANSACTION_FINISHED event of the CL_SYSTEM_TRANSACTION_STATE class using the SET HANDLER on_commit command. The reason for this is the following: Experience has shown that you cannot guarantee with cer-tainty that updates started in the event handler are also executed in the same SAP transaction.

One problem with object-oriented access layers can be that the instanc-ing of an object requires an overhead, which in some cases cannot be justified. This is the case, for example, if the user is searching for objects based on certain criteria and a number of attributes are displayed for this in an ALV grid. After the user selects an individual object, this is specifically loaded and shown in a display dialog. Another application scenario where instancing is not required is packaging as part of parallel processing. You want to determine packages of objects but do not need any time-consuming instancing to do this. A search service, that is, a class that can provide primary keys of object instances without instancing objects, can be useful in both of these application scenarios.

A search service can only consist of a static method of an application object that queries the database using direct SELECT statements. However, there are also application systems where you have to implement very complex search criteria that are required for controlling automatic pro-cesses. In the most complex case, these types of search services include objects that were instanced but whose status differs from the status in the database. You can even implement these techniques across sessions using shared objects, although the effort required to implement this type of object is usually too great. For more information about shared objects, refer to ABAP – Shared Objects in the SAP Library.

Complex search criteria

211_Book.indb 79 8/5/08 10:39:46 AM

80


Object Search Services

Based on experience, search services are the basis of numerous application scenarios in business programming and guarantee high-performance, object-oriented programs. Their implementation will therefore also be the topic in the following chapters.

Object Services3.3.2

In individual software development, either a lot of effort is invested in creating persistence layers, or commercial products are used. These soft-ware products implement mappings of objects to tables, of a database-independent persistence, and of caches and supported transactions. In ABAP development, a uniform persistence mechanism was previously not widely accepted. This was mainly because database updates occur predominantly in update modules and BAPIs that are developed indi-vidually. It was only relatively late in the game that the option of persis-tent ABAP classes was made possible with Object Services and an object-oriented framework made available for transactions. These functions are described in ABAP Objects by Horst Keller and Sascha Krüger, but also in the SAP Library under ABAP Object Services. The aim of the persistence layer is to be able to work with objects without having to worry about persistence. You instance objects and access their attributes using SET and GET methods. You then collect the modifications and write them to the database in separate update modules after the COMMIT WORK. The result of this procedure is that you do not need separate update modules. You can also use Object Services with classic update techniques, but you must take into account that, after a COMMIT WORK, a persistent object is invalidated and has an initial status. This means that accessing the object in an update module will fail if this object was already accessed in the LUW.

What must you keep in mind when using Object Services?

MappingEE The options for mapping the application object to transparent tables are somewhat restricted. For special techniques such as deriving or mapping different classes to a transparent table, refer to the SAP Library.

No uniform persistence mechanism

211_Book.indb 80 8/5/08 10:39:46 AM

81


Query serviceEE A query service using the methods of the IF_OS_CA_PERSISTENCY interface is available, but it always instances the objects found and is therefore not always suitable for mass processes.

Service interfacesEE The user must program different service interfaces such as lock man-agement or creating change documents.

Transaction conceptEE The Object Services were incorporated into the classic transaction concept. There are different transaction modes, including an object-oriented transaction concept that makes a transaction manager avail-able in the form of an API. This lets you implement transparently complex scenarios such as nested transactions, however, there is no coexistence with the classic LUW concept: The COMMIT WORK or ROLL-BACK WORK commands will cause a runtime error. We present the aspects of transaction control in detail in Section 3.4.

Many developers have reservations about Object Services, due primarily to a perception of poor performance. The basic technique was optimized in this case. For example, rather than vast numbers of update modules being executed, the data to be updated is instead bundled and written into a generic update task, to which binary serialized data is transferred. This ensures that mass updates are implemented in a small number of database operations.

An example of using Object Services in the sample application is shown in the text that follows. You create a persistent class called ZCL_VEHICLE in the ABAP Workbench, as shown in Figure 3.9.

You then define the persistence mapping using the Persistence button (or (Ctrl) + (F4)). A dialog box called Add Table/Structure appears, where you enter the name of the ZVEHICLE transparent table you created earlier. Finally, you select all table fields sequentially in the lower Persistence Representation area. Each field then appears automatically in the middle drop-down box, where you can set the visibility. Select protected visibil-ity for all fields, but only private visibility for the modification informa-tion because you want to be able to access the attributes of a class easily

Reservations

Creating persistent classes

211_Book.indb 81 8/5/08 10:39:47 AM

82


through a working area. This, however, is only one service function that you will develop in the following section.

Creating a Persistent ClassFigure3.9

Subsequently, two classes will be generated automatically: The ZCA_VEHICLE class agent and its ZCB_VEHICLE basis class. The class agent is a singleton object and therefore only exists once in an internal session. The actual database access takes place in the basis class agent; as does the object-relational mapping using the MAP_LOAD_FROM_DATABASE_KEY( ), MAP_LOAD_FROM_DATABASE_GUID( ) or MAP_SAVE_TO_DATABASE( ) meth-ods. The basis class agent is derived from the CL_OS_CA_COMMON class; therefore, you can redefi ne methods and also access the logic of a per-sistent class to defi ne your own object-relational mapping, for example. The most important interfaces for the user are IF_OS_FACTORY , IF_OS_CA_PERSISTENCY and IF_OS_CA_INSTANCE .

First, you will implement several requirements in the persistent class that will make it easier to work with the persistent class:

All equipment parts for a vehicle are to be automatically loaded from 1. the database into an internal table when you instance objects. This means that you will be able to display these parts easily and save them using mass inserts when you save the vehicle data.

Implementing requirements

211_Book.indb 82 8/5/08 10:39:47 AM

83


The change information (changed by, date, and time) should be deter-2. mined automatically at the time of the COMMIT WORK.

The second item is easy to implement. You implement the IF_OF_CHECK interface in the ZCL_VEHICLE class and create an implementation of the IS_CONSISTENT( ) method. You execute this checking agent after COM-MIT WORK and before you execute the update task. You normally use this to implement consistency checks for an object and, in the case of an emergency, prevent data from being saved. You use it to set the change information:

METHOD if_os_check~is_consistent. TRY. set_chdate( i_chdate = sy-datum ). set_chtime( i_chtime = sy-uzeit ). set_chuser( i_chuser = sy-uname ). CATCH cx_os_object_not_found .* The object has been deleted. ENDTRY. result = oscon_true.ENDMETHOD.

To ensure the IS_CONSISTENT( ) method is executed, you must register it. You do this by redefining the INIT( ) method of the IF_OS_STATE interface (see Listing 3.2).

METHOD IF_OS_STATE~INIT.********************************************************** Purpose : Initialization of the transient state * partition.* Version : 2.0* Precondition : -* Postcondition : Transient state is initial.* OO Exceptions : -* Implementation : Caution!: Avoid Throwing ACCESS Events.********************************************************** Changelog: 2000-03-07 : (BGR) Initial Version 2.0********************************************************** Modify if you like*********************************************************DATA: lr_tm type REF TO if_os_transaction_manager, lr_t type REF TO if_os_transaction.

Using the checking agent

211_Book.indb 83 8/5/08 10:39:47 AM

84


lr_tm = cl_os_system=>get_transaction_manager( ) . lr_t = lr_tm->get_current_transaction( ). lr_t->register_check_agent( me ).ENDMETHOD.

Registering the Checking AgentListing3.2

You can also use the initialization routine to load the equipment parts of a vehicle into a transient attribute that is not managed by the persistence service. Transient attributes are calculated at runtime and can be used to save data of dependent objects (see Section 3.3.4, Accessing Dependent Tables).

The source code from Listing 3.3 shows an example of how you create, modify, and delete a vehicle object in a transaction.

DATA: lr_vehicle_agent TYPE REF TO zca_vehicle, lr_vehicle TYPE REF TO zcl_vehicle, lv_vehicle_id TYPE z_vehicle_id.

lr_vehicle_agent = zca_vehicle =>agent.CALL FUNCTION ‘GUID_CREATE’ IMPORTING ev_guid_22 = lv_vehicle_id.TRY. lr_vehicle = lv_vehicle_agent->create_persistent( i_id = lv_vehicle_id ). TRY. lr_vehicle->set_seats( i_seats = ‘2’ ). CATCH cx_os_object_not_found.* Perform exception handling. ENDTRY. lr_vehicle_agent->delete_persistent( lv_vehicle_id ). CATCH CX_OS_OBJECT_NOT_EXISTING .* Perform exception handling.ENDTRY.COMMIT WORK.

Using Object Services Listing3.3

At the end of the transaction, the modifications are collected and writ-ten to the database by an Object Services update task. You can work

Transient attributes

211_Book.indb 84 8/5/08 10:39:47 AM

85


with the object in this way, without having to worry about persistence factors. (Using Object Services in the update would also generally cause an exception.) In the example, you used Object Services in the classic transaction mode instead of using the object-oriented transaction service of the IF_OS_TRANSACTION interface. You can execute the Object Services within classic LUWs. In contrast, the END( ) method of the Object Ser-vices that completes an LUW implicitly calls a COMMIT WORK so that classic updates can also be performed in an object-oriented transaction. These aspects are discussed in Section 3.4.

Deleting Persistent Objects

When you delete persistent objects, note that deleting an object that does not exist or no longer exists does not trigger an exception, but instead only causes an update module to terminate.

Inheriting Persistent Classes3.3.3

You use inheritance when there is a specialization relationship between a class and a number of subclasses. However, you should only use inheri-tance sparingly at the application object level, because there is a risk that you may link two business entities too closely together. If, in hindsight, your decision turns out to be incorrect, the cost of changing the program and database model of the database will in most cases be far greater than the benefits gained through reuse.

Nevertheless, inheritance is a powerful tool:

PolymorphyEE You can derive persistent classes and keep the mapping to achieve polymorphic behavior, for example, redefining methods: In the appli-cation sample presented here, you can avoid there being instances of coaches with standing room, define special checks, or implement display transactions.

Enhancing using additional attributesEE If you have to include additional attributes in a derived class that do not have meaningful semantics in the basis class, you can create them in an additional transparent table. This prevents transparent tables

Use it sparingly

211_Book.indb 85 8/5/08 10:39:47 AM

495

Index

A

ABAPClass, 213Dictionary, 61, 104, 142, 150, 183, 187Keyword documentation, 450Lock concept, 67Objects, 114, 116Unit, 128Workbench, 213

ACIDProperties, 97

Activation error, 152Additional fields, 406Administrability

Customizing contents, 29Live system, 28

AdministrationEnvironment, 29Tool, 175

AdministratorCockpit, 29Specialist, 28

Aesthetics, 135Agile method, 25, 54ALV grid, 229, 276, 283Analysis

Object-oriented, 52Application

Administrator, 394Architecture, 135Layer, 187Log, 401Logic, 188Object, 19, 51, 52, 53, 55, 56, 104, 190, 195, 196Object, example, 53Programming, 391

Application dataCheck, 44Merge, 33

Application Link Enabling (ALE), 76, 189Application Programming interface (API), 396Architecture, 179

Documentation, 179Model-driven (MDA), 48

ArchiveMigration, 194Search, 54, 74

Archive Development Kit (ADK), 74, 166, 417Archive information system, 74ArchiveLink, 192, 193Archiving, 73, 414

Criteria, 74Area menu, 29, 258, 259, 260AS ABAP, 17, 451ASSERT, 120Assertion, 120, 121Association, 55Attribute, 51

Public, 92Transient, 84, 89Virtual, 56

Authorization, 77Check, 77, 189Concept, 190Object, 189

B

BackgroundJob, 437, 445Processing, 132Work process, 436

BANK_PP_JOBCTRL, 439Basic

Class, 165Component, 146Function, 146

Basis component, 198

211_Book.indb 495 8/5/08 10:41:35 AM

496

Index

Batch program, 131Blog, 449, 461BOR object, 192, 213BPX, 448Breakpoint, 121Bundling technique, 72, 78Business Add-In (BAdI), 126, 167, 168, 169, 170, 181, 183Business Application Log (BAL), 33, 117, 130, 392, 396, 407

BAL_DB_DELETE, 415BAL_DB_LOAD, 397BAL_DB_SAVE, 397BAL_DSP_LOG_DISPLAY, 396, 397, 413BAL_DSP_PROFILE_SINGLE_LOG_GET, 405BAL_LOG_CREATE, 413Detailed information, 407Interactive functions, 394Log display, 395Log object, 396Log research, 394Log sub-object, 396

Business Application Programming Interface (BAPI), 45, 94, 142, 189, 454Business Data Toolset (BDT), 45, 93, 261, 333

Application object, 333Application owning the table, 333Applications, 338BUPA application object, 337Current memory, 348Data sets, 339Direct input, 46Event, 350, 351, 352Field group, 340Field grouping, 45Global memory, 348Naming conventions, 363Participating application, 334Regenerate subscreen containers, 366Screens, 343Screen sequence, 345Section, 343Tables, 339Views, 341

Business object, 55, 59, 192Delegation, 126

Business Object Builder, 126, 192Business partner, 19, 331

Role, 332, 366Business process, 51Business Process Expert (BPX), 448

Community, 448Business Server Pages (BSP), 229, 327Business Workplace, 230BUS Screen Framework, 261, 264, 265, 267, 300, 388Button, 314

User-defined, 416

C

Calculation method, 219Callback, 396, 415

Interface, 167Method, 428Routine, 410, 411, 427Routine, specify, 411

CALL DIALOG, 427CALL SCREEN, 268, 427CALL SUBSCREEN, 285CALL TRANSACTION, 427CALL TRANSFORMATION, 48, 108Cascading Stylesheets (CSS), 328Change document, 105, 106Check

Class, 474Enabling, 481Function, 27Mode, 152Report, 259

Checking agent, 83, 90Checkpoint group, 120, 121Class, 51, 113, 137

Abstract, 115Agent, 104CL_ABAP_EXPIMP_DB, 414CL_ABAP_OBJECTDESCR, 203CL_ABAP_ZIP, 109CL_APL_ECATT_TDC_API, 482CL_AUNIT_ASSERT, 128

211_Book.indb 496 8/5/08 10:41:35 AM

497

Index

CL_BATCH_EVENT, 131CL_BUS_ABSTRACT_MAIN_SCREEN, 267CL_BUS_ABSTRACT_SCREEN, 270, 301CL_BUS_ABSTRACT_SUB_SCREEN, 285, 303CL_BUS_LOCATOR_SEARCH, 382CL_BUS_LOCATOR_SEARCH_SCREEN, 382CL_BUS_MESSAGE, 277, 279CL_BUS_TAB, 287CL_BUS_TABSTRIP, 287, 293CL_BUS_TABSTRIP_TAB, 293CL_OS_CA_COMMON, 82CL_OS_SYSTEM, 101CL_SFW_EVT_EVENT, 173CL_SYSTEM_TRANSACTION_STATE, 79Diagram, 162Final, 115Model, 54Persistent, 81, 82, 85, 87, 88

Coaching, 460, 466Code inspection, 470

Automatic, 471Code Inspector, 128, 156, 470, 471, 480

Enhancement, 472Message suppressing, 480

Cohesion, 114, 194COMMIT WORK, 67, 80, 81, 85, 94, 98, 101, 107, 131, 401, 402, 427COMMUNICATION RECEIVE, 427Compatibility problem, 157, 159Component, 307

To be embedded, 325Componentization, 309Constant, 115, 200, 203

Evaluation, 201Constructor

Abstract, 127Container operation, 217, 218Control

Flow, 119Loop, 427Parameter, 197Program, 124

Cross-sectional function, 168CRUD interface, 191Customer enhancement, 168Customizing, 26, 29, 34, 129, 163, 166, 196, 197, 259, 443

Access layers, 198Check function, 27Customer, 197Developer, 197Initial, 197Table, 165Technical, 198

D

DataArchiving, 74Cluster, 108, 413, 414Complex, 412Exchange process, 37Model, 54, 56, 58, 59Model, modifications, 75Modeling, 61Origin, 45Quality, 110, 111Semi-structured, 107Tabular format, 326Unstructured, 107

Data areaRetractable, 237

DatabaseAccess layer, 76Buffering, 71Index, 71, 72Level, 56Persistence, 54Trace, 457

Data Modeler, 56, 57, 192, 453, 484Deadlock, 68Debugger, 451, 452

Layer debugging, 452Update debugging, 367

Decorator pattern, 191Default interface, 156

Virtual, 156Deliverability, 31

211_Book.indb 497 8/5/08 10:41:35 AM

498

Index

Denormalization, 60, 61, 93Forms, 60

DependencyCyclical, 143

Derivation, 51Deserialization, 125Design

Application system, 23Object-oriented, 54

Design pattern, 191Developer

Requirements, 43Development

Class, 138Coordination, 43Environment, 137Guideline, 469Test-driven, 128

DialogModal, 267Standard, 230Work processes, 436

Dialog text, 410Maintenance, 408

Direct access, 74Dirty read, 67Dispute case, 40DOCTYPE switch, 328Documentation, 138, 480, 483, 484

Mandatory components, 484Document maintenance, 408Domain-Specific Language (DSL), 46DTD validation, 109Duplicate, 188

E

Easy Access Menu, 453EDI procedure, 40Editor

Graphical, 408Text-based, 408

Encapsulation, 168, 185, 263Enhancement, 167

Spot, 168Enqueue module, 69

Enqueue server, 67Entity relationship

Diagram Model, structured, 57Entity type, 58Environment analysis, 458Environment information, 403, 404Ergonomics, 230, 231, 232Error

Potential, 179Process, 194Situation, 116System error, 117Temporary, 117, 174, 178Type, 178Unexpected, 178

Error messagesCollecting, issuing, 277

Evaluation report, 259Event, 116, 170, 226, 314

Block, 306Handler, 276, 277Linkage, 171, 172, 173, 226Linkage, asynchronous, 213Trace, 175, 176Type linkage, 226

Event queue, 175, 226Browser, 176, 177

Exception, 113, 116, 117, 121, 177, 426Checked, 118Classic, 117Design, 121Dynamically checked, 119Handling, 173Hierarchy, 122Interface, 116Linked, 122Object-oriented, 118Unchecked, 119

Exception class, 118CX_BO_ERROR, 174CX_BO_TEMPORARY, 174CX_DYNAMIC_CHECK, 119CX_NO_CHECK, 119CX_STATIC_CHECK, 118CX_SWF_EVT_INVALID_EVENT, 173CX_SWF_EVT_INVALID_OBJTYPE, 173

211_Book.indb 498 8/5/08 10:41:35 AM

499

Index

CX_SY_NO_HANDLER, 119PREVIOUS parameter, 122

EXIT FROM STEP-LOOP, 427EXPORT, 414EXPORT TO DATA BUFFER, 108extended Computer Aided Test Tool (eCATT), 482Extending

Check variant, 473Extensibility, 26Extension

Modification-free, 93External key, 65Extract Transform Load (ETL), 33

F

Field grouping, 45Field modification, 340Fixture method, 128Flexibility, 26Flow logic, 269Forum, 449Framework, 40, 43, 133Function code, 274, 275Function group, 115Function module, 130, 166, 206, 442

BAL_DB_SAVE, 402BAL_DSP_LOG_DISPLAY, 415BAL_DSP_PROFILE_DETLEVEL_GET, 406BAL_DSP_PROFILE_NO_TREE_GET, 406BAL_DSP_PROFILE_POPUP_GET, 406BAL_DSP_PROFILE_STANDARD_GET, 406BAL_LOG_CREATE, 396BAL_LOG_MSG_ADD, 396BAPI_TRANSACTION_COMMIT, 99BAPI_TRANSACTION_ROLLBACK, 94, 99BP_CALCULATE_NEXT_JOB_STARTS, 438BP_JOBVARIANT_OVERVIEW, 131, 437

BP_JOBVARIANT_SCHEDULE, 131, 437BP_START_DATE_EDITOR, 438BUPA_DIALOG_SEARCH, 383BUP_BUPA_BUT000_GET, 353BUS_MESSAGE_STORE, 353BUS_PARAMETERS_ISSTA_GET, 353BUS_SEARCH_GENERATOR_MAIN, 47Call, 425DB_COMMIT, 96DISPLAY_XML_STRING, 109FIMA_DECIMAL_MONTHS_AND_YEARS, 157FLUSH_ENQUEUE, 69FREE_SELECTIONS_DIALOG, 206GET_PRINT_PARAMETERS, 437GUID_CREATE, 65JOB_OPEN, 437JOB_SUBMIT, 438NUMBER_CHECK, 64NUMBER_GET_NEXT, 62OWN_LOGICAL_SYSTEM_GET, 33SAP_WAPI_START_WORKFLOW, 226SPBT_DO_NOT_USE_SERVER, 426SPBT_GET_PP_DESTINATION, 426SPBT_INITIALIZE, 425TR_OBJECTS_CHECK, 258TR_OBJECTS_INSERT, 102, 258TR_SYS_PARAMS, 36VIEWCLUSTER_MAINTENANCE_CALL, 258VIEW_MAINTENANCE_SINGLE_ENTRY, 249

G

GENERATE REPORT, 47GET BADI, 168Global Unique Identifier (GUID), 65, 103, 422Graphical User Interface (GUI)

Interface, 37Programming, 204, 229Status, 266Technology, 46, 327, 328

211_Book.indb 499 8/5/08 10:41:35 AM

500

Index

I

Icon, 235, 409ID, 278Implementation Guide (IMG), 29IMPORT, 414Include, 115

Multiple use, 244Program, 244, 255

Index, 72Information hiding, 114, 119, 150Inheritance, 66, 85, 114, 126

Hierarchy, 87INSERT FOR UPDATE, 67INSERT REPORT, 47Integration test, 482Integrity

Referential, 65Interface, 37, 113, 115, 123, 137, 162, 165, 167, 169

BI_EVENT_HANDLER_STATIC, 171, 172, 174, 191BI_OBJECT, 213, 215BI_PERSISTENT, 214, 215Design, 182Event-based, 170, 192External, 142IFARCH21, 192IF_BADI_INTERFACE, 169IF_OF_CHECK, 83IF_OS_CA_INSTANCE, 82IF_OS_CA_PERSISTENCY, 81, 82, 87, 92IF_OS_CHECK, 90, 91, 107IF_OS_FACTORY, 82IF_OS_STATE, 83, 89IF_OS_TRANSACTION, 85, 100IF_SERIALIZABLE_OBJECT, 203IF_WORKFLOW, 172, 213Public, 138Publish & Subscribe, 170Status, 233Type, 156Violation, 152

iXML Library (XML Library), 108

J

Job scheduling, 437

L

Layer, 144Debugging, 452Model, 39, 144, 181

ListInteractive, 131

Load distribution, 438Locator, 233Locator Framework, 267Lock, 67, 68

Management, 105Module, 70Object, 68, 69, 178Object, create, 68Remove, 71

Lock conceptExclusive but not cumulative lock, 69Exclusive lock, 69Optimistic lock, 69Shared locks, 69

Log, 391, 393Archive, 417Create and display, 397Default profile templates, 406Delete, 417Display, 406Enrich, 403Handle, 396Header, 412Object, 396Persistent, 391Recipient, 393Research, 392, 393Save, 399, 400Sub-object, 396

Logging, 403Logical Unit of Work (LUW), 62, 81, 95, 96, 131LOGPOINT, 215

211_Book.indb 500 8/5/08 10:41:35 AM

501

Index

M

Main package, 141, 147, 149, 150Main screen, 267Maintainability, 139Maintenance

Dialog, 241View, 239, 241, 250, 253, 258

Management service, 75Mapping, 80Mass data

Ability to process, 93Capability, 27

Master data tables, 197Memory

Bound, 483Lack, 483Referenced, 483

Memory Inspector, 213, 482Menu Painter, 233Menu standard, 233Message

Class, 95Handling, 263

MESSAGE, 427Metadata, 44Method, 51

Asynchronous, 221Migration, 73, 78, 102, 142, 143Mini SAP system, 444Mock object, 130Model View Controller (MVC), 308MODIFY FOR UPDATE, 67Modularization, 26, 77, 114

Unit, 130Module

Memory, 115Test, 128

Monitoring, 423Tool, 175

Multitenancy, 27, 198

N

Namespace, 149, 159, 160

Naming conflict, 160Naming convention, 159, 160, 469, 470Normalization, 59, 60NULL value, 72, 73Number assignment

External, 62Number range, 44, 61

Buffering, 62External interval, 64Fiscal year, 64Groups, 64Interval, 63, 336Interval, create, 64Interval, disjunctive, 103Interval, statuses, 62Management, 44Object, 61, 63Object, create, 63

O

ObjectIdentity, 51Lifecycle, 193Management, 141Model, 54Orientation, 51, 122, 166Persistence, 75, 141Persistent, 85, 104, 190Selection, 233Service, 192

Object search service, 35Object Services, 78, 80, 101

Checking agent, 83Class agent, 82, 87, 91, 92, 93Inheritance types, 86Mapping, 80, 104Object initialization, 89Query service, 87, 88, 92Transaction concept, 100Transaction service, 100Transient attributes, 84Type identifier, 86

OK field, 274OO event, 275

211_Book.indb 501 8/5/08 10:41:35 AM

502

Index

Open-closed principle, 124, 127Open source project, 461Organizational management, 210

P

Package, 143, 147, 149, 150, 161, 181, 183

Concept, 135, 138, 140, 148, 485Cyclical dependency, 143Cyclical usage, 181Declarative, 146Hierarchy, 150Interface, 453Main package, 149Name, 149Splitting, 180Strong encapsulation, 185Structure, 138, 142, 147Structure package, 149

Package Builder, 151Package check, 153, 183

Client, 152R3ENTERPRISE check mode, 156, 157RESTRICTED check mode, 152, 157, 184Server, 152, 184

Package interface, 149, 150, 151Extending visibility, 153Visibility, 153, 154

Packaging, 420, 422Criteria, 423

Parallelizability, 419, 420Parallelization, 391, 417, 439

Background jobs, 437Parallel processing, 132, 444

Framework, 445Performance optimization, 28, 419PERFORM ON COMMIT, 79, 99, 107Persistence

Layer, 93Mapping, 86Mechanism, 80, 88Service, 93

Plug-in, 125

Polymorphism, 163Polymorphy, 85, 87, 104, 114Primary key, 61, 69, 102, 103Principle of information hiding, 138, 139, 148, 177Print list, 131Print process, 193Product design, 145Product family, 39Product idea, 23, 136Programming

Generative, 46, 47Object-oriented, 113Principles, 114

Prototyping, 468Pseudo comment, 480Publish & Subscribe interface, 36, 162, 170, 183, 192, 213, 221

Q

Quality management, 467Query service, 81, 92

R

REJECT, 427Release

Change, 468External, 49Planning, 139, 140

Reload operation, 315Remote Function Call (RFC), 76, 94, 95

Asynchronous, 417, 424, 435, 444Server group, 425, 438Server group, development guideline, 470

Renaming development objects, 139Report, 130, 442

BDT_ANALYZER, 366For reuse, 442RS_PACKAGE_TREE, 152, 156RSVIMT_NON_UC_VIM_AREAS, 258SBAL_ARCHIVE, 417

211_Book.indb 502 8/5/08 10:41:36 AM

503

Index

SBAL_ARCHIVE_DELETE, 417Variant, 132

Repository Information System, 458Requirement, 25

Analysis, 24Functional, 25Non-functional, 26Requirements analysis, 24Requirements management, 41

Responsibility, 143, 193Return code, 426Reuse Library, 450Risk management, 467Robustness, 77ROLLBACK WORK, 81, 94, 402, 403, 427Runtime

Analysis, 454, 455Configuration, 162Error, 427

Run Time Type Information (RTTI), 200, 203

S

Safety facade, 117SAP_ABA, 49, 146, 154SAP_BASIS, 49, 146, 154SAP Business Partner, 55, 56, 57, 233, 260, 331, 332

Basic Customizing, 335Business partner relationships, 333Business partner role, 332Business partner views, 345Define Business partner roles, 345Role, 347Role category, 346

SAP Business Workflow, 261SAP Business Workplace, 210, 224SAP Community Day, 449SAP Design Guild, 451SAP Developer Network (SDN), 448

Subscription Program, 450SAP GUI for HTML, 209SAP Help Portal, 447, 448

SAP Library, 447, 448SAPlink, 47, 124, 125SAP Locator, 369

Search applications, 370Search categories, 372Search help hierarchies, 374Search IDs, 372, 386Search screen, 377

SAP LUW, 401, 403SAP NetWeaver Business Intelligence (SAP NetWeaver BI), 41SAP Note, 49, 448, 449SAP R/3 icon, 237SAP R/3 Style Guide, 231SAP Records Management, 108SAP release note, 50, 448SAPscript, 407SAP Service Marketplace, 447SAP software component, 154SAP standard, 137, 147, 159SAP Support Portal, 448SAP Web Flow Engine, 209Saving, 107

Complex data, 412Mode, 403

Scalability, 27, 419Scaling

Linear, 418SCI message, 480Screen, 263

BAdI, 262Call, 271Class, 286, 303, 304, 305Field, 286Layout, 233Logic, 273Painter, 265, 286, 294Programming, 229Programming, classic, 229Programming, object-oriented, 261Structural logic, 264

Script engine, 453Search criteria

Complex, 79Returning, 208

Search function, 164

211_Book.indb 503 8/5/08 10:41:36 AM

504

Index

Search help, 199, 234Elementary, 199, 374

Search service, 35, 75, 79, 80, 93, 161, 162, 163, 164, 165, 191, 204, 206SELECT FOR UPDATE, 67Selection

Criterion, 294Dynamic, 204Screen, 294, 295, 296, 299, 300, 301

SELECT-OPTIONS, 294Separating responsibilities, 41Serialization, 125Service, 168Service class, 194, 195, 196SET HANDLER, 277SET PF-STATUS, 300SET UPDATE TASK LOCAL, 94, 99Shared

Buffer, 414Memory, 414Object, 79

Simple transformation, 108, 110Single-step task, 190, 220Software

Architecture, 180Quality, 467Structuring, 135, 137, 145Technology, 136, 137Test, 482

Software component, 154, 162BBPCRM, 146, 158SAP_HR, 146

Sorting, 406Specification, 25, 37, 38SQL trace, 458Standard SAP system, 49Start report, 442STOP, 427Structured Entity Relationship diagram (SERM), 57Structure package, 149, 154, 155

Check, 156Style guide, 451Sub-application, 145SUBMIT, 427Subscreen, 261, 262, 264, 267, 285, 286, 289, 296, 298

Area, 283Class, 286

Subsequent process, 76Subset, 252, 253Substitution principle, 126, 127Supply function, 326System error, 117, 174, 178

Neutralization, 177System specification, 37System test

Automatic, 34

T

T100 message, 95Table

Control, 283, 369Dependent, 88

Table maintenance, 239, 241, 242, 243, 249

Dialog, 238, 239, 240, 249Table view element, 326Tabstrip, 235, 236, 287, 289, 324Tag interface, 169, 203Test

Class, 129Customizing, 129Method, 128

Top include, 115Transaction

Control, 98, 102Mechanisms, 76Security, 97

Transaction concept, 95, 401Classic, 98Object-oriented, 99

Transport system, 241, 258Type identifier, 86

U

UMLComponent diagram, 142

Unique constraint, 61

211_Book.indb 504 8/5/08 10:41:36 AM

505

Index

Unit test, 127Universal worklist, 210Update, 98

Module, 92Task, 402

UPDATE FOR UPDATE, 67Usage

Cyclical, 143, 181Use access, 149, 155User guide, 233User interface, 230

Graphical, 229Utility class

Global, 104

V

Verification, 35, 36View

Context, 326Embedding, 321

View cluster, 238, 249, 250, 251, 254, 255, 256, 258

Call, 257Event maintenance, 254Functions, 255

W

WAIT UNTIL, 427WAIT UP TO, 427Web Dynpro, 229, 306

Application, 310Code Wizard, 307, 315Component controller, 311Component-interface, 311Dynamic programming, 317Explorer, 311Interface view, 311Naming convention, 470Programming model, 308Window, 311

Web Dynpro ABAP, 48Framework, 48

Web service, 45, 141, 189Wf-XML, 210WHERE condition, 208Where-used list, 173, 399, 451Wiki, 461Workflow, 33, 37, 87, 103, 126, 142, 189, 193, 209, 212, 213

Asynchronous methods, 221Container, 216, 217Container operation, 217Customizing, 34Event, 170, 173, 174Event linkage, 175General task, 216Log, 225Multistep task, 222Receiver type, 171Resubmission, 211Single-step task, 190, 210, 220Start date, 220Substitute rules, 210Techniques, object-oriented, 213Template, 216Terminated events, single-step task, 222Test, 223, 224Work item preview, 210

Workflow Builder, 218, 222Working area, 105Work item, 224Wrapper, 191

X

XML, 107, 125Archiving, 74Clobbing, 108Library, 108Shredding, 109

XSL Transformation, 48

Z

ZIP compression, 109

211_Book.indb 505 8/5/08 10:41:36 AM

sappress abap objects application

Documents