mySAP.com Technologies:

mySAP CRM not only enables companies to generating and maintaining customer loyalty but it also enables you to optimize your customer relationships as a whole and throughout the life cycle - from customer acquisition through sales processes and order fulfillment to customer service.

mySAP E-procurement supports B2B procurement of both production materials and indirect materials.

mySAP BI components:1. SAP Business Information Warehouse (SAP BW)2. SAP Strategic Enterprise Management (SAP SEM)

One of the central modules of mySAP SCM is the Advanced Planner & Optimizer (APO) APO includes:

1. Supply Chain Cockpit2. Demand Planning3. Supply Network Planning and Deployment4. Production Planning and Detailed Scheduling 5. Global Available-to-promise

There are basically two ways of accessing an SAP component in dialog mode from the Internet1. Using SAP Internet Transaction Server (SAP ITS)2. Using the Internet Communication Manager (ICM) of the SAP Web Application Server

(SAP Web AS) The SAP ITS provides the following options:

1. Automatic conversion of SAP screens into HTML format2. Use of screen-based IACs (Internet Application Components) that have been delivered

with the R/3 System for years.3. Use of the SAP GUI for HTML, a 1:1 conversion of SAP screens into HTML.

The ICM enables you to process directly queries that were placed from the Internet/Intranet via a browser.

The Web browser and ICM communicates using Business Server Pages; these are HTML pages that also contain ABAP coding.

SAP GUI for HTML cannot currently be used with the ICM. SAP supports the TCP/IP and SNA LU6.2 (System Network Architecture; Logical Unit 6.2)

protocols. LU6.2 was developed by IBM and is used to communicate with mainframe-based R/2 Systems. R/3 application programming supports CPI-C (Common Programming Interface Communication),

RFC and OLE as communication interfaces. Other interfaces are based on technologies such as BAPIs (Business Application Programming

Interface), ALE (Application Link Enabling) and EDI (Electronic Data Interchange). ALE is the business-controlled message exchange

1. Through synchronous and asynchronous communication.2. Using BAPI interfaces and IDoc data containers 3. Using consistent data4. Across loosely linked SAP applications.

RFC is based on CPI-C. RFC is the protocol for calling special subroutines over the network. These subroutines are labeled

function modules. There are three types of RFC calls

1. Synchronous RFC call: Calling program waits until the called program gives response to the calling program.

2. Asynchronous RFC call: Calling program does not wait.3. Transactional RFC call: Several function modules can be grouped into one transaction.

They are processed in the destination system within an LUW once only, and in the sequence in which they were called.

SAP Service Marketplace under http://service.sap.com is aimed at SAP customers and partners. At SAP Service Marketplace you can get information regarding

1. Service requirements2. Corrections

3. Problem messages4. Current Output/ messages?5. Notes database (Patches)6. Training course information7. SAP software change registration

You must be registered as a user to use the SAP Service Marketplace. SAP provides a program for starting the SAP GUI that is SAP Logon. When you call up the SAP Logon, it displays a list of SAP systems whose logon process can be

started. This list is derived from a file on the front-end computer: saplogon.ini. SAP systems are client systems. The BW and KW components use one client only. Each user session only accesses data on the client that you selected when you logged on. A client is a self-contained organizational unit in the system. Each client has its own data environment and therefore, its own user master and transaction data. Multiple logons are recorded. If the same user logs on more than once, then the system displays a warning message for each

subsequent logon. The SAP Easy Access screen is the standard way to access the system. Screen Elements.

1. Command field2. Menu bar3. Standard toolbar4. Application toolbar5. Title bar6. Checkboxes7. Radio buttons8. Tab9. Status bar

Role describes a number of activities in the system that it makes sense to define. Roles/ activity groups must be set up using the Profile Generator so that SAP system users can

work with user-specific or work station-related menus. When users are assigned roles, they can choose between the standard SAP menu and their user

menus. “/n” ends the current transaction “/i” deletes the current session “/oSM04” opens a new session and branches to the specified transaction (SM04). System menu option contains:

1. Create/end session: System administrators can use parameter rdisp/max_alt_modes to set the maximum number of sessions to a number between 2 and 6.

2. User profile: contains user-specific settings. Choose Own Data to use parameter IDs that fill specific fields in the system with default values.

3. List: important list functions, such as searching by character string, saving to PC files, printing and so on.

4. Status: displays the most important user and system data. You can set personal standard values by choosing System User Profile Own Data.

Client-specific customizing settings are client specific and applicable to that client only. In addition to client-specific customizing settings, there are other settings that are set once and are

active for all clients. These settings include printer settings. The Repository is also client-independent (Cross-Client). It contains all ABAP Dictionary objects

as well as all ABAP programs, menus, screens, and so on. It is advisable to have three clients while implementing SAP viz., Development Client, Testing

Client and Production Client. Customers add their enhancements using Customer Exits. Modifications change SAP objects. Any object name starting with ‘Y’ or ‘Z’ is stored in the customer’s namespace. Data entered by the user is sent through the user interface (the SAP GUI) to the dispatcher, which

coordinates further processing. The dispatcher is the central process of the application server. The dispatcher manages in association with the operating system, the resources for the applications

written in ABAP.

Main tasks of dispatcher:1. Distributing transaction load to the work processes2. Connecting to the presentation level3. Organizing communication

User input is received by the SAP presentation program SAPGUI, converted into its own format and then sent to the dispatcher.

The processing requests are then saved by the dispatcher in request queues and processed according to the FIFO principle.

Data is actually processed in the work process. There is no fixed assignment of work processes to users. During initialization, the dispatcher executes the following.

1. It reads the system profile parameters2. starts work processes3. Logs on to the message server.

SAP GUI Types: 1. Windows 32 bit SAP GUI for Windows2. Java Application SAP GUI for Java3. Browser-Based SAP GUI for HTML

An Internet Transaction Server is used for the SAP GUI for HTML to turn the SAP GUI data flow from the dispatcher into HTML, and conversely.

The primary advantage of the SAP GUI for HTML is the low installation cost for the Front-end; all you need is a browser.

