Sap Abap Material Learning From Ground Up

SAP ABAP MATERIAL

Bangalore

1

Introduction to ERP (Enterprise resource planning) There are many different systems in a large company's including planning, manufacturing, distribution, shipping, and accounting. Enterprise resource planning (ERP) is a system that integrates all of these functions into a single system, designed to serve the needs of each different department within the enterprise. ERP is more of a methodology than a piece of software, although it does incorporate several software applications, brought together under a single, integrated interface. Enterprise resource planning (ERP) systems integrate primary business applications; all the applications in an ERP suite share a common set of data that is stored in a central database. A typical ERP system provides applications for accounting and controlling, production and materials management, quality management, plant maintenance, sales and distribution, human resources, and project management. Why should you be interested? Because, basically, a well-implemented and appropriate ERP system can create significant efficiencies across your business, resulting in timely business information, better customer relationships, a more cost-effective supply chain, improved internal process and, ultimately, increased profitability. The ERP system goes far beyond being just a simple piece of software. Each implementation is unique and is designed to correspond to the implementer's various business processes. Regardless of how a company approaches it, ERP is sure to bring significant changes to how a company does business. An ERP implementation can cost millions of dollars to create, and may take several years to complete. Once implemented however, the ERP system brings tremendous advantages. Because all systems are joined together, all departments can more easily share information. The workflow that takes place between departments can become much more automated, and

Bangalore

2

ultimately, customers are better served because the individual using the customer-facing applications will have access to every bit of information regarding each relevant process. For example, someone in sales would easily be able to log into a single system to determine the status of a customer order that is still in manufacturing. All this comes at a cost though; training costs are high because employees must not only learn how to use new software, they must also learn new processes.

ERP Improves Productivity Before ERP systems, each department in an organization would most likely have their own computer system, data and database. Unfortunately, many of these systems would not be able to communicate with one another or need to store or rewrite data to make it possible for cross computer system communication. For instance, the financials of a company were on a separate computer system than the HR system, making it more intensive and complicated to process certain functions. Once an ERP system is in place, usually all aspects of an organization can work in harmony instead of every single system needing to be compatible with each other. For large organizations, increased productivity and less types of software are a result. Implementing Enterprise Resource Planning ERP software is complex and expensive. Companies must devote significant human resources to ERP projects and often hire consultants or systems integrators to help implement the systems. As a result, the company can spend millions of dollars and several years on ERP projects. This report outlines the challenges companies should expect for ERP implementation and outlines the six main steps of an ERP project:      

Vendor Selection Business Strategy Formation Application Configuration Testing and End-user Acceptance Training Rollout

Benefits of implementing ERP systems:    

Inventory Reduction Improved Cash Management Increased Revenue and Profits Reduced Transportation and Logistics Costs

Bangalore

3



Reduced Information Technology (IT) Costs

Intangible benefits include unanticipated cost reductions, improved responsiveness to customers, more flexibility, and more effective management of the supply chain. Advantages of ERP Systems There are many advantages of implementing an EPR system; here are a few of them:       

A totally integrated system The ability to streamline different processes and workflows The ability to easily share data across various departments in an organization Improved efficiency and productivity levels Better tracking and forecasting Lower costs Improved customer service

Disadvantages of ERP Systems While advantages usually outweigh disadvantages for most organizations implementing an ERP system, here are some of the most common obstacles experienced: Usually many obstacles can be prevented if adequate investment is made and adequate training is involved, however, success does depend on skills and the experience of the workforce to quickly adapt to the new system.     

Customization in many situations is limited The need to reengineer business processes ERP systems can be cost prohibitive to install and run Technical support can be shoddy ERP's may be too rigid for specific organizations that are either new or want to move in a new direction in the near future.

ERP software packages Available in the Market Baan from Infor Global Solutions: The Baan Corporation provides the financial and administrative consulting services. JD Edwards Enterprise One & JD Edwards World from Oracle: JD Edward is into accounting business software development and an ERP system JDE comprises 3 basic areas of expertise, functional-business, and programmer-developer and technical-CNCsystem administration. Oracle e-Business Suite from Oracle : Oracle is into finance applications and Oracle relational database management system technology Bangalore

4

PeopleSoft from Oracle: PeopleSoft is into Human resource management systems (HRMS) applications SAP R/3 from SAP: The most widely used modules in this ERP are Financials and Controlling (FICO), Human Resources (HR), Materials Management (MM), Sales & Distribution (SD), and Production Planning (PP) and it’s an integration around 25 modules. It’s the biggest ERP package in the Market. Many more ERP packages are available in the market. Enterprise:-Organization or Business oriented company. Resource: - Man, Money, Machines and materials etc. Planning:-Plans to maximum utilization of resources with cost minimization. The ultimate aim of using ERP is planning with the available resources of an enterprise to get the maximum output with cost minimization.

What is SAP SAP was founded in 1972 by five former IBM engineers in Mannheim, Germany (Dietmar Hopp, Hasso Plattner, Klaus Tschira, Claus Wellenreuther and Hans-Werner Hector) and its headquarters in Walldorf German and since the 2005 annual general meeting the company’s official name is just SAP AG. The acronym of SAP is “Systems, Applications and Products in Data Processing" SAP is the largest software company in Europe and the third largest in the world. It ranks after Microsoft and IBM in terms of market capitalization. SAP is also the largest business application and Enterprise Resource Planning (ERP) solution and software provider in terms of revenue. Products SAP's products focus on Enterprise resource planning (ERP), which it helped to pioneer. The company's main product is mySAP ERP. The name of its predecessor, SAP R/3 gives a clue to its functionality: the "R" stands for realtime data processing and the number 3 relates to a 3-tier architecture: database, application server and client (SAPgui). R/2, which ran on Mainframe architecture, was the first SAP version. Other major product offerings include Advanced Planner and Optimizer (APO), Business Information Warehouse (BW), Customer Relationship Management (CRM), Supply Chain Management (SCM), Supplier Relationship Management (SRM), Human Resource Management Systems (HRMS), Product Lifecycle Management (PLM), Exchange Infrastructure (XI), Enterprise Portal (EP) and SAP Knowledge Warehouse (KW).The APO name has been retired and rolled into SCM. The BW name (Business Warehouse) Bangalore

5

has now been rolled into the SAP NetWeaver BI (Business Intelligence) suite and functions as the reporting modules. The company also offers a new technology platform, named SAP NetWeaver. While its original products are typically used by Fortune 500 companies, SAP is now also actively targeting small and medium sized enterprises (SME) with its SAP Business One and SAP All-in-One.According to SAP AG there are over 100,800 SAP installations serving more than 38,000 companies. SAP products are used by over 12 million people in more than 120 countries. 1. The name SAP is acronym for Systems, Applications and Products in Data Processing. SAP is an extremely complicated system where no one individual can understand all of it. 2. SAP runs on a fourth generation programming language language called Advance Business Application Programming (ABAP). It have many of the features of other modern programming languages such as the familiar C, Visual Basic, and Power Builder. Your programs name conventions begins with a letter yxxx or zxxx. 3. SAP graphical user interfaces (SAPGUI) runs on Windows / NT / Unix / AS400. 4. SAP is an enterprise resource planning (ERP) software product capable of integrating multiple business applications, with each application representing a specific business area. These applications update and process transactions in real time mode. It has the ability to be configured to meets the needs of the business. SAP R/3 is a client/server based application, utilizing a 3-tiered model. A presentation layer, or client, interfaces with the user. The application layer houses all the businessspecific logic, and the database layer records and stores all the information about the system, including transactional and configuration data. SAP R/3 functionality is structured using its own proprietary language called ABAP (Advanced Business Application Programming). ABAP, or ABAP/4 is a fourth generation language (4GL), geared towards the creation of simple, yet powerful programs. R/3 also offers a complete development environment where developers can either modify existing SAP code to modify existing functionality or develop their own functions, whether reports or complete transactional systems within the SAP framework. ABAP's main interaction with the database system is via Open SQL statements. These statements allow a developer to query, update, or delete information from the database. Advanced topics include GUI development and advanced integration with other systems. With the introduction of ABAP Objects, ABAP provides the opportunity to develop applications with object-oriented programming. The most difficult part of SAP R/3 is its implementation, since SAP R/3 is never used the same way in any two places. For instance, Atlas Copco can have a different Bangalore

6

implementation of SAP R/3 from Procter & Gamble. Some companies may run multiple productive clients/systems or even multiple instances of SAP R/3. This is seen, for example, when a company running R/3 acquires a new business already running R/3. They may elect to keep both systems separate, migrate one into the other, or migrate both onto a completely new instance. The system landscape is ultimately the customer's decision. There are definite pros and cons on the continuum from single global instance / productive client (master data, impact of configuration changes on multiple business units) to separate instances per business unit (hardware costs and communication between instances/clients) Two primary issues are the root of the complexity and of the differences: 



Customization configuration - Within R/3, there are tens of thousands of database tables that may be used to control how the application behaves. For instance, each company will have its own accounting "Chart of Accounts" which reflects how its transactions flow together to represent its activity. That will be specific to a given company. In general, the behavior (and appearance) of virtually every screen and transaction is controlled by configuration tables. This gives the implementer great power to make the application behave differently for different environments. With that power comes considerable complexity. Extensions, Bolt-Ons - In any company, there will be a need to develop interface programs to communicate with other corporate information systems. This generally involves developing ABAP/4 code, and considerable "systems integration" effort to either determine what data is to be drawn out of R/3 or to interface into R/3 to load data into the system.

Due to the complexity of implementation, these companies recruit highly skilled SAP consultants to do the job. The implementation must consider the company's needs and resources. Some companies implement only a few modules of SAP while others may want numerous modules. SAP has several layers. The Basis System (BC) includes the ABAP programming language, and is the heart (i.e. the base) of operations and should not be visible to higher level or managerial users. Other customizing and implementation tools exist also.

Implementation Tools There are multiple tools available to assist in the management of ERP implementation projects. SAP R/3, for example, provides an Implementation Roadmap that is broken up into five phases. Each phase includes documentation and planning tools to help the phase move towards completion. The five phases and their respective tasks include: 

Project Preparation

Bangalore

7

o o o o 

Business Blueprint o

o 

o

Configuration of the ERP system occurs in this phase. Configuration guidelines are based on documentation from the Business Blueprint phase. Legacy system connections are developed in this phase.

Final Preparation o o o o o



In this phase project team members decide and document how the business and business processes will function with the implementation of the ERP system. These decisions will guide the configuration of the ERP. Determination of methods to transfer or integrate legacy system information into the ERP system will also occur in this phase.

Realization o



Building of the project team. Designing the system (This includes network, hardware, and software requirements). Selecting ERP vendors. Defining the project’s scope.

Testing of the new ERP system. Development of the Help Desk and Help Desk Procedures. Migration of existing data. User training. Schedule a Roll-Out date.

Roll-Out o o o o

ERP system becomes part of everyday activities. Help Desk fields questions about ERP system. Monitoring of the ERP system starts in this phase. Monitoring of the ERP system starts in this phase.

The time required for each one of these phases differs from project to project based on the size of the implementation, dedication to the project…etc. Oftentimes the finished project’s scope differs from the original scope’s documentation causing projects to go overtime and over budget. When this happens, it is usually testing and training that get cut short which jeopardize the overall success of the project.

Why SAP 1. SAP is a platform independent; it can support various databases like Oracle, SQL Server. 2. SAP also supports various operating systems. 3. The integrity between its various modules makes SAP more users friendly.

Bangalore

8

Areas of SAP There are three areas in SAP. 1. Functional Area There are more than 25 functional modules in SAP. Those who work on functional areas are called Functional Consultants. Ex: - PP – Production planning MM- material management SD- Sales and Distribution FI- Financial Accounting CO- Controlling HR- human Resources PM- Plant Maintenance. Etc. 2. Technical Area Here the technical consultants i.e. ABAPers are working. Technical Consultants will implant the ideas of functional Consultants. 3. Basis Area Here the basis people will work. The following works are generally done here Creation users, Authorization, Dispatcher and Role Allocation

R/3 System Architecture R/3 is an integrated group of applications designed to handle the data processing for large corporations. The purpose of an R/3 system is to provide tightly integrated large scale business applications. The below figure shows the structure of R/3 Architecture. The architecture contains four layers as Presentation Servers, Application Servers, Database Servers and Database.

Bangalore

9

PS

PS

AS

AS

DBS

DB PS: - Presentation Servers AS: - Application Servers DBS: - Database Server DB: - Database Presentation Servers - The Presentation server is actually a SAPGUI or the user interface. The interface accepts input from the user in the form of keystrokes, mouse clicks and function keys, sends these requests to the application server to be processed. The application server sends the results back to the SAPGUI which then formats the output display to the user. Application Server – The application server is a set of executables that collectively interpret the ABAP/4 programs and manage the input and output for them. When an application server is started, these executables all start at the same time. When an application server is stopped, they all shut down together. Each application server has a profile that specifies its characteristics when it starts up and while it is running. For example, an application severs profile specifies:   

Number of processes and their types Amount of memory each process may use Length of time a user is inactive before being automatically logged off

The application server exists to interpret ABAP/4 programs, and they only run there-the programs do not run on the presentation server. If your ABAP/4 program requests

Bangalore

10

information from the database, the application server will format the request and send it to the database server.

Database Server - The database server is a set of executables that accept database requests from the application server. These requests are passed on to the RDBMS (Relation Database Management System). The RDBMS sends the data back to the database server, which then passes the information back to the application server. The application server in turn passes that information to your ABAP/4 program and then you will get the required output on your presentation server. Database – Database is nothing but a collection of data arranged for ease and speed of search and retrieval OR A database is a structured collection of records or data that is stored in a computer system.

Application Server Architecture Application Server

From Presentation Servers

Dispatcher

Queue

Work Processes WP

WP

WP

WP

Buffers Roll Area (Extended Memory)

To Database Server

All requests that come in from presentation servers are directed first to the dispatcher. The dispatcher writes them first to the dispatcher queue. The dispatcher pulls the requests from the queue on a first-in, first-out basis. Each request is then allocated to the first available work process. A work process handles one request at a time.

Bangalore

11

To perform any processing for a user's request, a work process needs to address two special memory areas: the user context and the program roll area. The user context is a memory area that contains information about the user, and the roll area is a memory area that contains information about the programs execution.

USER Context A user context is contains information about the user like about user name, login id and which program is running currently. Roll Area. It’s a memory allocated by the work process for an instance of a program It contains information about the recent program which is executing currently Value of variables, Dynamic Memory Allocation and Pointers to work Process. Instance: - The term instance means application server The term central instance means database server In general the term instance means server. Roll In: - When a job is assigned to a work process it creates pointers to the user context and roll area this process is called Roll In. Roll Out: - After the execution of the job the pointers assigned to both user context and roll area are deleted this process is called Roll Out. Dialog Steps: - This is the time taken by the systems to show the next screen from existing screen is called as dialog step. Work process This is the area in which actual work is done. There are seven types of work process each handles a specific type request. 1. 2. 3. 4. 5. 6.

Dialog or Online Process- for Dialog request. Update Process- Request to update data in database. Background Process- Background jobs. Spool Process- print spool request. Enque Process – Logical lock requests Message Process- Routes messages between application server with in an R/3 system 7. Gateway Process- Funnels Messages into and out of the R/3 system. Components of Work Process

Bangalore

12

Each Work Process is composed of the following 1. A task handler 2. An ABAP/4 Interpreter 3. A screen Interpreter. 4. A Database Interface All requests pass through the task handler, which then funnels the request to the appropriate part of the work process and the Interpreters Interpret the ABAP/4 code. Messages (6 types) 1. 2. 3. 4. 5. 6.

S (Success): Green color status bar. E (Error): Red color status bar. W (Warning): Yellow color status bar. I (Information): In a pop-up box. A (Abort): In a pop-up box. X (Exit): Comes out of the program

Three tier architecture of R/3 Database Server Application Server Presentation Server (Unlike normal Client/server architecture where you have only two layers i.e., client and server.) Communication among the 3 tiers is accomplished by standard protocol services like TCP/IP or CPIC (Common Programming Interface Communication).

Database Server

Application

Application

Server

Server

Application Server

Presentation

Presentation

Presentation

Presentation

Presentation

Presentation

Server

Server

Server

Server

Server

Server

Bangalore

13

In above case database server stores the data centrally. Basically contains database engine and associated processes. The database layers contain the database system used by all servers. Application server contains software components to run the program. It contains a SAP kernel, which can run ABAP/4 program. The presentation server is your client through which you send your request to application server. It is also called as SAP graphical user interfaces known as SAPGUI and is available in windows 3.1, Windows NT, Windows 95, and Macintosh. They all look similar whatever underlying system they are running on. The SAPGUI includes all graphical capabilities of window interface with menu bars, tool bars, focus property, and the entire mouse clicking operations. The R/3 system is open system in the sense that it can run on any operating system or any database and any communication technology. It means that:  R/3 system can run on any operating system platform such as UNIX, NT, 95, AS/400.  It supports various RDBMS such as SQL server, Oracle, Informix, DB2.  Standard GUIs supported by R/3 are Windows 95, NT, Windows 3.1, and Macintosh.  SAP can use standard communication protocols TCP/IP, CPIC, OSF/DCE/DME for network. Using SAP’s Open SQL ABAP/4 code is portable between databases. To access the database in an ABAP/4 program you will code SAP’s open SQL. Open SQL is a subset and variation of ANSI SQL. The ABAP/4 Interpreter passes all open SQL statements to the database interface part of the work process. There they are converted to SQL i.e. native to the installed RDBMS. For example if you were running an Oracle database your ABAP/4 Open SQL would be converted by the database interface to Oracle SQL statements. If you use Open SQL, your SQL statements will be passed to the database interface. Using Open SQL has three advantages. All of these advantages are implemented via database interface. Advantages using Open SQL 1. Buffering Data on the Application Server.

Bangalore

14

The database interface buffers information from the database on the application server, when data is read from the database, it can be stored in buffers on the application server. If a request is then made to access the same records, they would already be on the application server and the request is satisfied from the buffer without having to go the database. This buffering technique reduces the load on the database server and on the network link between the database and application servers and can speed up database access time by a factor of 10 to 100 times. 2. Portability: - The SQL statements will be portable between databases. For example, if for some reason your company wanted to switch from an Oracle to an Informix database, it could change the database and your ABAP/4 code would continue to run without modification. 3. Automatic client handling:-With Open SQL the client field is automatically populated by the database interface. This gives your development and testing teams may advantages. Such as the ability to perform multiple simultaneous testing and training on a single database without interface from each other

WORKING WITH R/3 system The SAP R/3 presentation interface behaves very similarly to any other typical window application and is also known as SAPGUI. The first screen that you come across in R/3 system is SAP logon screen.

SAP R/3 logon Screen This is the first screen that appears when you use SAP logon utility. It has four fields: the client, the user, the password and the language.

Bangalore

15

 Client: Here you enter the client number. The client is group of users who has similar rights. It can be group of users in a business entity or a whole business entity or a whole company.  User: The name of the SAP user identification. Users of the SAP system are clientspecific, which means that user belonging to one client is valid to only the particular client.  Password: It is the password that has been assigned by the system administrator.  Language: SAP R/3 system supports multinational language on the same system at the same time, which is very useful for multinational companies with different branches in several countries and possibly using different languages. After entering all the fields press ENTER key and system will take you to MAIN MENU screen. User might get different screens when he logs on, depending upon default settings of the user master record i.e., if user is DEVELOPER then the screen which he often works on is editor screen and he can go directly to this screen, if system administrator sets this screen for the user. Main features of any R/3 window are as follows:  R/3 standard window elements behave exactly the same, as any other standard window application would, like minimizing a screen, setting the active window etc.  From TOP to BOTTOM, R/3 window can contain typical elements such as check boxes, push buttons, input fields and following elements: Bangalore

16

 Menu bar is the first element of the every R/3 window. It contains the menu item corresponding to the particular R/3 application. The two menu options SYSTEM and HELP are always present in every R/3 window. SYSTEM menu option contains all utilities and functions, and is available to user at all the times. The HELP menu contains all the available options for the different types and methods of obtaining online help in the system.  Standard tool bar. The second R/3 window element is present in every R/3 window. It is nothing but a collection of icons, which perform common functions like saving the object, exit etc. The various icons on std. Tool bar are as follows (from left to right):  Application tool bar: The next part of the screen contains icons most commonly used in that particular task or transaction.  Status bar is the bottom line of the screen and usually shows errors or information messages to the user. It also includes other information such as system id, session number, client, server name and the response time.

Logging Off User can log off the R/3 system from any screen. There are three ways of logging off the R/3 system, which are as follows:  From the Menu bar choose SYSTEM  LOG OFF. In this case, you get the log off dialog box, which informs the user that any data not saved will be lost if continuing with the log off procedure.  Use/NEX transaction code in the command field. This is dangerous, since it does not ask if you want to save the data.  Clicking on the EXIT button on the R/3 initial screen.

Bangalore

17

Getting help in the R/3 system R/3 includes many possibilities to get online help for almost every element of the system, users can get help for entire application, for specific function, for definitions of various terms used in SAP, i.e., Glossary, messages, screens, fields etc. You obtain HELP by using any of the following options:  Help function from the R/3 window, which is compulsory menu item of every R/3 window.  ? Icon of standard tool bar.  F1 function key. The SAP system provides help on most fields that appear on the R/3 system. To get help on particular field, position the cursor over it and press help button or F1 function key. Another way in which R/3 system provides help is when system displays error messages in the status bar. Double clicking on the status bar shows additional information about the message.

Bangalore

18

ABAP/4 Development Workbench

The development environment of SAP R/3 system is fully integrated set of various development tools, data dictionary, and programming language. Full integration of all components means that changes in any part have a direct and immediate effect on all application using those components. The screen of ABAP/4 development workbench looks like

Tools of ABAP/4 workbench For programming:  ABAP/4 dictionary Defining, maintaining and storing the data dictionary of the SAP R/3 system stores all the dictionary objects including tables relationship and Help information. Transaction code for this is SE11.  ABAP/4 editor Creating and maintaining the ABAP/4 program, editing function modules, logical database, and screens. Transaction code is SE38. Bangalore

19

 Function library Defining and maintaining the ABAP/4 function modules. Transaction code is SE37.  Screen painter Designing and maintaining the screens in transaction. Transaction Code is SE51.  Menu painter Designing and maintaining the means for graphical user interface. Transaction code SE41. For Navigating:  Object browser Managing and organizing the development object in a hierarchical form. Transaction code is SE80.  ABAP/4 repository information Navigating and searching for the dictionary Objects, development objects and relationship objects. Transaction code SE84.  Data browser Navigating in the data tables of the database. Transaction code is SE 16. For Debugging:  SOL trace tracking the database calls from the system transaction and programs. Transaction code is ST05.  Debugger Stopping the program and analyzing the results of the execution of every program statement.  Runtime Analysis Analyzing the performance the system calls Transaction code is SE30 For Organizing:  Workbench organizer controlling and keeping track of development work and team related development projects and managing versions of development objects. Transaction code is SE09.  Transport system performing and managing the transport of development object across different system. Transaction code is SE01

Bangalore

20

What is ABAP/4 ? ABAP (Advanced Business Application Programming) is a programming language for developing applications for the SAP R/3 system. ABAP is one of many applicationspecific fourth-generation languages (4GLs) first developed in the 1980s. The most basic functions were written in ABAP. ABAP/4 is the language created by SAP AG for implementation and customization of their R/3 system. The ABAP programming language was originally used by developers to develop the SAP R/3 platform. 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. 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 nonprogrammers. Good programming skills, including knowledge of relational database design and preferably also of object-oriented concepts are required to create ABAP programs. The ABAP/4 Development Workbench contains all tools you need to create and maintain ABAP/4 programs. ABAP/4 programs are not complied but generated. During generation, the system creates a so-called runtime object from the source code and the program attributes. When you start the program, the system executes the runtime object. ABAP/4, a fourth generation language, contains all usual control structures and modularizing concepts for structured programming. Characteristics of the ABAP/4 programming languages    

Declarative elements for declaring data of different type and structures. Operational elements for manipulating data. Control elements to control processing flow. ABAP/4 is multi-lingual. Text elements such as titles, headings, and text body are stored separately, independent of the program codes. Thus, you can change, translate, and maintain text elements without having no adapt the coding.  ABAP/4 supports business-related data types and operations. You can execute calculations using special data and time fields. The system automatically executes all necessary type conversions.  ABAP/4 provides a number of functions for processing character strings.

Bangalore

21

 ABAP/4 allows you to define and call subroutines. You can even call subroutines of other programs. There are different ways of how to pass parameters to and from the Subroutines.  ABAP/4 contains a special type of subroutine, called function module. Function modules are stored and maintained in a central library. They have clearly defined data interfaces to the calling program. You can test function modules in a stand-alone mode independent of the calling program.  ABAP/4 contains an SQL subset called OPEN SQL. OPEN SQL allows you to read and change database tables independent of the underlying database system.  ABAP/4 allows you to define and process internal tables that exist only for the execution period of the program. Internal tables efficiently support the usage of database tables and allow you to implement complex data structures in a program.  ABAP/4 allows you to store data not only in databases but also as sequential files on application and presentation servers. ABAP language Contains below mentioned topics 1. Data Dictionary Objects Data Base Tables Views Structures Data Elements Domains Search helps Lock objects Primary Key and Foreign Key Table Maintenance Generator 2. Internal Tables Internal Tables Introduction Declaring Internal Table Populating Internal Table Processing Internal Table Initializing Internal Tables 3. Moduralization Techniques Macros Sub-routines Function Module 4. REPORTS

Bangalore

22

Classical Interactive Abap list viewer (ALV)

5. BDC - Batch Data Communication Session method Call Transaction Method LSMW 6. Module pool Programming Screen painter Menu painter 7. Forms Scripts Smart forms 8. Cross-Aplications ALE & IDOCS BAPI's BADI’s User Exists 9. Miscellaneous Topics Correction & Transport request (CTS) Transport Organizer Work Bench Request Task Creation Release Objects SAP Memory & ABAP Memory SD Flow MM Flow

Bangalore

23

