SAP - All About SAP Scripts / Layout Sets / Forms

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 Sales order confirmation
• RVDELNOTE Picking List
• RVPICKSIN Picking List
• RVINVOICE 01 Invoice
• MEDRUCK Purchase Order
• F110_PRENUM_CHCK Pre-numbered check

Usually you don’t create layout sets, instead, you copy the existing layout sets with some modification to the existing layout sets. SAP doesn’t allow you to modify the layout sets. You need to copy the existing layout set to your own layout set and then do all the modification.

Procedure to copy the existing layout sets:

Tools  Word processing  Layout sets.
Utilities  Copy from client
• Enter the name of the layout set in layout name.
• Enter target layout set name
• Click execute

The SAP standard layout set uses D German as the original language. In order to modify the copied layout set, the original language of the set must be changed to the language in which you are working.

To convert language:
Utilities – Convert original language
Click OK.
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

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

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:

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
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

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


NEW–PAGE: SAP Script automatically carries out a page break if window MAIN of one page is filled with NEW-PAGE command. You can face page break at any point. The current page is completed and the text in the following line is written on new page. If no name is defined, then, the next page attributes from page setup is taken.

Syntax:
/: NEW – PAGE [PAGE-NAME]

NEW–WINDOW: You can have 99 MAIN windows on one page. If MAIN window is filled, then the next MAIN window is accessed automatically. With NEW-WINDOW command, you can call next main window even if the current MAIN window is not yet completely filled.

PROTECT: You can determine that a paragraph must not be separated by a page break. The lines in this command are printed together on one page. If the space is enough on current page, then all the lines are printed on current page. If, however the space is not sufficient the PROTECT command works as a ‘NEW-PAGE’.
Syntax:

/: PROTECT
/: ENDPROTECT

SET COUNTRY: Some field types are formatted country – specifically. E.G. date. Normally the display types are defined in the user master record with the control command set country, an alternative to that in the user master record can be chosen.
Syntax:
/: SET COUNTRY

SET DATE MASK: Standard display of date can be changed
Syntax:
e.g. SET DATE MASK = ‘MM DDDD (Day in full) yyyy’

You can switch back to default display of date by
/: SET DATE MASK = ‘ ‘

SET TIME MASK: Standard display of time can be changed
Syntax:
/: SET TIME MASK = ‘HH:MM’.

TOP-ENDTOP: For main window, you can determine lines, which are always O/P automatically at the top of the window.

SAP - Transport System, Transport Request & Version Management.

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<900002>
Where DD1 is System Identification Number (SID)
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.

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


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

SAP - All About Workbench Organizer.

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
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.

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



Develop System: New Development No development

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.

SAP ABAP - VIEWS - Introduction, Types & Creating It.

A view is an aggregated dictionary object. Aggregate object or complex object are objects, which are created by using object. E.g., Table is created using data element and domain. A view is created using tables.

A view is an imaginary table or virtual table. Using one or more tables can create a view. Physically, view does not contain any data. The view is filled dynamically during runtime.

View is mainly used to restrict or limit, access to information or data by employees, area, plant and so on. By using view, you can display information specific to a particular user or to their work or the information for which they have the right to access.

Types of Views:

R/3 System offers following types of views:
• Database View: You can create this view on transparent table. It supports all the three operations like Selection, Projection & Join

• Projection View: This type allows you to suppress some fields from the transparent table. This view is defined only with relational operator projection.

• Help View: These views are exclusively used by the SAP help system. All relational operators are supported. These views are generated when the user presses F4 function key on the field on selection screen. You can see these views only with SAP help and not with open SQL statements.

• Maintenance View: This type of view enables the maintenance of a group of related tables using SM30 Transaction, which is for extended table maintenance.


Creating View:

• From initial screen of data dictionary, enter the name of object i.e. view.
• Select view radio button and click on the push button.
• Dialog box is displayed for types of views.
• Select the view type.
• On the next screen, you have to pass following parameters.
• Short text
• In the table box you need to enter the table names, which are to be related.
• In join table box you need to join the two tables.
• Click on the TABFIELD. System displays the dialog box for all the table fields and user can select the fields from this screen. These fields are displayed in the view fields box.
• Save and Activate: When the view is activated, view is automatically created in the underlying database system. As long as the table exists in the database, the view also exists (Unless you delete it).