The data, tables, and table relationships are defined in the database catalog (the data dictionary) of the database system.

Within the ABAP programming language, you can use SAP OPEN SQL to access data in the database regardless of your database management system. The mySAP.com database interface converts Open SQL statements from ABAP statements into corresponding database statements.

Native SQL commands can be used directly in ABAP. When interpreting Open SQL statements, the SAP database interface checks the syntax of these

statements and ensures the optimal utilization of the local SAP buffers in the shared memory of the application server.

Data that is frequently required by the applications is stored in these buffers so that the system does not have to access the database to read this data..

What can be buffered?1. Application data (screens, programs, ABAP dictionary info., business administration

parameters)2. Business application data.3. Data that is frequently required by applications.

Types of work processes:Work Process Allowed per mySAP.com System Allowed per dispatcherD – Dialog -- At least twoS – Spool At least one More than one allowedU – Update At least one More than one allowedB – Background At least two More than one allowedE – Enqueue Only one --

The Message Server (MS or M) communicated between the distributed dispatchers within a mySAP.com System.

The Gateway Server (GW or G) allows communication between mySAP.com components such as R/3 and R/2 and external application systems. There is only one gateway process for each dispatcher process.

An instance is an administrative unit that combines mySAP.com system components providing one or more services.

A central mySAP.com System consists of a single instance that provides all of the necessary services.

Each instance has its own SAP buffer areas. The message server provides the application servers with a central message service for internal

communication. The dispatchers for the individual application servers communicate through the message server

that is installed once in each mySAP.com System.

You can use the message server performance database for automatic load distribution. The task handler coordinates activity within a dialog work process. It activities the screen

processor or the ABAP processor and executes the roll-in and roll-out of the user context. The memory management system differentiates between main memory areas that are available

exclusively to a work process and memory areas that can be used by all work processes. The memory space used exclusively by a work process stores session-specific data that must be

kept longer than the duration of a work step.

The parameter rdisp/max_wprun_time (default setting: 300 seconds) sets the maximum time a dialog step is allowed to remain in a dialog work process. If this time is exceeded by more than double, the dialog step is terminated and the started transaction terminates with an error.

Background work processes are used for dialog-free execution of programs. Background processing is scheduled in the form of jobs that are processed sequentially. You can set priorities (from “C” to “A”) so that certain jobs are prioritized. You can trigger a job start at the operating system level using the SAPEVT program. The background scheduler is responsible for automatically triggering the job at the specified time.

(RDISP/BTCTIME, default 60 s). The spool mechanism works the local spool system on each server. The data itself is stored in the TEMporary Sequential TemSe object database. When data is to be printed, an output request is generated for a spool request. This output request

is processed by a spool work process. Once the spool work process has formatted the data for output, it returns the output request to the

operating system spool system. The operating system spooler takes over the queue management and ensures that the required data

is passed on to the output device. mySAP.com System provides its own lock management, controlled by the enqueue work process. In order for the system to execute lock requests, you must first define a lock object in the ABAP

Dictionary. The name of a user-defined lock object must begin with “EY” or “EZ”. The locks (enqueues) are administered by the enqueue work process using the lock table. The lock

table is stored in the main memory of the server where the enqueue work is running. Locks set by an application program are either reset by the application program itself, or using a

special update program. In transaction SM12, the locks held by the update program are colored blue, while the locks held

in the dialog work process are colored black. Using asynchronous update, the dialog part of the transaction and the associated database update

can also be run in different work process types or even on different servers.

Front-end: SAP GUI

DispatcherRequest Queues

Internal Mem

ory

Task Handler

Screen Processor

ABAPProcessor

DatabaseInterface

Internal Mem

oryTask Handler

Screen Processor

ABAPProcessor

DatabaseInterface

…

Roll File

Application Buffer Roll Area

Factory CalendarScreensABAP ProgramsTablesDictionary Objects …

User Context

Roll InRoll Out

Shared Memory

Buffer Access

Work Process 1

Work Process n

The two parts of the dialog step from the system’s point of view are called PBO and PAI. Organizational units can belong to a single application or they be assigned to several applications. The client is the superior element of all organizational units. A client corresponds to a group with several subsidiaries. All company data in an R/3 installation are differentiated at least by client, but usually also by

deeper organizational structures. Master data include customers, suppliers, materials, accounts and so on. Master data are created centrally (for all applications). Master data have an organizational aspect. They are assigned to organizational units. Whenever you save a query, an order an outline agreement, a inquiry conformation, a delivery note

and so on, an output format is created from the document concerned. This output format is a message (message type). The message is then placed in the message queue, from where it can be released for printing, output via EDI and so on as required.

The message control can be stored as a default value in the business partner’s master record. The SAP Business Workflow is a tool that you can use to optimize the flow of business

transactions. Workflow brings the “right” work in the “right” sequence to the “right” persons at the “right” time.

This can be done using an automated mail or a workflow item.

Object Oriented Programming Concepts:

Object orientation focuses on objects that represent either abstract or concrete things in the real world.

The behavior of objects is described through methods and events. Modeler, end user, and developer are all included in analysis and design process. Features of OOPs.

1. Encapsulation2. Polymorphism – objects in different classes react differently to the same messages.3. Inheritance – ABAP Objects only allows single inheritance.

Objects behave like client/server systems. When an object calls a method of another object, this give rise to two conditions:

1. The client object must adhere to the protocol of the server object.2. The protocol must be clearly described so that a potential client can follow it without a

problem. ABAP Objects statements can be used in procedural ABAP programs. In ABAP objects, types have to be assigned more strictly than in ABAP. Data and business functions are encapsulated in objects. In object-oriented programming, the analysis and design phase is even more important than it is for

procedural programming. Attributes of a class define the state of an object. ABAP Objects events are not included in class diagrams. UML Diagram Types:

Class diagram show the static view of a model Behavior diagram, such as Sequence diagram demonstrate the relationships and

method calls between objects. Component diagram show the organization and dependencies of components. Distribution diagram represent the dependencies of software and hardware.