Data Dictionary Data dictionary is the centralized and structured source of information about a database table. It’s a logical layer situated over the database. Data Dictionary does not contains the data like Emp name, Addresses etc but rather a type of data whose function is to define the properties of data such as type, length and relationship. Advantages of data dictionary. Advantage of using data dictionary is avoiding inconsistencies when defining data type that will later be used in different applications. This avoids redundancies. When a type is defined in the dictionary, it is available to any program in the application. A change in the definition of a type of data in the dictionary automatically affects any other data or program, which has this data. Again, data dictionary is a fast and efficient way to answer questions such as which entries exist in a table of the database, what the structure of table is. Activation of dictionary objects For a dictionary object to be effective at runtime, that is, for a dictionary object to be available for use within a program, transaction, and so on, it must be in active status. For objects to become active, R/3 includes the ACTIVATION function. When a table or aggregated object is activated, it is placed at the disposal of the system as a runtime object in a way that makes it available quickly for the application program to access relevant information of new activated objects. When a dictionary object is modified, that means that the object previously existed and activated. You need to reactivate the object after modification.

Bangalore

24

When mass activation is performed massively, it might take a quite a long time. Then it should be in the background system. This type of activation is known as background activation. The ABAP/4 Data dictionary is the central component of ABAP/4 repository. A Data dictionary is centralized and structured source of information for business application. The ABAP/4 dictionary is the core of the R/3 development system. It is the source of every definition, within R/3, from the very basic domain to the company data model. It is totally integrated with other tools of the development environment like screen painter, menu painter, and editor. Some of the main available functions in the ABAP/4 dictionary are as follows:  Add, delete, modify, and manage the definition of the dictionary data.  Preserve the data integrity.  Be the central source of information e.g. from the dictionary you get the information about the defined relationship between two tables or even the directory tells whether table is active or empty.  It also permits documentation of system data. In the R/3 system instead of working with original objects, you work with internal representation of objects. With this type of operation the system performance is enhanced and has the advantage that the development tools, screen interpreters always access current data. When any of the data dictionary objects are used in other parts of the development workbench for example, in program, programmer only has to enter a table name or field name. The system automatically knows all the properties and information of the field. To call ABAP/4 dictionary, from the main menu, Tools  ABAP/4 workbench  data dictionary or enter transaction SE11.

Bangalore

25

Objects of Data Dictionary 1. 2. 3. 4. 5. 6. 7. 8. 9.

Tables views Data Type Domain Type Group Search Help Lock Objects Primary key and Foreign key Table Maintenance generator.

Bangalore

26

Tables A table is two dimensional data matrix i.e. it’s the combination of rows and columns. The rows contain the data record and columns contain the field. Tables can be containing 0 or multiple records or rows. Ex: Employee Table.

Types of Tables 1. Client Dependent 2. Client Independent 1. Client Dependent:- If the first field of a table is MANDT and data type is CLNT then it is called client dependent table. The length will be always 3. 2. Client Independent: - If the first field contains other than the MANDT then it is Called client independent table The client dependent tables are again of three types. 1. Transparent tables. 2. Pooled Tables. 3. Clustered Table. 1. Transparent Tables A transparent table in the dictionary has one to one relationship with a table in the database. Its structure in R/3 Data dictionary corresponding to a single database table. The database table has the same name, the same number of fields and the fields have the same names as the R/3 table definition. It contains application data. In below fig first part will shows transparent table.

Bangalore

27

2. Table Pools and Pooled Tables A pooled table in R/3 has a many-to-one relationship with a table in the database. For one table in the database, there are many tables in the R/3 Data Dictionary. The table in the database has a different name than the tables in the DDIC, it has a different number of fields, and the fields have different names as well. Pooled tables are an SAP proprietary construct. In the database pooled tables are stored in a single table called a table pool table.R/3 uses table pools to hold a large number (tens to thousands) of very small tables (about 10 to 100 rows each). Table pools reduce the amount of database resources needed when many small tables have to be open at the same time. Pooled tables are primarily used by SAP to hold customizing data. In the above fig second part is an example for pooled tables 3. Table Clusters and Cluster Tables A cluster table is similar to a pooled table. It has a many to one relationship with a table in the database. Many cluster tables are stored in a single table in the database called a table cluster. Table clusters are used to hold data from a few (approximately 2 to 10) very large

Bangalore

28

tables. They would be used when these tables have a part of their primary keys in common, and if the data in these tables are all accessed simultaneously. Table clusters contain fewer tables than table pools and, unlike table pools, the primary key of each table within the table cluster begins with the same field or fields. In the above fig third part is an example for cluster tables. Restrictions on Pooled and Cluster Tables Pooled and cluster tables are usually used only by SAP and not used by customers, probably because of the proprietary format of these tables within the database and because of technical restrictions placed upon their use within ABAP/4 programs. 1. On a pooled or cluster table, Secondary indexes cannot be created. 2. You cannot use the ABAP/4 constructs select distinct or group by. 3. You cannot use native SQL. 4. You cannot specify field names after the order by clause. Order by primary key is the only permitted variation. Because of these restrictions on pooled and cluster tables and because of their limited usefulness. Normally in real time system we will not create much pooled and cluster tables. Only transparent tables are used or created maximum. So we will discuss only about transparent tables

Other Components of the Table Fields: - Fields are nothing but columns. Domain: - Domain consists of the technical characteristics of a field such as field length and data type. Data Element: - A table is composed of fields to create a field you need a data element. The data element contains the field labels and documentation (F1 help) for the field. It contains the semantic characteristics for the field and it works like a interface between Field and Domain. Domain and data elements are reusable. A domain can be used in more than one data element and data elements can be used in more than one field and in more than one table. Delivery Class: - Delivery class comes under attributes. The value in the delivery class field identifies the “OWNER” of the data in this table. The owner is responsible for maintaining the table contents. In customer tables we always enter ‘A’ Here which indicates that the table contains application data owned by the customer only. Ex: - A –Application table (Master and Transaction data).

Bangalore

29

Data Class: It comes under technical settings. It defines the physical address of the database in which the table uses creates and logically stored or it’s a physical place where the actual data is to be stored. Categories of data class: APPLO – Master data, transparent tables. Size Category: It also comes under technical settings. It defines the probable space requirement for a table in the database. Categories: 0:- 0 to 30,000. 1:- 30,000 to 1, 20,000. 2:- 1, 20,000 to 4, 90,000. 3:- 4, 90,000 to 1,9,00,000 Table Maintenance allowed: Its also comes under attributes. By enabling table maintenance allowed user can be able to enter the data, change and display manually. Approaches for creating tables:- There are two approaches you can use when creating tables. Top-down-approach: In top down approach first we create the field then data element then domain. Bottom-up-approach: In the bottom-up-approach first we create the domain, then data element and then field. Direct Method: Do not have data element or domain. Primary key: Primary key is a field or combination of fields that uniquely identify a row in the database table. Foreign Key: Foreign Key is a key which is a primary key of another table. Naming convention for database tables: 1. The tables we are creating are generally called as Z-tables or customizing tables. 2. The name of a table should be started with Y or Z that a user creates. 3. SAP has used A to X for its own use, Z or Y in the beginning means that the program or table is user defined. So it avoids the redundancy between predefined and customizing tables. Steps to Create Database Tables

Bangalore

30

To create tables, Go to transaction SE11 and select database table radio button: Give Database table name for example ZKA_EMP. All user-created tables must start with Y or Z. Eg: ZKA_EMP. Then click on the CREATE button.

Eg: ZKA_EMP. Then click on the CREATE button and you will get the below screen.

In the Attributes (tab) screen, Enter the short description as EMPLOYEE DETAILS. Bangalore

31

Delivery class: Under multiple entries, select A-Application table (Master and transaction data). Check the box for the Table maintenance allowed. Now select the fields (tab), Field name EMPNO and field type ZKA_EMPNO and check the primary key check box. Field name EMPNO and field type ZKA_EMPNO and check the primary key check box and click on save button.

When you click on save button you will get one pop-up box as shown below.

Click on the LOCAL OBJECT button.

Bangalore

32

Now double click on the field type and u will get CREATE DATA ELEMENT SCREEN, click on YES.

Enter the short text EMPLOYEE NO and the domain name ZKA_EMPNO.

Now double click on the domain name ZKA_EMPNO and enter the following details. Short text : EMPLOYEE NO. Data Type : NUMC(Click on the RIS button and select NUMC from that)

Bangalore

33

No. of characters: As per the requirement. ( Eg. 10 ). Note: If the field is employee name then u need to select the data type to be CHAR and required no of characters.

Now SAVE (CTRL + S) , Click on the CHECK button or (CTRL + F2), and should get NO INCONSISTENSIES FOUND in the status bar. Then click on the ACTIVATE button (CTRL + F3).

Now click on the BACK button and then, SAVE(CTRL+S), CHECK(CTRL+F2) & ACTIVATE(CTRL+F3). Click the BACK button and u will be in the main dictionary screen. Bangalore

34

Now click on the NEW ROWS button to enter as many fields u would prefer. Once all the fields with the data element and the domain is set up, the table need to be activated as a whole. To activate the table the technical settings should be saved. Before u activate, u need to set up the technical settings by clicking on the TECHNICAL SETTINGS button. Where the data class is APPL0 (Master data, Transparent tables). Size category is 0(0-30000). SAVE or (CTRL+S) the technical settings.

Click BACK to get to the main screen and SAVE, CHECK AND ACTIVATE the table. In order to give the input values(new entries), click on Utilities->Table contents->Create Entries

Bangalore

35

Enter and SAVE the values and click RESET to give the new values.

Once the values are saved, click the BACK button and click on the CONTENTS, then the EXECUTE button to see the output.

So when we click on the EXECUTE button, we get the output in the table format. Thus the table is created.

Bangalore

36

Database Views A view is a logical window to a table or more than one table, the data from a view is not actually physically stored instead being derived from one or more tables. A view can be used to summarize data which is distributed among several tables. It does not contain memory space. During runtime it contains memory after the execution the memory will be released Types of Views 1. Projection View 2. Database View 3. Maintenance View 4. Help View Projection View: This view is used to display data’s from only one table i.e. view can draw upon only one table, this means that only the data that actually required is exchanged when the database is accessed. Selection conditions cannot be specified for projection view. Database View: This view is used to display data’s from more than one table. Database views are implement an inner join, that is, only records of the primary table for which the corresponding records of the secondary tables also exist are fetched. In database views, the join conditions can be formulated using equality relationships between any base fields. Inconsistencies between primary and secondary table could, therefore, lead to reduced selection set Maintenance View: This view is used to for data manipulation like insert, update, delete, modify etc. Data from several tables can be summarized in a maintenance view and maintained collectively via this view. That is the data is entered via the view and then distributed to the underlying tables by the system.

Bangalore

37

Help View: This view is used to displaying possible values of field from one or more than one table i.e. used to output additional information when the online help system is called or when F4 is pressed on the field.

Steps to create Views DATABASE VIEW: View can be performed for more than one table which have the foreign relationship b/w the tables. For Eg: If we have ZKA_EMP and ZKA_COM, We can perform view. Now to start with the view. Go to transaction SE11 and select View Radio button and enter the name as below. Eg: ZKA_DBV and click on the CREATE button.

Select the database view among the options and then click on the copy button.

Bangalore

38

Enter the short text: DATABASE VIEW. And under the tables enter both the table names ZKA_EMP, ZKA_COM.

Now click on the RELATIONSHIPS button and select the referenced tables and click on the COPY button.

Bangalore

39

Now click on the VIEWS tab and click on the TABLE FIELD button.

Now choose the first table ZKA_EMP and select the fields required and click on the COPY button. Similarly for the second table ZKA_COM.

Bangalore

40

Now SAVE, CHECK and ACTIVATE. To see the output, click CONTENTS and EXECUTE.

Thus the database view is done with the fields in both the tables.

PROJECTION VIEW: Go to SE11 and click on VIEW and enter ZKA_PV. Click on the CREATE button.

Bangalore

41

Select PROJECTION VIEW and click on the CONTINUE button.

Now enter the short text: PROJECTION VIEW. Basis table: ZKA_COM (the table for which u need the projection view). Now click on the TABLE FIELDS button and select the fields that we need to project and click on the COPY button.

Bangalore

42

Now SAVE, CHECK and ACTIVATE. To see the output click on the CONTENTS button and EXECUTE. Thus the projection view is created.

SEARCH HELP Search helps are independent Repository objects that you create using the ABAP Dictionary. They are used to present input help for screen fields which gives list of all possible values for either primary key or non primary keys The input help (F4 help) is a standard function of the R/3 System. It permits the user to display a list of possible values for a screen field. A value can be directly copied to an input field by list selection. The fields having an input help are shown in the R/3 System by the input help key to the right of the field. This key appears as soon as the cursor is positioned on the corresponding screen field. The help can be started either by clicking on this screen element or with function key F4. Since the input help is a standard function, it should look and behave the same throughout the entire R/3 System. The development environment therefore provides tools for assigning a standardized input help to a screen field. When you define a parameter of a search help, you must also define whether it should be used to copy data to the input help (IMPORT parameter) or whether to return data from the input help (EXPORT parameter).

Bangalore

43

Types of Search helps Elementary search helps:- defines a search path where we will define the table from which the data has to be read and the selection criteria. Through import and export parameters. Used when we gets the data rom a single table. Collective search helps:- Combination of elementary search helps. When we need to fetch data based on multiple selection criteria s. More than one tables are selection from multiple tables. Diff Between Elementary search helps & Collective search helps 1) Elementary search helps describe a search path. The elementary search help must define where the data of the hit list should be read from (selection method), how the exchange of values between the screen template and selection method is implemented (interface of the search help) and how the online input help should be defined (online behaviour of the search help). 2) Collective search helps combine several elementary search helps. Collective search help thus can offer several alternative search paths. 3) An elementary search help defines the standard flow of an input help. 4) A collective search help combines several elementary search helps. The user can thus choose one of several alternative search paths with collective search help. 5) A collective search help comprises several elementary search helps. It combines all the search paths that are meaningful for a field. 6) Both elementary search helps and other search helps can be included in a collective search help. If other collective search helps are contained in collective search help, they are expanded to the level of the elementary search helps when the input help is called.

STRUCTURE Structure is a skeletal view of a table. It contains the definition of columns and don’t have any contents. Structure is generally a template based on which a table is created. The basic difference between structure and table is that the structure does not exist at the underlying database system level. Structure exists as definition in the dictionary. Types of Structures

Bangalore

44

Append Structure:- It will add Fields to the table from last . we can't use that structure in another table. An append structure is a structure assigned to just one table. When a table is activated, all append structures for the table are found and appended to the table.Append structures are used to add customer fields to SAP tables and Custom tables also. Include Structure: Include structures can used by us to add fields into any ztables and SAP tables also. Because in a Ztable we can add fields where ever we want. Include structure can be used more than one time in a table. The same include structure can be included to any no of custom tables. Steps to create Structure. In the DDIC (SE11), select DATATYPE and give the structure name: ZKA_STRUCT.

Now select STRUCTURE and click on the COPY button.

Enter the short text: STRUCTURE.

Bangalore

45

Then the components (field) corresponding to the table and select the component type from the existing data type. Click on SAVE, CHECK and ACTIVATE.

Now go the table to which the structure need to be added (ZKA_EMP).Select the row where the structure need to be added and click on EDIT->INCLUDE->INSERT

Enter the STRUCURE ZKA_STRUCT and click OK. SAVE, CHECK and ACTIVATE. To see the output, Click on CONTENTS and EXECUTE. Select all the records and click on the CHANGE button and click on the next entry and fill in all the values and BACK button to see the output. Thus the Structure is created.

Bangalore

46

Table types Table types are construction blueprints for internal tables that are stored in the ABAP Dictionary. When you create a table type in the ABAP Dictionary, you specify the line type, access type, and key. The line type can be any data type from the ABAP Dictionary, that is, a data element, a structure, a table type, or the type of a database table. You can also enter a predefined Dictionary type directly as the line type, in the same way that you can with a domain. In an ABAP program, you can use the TYPE addition to refer directly to a table type. If you define a local data type in a program by referring to a table type as follows: TYPES dtype TYPE table. The construction blueprint of the table type is used to create a local internal table dtype in the program. The predefined Dictionary data types of the domains used by the data elements in the structure are converted into the corresponding ABAP types. The semantic attributes of the data elements are used for the corresponding components of the internal table in the program.

Bangalore

47

Type Groups Type groups were based on the include technique, and allowed you to store any type definitions globally in the Dictionary by defining them using TYPES statements. The definition of a type group is a fragment of ABAP code which you enter in the ABAP Editor. The first statement for the type group pool is always: TYPE-POOL pool. After that, you define data types using the statement TYPES. It was also possible to define global constants using the CONSTANTS statement. All the names of these data types and constants must begin with the name of the type group and an underscore: pool_ In an ABAP program, you must declare a type group as follows before you can use it: TYPE-POOLS pool. This statement allows you to use all the data types and constants defined in the type group pool in your program. You can use several type groups in the same program. Let the type group HKTST be created as follows in the ABAP Dictionary: TYPE-POOL hktst. TYPES: BEGIN OF hktst_typ1, col1(10) TYPE c, col2 TYPE i, END OF hktst_typ1. TYPES hktst_typ2 TYPE p DECIMALS 2. CONSTANTS hktst_eleven TYPE i VALUE 11. This type group defines two data types HKTST_TYP1 and HKTST_TYP2, as well as a constant HKTST_ELEVEN with the value 11. Any ABAP program can use this definition with the TYPE-POOLS statement: TYPE-POOLS hktst. DATA: dat1 TYPE hktst_typ1, dat2 TYPE hktst_typ2 VALUE '1.23'. WRITE: dat2, / hktst_eleven. The output is: 1.23, Bangalore

11 48

The data types defined in the type group are used to declare data objects with the DATAstatement and the value of the constant is, as the output shows, known in the program Example for type Group *&---------------------------------------------------------------------* *& Report ZBASU_TYPE_GROUP * *& * *&---------------------------------------------------------------------* *& * *& * *&---------------------------------------------------------------------* REPORT ZBASU_TYPE_GROUP TYPE-POOLs: ZTYPE . tables: mara.

.

data: itab type table of ztype_basu with header line. select-options: material for mara-matnr. select * from mara into corresponding fields of table itab where matnr in material. write:/ ztype_a. loop at itab. write:/ itab-matnr, itab-ersda, itab-ernam. endloop.

***************** Type Group defined DDIC TYPE-POOL ZTYPE . constants: ZTYPE_a type i value 10. types: begin of ztype_basu, matnr like mara-matnr, ersda like mara-ersda, ernam like mara-ernam, end of ztype_basu.

LOCK OBJECTS These types of objects are used for locking the access to database records in table. This mechanism is used to enforce data integrity that is two users cannot update the same data at the same time. With lock objects you can lock table-field or whole table. In a system where many users can access the same data, it becomes necessary to control the access to the data. In R/3 system this access control is built-in on database tables. Developers can also lock objects over table records.

Bangalore

49

To lock an object you need to call standard functions, which are automatically generated while defining the lock object in ABAP/4 dictionary. This locking system is independent of the locking mechanism used by the R/3 system. Whenever an object is locked, either by in built locking mechanism or by function modules, it creates corresponding entry in global system table i.e. table is locked. The system automatically releases the lock at the end of transaction.

Creating Lock Objects Lock object is an aggregated dictionary object and can be defined by using the following steps: o From initial data dictionary screen, enter the name for the object, Click Lock object radio button and then click on Create. The system displays a dialog box for Maintain Lock Objects screen o Enter short text as usual and the name for primary table. o Save o Select Tables option From this screen you can: Select secondary tables, if any, linked by foreign key relationship. Fields for the lock objects. This option allows you to select fields for objects (R/3 system allows locking up to record level). Lock object argument are not selected by user but are imposed by the system and includes all the primary keys for the table. Types of locks You can lock the table or record by using following types of locking: Exclusive (E) or Read mode: The locked data can only be displayed or modified by single user i.e. the owner of the object. Access to other users is denied. Shared (S) or Write Mode: Several users can access the same record simultaneously, but only in display mode and except the first one, who has asked for the data in update mode. Exclusive not cumulating (X) it is similar to exclusive lock. It allows only a single user access. E can be called several times from the same transaction. In contrast, a lock type X can be called only once during the transaction. Any other call for this lock is rejected.

Bangalore

50

Activation of Lock Object When you activate the lock object, the functions are automatically generated. And these are ENQUEUE-EZN and DEQUEUE-EZN. EZN is name of the lock object. While ENQUEUE is used in program to set the code over the selected data depending upon the lock object arguments. DEQUEUE is used to release the lock.

Bangalore

51

Internal Tables By definition, internal tables are user defined structured data types. These internal tables can be created as a replica of data base table, using some or all fields of one table or more tables. These internal tables are created only during run time no memory is reserved. Why we need internal table Long life data is stored in database tables when we are directly modifying data there is every possibility that we may loose data by accident, which we can not afford to do so, As such we need some intermediate etc tables to do some operations upon satisfactory results, we can modify database tables. Defining Internal Tables: Internal table with header line: When we create internal table with header line, a default work area is created. Internal table with out header line: In this case, we need to create explicit work area to work with it. When we need to nest the tables with in tables, we need to use this type of internal table.

Types of internal tables 1. Standard tables: - Standard tables have an internal linear index. 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 tables. The key of standard table is always non-unique. Standard tables can always be filled very quickly, since the system does not have to check whether there are already existing entries. Key access to a standard table uses a linear search. This means that the time required for a search is in linear relation to the number of table entries. You should use index operations to access standard tables. 2. Sorted Tables: - Defines the tables as one that is always saved correctly sorted by key. 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 nonunique. If the key is not unique, the system takes the entry with the lowest index. The runtime required for key access is logarithmically related to the number of table entries.

Bangalore

52

3. Hashed tables: - Hashed tables have no linear index. Hashed table is accessed using its key. The response time is independent of the number of table entries and is constant, since the system accesses the table entries using a hash algorithm. The key of a hashed table must be unique. Defines the tables as one that is managed with an internal hash procedure. You can only access a hashed table using the generic key operations or other generic operations (sort, loop and so on) Explicit or implicit index operations (such as loop... from and insert itab with in and loop) are not allowed. 4. Index Table: - A table that can be accessed using an index. Index table is only used to specify the type of generic parameters in a from or function. That means that you can not create a table of type Index. Standard and sorted tables are index tables.

Initializing Internal Tables Clear: Clears the header (Work Area) line of the internal table. Syntax: clear Itab. Clear []: Clears the body of the internal table without clearing the work area or header. Syntax: Clear itab []. Refresh : Delete all table entries, memory space remains occupied i.e. only removes only contents of internal table. Free : Delete all table entries, memory space is released i.e. de-allocates memory associated with internal table.

Operations of Internal Tables 1. Append: It will take data from work area or header into internal table body. Syntax: Append itab (append itab to itab) Append wa_itab to itab. 2. Collect: It will work similar to append operation but it will adds the same integer fields otherwise it will append it. Syntax: Collect itab. 3. Insert: Used to insert data at any place. For this we have to specify the index no otherwise its goes to dump screen. Syntax: insert itab index (Index number). 4. Modify: This operation will modify the existing records. Syntax: Modify itab index (Index number). Bangalore

53

5. Read: Used to read a single record from itab with key or index and it will read from application server to the screen. Syntax: read itab with key (field name) 6. Sort: Used to sort the internal tables and by default it is ascending. Syntax: Sort itab by (Field name). 7. Delete: Used to delete the data from internal tables but you need to give index number or range and field names. Syntax: Delete itab by index (Index number) 8. Describe: Used to describe the internal tables like how many records and what kind of internal table etc. Syntax: Describe table itab lines (variable name)

Example for internal table operations *&---------------------------------------------------------------------* *& Report ZBASU_INTERNAL_TABLE_OPERATION * *& * *&---------------------------------------------------------------------* *& * *& * *&---------------------------------------------------------------------* REPORT

ZBASU_INTERNAL_TABLE_OPERATION.

DATA: BEGIN OF ITAB OCCURS 0, F1, F2 TYPE I, F3(3), END OF ITAB. DATA: LIN. ******Append Operation ITAB-F1 = 'A'. ITAB-F2 = 10. ITAB-F3 = 'BC'. APPEND ITAB. CLEAR ITAB. ITAB-F1 = 'B'. ITAB-F2 = 15. ITAB-F3 = 'BD'. APPEND ITAB. CLEAR ITAB. ******* ITAB-F1 ITAB-F2 ITAB-F3

Collect Operation = 'A'. = 20. = 'BC'.

Bangalore

54

COLLECT ITAB. CLEAR ITAB. ITAB-F1 = 'C'. ITAB-F2 = 25. ITAB-F3 = 'BF'. APPEND ITAB. CLEAR ITAB. *******Insert Operation ITAB-F1 = 'D'. ITAB-F2 = 30. ITAB-F3 = 'BG'. INSERT ITAB INDEX 2. CLEAR ITAB. *******Modify Operation ITAB-F1 = 'F'. ITAB-F2 = 40. ITAB-F3 = 'BH'. MODIFY ITAB INDEX 2. CLEAR ITAB. ITAB-F1 = 'F'. MODIFY ITAB TRANSPORTING F1 WHERE F1 = 'D'. CLEAR ITAB. *******Sort Operation SORT ITAB. SORT ITAB BY F2. ******Read READ TABLE READ TABLE READ TABLE

Operation ITAB INDEX SY-TABIX INTO ITAB. ITAB INDEX 3 INTO ITAB. ITAB INTO ITAB WITH KEY F1 = 'D'.

WRITE:/ ITAB-F1, ITAB-F2, ITAB-F3. ******Describe Operation DESCRIBE TABLE ITAB LINES LIN. ******Delete Operation DELETE ITAB INDEX 2. DELETE ITAB WHERE F1 = 'A'. WRITE:/ 'NO OF LINES IN MY INTERNAL TABLE', LIN. LOOP AT ITAB. WRITE:/ ITAB-F1, ITAB-F2, ITAB-F3. ENDLOOP.

Bangalore

55

REPORTS

