SAP Implementation

n
SAP Implementation is the whole of processes that defines a complete method to implement the Enterprise Resource Planning SAP ERP software in an organization. The SAP implementation method described in this entry is a generic method and not a specific implementation method as such. It is based on best practices and case studies from various literature sources and presents a collection of processes and products that make up a complete implementation method to allow any organization to plan and execute the implementation of SAP software.
Introduction
The implementation of SAP software, such as SAP R/3 is almost always a massive operation that brings a lot of changes in the organization. The whole process can take up to several years. Virtually every person in the organization is involved, whether they are part of the SAP technical support organization (TSO) or the actual end-users of the SAP software. The resulting changes that the implementation of SAP generates are intended to reach high level goals, such as improved communication and increased return on information (as people will work with the same information). It is therefore very important that the implementation process is planned and executed with the usage of a solid method. There are various SAP implementation methods. An example of how one company, Robert Bosch GmbH, implemented SAP R/3 over 10 years is available This study shows that designing IT architecture is very critical in SAP implementation practices.

Table of concepts

The data table below provides a summary of all the concepts addressed in the process-data diagram.

Concept	Definition
CHANGE MANAGEMENT	***Activities involved in (1) defining and installing new values, attitudes, norms, and behaviors within an organization that support new ways of doing work and overcome resistance to change; (2) building consensus among customers and stakeholders on specific changes designed to better meet their needs; and (3) planning, testing, and implementing all aspects of the transition from one organizational structure or business process to another. (www.gao.gov)
CHANGE MANAGEMENT DOCUMENTATION.	All documentation that is required and being delivered whilst performing change management, e.g. the functional test cases and all the other documents a new end-user of SAP requires and the various tools and approaches used to manage change by the TSO. (Anderson, 2003)
COST OF OWNERSHIP ANALYSIS	Determination of where and when the costs are inquired within the context of the SAP solution stack and ongoing operations. The analysis addresses all internal and external costs, both one-time as well as recurring (Anderson, 2003)
CUTOVER	The process of transitioning from one system to a new one (Anderson, 2004
CUTOVER PLAN	All documentation related to planning, preparing and executing cutover, describing how to lock down the system from a technical change management perspective, preparing the TSO for its new role and rolling out the SAP graphical user interface to all future end users. (Anderson, 2003)
DATA CENTER	A data center is a facility used for housing a large amount of electronic equipment, typically computers and communications equipment. (www.wikipedia.org)
DATA CENTER REQUIREMENT	A requirement for the SAP data center, i.e. a physical requirement like power requirements, a rack requirement, a network infrastructure requirement or a requirement to the network server. (Anderson, 2003)
DISASTER RECOVERY (DR) REQUIREMENT	Requirement that focuses on downtime that lasts many hours to days or even weeks (Anderson, 2003)
FUNCTIONAL TEST CASE	A set of conditions or variables under which a tester will determine if a certain business process works (www.wikipedia.org)
HIGH AVAILABILITY (HA) REQUIREMENT	Requirements that describes the amount of time that the system needs to be available to satisfy the needs of the users. (Anderson, 2003)
INSTALLATION DOCUMENTATION	All documentation related to the installation of an end-to-end SAP solution (Anderson, 2003)
OPERATIONS MANUAL	The collection of current state system documentation, day-to-day and other regularly scheduled operations tasks, various installation and operations checklists and how-to process documents. (Anderson, 2003)
SAP	SAP AG is the name of the biggest European software company. The head office is in Walldorf, Germany. SAP was founded in 1972 as Systemanalyse and Programmentwicklung ("Systems Analysis and Product") by five former IBM employees in Mannheim, Germany. (www.wikipedia.org)
SAP IMPLEMENTATION PROJECT PLAN	A comprehensive project plan that contains all products that are delivered whilst performing an SAP implementation project (Anderson, 2003)
SOLUTION STACK	Set of software subsystems or components needed to deliver a fully functional solution, e.g. a product or service. (www.wikipedia.org)
SOLUTION STACK PARTNERS LIST	A list of all vendors that deliver the products that make up the SAP solution stack (Anderson, 2003)
SOLUTION VISION	A vision of the future-state of the SAP solution (Anderson, 2003)
STRESS TEST PLAN	A test plan that is focused at determining the stability of a given system or entity. It involves testing beyond normal operational capacity, often to a breaking point, in order to observe the results. (www.wikipedia.org
TEST PLAN	A detail of how the test will proceed, who will do the testing, what will be tested, in how much time the test will take place, and to what quality level the test will be performed. (IEEE 829)
TRAINING	The acquisition of knowledge, skills, and attitudes as a result of the teaching of vocational or practical skills and knowledge that relates to specific useful skills (www.wikipedia.org)
TRAINING PLAN	Consisting of training units, a training plan is the result of hierarchical decompositions of a training goal, tailored according to the learning preferences and prior knowledge of the trainee. A plan is the means by which the trainee satisfies the goal. (www.ece.eps.hw.ac.uk/)
TSO	Technical Support Organization. The people that are committed to implementation and management of SAP. (Anderson, 2003)
TSO CHART	A chart that depicts the structure of the TSO. (Anderson, 2003)

Activity table

The following table provides a summary of all of the activities that form the SAP implementation process. These activities will be described with more detail and elaborated with examples in the rest of this entry.

Activity	Sub-Activity	Description
Project preparation	Craft solution vision	Refine and communicate a SOLUTION VISION of the future-state of the SAP solution, to sketch a design that meets both business and financial requirements. The focus should be on the company’s core business and how the SAP solution will better enable that core business to be successful. Some of the guidance and key requirements for how to put together an ERP and SAP business case for ROI, business benefit, and success includes focusing on competitive pressures, value propositions, and how the solution enables success.
	Design and initially staff the SAP TSO	Design and staff the key positions of the SAP Technical Support Organization (TSO), the organization that is charged with addressing, designing, implementing and supporting the SAP solution.
Sizing and blueprinting	Perform cost of ownership analysis	Perform a COST OF OWNERSHIP ANALYSIS to determine how to get the best business solution for the least money i.e. to determine where and when the costs are incurred within the context of the SAP solution stack.
	Identify high availability and disaster recovery requirements	Determine all HIGH AVAILABILITY and DISASTER RECOVERY REQUIREMENTS, to plan what to do with later downtime of the SAP system
	Engage SAP solution stack vendors	Select the best SAP hardware and software technology partners for all layers and components of the SAP SOLUTION STACK, based on a side-by-side sizing comparison
	Staff TSO	Staff the bulk of the TSO, i.e. fill the positions that directly support the near-term objectives of the implementation, which are to develop and begin installation/implementation of the SAP data center.
	Execute training	Train the various members of the SAP TSO, like data center specialists, high availability specialist and network specialists and train the end-users to give all the required SAP knowledge and skills
	Setup SAP DATA CENTER	Build a new SAP DATA CENTER facility or transform the current data center into a foundation capable of supporting the SAP SOLUTION STACK
	Perform installations	Install the (My)SAP components and technological foundations like a web application server or enterprise portal.
	Round out support for SAP	Identify and staff the remaining TSO roles, e.g. roles that relate to help desk work and other such support providing work.
SAP functional development	Address Change Management	Develop a planned approach to the changes in the organization. The objective is to maximize the collective efforts of all people involved in the change and minimize the risk of failure of implementing the changes related to the SAP implementation.
	Address SAP systems and operations management	Create a foundation for the SAP systems management and SAP computer operations, by creating a SAP OPERATIONS MANUAL and by evaluating SAP management applications.
	Perform functional, integration and regression tests	Test the SAP business processes, by executing functional tests to ensure that business processes work, integration tests to ensure that the organization’s business processes work together with other business processes and regression tests to prove that a specific set of data and processes yield consistent and repeatable results.
Final Preparation	Perform systems and stress tests	Plan, script, execute and monitor SAP STRESS TESTS, to see if the expectations of the end users, defined in service level agreements, will be met.
	Prepare for cutover	Plan, prepare and execute the CUTOVER, by creating a CUTOVER PLAN that describes all cutover tasks that have to be performed before the actual go-live
Go Live		Turn on the SAP system for the end-users

Implementation processes

Project preparation

The project preparation phase, depicted below, focuses at two main activities, i.e. to make a setup for the TSO and to define a solution vision. These activities allow an organization to put in on the right track towards implementation.

Design and initially staff the SAP TSO

The first major step of the project preparation phase is to design and initially staff an SAP technical support organization (TSO), which is the organization that is charged with addressing, designing, implementing and supporting the SAP solution. This can be programmers, project management, database administrators, test teams, etc. At this point, the focus should be at staffing the key positions of the TSO, e.g. the high-level project team and SAP professionals like the senior database administrator and the solution architect. Next to that, this is the time to make decisions about choosing for internal staff members or external consultants.

The image at the right shows a typical TSO chart.

Craft solution vision

The second project preparation job is to define a so-called solution vision, i.e. a vision of the future-state of the SAP solution, where it is important to address both business and financial requirements (budgets). The main focus within the vision should be on the company’s core business and how the SAP solution will better enable that core business to be successful. Next to that, the shortcomings of the current systems should be described and short but clear requirements should be provided regarding availability (uptime), security, manageability and scalability of the SAP system.

Sizing and blueprinting

The next phase is often referred to as the sizing and blueprinting phase and forms the main chunk of the implementation process. The phase is illustrated below.

Perform cost of ownership analysis

This phase starts with performing a total cost of ownership analysis (TCO analysis) to determine how to get the best business solution at the lowest costs. This means to compare SAP solution stack options and alternatives and then determine what costs each part of the stack will bring and when these costs will be incurred. Parts of the stack are for example the hardware, operating system and database, which form the acquisition costs. Next to that, there should be taken a look at recurring costs like maintenance costs and downtime costs. Instead of performing a complete TCO analysis for various solution stack alternatives that would like to compare, it can be wise just to do a so-called delta analysis, where only the differences between solutions (stacks) are identified and analyzed. The image at the right depicts the essence of a delta analysis.

Identify high availability and disaster recovery requirements

The next step is identifying the high availability requirements and the more serious disaster recovery requirements. This is to plan what to do with later downtime of the SAP system, caused by e.g. hardware failures, application failures or power outages. It should be noted that it is very important to calculate the cost of downtime, so that an organization has a good idea of its actual availability requirements.

Engage SAP solution stack vendors

A true sizing process is to engage the SAP solution stack vendors, which is the next step. This means selecting the best SAP hardware and software technology partners for all layers and components of the solution stack, based on a side-by-side sizing comparison. The most important factors that are of influence here are the estimated numbers of (concurrent) users and batch sizes. A wise thing to do is to involve SAP AG itself to let them create a sizing proposal stating the advised solution stack, before moving to SAP’s technology partners/SAP vendors, like Accenture, [[HP}] and IBM. A simplified solution stack is depicted at the right, showing the many layers for which software and hardware has to be acquired. Note the overlap with the OSI model.

Staff TSO

The TSO is the most important resource for an organization that is implementing SAP, so staffing the TSO is a vital job which can consume a lot of time. In a previous phase, the organization should already have staffed the most vital positions. At this point the organization should staff the bulk of the TSO, i.e. fill the positions that directly support the near-term objectives of the implementation, which are to develop and begin the installation/implementation of the SAP data center. Examples are: data center experts, network infrastructure experts, security specialists and database administration experts.

There are many ways to find the right people within or outside the organization for all of the TSO positions and it depends on the organization how much time it wants to spend on staffing.

Training

One of the most vital stages of the implementation process is training. Very few people within an organization are SAP experts or even have worked with SAP software. It is therefore very important to train the end users but especially the SAP TSO: the people who design and implement the solution. Many people within the TSO need all kinds of training. Some examples of these positions:

• SAP Network Specialists
• SAP Database Administrators
• SAP Security specialists
• Documentation specialists
• Et cetera

All of these people need to acquire the required SAP knowledge and skills or even SAP certifications through training. Moreover, people need to learn to do business in a totally new way. To define how much SAP training every person needs, a company can make use of a skillset matrix. With this matrix, a manager can identify who possesses what knowledge, to manage and plan training, by defining the height of expertise with a number between e.g. 1 and 4 for each skill for each employee.

Setup SAP data center

The next step is to set up the SAP data center. This means either building a new data center facility or transforming the current data center into a foundation capable of supporting the SAP solution stack, i.e. all of the technology layers and components (SAP software products) in a productive SAP installation. The most important factor when designing the data center is availability. The high availability and disaster recovery requirements which should have been defined earlier, give a good idea of the required data center requirements to host the SAP software. Data center requirements can be a:

• Physical requirement like power requirements
• Rack requirement
• Network infrastructure requirement or
• Requirement to the network server.

Perform installations

The following step is to install the required SAP software parts which are called components and technological foundations like a web application server or enterprise portals, to a state ready for business process configuration. The most vital sub steps are to prepare your OS, prepare the database server and then start installing SAP software. Here it is very important to use installation guides, which are published for each SAP component or technology solution by SAP AG. Examples of SAP components are:

• R/3 Enterprise — Transaction Processing
• mySAP BI — Business Information Warehouse
• mySAP CRM — Customer Relationship Management
• mySAP KW — Knowledge Warehouse
• mySAP PLM — Product Lifecycle Management
• mySAP SCM — Supply Chain Management
• mySAP SEM — Strategic Enterprise Management
• mySAP SRM — Supplier Relationship Management
• mySAP HCM — Human Capital Management

Round out support for SAP

Before moving into the functional development phase, the organization should identify and staff the remaining TSO roles, e.g. roles that relate to helpdesk work and other such support providing work.

Functional development

The next phase is the functional development phase, where it is all about change management and testing. This phase is depicted below.

Address change management

The next challenge for an organization is all about change management / change control, which means to develop a planned approach to the changes the organization faces. The objective here is to maximize the collective efforts of all people involved in the change and to minimize the risk of failure of implementing the changes related to the SAP implementation.

The implementation of SAP software will most surely come with many changes and an organization can expect many natural reactions, i.e. denial, to these changes. To fight this, it is most important to create a solid project team dedicated to change management and to communicate the solution vision and goals of this team. This team should be prepared to handle the many change issues that come from various sources like:

• End-user requests
• Operations
• Data center team
• DBA group
• Systems management

SAP systems and operations management

Next thing is to create a foundation for the SAP systems management and SAP computer operations, by creating a SAP operations manual and by evaluating SAP management applications. The manual is a collection of current state system documentation, day-to-day and other regularly scheduled operations tasks, various installation and operations checklists and how-to process documents.

Functional, integration and regression testing

Testing is very important before going live with any system. Before going live with a SAP system, it is vital to do many different kinds of testing, since there is often a large, complex infrastructure of hardware and software involved. Both requirements as well as quality parameters are to be tested. Important types of testing are:

• Functional testing: to test using functional use cases, i.e. a set of conditions or variables under which a tester will determine if a certain business process works
• Integration testing
• Regression testing

All tests should be preceded by creating solid test plans.

Final preparation

The last phase before going live can be referred to as the final preparation phase and is depicted below.

Systems and stress testing

Another vital preparation activity before going live with SAP is systems and stress testing. This means planning, scripting, executing and monitoring system and stress tests, to see if the expectations of the end users, defined in service level agreements, will be met. This can be done with SAP’s standard application benchmarks, to benchmark the organization’s configurations against configurations that have been tested by SAP’s hardware technology partners. Again, a test plan should be created at first.

Prepare for cutover

The final phase before going live with SAP is often referred to as the cutover phase, which is the process of transitioning from one system to a new one. The organization needs to plan, prepare and execute the cutover, by creating a cutover plan that describes all cutover tasks that have to be performed before the actual go-live. Examples of cutover tasks are:

• Review and update all systems-related operations procedures like backup policies and system monitoring
• Assign ownership of SAP’s functional processes to individuals
• Let SAP AG do a GoingLive check, to get their blessing to go live with the system
• Lock down the system, i.e. do not make any more changes to the SAP system

Go Live

All of the previously described phases all lead towards this final moment: the go-live. Go-live means to turn on the SAP system for the end-users and to obtain feedback on the solution and to monitor the solution. It is also the moment where product software adoption comes into play. More information on this topic:

• Product Software Adoption: Big Bang Adoption
• Product Software Adoption: Parallel Adoption
• Product Software Adoption: Phased Adoption

Critical success factors

In order to successfully implement SAP in an organization, there are several things that are of great importance:

1) Choose the correct SAP Consultants to have the correct blueprint. An SAP Consultant is a professional who has the skills to speak to the managers of a company and help them creating the blueprint. For this the SAP Consultant has the business skills of the business area he/she is working with, and also masters this area on SAP. For example, if this is SAP FI (accountancy) Consultant, this person is an expert on accountancy and payments, gained through experience or by the corresponding studies at the University. Also this person knows SAP FI because has gained by the corresponding training, or the course on the SAP Partner Academy or similar. Benefits: As this person knows about Accountancy he or she will understand the needs of the business and will bring it into reality. Screening Methods to Find the Right SAP Consultant

2) SAP R/3 implementation is not an IT project, in fact is an Organization Project impacting all levels of a company. So it is very important to get the support from all the people that are involved in implementing SAP, but more important the participation and commitment of all levels, specially managers, of the company.