An association describes a semantic relationship between classes. Object links are therefore the instances of an association.

Each association has two roles, one for each direction of the association (booking customer, customer booking).

Each role has a cardinality that shows how many instances participate in this relationship. Common Cardinalities:

* or 0..* Many 1 Exactly one 1..* One or more 0..1 Zero or one

An association is represented by a line between the class symbols The cardinality of the relationship can be shown at each end of the line. Associations can be given name for ease of identification. Should be in italics. Aggregation is a special kind of association. It describes one object that contains another or

consists of other objects (whole-part). The relationship can be described by the words “consists of” or “is part of”. An aggregation like association is represented by a line between two classes, which then

additionally has a small rhombus at one end. The rhombus is always at the aggregate side. Composition is a special kind of aggregation. Composition describes the fact that the object

contained cannot exist without the aggregate. Parts do not exist if the whole does not exist. Composition is shown as a line between two classes and marked with a small opaque rhombus on

the aggregate side. Sequence diagrams focus on the time sequence of the information exchange. Sequence diagrams have no notation for representing static methods. Object life line is represented by vertical dotted lines. Control focus is shown as a vertical rectangle on the object life line. The control focus shows the

object’s “active” period: Messages are shown as horizontal arrows between the object lines. The components of a class are attributes, methods, events, constants, types and implemented

interfaces.

A class cannot be nested inside another class. Public Attributes:

Can be viewed and changed by all users and in all methods. Direct access.

Private Attributes: Can only be viewed and changed from within the class. No direct access from outside the class.

Instance Attributes: One per instance. Statement: DATA

Static Attributes: Only one per class Statement: CLASS-DATA Also known as class attributes

Methods have a parameter interface called signature.

In ABAP Objects, methods can have IMPORTING, EXPORTING, CHANGING and RETURNING parameters as well as exception parameters.

You should no longer use the EXCEPTIONS parameter for exceptions but use the RAISING addition instead.

You can define a return code for methods using RETURNING. You can only do this for a single parameter, which additionally must be passed as a value. Also, you cannot then define EXPORTING and CHANGING parameters.

RETURNING = √ EXPORTING = × CHANGING = ×

Instance Methods: Can use both static and instance

components in their implementation part. Can be called using an instance. Defined using METHODS To call an instance methods write CALL

METHOD <instance_name> <method >. Static Methods:

Can only use static components in their implementation part. Can be called using the class. Defined using CLASS-METHODS. To call an instance methods write CALL METHOD <class_name> => <method >.

UML Notation: + Refers to public components. - Refers to private components. _ Refers to static components. # Refers to protected components.

Objects are instantiated using the statement CREATE OBJECT During instantiation, the runtime environment dynamically requests main memory

space and assigns it to the object. As soon as no more references point to an object, the Garbage Collector removes it

from the memory. The implementation of the operations of a class is called method. In the case of methods that return parameters to the caller, the IMPORTING addition

must always be used and all actual and formal parameters must be listed. Methods that have a RETURNING parameter are described as functional methods.

These methods cannot have EXPORTING or CHANGING parameters. Some syntaxes for method calls:

No IMPORTING parameters: reffunc_method( ) Exactly 1 IMPORTING parameter: reffunc_method( p1 ) or

reffunc_method( im_1 = p1 ) Several IMPORTING parameters: reffunc_method( im_1 = p1 im_2 = p2 )

=> and are component selectors. Constructors:

Each class can have one constructor The constructor is automatically called at runtime within the CREATE OBJECT

statement. Cannot be called explicitly. Define the constructor in the PUBLIC SECTION. Only has IMPORTING parameters and EXCEPTIONS. When exceptions are raised in the constructor, instances are not created, so no

main memory space is occupied. Implement Constructor when:

You need to allocate resources (external). You need to initialize attributes that cannot be covered by the

VALUE addition to the DATA statement. You need to modify static attributes.

Static Constructor: Automatically called before the class is first accessed. Only execute once per program.

An object calls another object’s method and passes its own address. The inheritance relationship is often described as an “is a”

relationship. Inheritance is a “one-sided relationship”: Subclasses know their

direct superclasses, but (super) classes do not know their subclasses. If you redefine a method, you do not need to enter its interface

again in the subclass, but only the name of the method. The reason for this is that ABAP Objects does not support overloading. Exception Overloading is possible with the constructor.

If no instance constructor has been defined for a class, then a default constructor, which is implicitly always present, is used. This default constructor calls the constructor from the immediate superclass.

Method Redefinition: Inherited methods can be redefined in subclasses. Redefined methods must be re-implemented in subclasses The signature of redefined methods cannot be changed. Static methods cannot be redefined In inheritance, static components are “shared”.

A class that defines a public or protected static attributes shares this attribute with all its subclasses.

After the narrowing cast, you can use the superclass reference to access the components of the subclass instance that were inherited from superclass.

Variables that point to a superclass instance can also refer to subclass instances at runtime.

Narrowing cast switching from a more detailed view to a one with less detail. Also known as up-cast.

When objects from different classes react differently to the same method call, this is known as polymorphism.

When an instance receives a message to execute a particular method, then that method is executed if it has been implemented by the class the instance belongs to. If the class has not implemented that method, but only inherited and not redefined it, then a search up through the inheritance hierarchy is carried out until an implementation of that is found.

The dynamic type, not the static type of the reference variable is used to search for the implementation method.

A reference variable always has two types, static and dynamic.

The reference me can be used to determine the dynamic type.

Widening cast means switching from a less detailed view to a one with more detailed view. Also known as down-cast.

Widening cast operator is “?=”. E.g.: <subclass_instance> ?= <superclass_instance>. We must enclose the above statement in TRY … CATCH

… ENDTRY block as it may throw CX_SY_MOVE_CAST_ERROR exception if the cast cannot be carried out.

Interfaces only describe the external point of contact of a class (protocols), they do not contain any implementation.

The Interface Resolution Operator <interfacename>~<componentname>.

Changes to an interface usually invalidate all the classes’ implementating it.