About reports Reports, in the R/3 system are online programs whose function is to retrieve data from database and display it or print it for the user. An end user often needs some information to look up, depending upon which various management decisions are taken, or to just see business results or simply to continue work. As R/3 is collection of all business applications, it has provided a very powerful feature to satisfy this crucial business need i.e., reports are involved at each and every step of business. This type of extracting, collecting and formatting data that is stored in database is done by REPORT program. The program that is written to retrieve and display data is REPORT program and the data that is displayed on the screen when you execute the program is called as LIST (output of the report). When you display data, you need to display the data, user needs. For example, user wants to see the all the employee, who has joined after 12th December 1997. In this case user has to pass this information, to the system, that he needs only those employee records where joining data is greater than 12th December 1997. For user, it is passing information to the system but for the system it is input from the user. System takes input from the user before it retrieves the data from the database. This is very common requirement of any report as the need of any business is to display data, which is required by user.  Reports are ABAP/4 programs.  You use reports to evaluation data from database tables. The results of such an evaluation can be displayed on the screen or printed form.  Reports are stand-alone programs.  The user can execute reports directly via the program name, for example, by choosing System ® Utilities ® Reporting.  A report program contains a collection of processing blocks for different events that are always triggered externally. In a report, you can react on events by programming the corresponding processing blocks or ignore the events by not writing the corresponding processing blocks. A report itself never creates events.

Bangalore

56

 Reports can use logical databases or select statements defined by developer.  For each application, SAP supplies logical databases. Or you can easily create logical database yourself.  Event control of a report corresponds to a certain scheme: When a report is executed, the ABAP/4 processor creates together with the logical database used (if any) a sequence of certain events for which you can program processing blocks. The chronology of the events is (more or less) Steps involved in creating a Report: 1. Processing the selection screen After starting a report, the selection screen allows the user to enter limits or control values for further report processing. The report can contain several processing blocks for events during selection screen processing, for example, for checking the input values. 2. Reading the database After selection screen processing come the events for reading the database. Either the report reads data from relational databases it using the corresponding ABAP/4 statements (open SQL) or leaves this task to a logical database. In the latter case, the logical database creates a sequence of events to allow the report to copy the data. 3. Evaluating data and creating lists During or after reading the database the report creates the output list. During list creation, several events allow you to layout the output list (for example, layout the page header). 4. Outputting a list The last part of the processing sequence controlled by the ABAP/4 processor is the list output on the screen or printer. When displaying the list on the screen, user can trigger other reports, that are interactive and are event driven. For example, by clicking the mouse. By programming processing blocks for these events, you change a normal report to a so-called Interactive report. If a report does not contain event keywords, the entire coding of the report belongs to a single processing block, which is called by a standard event. This standard event is triggered directly after processing the selection screen.

Bangalore

57

Selection criteria System accepts inputs from user through SELECTION CRITERIA. Selection criteria are nothing but input fields which allows the user to restrict information given to program for processing further data. If you don’t specify any criteria for selection, your report program produces a long list of data, which might not be needed by the user. Basically, selection criteria are the fields where user enters some value for which he needs information. Through selection criteria user can enter discrete value or ranges. For example, user wants to see all the records of the employees, who have joined between 12th December 1997 and 12th May 1998. This range can be entered in selection criteria. As the user becomes more specific for mentioning the criteria, the list will be smaller and more specific. Syntax:

SELECT-OPTIONS for . Field is the variable, which you declare for accepting input from the user. Table field is reference field. SELECT-OPTIONS: fld1 for sflight-fldate, carrid1 for sflight-carrid. Maximum length of the name Select-Options variable is 8. When system executes this statement, the selection screen is displayed and is like this.

Bangalore

58

When you enter the desired information and click on execute button, rest of the program is executed, that is retrieval of data from database, which matches this information and the list is displayed. Behavior of SELECT-OPTIONS When the Select-Options statement is executed the system creates the internal table with the same variable name (in this case it will be carrid1). This table is also called as selection table. The main purpose of selection table is to store selection criteria. The table has four standard fields, which are as follows:  SIGN is a variable, which denotes the system whether the result should be included with those particular criteria. It can contain either I or E. I denotes Inclusion. The criteria are included. E denotes Exclusion. The criteria are excluded from the result.  LOW the data type of LOW is the same as the field type of the database table, for which you are using selection criteria. This acts as lower limit of the selection.  HIGH the data type of HIGH is the same field type of the database table, for which you are using the selection criteria. This acts as higher limit. If you don’t enter HIGH value then the LOW value defines a single value selection.  OPTION is two-character field, which contains operators like EQ, GT, LT, GE, and LE.

Bangalore

59

When the user enters both the values i.e., high and low then this field acts as BT (between). If you don’t enter high value then all other operators can be Applicable. For each Select-Options statement system creates internal table. Default values for select-options If you want to display default values for the selection criteria before your screen is displayed, give default values for the selection table fields i.e., low or high. SELECT-OPTIONS: CARRID1 FOR SFLIGHT-CARRID DEFAULT CARRID1-LOW = ‘LH’ AND CARRID1-HIGH = ‘SQ’. In this case selection screen is displayed with default values ‘LH’ for lower range and ‘SQ’ for higher range. User can use same values or overwrite these values with new values, whichever he needs.

Parameters Parameter statement is used to accept input from user. PARAMETER statement is used when you want user to enter data and depending upon what he enters you need to take action. The parameter statement declares the variable and also allows system to accept data into that variable. Syntax. Parameters: num type I. Here parameter statement declares the variable and creates the selection screen on which user enters the data i.e., in this case num is declared of type I and user can enter any number. Entered value is stored in the same variable and can be used in program. Data: m type I Parameters: num type I M = num – 5 Write: / ‘The number is’, m. You can define default values with parameter statement for example Parameter: num type I default 12. In this case when selection screen is displayed the default value is displayed. User can either use same value or overwrite the value.

Bangalore

60

Parameter of type character and length = 1, can be displayed as Checkbox and Radiobutton. Parameter: C1 as Checkbox, C2 as Checkbox. Parameter: R1 Radiobutton group g1, R2 Radiobutton group g1. When parameter is defined as Radiobutton, it needs to be attached to one group. Only one Radiobutton of one group can be clicked. Every parameter can be associated with language dependent text that is displayed on the selection screen. This can be done with the help of text elements.

WRITE Statement The basic APAB/4 statement for outputting data on the screen is WRITE. Syntax: WRITE . This statement outputs the field to the current list in its standard output format. By default, the list is displayed on the screen. The field can be any variable or table field or just literal. PROGRAM ZDEMO WRITE: /‘HELLO’. When you start this program, the system leaves the current screen i.e., your editor screen and branches to the output screen, which is also called as list screen: The list screen has the same name as the title of the program specified in the program attributes. First line on the screen contains the list header. By default, the list header is the same as the title of the program. The current page number (1) appears on the right. The list header is followed by one line and then the output is displayed. Write : ‘HELLO’. Write : ‘WORK HARD’

Bangalore

61

On the screen, the output is normally left justified. But in above case, because we have used two WRITE statements, the output fields are displayed one after the other, each separated by one column (i.e., one blank). If there is not enough space for an output field on the current line, a new line is started. Almost all system-defined fields are right justified except FLOAT, INTEGER, and PACKED i.e., number field. The numeric data types F, P, and I are right justified and padded with blanks on the left. If there is sufficient space, thousands of separators are also output. If a type P field contains decimal places, the default output length is increased by one. With the data type D, the internal format of a date differs from its output format. When you use the WRITE statement for outputting data, the system automatically outputs dates of type D in the format specified in the user’s master record (e.g. DD/MM/YYYY or MM/DD/YYYY).

CLASSICAL REPORTS Events in Classical report Events associated with classical report are as follows and each one will be discussed in detail.       

INITIALIZATION AT SELECTION-SCREEN AT SELECTION-SCREEN ON START-OF-SELECTION TOP-OF-PAGE END-OF-PAGE END-OF-SELECTION

In this case first three events are associated with selection screen. Rests of the events are associated with your list.  INITIALIZATION We have already seen how to fill default values for the selection criteria. But in many cases you need to calculate the value and then put it in selection criteria. For example, say, you are accepting date from user and you need to fill in the default value for lower range as sy-datum – 30 days and sy-datum for higher range. In this case you are Bangalore

62

calculating lower range and then filling the criteria. This can be done in INITIALIZATION event. Piece of code to do the above task would look like the following: Tables: Sflight. Select-options: fldate1 for sflight-fldate. INITIALIZATION. Data: date1 like SY-DATUM. Date1 = sy-datum – 30. Fldate1-low = date1. Fldate1-high = sy-datum. Append fldate1. * Here appending is required because fldate1 is int’ table This event is triggered when you execute your program for the first time i.e., before selection screen is displayed.

 AT SELECTION-SCREEN When user enters the values in the fields of selection screen and clicks on execute button, this event gets triggered. This event is basically for checking the values entered by the user for the fields of the selection screen i.e., data validity checking. This event is for entire selection screen. For example: You are accepting carrid, connid, fldate from user and you don’t want to proceed if user enters no value for carrid and fldate. Using AT SELECTION-SCREEN can do this. Select-options: carrid1 for sflight-carrid, Connid1 for sflight-connid, F1date1 for sflight-f1date. AT SELECTION-SCREEN. If carrid1-low ne ‘ ’ and fldate1-low = ‘ ’. Error message. Endif. In this case, if both the fields are entered blank, then the user gets error message. Basically, this event is for many fields on selection screen. Usually, it is for the fields which are logically related.

Bangalore

63

 AT SELECTION-SCREEN ON When you want to check for specific value of a field. For example, carrid should be in the range of ‘LH’ and ‘SQ’. This can be done in this event. Basically, this event is for checking individual fields. You can have many AT selection-screen events in your program (i.e., for each field specified in the Select-Options). Select-Options carrid1 for sflight-carrid. AT SELECTION-SCREEN. If carrid1-low ne ‘LH’ and carrid1-high ne ‘SQ’. Error message. Endif. Here the system will not proceed on entering wrong values.

 START-OF-SELECTION This is the first event for your list. Once all the events are triggered for selection screen, the data is retrieved from database. Data declaration, select statements are done in this event. Consider the following example: START-OF-SELECTION. Data: mtype i. Tables: sflight. Select * from sflight where carrid = ‘LH’. Write: / sflight-carrid,sflight-connid. Endselect.  TOP-OF-PAGE This event is triggered with first WRITE statement or whenever new page is triggered. Advantage of using this event is that, whatever you write under this event, is applicable to all the pages. If you don’t have any write statement before TOP-OF-PAGE or in START-OF-SELECTION, this event is not triggered at all. For example, if you want the name of company and column headers for all the pages, it can be written in this event.

Bangalore

64

TOP-OF-PAGE Write: / ‘INTELLIGROUP ASIA PVT. LTD.’ Write : / 10 ‘carrid’, 20 ‘connid’, 30 ‘fldate’.  END-OF-PAGE This event is triggered at the end of page. End-of-page. Write : / ‘page number’, sy-pagno. In this case page number will be written on every page. Conditional triggering of EOP

Consider the following case. REPORT ZDEMO1 line-count 15(3). Top-of-page. Write: ‘this line is written by top-of-page event’. Start-of-selection. Write: ‘this line is written by start-of-selection event’. End-of-page. Write : ‘this line is written by end-of-page event’. In this case EOP will never be triggered, as end of page is never reached. The total Linecount defined for page = 15 in which 3 lines are for footer area. The output of the above code will be This line is written by top of page event. This line is written by start of selection event. In output screen, only two lines are written and cursor remains still on 3rd line, the end-ofpage event is not triggered. To trigger end of page event, cursor should reach at the last position, in this case on 11th line. Such cases are quite common, and could be overcome by conditional triggering of end of page. Sy-linct is the system variable, which gives total line count of a list.

Bangalore

65

Sy-linno is the system variable, which gives the current line number where the cursor is placed on the list. Consider the following case: Report zdemo1 line count 20(1). Start-of-selection. Data: m type i. Write: / ‘this is first line’. Do 5 times. Write: / ‘the number is’, sy-index. Enddo. M = sy-linct, sy-linno – 1. Skip x. End-of-page. Write: / ‘page end’. The output of above example is as follows : This is first line. The number is 1 The number is 2 The number is 3 The number is 4 The number is 5 After skipping 10 lines Page end In this case, with all write statement, you don’t reach to the end of page. After all write statement, m is calculated in this case: M = 20 – 8 – 1, So m is 12. And 11 lines are skipped after write statement and end of page is reached. (In this case you have 6 write statement so 6 lines + 1 line for page number and 1 horizontal line which is displayed for any list. So cursor is on 8th line and is subtracted from total line count i.e, 20.) Using Variants with selection criteria In many cases you need report to execute report at regular interval for certain fixed values of selection criteria. That means each times you execute the report you need to enter its values again and again. ABAP/4 provides the facility by which you can define the values for selection screen and store it. Using VARIANTS can do this. It can be Bangalore

66

defined as group of values used for selection criteria while executing report. For a particular report, you create a variant which means variant created for particular report cannot be used for another report. The group of values for the selection criteria is saved and assigned a variant name. So every time you call a report, you need not specify the values for selection criteria but instead call the variant thus avoiding extra typing. User can have many variants for a single report. Each of them can be used as different type of information. For example, if a manager wants to see how an employee in personnel department or admin department has performed. He need not enter the department, one has to just execute the report with variant. In case he doesn’t know about the variant, which is available, he can display list of variants attached to the report and values assigned to each variant. Creating variant  Execute the report program. The selection screen is displayed.  Enter the values for selection screen and click on saves. - System displays the variant screen  Enter the variant name and description for it.  Save it. Usually the variants are useful when you need to execute the report in background, which will be discussed in background processing. Example for Classical Report Events. *&---------------------------------------------------------------------* *& Report ZBASU_CLASSICAL_REPORT_EVENTS * *& * *&---------------------------------------------------------------------* REPORT ZBASU_CLASSICAL_REPORT_EVENTS NO STANDARD PAGE HEADING LINE-SIZE 90 LINE-COUNT 40(2). Tables: mara. data: begin of itab occurs 0, matnr like mara-matnr, ersda like mara-ersda, ernam like mara-ernam, end of itab. DATA: M TYPE I. selection-screen: begin of block b1 with frame title text-002. select-options: material for mara-matnr. selection-screen: end of block b1. INITIALIZATION. MATERIAL-LOW = '100'. MATERIAL-HIGH = '200'.

Bangalore

67

MATERIAL-SIGN = 'I'. MATERIAL-OPTION = 'BT'. AT SELECTION-SCREEN. IF MATERIAL-LOW = ' ' AND MATERIAL-HIGH = ' '. MESSAGE 'ENTER PROPER DATA' TYPE 'E'. ENDIF. START-OF-SELECTION. SELECT MATNR ERSDA ERNAM FROM MARA INTO CORRESPONDING FIELDS OF TABLE ITAB WHERE MATNR IN MATERIAL. TOP-OF-PAGE. WRITE:/ 'GALAXE SOLUTIONS'. END-OF-SELECTION. LOOP AT ITAB. WRITE:/ ITAB-MATNR, ITAB-ERSDA, ITAB-ERNAM. ENDLOOP. M = SY-LINCT - SY-LINNO - 2. SKIP M. END-OF-PAGE. WRITE:/ 'BANGALORE', SY-DATUM.

MODULARIZATION TECHNIQUES Modularization means minimization, if the programs contain the same or similar blocks of statements or it is required to process the same function several times, we can avoid this redundancy or duplication of codes by using modularization techniques. By modularizing the ABAP/4 program 1. We make them easy to read i.e. improves the readability 2. Improve their structure 3. Error handling and maintenance is easy 4. Updating can be done easily 5. Reusability i.e. procedures can be used in other programs as well 6. Encapsulation i.e. hides the internal architecture and data structure from other classes. It is important to use a series of functions that act as the means to access the data. 7. Reduces code redundancy i.e. avoids duplication of codes

Different modularization techniques available are:

Bangalore

68

1. 2. 3. 4.

SUBROUTINE FUNCTION MODULE METHODS INCLUDES AND MACROS

METHODS: It describes the functions and behavior of classes and their instances in ABAP objects methods must be defined in classes. MACROS: Macros designed based on place holder (place holder works like pointers in c language but in case of place holder changes effect on output. INCLUDES: If I am defining the same variables in many programs, instead of defining in all programs we have define all the variables in one program and that program is included or added to the programs whenever needed that’s called include program. It cannot be executed independently it has to include in a program. SUBROUTINES: A subroutine is a reusable section of code. It’s like a mini program that can be called from another point in your program. Subroutine is generally for local modularization i.e. they are generally called from the program in which they defined. We can use subroutine to write functions that are used repeatedly with in a program. You can define subroutine in any ABAP programs.

Syntax for defining subroutine FORM (subroutine name) (parameter (Optional)) -----------------------------------------------------------------------------------------------------END FORM. Syntax for calling subroutines PERFORM Subroutines cannot be nested, therefore place subroutine definitions at the end at the program. One subroutines can call other subroutines and may also call themselves (recursive). Once a subroutine has finished running, the calling program carries on processing after the perform statement.

Bangalore

69

There are two types of subroutines: 1) Internal subroutine: If the source code or body of the subroutine will be in the same ABAP/4 program i.e. in the calling program which is called internal subroutine. 2) External subroutine: If the source code or body of the subroutine present other than the calling program which is called external subroutine. An external subroutine is one that resides in a different program that the perform statement that calls it. Report ztn1811 Perform

Report ztn1811 Form s1 end term

PARAMENTERS IN SUBROUTINES Parameters can be either local or reference to global variables. The memory for local parameters is allocated when the subroutine is called & freed when it ends. If we define variables on the form statement, the perform statement must pass a value to each of these variables. Global variables: A global variable is one that is defined outside of a subroutine by using the tables or data statement. It can be accessed from any point in the program be it inside an event or inside a subroutine. Local variables: A local variables is a variable that is defined inside a subroutine using local data or static’s statement. It is said to be local to subroutine. The two types of parameters are: 1. Formal parameters: Parameter names that appear on the form statements are called formal parameters. Ex: FORM s1, using P1 changing P2, P3 Here P1, P2, P3 are called formal parameters. 2. Actual parameters: Parameter names that appears on the perform statement are called actual parameters. Ex: PERFORM S1 using P1 changing P2, P3. Here P1, P2, P3 are called actual parameters. CREATING TYPED AND UNTYPED PARAMETERS: Formal parameters are divided into two types: typed and untyped.

Bangalore

70

A typed parameter is a formal parameter that has a data type following its name on the form statement. Ex: Form s1 using u1 type t, value (u2) type t changing c1 type t value (c2) type t. An untyped parameter is a formal parameter that doesn’t have a data type following its definition on the form statement. Untyped formal parameters allow you to pass a variable of any data type or length to it. The formal parameters use the attributes of the actual parameter. Ex: if we pass a four byte integer to an untyped formal parameters P1. P1 becomes a four byte integer. There are three wage of passing parameters to a subroutine. 1) Pass by reference 2) Pass by value 3) Pass by value & result 1) Passing parameters by reference During subroutine call, only the address of the actual parameter is transferred to the formal parameters i.e. pointer to the original memory or address location is passed. The formal parameter has no memory of its own & we work with the fields of the calling program with in a subroutine. So changes to the variable within the subroutine update the original memory location immediately i.e. the field contents in the calling program also changes. Ex: Report xyz. Data F1 value A. Performs s1 using F1. Write: / F1.

Memory address for F1 is 1000 (Example) F1 = A before calling s1

Form s1 using P1. P1 = X. Write:/ P1. End the form

P1 – P1 is a pointer to memory location 1000 this changes memory location 1000 to X.

O/p

F1 = X after assignment in s1

P1= x F1= x

2. Passing parameters by value :

Bangalore

71

When you pass a parameters by value, new memory is allocated for the value i.e. the formal parameters are created as copies of the actual parameters, thus formal parameters have memory of their own i.e. the memory allocated when the subroutine is called and freed when the subroutine returns. Therefore changes to the formal parameters have no effect on the actual parameters. EX: Report xyz Data: F1 value A. Perform s1 using F1. Write: / F1. From s1 using value (P1) P1 =X. Write: / P1. End form.

F1 = A before call to s1 F1 = A after assignment in s1

0/P

P1 = X F1 = A

3. Passing parameters by value & result: Pass by value & result is similar to pass by reference like Pass by value, a new memory area is allocated & it frees when the subroutine ends. When the end form statement executes, it copies the value of the local memory area back into the original memory area changes to the parameter with in the subroutine are reflected in the original but not until subroutine returns. Ex: Report xyz Data: F1 value A PERFORM: S1 changing F1 S2 changing F1

Form S2 changing value (P2) P2 = ‘X’. Write: / P2. Stop. End form

End of selection Write: / F1. 0/P - P1 = B Form s1 changing value (P1) P2 = X P1 =B. Write:/ P1. F1 = B End form Leaving subroutine You can exit out of a subroutine at any time using the following statements. 1) Stop: Immediately leaves the subroutine & goes directly to the end of selection event. 2) Exit: It leaves the loop, subroutine or comes out of the program & display the result without any condition. 3) Check: It also comes or immediately leaves the subroutine but it depends on logical expression. If it is false comes out of the loop or subroutine.

Bangalore

72

FUNCTION MODULES Function modules are reusable section of codes. Functions modules generally used for global modularization. Functions modules contain functions that are used in the same form by many different programs. Functions modules must be defined in function group & called from any program. Function modules are similar to external subroutines. Function groups acts as container for function modules that logically belong together, we cannot execute function group. When we call a function module the system loads the whole of its function group into the internal session of the calling program. A single function group may contain one or more function modules which are logically related. The advantages of function modules are which helps code reusability. We can handle exceptions using functions modules. Each function group is known by a four character identifier called Function group id. If its user created function group than it’s begins with y or z. Function groups are stored in a group of tables with in the database called the function library or central library. To access the function library from the development workbench, press function library button on the application toolbar or use the transaction code SE 37. Syntax for detaining function module FUNCTION ----------------------------------------------------------------------------------------------------END FUNCTION

Syntax for all function statement Call function ‘FUNCTION MODULE NAME’ ---> function module name must be in upper case other wise it will not find and a short dump will result [Exporting P1 = V1] [Importing P2 = V2] [Changing P3 = V3] [Table P4 = IT] [Exception X2 = N [otherwise]} P1-P3 --> parameter name defined in function module

Bangalore

73

V1-V3 -->are variables or field strings defined within the calling program IT --> internal table defined with in the calling program. X2 --> exception name Function modules have the following interface parameters 1) Import parameter: A variables or filed string that contains values passed into the function module from the calling program. These values originate outside of the function module. They are imported into it. These must be supplied with data when you call the function module unless they are flagged as optional. 2) Export parameter: Are variables or field string that contains values returned from the function module. These values originate within the function module and they are exported out of it. These are also optional you may not have received in your program. 3) Changing parameter: These are variables or field string that contains values that are passed into the function module changed by code within the function module and then returned. These values originate outside the function module. They are passed into it, changed and passed back to the calling program. 4) Table parameter: These are internal tables that are passed to the function module changed within it and returned. The internal table must be defined in the calling program. 5) An exception: is a name for an error that occurs with in a function module. To pass parameters to a function module, we must define function module interface. The function module interface is the description of the parameters that are passed to and received form the function module. It is also called simply interface. Passing parameters: The methods for passing parameters to the function modules are very similar to those for passing parameters to external subroutines

By default 1) Import and Export parameter are passed by value 2) Changing parameters are passed by value and result 3) Internal tables are passed by reference. To come out of the function module at any time we use the statement called 1) RAISE ->which terminates the program and switches to debugging mode. 2) The message--->rising Bangalore

74

This statement display the specified message how the processing continues depends on the message type.

Types of functions modules There are two types of function module 1. Normal 2. Remote function call(RFC) 1. Normal: This function module is used for ABAP programming with in the system. It is normal function module. We can work within the system only. 2 .Remote function call (RFC): This function module can be called remotely by using RFC destination. Here remote means external system; it may be a SAP system or non SAP systems like java system. If it is RFC, we can work with in the system as well as across the system. Remote function modules are function modules that can be called from other SAP or non SAP systems. BAPI’S are examples of RFC MODULES Types of RFC’S 1. 2. 3. 4. 5.

Synchronous RFC Asynchronous RFC Transaction RFC Queued RFC Parallel RFC

1) Synchronous RFC: It is the very common method used in real business scenarios. Both the client and server must be available in this type of RFC. The advantage is that you can get the result immediately. Which means the RFC function module gives result or output immediately. The syntax: CALL functiondestination 2. Asynchronous RFC: Asynchronous remote function call are similar to transactional RFC’S in that the user does not have to wait for their completion before containing the calling dialog. There are three characters however that distinguish asynchronous RFC’S from transaction RFC’S 1) When the caller starts an asynchronous RFC’S the called serve must be available to accept the request. The parameters of asynchronous RFC’S are not logged to the database but sent directly to the server. Bangalore

75

2) Asynchronous RFC’s allow the user to carry on interactive dialog with remote system. 3) The calling program can receive results from the asynchronous RFC. You can use asynchronous remote function calls whenever you need to establish communication with remote system but do not want wait for the functions result before continuing processing. Asynchronous RFC can be also sent to the same System. In this case the system opens a new session (or window) and allows you to switch back and forth between calling dialog and the called session.

Subroutine 1) Subroutines are for local modularization Maximum 2) Are not remote enabled 3) No support for exception handling 4) Not stored in SAP library stored in ABAP Memory 5) Not executed directly we have embedded in ABAP program before executing

Function modules 1) It is for global modularization 2) Are remote enabled. 3) It supports exception handling 4) Stored in SAP library i.e. Functional library 5) Directly executed.

INTERACTIVE REPORTS About interactive report A classical report consists of one program that creates a single list. This means that when the list is displayed, it has to contain all the requested data, regardless of the number of details the user want to see. This procedure may result in extensive and cluttered lists Bangalore

76