3) The Blueprint is the keystone used as the lighthouse who must guide the whole project. A blueprint should never be a merely mapping of IT systems. In fact a blueprint is bringing the strategy of a company into execution through defining its processes across all business areas. Many projects have failed because the focus was on having people with SAP knowledge, but with no business skills and so defining something that works...wrongly. Just remember, processes must change across time, and a manual error automated could be repeated infinitely.

4) Always consider changing the way things have been done before implementing SAP. "This has always been done like this and the Consultant should replicate it on SAP" is the start of a big problem. SAP many times could save you time and money as it allows your organization to automate many processes.

5) Test the SAP hardware and software rigorously by testing your business processes, and to ensure that the end-users are ready to use SAP before going live, because there are many known projects that failed because of a lack of support and SAP knowledge.

6) Design and execute a Change Management Program by communicating as early as needed all the information that end users should have to accept the new technology and designing and executing a training plan in order to reassure a knowledge base within the organization

SAP NetWeaver Process Integration

SAP NetWeaver Process Integration (SAP PI) is SAP's enterprise application integration (EAI) software, a component of the NetWeaver product group used to facilitate the exchange of information among a company's internal software and systems and those of external parties. Before the current version, SAP PI was called SAP Exchange Infrastructure (SAP XI). Like other NetWeaver components, SAP PI is compatible with software products of other companies.