Interface references always refer to instances in the classes carrying out the implementation. Interfaces references always have both static and dynamic types.

With an interface reference, you can no longer address all components in the class carrying out the implementation, but only the components defined in the interface.

EVENTS:

Triggering Events:1. Class defines event (EVENTS, CLASS-EVENTS).2. Object or class triggers event (RAISE EVENT)

Handing Events:1. Event handler class defines and implements event handler method ( [CLASS-]

METHODS <handler_method> FOR EVENT <event> OF <classname>)2. Event handler object or handler class registers itself to specific events at runtime (SET

HANDLER <handler_method> FOR <reference>. For instance events. SET HANDLER <handler_method>. For static events.).

Both instance and static events can be triggered in instance methods. Only static events can be triggered in static methods. Events can only have EXPORTING parameters which must be passed by value. Events are registered using the SET HANDLER statement. Events cannot be persistent. The implicit parameter sender can also be listed as an IMPORTING parameter for instance events.

This passes on a reference to the object that triggered the event. You can register an event using ACTIVATION ‘X’, and deregister it using ACTIVATION

SPACE. If you do not specify ACTIVATION, then the event registers.SET HANDLER <ref_handle> <on_event> FOR <ref_sender> | FOR ALL INSTANCES | [ACTIVATION <var>].

Event handling is sequential Sequence in which event handler methods are called is not defined With regard to the Garbage Collector, registration has the same effect as a reference to the

registered object. Registered objects are never deleted. The visibility of an event defines authorization for event handling. Abstract classes themselves cannot be instantiated (although their subclasses can) References to abstract classes can refer to instances of subclasses Abstract (instance) methods are defined in the class, but not implemented. They must be redefined

in subclasses. Classes with at least one abstract method are abstract themselves. Static methods and constructors cannot be abstract (they cannot be redefined). Final classes cannot have subclasses. Final methods cannot be redefined in subclasses. Hence methods cannot be both final and abstract. Classes, on the other hand, that are both final and abstract are useful: only static components can

be used. Persistence service tasks.

1. Loading the objects from the database2. Managing changes to the objects3. Storing the objects in the database

When creating a persistent class, the Class Builder automatically creates a corresponding class, the so called class actor or agent, the methods of which are used to manage the objects of the persistence class.

A class declared with CREATE PRIVATE and FINAL ensures that there is only one instance of the class. The object is instantiated using static constructor.

Dialog Programming

Screen consists of a screen image and flow logic. A Screen has four components:

1. Screen mask2. Screen attributes3. Element list4. Flow-logic

Types of Screen:1. Normal 2. Subscreen3. Modal dialog box4. Selection Screen

The ABAP processor controls the program flow within a module. The DYNP processor controls the flow logic and prepares data to be displayed.

Copying of screen elements to corresponding ABAP work area and back takes place as follows:1. After PBO2. Before PAI

Dynamic changes to the attributes of screen elements are temporary. We can modify the dynamically modifiable attributes of screen elements in the PBO. You can include each screen element in up to four modification groups All of a program’s GUI titles and statuses taken together make up its user interface. Key assignments and application toolbars are sub objects of the function key settings. Menubar can contain 8 different menus i.e., 6 user defined + System + Help. Changes to the attributes of the screen elements are done in the PBO using LOOP AT SCREEN …

MODIFY SCREEN… END LOOP. You cannot use LOOP AT SCREEN WHERE … or READ TABLE SCREEN. as SCREEN is a

system internal table. Input / Output fields have:

1. Automatic field input checks.2. Data consistency checks.3. Input helps.

SET parameter copies the corresponding field contents into the SAP memory in the PAI processing block.

GET parameter copies the corresponding field contents from the SAP memory in the PBO processing block.

Data transport from the screen fields to ABAP program fields:1. First it transports all fields not contained in the FIELD statements.2. Then it transports all fields contained in the FIELD statements if no error message occurs.

If you use ON INPUT addition in a MODULE statement after FIELD, the module is called only if field contents have changed from their initial value (analogy ON CHAIN-INPUT if at least one field has changed.)

ON REQUEST & ON CHAIN-REQUEST MODULE is called if the user has entered new values for the field.

Function Type : BACK ‘ ‘, EXIT ‘E’, CANCEL ‘E’. AT EXIT-COMMAND Module is processed before PAI or any field transport and input checks. A page element consists of a tab title, a subscreen area and a subscreen. The ACTIVETAB field of CXTAB (TABSTRIP) contains the function code of the tab title of the

currently active tabstrip. The PAI processing block is triggered when you scroll vertically in the table control or save the

user configuration. You can use the selected field of cols structure in table control structure to determine the selected

column. Transportation of data from the screen fields to ABAP fields:

1. All data except data in table controls and data listed in FIELDS are transported.2. Table control data are transported line-by-line in LOOP.3. Finally all data listed in FIELDS are transported.

In currency fields first the reference fields must be transported then the currency amount fields. Permanent changes to table control can be carried out at any point in program flow.

Temporary changes to table control must be carried out in LOOP …END LOOP. SET SCREEN <nnnn> statement temporarily overwrites the Next screen attribute. If you enter a 0 in the Next screen attribute, the system resumes processing from the point at which

the screen was initiated, once it has finished processing the screen itself. Menus can be up to 3 levels deep. Status Type of GUI Status :

1. Online status2. Dialog box3. Context menu

Restrictions to subscreens:1. CALL SUBSCREEN is not allowed in the LOOP…ENDLOOP or between CHAIN and

ENDCHAIN.2. A subscreen may not have a named OK_CODE field.3. Object names must be unique within the set of all subscreens called in a single main screen.4. Subscreens may not contain a module with the AT EXIT-COMMAND addition.5. You cannot use the SET TITLEBAR, SET PF-STATUS, SET SCREEN or LEAVE SCREEN

statements in the modules of the subscreen. To use a subscreen you must call it in both the PBO and PAI sections of the flow logic of the main

screen. If the function type of the tabstrip control is ‘P’, the user can scroll between different tab pages of

the same type without triggering the PAI processing block. To scroll freely among tabs of tabstrip control:

1. You must assign subscreen area to each tab page.2. Call all of the subscreens from the flow logic.3. Assign function type ‘P’ to all the tab titles.

If there are no page elements containing elements that can be displayed, the system hides the entire tabstrip control.

If you want the application program to process scrolling (executing PAI) in the tabstrip control, the following requirements must be met:1. All of the tab pages must share a common subscreen area.2. All of the tab titles must have the function code type ‘ ’ (space).3. In the flow logic, you must use a variable to call the screen that is to be displayed in the

subscreen area. The top line of a table control is the header line, which is distinguished by a gray separator. A line may have up to 255 columns; each column may have a title. The table control contains a series of actions that are controlled entirely at the presentation server:

1. Horizontal scrolling using the scrollbar in the table control2. Swapping columns3. Changing column width4. Selecting columns5. Selecting lines

The PAI processing block is triggered when you scroll vertically in the table control or save the user configuration.

The stepl and loopc fields of structure syst (sy-stepl and sy-loopc) contain information about the loop processing used with table controls.

Use Entry table as the table type if you are creating the table to enter data. Use Selection table if the table is only for selecting and transferring entries, or if the table exists only in display mode.

When you create a table control, you must create:1. A table control area2. Table control fields

At run-time, the data object (my_control) contains the static attributes of the table control. The USING SCREEN addition in the CONTROLS statement determines the screen whose initial

values are to be used for the table control. You can reset a table control to its initial attributes at any time using the statement REFRESH

CONTROL <ctrl> FROM SCREEN <scr>. The general attributes contain information about the properties of the entire table control, such as

the number of fixed columns. In the PBO processing block, data is transferred from the ABAP program to the screen after each

loop pass in the flow logic. The rest of the screen fields are filled, as normal, at the end of the PBO.

Field Transport in the PAI: Table Control.

1. In the PAI, all screen fields that do not belong to a table control and that are not listed in a FIELD statement are transported back to the work fields in the ABAP program first.

2. The contents of the table control are transported line by line to the corresponding work area in the ABAP program in the appropriate loop.

3. As usual, the fields that occur in FIELD statements are transported last. To change the attributes of individual cells temporarily, change the SCREEN table in a PBO

module that you process between LOOP and ENDLOOP in the flow logic (LOOP AT SCREEN, MODIFY SCREEN).

You can use the selected field of the SCREEN table to determine whether the user has selected a particular column.

Database Updates (+)

All Open SQL commands provide you with a return message about the success or failure of the database operation performed. ( sy-subrc = 0 for success)

Open SQL commands do not perform any automatic authorization checks. You need to execute these explicitly in the program.

An Open SQL command accesses all clients if it contains the addition CLIENT SPECIFIED without a client specification.

INSERT VARIANTS:1. Single record insert:

INSERT INTO <dbtab> [CLIENT SPECIFIED] VALUES <wa>. INSERT <dbtab> [CLIENT SPECIFIED] FROM <wa>.

2. Multiple records insert: INSERT <dbtab> [CLIENT SPECIFIED] FROM TABLE <itab>.

Rows can also be inserted in tables using views only if it has maintenance status “read and change” and must contain fields from a table.

The Insert variant has the following return code:1. 0 = Line inserted successfully2. 4 = Line could not be inserted because a line with the same key already exists.

In multiple record insert if any one record cannot be inserted a runtime error occurs. Hence rollback occurs.

If you want that other records may be inserted without runtime errors use the addition ACCEPTING DUPLICATES. The system inserts those records which can be inserted but sets the sy-subrc to 4.

UPDATE VARIANTS:1. Single record updates:

UPDATE <dbtab> [CLIENT SPECIFIED] FROM <wa>. UPDATE <dbtab> [CLIENT SPECIFIED] SET <f1> = <g1> … <fn> = <gn>

WHERE <full_qualified_key>.2. Multiple records updates:

UPDATE <dbtab> [CLIENT SPECIFIED] SET <f1> = <g1> … <fn> = <gn>

WHERE <condition>. UPDATE <dbtab> [CLIENT SPECIFIED] FROM TABLE <itab>.

The single record update variant have the following return codes:1. 0 = Line was changed.2. 4 = Line could not be changed because, for example, the specified key does not exist.

The multiple records update variant 1. have the following return codes.1. 0 = Atleast one line was changed.2. 4 = No line was changed because, for example no such line exists.

The multiple records update variant 2. have the following return codes.1. 0 = All lines were changed successfully.2. 4 = Atleast one of the specified line could not be changed because, for example it does

not exist. MODIFY command covers two commands UPDATE and INSERT. MODIFY VARIANTS:

1. Single record modify : MODIFY <dbtab> [CLIENT SPECIFIED] FROM <wa>.

2. Multiple records modify: MODIFY <dbtab> [CLIENT SPECIFIED] FROM TABLE <itab>.

This command has the following return codes.1. 0 = Specified record or all specified records were processed (updated/inserted).2. 4 = The specified record or at least one of the specified records could not be processed.

DELETE VARIANTS:1. Single record delete:

DELETE FROM <dbtab> [CLIENT SPECIFIED] WHERE <full_qualified_key>.

DELETE <dbtab> [CLIENT SPECIFIED] FROM <wa>.

2. Multiple records delete: DELETE FROM <dbtab> [CLIENT SPECIFIED]

WHERE <condition>. DELETE <dbtab> [CLIENT SPECIFIED] FROM TABLE <itab>.

Return codes for single record delete variant.1. 0 = Line was deleted.2. 4 = Line could not be deleted bcoz, for example it does not exist.

Return codes for multiple record delete variant with where condition.1. 0 = At least one line was deleted.2. 4 = No line was deleted bcoz for example the specified lines do not even exist.

Return codes for multiple record delete variant with where condition.1. 0 = All the lines specified in the internal table were deleted.2. 4 = At least one line could not be deleted, the other records were deleted.

There are two ways of causing a database rollback.1. Sending a termination dialog message (Message A)2. Using the ABAP statement ROLLBACK WORK.