from which the user has to pick the relevant data. The desired selections must be made before hand and the report must provide detailed information. This is not possible using the classical report and for this ABAP/4 has provided reporting feature called INTERACTIVE REPORT. The list produced by classical report doesn’t allow user to interact with the system but the list produced by interactive report allows the user to interact with the system i.e., user can tell the system, that he needs further information. Depending upon what the user tells the system, the action is taken. Interactive reporting thus reduces information retrieval to the data actually required. Interactive reporting allows the user to participate in retrieving and presenting data at each level during the session. Instead of presenting one extensive and detailed list with cluttered information, with interactive reporting you can create a condensed basic list from which the user can call detailed information by positioning the cursor and entering commands. Detailed information is presented in secondary lists. A secondary list may either overlay the basic list completely or appear in an additional dialog window on the same screen. The secondary list can itself be interactive again. The basic list is not deleted when secondary list is created. User can interact with the system by:  Double clicking or pressing F2  Selecting menu option Like classical report, the interactive report is also event driven. Both the action mentioned above trigger events and code is written to handle these events. The events triggered by this action are as follows:  At line-selection  At user-command  Top-of-Page During Line-Selection for Secondary Page Header info Interactive report consists of one BASIC list and 20 secondary list. Basic list is produced by START-OF-SELECTION event. When the user double clicks on the basic list or chooses the menu option, the secondary list is produced. All the events associated with classical report except end-of-page are applicable only to basic list.

Bangalore

77

AT LINE-SELECTION event Double clicking is the way most users navigate through programs. Double clicking on basic list or any secondary list triggers the event AT LINE-SELECTION. SY-LSIND denotes the index of the list currently created. For BASIC list it is always 0. Following piece of code shows how to handle the event. Start-of-selection. Write: / ‘this is basic list’. At line-selection. Write : ‘this is first secondary list’. In this case the output will be displayed on basic list i.e. This is basic list. When user double clicks on this line, the event at line-selection gets triggered and secondary list is produced, i.e. This is first secondary list. You can go back to basic list by clicking on F3 or back icon on the standard tool bar. For this list, the value of sy-lsind will be 1. HIDE technique In this case thins are much simpler. Consider the case, wherein you display fields from table sflight in basic list. When user double clicks on any sflight-carrid, you are displaying the detailed information related to that particular carrid on secondary list. Hence there is a need to store the clicked carrid in some variable. So that you can access this carrid for next list. ABAP/4 has facility; a statement called HIDE, which provides the above functionality. HIDE command temporarily stores the content of clicked field in system area.

Bangalore

78

Syntax: HIDE . This statement stores the contents of variable in relation to the current output line (system field SY-LINNO) internally in the so-called HIDE area. The variable must not necessarily appear on the current line. You have to place the HIDE statement always directly after the output statement i.e., WRITE for the variable . As when you hide the variable, control is passed to next record. While writing, WRITE statement takes that record from header and writes it on to the list, but when writing onto your interactive list you will miss out 1st record. To hide several variables, use chain HIDE statement. As soon as the user selects a line for which you stored HIDE fields, the system fills the variables in the program with the values stored. A line can be selected.  By an interactive event. For each interactive event, the HIDE fields of the line on which the cursor is positioned during the event are filled with the stored values. The HIDE area is a table, in which the system stores the names and values of all HIDE fields for each list and line number. As soon as they are needed, the system reads the values from the table. (Please try to find the name of this table.) Sy-lsind indicates the index of the list and can be used to handle all the secondary lists. When the user double clicks on the line or presses F2, sy-lsind is increased by one and this new sy-lsind can be handled. For example: Write: / ‘this is basic list’.  Will create a basic list. If sy-lsind = 1. Write: / ‘this is first secondary list’. Elseif sy-lsind = 2. Write: / ‘This is second secondary list’. Endif.

Bangalore

79

When this code is executed,

Bangalore

80

       

Basic list is produced. When the user clicks on the basic list, sy-lsind becomes one. AT LINE-SELECTION event is triggered. Whatever is written under IF Sy-lsind = 1, gets executed. Secondary list is produced. Again if user clicks on this list, sy-lsind becomes two. AT LINE-SELECTION gets triggered. Code written under IF Sy-lsind = 2, gets executed.

Example for Interactive Report Events *&---------------------------------------------------------------------* *& Report ZBASU_INTERACTIVE_REPORT_EVENT * *& * *&---------------------------------------------------------------------* *& * *& * *&---------------------------------------------------------------------* REPORT

ZBASU_INTERACTIVE_REPORT_EVENT NO STANDARD PAGE HEADING LINE-SIZE 90 LINE-COUNT 40(2).

Tables: mara, kna1, vbak, vbap. types:begin of ty_kna1, kunnr like kna1-kunnr, name1 like kna1-name1, end of ty_kna1. types:begin of ty_vbln, vbeln like vbak-vbeln, netwr like vbak-netwr, end of ty_vbln. types:begin of ty_vbap, posnr like vbap-posnr, matnr like mara-matnr, end of ty_vbap. data: it_kna1 type standard table of ty_kna1, wa_kna1 like line of it_kna1. data: it_vbln type standard table of ty_vbln, wa_vbln like line of it_vbln. data: it_vbap type standard table of ty_vbap, wa_vbap like line of it_vbap. START-OF-SELECTION. select kunnr name1 from kna1 into

corresponding fields of table

loop at it_kna1 into wa_kna1. write:/ wa_kna1-kunnr,

Bangalore

81

it_kna1.

wa_kna1-name1. hide: wa_kna1-kunnr. endloop. TOP-OF-PAGE. WRITE:/ 'GALAXE SOLUTIONS'. At line-selection. case sy-lsind. when '1'. select vbeln netwr from vbak into corresponding fields of table . loop at it_vbln into wa_vbln. write:/ wa_vbln-vbeln, wa_vbln-netwr. hide: wa_vbln-vbeln. endloop.

it_vbln

when '2'. select a~posnr b~matnr into corresponding fields of table it_vbap from vbap as a inner join mara as b on a~matnr = b~matnr. loop at it_vbap into wa_vbap. write:/ wa_vbap-posnr, wa_vbap-matnr. endloop. endcase. Top-of-page during line-selection. if sy-lsind = '1'. write:/ ' first list'. elseif sy-lsind = '2'. write:/ 'second list'. else. write:/ 'proper list no'. endif.

Bangalore

82

ALV (ABAP LIST VIEWER) Reports Sap provides a set of ALV (ABAP LIST VIEWER) function modules, which can be put into use to embellish the output of a report. This set of ALV functions is used to enhance the readability and functionality of any report output. Cases arise in sap when the output of a report contains columns extending more than 255 characters in length. In such cases, this set of ALV functions can help choose selected columns and arrange the different columns from a report output and also save different variants for report display. This is a very efficient tool for dynamically sorting and arranging the columns from a report output. The report output can contain up to 90 columns in the display with the wide array of display options. The commonly used ALV function modules are; 1. REUSE_ALV_LIST_DISPLAY 2. REUSE_ALV_GRID_DISPLAY 3. REUSE_ALV_EVENTS_GET 4. REUSE_ALV_COMMENTARY_WRITE 5. REUSE_ALV_FIELDCATALOG_MERGE The different steps used for getting the above function modules into use are described below. Step 1: DATA DECLARATION Sap standard type pools: SLIS. Sap standard tables types taken from the type pools are: SLIS_LAYOUT_ALV, SLIS_T_FIELDCAT_ALV SLIS_T_LISTHEADER, SLIS_T_EVENT, SLIS_SELFIELD. Internal tables to be used in the program declared based on the above table types TYPE-POOLS: SLIS. * To pass name of the report in function module for ALV Data: V_REPID LIKE SY-REPID. * To pass the overall structure of the ALV report Data: STRUCT_LAYOUT TYPE SLIS_LAYOUT_ALV. Bangalore

83

* Internal table to capture various events in ALV Data: I_EVENTS TYPE SLIS_T_EVENT. * Table for catalog of the fields to be displayed Data: I_FIELDCAT TYPE SLIS_T_FIELDCAT_ALV. Data: X_FIELDCAT TYPE SLIS_FIELDCAT_ALV. * Internal table to mention the sort sequence Data: IT_SORT TYPE SLIS_T_SORTINFO_ALV. Data: X_SORT TYPE SLIS_SORTINFO_ALV. * Internal table to display top of page Data: i_list_top_of_page type slis_t_listheader. * Internal table to pass data DATA: BEGIN OF I_TAB OCCURS 0, MATNR LIKE MARA-MATNR, MBRSH LIKE MARA-MBRSH, END OF I_TAB.

Step2 (Defining Output Characteristics) PREPARING DISPLAY FIELDS CATALOG A field catalog is prepared using the internal table (I_FIELDCAT) of type SLIS_T_FIELDCAT_ALV. Field catalog containing descriptions of the list output fields (usually a subset of the internal output table fields). A field catalog is required for every ALV list output to add desired functionality (i.e. Key, Hotspot, Specific headings, Justify, Col. position etc) to certain fields of the output. If not mentioned specifically, then the defaults are taken. The possible values and defaults are listed below. The minimal field catalog is documented below. This can be done in a routine using a local variable. The user can use the other optional parameters to assign output attributes to different fields in the output, which differ from the default. A field catalog need not be built-up and passed explicitly only under the following conditions: 1. The internal table to be output has the same structure as a Data Dictionary structure which is referred to in the internal table declaration using LIKE or INCLUDE STRUCTURE. In this case the attributes of the different fields is taken directly from the table and the attributes (key fields, length, texts etc) need to state explicitly. 2. All fields in this structure are to be output Bangalore

84

3. The structure name is passed to ALV in the parameter of the function module REUSE_ALV_LIST_DISPLAY or REUSE_ALV_GRID_DISPLAY. All the values entered in the catalog are specific to the particular field whose name is entered in the fieldname FIELDNAME of the fieldcat structure. The name of the table is also entered in the corr. Fieldname TABNAME of the structure. The different possible attributes are: • Col_pos (column position): This parameter is relevant when the fields in the output are to be different from the sequence of the fields in the internal table used for display. The parameter specifies the relative column position of the field in the list output. The column order can be changed interactively by the user. If this parameter is initial for all field catalog entries, columns appear in the internal table field sequence. Value set: 0, 1 – 60 • Fieldname (field name): This is the name of the internal table field for which the parameters are passed in the catalog. Value set: internal output table field name (required parameter) • Tabname (internal output table): Name of the internal output table that contains the field FIELDCAT-FIELDNAME above. • Outputlen (column width): This parameter is used if the desired output length for a field is desired to be different from the internal output table field. For fields with a Data Dictionary link this parameter can be left initial. For fields without a Data Dictionary link (program field) the parameter must be given the value of the desired field list output length (column width). Initial = column width is the output length of the referred Data Dictionary field (domain). N = column width is n characters. • Text The following parameters are used for customizing the texts in the heading of the output of the columns. The texts are taken from the Data Dictionary for fields with a Data Dictionary reference. If this is not desired, the text parameters can also be specified. The Data Dictionary texts are then ignored. If the user changes the column width interactively, the column header text with the appropriate length is always used. The interactive function 'Optimize column width' takes account of both the field contents and the column headers: if all field contents are shorter than the shortest column header, the column width depends on the column header. The 'long field label' is also used in display variant definition, Sort, etc. Popup. • seltext_l (long field label) • seltext_m (medium field label) Bangalore

85

• seltext_s (short field label)

Sample code to populate Fieldcatalog: X_FIELDCAT-COL_POS = 0. * First field to appear in ALV list X_FIELDCAT-FIELDNAME = 'MATNR'. * Name of the field in the internal table X_FIELDCAT-TABNAME = 'I_TAB'. * Name of the internal table X_FIELDCAT-OUTPUTLEN = 18. * Output Length of the field X_FIELDCAT-SELTEXT_M = 'MatItem'. * Heading for the column APPEND X_FIELDCAT TO I_FIELDCAT. CLEAR X_FIELDCAT. X_FIELDCAT-COL_POS = 1. X_FIELDCAT-FIELDNAME = 'MBRSH'. X_FIELDCAT-TABNAME = 'I_TAB'. X_FIELDCAT-SELTEXT_M = 'Industry Sector'. X_FIELDCAT-OUTPUTLEN = 50. APPEND X_FIELDCAT TO I_FIELDCAT. CLEAR X_FIELDCAT.

Step 3(Build up events table) The next step is to build an event table, which are used for firing both user commands and the system dependent events. A list of possible events is populated into an event table (I_EVENTS) when this table is passed from the function module REUSE_ALV_EVENT_GET. The return table from this function module contains all the possible events. The function module contains following import and export parameters. IMPORTING PARAMETERS: I_LIST_TYPE This parameter has possible values from 0-4. The parameter I_LIST_TYPE is of TYPE SLIS_LIST_TYPE and is DEFAULT 0 . EXPORTING PARAMETERS: I_EVENTS table. This table is of TYPE SLIS_T_EVENT and returns to the program the name of all the possible events. The table structure contains the fields: I_EVENTS-NAME: Name of the Callback event. I_EVENTS-FORM: Name of the form routine that should be called in the calling program at the event. Only events with a form routine name are processed. Bangalore

86

1. Slis_ev_user_command TYPE slis_formname VALUE 'USER_COMMAND'. As this is a frequently-used Callback event, the form routine can also be passed directly in the interface by passing the user command in the IMPORTING parameter I_CALLBACK_USER_COMMAND. 2. Slis_ev_top_of_page TYPE slis_formname VALUE 'TOP_OF_PAGE'. Equivalent to the list processing TOP-OF-PAGE event. 3. Slis_ev_top_of_coverpage TYPE slis_formname VALUE 'TOP_OF_COVERPAGE'. The selection information and list status are output together (if they exist) on a separate page by default 4. Slis_ev_end_of_coverpage TYPE slis_formname VALUE 'END_OF_COVERPAGE'. Analogously to TOP_OF_COVERPAGE the user can add other information to the information output by ALV (selection information, list status) at this event. 5. Slis_ev_pf_status_set TYPE slis_formname VALUE 'PF_STATUS_SET'. If a user list status is to be set, it must be done in the form routine assigned to this event. The ALV function codes, which must not be active, are in the Parameter RT_EXTAB. This table must be passed with the SET PF-STATUS command (with inactive user function codes as well, if necessary). Sample code for Events : FORMNAME_TOP_OF_PAGE TYPE SLIS_FORMNAME VALUE 'TOP_OF_PAGE', FORMNAME_USER_COMMAND TYPE SLIS_FORMNAME VALUE 'USER_COMMAND'. DATA: L_I_EVENT TYPE SLIS_ALV_EVENT. CALL FUNCTION 'REUSE_ALV_EVENTS_GET' EXPORTING I_LIST_TYPE = 0 IMPORTING ET_EVENTS = I_EVENTS. READ TABLE I_EVENTS WITH KEY NAME = SLIS_EV_TOP_OF_PAGE INTO L_I_EVENT. IF SY-SUBRC = 0. MOVE FORMNAME_TOP_OF_PAGE TO L_I_EVENT-FORM. APPEND L_I_EVENT TO I_EVENTS. ENDIF. READ TABLE I_EVENTS WITH KEY NAME = SLIS_EV_USER_COMMAND INTO L_I_EVENT. Bangalore

87

IF SY-SUBRC = 0. MOVE FORMNAME_USER_COMMAND TO L_I_EVENT-FORM. APPEND L_I_EVENT TO I_EVENTS. ENDIF. This will prepare the events table for the report. The report will contain three forms for the above events: 1. FORM TOP_OF_PAGE: This form will contain the top of page event for the report i.e. header etc Using the function module ‘REUSE_ALV_COMMENTARY_WRITE’, the internal table containing the headings for top of page event can be passed to the list output. Also, any logo specific to the report can be passed to the function module. 2. FORM USER_COMMAND: This form will contain the desired user command i.e. pick/line selection Step 4(Report Output list description) A layout is build for the report output list description USING the internal table declared above (I_LAYOUT). Output list description structure. The parameters are described under the following heads: • Display options • Exceptions • Totals • Interaction • Detail screen • Display variants (only for hierarchical-sequential lists) • Color • Other The layout table is of type slis_layout_alv_spec and has the following fields: Display options 1. Colwidth_optimize (1) TYPE c: This parameter optimizes the length of the different columns in the output. The width of the different col. now depends on the max. Length of the data in the column. Value set: SPACE, 'X' 'X' = optimizes the column width so that all contents are displayed completely. 2. No_colhead (1) TYPE c: This parameter suppresses the column headings Value set: SPACE, 'X'. 'X' = column headers are not output 3. Zebra(1) TYPE c : The report is output in the striped pattern. Value set: SPACE, 'X'. 'X' = striped pattern (e.g. for wide lists)

Bangalore

88

4. No_sumchoice (1) TYPE c: This parameter allows the choice for summing up Only by field catalog. Value set: SPACE, 'X' 'X' = fields which are to be summed, passed by the calling program (FIELDCATDO_SUM = 'X'). The user should not be able to change this value interactively. 5. List_append(1) TYPE c : no call screen. It is only useful to output block-lists without specifying the above modules if the number of list blocks exceeds, or may exceed, the maximum number specified in the block module documentation. These operations are not possible for user-defined block lists. Example code for Layouts : I_LAYOUT-zebra = 'X'. I_LAYOUT-colwidth_optimize = 'X'. I_LAYOUT-key_hotspot = ‘X’. Step 5(Deciding Sort Criteria) The Table IT_SORT is populated with the sort criteria for the different fields. The caller specifies the sorting and/or subtotaling of the basic list in the internal table IT_SORT. This internal table has the following fields: • spos : Sort sequence • fieldname : Internal output table field name • tabname : Only relevant for hierarchical-sequential lists. Name of the internal output table. • up : 'X' = sort in ascending order • down : 'X' = sort in descending order • subtot : 'X' = subtotal at group value change • group : '* ' = new page at group value change ,'UL' = underline at group value change Step 8(Final Step) The final step in the output of the report is the use of two ALV functions modules. 1. REUSE_ALV_FIELDCATALOG_MERGE 2. REUSE_ALV_LIST_DISPLAY The first function module is used to pass the field catalog to the report output and merge it with the internal output table. FUNCTION reuse_alv_fieldcatalog_merge. *"--------------------------------------------------------------------*"*"Lokale Schnittstelle: *” IMPORTING *" VALUE(I_PROGRAM_NAME) LIKE SY-REPID OPTIONAL *" VALUE(I_INTERNAL_TABNAME) TYPE SLIS_TABNAME OPTIONAL *" VALUE(I_STRUCTURE_NAME) LIKE DD02L-TABNAME OPTIONAL Bangalore

89

*" VALUE(I_CLIENT_NEVER_DISPLAY) TYPE SLIS_CHAR_1 default ‘X’ *" VALUE(I_INCLNAME) LIKE TRDIR-NAME OPTIONAL *" CHANGING *" VALUE(CT_FIELDCAT) TYPE SLIS_T_FIELDCAT_ALV *" EXCEPTIONS *" INCONSISTENT_INTERFACE *" PROGRAM_ERROR *"--------------------------------------------------------------------Import parameters I_PROGRAM_NAME: Program in which the internal output table is declared and populated I_INTERNAL_TABNAME: Internal output table name I_STRUCTURE_NAME: Structure name (structure, table, and view) I_CLIENT_NEVER_DISPL: Hide client fields default ‘X’ I_INCLNAME: Data declarations include name CHANGING parameter CT_FIELDCAT: Field catalog with field descriptions The variant based on a program-internal table should only be used for rapid prototyping since the following restrictions apply: 1. Performance is affected since the code of the table definition must always be read and interpreted at runtime. 2. Dictionary reference are only considered if the keywords LIKE or INCLUDE STRUCTURE (not TYPE) are used. Step 8(Display Internal Output Table) The other function module is used to display the internal output table with the contents FUNCTION reuse_alv_list_display. *"---------------------------------------------------------------------*"*"Lokale Schnittstelle: ” IMPORTING *" VALUE(I_INTERFACE_CHECK) DEFAULT SPACE *" VALUE(I_CALLBACK_PROGRAM) LIKE SY-REPID DEFAULT SPACE *" VALUE(I_CALLBACK_PF_STATUS_SET) TYPE SLIS_FORMNAME DEFAULT SPACE *" VALUE(I_CALLBACK_USER_COMMAND) TYPE SLIS_FORMNAME DEFAULT SPACE *" VALUE(I_STRUCTURE_NAME) LIKE DD02L-TABNAME OPTIONAL *" VALUE(IS_LAYOUT) TYPE SLIS_LAYOUT_ALV OPTIONAL *" VALUE(IT_FIELDCAT) TYPE SLIS_T_FIELDCAT_ALV OPTIONAL *" VALUE(IT_EXCLUDING) TYPE SLIS_T_EXTAB OPTIONAL *" VALUE(IT_SPECIAL_GROUPS) TYPE SLIS_T_SP_GROUP_ALV OPTIONAL *" VALUE(IT_SORT) TYPE SLIS_T_SORTINFO_ALV OPTIONAL *" VALUE(IT_FILTER) TYPE SLIS_T_FILTER_ALV OPTIONAL *" VALUE(IS_SEL_HIDE) TYPE SLIS_SEL_HIDE_ALV OPTIONAL Bangalore

90

*" VALUE(I_DEFAULT) DEFAULT 'X' *" VALUE(I_SAVE) DEFAULT SPACE *" VALUE(IS_VARIANT) LIKE DISVARIANT STRUCTURE DISVARIANT DEFAULT SPACE *" VALUE(IT_EVENTS) TYPE SLIS_T_EVENT OPTIONAL *" VALUE(IT_EVENT_EXIT) TYPE SLIS_T_EVENT_EXIT OPTIONAL *" VALUE(IS_PRINT) TYPE SLIS_PRINT_ALV OPTIONAL *" VALUE(IS_REPREP_ID) TYPE SLIS_REPREP_ID OPTIONAL *" VALUE(I_SCREEN_START_COLUMN) DEFAULT 0 *" VALUE(I_SCREEN_START_LINE) DEFAULT 0 *" VALUE(I_SCREEN_END_COLUMN) DEFAULT 0 *" VALUE(I_SCREEN_END_LINE) DEFAULT 0 " EXPORTING *" VALUE(E_EXIT_CAUSED_BY_CALLER) *" VALUE(ES_EXIT_CAUSED_BY_USER) TYPE SLIS_EXIT_BY_USER " TABLES *" T_OUTTAB " EXCEPTIONS *" PROGRAM_ERROR Import parameters I_INTERFACE_CHECK: Interface consistency check log output. I_CALLBACK_PROGRAM: Name of the calling program I_CALLBACK_PF_STATUS_SET: Set EXIT routine to status. I_CALLBACK_USER_COMMAND: EXIT routine for command handling I_STRUCTURE_NAME: Internal output table structure name IS_LAYOUT: List layout specifications IT_FIELDCAT: Field catalog with field descriptions IT_EXCLUDING: Table of inactive function codes IT_SPECIAL_GROUPS: Grouping fields for column selection IT_SORT: Sort criteria for first list display IT_FILTER: Filter criteria for first list output IS_SEL_HIDE: Selection information modification I_DEFAULT: Initial variant active/inactive logic I_SAVE: Variants can be saved IS_VARIANT: Variant information IT_EVENTS: Table of events to perform IT_EVENT_EXIT: Standard fcode exit requests table IS_PRINT: Print information IS_REPREP_ID: Initialization keys for Re/Re interface I_SCREEN_START_COLUMN: Coordinates for list in dialog box I_SCREEN_START_LINE: Coordinates for list in dialog box I_SCREEN_END_COLUMN: Coordinates for list in dialog box I_SCREEN_END_LINE: Coordinates for list in dialog box IT_EVENT_EXIT: Standard fcode exit requests table IS_PRINT: Print information Bangalore

91

IS_REPREP_ID: Initialization keys for Re/Re interface I_SCREEN_START_COLUMN: Coordinates for list in dialog box I_SCREEN_START_LINE: Coordinates for list in dialog box I_SCREEN_END_COLUMN: Coordinates for list in dialog box I_SCREEN_END_LINE: Coordinates for list in dialog box Export parameters E_EXIT_CAUSED_BY_CALLER: Delete list in CALLBACK_USER_COMMAND ES_EXIT_CAUSED_BY_USER: How the user left the list Tables T_OUTTAB: Table with data to be displayed ---mandatory Documentation on function module: REUSE_ALV_GRID_DISPLAY The function module outputs an internal table with whatever structure in the form of a formatted single- or multi-line list. Process: � � � The field catalog describes the fields to be output in the list. Notes � Sorting the list, for example, also involves a resorting of the internal output table passed (since it was passed by reference). � nt factor determining the usability of the tool or of various generic functions (totals, subtotals) is the expected amount of data to be displayed. Parameters : • I_INTERFACE_CHECK • I_BYPASSING_BUFFER • I_BUFFER_ACTIVE • I_CALLBACK_PROGRAM • I_CALLBACK_PF_STATUS_SET • I_CALLBACK_USER_COMMAND • I_CALLBACK_TOP_OF_PAGE • I_CALLBACK_HTML_TOP_OF_PAGE • I_CALLBACK_HTML_END_OF_LIST • I_STRUCTURE_NAME • I_BACKGROUND_ID • I_GRID_TITLE • I_GRID_SETTINGS • IS_LAYOUT • IT_FIELDCAT • IT_EXCLUDING • IT_SPECIAL_GROUPS Bangalore

92

• IT_SORT • IT_FILTER • IS_SEL_HIDE • I_DEFAULT • I_SAVE • IS_VARIANT • IT_EVENTS • IT_EVENT_EXIT • IS_PRINT • IS_REPREP_ID • I_SCREEN_START_COLUMN • I_SCREEN_START_LINE • I_SCREEN_END_COLUMN • I_SCREEN_END_LINE • IT_ALV_GRAPHICS • IT_ADD_FIELDCAT • IT_HYPERLINK • E_EXIT_CAUSED_BY_CALLER • ES_EXIT_CAUSED_BY_USER I_CALLBACK_PROGRAM: Name of the calling program Program from which the function module is called and that contains the exit routines. The program should always be a report, function group, module pool or form routine pool (it should not be an include). Caution: Never pass SY-REPID directly at the interface. If field SY-REPID contains the desired program name, you must absolutely assign this name to an auxiliary variable and pass this variable to the interface. I_CALLBACK_PF_STATUS_SET: Set EXIT runtime to status Passing an EXIT routine indicates to the ALV that the caller wants to set a self-defined user status. As a result, the default status of the ALV is not set. The interface of the form routine specified must be defined as follows: FORM set_pf_status USING rt_extab TYPE slis_t_extab Table RT_EXTAB contains the function codes that would be hidden on the standard user interface. If the caller wants to use a self-defined user interface (for example, in order to provide additional list functions or use existing functions), we recommend that you copy standard status STANDARD from function group SALV and modify it accordingly. ALV standard function codes always start with '&'. See also the documentation on parameter I_CALLBACK_USER_COMMAND. If a self-defined user interface is used that includes function codes of the standard user interface, the function codes of the excluding table passed should be taken into account. This means that the user status should generally be set as follows:

Bangalore

93

SET PF-STATUS user status EXCLUDING rt_extab. Application functions can be added to excluding table rt_extab if they are to be disabled. The routine is called whenever the standard user interface would be set with SET PFSTATUS. I_CALLBACK_TOP_OF_PAGE EXIT routine for handling TOP-OF-PAGE Description If the caller specifies an EXIT routine, this routine must have the following form: FORM top_of_page. Module REUSE_ALV_COMMENTARY_WRITE can then be called within the EXIT routine. This module is responsible for formatting the header information and also ensures online HTML formatting. In the print preview or in batch mode, the text passed is then output in the normal format. If module REUSE_ALV_COMMENTARY_WRITE cannot be used, you must use two parameters instead. In I_CALLBACK_TOP_OF_PAGE you pass the form routine that is responsible for normal formatting in batch mode or in the print preview mode. The form routine that is responsible for online formatting, is passed in parameter

Note the section on pre-defined settings. Display options • colwidth_optimize Value range: SPACE, 'X' X' = Optimizes the column width to ensure that the content is displayed completely. • no_colhead Value range: SPACE, 'X' 'X' = Do not output column headings. • zebra Value range: SPACE, 'X' 'X' = Striped pattern (for wide lists, for example) • no_vline Value range: SPACE, 'X' ‘X' = Separate columns by SPACE. You can generate the field catalog automatically or semi-automatically by calling function module REUSE_ALV_FIELDCATALOG_MERGE. See also the documentation on function module : REUSE_ALV_FIELDCATALOG_MERGE.

Bangalore

94

The minimum values required for the field catalog are documented in the 'Default' section. The caller can optionally use all other parameters to assign non-standard output attributes to a field. It is only in the following cases that you are not required to generate the field catalog and pass it explicitly: • The structure of the internal table to be output corresponds to a structure stored in the Data Dictionary and is referenced with LIKE or INCLUDE STRUCTURE in the declaration of the internal table. • All fields of this structure should be output in the list. • The structure name is declared to the ALV using parameter I_STRUCTURE_NAME. See also the documentation on IMPORTNG parameter I_STRUCTURE_NAME. Positioning • col_pos (column position) Value range: 0, 1 - 60 Only relevant if the relative column positions should by default not be identical to the sequence of the fields in the field catalog. The parameter determines the relative column position of the field in the list output. The column sequence can interactively be changed by the user. If this parameter is set to its initial value for each field catalog entry, the columns are arranged in the order of the fields in the field catalog. • fieldname (field name) • outputlen (column width) Value range: 0 (initial), n For fields with reference to the Data Dictionary you can leave this parameter set to initial. For fields without reference to the Data Dictionary (program fields) you must set the parameter to the desired field output length on the list (column width). initial = The column width is derived from the output length of the referenced field (domain) in the Data Dictionary. n = The column width is n characters. • do_sum (calculate totals for column) Value range: SPACE, 'X' 'X' = Totals are calculated for this field of the internal output table. This function can also be used interactively by the user. • no_sum (totals calculation not allowed) Value range: SPACE, 'X' Bangalore

95

'X' = No totals may be calculated for this field although the data type of the field allows totalling. Formatting column contents The long field label is also used in the dialog boxes for defining the display variant, the sort order, and so on. • seltext_l (long field label) • seltext_m (medium field label) • seltext_s (short field label) • reptext_ddic (heading)

Example Code WS_REPNAME = SY-REPID. CALL FUNCTION 'REUSE_ALV_FIELDCATALOG_MERGE' EXPORTING I_PROGRAM_NAME = WS_REPNAME I_INTERNAL_TABNAME = Internal output table field name I_INCLNAME = WS_REPNAME CHANGING CT_FIELDCAT = I_FIELDTAB. IF SY-SUBRC 0. WRITE: 'SY-SUBRC: ', SY-SUBRC, 'REUSE_ALV_FIELDCATALOG_MERGE'. ENDIF. CALL FUNCTION 'REUSE_ALV_LIST_DISPLAY' EXPORTING I_CALLBACK_PROGRAM = WS_REPNAME I_STRUCTURE_NAME = Internal output table field name IS_LAYOUT = I_LAYOUT IT_FIELDCAT = I_FIELDTAB I_DEFAULT = 'A' I_SAVE = 'A' IS_VARIANT = 'X' IT_EVENTS = I_EVENTS[] IT_SORT = I_SORT IS_SEL_HIDE = I_SELINFO TABLES T_OUTTAB = Internal output table field name. IF SY-SUBRC 0. WRITE: 'SY-SUBRC: ', SY-SUBRC, 'REUSE_ALV_LIST_DISPLAY'. ENDIF Bangalore

96

Using other function module 'REUSE_ALV_GRID_DISPLAY’ can help us get list output in the form of a grid and also attach logos to the report output. 1 Simple list output: REPORT Y_DEMO_ALV NO STANDARD PAGE HEADING. * Data to be displayed DATA: I_SFLIGHT TYPE TABLE OF SFLIGHT. *---------------------------------------------------------------------* * Selection SELECT * FROM SFLIGHT INTO TABLE I_SFLIGHT. * Call ABAP List Viewer (ALV) CALL FUNCTION 'REUSE_ALV_LIST_DISPLAY' EXPORTING I_STRUCTURE_NAME = 'SFLIGHT' TABLES T_OUTTAB = I_SFLIGHT. 2.Simple grid output: REPORT Y_DEMO_ALV_1. * * Data to be displayed DATA: I_SFLIGHT TYPE TABLE OF SFLIGHT. *---------------------------------------------------------------------* * Selection SELECT * FROM SFLIGHT INTO TABLE I_SFLIGHT. * Call ABAP List Viewer (ALV) CALL FUNCTION 'REUSE_ALV_GRID_DISPLAY' EXPORTING I_STRUCTURE_NAME = 'SFLIGHT' TABLES T_OUTTAB = I_SFLIGHT.

Bangalore

97

BATCH DATA COMMUNICATIONS/BATCH INPUT/INBOUNDOUTBOUND (BDC’s) ABOUT DATA TRANSFER Implementing a new software system takes major effort. New implementation requires moving data from the present system i.e., legacy system into the R3 system. The product, components, customers and vendors have to be available in the new system. Initial data transfer is the process of populating your R3 database with data from your legacy system. To prepare for the data transfer there are certain tasks you need to perform.  First, understand your SAP system to know which data needs to be transferred, e.g., you would not transfer any sales order if you do not use the Sales and distribution module.  Second, you need to know the contents of existing data in your legacy system. Data transfer program, an effective and efficient way of transferring large amount of data into your new system, saves time and resources. But more importantly it ensures that accurate data is transferred into R/3.

Two steps involved in data transfer are CONVERSION and SAP DATA TRANSFER.  CONVERSION, data is converted from your legacy system into the required flat file format.

Bangalore

98

 SAP DATA TRANSFER, data is automatically entered into the SAP system. A SAP data transfer program reads the prepared data from the flat file and moves it into R/3.

Steps for any data transfer Preparation for legacy database This is the first step of transfer though not associated with SAP, plays very important role in data transfer.

Before data is extracted, delete obsolete data in the legacy system and fix inconsistencies. It is easier this way, than doing it during conversion. The two steps involved in this are: Data purging: Before transferring data from legacy system, delete all the old and obsolete data, e.g.: To save conversion time and disk space, you may delete all one-time customers, vendors and all unused materials. Data cleansing: This process corrects data inconsistencies and ensures the integrity of the existing data during the transfer process. Mistakes must be fixed before the transfer.

Converting legacy data to the flat file For this second step, SAP provides no specific tools.  In the ABAP/4 development workbench, write an ABAP/4 program to convert a file from your legacy system into the required flat file structure.  Use other programming language to write conversion program. For C, COBOL, you can easily download the table definition for specific flat file structure.  Use third party tools, such as format editors and code generators, which support mapping and conversion between different file formats.  For other RDBMS like oracle, Sybase, MS access, you have EXPORT utility. By which, you can directly export data to flat file. Files will be discussed in detail in later part of the topic.

Bangalore

99

Getting the data into R/3 This step actually transfers data to SAP database. After converting the data into the flat file you are ready to begin the third step of the data transfer. Data transfer is an interactive process. You may often feel like you are taking two steps forward and one step back. For example, short steps involved in whole process are as follows:     

Convert the data from the legacy system into the flat file format. Run the data transfer program. Check data for error. Is the transfer working as it was designed? If not, adjust the data/conversion program and start with step 1. Go back to step one, if you don’t get the desired result.

You have three different options to enter your data into R/3.  Automatically, with SAP standard data transfer programs.  Automatically, by creating your own branch input programs  Manually, by entering the data via the corresponding online transaction.

Automatic transfer with a standard data transfer program This can be done if:    

A standard program exists for the data transfer of a business object in R/3. The data is available in electronic form. There is a significant number of records you want to transfer. The cost of converting the legacy data into the required flat file format is acceptable.

Manually transferring business objects You should manually transfer data, if:  You have no legacy system.  There is only small number of records to enter.  Translating legacy data into the R/3 structure is more an effort than manually entering the data.

Bangalore

100

Using customer specific batch input to transfer business objects Create batch input program to transfer data if:    

No standard program exists to transfer the business object in R/3. The data is available in electronic form. There is a significant number of records you want to transfer. Translating your legacy data into the structure required by your custom program is easier than manually entering data.

 Batch input is a standard procedure for transferring large amount of data into the R/3 system. It simulates manual data entry. Data consistency is ensured because batch input uses all the checks conducted on the normal screen. Using batch input is like entering the data online. Another advantage to batch input is that you do not have to check the data in advance.

Batch input is a two-step procedure. It involves a program that creates the batch input session. This session is the data file that includes everything to begin the transaction and the data to be entered on the appropriate screens. The data is not yet in the database tables of R/3 application. The second step is to process the session, which then actually transfers the data to database table. You can transfer data directly to database table by using CALL TRANSACTION method also. Another method - Direct Input, is done for high volume of data for the standard application. All these methods are discussed in detail in later part of the topic. Basically there are two steps involved in any transfer of data from legacy system to SAP system. -

Creation of file and transferring file into SAP system Transferring data to database file

Whenever, you create flat file following points should be considered: -

Provide the data in an ASCII/Text file format. Know how each line of the file is structured. Know how the required flat file for the business object must be structured. Once your flat file is ready, the data should be transferred into SAP system.

Handling of local files Introduction Bangalore

101

Files on presentation server / workstation are LOCAL FILES. Local files are processed using UPLOAD and DOWNLOAD functions. The local files are brought into ABAP/4 memory using these functions. Unlike dataset, all the records of the file are UPLOADED into an internal table in one shot. Similarly, all records are DOWNLOADED in one shot from an internal table to a local file.

DOWNLOAD function: Important EXPORTING parameters for this function are: Filename = name of the local file to which the internal table is to be downloaded. Filetype = file type, default values are ASC, DAT, BIN Mode = Write mode, overwrite (‘ ‘) or append (‘A’) Important IMPORTING parameters are: Filename = actual file name entered Tables to be passed to the function: Data_tab = the internal table that is to be downloaded. Similar function called GUI_DOWNLOAD is used to download the information from internal table to local file. UPLOAD function

Upload function is used to upload the local file to internal table into SAP system. For uploading, you have similar function called GUI_UPLOAD.

Files with multiple record types Many times the input files will have records with different structures. In all such cases each record will have a field, (usually the first) which identifies the record (e.g., ‘H’ for header, ‘D’ for detail or ‘1’ & ‘2’ etc). Text tile with multiple record types would be as mentioned below: Hxxxxyyyyyyyynnnnnnnnn Daaaaaaaaaabbbbbbbbbcccccccc Daaaaaaaaaabbbbbbbbbbcccccccc Hxxxxyyyyyyynnnnnnnnnnn Daaaaaaaaaabbbbbbbbbbcccccccc Bangalore

102

Daaaaaaaaaabbbbbbbbbbcccccccc

Processing Text file with multiple record types: To process such files, it is necessary to first read the record into a character field that is a minimum of the lengths of the different structure in the file. If ‘H’ type record is 30 char long (including the record identifier) and ‘D’ type is 40 long (including the record identifier), then this character field should be at least 40 char long.

BATCH DATA COMMUNICATION

About Data Transfer In R/3 System When a company decides to implement the SAP R/3 to manage business-critical data, it usually does not start from a no-data situation. Normally, a SAP R/3 project comes into replace or complement existing application. In the process of replacing current applications and transferring application data, two situations might occur:  The first is when application data to be replaced is transferred at once, and only once.  The second situation is to transfer data periodically from external systems to SAP and vice versa.  There is a period of time when information has to be transferred from existing application, to SAP R/3, and often this process will be repetitive. The SAP system offers two primary methods for transferring data into SAP systems. From non-SAP systems or legacy system. These two methods are collectively called “batch input” or “batch data communication”.

1. SESSION METHOD 2. CALL TRANSACTION

Bangalore

103

3. DIRECT INPUT Advantages offered by BATCH INPUT method: 1.

Can process large data volumes in batch.

2.

Can be planned and submitted in the background.

3.

No manual interaction is required when data is transferred.

4.

Data integrity is maintained as whatever data is transferred to the table is through transaction. Hence batch input data is submitted to all the checks and validations.

To implement one of the supported data transfers, you must often write the program that exports the data from your non-SAP system. This program, known as a “data transfer” program must map the data from the external system into the data structure required by the SAP batch input program. The batch input program must build all of the input to execute the SAP transaction. Two main steps are required:  To build an internal table containing every screen and every field to be filled in during the execution of an SAP transaction.  To pass the table to SAP for processing. Prerequisite for Data Transfer Program

Writing a Data Transfer Program involves following prerequisites:

Analyzing data from local file Analyzing transaction Analyzing transaction involves following steps:     

The transaction code, if you do not already know it. Which fields require input i.e., mandatory. Which fields can you allow to default to standard values. The names, types, and lengths of the fields that are used by a transaction. Screen number and Name of module pool program behind a particular transaction.

To analyze a transaction:

Bangalore

104

 Start the transaction by menu or by entering the transaction code in the command box. (You can determine the transaction name by choosing System – Status.)  Step through the transaction, entering the data will be required for processing your batch input data.  On each screen, note the program name and screen (dynpro) number. (dynpro = dyn + pro. Dyn = screen, pro = number)  Display these by choosing System – Status. The relevant fields are Program (dynpro) and Dynpro number. If pop-up windows occur during execution, you can get the program name and screen number by pressing F1 on any field or button on the screen. The technical info pop-up shows not only the field information but also the program and screen.  For each field, check box, and radio button on each screen, press F1 (help) and then choose Technical Info. Note the following information: -

The field name for batch input, which you’ll find in its own box. The length and data type of the field. You can display this information by double clicking on the Data Element field.

 Find out the identification code for each function (button or menu) that you must execute to process the batch-input data (or to go to new screen). Place the cursor on the button or menu entry while holding down the left mouse button. Then press F1. In the pop-up window that follows, choose Technical info and note the code that is shown in the Function field. You can also run any function that is assigned to a function key by way of the function key number. To display the list of available function keys, click on the right mouse button. Note the key number that is assigned to the functions you want to run. Once you have program name, screen number, field name (screen field name), you can start writing. DATA TRANSFER program.

Bangalore

105

Declaring internal table First Integral Table similar to structure like local file.

Declaring internal table like BDCDATA The data from internal table is not transferred directly to database table, it has to go through transaction. You need to pass data to particular screen and to particular screenfield. Data is passed to transaction in particular format, hence there is a need for batch input structure. The batch input structure stores the data that is to be entered into SAP system and the actions that are necessary to process the data. The batch input structure is used by all of the batch input methods. You can use the same structure for all types of batch input, regardless of whether you are creating a session in the batch input queue or using CALL TRANSACTION.

This structure is BDCDATA, which can contain the batch input data for only a single run of a transaction. The typical processing loop in a program is as follows:  Create a BDCDATA structure  Write the structure out to a session or process it with CALL TRANSACTION USING; and then  Create a BDCDATA structure for the next transaction that is to be processed. Within a BDCDATA structure, organize the data of screens in a transaction. Each screen that is processed in the course of a transaction must be identified with a BDCDATA record. This record uses the Program, Dynpro, and Dynbegin fields of the structure. The screen identifier record is followed by a separate BDCDATA record for each value, to be entered into a field. These records use the FNAM and FVAL fields of the BDCDATA structure. Values to be entered in a field can be any of the following:  Data that is entered into screen fields.  Function codes that are entered into the command field. Such function codes execute functions in a transaction, such as Save or Enter.  The BDCDATA structure contains the following fields:  PROGRAM: Name of module pool program associated with the screen. Set this field only for the first record for the screen. Bangalore

106

 DYNPRO: Screen Number. Set this field only in the first record for the screen.  DYNBEGIN: Indicates the first record for the screen. Set this field to X, only for the first record for the screen. (Reset to ‘ ‘ (blank) for all other records.)  FNAM: Field Name. The FNAM field is not case-sensitive.  FVAL: Value for the field named in FNAM. The FVAL field is case-sensitive. Values assigned to this field are always padded on the right, if they are less than 132 characters. Values must be in character format. Transferring data from local file to internal table Data is uploaded to internal table by UPLOAD of WS_UPLOAD function.

Population of BDCDATA For each record of internal table, you need to populate Internal table, which is similar to BDCDATA structure. All these five initial steps are necessary for any type of BDC interface. DATA TRANSFER program can call SESSION METHOD or CALL TRANSACTION. The initial steps for both the methods are same. First step for both the methods is to upload the data to internal table. From Internal Table, the data is transferred to database table by two ways i.e., Session method and Call transaction.

SESSION METHOD About Session method In this method you transfer data from internal table to database table through sessions. In this method, an ABAP/4 program reads the external data that is to be entered in the SAP System and stores the data in session. A session stores the actions that are required to enter your data using normal SAP transaction i.e., Data is transferred to session which in turn transfers data to database table. Session is intermediate step between internal table and database table. Data along with its action is stored in session i.e., data for screen fields, to which screen it is passed, the program name behind it, and how the next screen is processed.

Bangalore

107

When the program has finished generating the session, you can run the session to execute the SAP transactions in it. You can either explicitly start and monitor a session or have the session run in the background processing system. Unless session is processed, the data is not transferred to database table.

BDC_OPEN_GROUP You create the session through program by BDC_OPEN_GROUP function. Parameters to this function are:    

User Name: User name Group: Name of the session Lock Date: The date on which you want to process the session. Keep: This parameter is passed as ‘X’ when you want to retain session after processing it or ‘ ‘to delete it after processing.

BDC_INSERT This function creates the session & data is transferred to Session. Parameters to this function are:  Tcode:  Dynprotab:

Transaction Name BDC Data

BDC_CLOSE_GROUP This function closes the BDC Group. No Parameters.

Some additional information for session processing When the session is generated using the KEEP option within the BDC_OPEN_GROUP, the system always keeps the sessions in the queue, whether it has been processed successfully or not. However, if the session is processed, you have to delete it manually. When session processing is completed successfully while KEEP option was not set, it will be removed automatically from the session queue. Log is not removed for that session. If the batch-input session is terminated with errors, then it appears in the list of INCORRECT session and it can be processed again. To correct incorrect session, you can Bangalore

108

analyze the session. The Analysis function allows to determine which screen and value has produced the error. If you find small errors in data, you can correct them interactively, otherwise you need to modify batch input program, which has generated the session or many times even the data file.

CALL TRANSACTION

About CALL TRANSACTION A technique similar to SESSION method, while batch input is a two-step procedure, Call Transaction does both steps online, one after the other. In this method, you call a transaction from your program by Call transaction using Mode Update Messages into . Parameter – 1 is transaction code. Parameter – 2 is name of BDCTAB table. Parameter – 3 here you are specifying mode in which you execute transaction A is all screen mode. All the screen of transaction are displayed. N is no screen mode. No screen is displayed when you execute the transaction. E is error screen. Only those screens are displayed wherein you have error record. Parameter – 4 here you are specifying update type by which database table is updated. S is for Synchronous update in which if you change data of one table then all the related Tables gets updated. And sy-subrc is returned i.e., sy-subrc is returned for once and all. A is for Asynchronous update. When you change data of one table, the sysubrc is returned. And then updating of other affected tables takes place. So if system fails to update other tables, still sy-subrc returned is 0 (i.e., when first table gets updated).

Bangalore

109

Parameter – 5 when you update database table, operation is either successful or unsuccessful or operation is successful with some warning. These messages are stored in internal table, which you specify along with MESSAGE statement. This internal table should be declared like BDCMSGCOLL, a structure available in ABAP/4. It contains the following fields: 1. Tcode:

Transaction code

2. Dyname:

Batch point module name

3. Dynumb: Batch input Dyn number 4. Msgtyp:

Batch input message type (A/E/W/I/S)

5. Msgspra: Batch input Lang, id of message 6. Msgid:

Message id

7. MsgvN:

Message variables (N = 1 - 4)

For each entry, which is updated in database, table message is available in BDCMSGCOLL. As BDCMSGCOLL is structure, you need to declare a internal table which can contain multiple records (unlike structure).

Steps for CALL TRANSACTION method 1.

Internal table for the data (structure similar to your local file)

2.

BDCTAB like BDCDATA

3.

UPLOAD or WS_UPLOAD function to upload the data from local file to itab. (Considering file is local file)

4.

Loop at itab. Populate BDCTAB table. Call transaction using Mode Update . Refresh BDCTAB.

Bangalore

110

Endloop.

(To populate BDCTAB, You need to transfer each and every field)

The major differences between Session method and Call transaction are as follows:

SESSION METHOD

CALL TRANSACTION

1.

Data is not updated in database table unless Session is processed.

Immediate updation in database table.

2.

No sy-subrc is returned.

Sy-subrc is returned.

3.

Error log is created for error records.

Errors need to be handled explicitly

4.

Updation in database table is always synchronous

Updation in database table can be synchronous Or Asynchronous.

Error Handling in CALL TRANSACTION When Session Method updates the records in database table, error records are stored in the log file. In Call transaction there is no such log file available and error record is lost unless handled. Usually you need to give report of all the error records i.e., records which are not inserted or updated in the database table. This can be done by the following method: Steps for the error handling in CALL TRANSACTION

1.

Internal table for the data (structure similar to your local file)

2.

BDCTAB like BDCDATA

3.

Internal table BDCMSG like BDCMSGCOLL

Bangalore

111

4.

Internal table similar to Ist internal table (Third and fourth steps are for error handling)

5.

UPLOAD or WS_UPLOAD function to upload the data from the local file to itab. (Considering file is local file)

6.

Loop at itab. Populate BDCTAB table. Call transaction using Mode Update Messages . Perform check. Refresh BDCTAB. Endloop.

7

Form check. IF sy-subrc 0. (Call transaction returns the sy-subrc if updating is not successful). Call function Format_message. (This function is called to store the message given by system and to display it along with record) Append itab2. Display the record and message.

Common batch input errors -

The batch input BDCDATA structure tries to assign values to fields which do not exist in the current transaction screen. The screen in the BDCDATA structure does not match the right sequence, or an intermediate screen is missing.

Bangalore

112

-

-

On exceptional occasions, the logic flow of batch input session does not exactly match that of manual online processing. Testing the sessions online can discover by this. The BDCDATA structure contains fields, which are longer than the actual definition. Authorization problems.

RECORDING A BATCH INPUT A B recording allows you to record a R/3 transaction and generate a program that contains all screens and field information in the required BDC-DATA format. You can either use SHDB transaction for recording or SYSTEM  SERVICES  BATCH INPUT  EDIT And from here click recording. Enter name for the recording. (Dates are optional) Click recording. Enter transaction code. Enter. Click Save button. You finally come to a screen where, you have all the information for each screen including BDC_OKCODE.  Click Get Transaction.  Return to BI.  Click overview.  Position the cursor on the just recorded entry and click generate program.  Enter program name.  Click enter The program is generated for the particular transaction.

AN EXAMPLE WITH SESSION METHOD Following program demonstrates how data is passed from flat file to SAP transaction and further to database table by using SESSION method. The transaction is TFBA (to change customer). Bangalore

113

A simple transaction where you are entering customer number on first screen and on next screen data is displayed for the particular customer number. Field, which we are changing here, are name and city. When you click on save, the changed record gets saved. Prerequisite to write this BDC interface as indicated earlier is: 1. To find screen number 2. To find screen field names, type of the field and length of the field. 3. To find BDC_OKCODE for each screen 4. Create flat file. Flat file can be created in your hard disk as follows: 1

Vinod Krishna

Hyderabad

2

Kavitha

Secunderabad

3

Kishore

Hyderabad

(Where 1st character field is Customer number, 2nd field is Customer name and 3rd field is City.) To transfer this data to database table SCUSTOM following interface can be used. REPORT DEMO1. * Following internal table is to upload flat file. DATA: BEGIN OF ITAB OCCURS 0, ID(10), NAME(25), CITY(25), END OF ITAB. *Following internal table BDCDATA is to pass date from internal table to session. DATA: BDCTAB LIKE BDCDATA OCCURS 0 WITH HEADER LINE. * Variables DATA: DATE1 LIKE SY-DATUM. DATE1 = SY-DATUM - 1. “ This is for Hold Date * To upload flat file to internal table. CALL FUNCTION UPLOAD EXPORTING = ‘C:\FF.TXT’

FILE NAME

Bangalore

114

= ‘ASC”

FILE TYPE TABLES DATA_TAB

= ITAB

EXCEPTIONS CONVERSION_ERROR

=1

INVALID_TABLE_WIDTH

=2

INVALID_TYPE

=3

NO_BATCH

=4

UNKNOWN_ERROR

=5

OTHERS

= 6.

If sy-subrc = 0. * Calling Function to Create a Session CALL FUNCTION ‘BDC_OPEN_GROUP’ EXPORTING CLIENT

= SY-MANDT

GROUP

= ‘POTHURI’

HOLDDATE

= DATE1

KEEP

= ‘X’

USER

= SY-UNAME

EXCEPTIONS

Bangalore

CLIENT_INVALID

=1

DESTINATION_INVALID

=2

GROUP_INVALID