SAP - SQL Trace & It's Importance (ST05).

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.

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.

SAP - Measure Performance Of ABAP Program - RunTime Analysis.

How do you measure the performance of a program in ABAP?

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.

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.

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.

Lock Objects Concept In SAP ABAP

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.

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. This mechanism also defines LUW i.e. Logical Unit of Work. 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. The LUW starts when a lock entry is created in the system table and ends when the lock is released.


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.

Working With Matchcode Objects In Sap ABAP.

A Matchcode is an aggregated object and it gives list of possible values for the user. A matchcode is a collection of search terms on which you retrieve a data from the database table.

All matchcode are associated with either selection criteria or parameters. When an input field has a little triangle in the right-hand corner, it indicates that it has an associated matchcode. When you click on drop-down arrow or press F4 button, it gives a list of all possible values. For example Matnr field i.e. material number from MARA table, user might not know all the material number, but they might know other details like material description, type or any other details. You can create matchcode, which has all these search terms i.e. you can create matchcode with description as search term or matchcode with type as search term.

R/3 system includes many predefined matchcode but developers can create new matchcode as is created in following case. Usually, system displays list of possible values for all the primary keys with particular search term. Usually you create matchcode in following cases:

When you use non-primary key of input.
You need different search term for the primary key.

Creating Matchcode object:

Entire Matchcode object is created in two steps:

Defining of Matchcode object.
Defining one or more search ids for the object.

Defining Matchcode Object:

It includes all the tables and fields, which make up the Matchcode, which are used for Matchcode Ids.
Steps for defining Matchcode object are as follows:

From dictionary, enter name (four character).
Select Matchcode radiobutton and click on CREATE.
Define attributes for the object i.e. description.

Select primary table.
Select the fields for the table by clicking on the fields.
Activate the object.

If at all you are selecting secondary table then it is done after selecting primary table.
And steps are as follows:
Tables  Choose secondary table. A dialog box appears, which displays list of possible secondary tales. Select the table by Choose  copy.

To activate the object, Matchcode object - activate

Creating Matchcode ID's:

Once the object is created, you need to define search term for the object and steps are as follows:

Click on the Matchcode ID from maintenance screen.
Enter attributes for the Matchcode Id.
Short text.
Update type - Default is 1 for logical updating. It means that at the moment when you access the Matchcode object, the table is created like view. Unlike logical updating, physical updates are: A,S,P.
System Matchcode: If you click this particular field, it indicates a system matchcode, which is used by SAP software and cannot be changed by the end user.
Autho.checks: If it is checked, the system performs authorization checks for this matchcode Id.


Selecting Secondary Tables:

Position the cursor on the base table of the ID.
Edit  Choose secondary tables
A dialog box appears listing the tables linked to the table by foreign keys
Select table.
Save.
Selecting fields for Matchcode ID

Select fields.
Choose fields.
Once all the fields are selected, click on copy fields.
Fields are transferred to the matchcode ID.


Activation of ID:

A corresponding database view is created in the database during activation for the Ids of update type I. During activation, a check is made to see whether the corresponding index to support view selection exists in the database. If it doesn’t, a warning is displayed.

Testing the Matchcode ID.

To test the matchcode Id:

Maintain matchcode object.
Utilities  display matchcode data.

Using Matchcode:

When the user do not know which matchcodes are available for a field, user can find the matchcode by:

Positioning the cursor on a field and clicking on drop arrow or pressing the F4 key.
A dialog box appears with a list of available matchcode.
User can select another matchcode by clicking on the NEW selection button.
Double click on a matchcode to use it. If you want to use this as default matchcode, click on standard button. If user does this once, the selected matchcode is proposed automatically the next time.
You can enter the search term and press ENTER. If search term is not specified, the system displays all the records for the specific matchcode.

Changing The Screen During Runtime / At-Selection Screen Output Command.

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:

Field Name Length Description
NAME 30 Name of screen field
GROUP1 3 Field belongs to field group1
GROUP2 3 Group 2
GROUP3 3 Group 3
GROUP4 3 Group 4
ACTIVE 1 Hide/Show
REQUIRED 1 Field input is mandatory
INPUT 1 Enable/Disable
OUTPUT 1 Field for display only
INTENSIFIED 1 Field is highlighted.
INVISIBLE 1 Field is suppressed.
LENGTH 1 Field output length is reduced
DISPLAY 3D 1 Field is displayed with 3-D Frame
VALUE_HELP 1 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.

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