An SAP LUW consists of changes in SAP R/3 that logically belongs together. Either all or nothing principle.

A database LUW consists of changes that are executed until the database status is ‘sealed’ (DB Commit).

Explicit COMMIT:1. COMMIT WORK

Explicit ROLLBACK:1. ROLLBACK WORK

Implicit DBCOMMIT:1. Whenever there is a screen change.2. When the system sends a dialog message.3. Whenever there are synchronous and asynchronous RFC calls.4. With CALL TRANSACTION <tcode> or SUBMIT <program> statements.

The SAP LUW must be processed within a DB LUW. The user is assigned to a work process on an application server which in turn assigns the user to a

work process on the database server. After the work process has processed the user input in a dialog step, the user along with the program context is removed from the work process.

Before each single screen is displayed, the current work process is released on the application server. This in turn triggers the release of the respective database work process and automatically initiates an implicit DB Commit.

LOCKS

Locks are a way of coordinating competing accesses to a resource. It is important to release the lock as soon as possible so as not to hinder other users unnecessarily. At the end of a database LUW (after DB Commit) the database system releases all the database

locks (NOT SAP LOCKS) set during the DB LUW. The R/3 system has a unique global lock table for the purpose of retaining set locks through a

series of screens. The global lock table and the respective enqueue work process that manages the lock table are on a

uniquely defined application server of the SAP R/3 system. You can also use logical locks to ‘lock’ table entries that do not yet exist on the database. To create a lock object you must specify the name of the table on which the lock is to be set, the

lock mode (E, X, S), the name of the secondary table (if foreign key relationship exists) and lock parameter.

Lock objects are maintained in the Dictionary. Customer lock object names must begin with EY or EZ. Whenever you activate a lock object two function modules are generated automatically by the

system and are stored in the development class ‘$ENQ’. Naming conventions of the two lock object modules.

1. ENQUEUE_<lock-object_name> to set locks.2. DEQUEUE_<lock-object_name> to release locks.

A logical lock is set when you call the lock module, this writes a corresponding entry into the lock table.

Possible answers while setting a lock.

1. Lock set successfully2. Lock could not be set because:

a. Entry already blocked (Exception ‘FOREIGN_LOCK’)b. Error in lock management (Exception ‘SYSTEM_FAILURE’)

Depending on the bundle technique used for database updates, an application program may need to delete again the lock entries it has created (during inline update) or have them deleted automatically (during the update task)

Locks are released implicitly :1. When program terminates.

a. If message type “A” / “X” is executed.b. LEAVE PROGRAM, LEAVE TO TRANSACTION

DEQUEUE function modules do not trigger any exceptions. If you attempt to release an entry that is not locked, this has no effect.

To release all locks set by ABAP program use function module DEQUEUE_ALL The following rules apply when you call the lock module and lock applies as follows.

1. If the client parameter is not specified current execution client.2. If the client parameter is specified applies to this client.3. If the client parameter is specified with a SPACE all client.

To display lock table transaction SM12. Parameters in ENQUEUE Module.

Parameters Values MeaningMode_<TabName> ‘E’

‘X’‘S’

Exclusive lock (accumulative)Exclusive lock (not accumulative)Shared lock (accumulative)

<Lock parameter> <Value> Field value to be used for lockingX_<Lock parameter> SPACE

‘X’Lock acc. to corresponding lock parameter (Default)Lock for table line with initial field value

_scope ‘1’‘2’‘3’

Lock remains in programLock passed to V1 update (default)Lock in program + passed to V1 update

_wait SPACE‘X’

If external lock, no further lock attempt (default)If external lock, second lock attempt

_collect SPACE‘X’

Setting lock without local lock container (default)Setting lock with local lock container

You can send the contents of the lock container afterwards to the lock management using the function module FLUSH_ENQUEUE.

If one of the locks in a container cannot be set, the function module FLUSH_ENQUEUE triggers the exception FOREIGN_LOCK. In this case none of the locks in the container is set.

You can delete the contents of the container using the function module RESET_ENQUEUE. Lock Modes:

1. E: sets lock for changing data. Lock can be accumulated.2. X: used like mode E for changing data. Does not allow accumulation.3. S: ensures that data displayed in your program cannot be changed by other

users during display time.Other

ProgramsExisting Program

E X SE × × × X × × ×S × × √

SameProgram

Existing LocksE X S

E √ × √X × × ×S √ × √

Sequence of setting and releasing locks.1. Lock the data.2. Read the data.3. Update the data.4. Release the locks set on the data.

Organizing Updates: Database updates from dialog mode can be executed in bundled form using the special subroutine

technique PERFORM <subroutine> ON COMMIT. Each subroutine registered with PERFORM ON COMMIT is executed only once per LUW. Calls

can be made more than once (no errors); however it is executed only once. The COMMIT WORK statement carries out all subroutines registered to be executed one after the

other and triggers a database commit. If in a subroutine update cannot be carried out then you can terminate processing that subroutine

using Message Type ‘A’ (Hence ROLLBACK). Subroutines called using PERFORM ON COMMIT must have no interface. They work instead

with global data. PERFORM ON COMMIT / Update within program :

1. Are synchronous updates.2. Gives poor DB performance as the user has to wait until the update has been made. Hence

work process is occupied.3. Used only for single record update and updates which are not critical for performance.

In update techniques user dialog runs in separate work process and all updates are carried out in separate programs (update program) which again run in separate work process.

No dialogs run in the update program. Transaction SM13 to monitor update requests. To examine error log entries during updates. An update program must be implemented as special function module (update module) whose

interface only includes IMPORTING and TABLES parameter. These must be typed using reference fields or structures.

In the update function module use the IN UPDATE TASK addition. This means that the function is not executed immediately, but is written to the log table.

Function modules with IN UPDATE TASK are recorded to log table under same update key and are executed when the dialog program executes COMMIT WORK.

When COMMIT WORK is encountered the entries of the log table with same update key are closed by creating a header (log header) which contains the information of the dialog program.