SAP calls PI an integration broker because it mediates between entities with varying requirements in terms of connectivity, format, and protocols. According to SAP, PI reduces the TCO by providing a common repository for interfaces. The central component of SAP PI is the SAP Integration Server, which facilitates interaction between diverse operating systems and applications across internal and external networked computer systems.

PI is built upon the SAP Web Application Server.

First release of SAP Exchange Infrastructure was XI 2.0. Later on, releases 3.0, 7.0 and 7.1 followed. From release 7.0 onwards, SAP Exchange Infrastructure has been renamed as SAP Process Integration (SAP PI).

SAP NetWeaver

SAP NetWeaver is SAP's integrated technology platform and is the technical foundation for all SAP applications since the SAP Business Suite. SAP NetWeaver is marketed as a service-oriented application and integration platform. SAP NetWeaver provides the development and runtime environment for SAP applications and can be used for custom development and integration with other applications and systems. SAP NetWeaver is built using open standards and industry de facto standards and can be extended with, and interoperate with, technologies such as Microsoft .NET, Sun Java EE, and IBM WebSphere.

SAP NetWeaver's release is considered as a strategic move by SAP for driving enterprises to run their business on a single, integrated platform that includes both applications and technology. Industry analysts refer to this type of integrated platform offering as an "applistructure" (applications + infrastructure). According to SAP, this approach is driven by industry's need to lower IT costs through an enterprise architecture that is at once (1) more flexible; (2) better integrated with applications; (3) built on open standards to ensure future interoperability and broad integration; and, (4) provided by a vendor that is financially viable for the long term.