=3

GROUP_IS_LOCKED

=4

HOLDDATE_INVALID

=5

INTERNAL_ERROR

=6

QUEUE_ERROR

=7

RUNNING

=8

SYSTEM_LOCK_ERROR

=9

USER_INVALID

= 10

OTHERS

= 11.

115

If sy-subrc = 0. *-------------------------- MAIN Logic-----------------------------LOOP AT ITAB PERFORM GENERATE_DATA. “ Populating BDCDATA Table CALL FUNCTION ‘BDC_INSERT’ EXPORTING = ‘TFBA’

TCODE TABLES DYNPROTAB

= BDCTAB

EXCEPTIONS INTERNAL_ERROR

=1

NOT_OPEN

=2

QUEUE_ERROR

=3

TCODE_INVALID

=4

PRINTING_INVALID

=5

POSTING_INVALID = 6 OTHERS

= 7.

REFRESH BDCTAB ENDLOOP. * Calling function to close the session CALL FUNCTION ‘BDC_CLOSE_GROUP’ EXCEPTIONS NOT_OPEN

=1

QUEUE_ERROR

=2

OTHERS

= 3.

Endif. Endif. *&--------------------------------------------------------------------* *& Form GENERATE_DATA *

Create BDC Data

*&--------------------------------------------------------------------*

Bangalore

116

FORM GENERATE_DATA * Passing information for 1st screen on BDCDATA BDCTAB-PROGRAM = ‘SAPMTFBA’. BDCTAX-DYNPRO = 100. BDCTAP-DYNBEGIN = ‘X’. APPEND BCDTAB.CLEAR BDCTAB. * Passing field information to BDCDATA BDCTAB-FNAM = ‘SCUSTOM-ID’ BDCTAB-FVAL = ITAB-ID. APPEND BDCTAB.CLEAR BDCTAB. * Passing BDC_OKCODE to BDCDATA BDCTAB-FNAM = ‘BDC_OKCODE’. BDCTAB-FVAL = ‘/5’. APPEND BDCTAB.CLEAR BDCTAB. * Passing screen information for next screen to BDCDATA BDCTAB-PROGRAM = ‘SAPMTFBA’. BDCTAB-DYNPRO = 200. BDCTAB-DYNBEGIN = ‘X’. APPEND BDCTAB.CLEAR BDCTAB. * Passing screen information to BDCDATA BDCTAB-FNAM = ‘SCUSTOM-NAME’. BDCTAB-FVAL = ITAB-NAME. APPEND BDCTAB.CLEAR BDCTAB. * Passing screen information to BDCDATA BDCTAB-FNAM = ‘SCUSTOM-CITY’. BDCTAB-FVAL = ITAB-CITY. APPEND BDCTAB.CLEAR BDCTAB. * Passing BDC_OKCODE to BDCDATA BDCTAB-FNAM = ‘BDC_OKCODE’. BDCTAB-FVAL = ‘SAVE’. APPEND BDCTAB.CLEAR BDCTAB.

Bangalore

117

ENDFORM.

“GENERATE_DATA

AN EXAMPLE WITH CALL TRANSACTION Same steps to be repeated for CALL TRANSACTION The only difference between the two types of interface is in Session method, you create session and store information about screen and data into session. When session is processed the data is transferred to database. While in CALL TRANSACTION, data is transferred directly to database table. REPORT DEMO1. * Follow above Code till MAIN Logic. Even the Subroutine should be copied LOOP AT ITAB PERFORM GENERATE_DATA, “Populating BDCDATA Table Call transaction ‘TFBA’ using BCDDATA Mode ‘A’ Update ‘S’. REFRESH BDCTAB ENDLOOP.

TRANSACTIONS GENERAL INTRODUCTION TO TRANSACTION Transaction, in R/3 system is an operation that lets the user make necessary changes to the database. The entire R/3 system is nothing but set of business transaction. The data transfer from old system to SAP R/3 database, or modifying data, or deleting data, which is not required, is done through transaction.

Bangalore

118

For SAP system, Transaction is nothing but sequence of steps called as dialog steps and for user it is sequence of screens that appears one after the other depending upon the option he selects. The special transaction monitor called the SAP dispatcher handles the sequence of steps that takes place in any transaction. The main task of transaction is to update database table. The database table is not updated until a transaction is completed. All changes can be rolled back if the transaction has not finished. The transaction contains two steps which are as following: 

Interactive phase: In this step, user enters the data, which needs to be inserted or deleted or modified on to the screen. There can be single screen or multiple screens depending upon the transaction. So this step can consist of single step or multiple steps. In this phase you prepare database record.



Update phase: This phase processes the database record and updates the database table. Actual updating of database table takes place in this phase.

All the transactions are associated with transaction code. And all these codes are stored in a table TSTC. Logical Unit of Work (LUW) The R/3 system is multi user system and many users access the same information at the same time, which is mainly DATA. Consider the case where one user is modifying a record, and second user is trying to delete the same record. If the second user is successful in deleting the record then the first user will face problem for modifying the record that is already deleted. The avoid such situation, R/3 system has provided Logical Unit of Work, which is defined as a locking mechanism to protect transaction integrity. Of course, there are other measures, which ensures data integrity like check table i.e. foreign key relationship. Within SAP system there are three types of transaction and may be distinguished as: 



Database transaction known as LUW. It can be defined as a period in which operation requested must be performed as a unit, i.e. all or nothing operation. At the end of LUW, either of the database changes are committed or rolled back. Update transaction or SAP LUW. One SAP LUW can have several databases LUW. So a set of a database is either committed or rolled back. The special ABAP/4 command COMMIT WORK, marks the end of a SAP LUW.

Bangalore

119



ABAP/4 transaction. Is made up of a set of related task combined under one transaction code. ABAP/4 transactions are for programming environment, in which ABAP/4 transaction functions like one complete object containing screens, menus and transaction codes.

R/3 system has provided in built locking mechanism, which defines the Logical Unit of Work. Also user can set his own locking mechanism. The LUW starts when a lock entry in the system table is created, and it ends when the lock is released. To provide the user the facility to communicate with the table in order to modify or delete or insert data, R/3 has provided tool called SCREEN PAINTER. This tool allows you to design screen, process screen through program and update the database table. SAP has provided one and only one way to update the database table, i.e. transaction. Though you can update database table by using open SQL statement through program, SAP usually doesn’t recommend this kind of updating. Many standard transactions are available to update standard table but if the need arises, the developer should be able to develop new transaction, which allows the updating of database tables. This can be achieved by using various components of screen painter. Following are the few concepts and steps for creating entire new transaction.

DYNPRO concept A dynpro refers to the screen + flow logic. With screen painter you can develop screen and flow logic. The relationship between screen, flow logic, and program can be shown as follows: Flow logic

Screen 100 Module Pool Program Flow logic

Screen 200

Flow logic

Bangalore

120

Dynpro, as figure indicates consist of screen and flow logic and places exactly one call to module pool program. A transaction consists of many screens and for each screen flow logic is attached. When the transaction is executed, the screen places a call to flow logic and flow logic in turn places a call to module pool program.  



A module program is usual ABAP/4 program that consist of modules and data declaration. ABAP/4 is an event driven language. In module pool program too, events get triggered and these events are handled in flow logic. Flow logic editor is subset of ABAP/4 editor. The system automatically displays the two important events for the flow logic. Screen is the important component of dynpro and can be created, designed by screen painter.

Screen Painter A screen painter can be started by Development workbench  Screen Painter Or SE51 transaction code.

Using Screen Painter The process of creating a dynpro includes the creation and definition of all the needed screen components. The steps involved in creating the dynpro are as follows:    

Create screen and attributes by using screen attribute screen. Select and place the needed fields within the screen by using dict/program fields. Establish the field attributes to which the screen belongs by using field list. Define the flow logic respect to the transaction to which it belongs by using flow logic.

Creating a new Screen Steps involved are as follows:  Enter the name of program and number of the screen  Click on Create  On “screen attribute” screen enter short description  Enter screen type. Normally, you select NORMAL option for usual R/3 screen. Other options available are SUBSCREEN & MODAL DIALOG BOX. Modal dialog box is used to establish independent and interactive dialog box while subscreen is screen within screen.

Bangalore

121



Next attribute to be passed is NEXT SCREEN. Here you need to specify the next screen number, which must be processed after the current one.

Designing of Screen Screen can be designed by using FULL SCREEN EDITOR. You can go to full screen editor. From screen attribute screen By pressing full screen editor pushbutton Or From initial screen of screen painter. There are two modes available with full screen editor.  

Graphical mode. The graphical mode works similarly to typical window application. Alphanumeric mode (rarely used).

Elements of screen         

Text – Standard text or field labels. Entry - display field. Radiobutton – All radiobutton must be associated with one group. Checkbox – Normally used for YES/NO operations. Pushbutton – Used for activating particular function. Boxes – grouping together many screen elements. Subscreens – This is a screen area in which you can display another screen. Table controls – This area of screen is similar to table but should be treated as a loop. Status - Display output fields containing icon.

All these elements are on the control bar of full screen editor and can be placed on the screen work area by clicking and placing them wherever needed.

Selecting Screen Fields Screen field can be either dictionary objects or program fields. Steps involved in the placing of fields on the screen are as follows: Click the pushbutton Dict/program fields on the full screen editor Or Goto  dict/prog fields. Bangalore

122

    

Enter table name. Click Get from dictionary. Select fields. Click copy pushbutton. Position the cursor where you want those fields to be placed.

To adjust various screen elements, you can use drag and drop facility for screen elements.

Attributes of Screen Elements The entire element of a screen has some attributes, which determines their behavior.    

General – These attributes are directly managed by the screen painter like name of the element, or text of element or column width and various things associated with the screen. Dictionary – These attributes are applicable to fields, which are from dictionary. Various components of dictionary can be attached to this element like search help, foreign key. Program. Display – Behavior of the element with respect to their display feature.

Attribute dialog box can be displayed by  

Clicking on the ATTRIBUTE push button on the application tool bar. Double clicking on the element.

Field List This list displays a list of all screen elements together with their screen attributes. One important element of Field list is OKCODE. Any pushbutton is associated with function code as in menu item in menu painter. When the user clicks the pushbutton this code is stored in OKCODE. This OKCODE is created by system without a name and is not visible on the screen. In ABAP/4 this field is work field and is nothing but an area wherein system stores the variable and is the last field of the field list and is invisible, hence user needs to give the name OKCODE. It is not mandatory to give the name OKCODE; developer can give any name to this field.

Bangalore

123

Screen Flow Logic You can go to this screen either by Initial screen of Screen painter  Flow logic Or From Screen attribute screen  Flow logic When transaction is executed, the screen is displayed, user enters few fields, selects few functions. Later the screen is processed and processing of screen is done by flow logic. The events that are associated with screen are as follows:    

Process before Output (PBO) Process after input (PAI) Process on value request (POV) Process on help request (POH)

The system automatically displays two very important events or modules in flow logic i.e. PAI and PBO PBO event This event is triggered before the screen is displayed. The processing of screen before the display of screen is done in this event. For example, filling in default values in the screen fields. PAI event This event is responsible for processing of screen after the user enters the data and clicks the pushbutton. The processing of screen can include displaying another screen, or just displaying list or quitting the transaction itself and many more things. Usually it is displaying another screen. These operations can be carried out in the PAI event. OKCODE plays an important role in this operation. POV event Process on value request is triggered when the user clicks F4 key. You can handle this event when the user presses F4 key by writing code for the same in module pool program. Normally when the user presses F4, list of possible values is displayed. The standard list produced by system is adequate for applications you develop yourself. However, you can also have the option of setting up your own documentation and lists of possible values that are more detailed. Bangalore

124

POH event Normally when the user places the cursor on the field and presses F1 function key, the system displays its own Help for that particular field. You can add your own functionality to the Help button by writing code for the same in the POH event.

Module Pool Programming This component though is not attached to the screen painter, plays important role in transaction. Normally, for reports, on line executable programs are written but for transaction, Module Pool Programs are written. The module pool program contains only modules to handle various events associated with screen and data declaration statements. System divides the module pool program into several include program. These are global field, PBO modules, and PAI modules. It is entirely user’s decision whether to use these modules or write directly into main program.

Creation of Module Pool Program You can create module pool program either through Object browser System automatically creates the module pool program and for these program which are created through object browser, system creates the include modules. Or ABAP/4 editor It is similar to normal program creation. Type of program should be given ‘M’ and is not created by system.

Communication between Dynpro and Module Program For each screen, the system executes the flow logic, which contains corresponding events. The control is passed to Module Pool Program. Module Pool Program handles the code for these events and again passes back control to the flow logic and finally to screen. Unlike on line program, in this case, the control remains with flow logic. The switching of control between flow logic and module pool program and back is common process when user executes transaction. Bangalore

125

Creation of a Complete Transaction

Steps involved to create a complete transaction          

Create module pool program. From screen painter create screens. Write flow logic for each screen. Write code for all the events in module pool program. Check for any error in screen and flow logic. Generate each and every component of screen i.e. flow logic and screen. Single screen can be tested using Screen Painter. Create transaction code through object browser. Generate the transaction code. User can execute the transaction by entering the transaction code in the command field.

Handling Function Code The function code or OKCODE is the last field of Field list. Function code can be handled as follows: During the Designing of the screen, a function code is assigned to pushbutton.   

In field list, developer needs to specify OKCODE as last field. In module program it is a global field and can be evaluated in the PAI event. A function code is treated in the same way, regardless it comes from pushbutton, menu item or any other GUI element.

A complete example for transaction is shown below: If you have a screen like the one below:

Bangalore

126

When the user clicks on the Display button, you want to display details of sflight, with corresponding carrid and connid (which is entered by the user). Module pool program to handle this particular screen is as follows: Program YVTEST7. TABLES: SFLIGHT. DATA: OKCODE (4). MODULE INPUT1 INPUT, CASE OKCODE. WHEN ‘DISP’. SELECT * FROM SFLIGHT WHERE CARRID = SFLIGHT – CARRID AND CONNID = SFLIGHT – CONNID. ENDSELECT. LEAVE TO SCREEN 200. WHEN ‘EXIT’. LEAVE TO SCREEN 0. ENDCASE. ENDMODULE. “INPUT1 INPUT MODULE USER_COMMAND_0200 INPUT. CASE OKCODE. WHEN ‘BACK’. LEAVE TO SCREEN 100. ENDCASE. ENDMODULE. “USER_COMMAND_0200 INPUT When the user clicks on display, control is transferred to screen no. 200 on which you display sflight details & on the same screen, when user clicks on BACK button, he comes back to main screen. Flow logic for screen 100 is as follows: Bangalore

127

PROCESS AFTER INPUT. MODULE INPUT. Flow logic for screen 200 PROCESS AFTER INPUT. USER_COMMAND_0200. MODULES: Modules are handled in module pool program. You need to write flow logic for screen 200 and design screen 200. In case of transaction transfer of data from program to screen is automatic i.e. you need not transfer the data from program to screen explicitly. The fields, which you define in the screen receives the data from program and displays the same.

The Field Checks As already mentioned Transaction is the only method, which SAP recommends to update the database tables. Data entered in the database table should be valid and correct. Data entered is validated at each and every point. ABAP/4 offers various methods to validate data and those are as follows:   

Automatic field checks Checks performed in the flow logic Checks performed in the ABAP/4 module pool program

Automatic Field Checks These checks are based on the field information stored in the dictionary. These checks are performed by the system automatically when the user enters the data for the screen field. System performs these checks before PAI event is triggered. Types of field checks performed by system are as follows:  Required input While designing the screen, for particular screen field if you click the Req. Entry checkbox, the field becomes mandatory. When the transaction is executed if user leaves this particular field blank, the system displays error message. User cannot proceed until the user enters some data.  Proper Data Format

Bangalore

128

Each field has its own data format whether it is table field or screen field. Whenever data is entered, system checks for the proper format of the data. For example date. Each user has its own format for date, which is defined in the user master record. If the date defined in the user master record is in the format DD/MM/YYYY, if the user enters the date, say, in YY/DD/MM, the user displays the error message. System also checks for the value of month or days. For example if month entered is greater than twelve then the error message is displayed.  Valid Value for the Field In data dictionary two tables are related by Primary key-Foreign key relationship. Whenever the user enters the data, the system checks for the check table values. Also in Domain, if you have fixed values, then the system checks for these values. Automatic field checks are repeated each time the user enters the data.

Flow Logic Validations Consider the case where you want user to enter only ‘LH’ and ‘SQ’ for sflight-carrid. In this case, you are restricting value of a screen field. This cannot be achieved by automatic field check. Hence there is a need of additional validation. It can be done in flow logic by using following statement: Field --------------- Values Syntax PAI. Field sflight-carrid values (‘LH’). For multiple values PAI. Field sflight-carrid values (‘LH’ ‘SQ’). Field sflight-price values (between 1000 and 2000). In this case when the user enters the value, PAI is triggered and field is checked for that particular value. If the value entered happens to be wrong, that field is enabled for user to enter. If you have multiple Field statements in your flow logic, it is sequential execution. Consider the following case: PAI.

Module assign. Field sflight-carrid values (‘LH’ ‘SQ’). Bangalore

129

In ABAP/4 Module assign. Data: carrid1 like sflight-carrid. Carrid1 = sflight-carrid. Endmodule. In this case, Sflight-carrid is used in the flow logic before the field statement. The system will give invalid value or some previous value as the field sflight-carrid is used in module before it is checked i.e., field statement is after the module in which sflight-carrid is being used. The field is not available to the system unless it executes the field statement. Field statement transfers the values to the program and is done only once. If you don’t have Field statement in your flow logic, transfer of values takes place in PAI event. Consider one more case where you have multiple field statement. PAI. Field Sflight-carrid values (‘LH’). Field Sflight-connid values (‘0400’ ‘0500’).

In this case if the user enters only carrid wrong, then this particular field is enabled and rest of the fields are disabled for user to input. Many times if the user enters wrong value for one field, then you might want to give option to user to enter all the fields, which is not possible by using Field statement only. This functionality can be achieved by CHAIN – ENDCHAIN. Syntax Chain. Field sflight-carrid value (‘LH’). Field sflight-connid values (between ‘200’ and ‘500’). Endchain. Field sflight-price values (‘100’ ‘1000’). In this case, if the user enters wrong value only for carrid, both the fields i.e. carrid and connid are enabled as they are grouped together in the Chain statement. The field price will be disabled for input. Usually, logically related fields are grouped together with Chain-Endchain statement. Bangalore

130

Module Pool Program Validations Checking fields ABAP/4 program includes  

Field statement in flow logic. Module statement in ABAP/4 module pool Program.

Syntax PAI. Field sflight-carrid module . This module can be handled in the main program i.e. module pool program. In ABAP/4 program Module Check. Select single * from sflight where carrid = sflight-carrid. If sy-subrc ne 0. Message e001. Endif. In this case, field sflight-carrid is checked in the table for its existence.

Dynamically Calling the Screens

About Displaying Next Screen Transaction is a sequence of screens, which are displayed one after the other. The next screen displayed depends upon the attributes of first screen. In attributes you need to give Next Screen number i.e. if next screen displayed should be 200 screen, then this number should be given in next Screen attributes. These are static attributes of the screen. By default, if nothing is specified in the program, the system branches out to the screen number, which is specified in the attribute screen. But this doesn’t happen always. If you have many pushbuttons on the screen like the one in the following case:

Bangalore

131

In this case, if user selects MARA pushbutton, then fields from Mara table are displayed. When the user clicks on the MARD, then the fields from MARD table are displayed. Depending upon users selection, the screen is branched out and this has to be done during runtime. This functionality can be achieved by dynamically calling the screen in module pool program. The screen can branch out to new screen depending upon user selection. Following command in module pool program can do this:  SET SCREEM  CALL SCREEN  LEAVE TO SCREEN All these commands override the specifications given in the attributes. This overriding is temporary. The values stored in the attribute are not changed.

Set Screen Syntax Set screen . In module pool program Bangalore

132

Case okcode. When ‘DISP’. Set screen 200. When ‘LIST’. Set screen 300. Endcase. In this case, the entire processing of current screen takes place and then the system branches out to next screen. If you want to branch out to the next screen without processing the current screen, LEAVE SCREEN should be used along with the SET SCREEN. For Example:

Case okcode.. When ‘DISP’. Set screen 200. Leave Screen. When ‘LIST’. Set screen 300. Leave Screen. Endcase. When SET SCREEN is used, control cannot be transferred to the main screen or previous screen, unless you write code for the same.

Call Screen Usually used for pop up screens. Many times, there is a need for user to enter additional information or secondary information on another screen or pop up screen. Once the user enters the data, he should be able to go back to main screen or to the screen where he started. This is not possible by using SET SCREEN. CALL SCREEN achieves this functionality. Syntax Call Screen 200. Will simply call a screen number 200 from a main screen. Once the screen is displayed the user can enter all the data and return to the main screen by clicking BACK button.

Bangalore

133

To call screen as pop up screen the syntax is Call screen starting at Ending at . In this case window will be popped as window and user can close it by using BACK button.

Leave to screen To SET a new screen without processing current screen, you need to use the following two statements together: SET SCREEN 200. LEAVE SCREEN. Or a Single statement LEAVE TO SCREEN 200.

Table Controls A table can be created in transaction. These tables when designed on the screen are called as SCREEN TABLES. These screen tables are of two types viz.  Table controls  Step loops Though these are tables when code is written to handle them, the tables are treated as loops.

Features of Table Controls       

Data is displayed in the form of table when many records match the criteria. Table control gives user the feeling of an actual table. You can scroll through the table vertically and horizontally. You can select rows and columns Resize the width of a column You can have separator lines in between rows and columns Automatic resizing of the table when the user resizes the window.

Bangalore

134

In general table control includes all the features of an actual table and user gets the feeling that he is actually working with table. You can update information in table control and it can be updated in the database table by writing code for it. Steps associated for creating complete screen table are as follows:   

Declaration of table control in module pool program. Designing of table control on the screen. Passing data to table in flow logic.

Declaring of Table Control in the Module Pool Program Syntax Controls TCI type Tableview using screen When you use table control in a screen you must declare the structure in module pool program. Important fields of tableview are as follows:   

Lines – number of displayable rows in a table. Top_line – the row of table where the screen displays start. Current_line – The row currently being processed inside a loop.

When you process the table control in flow logic depending upon where you want to start display of rows, you need to use these variables.

Designing Table Control on Screen   

To design table control on the screen, you need to click on Table in control bar and place it on the screen. You can adjust the length and width of table control. Name the table control. (Here you need to use same name which you have used for declaration of table control in module pool program) From dictionary object, select table fields and place them in the table control.

Passing data to Table Control As already mentioned, table controls are tables but are treated like loops. Usually transfer of data from program to screen is automatic. But in case of table control, transfer of data is not automatic. You need to explicitly transfer the data to table control. ABAP/4

Bangalore

135

provides loop statement, which is associated with flow logic to transfer the data. Because table control is treated like a loop, data from where it is transferred should be a loop. You cannot transfer the data by only select statement; you need to put the data into internal table. ABAP/4 provides the LOOP statement, which is associated with the flow logic and allows you to loop through the table control and internal tables. In between LOOPENDLOOP, you can use most of the flow logic keywords like field values. Module etc. You need to code a LOOP statement in both PBO and PAI event of the screen. With LOOP statement, you can transfer the data from program to table control and vice versa. That is, if user updates the value in the table control, you can update database table with its value. And this can be done in PAI event. So even if you are not updating database table through the table control, you need to put the LOOP statement in the PAI event also. Syntax

PBO. LOOP AT with control cursor PAI. Loop at itab. Proper usage of Table Control is as follows: In flow logic.

PBO. LOOP AT ITAB WITH CONTROL TC1 CURSOR TC1-TOP_LINE. MODULE ASSIGN. ENDLOOP. PAI. LOOP AT ITAB. ENDLOOP. Considering, we have following fields in table control and the screen looks like this:

Bangalore

136

In module pool program CONTROL TC1 Type tableview using screen 200. Module assign. Sflight – carrid = itab – carrid. Sflight - connid= itab - connid. Sflight - fldate= itab – fldate. Endmodule.

The transfer of the data from program to table control takes place in steps and these steps are as follows:  With LOOP AT statement the first row is picked up and placed in the header of the internal table.  Whatever statements you have in between LOOP-ENDLOOP are executed. In this case, you have Module statement. In Module statement, value of internal table is assigned to table control field.  The row in internal table is transferred to the first line of the table control as stated in the LOOP AT statement.  The system encounters the ENDLOOP statement and Control is passed to the next line of the internal table.

Bangalore

137



In the same way, all the records of the internal table are passed to the table control.

STEP LOOPS Step Loops are type of screen table as already mentioned. Step loops are repeated blocks of field in a screen. Each block contains one or more fields and these blocks are repeated. Step loops aren’t like actual table. You can scroll vertically but not horizontally. Three steps are associated with creation of step loops:   

Creation of step loops on screen, which includes declaring fields on the screen and then defining the step, loops for these fields. Passing data to the step loop is exactly similar to the passing of data to table controls. In step loop, you don’t need to define the step loop as such in the module pool program but the cursor needs to be defined in the program.

Types of Step Loops  

Static – Static Step Loop (SSL) have fixed size that cannot be changed during the runtime. If user resizes the window, the size of the static step loop is not changed. Dynamic – Dynamic Step Loop (DSL) is variable in size. When the user resizes the window, the system increases or decreases the number of the step loop blocks.

You can have only one dynamic step loop and can have as many static loops in your transaction. Programming with the Static and dynamic step loop is exactly same. For the system or for the user it doesn’t make any difference whether it is static or dynamic step loop. Only attribute, which you fix during designing of the step loop, is type attribute for step loop F for fixed i.e static and V for variable i.e. dynamic. Writing code for Step Loop in the flow logic. PBO. Loop at itab cursor cl. Module set. Endloop. PAI. Loop at itab.

Bangalore

138

Endloop. * Empty loop is must for both table control and step loop LOOP AT statement for step loops and Table controls is similar. Loop At statement transfers the data to screen table. You need to have the Module to assign the values for the screen table. In module pool program you need to define the cursor. Date: CL TYPE i. * Cursor parameter tells which line of step loop display should start. “Module Set” in module pool program assigns the values to step loop fields, which is similar to table controls. Branching to List Processing