ROLLBACK WORK or MSG TYPE ‘A’1. Delete all change requests written up to that point2. Delete all the locks set up to that point3. Discard all the changes executed in the current DB LUW4. Discard all the form routines registered using PERFORM ON COMMIT.

The ROLLBACK WORK does not affect the program context. You may not use the explicit ABAP statements COMMIT WORK or ROLLBACK WORK in an

update module. The update module automatically releases all the locks on its completion. The automatic release of locks by the update module will also take place if there is an error. The reprocessing of the failed updates is carried out in V2 update modules without locks. In asynchronous updates, the dialog program runs separately. COMMIT WORK AND WAIT is a synchronous update where the calling program waits until

the update ends. During the entire waiting phase, the dialog program is in a “rolled out” state. This means that the

respective dialog work process is released for further use. When the update is complete, the system again assigns a free dialog work process for further processing.

In local updates, the update functions are run in the same dialog process used by the dialog program containing the dialog program (that is locally). Synchronous.

Use the statement SET UPDATE TASK LOCAL before you write respective requests. Local updates are appropriate in batch mode only. There are two types of update modules: V1 and V2. All V1 requests in the dialog program are executed as independent DB LUW. Only if the V1

requests are executed successfully are V2 requests processed, also as independent LUWs. V1 modules can be restartable or non-restartable. V2 update modules can always be restarted for

processing if there was an error.

V1 update modules create requests in the VBLOG table for synchronous and asynchronous updates. For local updates, the V1 requests are retained in the main memory.

V2 requests are always stored in the VBLOG table. If the V1 update module terminates with a termination message, all locks passed on to the update

task are deleted, a DB rollback takes place, an email is send to the user who created the LUW, and the V1 requests are flagged as incorrect. V2 update is not triggered.

If V2 update is terminated by a termination message of a V2 update module, the system triggers a database rollback. All of the V2 changes in the SAP LUW are undone and the V2 requests in VBLOG are flagged as incorrect with the corresponding termination message.

The locks created from within the dialog program using _SCOPE = 2 (default) are transferred to the V1 update task at COMMIT WORK (AND WAIT). At the end of the V1 update, they are automatically deleted, regardless of whether the V1 update was successful or not.

V2 update always runs without SAP locks. Performance Rules:

Create new entries first (INSERT). Then perform changes to non-performance-critical tables (UPDATE). Then perform changes to performance-critical tables (UPDATE).

Synchronous Calls: CALL FUNCTION, CALL TRANSACTION, SUBMIT <program> AND RETURN

The processing of the calling program is interrupted and then continued again after the called program is completed.

SUBMIT <program>, LEAVE TO TRANSACTION <t_code> The calling program is interrupted (terminated) and the called program is started.

You can use SUBMIT <program> and SUBMIT <program> AND RETURN to start executable programs (type 1).

Asynchronous Calls: CALL FUNCTION ‘<fun_name>’ STARTING NEW TASK <task

name>. Asynchronously called function modules are processed in parallel with

and independent of the calling program. You can receive the output of the function module (RECEIVE RESULTS

FROM FUNCTION) in a later processing phase of the calling program. Must be marked as remote capable modules.

Several internal sessions (up to 9) can run within one external session.

You can use SAP memory and ABAP memory to pass data between different programs.

ABAP memory is a storage area for internal program variables so that they can be passed between internal sessions of an external session.

When a function module is called (CALL FUNCTION), the corresponding function group is loaded into the current internal session and the called function module is processed.

The loaded function group and the global data objects in it are kept in the internal session until the end of the calling program.

The program called using CALL TRANSACTION or SUBMIT AND RETURN runs in a separately opened internal session that contains a new program context.

After the called program has been completed, the new internal session is deleted and processing is continued for the calling program.

If a program is called through the SUBMIT statement, the context of the calling program is removed from the current internal session and the called program is loaded for processing.

The LEAVE TO TRANSACTION statement removes all the internal sessions of the current external session and opens a new internal session for processing the called transaction.

When this happens, the ABAP memory is initialized! This means, in particular, that you cannot pass any data to the called transaction through the ABAP memory.

The SUBMIT addition VIA SELECTION-SCREEN is used to start the called program by displaying its selection screen. If this addition is not specified, the system executes the program without processing its selection screen.

You can use ABAP memory to exchange data between the programs in the same external session.

EXPORT TO MEMORY ID <id> statement is used to write the value for the data to the memory location <id>.

IMPORT FROM MEMORY ID <id> is used to read the value of the data from the memory location <id>.

If data is written to the same memory location then the data in that memory location is overwritten.

Using the Object Navigator you can define parameter IDs for the SAP R/3 system.

SAP memory is used to exchange data between programs running in the different external sessions.

SET PARAMETER ID is used to write the value to the SAP memory location ID.

GET PARAMETER ID is used to read the value from the SAP memory location ID.

A screen input field can display the corresponding parameter value in the SAP memory to the user as an input proposal. The following prerequisites must be fulfilled:1. The screen input field has been defined through a data

element that is linked to the corresponding parameter ID.2. The GET functions of the screen fields are activated.3. The program supplies the screen fields only with the

initial values. Function modules run in the same SAP LUW as the program that calls them. If you have SUBMIT AND RETURN and CALL TRANSACTION, the SAP LUW of the

calling program is continued as soon as the calling program is completed. The LUWs of calling and called programs are run independently of one another, therefore the following happens:

Direct inline changes are updated to the database at each screen change. Both update flags and calls using PERFORM ON COMMIT require a separate

COMMIT WORK in the corresponding SAP LUW. If SUBMIT and LEAVE TO TRANSACTION are used, the SAP LUW of

the calling program ends. The asynchronous function module call triggers an implicit database commit

in the calling program. You cannot set additional locks (any) to existing ones from within a

program called using SUBMIT AND RETURN or CALL TRANSACTION. Any lock attempts from such programs will be rejected with the exception FOREIGN_LOCK.

If you have a program called using SUBMIT or LEAVE TO TRANSACTION, the calling program will be terminated immediately. All the locks set up to that point will automatically deleted.