Help & Value Request In Sap ABAP.

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.

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.

Matchcode objects: Are aggregated dictionary objects and detailed procedure to create these objects is explained in the later part of the material.
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.

Creating A Subscreen -SAP ABAP.

A subscreen is a screen within screen. Consider the following case.




If user clicks on FIRST pushbutton, you want to display details of MARA table and if user clicks on the SECOND pushbutton, you want to display details of MARD table. You can do this by calling two different screens. But the information will be displayed on the next screen. Displaying data on the same screen is possible by using SUBSCREENS.

Step to create a subscreen are as follows:

• Create a subscreen area on MAIN screen and name it.
• Create a separate screen of subscreen type.
• Arrange the fields on this screen so that they fit in subscreen area exactly. Only when it is larger, the part of the screen that fits in the main area will be visible.
• Write code for calling subscreen in flow logic.

To call subscreen, from your flow logic, you need to include the statement both in PAI and PBO.




Syntax

PBO.
Call subscreen including <’screen no’>.

PAI.

Call subscreen .
Area - is the name of the area on main screen.
Prg. Name - is the name of the module pool program.
Screen number - is subscreen screen number.

Some of the don’ts with subscreen are:

GUI status cannot be set to the subscreen
• OKCODE is not applicable to the subscreen.
• Subscreen cannot call another screen.
• It cannot contain AT EXIT-COMMAND.

You can call multiple subscreen in the same area (at any given point of time, only one subscreen can be called in the subscreen area) and is done dynamically during runtime by using variable screen number.

SAP ABAP - Step Loops - Types & How To Create.

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.
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.

Difference Between Call Screen, Set Screen & Leave Screen.

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.

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.


Subscreens

A subscreen is a screen within screen. Consider the following case.




If user clicks on FIRST pushbutton, you want to display details of MARA table and if user clicks on the SECOND pushbutton, you want to display details of MARD table. You can do this by calling two different screens. But the information will be displayed on the next screen. Displaying data on the same screen is possible by using SUBSCREENS.

Step to create a subscreen are as follows:

• Create a subscreen area on MAIN screen and name it.
• Create a separate screen of subscreen type.
• Arrange the fields on this screen so that they fit in subscreen area exactly. Only when it is larger, the part of the screen that fits in the main area will be visible.
• Write code for calling subscreen in flow logic.

To call subscreen, from your flow logic, you need to include the statement both in PAI and PBO.




Syntax

PBO.
Call subscreen including <’screen no’>.

PAI.

Call subscreen .
Area - is the name of the area on main screen.
Prg. Name - is the name of the module pool program.
Screen number - is subscreen screen number.

Some of the don’ts with subscreen are:

GUI status cannot be set to the subscreen
• OKCODE is not applicable to the subscreen.
• Subscreen cannot call another screen.
• It cannot contain AT EXIT-COMMAND.

You can call multiple subscreen in the same area (at any given point of time, only one subscreen can be called in the subscreen area) and is done dynamically during runtime by using variable screen number.

SAP ABAP - Table Control - Introduction, Syntax & Example.

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.

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 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 LOOP-ENDLOOP, 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:

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.
• In the same way, all the records of the internal table are passed to the table control.

SAP ABAP - Screen painter & How To Use It (SE51 t-code).

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:



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.
• 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.

• 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.

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.

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.

Introduction To 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.

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:

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:

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
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.

About at Exit – Command

Automatic field checks can be avoided by AT EXIT-COMMAND, which works exactly the same way as Cancel works on application tools bar. In the R/3 screen, if you want to quit the processing of that particular screen without entering the mandatory fields, user can click the Cancel button. Same functionality can be incorporated in the user-defined transaction by using AT EXIT-COMMAND. This module can be called before the system executes the automatic field checks and it goes without saying that before PAI event. Code for AT EXIT-COMMAND in flow logic and in module pool program can be written as follows:

In Flow Logic