SAP is fostering relationships with system integrators and independent software vendors, many of the latter becoming "Powered by SAP NetWeaver".

SAP NetWeaver is part of SAP's plan to transition to a more open, service-oriented architecture and to deliver the technical foundation of its applications on a single, integrated platform and common release cycle.

History

SAP announced first NetWeaver release, named Netweaver 2004, in January 2003, and it was made available in March 31, 2004.

NetWeaver 7.0, aka 2004s, was made available in October 24, 2005. .

Composition

NetWeaver is essentially the integrated stack of SAP technology products. The SAP Web Application Server (sometimes referred to as WebAS) is the runtime environment for the SAP applications—all of the mySAP Business Suite solutions (SRM, CRM, SCM, PLM, ERP) run on SAP WebAS.

Products

The core products that make up SAP NetWeaver include:

• SAP NetWeaver Application Server
• SAP NetWeaver Business Intelligence
• SAP NetWeaver Composition Environment (CE)
• SAP NetWeaver Enterprise Portal (EP)
• SAP NetWeaver Identity Management (IdM)
• SAP NetWeaver Master Data Management (MDM)
• SAP NetWeaver Mobile
• SAP NetWeaver Process Integration (PI)

SAP has also teamed with hardware vendors like HP, IBM, Fujitsu-Siemens, and Sun to deliver appliances (i.e., hardware + software) to simplify and enhance the deployment of NetWeaver components. Examples of these appliances include:

• BW Accelerator
• Enterprise Search

Development Tools

• ABAP Workbench (SE80)
• SAP NetWeaver Developer Studio (NWDS) based on Eclipse for most of the Java part of the technology (Web Dynpro for Java, JEE, Java Dictionary, Portal Applications etc.)
• SAP Netweaver Development Infrastructure (NWDI)
• Visual Composer

see also:

• Web Dynpro
• SAP Enterprise Portal Content Studio
• SAkP Composite Application Framework - an environment for designing and using composite applications

Features

• SOAP and Web Services
• Interoperability with Java EE
• Interoperability with .NET (Microsoft)
• Integration of Business Intelligence
• xApps
• Duet

Specifically, ERP is being extended by Business Process Management Systems (BPMs) and, as BPMs takes hold as the pre-dominant technical platform for new applications, expect to see radical changes to ERP architecture in the years ahead. Allen Davis, a NetWeaver xMII expert, has successfully used Six Sigma scenarios as information in real time from shop floor control systems and used in plant quality control lab experimental tests. The technology has been applied to a wide range of industries and applications.

SAP's Netweaver platform is still backwards-compatible with ABAP, SAP's custom development language.

ABAP

ABAP/4
Paradigm	Object-oriented, structured, imperative
Appeared in	1980s
Designed by	SAP AG
Typing discipline	Statc, strong, sakfe, nominative
Mkajor implementations	SAP R/2, SAP R/3
Influenced by	Objective-C, COBOL, Java
OS	Cross-platform
Website	https://www.sdn.sap.com/irj/sdn/abap

ABAP (Advanced Business Application Programming, originally Allgemeiner Berichts-Aufbereitungs-Prozessor, German for "general report creation processor"^]) is a very high level programming language created by the German software company SAP. It is currently positioned, alongside the more recently introduced Java, as the language for programming SAP's Web Application Server, part of its NetWeaver platform for building business applications. Its syntax is somewhat similar to COBOL.

ABAP Introduction

ABAP is one of the many application-specific fourth-generation languages (4GLs) first developed in the 1980s. It was originally the report language for SAP R/2, a platform that enabled large corporations to build mainframe business applications for materials management and financial and management accounting.

ABAP used to be an abbreviation of Allgemeiner Berichtsaufbereitungsprozessor, the German meaning of "generic report preparation processor", but was later renamed to Advanced Business Application Programming. ABAP was one of the first languages to include the concept of Logical Databases (LDBs), which provides a high level of abstraction from the basic database level(s).

The ABAP programming language was originally used by developers to develop the SAP R/3 platform. It was also intended to be used by SAP customers to enhance SAP applications – customers can develop custom reports and interfaces with ABAP programming. The language is fairly easy to learn for programmers but it is not a tool for direct use by non-programmers. Good programming skills, including knowledge of relational database design and preferably also of object-oriented concepts, are required to create ABAP programs.

ABAP remains the language for creating programs for the client-server R/3 system, which SAP first released in 1992. As computer hardware evolved through the 1990s, more and more of SAP's applications and systems were written in ABAP. By 2001, all but the most basic functions were written in ABAP. In 1999, SAP released an object-oriented extension to ABAP called ABAP Objects, along with R/3 release 4.6.

SAP's most recent development platform, NetWeaver, supports both ABAP and Java.

Where does the ABAP program run?

All ABAP programs reside inside the SAP database. They are not stored in separate external files like Java or C++ programs. In the database all ABAP code exists in two forms: source code, which can be viewed and edited with the ABAP Workbench tools, and generated code, a binary representation somewhat comparable with Java bytecode. ABAP programs execute under the control of the runtime system, which is part of the SAP kernel. The runtime system is responsible for processing ABAP statements, controlling the flow logic of screens and responding to events (such as a user clicking on a screen button). A key component of the ABAP runtime system is the Database Interface, which turns database-independent ABAP statements ("Open SQL") into statements understood by the underlying DBMS ("Native SQL"). The database interface handles all the communication with the relational database on behalf of ABAP programs; it also contains extra features such as buffering of frequently accessed data in the local memory of the application server.

SAP has three different layers as presentation layer (GUI), application layer (programs run on this) and data base layer where all data is stored and retrieved from user driven conditions, commands given by end user programmer through presentation layer.

SAP Basis

The ABAP language environment, including the syntax checking, code generation and runtime system, is part of the SAP Basis component. SAP Basis is the technological platform that supports the entire range of SAP applications, now typically implemented in the framework of the SAP Web Application Server. In that sense SAP Basis can be seen as the "operating system" on which SAP applications run. Like any operating system, SAP Basis contains both low-level services (for example memory management, database communication or servicing Web requests) and high-level tools for end users and administrators. These tools can be executables ("SAP kernel") running directly on the underlying operating system, transactions developed in ABAP, or Web-based interfaces.

SAP Basis also provides a layer of abstraction between the business applications and the operating system and database. This ensures that applications do not depend directly upon a specific server or database platform and can easily be ported from one platform to another.

SAP Basis currently runs on UNIX (AIX, HP-UX, Solaris, Linux), Microsoft Windows, i5/OS on IBM System i (formerly iSeries, AS/400) and z/OS on IBM System z (formerly zSeries, S/390). Supported databases are IBM DB2, Informix, MaxDB, Oracle and Microsoft SQL Server (support for Informix was discontinued in SAP Basis release 7.00).