With external number assignment, the user enters a number that is checked by the system to see if it has been reserved for external assignment.

To assign numbers without any problems, you need a corresponding number range object, a well-maintained number range interval, and access to both of these from within your application program.

Number range object names for customer objects should always begin with Y or Z.

The length of numbers (max number of characters) cannot be entered directly; you must enter a domain instead. This domain can be either type NUMC or type CHAR and have a field length of up to 20 characters

Number range intervals are composed of either numbers or alphanumeric characters (external number ranges only).

Number ranges objects can be subdivided into subobjects. When assigning numbers internally, call the function module

NUMBER_GET_NEXT to determine the next number(s) available. If the last number of the interval has been assigned, the number assignment

begins again at the first number of the interval, provided Roll was specified in the definition of the number range object.

The return code (number assignment) allows you to see if the number can be assigned without any problems, or if it lies within a critical area.

SPACE : Number assignment successful 1 : Number assignment successful, but many numbers are still

available in critical area. 2 : Number assignment successful; the last number available was

just assigned to you. 3 : You requested more numbers than were available. The

available numbers were assigned to you. The function module NUMBER_CHECK is used to check external numbers to see if they lie

within a number range interval. The check results are returned through the export parameter return code.

SPACE : Number within the specified interval X : Number outside the specified interval

In the function module NUMBER_GET_NEXT, the SELECT SINGLE … FOR UPDATE statement is used to access table NRIV. This locks the relevant table entry in the database until completion of the current LUW.

Buffering transfers responsibility for most number assignments to your application server.

Function module NUMBER_GET_NEXT offers you the option of ignoring the buffer if you so desire (interface parameter IGNORE_BUFFER).

Another means of assigning buffered numbers is to buffer the numbers block by block for each application server on the database.

Using function groups to manage number ranges.Function Group SNR0

Maintenance dialog for number ranges, intervals, and groups

Function Group SNR1

Services for reading and maintaining number range intervals & groups

Function Group SNR2

Services for reading, maintaining, and for maint. Dialog with no. range objects

Function Group SNR3

Number checks and assignments

Function Group SNR4

Utilities

Enhancements and Modifications

SAP enhancements are made up of component parts. Components:

i. Function module exitsii. Menu exits

iii. Screen exits SAP Enhancements creation procedure

i. Customer exits define i.e. function module exits, screen exits, menu exits.ii. Collect components for SAP enhancement.

iii. Document enhancement project. Function module exit’s function module always resides in the function group starting with

‘X’. In Exit function group SAP global data are stored in include program LXaaaTAP. In Exit function group customer global data are stored in include program LXaaaTOP. Subscreen cannot have GUI status. In subscreens you should not enter value in the next screen field. Business Transaction Events have two types of interface:

i. Publish & Subscribe Interfaces These interfaces inform external s/w component about an event triggered in the SAP application, External s/w cannot return data to SAP program.

ii. Process Interfaces They intervene in the standard process and return data to the SAP application.

BTEs and BAdIs are reusable while customer exits are not. A BAdI can have more than one implementations but only one can be active at any time. FCodes in BAdI could be implemented only once (NO REUSABILITY), Hence BAdI should

not be filter-dependent. Procedure for using BAdI:

i. Create a ref variable of the BAdI interface.DATA: r_var TYPE REF TO <BAdI-interface>

ii. Get the reference of the instance of the implementation class in r_var.CALL METHOD CL_EXITHANDLER => get_instance CHANGING Instance = r_var

iii. Call any of the interface methods from the implementing class using the ref variable r_var.CALL METHOD r_var method1 EXPORTING <i_variables>

IMPORTING <e_variables>

When you activate the BAdI interface, the BAdI class is generated for the BAdI. If you change the BAdI interface the BAdI class is then regenerated automatically. If a BAdI contains one or more screen enhancements, it cannot be flagged as

Reusable. Repairs to SAP objects are called modification. Perform modification adjustments in your development system to ensure consistency. During the modification adjustment, use transaction SPDD to adjust the following

ABAP Dictionary objects:i. Domains

ii. Data Elementsiii. Tables

SPAU is used to modify :i. ABAP programs

ii. Interfacesiii. Screensiv. Search helpsv. Views

vi. Lock objects

You can find a list of all user exits in the SAP Reference Implementation Guide. User exits are actually empty subroutines that SAP developers provide for you. You then fill

them with your own source code. A user exit is considered a modification, since technically objects in the SAP namespace are

being modified. User exits are mostly in SD. Includes are delivered only once. Modification Assistant: Tools Supported.

i. ABAP Editorii. Screen Painter

iii. Menu Painteriv. Text Elementsv. Class Builder

vi. Function Buildervii. ABAP Dictionary

viii. Documentation Critical Success Factors for User Exits:

i. Use narrow interfaces during encapsulationii. Standardize your modification documentation

iii. Log all modificationsiv. Confirm and release all repairs, as well as all requests that contain repairs.

Finding A BAdI : i. Search for a string “CL_EXITHANDLER” in the relevant program from where you

could get the reference variable that points to the badi-interface. You can then perform forward navigation.

ii. Using Application hierarchyiii. Using Repository browseriv. Using IMG (Implementation Guide)

BTEs are enhancements that were developed for the Financial Accounting (FI) component of R/3.

BTEs allow you to attach additional components, in the form of function module, for example to the R/3 system.

In BTEs multiple enhancements can exist side by side without impeding each other; however, only one of the enhancements can be processed at runtime. You must decide which bit of logic you want to execute at what time.

Publish & Subscribe interfaces: i. Allow you to start one or more (multiple) additional operations when a particular

event is triggered. They do not influence the standard R/3 program in any way.ii. Multiple operations do not interfere with each other.

iii. Add on components can only import data.iv. Possible applications: Additional checks (authorizations, existing duplicates, and so

on) Process interfaces:

i. In contrast to Publish and Subscribe interfaces, data is exchanged in both directions with process interfaces.

Finding a BTE: i. Search for a string “OPEN_FI_PERFORM_” in the relevant program.

ii. SAP reference IMG. BTEs are client-specific.