Process After Input.
Module exit AT EXIT-COMMAND.
In module pool program.
Module exit.
Case okcode.
When ‘Exit’.
Leave to screen 0.

To achieve this kind of functionality a pushbutton or menu item should be assigned a function type ‘E’. It tells the system to process this particular module before carrying out any field checks.

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’).

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.

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

Logical Unit of Work (LUW) - SAP ABAP.

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.

• 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.

Introduction To Transaction(T-Codes / SE93) In SAP ABAP.

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.

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.

Important System Fields For Reports - ABAP.

Sy-linct - Gives total line numbers for a page.
Sy-linno - Gives current line number on the list
Sy-lsind - Index of the lists created in interactive report
Sy-listi - Index of the list from where event was triggered, usually previous list
Sy-lilli - Line number of a list from where event was triggered
Sy-lisel - Contents of a line from where event was triggered
Sy-ucomm - Holds the function code of clicked menu item or function key

ABAP Sample Exercise - 1.

EXERCISES

INTERNAL TABLES and REPORTS

1 Create an internal table taking all the fields from BKPF and display fields Company code, Document number, Document type and date of document.

2 Create an internal table taking fields’ Company code, Document number, Account type and Tax code from table BSEG and display the same with column headings.

3 Create an internal table with following fields:
Sales Document and Material from table VBAP.
Date, Name of the user and sales document type from table VBAK and
Price group and customer group from table VBKD.
Sort the table according to Material number and display the contents.

4 Create an internal table called T_BSIS having a similar structure as table BSIS. Explore all possible methods to create the internal table with header line / without header line. (use data types, data … begin of ….end of, data …. data …. Include structure … etc.)
Also create a field string F_BSIS. Populate the internal code and display contents of BSIS. Sort the table according to company code and display contents.

5 Determine for each material type (MTART) the 5 table entries with the highest gross weight (as a ranked list).
To do this, read the table MARA and store the material type (MTART), material number (MATNR), unit of measure (MEINS) and gross weight (BRGEW) into an internal table.
Allow the user to specify the Material type as a parameter on the selection screen.

6 Create a list of the maximum number of available seats for each carrier. To do this, read the table SFLIGHT and store the airline carrier id (CARRID) and maximum number of seats (SEATSMAX) in an internal table. Determine the total number of seats for each airline carrier when filing the int’ table.


7 Read the table SFLIGHT into an internal table and then output the internal table with the fields CARRID, FLDATE and PRICE.
Delete all the internal table entries where the airline carrier (CARRID) is not equal to LH. Read the internal table with entry with the key CARRID = LH and CONNID = 0400, multiply the price by 3 and write the modified entry back to the internal table. Then Output the internal table.


8 Read table TABNA into internal table and output the fields Country, Id, Name1, and Sales. Sort the table with Country.
Delete all internal table lines with sales lower than 50,000.
Read internal table with key ‘GB’ and ‘00000003’ and multiply the sales by 3 and change table entry.
Insert any one record of your choice.
Find out how many lines are there in the internal table.
Remove all the contents of the table.
De-allocate the memory associated with table.

9 Use tables LFA1, LFB1 and LFM1.
Define an internal table with the following:
Lifnr like Lfa1-lifnr,
Bukrs like Lfb1-bukrs,
Ekorg like Lfm1-ekorg.
Add data from these table into the internal tables.
Sort the internal table Lifnr.
Read the internal table with Lifnr = ‘A5’ and change name to trainee.
Put back the record into the table.
Delete first three records of internal table.
Clear header for internal table each time you access a record.


10 Create a report, which will give the existing stock for a material. The report should have subtotal of the stock for each storage location and Grand total of the stock at the end of the plant.


Plant data should start at new page.
Input: Selection screen which will allow one to select a range of materials.
Materials:
Output Report format as follows:

Plant Storage location Material number Description Stock
(unrestricted)


Grand total * * * * * *


Tables and fields:
Material Number MARA-MATNR
Description MAKT-MAKTX
Plant MARC-WERKS
Storage location MARD-LGORT
Stock MARD-LABST
Use Standard Formatting colors.
Exception handling:
Error message “ Material not found “ – if Material not present.


11 Generate a report to list the following details from the tables LFA1 & LFB1 vendor no., vendor name, city, state, telephone no., fax no., company code and terms of payment. User shall have options to select the vendor number range for which the report is generated.
.