SAP systems and landscapes

All SAP data exists and all SAP software runs in the context of an SAP system. A system consists of a central relational database and one or more application servers ("instances") accessing the data and programs in this database. An SAP system contains at least one instance but may contain more, mostly for reasons of sizing and performance. In a system with multiple instances, load balancing mechanisms ensure that the load is spread evenly over the available application servers.

Installations of the Web Application Server (landscapes) typically consist of three systems: one for development, one for testing and quality assurance, and one for production. The landscape may contain more systems, e.g. separate systems for unit testing and pre-production testing, or it may contain fewer, e.g. only development and production, without separate QA; nevertheless three is the most common configuration. ABAP programs are created and undergo first testing in the development system. Afterwards they are distributed to the other systems in the landscape. These actions take place under control of the Change and Transport System (CTS), which is responsible for concurrency control (e.g. preventing two developers from changing the same code at the same time), version management and deployment of programs on the QA and production systems.

The Web Application Server consists of three layers: the database layer, the application layer and the presentation layer. These layers may run on the same or on different physical machines. The database layer contains the relational database and the database software. The application layer contains the instance or instances of the system. All application processes, including the business transactions and the ABAP development, run on the application layer. The presentation layer handles the interaction with users of the system. Online access to ABAP application servers can go via a proprietary graphical interface, the SAPGUI, or via a Web browser.

Transactions

A transaction in SAP terminology is the execution of a program. The normal way of executing ABAP code in the SAP system is by entering a transaction code (for instance, SE80 is the code for the ABAP workbench). Transactions can be accessed via system-defined or user-specific, role-based menus. They can also be started by entering their transaction code (a mnemonic name of up to 20 characters) in the special command field, which is present in every SAP screen. Transactions can also be invoked programmatically by means of the ABAP statements CALL TRANSACTION and LEAVE TO TRANSACTION. Transaction codes can also be linked to screen elements or menu entries. Selecting such an element will start the transaction. The term "transaction" must not be misunderstood here: in the context just described, a transaction simply means calling and executing an ABAP program. In application programming, "transaction" often refers to an indivisible operation on data, which is either committed as a whole or undone (rolled back) as a whole. This concept exists in SAP but is there called a LUW (Logical Unit of Work). In the course of one transaction (program execution), there can be different LUWs.

There exists different kind of transactions:

Dialog transaction

These are the most common kind of transactions. The transaction code of a dialog transaction is linked to a Dynpro of an ABAP program. When the transaction is called, the respective program is loaded and the Dynpro is called. Therefore, a dialog transaction calls a Dynpro sequence rather than a program. Only during the execution of the Dynpro flow logic are the dialog modules of the ABAP program itself called. The program flow can differ from execution to execution. You can even assign different dialog transaction codes to one program.

Parameter transaction

In the definition of a parameter transaction code, a dialog transaction is linked with parameters. When you call a parameter transaction, the input fields of the initial Dynpro screen of the dialog transaction are filled with parameters. The display of the initial screen can be inhibited by specifying all mandatory input fields as parameters of the transaction.

Report transaction

A report transaction is the transaction code wrapping for starting the reporting process. The transaction code of a report transaction must be linked with the selection screen of an executable program. When you execute a report transaction, the runtime environment internally executes the ABAP statement SUBMIT—more to come on that.

Object Oriented transaction

A new kind of transaction as of release 6.10. The transaction code of an OO transaction is linked with a method of a local or global class. When the transaction is called, the corresponding program is loaded, for instance methods an object of the class is generated and the method is executed.

Types of ABAP programs

In ABAP, there are 7 different types of programs:

Include, executable, function module, module pool, subroutine, class, interface,

Report programs

Report programs follow a relatively simple programming model whereby a user optionally enters a set of parameters (e.g. a selection over a subset of data) and the program then uses the input parameters to produce a report in the form of an interactive list. The output from the report program is interactive because it is not a passive display; instead it enables the user, through ABAP language constructs, to obtain a more detailed view on specific data records via drill-down functions, or to invoke further processing through menu commands, for instance to sort the data in a different way or to filter the data according to selection criteria. This method of presenting reports has great advantages for users who must deal with large quantities of information and must also have the ability to examine this information in highly flexible ways, without being constrained by the rigid formatting or unmanageable size of "listing-like" reports. The ease with which such interactive reports can be developed is one of the most striking features of the ABAP language.
The term "report" is somewhat misleading in the sense that it is also possible to create report programs that modify the data in the underlying database instead of simply reading it.

SAP Online programs

Online programs (also called module pools) do not produce lists. These programs define more complex patterns of user interaction using a collection of screens. The term “screen” refers to the actual, physical image that the users sees. Each screen also has a “flow logic”; this refers to the ABAP code invoked by the screens, i.e. the logic that initializes screens, responds to a user’s requests and controls the sequence between the screens of a module pool. Each screen has its own Flow Logic, which is divided into a "PBO" (Process Before Output) and "PAI" (Process After Input) section. In SAP documentation the term “dynpro” (dynamic program) refers to the combination of the screen and its Flow Logic.
Online programs are not invoked directly by their name, but are associated with a transaction code. Users can then invoke them through customizable, role-dependent, transaction menus.

Apart from reports and online programs, it is also possible to develop sharable code units such as class libraries, function libraries and subroutine pools.

Transaction Code is se51

Subroutine pools

Subroutine pools, as the name implies, were created to contain collections of subroutines that can be called externally from other programs. Before release 6.10, this was the only way subroutine pools could be used. But besides subroutines, subroutine pools can also contain local classes and interfaces. As of release 6.10, you can connect transaction codes to methods. Therefore, you can now also call subroutine pools via transaction codes. This is the closest to a Java program you can get in ABAP: a subroutine pool with a class containing a method – say – main connected to a transaction code!

Function pools

Function pools, more commonly known as "function groups", are libraries of functions developed in ABAP. Functions differ from subroutines in that they are self-contained and do not belong to a specific program. ABAP functions accept as input any number of input parameters, return as output any number of output parameters, and raise exceptions if an error condition occurs.

Functions are invoked in ABAP programs by means of the CALL FUNCTION statement. A very important feature of ABAP is the ability to call function modules in another SAP system or in an external application using the RFC (Remote Function Call) mechanism. It is also possible to call functions asynchronously; the ABAP program then does not wait for the function to return but instead continues immediately, while the function executes in a separate context.

Type pools

Type pools are the precursors to general type definitions in the ABAP Dictionary. Before release 4.0, only elementary data types and flat structures could be defined in the ABAP Dictionary. All other types that should’ve been generally available had to be defined with TYPES in type pools. As of release 4.0, type pools were only necessary for constants. As of release 6.40, constants can be declared in the public sections of global classes and type pools can be replaced by global classes..

