4-abap development tools

Title Title Title Title TitleABAP Development Tools
4-ABAP Development Tools.*
This is PricewaterhouseCoopers PROPRIETARY MATERIAL (hereafter, the Material) intended for internal use only. You may not rent, lease or distribute the Material to clients or other third parties, but you may transfer the Material to other employees of PricewaterhouseCoopers.
ABAP Development Tools
List of Topics
Module Map
Learning Objectives
Learn new enhancements in Module Pool Programming
Screen Painter
Data Transfer Workbench
Batch Input Recorder
Module Map
Inactive Sources
As of release 4.6, new functionality for inactive sources has been introduced
This enhancement provides developers with a separate local view of the R/3 Repository and is the basis for a "local runtime system”
Changes to development objects can be tested within this local system without disturbing the wider development environment
The main advantage of inactive sources is that the development process becomes seamless.
For example, it is now possible for you to change the interface of a function module without having those changes immediately visible in programs that call it. The changes are only visible system-wide once the object has been activated
The concept avoids redundant program generation. Previously, the system generated a new load version whenever you saved a program in the ABAP Editor. The introduction of inactive sources means that the program is not generated until you decide that it is appropriate to activate it.
The introduction of inactive sources is accompanied by a standardization of the working methods of the different ABAP Workbench tools. In addition, a check on the main program performs a consistency check whenever you activate an object.
Inactive Sources: Terminology
There are three essential new terms used in the context of inactive sources:
Active version: The database version of a development object used to generate the runtime object
Inactive version: A saved database version of a database object that does not affect the runtime object (even after regeneration)
Worklist: The set of all inactive versions of development objects belonging to a particular user
When a user edits a new object, it is added to his or her worklist. When a user activates an object, it is removed from the worklist.
Aside from local private objects, a user's worklist is a subset of all of the objects he or she is working on and that are included in open tasks administered by the Workbench Organizer.
Inactive Sources - Object Status
Inactive Sources: Procedure
Objects are always saved as inactive versions
When you create or change a development object and then save it, an inactive version is written to the database
Inactive objects are included in the user's worklist
Development objects that have been edited and saved are placed in the worklist of the developer responsible
Each user has their own worklist, which other users cannot access directly
You can link worklists. If another user changes a development object and saves it, the object is included in his or her worklist.
The ABAP Workbench tools always take into account the user's worklist.
In display mode, the user always sees objects from his or her own worklist in their inactive version, but all other objects in their active version (even if an inactive version exists). This particularly applies to navigation within the ABAP Workbench.
In change mode, the latest version is always displayed, regardless of whether it is included in the user's worklist or not.
All tools display the current status of the object that you are currently working on. You can display an overview of your work list and of all inactive objects in the system. You activate your worklist at any time. Furthermore, you can decide whether to activate the whole worklist or just a part of it. When you activate an object, it is removed from the worklist.
Only the active version of an object is used to generate runtime objects.
Users without a task in the change request cannot change the object, and therefore cannot see the active version in display mode. You cannot release a transport request until all of its objects have been activated.
Activating Objects
Entire worklist
Selected objects
Prerequisites:
Before activating an object, the system checks the syntax of the entire object (main program, function group, or class)
Any syntax errors are displayed in a list
It is still possible to activate objects even if they contain errors. This can be useful if you want to create templates for coding generators.
When you activate an object, its syntax is checked. The check uses the inactive versions of the components selected for activation, but the active versions of all other components.
The inactive versions are used to create active versions of the objects. A new runtime version is then generated. Finally, the inactive version is deleted and removed from the worklist.
When you activate an entire object from the object list, only the inactive objects belonging to that object are displayed in the worklist. However, you can display all of your inactive objects by choosing Whole worklist.
To activate an object, complete the following steps:
Select the relevant object in the object list
Choose Activate from the context menu or the icon. Your worklist appears. The selected object is highlighted.
Choose Continue to confirm your selection
A message in the status bar informs you that the object has been successfully activated.
Overview of Inactive Objects
It is possible to display various sets of inactive development objects within the system
The following functions are available:
Activate the selected objects
Display all inactive objects belonging to a request in the Workbench Organizer
Display the worklist for a specified user
Display all inactive sub-objects for a main program or function group
Display all inactive objects in the system
To display the overview follow the menu path Environment Inactive objects anywhere in the ABAP Workbench.
Once you have selected an object, you can open it using the relevant tool and display or change it. You can also place objects from another user in your own worklist ("networked worklists") and activate them.
The current status of a development object is always displayed in the tool with which you are editing it.
The status indicates the following:
Whether a database version exists for an existing development object (new Ö active/inactive).
Whether the current state of the object corresponds to the state of the object in the database (revised Ö saved).
The status saved is not explicitly displayed. Objects are always saved as inactive.
Whether the database version is inactive or active (inactive Öactive).
Effect of inactive sources
Save
Saves the object in an inactive version without a syntax check. Enters the object in your worklist.
Activate
Creates an active version from the existing inactive version. If an object contains components (like classes in ABAP Objects), you can activate individual components.
Before activating the object, the system checks the syntax of the entire object, then creates an active version, generates a runtime version, and deletes the corresponding entry from your worklist.
Generate
Creates a new runtime version from the existing active version. Unlike the 'Activate' function, this function only generates a new load version.
Display Active/Inactive Sources
If an object exists in both active and inactive versions, you can switch between the versions in the ABAP Workbench tools.
Delete
Both active and inactive versions are deleted.
Note that when you delete components of a global class in the Class Builder, they reappear in your worklist with the "Delete" icon. They are not finally deleted or removed from your worklist until you activate the relevant objects.
Copy
The system uses the active version of the source object, except in the Function Builder, where it asks you which version you want to copy if both an active and an inactive version exist). The new copy is always inactive.
Rename
Applies to both the active and inactive versions of an object.
Syntax check
Execute
A runtime object can only be generated from a syntactically-correct active version. The inactive version of an executable program can be run from the ABAP Editor. If you execute a program from the object list, there must be an active version.
Transport
Only active objects can be transported. You cannot release a transport request until all objects have been activated
Object list (SE80)
Displays all active and inactive objects. If an inactive version exists, the object is highlighted.
Where-used list
Like the object list, the where-used list is global, not user-specific. It is based on all objects.
Navigation
Navigation is user-specific, and takes your worklist into account. If an inactive version of an object exists and the object is in your worklist, you will see that inactive version. Otherwise, the active version is always displayed. This does not apply only to navigation in the various ABAP Workbench tools, but also from the object list or from a where-used list.
Debugging
The Debugger always displays the active version of an object.
Module Map
Calling Additional Selection Screens
[…..]
AT SELECTION-SCREEN. “event whenever selection screen CASE sy-dynnr. “is called (standard or other).
WHEN ‘1100’.
”dynamic call of additional screen
The Standard Selections screen can be used in interactive reporting, which will be displayed before the basic list.
In addition, further selection screens can be displayed.
[…..]
[…..]
CASE sy-dynnr. “called (standard or other).
WHEN ‘1100’.
[…..]
Menu Painter GUI Enhancements
Activate
To access the Menu Painter follow the menu path Tools ABAP Workbench Development User Interface Menu Painter, or use transaction code SE41.
List and List in Dialog Box are now called List Status and List in the Dialog Box, respectively.
The menu path Edit Delete menu path has been replaced by Edit Entry Delete.
Menu Painter
As of release 4.0 it is possible to create up to 35 pushbuttons in the application toolbar
Names have been extended for function codes, status names, titles and texts
Names have been extended for function codes, status names, titles, texts, as follows:
Function code 20 Characters
Status names 20 Characters
Title codes 20 Characters
Documentation 60 characters
Menu Painter
As of release 4.6, the Menu Painter is fully integrated with the new version of the ABAP Workbench
As well as its inclusion in the new design and navigation of the Object Navigator, the Menu Painter also contains the following new features:
Inactive sources
Defining application toolbars with fixed positioning (from release 4.5A)
Separators in application toolbars
When you call a GUI status from the Object Navigator, the Menu Painter is displayed in the work area.
The Menu Painter is still available as a standalone tool using Transaction SE41.
Merge List Functions
The “Merge List Functions” icon in the Function Key assignment section of the “Maintain Status” screen retrieves the standard SAP function codes
To access this functionality follow the menu path Utilities Help Texts Standards and Proposals for standard function code access (4.0 and 4.6)
Module Map
Screen Painter GUI Enhancements
Tabs
When you call a screen from the Object Navigator, the Screen Painter appears in the work area.
The new tabstrip control design allows you to access the attributes, element list, and flow logic directly.
The layout editor (alphanumeric or graphic) is accessible using a pushbutton.
You can still start the Screen Painter as a standalone tool using transaction SE51.
Screen Painter
As of release 4.6 the screen painter has been enhanced to make it easier to use:
Tabstrip control
Enhanced editor functions
Unlike conventional screen sequences, tabstrip controls allow the user to see all of the titles of the screens to which he might need to navigate within a task.
The following Editor Functions are available in the graphical Screen Painter:
Undo
Repeat
Cut
Copy
Paste
To access the Screen Painter follow the menu path Tools ABAP Workbench Development User Interface Screen Painter, or use transaction code SE51.
Screen Painter
As of release 4.6, the Screen Painter is included in the Object Navigator
The Screen Painter also contains the following new features:
Status display for inactive sources
Consistent forward and backward navigation
Dropdown list boxes for input/output fields, table controls (as of release 4.5A)
Function codes for checkboxes and radio buttons
Custom container (as of release 4.5A)
In addition to the 4.6 enhancements listed above, the following enhancements are also available:
Assigning a context to a screen or screen element
Visualization of double-click sensitive screen elements
Linking text and input/output fields
Scrollable subscreen areas
F1 help attached in graphical layout editor (from Release 4.5A)
Tabstrips
A tab is an area on a screen in which you can include several screens (tab pages) within a sub-screen
The user switches between the tab pages using the push buttons on the top of the tab
Tabstrips allow users to access multiple subscreens on one normal screen
The graphical screen painter is activated by the following menu path when in flow logic: Settings Graph Fullscreen.
Tabstrips can be created in either Graphical or Alphanumeric Screen Painter.
Tabstrips are batch input compatible
Tabstrips
Graphical Screen Painter is particularly desirable when creating tabstrips because of the intricacy involved
The actual tabstrip objects DO NOT display information to the user
Tabstrips must have subscreen areas painted onto them, which in turn hold subscreens that display information to the user
Creating Tabstrips
Begin with a normal type screen
Paint a tabstrip onto the normal screen
Paint one or more (depending on the type of tabstrip) subscreen areas onto the tabstrip
In the ABAP code, different subscreens are called into the subscreen area
It is these subscreens which display information to the user
Subscreens
Subscreens are created the same way normal screens and modal dialog boxes are created
Subscreens are called by other screens in your program
This allows for a more dynamic program since different groups of screen elements can be displayed on one screen
Subscreens are called in flow logic using the following syntax:
CALL SUBSCREEN <subscreen area name > INCLUDING <program name> ‘<subscreen #>’.
To designate a subscreen, select the appropriate radio button in the Screen Attributes.
Subscreens are displayed by other screens by defining a subscreen area in the screen painter.
Subscreens can be assigned statically or dynamically in a tabstrip control.
When screens are assigned statically (without the application server):
All fields are populated, and all subscreens are called into their subscreen areas before the screen holding the tabstrips is displayed.
The user can navigate between tabs without involving the application server.
Each tab must be given a function type of “P.” This can be done in the field’s attributes.
Using tabstrips without the application server will generally be faster because the user does not have to wait for the app server to be invoked before displaying the next tab.
When screens are assigned dynamically (with the application server):
The function code assigned to the tab must be determined in the PAI module of the current screen to determine the value the ACTIVETAB field should be set to.
The PBO must call the appropriate screen.
Each tab has a function type of ‘ ’ (space).
New Function Type
As of release 4.0 function type “P” is available
Used only in local GUI logic (i.e., when creating tabstrip controls)
Function codes of different types can be created:
‘ ’ - Program function
‘E’ - Exit command
Used to conditionally execute PAI modules with AT EXIT-COMMAND (covered in the next chapter).
‘S’ - System function
Used to conditionally execute PAI modules with AT CURSOR-SELECTION (covered in the next chapter).
‘P’ - Local GUI function
Used only in local GUI logic (I.e., when creating tabstrip controls). Does not populate the okcode field or sy-ucomm.
‘T’ - Start transaction
The function code must be a valid transaction code (in the ABAP Dictionary table TSTC). Triggering a function of this type is like performing a “LEAVE TO TRANSACTION <function code>” statement.
Each specific function code of a GUI can only be one function type.
Selection Screens as Subscreens
SELECT-OPTIONS: s_carr FOR spfli-carrid,
SELECTION-SCREEN BEGIN OF SCREEN 102 AS SUBSCREEN.
SELECT-OPTIONS: ...
PARAMETERS: ...
PARAMETERS: ...
SELECT-OPTIONS: ...
Subscreen 101
Subscreen 102
Subscreen 103
AS SUBSCREEN
AS SUBSCREEN
AS SUBSCREEN
Since it is possible to define selection screens as subscreens, you can include selection fields that you create in this way in any other screens. Selection screens as subscreens are processed similarly to other screens.
You define a selection screen as a subscreen as follows:
SELECTION-SCREEN BEGIN OF SCREEN <scrn> AS SUBSCREEN
[NESTING LEVEL <m>] [NO INTERVALS].
...
SELECTION-SCREEN END OF SCREEN <scrn>.
Optional additions: [NESTING LEVEL <m>]. Each box around a tabstrip control increases the
NESTING LEVEL by one.
[NO INTERVALS]. This option hides the HIGH fields for any selection criteria defined using SELECT-OPTIONS on the screen.
Defining A Tabstrip Control on the Selection Screen
...
...
SELECTION-SCREEN BEGIN OF TABBED BLOCK blockname FOR n LINES.
SELECTION-SCREEN TAB (length) tabname1 USER-COMMAND ucomm1 DEFAULT SCREEN 101.
SELECTION-SCREEN END OF BLOCK blockname.
INITIALIZATION.
SELECTION-SCREEN BEGIN OF TABBED BLOCK blockname FOR n LINES.
SELECTION-SCREEN END OF BLOCK blockname.
INITIALIZATION.
tabname1 = TEXT-001. "TEXT-001 EN: Connection
tabname2 = TEXT-002. "TEXT-002 EN: Flight
You define a subscreen area for a tabstrip control on a selection screen as follows: SELECTION-SCREEN BEGIN OF TABBED BLOCK <blockname> FOR <n> LINES.
SELECTION-SCREEN END OF BLOCK <blockname>.
The size of the subscreen area in lines is defined by <n>.
The system automatically generates a CONTROLS statement (CONTROLS: TABSTRIP_BLOCKNAME TYPE TABSTRIP.) You must not write your own CONTROLS statement. If you try to do so, a syntax error results.
You define the individual tab pages as follows:
SELECTION-SCREEN TAB (length) <name> USER-COMMAND <ucomm> [DEFAULT [PROGRAM <prog>/SCREEN <dynnr>]].
Optional additions: [DEFAULT [PROGRAM <prog>/SCREEN <dynnr>]].
Assign the selection screen to a tab page. If you use the DEFAULT addition, you must also use the SCREEN addition. The PROGRAM addition is optional. You only need it if the screen comes from another program.
You can delay specifying the link between the tab title and the selection screen until runtime. You can also change an existing assignment at runtime. To do this, fill the structure blockname. This is created automatically for every tabstrip block. The structure has the same name as the tabstrip block, and contains the fields PROG, DYNNR, and ACTIVETAB. For further information, refer to the online documentation in appendix reference SUB-2.
Custom subscreens
Context Menus
Screen area
Subscreen area
Area in the box
Elements that do not have their own menu inherit the area menu
List
Edit
Goto
Extras
Envir.
System
Help
Box
Subscreen area
Context menus (right mouse key, SHIFT F10) are shortcuts for functions that are frequently used.
They can be used to display context-sensitive menus. The context is defined by the position (cursor for SHIFT F10, mouse location for right mouse key) where the user called the context menu. If needed, you can specify the context more precisely with the displayed contents. This permits the user to select functions that are relevant for the current context using the context menu.
You define whether a context menu should be offered when you create a screen object (screens, input fields, table controls, boxes, ...). When the user selects a context menu on an object, an event mechanism (as understood by ABAP objects) calls a certain subroutine in the application program. The program is assigned a menu reference. The program uses this menu reference to build the display menu. Menus defined with the Menu Painter and dynamic menus can be used here.
After the user executes a menu function, the application program regains control and can react to the user input.
Context menus are assigned to output fields. When you assign a context menu to a box, table control or screen (normal or subscreen), all the subordinate output fields that do not have a context menu inherit that one.
Creating a Context Menu
Status attribute
Short text
Status type
Dialog status
Dialog box
Context menu
You can create a context menu from within the object list of the Object Navigator. Position the cursor on GUI status and right-click. The Object Navigator automatically opens the Menu Painter.
Of course you can also create a context menu directly in the Menu Painter.
A context menu is a special GUI status. Assign it a name, a descriptive text and status type Context menu.
Creating a Context Menu:
Code
Text
...
In a context menu you can link any function codes and function texts. In particular, you can take advantage of your screen pushbuttons. The functions already provided in the interface can be used as an F4 input help.
The link technique ensures consistent context menus in large applications.
You should observe the following rules when designing context menus.
Do not use any functions that cannot be found elsewhere in the system (pushbuttons or interface).
Avoid using more than two hierarchy levels in context menus.
Do not use more than 10 entries, but map all the available pushbuttons.
Use separators to structure the context menu optically.
Place object-specific statements at the beginning of the menu.
Linking Screen Objects
...
...
ENDFORM.
on_ctmenu_rbgframe
on_ctmenu_sub130
SUB130
RBGFRAME
Pressing the right mouse key triggers a callback routine in your program. You can create this callback routine in your application program with forward navigation. It is named ON_CTMENU_<name>. You define which callback routine is called in the Screen Painter.
You can directly assign a callback routine to input/output fields, text fields and status icons. Checkboxes, radio buttons and pushbuttons do not have their own callback routines. However, these fields can inherit context menus from boxes or screens.
If you assign a callback routine to a table control, it is triggered for all the fields of the table control that do not have their own callback routine.
The callback routine has the following form:
FORM ON_CTMENU_<name> USING p_menu TYPE REF TO cl_ctmenu.
<definition of the context menu>.
ENDFORM.
The context menu is built with a method call for the instance of class cl_ctmenu that was passed.
Using the Context Menu
CALL METHOD cl_ctmenu=>load_gui_status
ENDFORM.
Clicking with the right mouse key on an output field triggers the corresponding callback routine.
You can now use the static method load_gui_status of class cl_ctmenu to load a context menu that was predefined in the Menu Painter. Using other methods of class cl_ctmenu (see next slide) you can also completely rebuild the context menu or modify a loaded menu.
If the user triggers a function in the context menu, the corresponding function code is placed in the command field and triggered depending on function type PAI of the screen.
Module Map
The Data Transfer Workbench supports the automatic transfer of data from legacy systems into the R/3 System
The Workbench provides access to the standard programs as well as the necessary tools for transferring data
The Workbench is particularly useful for large amounts of data
It guarantees that data is transferred efficiently and ensures that data in the R/3 System is consistent
Administration and organization of data transfer projects
Tools for analyzing the required SAP structures
Integration of standard data transfer programs
Registration and integration of your own data transfer programs
Various techniques to load data into R/3
To access the Data Transfer Workbench follow the menu path Tools Data Transfer Workbench (transaction code SDXA).
You can also call the Workbench in the IMG under "Data Transfer Workbench: <Data transfer object>". In this case, the data transfer object is pre-allocated and selection using the Possible entries push button (F4) does not apply.
The data is read from a transfer file in SAP format and loaded into the R/3 System using one of the techniques below:
BAPI interface
Batch input
Direct input
Initial Data Transfer File
Before transferring the data automatically into the system, first convert the data from the legacy system into a suitable format
This initial file contains the relevant fields in the length and sequence specified by the structure
Use the data transfer file to see the fields of a transfer object in the R/3 System and the structure in which the data should be delivered
By choosing Transfer object Create init file, it is possible to create an empty transfer file for test purposes
By choosing Transfer object Create init file, you can create an empty transfer file for test purposes. This file can be used to illustrate how the fields are filled.
You display the transfer file by choosing Transfer object Display file. This displays the data records that the transfer file contains, as well as the structure tables for each data record. In the top line of the screen, the number of transactions displays the number of data records that the transfer file contains.
The system displays the fields of the transfer object in their predefined length and sequence. If you double-click on a structure line, this displays the fields of the structure you have chosen.
The various hierarchy levels of a data record are flagged with different colors (hierarchy level 1: green, hierarchy level 2: yellow, hierarchy level 3: blue).
You can display the structure of the transfer file by choosing Goto Interface structure. The interface structure gives a technical description of the transfer file and shows the structures that can be used and the sequence in which they should be used.
Editing the Data Transfer File
The Editor provides functionality to change a data transfer file
Particularly useful for editing transfer data during the test (before the data is actually transferred)
You access the Editor by choosing Transfer object Change file.
In addition to having the ability to delete and duplicate structures, you can also edit the fields in the structure, for example by entering field values. In the Editor, you can often use the Possible entries push button (F4) to display the possible entries.
If you want to work with different transfer files, you can use this function to copy an existing data transfer file. In doing so you can choose from where the files should be copied (for example, from the application server to the presentation server).
You can export the metadata of the transfer file or individual structures into the programming language you are using. It is currently possible to export into the programming languages COBOL, PL/1, C and P_RPG.
This conversion helps you to create a conversion program in the appropriate programming language.
You can start the data transfer program for a particular transfer object directly from the Workbench.
Testing the Data
It is possible to start data transfer objects that support input directly on-line
It is possible to create a data transfer file for test purposes using data that already exists in R/3 for the following records:
G/L account master records
Personnel planning
Although you are are not able to restart the data transfer program after it runs into errors, the advantage is that you can obtain concrete results more quickly. You can use this function to transfer financial documents, material masters and sales documents.
Because this tool is table driven, you can support other DX-objects by maintaining the underlying control tables.
The underlying control tables for this tool are SXDA0, SXDA1, SXDA2, SXDA3.
These tables can be maintained with transaction SM30, but SAP recommends not changing the settings for the existing entries.
If you want to add new entries, SAP recommends using only data transfer object numbers greater than 9000.
BDC_INSERT
Post local is a new 4.0 parameter in the BDC_INSERT function module
CALL FUNCTION ‘BDC_INSERT’
The “BDC_INSERT” function module inserts transaction data into a batch
input session.
The exporting parameters are as follows:
Tcode (required): The transaction code that is to be executed. In other words, the information in the BDC table refers to this transaction.
POST_LOCAL: If you set this parameter to ‘X’ the update will run in asynchronous mode instead of the default synchronous one (for the differences between the two update types see the chapter on CALL TRANSACTION)
The only tables parameter is:
Dynprotab (required): The BDC table with the transaction data.
The “BDC_INSERT” function module is “called” for each transaction entered into the batch input session.
A batch input session can include data for different transactions. The “TCODE” parameter indicates the appropriate transaction code. The BDC table contents must mimic the transaction code specified or an error will occur when the batch input session is processed.
For example, if you read vendor information from a sequential file, you will use the “Change Vendor” transaction (“FK02”) if the vendor already exists or the “Create Vendor” transaction (“FK01”) if the vendor does not exist. The BDC table for each of these transactions will be different because different screens are encountered and different fields must be filled.
The Batch Input Recorder allows the user to record transactions while they are being manually entered
The user can then create a batch input session to be executed at a later time
Once the transaction is recorded, a batch input program can be generated
This program is then available for modification by the programmer in order to meet customer requirements
The batch input recorder is a tool used to record transactions as they are manually entered. Based on this information, a batch input session can be generated which may be executed at a later time.
The transaction for recording a session is SHDB, or you may begin the BI recorder by selecting the Recording push button from the batch input overview initial screen.
The recording name is a user defined name and can match the BI session name which can later be created from the recording.
Begin an SAP transaction and start posting the transaction. After you have completed posting the SAP transaction, you either choose get transaction and save to end the recording or Next transaction and post another transaction. During one recording session multiple transactions can be invoked and recorded.
Once you saved the recording you can Change, display or Delete the recording.
The batch input recorder tool can serve as a good base for creating a batch input session
It allows the programmer to gather information on a specific transaction(s) such as screen numbers, field names and values and then stores it in a form of a log or a batch input program
To access the Batch Input Recorder complete the following steps:
In transaction SM35 hit the ‘Recording’ button.
Enter the recording name and click the ‘Create’ button.
In the dialog box that appears enter the transaction name for the first transaction to be recorded and click ‘Enter’. Once you complete the first transaction you will be asked whether you want to record another one.
You will then proceed with entering the necessary data for the transaction you are working on.
Remember that the data you are entering will be entered in the database if you click 'Save' button in the end. To avoid saving data click the green arrow button once you are done entering all fields in the transaction.
At this point, if you would like to add another transaction, you would click the ‘Next Transaction’ button. You will be taken to the screen where you can enter the name of the second transaction you want to record. If you are done just click the the ‘Save’ button. Important: if you exit the screen without clicking the ‘Save’ button you will lose all the data you have recorded. Then click the ‘Exit’ or ‘Back’ buttons to go back to the initial recording screen.
Right now you are back in the initial recording screen. The name of your recording should automatically appear in the ‘Recording’ box. Click the ‘Overview’ button to work with your recording.
Module Review

4-abap development tools

Documents