Report title: Vendor Master Listing 2
Vendor Name: _____________ Vendor no. : _____________
Address: __________________
Telephone no. _______________ Fax no : ______________
Company code Terms of payments
_____________ _________________

All text used in the report shall be generated using text elements only.
The output list shall have a footer showing page no., date and Intelligroup’(left corner)


12 Generate a report for displaying material description, plant & storage data.
Input: Material number (MARA-MATNR)
Data to be displayed for the following three materials only.
1. BP770M15
2. FP56790031
3. FP28652011

Output format:
11/11/1998 Report to analyze material stocks
Material No. Description
FP96412101 Meditech Patterned Weld Rod
Oatmeal 60’
Plant Storage Loc. Unrestricted stock
xxxx xxxxxxxxxxx xxxxxxxxxxxxxxx

All texts are to be generated using Text Elements only.
Use tables: MARA, MAKT, MARC and MARD.

SUBROUTINES

1. Read a number between 0 and 100 and another digit between 0 and 9. Write a subroutine that will calculate the sum of all numbers (below the limit) that end with the digit. The parameters to be passed are limit and digit both by value and sum by reference.

Ex. If limit = 67 and digit = 4 then sum should be the sum of 4,14,24,34, ..64.

2. Write a subroutine CENTRE-STRING, which will output a string on the center of a line. The subroutine will accept parameters STRING pass by value.

3. Write a program extensively using subroutines to print the equivalent number in words.
For example: if the number is 66, the output should be SIXTY SIX.
Limit the number range from 0 – 99.
Accept the input number as a parameter.

4. Accept a date from the user.
Write a date as dd-mm-yyyy where mm is month written as JAN/FEB/Mar…etc.
Make use of subroutines.

5 For each flight connection, calculate the sales for all flights of an airline carrier. Use internal table for calculating the sales. Use a subroutine for the output by passing the internal table as the paramete

At User-Command Command With Example - ABAP

AT USER-COMMAND

When the user selects the menu item or presses any function key, the event that is triggered is AT USER-COMMAND, and can be handled in the program by writing code for the same. The system variable SY-UCOMM stores the function code for the clicked menu item or for the function key and the same can be checked in the program. Sample code would look like

AT USER-COMMAND.

Case sy-ucomm.
When ‘DISP’.
Select * from sflight.
Write sflight-carrid, sflight-connid.
Endselect.

When ‘EXIT’.
LEAVE.

If GUI status, suppose you have set menu bar for two items and the function code is ‘DISP’ and ‘EXIT’ respectively. If the user clicks the menu item ‘DISPLAY’, then function code ‘DISP’ is stored in the sy-ucomm and whatever is written under the when ‘DISP’, gets executed. This is applicable for EXIT as well.

Sy-lsind for the screen increases when the user clicks the menu item.

Usually you have combination of all the three navigations in your user interface, i.e., you have to create menu bar, assign function code for the function keys and write code to handle all this in addition to handling double clicking.

Things to remember while using all the combinations:

• Sy-lsind increases even if you select menu-item.

• When the user double clicks on particular line, value of sy-ucomm is ‘PICK.

• If you set sy-lsind = 2 for your 4th secondary list, when control is transferred to the 2nd secondary list, all the other lists after 2nd are lost or memory allocated to them is lost.

• Sy-lisel also gives you the value of clicked line but in this case you cannot differentiate between field. To retrieve the exact field, you have to know the field length of each field.

• If you use statement SY-LSIND = 1.