Class pools

Class pools serve as containers for exactly one global class. Besides the global class, they can contain global types and local classes/interfaces to be used in the global class. A class pool is loaded into memory by using one of its components. For example, a public method can be called from any ABAP program or via a transaction code connected to the method. You maintain class pools in the class builder.

Interface pools

Interface pools serve as containers for exactly one global interface—nothing more and nothing less. You use an interface pool by implementing its interface in classes and by creating reference variables with the type of its interface. You maintain interface pools in the class builder.

ABAP workbench

The ABAP Workbench contains different tools for editing Repository objects. These tools provide you with a wide range of assistance that covers the entire software development cycle. The most important tools for creating and editing Repository objects are:
ABAP Editor for writing and editing program code (Transaction:SE38 ABAP Editor)
ABAP Dictionary for processing database table definitions and retrieving global types(Transaction:SE11)
Menu Painter for designing the user interface (menu bar, standard toolbar, application toolbar, function key assignment)(Transaction:SE41)
Screen Painter for designing screens (dynamic programs) for user dialogs (Transaction:SE51)
Function Builder for displaying and processing function modules (routines with defined interfaces that are available throughout the system) (Transaction:SE37)
Class Builder for displaying and processing ABAP Objects classes(Transaction:SE24)

The ABAP dictionary

The ABAP Dictionary is a fully integrated data environment controlling facility. It contains all definitions for Domains, Data Elements, Structures, Tables, Views, Search Helps, Lock Objects, Matchcode Objects, The Table Maintenance Generator, and the Table Description Generator.

With these objects in its repository, the ABAP Dictionary:

• Enforces data integrity
• Manages data definitions without redundancy
• Is tightly integrated with the rest of the ABAP/4 Development Workbench.

Enforcing data integrity is the process of ensuring that data entered into the system is logical, complete, and consistent. When data integrity rules are defined in the ABAP/4 Dictionary, the system automatically prevents the entry of invalid data. Defining the data integrity rules at the dictionary level means they only have to be defined once, rather than in each program that accesses that data.

The following are examples of data lacking integrity:

• A date field with a month value of 13
• An order assigned to a customer number that doesn’t exist
• An order not assigned to a customer

Managing data definitions without redundancy is the process of linking similar information to the same data definition. For example, a customer database is likely to contain a customer’s ID number in several places. The ABAP Dictionary provides the capability of defining the characteristics of a customer ID number in only one place. That central definition then can be used for each instance of a customer ID number.

The ABAP Dictionary’s integration with the rest of the development environment enables ABAP programs to automatically recognize the names and characteristics of dictionary objects.

Additionally, the system provides easy navigation between development objects and dictionary definitions. For example, as a programmer, you can double-click on the name of a dictionary object in your program code, and the system will take you directly to the definition of that object in the ABAP/4 Dictionary.

When a dictionary object is changed, a program that references the changed object will automatically reference the new version the next time the program runs. Because ABAP is interpreted, it is not necessary to recompile programs that reference changed dictionary objects.

ABAP syntax

This brief description of the ABAP syntax begins inevitably with the ubiquitous "Hello World" program.

"Helloworld"

PROGRAM TEST.

WRITE 'Hello World'.

This example contains two statements, one on each line. The keywords are PROGRAM and WRITE. The program displays a list on the screen. In this case, the list consists of the line "Hello World".

Formatting rules

White space significance

ABAP has no format restrictions. You can enter statements in any format, so a statement can be indented, you can write several statements on one line, or spread a single statement over several lines. The only requirement is that every statement ends in a period.

You must separate words within a statement with at least one space. The system also interprets the end of line marker as a space.

The two-line "Hello World" program from above could also be written as

PROGRAM TEST. WRITE 'Hello World' .

or even as:

               PROGRAM 

               TEST.

                          WRITE

                          'Hello World'.

Free formatting is convenient, but with complex code, such as deeply nested IF/ELSE blocks, it can get tricky. The ABAP editor therefore offers a "Pretty Printer" function, which can take care of proper indentation.

One obvious exception to the free-formatting rule are text literals. A text literal is a sequence of alphanumeric characters in the program code enclosed in single quotes. If a text literal in an ABAP statement extends across more than one line, then a ‘&’ character must be used to combine a succession of text literals into a single one. Example:

USERPROMPT = 'Please double-click on a line in the output list ' &

             'to see the complete details of the transaction.'.

Case sensitivity

ABAP statements are not case-sensitive. The following code is perfectly permissible:

proGRAm TEsT.

WriTe 'Hello World'.

Users can configure the way source text is presented (all upper case, all lower case, ABAP keywords in upper case and variable names in lower case, etc.) according to their own preference. Typically the keywords are in upper case and everything else (variable, function, method, and class names) in lower case.

Chained statements

The ABAP programming language allows you to concatenate consecutive statements with an identical first part into a chain statement.

To concatenate a sequence of separate statements, write the identical part only once and place a colon (:) after it. After the colon, write the remaining parts of the individual statements, separating them with commas. Ensure that you place a period (.) after the last part to inform the system where the chain ends.

Chaining is very often used in WRITE statements. WRITE accepts just one argument, so if for instance you wanted to display three fields from a structure called FLIGHTINFO, you would have to code:

WRITE FLIGHTINFO-CITYFROM.

WRITE FLIGHTINFO-CITYTO.

WRITE FLIGHTINFO-AIRPTO.

Chaining the statements results in a more readable and more intuitive form:

WRITE: FLIGHTINFO-CITYFROM, FLIGHTINFO-CITYTO, FLIGHTINFO-AIRPTO.

In the chain, a colon separates the beginning of the statement from the variable parts. After the colon or commas, you can insert any number of spaces.

You could, for example, write the same statement like this:

WRITE:    FLIGHTINFO-CITYFROM,

          FLIGHTINFO-CITYTO,

          FLIGHTINFO-AIRPTO.

In a chain statement, the first part (before the colon) is not limited to the keyword of the statements. For example, the code

SUM = SUM + 1.

SUM = SUM + 2.

SUM = SUM + 3.

SUM = SUM + 4.

could be written in chained form:

SUM = SUM + : 1, 2, 3, 4.

Comments

ABAP has 2 ways of defining text as a comment.

