You are on page 1of 22

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 Cockpit
2. Demand Planning
3. Supply Network Planning and Deployment
4. 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 Internet
1. 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 format
2. 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 data
4. 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 requirements
2. Corrections
3. Problem messages
4. Current Output/ messages?
5. Notes database (Patches)
6. Training course information
7. 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 field
2. Menu bar
3. Standard toolbar
4. Application toolbar
5. Title bar
6. Checkboxes
7. Radio buttons
8. Tab
9. 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 processes
2. Connecting to the presentation level
3. 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 parameters
2. starts work processes
3. Logs on to the message server.
• SAP GUI Types:
1. Windows 32 bit SAP GUI for Windows
2. Java Application SAP GUI for Java
3. 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
Allowed per dispatcher
System
D – Dialog -- At least two
S – Spool At least one More than one allowed
U – Update At least one More than one allowed
B – Background At least two More than one allowed
E – 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.

Front-end: SAP GUI

Request Queues Dispatcher

Work Process n
Work Process 1 Screen Screen
Internal Memory

Internal Memory

Processor Processor
ABAP
Processor
Task
Handler … ABAP
Processor
Task
Handler

Database Database
Interface Interface

Buffer Access Roll Out Roll In

Application Buffer Roll Area

Factory Calendar
Shared Memory Screens
ABAP Programs User Context Roll File
Tables
Dictionary Objects …

• 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.
• 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. Encapsulation
2. 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: reffunc_method( )
 Exactly 1 IMPORTING parameter: reffunc_method( p1 ) or
reffunc_method( im_1 = p1 )
 Several IMPORTING parameters: reffunc_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 database
2. Managing changes to the objects
3. 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 mask
2. Screen attributes
3. Element list
4. Flow-logic
• Types of Screen:
1. Normal
2. Subscreen
3. Modal dialog box
4. 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 PBO
2. 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 status
2. Dialog box
3. 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 control
2. Swapping columns
3. Changing column width
4. Selecting columns
5. 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 area
2. 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 successfully
2. 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 successfully
2. 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 Meaning
Mode_<TabName> ‘E’ Exclusive lock (accumulative)
‘X’ Exclusive lock (not accumulative)
‘S’ Shared lock (accumulative)
<Lock parameter> <Value> Field value to be used for locking
X_<Lock parameter> SPACE Lock acc. to corresponding lock parameter (Default)
‘X’ Lock for table line with initial field value
_scope ‘1’ Lock remains in program
‘2’ Lock passed to V1 update (default)
‘3’ Lock in program + passed to V1 update
_wait SPACE If external lock, no further lock attempt (default)
‘X’ If external lock, second lock attempt
_collect SPACE Setting lock without local lock container (default)
‘X’ 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 Existing Program
Programs E X S
E × × ×
X × × ×
S × × √
Same Existing Locks
Program E 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 point
2. Delete all the locks set up to that point
3. Discard all the changes executed in the current DB LUW
4. 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 Maintenance dialog for number ranges, intervals, and groups
SNR0
Function Group Services for reading and maintaining number range intervals & groups
SNR1
Function Group Services for reading, maintaining, and for maint. Dialog with no. range
SNR2 objects
Function Group Number checks and assignments
SNR3
Function Group Utilities
SNR4
Enhancements and Modifications

• SAP enhancements are made up of component parts.


• Components:
i. Function module exits
ii. 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 Elements
iii. Tables
• SPAU is used to modify :
i. ABAP programs
ii. Interfaces
iii. Screens
iv. Search helps
v. 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 Editor
ii. Screen Painter
iii. Menu Painter
iv. Text Elements
v. Class Builder
vi. Function Builder
vii. ABAP Dictionary
viii. Documentation
• Critical Success Factors for User Exits:
i. Use narrow interfaces during encapsulation
ii. Standardize your modification documentation
iii. Log all modifications
iv. 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 hierarchy
iii. Using Repository browser
iv. 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.

You might also like