The system reacts to a manipulation of SY-LSIND only at the end of an event, directly before displaying the secondary list. So, if within the processing block, you use statements whose INDEX options access the list with the index SY-LSIND, make sure that you manipulate the SY-LSIND field only after processing these statements. The best way is to have it always at the `as the last statement’ of the processing block.

Tool Bars / GUI Status / PR-STATUS - SAP ABAP.

An interactive report starts with basic list where condensed information is stored on basic list and detailed information is stored on secondary list. To implement this kind of reporting, you need to provide the user with things like menu, icons, function keys. You also need to write code, which must react, to the user’s action.

For this, you need to create the interface, which interacts with the user.

The user interface is independent of the program or list or screen. However both interface and list can be associated by means of GUI status. A GUI status groups together the interface components.

• Menu bar
• Application tool bar
• Function keys
• Title bar

The last element of the user interface is independent of the GUI status i.e., titlebar.

To assign status to your list the statement SET PR-STATUS.

Some facts about GUI status are:

• A program can have multiple GUI status and titles for different lists.
• Multiple lists can be assigned to same GUI status.
• Normally both GUI status and title go together.

Function code

An important concept, when working with user interface. Function is a four character alphanumeric code, which the system stores in the system variable called SY-UCOMM for each function key, push button, or menu option. Whenever any push button is clicked or menu option is selected, the code attached to that, is stored in SY-UCOMM and can be handled in your program.


Menu painter

Menu painter is the ABAP/4 workbench tool for creating and maintaining user interface.

Starting Menu Painter

ABAP/4 development workbench  menu painter
Or
Transaction SE41 in the command field.
Or
Through program SET PF-STATUS

If you double click on the variable, the system takes you to the menu painter screen.

Creating Menu bar

Steps involved are as follows:

• Enter the name in the first field. It is just a name given to the menu and is not displayed anywhere in the output.
• Enter the name of each menu item. You can create up to six menus (total eight menu items are available, out of which system and help are mandatory).
• Enter name of the menu items and function code. You can have fifteen menu items under one menu.

If you leave function blank, the system assumes that this particular menu item will have submenu. You can create the sub menu items under this menu item. User can go up to three levels.



Creating Application Tool Bar





Assign Function Keys


In Application tool bar you can include icon assigned for function keys.
Procedure:

• Select function key.
• From the menu, more utilities -  change text type. The system displays a dialog box, click on icon and presses ENTER.
• Select icon from list of icons displayed


Creating GUI title

From your program, you can set title for your list and SET TITLEBAR is used.

Syntax:

SET TITLEBAR .

Here var can be any three-character name. When developer double clicks on the var, system displays the dialog box in which you enter the title number, the description, and the actual text for title.

Similar to dictionary objects, the GUI status must be generated to be accessible by program.


AT USER-COMMAND

When the user selects the menu item or presses any function key, the event that is triggered is AT USER-COMMAND, and can be handled in the program by writing code for the same. The system variable SY-UCOMM stores the function code for the clicked menu item or for the function key and the same can be checked in the program. Sample code would look like

AT USER-COMMAND.

Case sy-ucomm.
When ‘DISP’.
Select * from sflight.
Write sflight-carrid, sflight-connid.
Endselect.

When ‘EXIT’.
LEAVE.

If GUI status, suppose you have set menu bar for two items and the function code is ‘DISP’ and ‘EXIT’ respectively. If the user clicks the menu item ‘DISPLAY’, then function code ‘DISP’ is stored in the sy-ucomm and whatever is written under the when ‘DISP’, gets executed. This is applicable for EXIT as well.

Sy-lsind for the screen increases when the user clicks the menu item.

Usually you have combination of all the three navigations in your user interface, i.e., you have to create menu bar, assign function code for the function keys and write code to handle all this in addition to handling double clicking.

Things to remember while using all the combinations:

• Sy-lsind increases even if you select menu-item.

• When the user double clicks on particular line, value of sy-ucomm is ‘PICK.

• If you set sy-lsind = 2 for your 4th secondary list, when control is transferred to the 2nd secondary list, all the other lists after 2nd are lost or memory allocated to them is lost.

• Sy-lisel also gives you the value of clicked line but in this case you cannot differentiate between field. To retrieve the exact field, you have to know the field length of each field.

• If you use statement SY-LSIND = 1.

The system reacts to a manipulation of SY-LSIND only at the end of an event, directly before displaying the secondary list. So, if within the processing block, you use statements whose INDEX options access the list with the index SY-LSIND, make sure that you manipulate the SY-LSIND field only after processing these statements. The best way is to have it always at the `as the last statement’ of the processing block.

HIDE Technique In ABAP Interactive Reporting

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.


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.

When this code is executed,


• 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.

A sample program for AT LINE-SELECTION.

AT LINE-SELECTION Event In Interactive Report Programming

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.

Interactive Reports - SAP ABAP.

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 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.

Using Variants With Selection Criteria In Report Programming.

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 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.