An asterisk (*) in the leftmost column of a line makes that line a comment. A double quotation mark («"») anywhere on a line makes the rest of that line a comment.

Example

***************************************

** Program: BOOKINGS                 **

** Author: Joe Byte, 07-Jul-2007     **

***************************************

REPORT BOOKINGS.

* Read flight bookings from the database

SELECT * FROM FLIGHTINFO

  WHERE CLASS = 'Y'       "Y = economy

  OR    CLASS = 'C'.      "C = business

(...)

Naming notation

ABAP has a large number of naming conventions for different language elements. These are conventions and not rules, so an ABAP programmer is free to abide by them or not. However ABAP code developed by SAP itself generally respects these naming rules. Below is a list.

• ALV_* SAP List Viewer
• AS_* Methods that perform type conversions
• CHECK_* Check Methods
• CH_* Changing Parameters
• CT_* Changing Table
• CL_* Class name
• CO_*/C_* Constants
• DR_* Data reference
• G_* Global variables/data objects
• GT_* Global table
• GX_* Global boolean field (X or space)
• IF_* Interface
• INT_*/IT_ Internal Table
• IS_* Methods that return a Boolean value
• L_* Indicates the data object is local. Often, before underscore, put a 'type letter' in case of simple type (LC_,LF etc.)
• LC_* Local Constant
• LV_* Local Variable
• LR_* Local Range
• LT_* Local Table
• LS_* Local Structure
• LVC_* List Viewer Control
• ON_* Event handler
• PA_* Parameters
• PE_*/EX_* Export parameter
• PI_*/IM_* Input parameter
• RA_* Ranges/Type Range Of
• RE_* Result
• RF_* Reference Variable
• SET_* Accessors Methods
• SO_* Select-Options
• ST_* Structure
• TA_* Internal Standard Table
• TC_* Table Control
• TH_* Internal Hashed Table
• TP_* Other Variables
• TS_* Internal Sorted Table
• TT_* Table type
• TY_* Types
• T_* Variable is a table (T_MY_TABLE_VARIABLE)
• X* Source/first data object (e.g. XVBAK)
• Y* Destination/second data object (e.g. YVBAK)
• WA_* Work Area
• $* Static Variable
• ** Secondary working area (e.g. *VBAK in TABLES statement. Obsolete)

DATA and TYPES

It is a special strength of ABAP that you can define a great variety of data types and objects that span the spectrum from very elementary data types to very complex and dynamic types. Consequently, the subject of ABAP declarations is quite extensive.

ABAP accepts all data types defined in the SAP dictionary or in Type Pools. Types can also be defined inside the program itself. Object numeric (I for integer, F for floating point), packed decimal (P), character (C or N, where the N type is used for numeric strings that can be used in computation) or hexadecimal (X). Date fields (type D) and time fields (type T) have a "dual" nature; in an input/output context they behave like strings, but in a computational context they are numeric integers. There are no built-in functions or statements for dealing with dates and times; but, as in spreadsheets, arithmetic can be performed on a date-value to break it up. For example:

DATESENT = '20070901'.

VALIDTO = DATESENT + 60.

WRITE: 'Offer is valid until', VALIDTO DD/MM/YYYY.

In this example, a string literal representing September 1, 2007 is assigned to DATESENT. DATESENT is then used in a numeric calculation to produce another data field, VALIDTO, which is set to DATESENT plus 60 days. Finally, VALIDTO is output as a string. The optional "DD/MM/YYYY" modifier displays the date in a predefined format, here "31/10/2007". Without the modifier the date would display as "20071031".

All ABAP variables must be explicitly declared in order to be used. The convention is for all declarations to be at the top of the program, or subroutine. The declaration consists of the name, type, length (where applicable), additional modifiers (e.g. the number of implied decimals for a packed decimal field) and optionally an initial value:

* Primitive types:

DATA: COUNTER      TYPE I,

      VALIDITY     TYPE I VALUE 60,

      TAXRATE(3)   TYPE P DECIMALS 1,

      LASTNAME(20) TYPE C.

* Dictionary types:

DATA: ORIGIN       TYPE COUNTRY.

* Internal table:

DATA: T_FLIGHTS    TYPE TABLE OF FLIGHTINFO,

      T_LOOKUP     TYPE HASHED TABLE OF FLT_LOOKUP.

* Objects:

DATA: BOOKING      TYPE REF TO CL_FLT_BOOKING.

Notice the use of the colon to chain together consecutive DATA statements.

ABAP Objects

The ABAP language supports object-oriented programming, through a feature known as "ABAP Objects". This helps to simplify applications and make them more controllable.

ABAP Objects is fully compatible with the existing language, so one can use existing statements and modularization units in programs that use ABAP Objects, and can also use ABAP Objects in existing ABAP programs. Syntax checking is stronger in ABAP Objects programs, and some syntactical forms (usually older ones) of certain statements are not permitted.

ABAP statements – an overview

The first element of an ABAP statement is the ABAP keyword. This determines the category of the statement. The different statement categories are as follows:

Declarative statements

These statements define data types or declare data objects which are used by the other statements in a program or routine. The collected declarative statements in a program or routine make up its declaration part.

Examples of declarative keywords:

TYPES, DATA, TABLES

Modularization statements

These statements define the processing blocks in an ABAP program.

The modularization keywords can be further divided into:

· Event Keywords

You use statements containing these keywords to define event blocks. There are no special statements to conclude processing blocks - they end when the next processing block is introduced.

Examples of event keywords are:

AT SELECTION SCREEN, START-OF-SELECTION, AT USER-COMMAND

· Defining keywords

You use statements containing these keywords to define subroutines, function modules, dialog modules and methods. You conclude these processing blocks using the END- statements.

Examples of definitive keywords:

FORM ..... ENDFORM, FUNCTION ... ENDFUNCTION, MODULE ... ENDMODULE.

Control statements

You use these statements to control the flow of an ABAP program within a processing block according to certain conditions.

Examples of control keywords:

IF, WHILE, CASE

Call statements

You use these statements to call processing blocks that you have already defined using modularization statements. The blocks you call can either be in the same ABAP program or in a different program.

Examples of call keywords:

CALL METHOD, CALL TRANSACTION, SUBMIT, LEAVE TO

Operational statements

These keywords process the data that you have defined using declarative statements.

Examples of operational keywords:

MOVE, ADD

Concept of internal table in ABAP

Internal tables provide a means of taking data from a fixed structure and storing it in working memory in ABAP. The data is stored line by line in memory, and each line has the same structure. In ABAP, internal tables fulfill the function of arrays. Since they are dynamic data objects, the programmer is saved the task of dynamic memory management in his or her programs. Internal tables should be used whenever there is a need to process a dataset with a fixed structure within a program. A particularly important use for internal tables is for storing and formatting data from a database table within a program. They are also a good way of including very complicated data structures in an ABAP program.

Like all elements in the ABAP type concept, internal tables can exist both as data types and as data objects. A data type is the abstract description of an internal table, either in a program or centrally in the ABAP Dictionary, that you use to create a concrete data object. The data type is also an attribute of an existing data object.

Internal tables as data types

Internal tables and structures are the two structured data types in ABAP. The data type of an internal table is fully specified by its line type, key, and table type.

Line type

The line type of an internal table can be any data type. The data type of an internal table is normally a structure. Each component of the structure is a column in the internal table. However, the line type may also be elementary or another internal table.

Line Type can also refer to an ABAP Object's reference pointer value. If two ABAP Objects are not related, they do not have the same line type. The line type is stored in the value of the reference pointer and can be viewed in the debugger. If one object attempts to access another unrelated object's components, you will receive an error specifying that the line types do not match.

Key

The key identifies table rows. There are two kinds of key for internal tables - the standard key and a user-defined key. You can specify whether the key is UNIQUE or NON-UNIQUE. Internal tables with a unique key cannot contain duplicate entries with the same key. The uniqueness depends on the table access method.

If a table has a structured line type, its default key consists of all of its non-numerical columns that are not references or themselves internal tables. If a table has an elementary line type, the default key is the entire line. An internal table which has a line type that is itself an internal table, has an empty key.

The user-defined key can contain any columns of the internal table that are not references or themselves internal tables. Internal tables with a user-defined key are called key tables. When you define the key, the sequence of the key fields is significant. You should remember this, for example, if you intend to sort the table according to the key.

Later versions of ABAP permit the definition of secondary keys. hi

Table type

The table type determines how will access individual table entries. Internal tables can be divided into three types:

Standard tables have an internal linear index. (Think of index as "record number". It is not to be confused with a database index, for example). From a particular size upwards, the indexes of internal tables are administered as trees. In this case, the index administration overhead increases in logarithmic and not linear relation to the number of lines. The system can access records either by using the table index or the key. The response time for key access is proportional to the number of entries in the table. The key of a standard table is always non-unique. You cannot specify a unique key. This means that standard tables can always be filled very quickly, since the system does not have to check whether there are already existing entries.

Sorted tables are always saved sorted by the key. They also have an internal index. The system can access records either by using the table index or the key. The response time for key access is logarithmically proportional to the number of table entries, since the system uses a binary search. The key of a sorted table can be either unique or non-unique. When you define the table, you must specify whether the key is to be unique or not. Standard tables and sorted tables are known generically as index tables.

Hashed tables have no linear index. You can only access a hashed table using its key. The response time is independent of the number of table entries, and is constant, since the system access the table entries using a hash algorithm. The key of a hashed table must be unique. When you define the table, you must specify the key as UNIQUE.

Generic internal tables

Unlike other local data types in programs, you do not have to specify the data type of an internal table fully. Instead, you can specify a generic construction, that is, the key or key and line type of an internal table data type may remain unspecified. You can use generic internal tables to specify the types of field symbols and the interface parameters of procedures. You cannot use them to declare data objects.

Internal tables as dynamic data objects

Data objects that are defined either with the data type of an internal table, or directly as an internal table, are always fully defined in respect of their line type, key and access method. However, the number of lines is not fixed. Thus internal tables are dynamic data objects, since they can contain any number of lines of a particular type. The only restriction on the number of lines an internal table may contain are the limits of your system installation. The maximum memory that can be occupied by an internal table (including its internal administration) is 2 gigabytes. A more realistic figure is up to 500 megabytes. An additional restriction for hashed tables is that they may not contain more than 2 million entries. The line types of internal tables can be any ABAP data types - elementary, structured, or internal tables. The individual lines of an internal table are called table lines or table entries. Each component of a structured line is called a column in the internal table.

Choosing a table type

The table type (and particularly the access method) that you will use depends on how the typical internal table operations will be most frequently executed.

Standard tables

This is the most appropriate type if you are going to address the individual table entries using the index. Index access is the quickest possible access. You should fill a standard table by appending lines (ABAP APPEND statement), and read, modify and delete entries by specifying the index (INDEX option with the relevant ABAP command). The access time for a standard table increases in a linear relationship with the number of table entries. If you need key access, standard tables are particularly useful if you can fill and process the table in separate steps. For example, you could fill the table by appending entries, and then sort it. If you use the binary search option with key access, the response time is logarithmically proportional to the number of table entries.

Sorted tables

This is the most appropriate type if you need a table which is sorted as you fill it. You fill sorted tables using the INSERT statement. Entries are inserted according to the sort sequence defined through the table key. Any illegal entries are recognized as soon as you try to add them to the table

Hashed tables

This is the most appropriate type for any table where the main operation is key access. You cannot access a hashed table using its index. The response time for key access remains constant, regardless of the number of table entries. Like database tables, hashed tables always have a unique key. Hashed tables are useful if you want to construct and use an internal table which resembles a database table or for processing large amounts of data..

Advanced topics

Batch input: concepts

Processing sessions

A batch input session is a set of one or more calls to transactions along with the data to be processed by the transactions. The system normally executes the transactions in a session non-interactively, allowing rapid entry of bulk data into an R/3 System.

A session records transactions and data in a special format that can be interpreted by the R/3 System. When the System reads a session, it uses the data in the session to simulate on-line entry of transactions and data. The System can call transactions and enter data using most of the facilities that are available to interactive users.

For example, the data that a session enters into transaction screens is subject to the same consistency checking as in normal interactive operation. Further, batch input sessions are subject to the user-based authorization checking that is performed by the system.

There are three batch input methods:

(1) In the Direct Input Method, the programs are provided by the SAP system. These programs are available for Standard Applications. Under this method, the data base is updated using a Function Module, which is responsible for executing the appropriate consistency checks.

(2) In the Call Transaction Method, the ABAP Program reads the external data which is present on the Application or Presentation Server, and uses the ABAP Statement CALL TRANSACTION USING to run a SAP statement.

(3) In the Session Method the program reads the data and the SAP system stores the data in a "Batch Input Session". The session records the actions that are required to transfer data into the system using normal SAP transactions.

Other Features

ABAP Objects ABAP uses an object-oriented interfaces.

Sharing Data: With ABAP shared objects, you can aggregate data in memory once at a central location. Different users and programs can then access this data without the need for copying.

Exception Handling: With the class-based exception concept of ABAP, you can define a special control flow for a specific error situation and provide the user with information about the error.

Developing Persistency: For permanent storage of data in ABAP, you use relational database tables by means of database-independent Open SQL, which is integrated in ABAP. However, you can also store selected objects transparently or access the integrated database or other databases using proprietary SQL.

Connectivity and Interoperability: The Exchange Infrastructure and Web services are the means by which developers can implement a service-oriented architecture. With Web services, you can provide and consume services independently of implementation or protocol. Furthermore, you can do so within NetWeaver and in the communication with other systems. With the features of the Exchange Infrastructure, you can enable, manage, and adapt integration scenarios between systems.

Making Enhancements: With the Enhancement Framework, you can enhance programs, function modules, and global classes without modification as well as replace existing code. The Switch Framework enables you activate only specific development objects or enhancements in a system.