Switching To List Mode You can display a list within a transaction. You can produce a list from module pool program by using the command Leave to List-Processing. This statement switches the system from dialog mode to list mode. And from this point onwards until you return to dialog mode, you can use all the normal report statement like write, select or any other event.

Returning back from LIST mode You can return back to dialog mode by clicking the BACK button. You can have your GUI status and write code for the same. You can include the command LEAVE LIST-PROCESSING. When the system reaches this command, it leaves the list mode and returns to the dialog mode. Help & Value Request In any transaction, When the user presses F1 or ? on a field, System provides the help facility for that particular field. In dialog program, when F1 is pressed, help provided by R3 system is sourced from data element documentation. If this documentation is not present for that particular field or if user needs to display additional information for that particular field, then user defined help can be provided through PROCESS ON HELP REQUEST.

Bangalore

139

In ABVP/4 help can be provided to the user by: Data element documentation: The F1 help can be enhanced, by adding an additional text for the data element in ABAP/4 dictionary. It can be done with the help of following steps: Place cursor on the screen field, GOTO  DOCUMENTATION  DATA ELEMENT DOCUMENT You can now extend the existing help. USING THE PROCESS ON HELP-REQUEST. If you don’t have this event in a program, then the documentation of the field in the ABAP/4 dictionary is taken into consideration. If this event exits in the program then it is executed.

Process on HELP-REQUEST event This event is triggered when user presses F1 on a screen field. You need to handle this event in flow-logic by specifying the fields and attaching the module to it. Syntax PROCESS ON HELP –REQUEST. FIELD SFLIGHT-CARRID MODULE HELP-FOR-CARRID. In module pool program MODULE HELP. Write : `This is field is from sflight table’ Write : / ‘It is of four Character’. ENDMODULE. When the user presses F1 on this particular field, then this message will be displayed on the screen.

Value Request Whenever the user presses F4 on the screen field list of possible values, particular fields are displayed. If the standard value-help is inadequate or if you want to display additional fields or with different combination of fields, developer can program this in PROCESS ON VALUE-REQUEST event in the flow-logic and subsequent module in the module pool program. When the user presses F4, list of possible values are displayed either from matchcode objects or check table or help view or domain. Each one of them is explained briefly.

Bangalore

140

Check Table: If a check table is assigned to the table field and if the user presses F4 for that particular field, then all the key fields are displayed. Domain Values: The values defined in the domain are displayed. These values are set in domain when the domain is created in the dictionary. Help views: In cases where the check table is not sufficient, you can create a help view with this check table, which gives additional information like explanatory text for the fields of the check table. PROCESS ON VALUE_REQUEST. Each time the user presses F4 on the screen field, following algorithm is called internally. Does this field have its own F4 module in the Screen Painter?

no

yes

Execute the module

Matchcode object in the Screen

yes

Execute help

no

matchcode

Check table?

yes

Domain values?

Help view for the check table?

yes

Display help view Bangalore

no

no

no yes

Display check 141

Display domain values

Message ``No display of possible entries here”

When the user presses F4 on flight number, the following screen is displayed.

The screen displayed is pop-up screen and code for the flow logic and module is written below:

Flow-logic code PROCESS ON VALUE-REQUEST. FIELD SFLIGHT-CONNID MODULE HELP-FOR-CONNID. Code for module pool program. MODULE HELP-FOR-CONNIDINPUT. DATA: BEGIN OF ITAB OCCURS 0, CONNID(50), END OF ITAB. REFRESH ITAB. ITAB-CONNIDI= POSSIBLE VALUES FOR CONNECTION ID’. APPEND ITAB.

Bangalore

142

SELECT CONNID FROM SFLIGHT INTO TABLE ITAB. CALL FUNCTION ‘POPUP_WITH_TABLE_DISPLAY’ EXPORTING ENDPOS_COL = 45 ENDPOS_ROW = 25 STARTPOS_COL = 10 STARTPOS_ROW = 1 TITLETEXT = ‘TEXT’ IMPORTING CHOISE = Some Integer Variable TABLES VALUETAB = ITAB EXCEPTIONS BREAK_OFF =1 OTHERS =2. ENDMODULE. “HELP-FOR-CONNID INPUT Changing The Screen During Runtime The attributes are assigned to the screen field when the screen is designed in full screen editor. Such kind of assignment is static, which means that these attributes are fixed. But many times the need to change the attributes of the screen arises. And this has to be done during runtime.

Need To Change Screen There can be a requirement in the transaction that, certain fields on the screen Appear only in certain conditions. Are in Change/display mode according to user inputs Become mandatory subject to specific inputs. Changes its format depending upon certain conditions.

Modifying the screen At the runtime, attributes for each screen field is stored in system defined internal table, with header line, called as SCREEN TABLE. It contains name of field and its attributes. This tab le can be modified during the runtime i.e. through module pool program. Screen table has following fields:

Bangalore

143

Field Name

Length

NAME GROUP1 GROUP2 GROUP3 GROUP4 ACTIVE REQUIRED INPUT 1 OUTPUT INTENSIFIED INVISIBLE LENGTH DISPLAY 3D VALUE_HELP

30 3 3 3 3 1 1 1 1 1 1 1 1

Description Name of screen field Field belongs to field group1 Group 2 Group 3 Group 4 Hide/Show Field input is mandatory Enable/Disable Field for display only Field is highlighted. Field is suppressed. Field output length is reduced Field is displayed with 3-D Frame Field is displayed with Value help

E.g., SCREEN-ACTIVE = 0 has the same effect as the following statements. SCREEN- INPUT = 0. SCREEN-OUTPUT = 0. SCREEN-INVISIBLE = 1. The fields SCREEN-NAME and SCREEN-GROUP 1 through SCREEN-GROUP4 tell you which field and / or field group has the attributes. You can assign up to 4 groups to a field. You need to program screen modifications in module, which is processed during the event PROCESS BEFORE OUTPUT. `SCREEN’ is an internal table and, in order to change the field values, LOOP statement has to be used so that the header-line can be populated with the new values, changing the earlier values, the SCREEN table consisted for the specific screen. Finally the changed record in the header-line is NOT APPENDED, but is MODIFIED to the SCREEN table. That is, we first use `LOOP AT SCREEN’ and then assign the values. And finally PRIOR TO ENDLOPP give `MODIFY SCREEN’. PROCESS BEFORE OUTPUT. MODULE MODIFY_SCREEN OUTPUT.

Bangalore

144

MODULE MODIFY_SCREEN. LOOP AT SCREEN. IF SCREEN-NAME = ‘SFLIGHT-CARRID’. SCREEN-INPUT = 1. MODIFY SCREEN. ENDIF. ENDLOOP. ENDMODULE.

Bangalore

145

Creating Lock Objects Lock object is an aggregated dictionary object and can be defined by using the following steps: o From initial data dictionary screen, enter the name for the object, Click Lock object radiobutton and then click on Create. The system displays a dialog box for Maintain Lock Objects screen o Enter short text as usual and the name for primary table. o Save o Select Tables option From this screen you can: Select secondary tables, if any, linked by foreign key relationship. Fields for the lock objects. This option allows you to select fields for objects (R/3 system allows locking up to record level). Lock object argument are not selected by user but are imposed by the system and includes all the primary keys for the table. Types of locks You can lock the table or record by using following types of locking: Exclusive (E) the locked data can only be displayed or modified by single user i.e the owner of the object. Access to other users is denied. Shared (S) several users can access the same record simultaneously, but only in display mode and except the first one, who has asked for the data in update mode. Exclusive not cumulating (X) it is similar to exclusive lock. It allows only a single user access. E can be called several times from the same transaction. In contrast, a lock type X can be called only once during the transaction. Any other call for this lock is rejected.

Activation of Lock Object When you activate the lock object, the functions are automatically generated. And these are ENQUEUE-EZN and DEQUEUE-EZN. EZN is name of the lock object. While ENQUEUE is used in program to set the code over the selected data depending upon the lock object arguments. DEQUEUE is used to release the lock.

Bangalore

146

SAP Scripts/Layout Sets/Forms Sap Scripts If the user wants to print documents such as invoices, purchase order, all such documents are printed with the use of forms. SAP allows the user to define these forms by using layout sets. SAP script is the tool used to create the layout set. In order to print the document, the SAP system runs a program that collects the data for the document and feeds it into the layout set. This is called as Print Program. SAP Provides a standard layout set for every printable document and usually there is no need to create layout sets as such. User just modifies the existing layout sets as per requirement of client. Following are some standard layout sets provided by SAP:      

RVORDER 01 RVDELNOTE RVPICKSIN RVINVOICE 01 MEDRUCK F110_PRENUM_CHCK

Sales order confirmation Picking List Picking List Invoice Purchase Order Pre-numbered check

Layout Set Layout set is used to design the document. Layout set on its own does not contain any data. The selection of data for the document is done through the print program i.e. the print program selects the data from database table and feeds it to the layout set. The document is printed after the print program gets executed. A layouts set consist of following components:  Header  Paragraph  Character String  Windows  Pages  Page Window

Bangalore

147

Header: The header consists administrative information for the layout sets and default settings for the various other components of the layout sets like page, paragraph. You give all the administrative information for the header when you create the layout set, while all default settings are specified when all the components are created. Paragraphs: A Paragraph contains all the information needed to format a paragraph of text and font. Tabs are important for paragraphs. Specifying the list of tabs is the way to create columns for outputting line items of a document. Character string: is used to override paragraph settings for specific words in a paragraph. For example you might want to use Bold for a single word but not the entire paragraph. The only important thing that is defined with the character string is the font. Windows: A window mainly contains the SAP scripts text and the variable to be printed. There is one special window, MAIN, which contains the output of the line item of a document and is created by the system. The window can be of type VAR or CONST except for the MAIN. But in the present version, SAP system does not distinguish between these two types. The content of variable window is regenerated on every page. The content of a constant window is generated once at the beginning and later printed on every page.

Printing a company logo There are two ways to print a company logo: 1. The logo can be included in the layout set. 2. It can be a macro on PCL – 5 printers. Including a logo in the layout sets  Create logo with a graphics program and save it as tiff file.  From editor run the program RSTXLDMC. Parameters to be passed are  File name  File type  BMON – For a black and white image.  BCOL – For a color image.  Text name – The standard text in layout set

Bangalore

148

This text can be included in a layout set by including . Using PCL – 5 printers, can also print the logo. In R3, the printer types are IIPLJIIID, IIPLJ4, LX4039 and SM120XXS.

Control Commands About control commands: All script control commands are entered in the SAP Script editor.    

All commands are indicated by /: in the tag column Only one control command is allowed per line Lines with control commands are not affected by the editor formatting If control command is unknown or incorrect, command line is treated as comment line

ADDRESS: This command formats and address according to the postal standards of the country. Syntax:

/: Address /: Title ‘Company’ /: Name ‘Intelligroup’ /: Street ‘115’ /: P.O. BOX ` ` /: Postcode /: City /: Region /: Country /: End Address

BOTTOM-ENDBOTTOM:

For the Main window you can determine lines, which are always output automatically at the bottom of that window. This is called footer text. Syntax: /: BOTTOM /: ENDBOTTOM

BOX, POSITION, & SIZE: These commands are used for drawing boxes and are used only during creating output. Syntax: /: BOX [Xpos] [Ypos] [Width] [Height] [Frame] [Intensive] X & Y – Upper left corner of the box. Width – Width of the box

Bangalore

149

Ht – Height of the box Frame – Thickness of the box (Default is full black) Units used for Width, Height and Thickness are TW, PT, IN, CM, CH, LN. Ex., /: BOX WIDTH ‘20’ CM HEIGHT 1 IN FRAME 10 TW INTENSIFY 15.

POSITION Syntax: /: POSITION [X Origin] [Y Origin] [Window] [Page] X&Y Sets the origin for x 7 y parameters for the box command. Window Sets the default values for the left and upper edges. Pages Sets the values for the left and upper edges of the current page. Basically used to set default setting for the box command. /: Position x Origin ‘1.5’ cm y origin ‘1’ cm

SIZE Syntax: /: SIZE [WIDTH] [HEIGHT] [WINDOW] [PAGE] Sets width and height parameters for the box command.

CASE: It is similar to ABAP/4 editor command ‘CASE’ only symbol can be queried. Syntax: /: CASE SYMBOL /: WHEN 1 /: WHEN 2 /: WHEN OTHERS /: ENDCASE

DEFINE: Values can be assigned to text symbol by DEFINE keyword. The assigned value may have a maximum 60 characters. It can also contain further symbols.

Syntax: /: DEFINE & SYMBOL & = ‘XXXX’ IF: With IF command you can define the lines that are output only under certain conditions. Syntax: /: IF &var& = ‘char val’ /: ENDIF

Bangalore

150

INCLUDE: Contents of another text can be included in text by INCLUDE command. The contents are copied only at the time of the output formatting. You can also specify language and the paragraph irrespective of the language in which the calling text is created. The language which is used in include test is used for output. Syntax: /: INCLUDE MYTEXT

MISCELLANEUOS TOPICS RUNTIME ANALYSIS The runtime analysis is an additional development workbench tool that is quite useful for analyzing performance of an ABAP / 4 Program or transaction. With this tool, the system can display information about:  Executed instruction  Accessed execution time.  Tables and Types of access.  Chronological execution flow The runtime analysis tool creates lists that reveal expensive statements, summarize table accesses. Runtime analysis is specifically designed for tuning individual programs and transactions. The Runtime Analysis tool measures ABAP/4 statements that are potentially expensive in terms of CPU time. The most significant of these are: Statement used for database access like select. Statement used for modularization such as module, perform, call function. Internal table statements like append, collect.

Starting Runtime Analysis     

From ABAP/4 development workbench select Test – Runtime Analysis. From ABAP/4 editor, select utilities – more utilities – Runtime Analysis. From ABAP/ source code screen, select Execute – Runtime Analysis. From R3 screen, select System – Utilities – Runtime Analysis. Entering Transaction code SE30 in the command field.

Following screen is the initial screen for SE30 transaction.

Bangalore

151

On the initial screen, select the needed object you want to analyze i.e. program or transaction. Enter the name of the object. Click on execute. The system will execute the specified object and will generate a trace file or performance data file, which can then be analyzed when the transaction or program is finished. Analyzing a performance data file These files are created at operating system level and many times occupy large memory space, so be sure to remove the files, which are no longer needed. To analyze the files:  Click on Analysis  Following screen is displayed  From GOTO option you can get overview of runtime analysis. The options are as follows:  Hit List – Displays a list with the most system expensive instructions.  Tables – Displays the most important tables, the number of accesses and the time needed for the accesses.  Group hit list – Displays a list with the performed instructions classified by instruction type.  Call hierarchy – Presents a chronological listing with the flow of calls during the execution of a program. During Runtime Analysis, the system measures the statements and stores these measurements in a performance data file. If you measure the same program or transaction several times, the data can vary. Many factors make it difficult to reproduce identical result. E.g., Network traffic.

Bangalore

152

When you evaluate this file, the system displays the overview - Runtime Analysis Evaluation screen including a bar chart for total execution time. From this screen, you can analyze several types of information like:    

Hit list: displays the list with the most `system-expensive’ instructions. Tables: displays the most important tables, the number of accesses and the time needed for the accesses. Group hit list: displays a list of performed instruction classified by its type. Call hierarchy: presents a chronological listing with the flow of calls during the execution of program.

SQL TRACE The SQL trace is a tool, which allows displaying and analyzing the contents for the database calls, which are made by the reports and transactions written in ABAP/4. It monitors programs and transactions on the database level. With the help of this facility for every open SQL instructions, you can display, about which SQL Embedded (DECLARE, OPEN, FETCH) Statement have been executed, besides analyzing the system performance. Steps to Creation     

From R3 screen, select system –-> Utilities –-> SQL trace. Or Enter transaction ST05. Click the trace on button. Enter the user name whose programs are going to be traced. Execute the program or transaction you want to trace. Return to SQL trace initial screen and press the button SQL trace off. This switching off is necessary because if it is not done then SQL trace will trace each and every program executed by a particular user. And it is quite expensive in terms of memory and time of the system.

Analyzing The Trace File To analyze the created trace, press the button list trace. Using this file you can see exactly how the system handles database requests. The first screen of the SQL trace data file displays each measured database requests, the application made. The trace file records when the request occurred and its duration.

Bangalore

153

To display dictionary definition information about the table field, position the cursor on the table field and click on the DDIC info button. When this button is clicked, it displays system information like object name, table class, whether buffering is allowed or not i.e. information related to dictionary. Explain SQL: This button provides the functionality, which includes the utility for providing detailed information about the SQL Operation Strategy followed by the underlying database system. You need to click on Explain SQL button. The system displays the execution plan for SQL statements. Here you can display the actual SQL statement like Select, which fields are being accessed, Table being accessed, all where conditions. ABAP/4 Display Gives you the actual ABAP/4 code. More information gives the detailed information for time, select statement, client, number of records selected etc. Replace variable will display the SQL statement with another variables. Workbench Organizer & Transport System SAP recommends three types of systems for implementation purpose  Development System  Test System  Production System Though number of systems used by an organization depends upon many factors such as size of implementation, budget etc. However even in the smallest installation, a second system is a must. Development system Development system is the system where the actual development takes place. Normally the development is carried out for objects and these objects are original for these systems. Test system Also known as quality assurance system and are used to test the objects. You can test objects on development system also, but on Test System the object is tested against real data. When the tests are validated the development objects are transported to the production system. Production System

Bangalore

154

The production system is where the end user enters real business data and where the actual business runs. No development takes place in this system. You need to transfer the object from test system to production system. The overall flow of objects can be understood in the following diagram:

DEVELOPMEN SYSTEM

TEST SYSTEM

PRODUCTION SYSTEM

Developer creates the objects in the development system, these objects are transported to the Test system to test them against the real data and when validated, these objects are transported to the Production System. To transport these objects from one system to another, ABAP/4 development work bench provides the tool called Work bench organizer which is also used to manage activities that are important in the overall development environment. Example, for these activities are.  The management and control of new development requests.  Modification of objects  Version management In a distributed environment, workbench Organizer transports the development object between different SAP systems. In the following example, the objects are transported from the development system to production system. E.g., between development and Production System

Type Users: Developers, Consultant

Develop System: New Development

Production System End Users

No development hhhjhjh

Bangalore

155

Workbench Organizer The most puzzling topic of R3 system is intended to help functions for system development.

Concepts of workbench 



Development objects: Workbench records and controls change to existing development objects as well as new objects. A development object is an object created in R/3 system. (Program, Screens, Function modules.) Dictionary objects: Tables, Domains, Match code objects, Data Elements.

The workbench is fully integrated into the ABAP/4 development workbench.  Development Classes: A Development class classifies the objects belonging to the same development project. When a user creates a object in R/3 system, the object needs to be stored in a particular development class. The development class are objects themselves. In R/3 system you can store objects.  In local object i.e. object is stored in $tmp class and cannot be transported from one system to another.  User can assign his own development class and can be transported. Transport System 



Developers are in charge of creating or correcting data objects and will create change request, which can be for individual object or common request for a project. When the change request is released the system performs transport R/3 administrator is the person who sets up the transport system. This group works both at the R/3 application level and at the operating system level, using transport control (tp) program.

Change Request A Change request is a list in the system, which mainly contains the object to be transported. It also contains the transport type, the request category and the target system. When the change request is created either manually or automatically, the system assigns a number to it automatically. This number is known as change request number. The format of this number is normally K E.g., DD1K Where DD1 is System Identification Number (SID) Bangalore

156

K is keyword The number is automatically generated by system and starts with 900001. The change request records all modifications made to development object. When the changes are made and the change task (will be discussed) has been released, the change request can be released. SEO9 transaction Or Tools -> ABAP/4 W.B -> overview -> W.B. organizer Will display and check all the change requests.

Tasks A task in the workbench organizer is an activity in which user either creates an object or modifies the same. In workbench organizer, task can be either development or repair task. A task is related to single user while change request contains tasks belonging to different users. You cannot transport task as such, but as a part of request. Each task is associated with task number, which is similar to change request number. Usually, when a development work starts, a system administrator or project manager creates a change request to define tasks for all users involved in the project. Later, user starts modifying objects or create new object. Once user finishes his task, they must release them. A change request can be released for transporting, only when all tasks under the same change request are released. Objects included in task become locked against other development work on the same object. Version Management ABAP/4 workbench and the organizer provide a version management for all the objects in the system. With version management user can compare current version object and object with the previous version. To display the version for a object, Locate your object through the change request number of workbench organizer. Click on the object and from menu. Or Utilities  display version. It displays what has been modified and who did it. Bangalore

157

Version management is important for developers also as it allows user to compare previous programs with the current one.

Transport A transport means the process of moving something from one place to another. In R/3 system this ‘something’ means change request. To transport the objects you need to create the change request. It can be done with the help of workbench organizer. Transport System and workbench organizer are closely linked to each other. An object original is a development object that has been created in the system in which you are working. DD1 PP1 Zsus001 (Development System)

Zsus001 (Production System)

Suppose you transport object Zsus001 to another system, Zsus001 is object original for system DD1. If anyone tries to modify the program, he will be making repair to it, provided he has access key for the same. R/3 system offers this security measure to ensure that development object remain consistent for all system, thus preventing parallel work on the same objects. Correction of objects and development of objects can be only in original system. The difference between Repair and Correction is as follows:  If you modify an object in a system in which it is created, you are making Correction to it.  If you modify an object in a system in which it was not created, then you are making Repair task. Releasing Tasks and Request When new development or correction is complete, developer must release their task and request. To release a task:  Find a task from the Workbench initial screen.  Position the cursor over the task.  Click on the release button A request is released by either system Administrator or Project Managers, once all the tasks are released Bangalore

158

Cross Applications BAPI:-Business Applications Programming Interface SAP created the Business Framework to allow the technical integration and exchange of business data among SAP components and between SAP and non-SAP components. Important components of the Business Framework are the Business Application Programming Interfaces (BAPIs), which represent visible interfaces at the component boundaries and whose properties serve to integrate these components. The integration can include both components within a local network and components that are connected with one another through the Internet. BAPIs allow integration at the business level, not at the technical level. This provides greater stability in the link, and independence from the underlying communication Process Flow The structure of the tools in the ABAP Workbench determines how the BAPI is implemented. 1. Defining the data structures (including domains and data elements) in the ABAP Dictionary. 2. Implementing the Function Module in the Function Builder 3. Defining the Business Object Types And it’s methods in the BOR 4. The Business object Repository (BOR) is object oriented repository in R/3 system. It contains SAP business objects and their methods. Conventions for BAPI Data Structures Bangalore

159

1. Each parameter must refer to a data structure in the ABAP Dictionary. In the case of structured parameters this is always to the whole BAPI data structure. If the parameter consists of only one field, it must refer to a field in a BAPI structure. 2. You have to create separate data structures for BAPIs, which are independent of the data structures generally, used in the R/3 application. 3. All data structure names must begin with BAPI. 4. BAPI structure names should be as meaningful as possible.

Custom BAPI creation - Step-by-step Procedure Scenario: Step-by-step creation of a BAPI to retrieve fields from table T001. Procedure: Go to transaction SE11 and create a structure as shown or as per your requirement. Give the name in the Data type field and click on create.

Bangalore

160

In the pop-up that comes up, select the radio button “structure”.

In the components tab of the structure, give the different fields and their corresponding field types and press enter to check the compatibility and creativeness.

Bangalore

161

Do not forget to save it in a package. You can even save it as a local object. For my example, I save it in a package.

Check the structure (ctrl + F2) and activate (ctrl + F3) the structure. +++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++ Now we are done with the creation of a Structure. +++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++

Go to transaction SE37 where you create function modules. Click on create after you enter the name of the Function module.

Bangalore

162

A screen as shown above would pop-up where you mention the function group to save the function module and also provide some short text describing your function module.

In the next pop-up that follows, click on continue as shown above.

Bangalore

163

The function module screen would look like the one above.

Go to the Attributes tab and select the radio button reading “remote-enabled module”. Come back to the imports tab and provide the import parameters as shown or as per your requirement.

Bangalore

164

Now in the Export tab, provide the export parameters as shown or as per your requirement.

In the tables tab, provide the information as shown or as per your requirement.

The next screen you visit is the source code. It would look like this.

In the source code tab, write the following code in order to pick the data based on the input you provide.

Bangalore

165

Now, save and check the code and activate the function module. After successful activation, go to the attributes tab. Go to Function moduleReleaseRelease.

+++++++++++++++++++++++++++++++++++++++++++++++ Now we are done with the creation of a Function Module. +++++++++++++++++++++++++++++++++++++++++++++++ Go to transaction SWO1 and enter the name of the BAPI you would like to create or as shown in the screen and click the create button.

Bangalore

166

Give the name of the BAPI as above and click on create.

Give the above-mentioned details and click on the continue icon.

Bangalore

167

Save in a package. The resulting screen is as follows.

Now click on the methods to drop down and see what methods are provided by default. There would be two methods, showing in red color which comes by default while creating the BAPI.

Bangalore

168

Click or select the method as shown above and go to the path “UtilitiesAPI methodsAdd methods”. On the screen that follows, provide the function module name and click on the continue icon.

Bangalore

169

In the ultimate pop-up, click the next step icon. We observe that the information is predefined in the fields. This is the next screen where you would just click on the “next” icon.

Bangalore

170

Click on Yes. You can see an information message reading “ZBAPIFMT001” inserted. Now save after you add the method. Select & Double click on the API method. Go to Tab: ABAP Check 'API Function'.

Bangalore

171

The above screen is displayed. Go to the ABAP tab as shown below.

Bangalore

172

Select the Radio button reading “API Function” as already said above.

Bangalore

173

click on the continue icon to proceed further. Now select the Object “ZBAPI_T001” as shown below.

Go to : EditChange Release StatusObject type To Modeled.

Bangalore

174

The above shown screen will be displayed. Click on yes. The message shows, ‘The object type status set to modeled’. (Or already modeled) Go to: EditChange Release StatusObject type  To Implemented.

Bangalore

175

You can see a message reading “Object type status set to implemented” Now, go to: EditChange Release StatusObjectTo Released.

There would be two pop ups coming up. Click on continue on the Pop Ups. Keep the cursor on the 'Method'. Go to: EditChange Release StatusObject type componentTO Modeled.

Bangalore

176

You can see the message reading “status for method ‘zbapifmt001’ set to modeled”. Now, go to: EditChange Release StatusObject type component TO Implemented

You can see the message reading “status for method ‘zbapifmt001’ set to implemented”. Now go to: EditChange Release Status  Object type component  To Released

Bangalore

177

You can see the message reading “status for method ‘zbapifmt001’ set to Released”. Click on Generate Button. (The red ball kind of button is the Generate button)

After clicking on the generate button, you can see the message reading “Object type 'ZBAPI_T001' generated successfully”. Now go to BAPI Tcode (BOR) there we can find the BAPI (our BAPI) The BAPI browser would look like the screen below.

You can click on the Alphabetical tab so that you can browse the BAPI’s in an alphabetical order. Find your BAPI as shown.

Bangalore

178

+++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++ Now we are done with the creation of a BAPI. +++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++ Test Your BAPI.

Enter the name of your BAPI in the transaction SWO1 and click on ‘Test’.

Bangalore

179

The above screen is displayed. Click on the Execute icon against the BAPI as shown.

The above screen is displayed where you would require entering the data against the empty input fields.

Bangalore

180

We have entered some data in the Field. After entering the data, click on the execute icon as shown below.

The following screen is displayed which has some values as is indicated by the ITEMTAB.

Bangalore

181

Click on the Edit table icon as shown below.

The results as per our input are as shown below.

Bangalore

182

By this, we would get it confirmed that our BAPI is working properly. We can even check it by passing different values again. Come back to the input and execution screen.

After executing the BAPI based on the input provided, we get the following screen.

Bangalore

183

Hit on the execute icon.

In the above shown screen, hit on the edit table icon.

Bangalore

184

The above is the output we get from the input we provided. We are now done with the creation and successful execution of a BAPI.

ALE (Application Link and Enabling) & IDOC(Intermediate Documents)

What is ALE? ALE (Application Link and Enabling) is SAP proprietary technology that enables data communications between two or more SAP R/3 systems and/or R/3 and external systems. ALE is the set of tools, programs, and data definitions that Provides the mechanism for distributing SAP functionality and data across multiple systems. ALE enables the construction and operation of distributed applications. ALE Overview

Bangalore

185

From a System Infrastructure view, an SAP system consists of three layers: 

The Database Layer stores and retrieves all data. The database contains all of the data related to the SAP system, including the ABAP programs, the Configuration data, the master data, and the transaction data.



Application layer: This layer provides ALE with an interface to R/3 to originate or receive messages containing data to or from external (or other R/3) systems and executes the SAP programs and processes requests from users.



The Presentation Layer contains the SAP Graphical User Interface (GUI), and handles all user input and output.

Together, the three layers make up the three-tiered client-server architecture of SAP. We can distribute the three layers over any number of physical computers. However, there may only be one database server. From a Database or Configuration view, the SAP system consists of:  

Client-Independent data, such as ABAP programs, client-independent tables, etc. One or more Clients. Each client contains its own client-dependent configuration (Company hierarchy, process configurations, etc.), master data (customer, Material, vendor, etc.), and transaction data.

The Basic Ideas of ALE Bangalore

186

ALE is a technology introduced by SAP with its 3.0 release. Its purpose was to overcome the limitations of a single SAP system. A single SAP system that runs on top of one database often does not fulfill the needs of larger corporations, either from a business or a technical perspective. ALE allows the implementation of loosely coupled SAP systems; each of the SAP systems has its own database and is essentially independent from the other systems. ALE allows us to distribute data between different systems and different business processes. The distribution of data happens at the application server level (Hence, Application Link Enabling). SAP supports a number of distribution scenarios, which define how different SAP systems can interact. The scenarios define what messages are sent back and forth between the systems (for example, Contract information needs to be exchanged between systems that run central purchasing and systems that run decentral purchasing). The “data container” that carries the message is the Intermediate Document, or IDoc. SAP delivers over 100 IDoc types to support its distribution scenarios; along with the IDocs come the associated programs to generate (on the outbound side) or to process (on the inbound side) IDocs. Part of ALE is a communication infrastructure; specifically ALE uses the “transactional RFC” technology to ensure the transaction consistency across system boundaries. ALE also ties into SAP workflow to handle errors in the data transfer process.

Bangalore

187

ALE scenarios fall into three categories: master data, transactional data, and control data distribution. Although the underlying principles are the same for the different categories, there are differences in their functions and configurations. SAP delivers over 200 ALE scenarios; and by extension there are approximately 200 application areas that can leverage ALE technology for data distribution or communication. A subset of these scenarios is supported by R/3 for Electronic Data Interchange (EDI). There are several advantages to using ALE technology: ALE Building Blocks and Concepts The following building blocks are fundamental to ALE functionality: Logical System: A Logical System (LS) is the representation of an R/3 or external system in SAP R/3 for the distribution of data to and from the R/3 System. Every R/3 client used for ALE or EDI has to have a base LS associated with the client. This LS becomes the “sender” for outbound messages and a “receiver” for inbound messages. In addition to the base LS, a second LS should be created within that R/3 system for each R/3 or external system used for ALE interfaces. In an inbound ALE interface, this second LS represents the sender (another R/3 or external system) with respect to the base LS (receiver). In an outbound ALE interface, this second LS is the receiver on behalf of the R/3 or external system with respect to the base LS (sender). Message type: A message type represents the application message exchanged between R/3 systems and R/3 and an external system. A message type characterizes the data sent across systems and relates to the structure of the data called an IDOC type (see below). For example, MATMAS is a message type for Material Master, and INVOIC is a message type for an Invoice (Billing Document). ALE supports over 200 message types in R/3 and about 200 application areas. IDOC type and IDOC: An Intermediate Document (IDOC) type represents the structure of the data associated with a message type (DEBMAS02 for message type DEBMAS — Customer Master, and WMMBID02 for message type WMMBXY— Goods Movements), while an IDOC is an object containing the data of a particular message type. IDOCs are data containers with intelligence built in. Each IDOC contains one and only one business object. For example, an IDOC of type SHPMNT01, message type SHPMNT, will contain data only of one Shipment Document. Generally, the architecture of an IDOC is independent of the message type by virtue of ALE’s ability to redefine it for any message type. Customer Distribution Model: In an R/3 system, the Customer Distribution Model is a tool that stores information about the flow of messages across various systems. The Customer Distribution Model uses an SAP-delivered Distribution Reference Model as its basis (the Customer Distribution Model can have distribution scenarios other than ones Bangalore

188

stored in the Distribution Reference Model.) The Customer Distribution Model stores data that dictates which messages (message types) flow to which Logical Systems. Many messages can flow to one Logical System, and one message can flow to several systems. With the use of filter objects and listings (which I’ll describe shortly), it is also possible to specify in a model the criteria for filtering information for a specific system. A Customer Distribution Model can be created in an R/3 system with that client’s base Logical System as the “sender” Logical System. ALE provides powerful capabilities to capture changes occurring to master data and to distribute them via the IDOC interface. This feature can be used to keep two or more systems synchronized with respect to master data. Ports: A port is a logical representation of a communication channel in SAP, with the data communicated being IDOCs. There are four types of ports that can be defined in R/3: tRFC, File, R/2, and Internet. ALE can use all port types to distribute IDOCs, while EDI typically uses a file-based port. tRFC and File ports can link to RFC destinations connected to R/3-to-R/3 or TCP/IP. By linking ports to RFC destinations, the port can also trigger scripts to invoke EDI subsystems, IDOC mapping software, and FTP. You can maintain ports by executing transaction WE21 or WEDI, or selecting IDOC -> Port Definition. RFC destinations can be maintained using transaction SM59. Partner profile: A partner profile is an identifier for a system used for communicating messages. There are four types of partner profiles: KU for Customer, LI for Vendor, B for Bank, and LS for Logical System. KU, LI, and B are used for EDI partners, while LS is used for ALE communications. Every partner profile used for ALE must be based on an existing LS. A partner profile brings together several ALE and EDI elements to define the parameters of communication between two or more systems. Other than general information, you have to maintain inbound parameters, outbound parameters, and message control. The main parameters are message types, IDOC types, process codes, partner functions, application identifiers, message functions, output types, and ports. Other parameters also determine the mode of processing and error handling. A partner profile plays a major role and can be viewed as a gateway for ALE and EDI communications. It routes the specified messages through defined IDOC types to a given port after invoking the appropriate function modules for outbound processing. It receives IDOCs of a specific type, and it identifies modules to post data to the application databases in the case of inbound interfaces. RFC Destination:Used to define the characteristics of communication links to a remote system on which a functions needs to be executed.

Bangalore

189

Process: The processes in the application layer and the ALE layer are completed on both the inbound and outbound processing sides. The communication layer transfers the data by transactional Remote Function Call (tRFC) or by EDI file interface. The process can be divided into the following sub-processes: 1. Outbound Processing 2. Inbound Processing

Why use ALE? ALE provides for the integration of distributed applications, but why would we distribute applications in the first place? There are several technical and business reasons:        

System Performance: The transaction load is too heavy for a single SAP system. High Availability Requirements: The company cannot afford downtime due to backups, maintenance, upgrades, etc. SAP Release Coordination: Different units of the organization may require different releases of the SAP software. Very Large Database: Companies with very large databases may need to distribute the data across multiple SAP systems. Business Structure: Business units may require independence and autonomy for day-to-day operations, and yet still need to share some data and functionality with other units in the enterprise. Interfacing with non-SAP systems: The company may wish to maintain certain applications on non-SAP systems, while at the same time integrate these applications and their data with the SAP system. Keep development system data in sync with production data: An organization may wish to keep the data on a development system the same as on a production system. Maintain configuration and master data across clients: Organizations using multiple clients may wish to maintain certain data on a client-independent basis.

What can we distribute with ALE? We can distribute all types of data with ALE:  Control or Customizing Data: Control data includes all configuration objects that define how the SAP system is organized. This includes the enterprise structure configurations, global settings, etc.  Master Data: Master data objects that can ALE can distribute include:  Material Master

Bangalore

190

      

Customer Master Vendor Master Cost Centers Activity Types G/L Accounts Characteristics/Classes/Classifications and many others

Transaction Data: Transaction data is data related to specific business transactions or processes (e.g. sales orders, credit memos, invoices).

SAP delivers several hundred predefined distribution scenarios. If a standard solution is not provided, then we can develop a custom scenario to distribute any data required by the business. The number of supported business scenarios increases with each SAP release.

Example distribution scenario: Sales and Distribution

The sales system provides only the logistics data that the warehouse requires to fill an order. Summary information is reported into the central sales information system. All of the data sent references a single order document. The Intermediate Document (IDoc)

Bangalore

191

The Intermediate Document, or IDoc, is the main component of all interface functionality in SAP. Each interface message type has an associated IDoc type. The IDoc, in turn, defines the structure and formatting of the data contained within the message type. IDocs provide support for customized development:     

API for development Easy to use and apply Real-time or asynchronous interface connection Independent of external system data requirements Independent of type of external system

The data interface standard is standardized according to the following key rules:  The documentation of the interface is published.  SAP takes responsibility for compatibility of the interface standard for its own applications.  Field lengths and types are defined according to the data element definitions of the EDIFACT EDI standard and SAP’s data repository.  Codes for coded fields are taken from international standards where the standard applies. IDoc Structure

An IDoc consists of three record types:  Control Record: Contains the data that uniquely identifies the IDoc.  Data Records: Contain the application data related to the message type. An IDoc may have multiple data records, called segments. A data segment is made up of a

Bangalore

192

key section and a data section. The key section uniquely identifies its respective data segment.  Status Records: Contain the information relative to the various statuses that the IDoc encounters, such as IDoc created, document posted, etc.The IDoc is data stored in a structured format. It is a medium for data transfer. An IDoc is not a process nor executable code. SAP originally developed IDocs for EDI, and then adopted the IDoc concept and structure for its ALE interface. The IDoc Control Record The Control Record stores the characteristics of the IDoc. Some of the more important fields are:       

IDoc ID Number (DOCNUM) IDoc type (DOCTYP) Direction (In or Out) (DIRECT) Name of Sender (SNDPRN) Name of Receiver (RCVPRN) Processing Status (STATUS) EDI Message Type (if EDI) (STDMES)

Control Records are stored in the R/3 transparent table EDIDC, keyed by IDoc ID number. This ID number is assigned by SAP for all IDocs. The IDoc Data Records The Data Records contain the actual application data. Some of the more important fields are:  IDoc ID Number (DOCNUM)  Segment Name (SEGNAM)  IDoc Data (SDATA) (structure differs with each IDoc type) The Data Records are stored in table EDID4 (EDID2 in prior versions), keyed by IDoc number and segment number. The table structure is 71 bytes of administration data (IDoc number, segment identifier, etc.) Followed by 1000 bytes of free-form application data. Each segment type uses a different format for the 1000 bytes of application data. Data Record Hierarchy

Bangalore

193

Information that relates to the object as a whole is stored in the main segment. Hierarchical information is stored in separate segments. Each segment typically corresponds to a different database table.  Attributes of a segment:  The fields of the segment. Each field is assigned a length and a data element from the ABAP dictionary.  Whether the segment is required or optional in a valid IDoc.  The minimum and maximum number of instances of the segment.

Example – Material Master

As an example, consider the Material Master IDoc Type (MATMAS01). Each material has information that is common throughout an SAP implementation. This data is stored in the main segment. Each material has some information that is different for each plant, which is stored in a separate plant segment. Within a plant, the material can be stored in multiple storage locations, each of which requires a storage location segment for its information. We can store several different descriptions of the material (for different languages, for example).

Distribution Models

Bangalore

194

The distribution model describes the flow of data between logical systems:     

What systems are there? What applications will run on which systems? What systems will SEND data? What systems will RECEIVE the data? Other rules for data distribution?

ALE uses the model to control data distribution. The ALE system will not distribute any data unless you specify the data flow in a distribution model. Before building a distribution model, we must define the logical systems that we will be using. The Logical System Definition transaction will access the list of logical system names. Click on New entries to create new logical systems. Steps to create ALE and IDOC’s:        

Create the Logical System using SALE Tcode. Assign Clients to logical System using SALE Tcode. Create RFC Destinations using SM59 Tcode. Create Ports using WE21 Tcode. Create Distribution Model using BD64 Tcode. Create Partner profile using BD64 Tcode. Outbound Process using WE05 Tcode. Inbound Process using WE05 Tcode.

Enhancements Bangalore

195

SAP has developed its various modules with standards, which are broadly practiced all over. But yet the requirements of customers differ from place to place. In this scenario it becomes imperative to modify SAP objects to suit the customer’s needs. Hence SAP allows you to change the system accordingly and add your own functionality to the SAP system. There are four different ways of changing the SAP system to fit our needs: 1. Customizing: Customizing constitutes changing the system parameters with its own special user interface. These changes are organized and preplanned. It is an obligatory part of a SAP implementation process. 2. Enhancement Concept: It constitutes changing of SAP Repository objects by the customer without modification 3. Modification: Modifying the SAP repository objects in the form custom changes. This should be avoided because when SAP changes occur in new versions then the customer version and the new SAP version have to be reconciled manually. This means an increased maintenance workload because of the need to adjust all such modifications. Hence, use of this option should be avoided as far as possible. 4. Customer Development: If the customer requirements are not met by SAP then we should go in for customer development. These means that we need to create customer specific objects within the customer range. Modification and Customer Development involve high maintenance and costs. Hence use these only when customer requirements are not met by customizing or by exits. SAP creates customer exits for specific programs, screens and menus within standard R/3 applications. There are two methods in enhancements. 1. User Exits. 2. BADI (Business Add Ins) User Exits There are mainly two reasons to why we have to use exits if we ever have to. 1. You should them because they do not affect the SAP source code but still allow you to change the functionality of SAP to suit your needs. SAP has provided us with some standard exits that we should modify by adding our encapsulated as separate objects. When you create Exits, they are encapsulated as separate objects. 2. And since, they do not affect the source code and are named as per the SAP naming conventions; they do affect future software upgrades. Hence you do not have to save Bangalore

196

them and then reenter add-ons attached to exits. You can only use exits if they already exist within the SAP R/3 System In case you do not find an exit available for an area where you would want to make a change, then you should request SAP to develop an exit. There are four types of exits: 1. Menu Exits 2. Screen Exits 3. Function module Exits 4. Field Exit 1. Menu Exits Using the Menu Exits you can add menu items to the menus of standard R/3 Applications. The Menu Exit entries have function codes that begin with + (plus sign). 2. Function Exits This includes creating function modules with the administrative part, the interface and the documentation but usually without any additional code. Function module exits play a role in both in menu and screen exits When you add a new menu item to a standard pull-down menu, for example, you can use a function module exit. 3. Screen Exits Screen Exits defines special areas called Subscreens within a screen. Using Screen Exits you can add subscreens to the screens within R/3 applications. 4. FIELD EXITS Let us now see how to create field exits.  First and foremost, ask your system administrator to include the parameter abap/fieldexit = Y in your Instance Profile  For the Field Exits we do not need an Enhancement project.  To create a Field Exit, you need to first determine which Data Element you would want to change, The program that you would like to have the effect on, The screen number. In our example we will consider the transaction MM02, which is for changing the material master. We will select the Basic Data view and then make fields exit for restricting the Basic Unit Of Measurement. For example, we will not allow the user to enter ‘BOX’ as basic unit of measurement. For this field, we need to have details such the Data Element, Program name and Screen Number. This information can be gathered by as follows: i. Start the Transaction MM02. ii. Select a material and click enter iii. From the pop up that you get, select the Basic Data view iv. Locate the label Base Unit of Measure in the General Data section. Bangalore

197

v. Place your cursor in the field and press F1 vi. In the Help screen of this field, press on Technical Info button and note down the above information Detailed explanation about BADI with an example Defination: BADI (Business Add-In) is a new SAP Object Oriented enhancement technique which is used to add our own business functionality to the existing SAP standard functionality. BADI's are available in SAP R/3 from the system release 4.6c Why BADI? In contrast to the earlier enhancement techniques, BADI follows Object Oriented approach to make them reusable. A BADI can be used any number of times where as standard enhancement techniques can be used only once. For example if we assign an enhancement to one custom project, then that enhancement cannot be assigned to any other custom projects. To overcome this drawback SAP has provided a new enhancement technique called BADI. Transaction code for BADI Definition: SE18 When you create a BAdI definition, a class interface will be automatically created and you can define your methods in the interface. The implementation of the methods can be done in SE19 transaction. When a BAdi is created following are automatically generated:An interface with 'IF_EX_' inserted between the first and second characters of the BAdi name. An adapter class with 'CL_EX_' inserted between the first and second characters of the BAdi name. Transaction code to Implement BADI: SE19 Types of BADI's: While creating a BADI using the T-code SE18, it provides the pop-up screen to select the type of BADI to be used is as shown below.

Bangalore

198

There are two types of BADI's. 1) Multi use BADI: With this option, any number of active implementations can be assigned to the same definition BADI. By default this option is checked.If we want the BADI for multiple use If you have multiple-use BADI definitions, the sequence must not play any role. The drawback in Multiple use BADI is, it is not possible to know which BADI is active especially in country specific version. 2) Filter dependent BADI: Using this option we can define the BADI's according to the filter values to control the add-in implementation on specific criteria. Ex: Specific country value. How to Find BADI's in SAP system: Method 1: Steps to find BADI: 1. Go to SE 24 transaction, type CL_EXITHANDLER and then click on display.

Bangalore

199

2. Double click on GET_INSTANCE method.

3. Put a break-point on class method CL_EXITHANDLER=>GET_CLASS_NAME_BY_INTERFACE.

Bangalore

200

4. Run any transaction on which we want finds the BADI's say VA01. 5. Give the transaction name VA01 and press enter. 6. It will automatically take you to the break-point which we have set the in the SE24 transaction. Each time if you press F8 a list BADI names will be displayed

Bangalore

201

7. You can find the BADI name in field EXIT_NAME and if you double click on it, we can get the corresponding BADI name before hit the corresponding screen. Based on the requirement find the BADI name and accordingly implement your functionality using the transaction se19. Method 2: Go to transaction SE84 and click on Enhancements. Then double click on Business AddIns. For example if you want to find the BADI's for the standard transaction ME22n, the procedure is as follows. This example shows, finding the way of BADI names by providing the Package of ME22n. 1) Go to transaction ME22n. Select the System option from the menu and then click on Status. It displays the following information.

2) Double click on the program name i.e. SAPLMEGUI. It will take you into the program and click on Go to tab from the Menu. There we can find the package name of the standard transaction ME22n.Copy and paste it in the package filed.

Bangalore

202

3) Now Press F8, a list of BADI names will be displayed as shown below. Select the appropriate BADI name and implement it based on the business requirement using the transaction SE19. Method 3: Finding the BADI names using SE18 transaction 1) Go to transaction SE 18. Select F4 help for the definition name and click on Information System button as shown below.

Bangalore

203

2). A pop-up screen will be displayed and give the package name for any standard transaction say VA02. Finding the package is explained above. Please refer above method to find the package name. The package name for VA02 transaction is 'VA.'

Bangalore

204

3) A list of BADI names will be displayed for the transaction VA02. Select the appropriate BADI name and implement it using T-code SE19. Example : This Example explains how to implement BADI's. Here I am trying to show how to add custom screen to the ME23N Transactions using BADI's. The procedure is as explained below. Find the BADI using the method 1 as shown above.

The BADI name to add the custom screen to ME23n is 'ME_GUI_PO_CUST'.

Bangalore

205

- Go to T-code SE19 and create an implementation ZME_GUI_PO_CUST and then click on create button - Give the Definition name "ME_GUI_PO_CUST" and continue, give short text, save - Click on Interface Tab, you can find the implementation class name as ZCL_IM_ME_GUI_PO_CUST2. - Click on ZCL_IM_ME_GUI_PO_CUST2, which will take you to SE24. - Add "MMMFD" in the Type Group Section of properties tab. - Go to Attributes section and declare the following attribute - SUBSCREEN1 Constant Public Type MEPO_NAME Name of a View 'ITEMSCREEN1 '. Go to Methods section, you can find the BADI interface methods. Double click on the method "IF_EX_ME_GUI_PO_CUST~SUBSCRIBE", this method is having 3 parameters

Go to the code section of the method and add the following code there. Code for IF_EX_ME_GUI_PO_CUST~SUBSCRIBE: DATA: ls_subscriber LIKE LINE OF re_subscribers. *--FIRST SCREEN POPULATION

Bangalore

206

*--we want to add a customer subscreen on the item detail tab CHECK im_application = 'PO'. CHECK im_element = 'ITEM'. *--each line in re_subscribers generates a subscreen. We add one subscreen *--in this example CLEAR re_subscribers[]. *--the name is a unique identifier for the subscreen and defined in this *--class definition ls_subscriber-name = subscreen1. *--the dynpro number to use ls_subscriber-dynpro = '0002'. *--the program where the dynpro can be found ls_subscriber-program = 'ZME_GUI_PO_CUST_SCREEN'. *--each subscreen needs itsown DDIC-Structure ls_subscriber-struct_name = 'ZMARA'. *--a label can be defined ls_subscriber-label = 'Cust BADI'. *--the position within the tabstrib can be defined ls_subscriber-position = 7. *--the height of the screen can be defined here. Currently we suport two *--screen sizes: *--value 7 a 16 line subscreen ls_subscriber-height = 7. APPEND ls_subscriber TO re_subscribers. Save and check & back Double click on method IF_EX_ME_GUI_PO_CUST~MAP_DYNPRO_FIELDS". Add the following code in the method. *given the field catalog of structure ZMARA we have to *establish a mapping to metafields which are used for field selection *purposes and error handling Standard definitions can be found in type *pool MMMFD. It is important for customer fields to use integer *constants above 90000000 for the metafield. FIELD-SYMBOLS: LIKE LINE OF ch_mapping. LOOP AT ch_mapping ASSIGNING .

Bangalore

207

CASE -fieldname. WHEN 'MATNR'. -metafield = mmmfd_cust_08. WHEN 'MTART'.

-metafield = mmmfd_cust_09.

WHEN 'MATKL'. ENDCASE.

-metafield = mmmfd_cust_10.

ENDLOOP. The metafield mapping important for field selection & error handling purpose. Save, check and back Activate the Implementation class. Activate the BADI Implementation. Now create a structure in SE11 with the name ZMARA. Add the following fields in the structure.

Now Create a Program with the Name 'ZME_GUI_PO_CUST_SCREEN' and create a screen with sub screen type with the number 0002.

Bangalore

208

Add the fields on to screen from ZMARA program 'ZME_GUI_PO_CUST_SCREEN'.

De comments the PBO module in screen flow logic & create the module in above program.

Bangalore

209

Add the following code in program ZME_GUI_PO_CUST_SCREEN. TABLES: ZMARA. DATA: call_subscreen TYPE sy-dynnr, call_prog TYPE sy-repid, call_view TYPE REF TO cl_screen_view_mm, call_view_stack TYPE REF TO cl_screen_view_mm OCCURS 0. *---------------------------------------------------------------------* * FORM SET_SUBSCREEN_AND_PROG * *---------------------------------------------------------------------* * ........ * *---------------------------------------------------------------------* * --> DYNNR * * --> PROG * * --> VIEW * * --> TO * * --> CL_SCREEN_VIEW_MM * *--------------------------------------------------------------------* FORM set_subscreen_and_prog USING dynnr TYPE sy-dynnr prog TYPE sy-repid view TYPE REF TO cl_screen_view_mm. call_subscreen = dynnr. call_prog = prog. call_view = view. ENDFORM. *&---------------------------------------------------------------------* *& Module STATUS_0002 OUTPUT *&---------------------------------------------------------------------* * text *----------------------------------------------------------------------* MODULE STATUS_0002 OUTPUT. SELECT SINGLE * FROM MARA INTO CORRESPONDING FIELDS OF ZMARA WHERE MATNR = '100-100'. ENDMODULE. " STATUS_0002 OUTPUT The sub-routine "set_subscreen_and_prog" is must with the same signature. This routine is called from BADI to call the sub screen. Activate the screen & program. Now Go to T-Code ME23N to test the application. You can find a new tab is added in the item level with the name CUST BADI. Bangalore

210

Final Output:

Bangalore

211