SAP Landscape a Overview

Landscape is like a server system or like a layout of the servers or some may even call it the architecture of the servers viz. SAP is divided into three different landscape DEV, QAS and PROD.DEV would have multiple clients for ex: 190- Sandbox, 100- Golden, 180- Unit Test.QAS may again have multiple clients for ex: 300- Integration Test, 700 to 710 Training.PROD may have something like a 200 Production.These names and numbers are the implementers discreet on how they want it or they have been using in their previous implementations or how is the client's business scenario.Now whatever you do in the Sandbox doesn't affect the other servers or clients. Whenever you think you are satisfied with your configuration and you think you can use it moving forward, you RE-DO it in the golden client (remember, this is a very neat and clean client and you cannot use it for rough usage).

As you re-do everything that you had thought was important and usable, you get a transport request pop up upon saving every time. You save it under a transport request and give your description to it. Thus the configuration is transported to the Unit Test client (180 in this example).

You don't run any transaction or even use the SAP Easy Access screen on the 100 (golden) client. This is a configuration only client. Now upon a successful tranport by the Basis guy, you have all the configuration in the Testing client, just as it is in the Golden client. The configuration remains in sync between these two clients.

But in the Testing client you can not even access SPRO (Display IMG) screen. It's a transaction only client where you perform the unit test. Upon a satisfactory unit test, you move the good configuration to the next SERVER (DEV).

The incorrect or unsatisfactory configuration is corrected in Golden (may again as well be practiced in the sandbox prior to Golden) and accordingly transported back to 180 (Unit Test) until the unit test affected by that particular config is satisfactory.

The Golden client remains the 'database' (if you wanna call it that) or you may rather call it the 'ultimate' reference client for all the good, complete and final configuration that is being used in the implementation.

In summary:

Landscape : is the arrangement for the servers

IDES : is purely for education purpose and is NOT INCLUDED in the landscape.


DEVELOPMENT : is where the the consultants do the customization as per the company's requirement.

QUALITY : is where the core team members and other members test the customization.

PRODUCTION : is where the live data of the company is recorded.

A request will flow from Dev->Qual->Prod and not backwards.

1. Sandbox server:

In the initial stages of any implementation project, You are given
a sandbox server where you do all the configuration/customization as per the companies business process.

2. Development Server:

Once the BBP gets signed off, the configuration is done is development server and saved in workbench requests, to be transported to Production server.

3. Production Server:

This is the last/ most refined client where the user will work after project GO LIVE. Any changes/ new development is done is development client and the request is transported to production.

These three are landscape of any Company. They organized their office in these three way. Developer develop their program in Development server and then transport it to test server. In testing server tester check/test the program and then transport it to Production Server. Later it will deploy to client from production server.

Presentation Server- Where SAP GUI have.
Application Server - Where SAP Installed.
Database Server - Where Database installed.

What is the meaning of "R" in R/3 systems?

R/3 stands for real time three tier architecture. This is the kind of architecture SAP R/3 system has.

R/3 means three layers are installed in Different system/server and they are connected with each other.

3)Data base server.



CRM Activity Administration in SAPSAP CRM Partner Processing
SAP CRM Pricing
SAP CRM Actions

Program Interface in SAP ABAP Lesson Thirty Six

A GUI status is made up of a menu bar, a standard toolbar, an application toolbar, and of function key settings. Each screen can have one or more GUI statuses. For example, an editor program might have two statuses - one for display mode and one for change mode.The elements of a GUI status allow users to choose functions using the mouse.Menus are control elements that allow the user to choose which functions will be processed by an application program. Menus can also contain sub menus. The 'System' and 'Help' menus are present on every screen in the R/3 System. They always have identical functions and cannot be changed or hidden.

The application toolbar contains icons for frequently-used functions. The standard toolbar, which is the same on every screen in the R/3 System, contains a set of icons, each of which has a fixed assignment to a corresponding function key. If a function in the standard toolbar is not available on the current screen, the icon is grayed out.

The application toolbar allows the user to choose frequently-used functions by clicking the corresponding push button.You use the function key settings to assign functions such as Find, Replace, or Cut to the function keys.All of a program's GUI titles and statuses taken together make up its user interface. Whenever you change or add a new title or status, you must regenerate the user interface.

There are three ways to create a title: from the object list in the Object Navigator, from the Menu Painter, or by forward navigation from the ABAP Editor.The name of a title can be up to 20 characters long.You should set an appropriate title for each screen in your application.You can use variables in titles that are set dynamically at run time by including the ampersand character (&) as a placeholder. At runtime, the ampersand is replaced by a value that you specify.

You can use up to nine variables by placing digits after the ampersand.
To set a title that contains variables, use the statement:
SET TITLEBAR WITH <&1> ... <&10>.

A title bar remains in place until you set another one. At run time, the system variable sy-title contains the current title. Title bars are also known as GUI titles.From a technical point of view, a status is a reference to a menu bar, to certain key assignments and to an application toolbar.A single component (such as a menu bar) can be used by more than one GUI status.

  1. GUI statuses are ABAP program objects that can be displayed on screens and lists.
  2. You should set a status for every screen in your application.
  3. A status is a reference to a menu bar, a key setting, and an application toolbar.
  4. A menu bar is made up of individual menus.
  5. Key assignments and application tool bars are sub-objects of the function key settings.
  6. You can create a set of application tool bars for a single key setting.

In order to include a function in an application toolbar, the function must be assigned to a function key. Each status contains a single application toolbar.All program menus and key assignments refer to a particular function list. This list can be reached using F4 help. Application toolbars refer to the function list indirectly by way of the key assignment.A function within a status can be either active or inactive. Inactive functions are not displayed in the application toolbar.

Functions are identified by their function codes.The attribute function type determines the intended purpose of a function. You can use the function types ' ' (space), 'E', and 'P' for push buttons that you place on a screen using the Screen Painter, and for tab titles. Function types 'S and 'H' are reserved for internal use by SAP. Function type 'T' indicates a transaction code. When the user chooses a function with this type, the system leaves the current program (without performing any checks) and calls the new transaction.

Functions can be created with static texts or dynamic texts.If a function has a static text, you can assign an icon to it (Icon name attribute). If the function is already assigned to a pushbutton, an icon is displayed instead of the static text. The static text is used when you assign the function to a menu entry. The function text belonging to the function is used as "quick info". The contents of the Infotext attribute appear in the status bar of the screen when the user chooses the function. If you want to display text as well as the icon, enter the text in the Icon text attribute.

The Fast path attribute allows you to define a letter code, which users can enter to choose the function without using the mouse.Functions can be assigned to individual function keys or push buttons.Function key settings consist of a key assignment and an application toolbar push button.A function key assignment's type (possible values: screen or dialog box) only serves to define the technical use of the key assignment.

Key assignments consist of Reserved Functions Keys, Recommended Functions Keys and Freely Assigned Function Keys. Reserved Functions Keys are function keys whose assigned values cannot be changed in the SAP system. You may activate and deactivate their functions, however, the icons and texts assigned to them cannot be changed. Activated Reserved Functions Keys appear in the standard toolbars of both screens and lists.

Recommended Functions Keys are assigned suggested values that satisfy SAP usability (ergonomic) norms.Functions that have been assigned to function keys can also be assigned to pushbuttons in the application toolbar.

  1. An application toolbar can contain up to 35 push uttons.
  2. A menu can contain up to 15 entries.
  3. Possible entries are functions, separators, and menus (cascading menus).
  4. Menus can be up to three levels deep. The third level may only contain functions and separators.
  5. Menus can be created with static or dynamic text. You must assign a field name to menus with dynamic text, whose contents will be displayed as the menu text at run time.
The menu type Include menu allows you to reference menus in other programs. When you do this, you must specify the name of the program and status from which you want to include the menu next to the Short documentation field.Include menus can only be accessed using the menu bar.A menu bar can contain up to eight different menus. Up to six of these can be freely assigned. The system automatically adds both the System menu and the Help menu to every menu bar.

There are three ways to create a title: from the object list in the Object Navigator, from the Menu Painter, or by forward navigation from the ABAP Editor.

The status type indicates the technical attributes of the status. You can choose between a dialog status (status for full screen), or a dialog box status (for use with modal dialog boxes). Context menus are special collections of functions that can be displayed when the user clicks the right-hand mouse button. We will deal with them separately in the Context Menus unit.

You can create your own statuses by initially generating new settings, using existing ones (reference technique), or by combining both of these procedures. If you want to create an entirely new status, you must then create your own menu bars, menu functions, and other elements. Changes to a status only affect that status.

When you use the reference technique, you create menu bars, application tool bars, and function key assignments as independent elements. You then create your own status and refer to the menu bar, application toolbar, and any function key assignment you want. The Menu Painter stores and maintains these references so that any changes in the menu bar, application toolbar or function key assignments automatically take effect in all statuses referring to them.

The linking technique is particularly effective for ensuring consistency in very large applications that use several statuses. The links ensure that the user can access functions in the same way whatever status is set.In a key setting, you assign individual functions to function keys and push buttons. Function key settings consist of a key assignment and a set of application tool bars.A function key assignment's type (possible values: Screen, Dialog box, List, List in a dialog box) determines where the key can be used.

You can attach functions to reserved function keys, recommended function keys, and freely-assigned function keys. You should observe SAP's ergonomic guidelines.If a function is important, and you have already assigned it to a function key, you can also assign it to a pushbutton in the application toolbar. The application toolbar may contain up to 35 push buttons.When you assign a function to the standard toolbar, it is also automatically assigned to a reserved function key.

To find out the function keys to which these functions are assigned in the current status, click the Information icon in the Menu Painter.For more information about how key combinations such as Ctrl-P are converted into internal function key numbers (for example, for batch input), follow menu path GUI-3 in the Menu Painter.

You can only use a function in the application toolbar if you have already assigned it to a function key.Functions in the application toolbar are identified by their function code. The Function type attribute identifies the purpose of the function. If you want to process a function in the program, use the type ' ' (space). If you assign type 'T' to a function, the current program terminates when the user chooses the function, and the system starts the transaction assigned to the function.

If you assign an icon to a function with a static text (Icon name attribute), the system displays the icon instead of the text in the application toolbar. The function text belonging to the function is used as "quick info". The contents of the attribute Info. text appear in a screen's status line whenever the event is triggered. If you want to display additional text with an icon, it should be entered in the attribute Icon text.

You can use the Fast path attribute to specify the letters that allow you to choose a function without using the mouse.To insert a separator in the application toolbar, use the Insert menu in the Menu Painter.

If you use the 'Fixed positions' attribute for the application toolbar, push buttons for inactive functions are grayed out instead of being hidden. To set this attribute, double -click the open padlock symbol next to the application toolbar description.A menu entry can be a function, a separator, or another menu (cascading menu)

To add a function to a menu, enter its function code in the left-hand column. If the function already exists in the function list and has a text assigned to it, this is entered automatically in the text field. If not, double -click the right-hand field to maintain a text.To insert a separator, use the 'Insert' menu or fill the function text field with minus signs at the appropriate position.Status and title names can be up to 20 characters in length and must be entered all in capital letters. A status stays active until a new one is set.

You can use up to nine variables in a GUI title using the syntax SET TITLEBAR title WITH f1 ..f9.

If no GUI interface has been set, a standard user interface is displayed. Use SET PF-STATUS SPACE to deactivate previously entered statuses and activate the default list status. You can deactivate functions at run time with the EXCLUDING addition. If you want to deactivate several function codes at the same time, you must first transfer these to the system using an internal table.

You should work with an interactive event and centrally control various user actions in the program, handling the actions independently of each other.You program AT USER-COMMAND as an interactive event and evaluate the system field syucomm in a CASE control structure. This field contains the current function code.Data is restored from the hide area to the corresponding global data fields for the line on which the cursor was positioned.



CRM Part One

SAP CRM Business TransactionsSAP CRM marketing Management Campaign
SAP CRM Internet sales FeaturesSAP CRM interaction center overviewSAP CRM Mobile sales and serviceRoles in SAP CRMSAP CRM Organizational Model

Basics of Interactive Reporting in ABAP Lesson Thirty Five

When the user starts an executable (type 1) program, the program context and memory space for data objects (variables and structures) are made available on the application server. The subsequent program flow is controlled by the ABAP run time system.If the program contains a selection screen, the ABAP run time system sends it to the presentation server at the start of the program.

Once the user has finished entering data on the selection screen, he or she chooses 'Execute' to tell the system to start processing the rest of the program. The data entered on the selection screen is automatically placed in the corresponding data objects. The ABAP run Time system takes over control of the program.In this simple example, there is only one ABAP processing block to be processed by the runtime system.This processing block contains a read access to the database. The program sends information to the database about the records that should be read.

The database returns the required database records and the run time system ensures that the data is placed in the relevant data objects.The list output is also programmed in the processing block. After the processing block finishes, the run time system sends the list as a screen to the presentation server.Selection screens allow users to enter ranges of values. They are normally used to define the set of data that needs to be read from the database.

As well as the normal graphical elements (group boxes, check boxes, radio buttons, and so on) that you use in screens, selection screens also have input/output fields (PARAMETERS) and special groups of input/output fields (SELECT-OPTIONS).

You place a single input/output field on the selection screen using the PARAMETERS statement.

You can use the SELECT-OPTIONS statement to place a group of fields on the screen that allows users to enter complex selections. The selection may be a single value, or any form of interval (discrete or continuous). You can also use patterns. (See following slides).

You can create variants for selection screens.If you declare an input field with reference to an ABAP Dictionary field, any search helps defined for the Dictionary field will be available on the selection screen.Selection texts can be translated into other languages. They are then displayed in the user's logon language.

Selection ranges are stored in programs using an internal table.The ABAP statement SELECT-OPTIONS FOR declares an internal table called , containing four fields - SIGN, OPTION, LOW, and HIGH. The fields LOW and HIGH have the same type as the field .

The SIGN field can take the value 'I' (for inclusive) or 'E' (for exclusive).

The OPTION field can contain relational operators, pattern operators, and operators that allow you to enter intervals.

To define a selection screen, include the required PARAMETERS and SELECT-OPTIONS statements in your data declarations. If you define more selection screens than just the standard selection screen, you must enclose the additional definitions in the statements SELECTIONSCREEN BEGIN OF SCREEN and SELECTION-SCREEN END OF SCREEN where is the number of the selection screen.

For information about other graphical elements that you can place on a sele ction screen, such as group boxes, checkboxes, radio buttons, references to input fields on other selection screens and so on, see the keyword documentation for the SELECTION-SCREEN statement

The standard selection screen is displayed by the ABAP run time system when the program starts.User-defined selection screens are displayed when you use the statement CALL SELECTIONSCREEN . This statement sets the return code sy-subrc to zero if the user chooses 'Execute', and to 4 if the user chooses 'Cancel'.

You can also call a selection screen as a modal dialog box. To do this, use the syntax CALL SELECTION-SCREEN STARTING AT ENDING AT where and are the coordinates of the top left-hand corner of the screen. and are the coordinates of the bottom right-hand corner.

Selection screen processing is event-driven. Events are ABAP processing blocks that are called by the runtime system in a particular order and processed sequentially. In the program, each event is introduced by an event keyword. The processing block ends when the next event block starts, or the definition of a subroutine or dialog module occurs.

AT SELECTION-SCREEN OUTPUT is processed before the selection screen is displayed. You can use this event to modify the selection screen dynamically.

AT SELECTION-SCREEN ON VALUE-REQUEST FOR allow you to define your own F1 and F4 help.

AT SELECTION-SCREEN is processed when the user presses ENTER or chooses another function on the selection screen. You can use this event to check the values the user entered on the screen. The addition ON... allows you to control which fields or groups of fields should accept input again in the event of an error.An ABAP program consists of a sequence of processing blocks (events) that are processed by the run time system in a particular order.

LOAD-OF-PROGRAM is triggered directly after the system has loaded a program with type 1, M, F, or S into an internal session. The processing block is executed once only for each program in each internal session.

INITIALIZATION is processed in executable (type 1) programs, directly before the selection screen is displayed. You can use the corresponding processing block to preassign values to the parameters and selection options on the selection screen.

START-OF-SELECTION is processed after the selection screen has been processed. If you are working with a logical database, the corresponding GET events are triggered after START-OFSELECTION.

END-OF-SELECTION is processed after all of the data has been read, and before the list is displayed.

TOP-OF-PAGE is an event in list-processing. The processing block is always executed when you start a new page in the list.

Once the basic list has been displayed, you can react to possible user actions. Detail lists allow you to distribute the information you want to display across several lists.This makes the lists easier for the user to understand, and improves performance, since you can delay reading extra information from the database until the user actually requests it.You can also use additional selection screens to allow the user to enter further restrictions.

For each basic list you can use up to 20 detail lists. Each list is stored in its own list buffer. When the user chooses 'Back' (green arrow) or 'Cancel' (red cross), he or she returns to the previous list.This action initializes the list buffer of the list level the user just left.When the user chooses 'Exit' (yellow arrow), the system terminates the list processing and returns to the standard selection screen.

The events START-OF-SELECTION, GET, END-OF-SELECTION, TOP-OF-PAGE and END-OFPAGE can be used only to create basic lists.

To create detail lists, use the events AT LINE-SELECTION or AT USER-COMMAND.

Use TOP-OF-PAGE DURING LINE-SELECTION for page headers on detail lists.

Each detail list event exists only once in the program and is shared by all detail lists. You must therefore ensure yourself, within the processing block, that the correct list is created. To do this, use a CASE structure that uses the system field sy-lsind. This system field contains the list index of the list that you are currently generating.Use the statement HIDE global_field to store the contents of the global data field global_field for the current line.

If the user selects the line, the data field is automatically filled with the value that you retained for the line.You do not have to display the field on the list in order to retain its value using HIDE.The field can be a structure. However, deep structures (structures containing internal tables as components) are not supported.

When the user selects a line on an interactive list, all of the global data fields whose values you stored using the HIDE statement while you were creating the basic list are filled with those values.The line selection is based on the cursor position when the AT LINE-SELECTION and AT USERCOMMAND events occur. (system field sy-lilli).

If you choose a line using the READ LINE... statement, the values are placed back in the original fields according to the line numbers.To check whether the user selected a valid line, you can use the fact that the hide area only contains data for valid lines. When you have finished creating the list, initialize a suitable test field. This allows you to check before you create the detail list whether a value from the hide area has been placed in the test field.

Once you have created the detail list, re-initialize the test field to ensure that the user cannot choose an invalid line once he or she returns from the detail list and attempts to select another line for a new detail list.



MySAP CRM System architecture and design
MySAP CRM architecture and E procurement introduction

ABAP ALV Grid Control Lesson Thirty Four

This task is performed by the SAP Control Framework.The R/3 System allows you to create custom controls using ABAP Objects. The application server is the Automation Client, which drives the custom controls (automation server) at the front end.If custom controls are to be included on the frontend, then the SAPGUI acts as a container for them.Custom controls can be ActiveX Controls or JavaBeans.The system has to use a Remote Function Call (RFC) to transfer methods for creating and using a control to the front end.ABAP objects are used to implement the controls in programs.

An SAP Container can contain other controls (for example, SAP ALV Grid Control, Tree Control, SAP Picture Control, SAP Splitter Control, and so on). It administers these controls logically in one collection and provides a physical area for the display.Every control exists in a container. Since containers are themselves controls, they can be nested within one another. The container becomes the parent of its control. SAP containers are divided into five groups:

SAP custom container: Displays within an area defined in Screen Painter on screens or sub screens.
SAP dialog box container: Displays in a modeless dialog box or as a full screen. Class:

SAP docking container: Displays as docked, resizable sub-window with the option of displaying it as a modeless dialog box. Class: CL_GUI_DOCKING_CONTAINER
SAP splitter container: Displays and groups several controls in one area - that is, splits the area into cells Class: CL_GUI_SPLITTER_CONTAINER
SAP easy splitter container: Displays controls in two cells, which the user can resize using a split bar. Class: CL_GUI_EASY_SPLITTER_CONTAINER.

In the control, you can adjust the column width by dragging, or use the 'Optimum width' function to adjust the column width to the data currently displayed. You can also change the column sequence by selecting a column and dragging it to a new position.Standard functions are available in the control toolbar. The details display displays the fields in the line on which the cursor is positioned in a modal dialog box.

The sort function in the ALV Control is available for as many columns as required. You can set complex sort criteria and sort columns in either ascending or descending order.You can use the 'Search' function to search for a string (generic search without *) within a selected area by line or column.

You can use the 'Sum' function to create totals for one or more numeric columns. You can then use the "Subtotals" function to set up control level lists: You can use the 'Subtotal' function to structure control level lists: select the columns (non-numeric columns only) that you want to use and the corresponding control level totals are displayed.For 'Print' and 'Download' the whole list is always processed, not just the sections displayed on the screen.

You can define display variants to meet your own specific requirements. For information on saving variants, see 'Advanced Techniques'.The ALV grid control is a generic tool for displaying lists in screens. The control offers standard functions such as sorting by any column, adding numeric columns, and fixed lead columns .

Data collection is performed in the program (with SELECT statements, for example) or by using a logical database. The data records are saved in an internal table and passed on to the ALV control along with a field description.

The field description contains information about the characteristics of each column, such as the column header and output length. This information can defined either globally in the Dictionary (structure in the Dictionary) or in the field catalog in the program itself. You can also merge both techniques.

The ALV link is a standard function of Query and QuickViewer. If multiline queries or Quick View lists have been defined, they will automatically be compressed to a single line and output in the ALV control as a long, single line list.

Use Screen Painter to create a sub screen container for the ALV grid control. The control requires an area where it can be displayed in the screen. You have to create a container control that determines this area.Use the corresponding icon in the Screen Painter layout to create the container control. The size of area "MY_CONTROL_AREA" determines the subsequent size of the ALV control.

The valid GUI status must be set at the PBO event in the flow logic of the ALV subscreen container.
The OK_CODE processing for the cancel functions must be programmed at the PAI event.The reference variables for the custom container and the ALV grid control must be declared.To create reference variables, use ABAP statement TYPE REF TO .

The global classes you need to do this are called cl_gui_custom_container (for the custom container control) and cl_gui_alv_grid (for the ALV grid control).The global classes are defined in the Class Builder. You can use the Class Builder to display information for the methods, their parameters, exceptions, and so on.

Use ABAP statement CREATE OBJECT to create the objects for the container and the ALV control. Objects Are instances of a class.When an object is created (CREATE), method CONSTRUCTOR of the corresponding class is executed. The parameters of method CONSTRUCTOR determine which parameters have to be supplied with data when the object is created. In the above example, object alv_grid is given the name of the container control (g_custom_container) in exporting parameter i_parent, which links the two controls. For information on which parameters method CONSTRUCTOR possesses and which of these parameters are required, see the Class Builder.

Objects should only be created once during the program. To ensure that this is the case, enclose the CREATE OBJECT statement(s) in an IF IS INITIAL. ... ENDIF clause. The objects must be generated before the control is displayed for the first time - that is, during the PBO event of the ALV sub screen container.

To display the requested data set in the ALV control, the data must be passed on to the control as an internal table, and a field description must exist indicating the order in which the columns will be output.

In the simplest case, the field description can use a structure from the Dictionary. The Dictionary also determines the technical field attributes like type and length, as well as the semantic attributes like short and long texts. The ALV control uses this information to determine the column widths and headers. The column sequence is determined by the field sequence in the structure.

If no suitable structure is active in the Dictionary, or you want to output internal program fields in the control, then you will have to define information like the output length and column header in the field catalog.

In a typical program run, the dataset is read first (SELECT ....), the internal table is filled with the data to display (... INTO TABLE ...), and ABAP statement CALL SCREEN is then used to call the ALV sub screen container.

The data transfer to the ALV control takes place during the call of method
set_table_for_first_display from class cl_gui_alv_grid. The method call must be programmed at the PBO event of the ALV subscreen container.

The name of the Dictionary structure that supplies the field description is specified in exporting parameter i_structure_name. The name of the internal table that contains the data records to display is specified in changing parameter it_outtab.

The field description for the ALV control can be ta ken from an active Dictionary structure (fully automatic), by passing a field catalog (manual), or through a mixture of the two options (merge).

The field catalog is in internal table with type lvc_t_fcat. This type is defined globally in the Dictionary.Each line in the field catalog table corresponds to a column in the ALV control.

The field characteristics (= column characteristics) are defined in the field catalog. The field catalog is in internal table with type lvc_t_fcat. Each line that is explicitly described in the ALV control corresponds to a column in the field catalog table.

The link to the data records to output that are saved in internal table is established through field name . This name must be specified in column "fieldname" in the field catalog.This field can be classified through a Dictionary reference (ref_table and ref_field) or by specifying an ABAP data type (inttype).

Column headers and field names in the detail view of an ALV control line can be determined in the field catalog in coltext and seltext, respectively.The position of a field during output can be determined with col_pos in the field catalog.If you want to hide a column, fill field no_out with an "X" in the field catalog. Hidden fields can be displayed again in a user display variant.

Icons can be displayed in the ALV control. If you want a column to be interpreted as an icon, then the icon name must be known to the program (include .) and icon = "X" must be specified for this column in the field catalog.

The above example shows a semi-automatic field description: Part of the field description comes from the Dictionary structure (sflight), while another part is explicitly defined in the field catalog (gt_fieldcat).The field catalog (internal table) is filled in the program and is passed on together with the name of the Dictionary structure during the method call. The information is merged accordingly in method set_table_for_first_display.

For a user to save display variants, parameters is_variant and i_save must be passed on during method call set_table_for_first_screen. To assign display variants uniquely to a program, at least the program name must be supplied in the transferred structure (gs_variant).

Program names can be up to 30 characters long.If you only pass on the current parameters for is_variant, then existing variants can be loaded, but no new ones can be saved. If you use parameter i_save, you must pass on a variant structure with is_variant.

I_SAVE = SPACE No variants can be saved.
I_SAVE = 'U' The user can only save user-specific variants.
I_SAVE = 'X' The user can only save general (shared) variants.
I_SAVE = 'A' The user can save both user-specific and general (shared) variants.

You can use parameter is_layout of method set_table_for_first_display, for example, to define the header in the ALV control and the detail display.To do this, define a query area in the program in accordance with Dictionary structure lvc_s_layo, and pass on the text to display in field -grid_title or -detailtitl.

If you want to create print lists with zebra stripes, set field -zebra to "X". You can display a print preview for print lists by requesting standard function "Print".All parameters of method SET_TABLE_FOR_FIRST_DISPLAY from global class CL_GUI_ALV_GRID are defined in the Class Builder.

Events are defined in global class cl_gui_alv_grid; you can use these events to implement user interaction within the program. To respond to a double -click on a table line, you must respond to event DOUBLE_CLICK.

You receive control in the program, allowing you to implement interactive reporting - such as a full screen details list. The events for cl_gui_alv_grid are located in the Class Builder.To define an implement a local class in the program, you use a handler method. In this handler method, you program the functionality to trigger by a double -click in the output table.

To activate a handler method at runtime, a class or an object from that class registers itself with an event using command SET HANDLER. The names of the IMPORTING parameters in the handler method correspond to the names of the EXPORTING parameters of the related event.

In the above example, the local class is LCL_ILS and the handler method is ON_DBLCLICK. An object - ALV_DBLCLICK - is created and registers itself for event DOUBLE_CLICK.

You can query parameter e_row-index to determine which output line was requested by the double -click. This parameter corresponds to the line number of the output table (internal table with the data records to output). If you need information for the selected line, you have to read it with READ TABLE itab INDEX e_row-index.

This subsequent read in the output table generally corresponds to the HIDE area in conventional reporting. You first have to make sure that the user has double -clicked a line in the output table (similar to the valid line selection with the HIDE technique).A field group can contain global data objects, but not data objects that have been defined locally in a subroutine or function module.

You can use INSERT to specify both fields and field symbols. This makes it possible to dynamically insert a data object referred to by a field symbol into a field group at runtime. Any field symbols that have not been assigned are ignored, which means no new field is inserted into the field group.The EXTRACT statement writes all the fields of a field group as one record to a sequential dataset (transport takes place with similarly named fields). If a HEADER field group is defined, then its fields are placed ahead of each record as sort keys. You can then sort the dataset with SORT and process it with LOOP ...ENDLOOP. In this case, no further EXTRACT is possible.

The INSERT statement is not a declarative statement: This means field groups can also be expanded in the program flow section.As soon as the first dataset of a field group has been extracted with EXTRACT, that field group can no longer be expanded with INSERT. In particular, the HEADER field group cannot be expanded after the first EXTRACT (regardless of the field group).

When the GET events are processed, the logical database automatically writes hexadecimal zeros in all the fields of a node when it returns to an upper-level node in the hierarchy. Since the HEADER normally contains sort fields for all field groups, these hexadecimal zeros in the HEADER serve as a type of hierarchy key: The more zeros there are, the further up in the control level hierarchy you go.
The SORT statement sorts the extract dataset in accordance with the defined field sequence in field group HEADER. The addition BY ... sets a new sort key.

Each must be either a field of field group HEADER or a field group that consists only of fields of the field group HEADER. You can use the additions ASCENDING and DESCENDING to determine whether the fields are sorted in ascending (default) or descending order.Fields containing X'00' in the logical databases are always displayed before all other values during a SORT.Processing of an extract dataset always takes places within a LOOP. The contents of the extract dataset field are placed in program fields with the same names.

The group change always involves the fields of the HEADER. Single record processing for extract datasets is performed using language element AT ( = field group).CNT() is not a statement, but instead a field that is automatically create d and filled when is a non-numeric field from field group HEADER and is part of the sort key. At the end of the group, CNT() contains the number of different values that the field recorded in this group level.SUM() is not a statement, but instead a field that is automatically created and filled when is a numeric field of an extract dataset. At the end of the group, SUM() contains the control total of field .

CUM and CNT are only available at the end of the group level or at AT LAST.

Single record processing for extract data sets AT WITH is only performed when field group is immediately followed by field group in the temporary data set.Loops over an extract dataset cannot be nested. However, several contiguous loops are permitted.The sequence of the control level changes within the LOOP must correspond to the sort sequence.

Totals can only be calculated within control footer processing.Extracts allow only appends (EXTRACT), sorting (SORT) and sequential processing (LOOP).Once a SORT or LOOP has occurred, the intermediate dataset is frozen and cannot be expanded with EXTRACT. Operations that insert into or delete from EXTRACT datasets are not supported.

Extracts allow for several record types (FIELD-GROUPS) with fields that can be set dynamically (INSERT is not a declarative statement!). Internal tables have a single, statically-defined line type. control leve l. The control level structure for internal tables is therefore static, and is independent of which criteria were used to sort the internal table.

Extracts do not depend on the field sequence for control level processing: a re-sort or a completely different control level process can take place. The control level structure for extract data sets is therefore dynamic. It corresponds exactly to the sort key of the extract data set. The sort key is the sequence of fields from the field group HEADER, and is used to sort the extract data set.

Extracts rely on the compiler to determine which combinations of group levels and a accumulating field the control level totals desire. The desired control level totals are determined by the processing of LOOP ... ENDLOOP blocks. Internal tables build the control level total with the SUM statement.This procedure leads to high resource depletion for totaling control levels in internal tables.



MySAP CRM and customer relationship management
My SAP CRM , Business Scenarios and SAP Solutions

Saving Lists and Back Ground Processing Lesson Thirty Three

There are three ways to save a list that you have generated:

1.) In SAP office
2.) As a local file on your PC
3.) In the area menu

You can always use menu sequence STL-1 in the System menu to save the list, or use the List menu in the standard list status.You can also create folders in SAP office. You can use these folders to store the lists. When a list is placed in the outbox of the personal folders, it can also be sent to other users.You can save a list to a PC as a local file in four different formats:

1.) Unconverted (ASCII)
2.) Spreadsheet format (-> Microsoft Excel)
3.) RTF (Rich Text Format -> Microsoft Word)
4.) HTML (Web Browser)

You can use the program RSSOPCDR to specify the default file that the system proposes when the user chooses to save a file to the local PC.

The area menus have been converted to tree navigation in Release 4.6A. Type 1 programs and SAP queries can now be added to the area menus in addition to the previously contained transactions. Any programs that do not have a transaction code are allocated one automatically.

The report trees have been integrated in the area menus in Release 4.6. The report trees are now maintained using the maintenance tools for area menus. You can maintain area menus in the Workbench menu path STL-1.

Saved lists are saved with the program itself. If the program has been integrated in the area menu, then the saved lists will also appear there. You can also use standard program RSRSSLIS to display saved lists.

A user can access an area menu whenever that area menu has been allocated to an activity group to which the user belongs. You can use the profile generator to allocate an area menu to an activity group.

There are 4 options for printing a list:

1) From the selection screen

The list is printed when it is generated (adjusted to print format) and does not appear on the screen.

The list is generated in a dialog work process

2) From within the program

The first two points of 1, above
This procedure is suitable for interactive lists: printing details lists

3) After the list has been generated
The list has already been generated (visible on the screen) and can be formatted within limits.

For example, the number of columns in the list cannot be changed after the list is generated.

The list is generated in a dialog work process

4) In the background

The list can be printed after it has been generated (as described in 1 above)
The list is generated in a background work process. This procedure is particularly suitable for long lists, since it does not block a dialog work process during processing.

To print a list, you must enter print parameters. The print parameters control list output and are divided into the following areas:

1) Output device and number of copies
2) Spool request
3) Spool control
4) Cover sheets
5) Output format

You can enter print parameters on the screen or set them directly in the program. Setting print parameters in the program is treated below (NEW-PAGE PRINT ON).You can use the function module SET_PRINT_PARAMETERS to set default values for printing an online list; you can execute print from the selection screen or after generation of the list.

NEW-PAGE PRINT ON triggers a page break, and all the subsequent output is redirected to the spool.The print parameters can either be passed on to the system as a structure with the PARAMETERS attribute or - as shown in the above example - specified individually.

Individual entry of print parameters is not recommended. Consider the case where the user arrives at the print parameter screen and decides not to print; the only option in this case would be to terminate the entire program.In contrast, if you use the PARAMETERS attribute, the user can cancel printing without having to terminate the program.

If you enter parameter NO DIALOG, the list is placed directly in the spool without giving the user any opportunity to change the print parameters at run time.If you do not enter NO DIALOG, the user is presented with a print parameters screen containing default values at runtime.NEW-PAGE PRINT OFF triggers a page break, ends the spool request (sy-spono is assigned), and all subsequent output is once again output on the screen.

The structure for the PARAMETERS attribute of the NEW-PAGE PRINT ON statement must be filled using function module GET_PRINT_PARAMETERS. The structure contains an internal checksum that is calculated by NEW-PAGE PRINT ON. If the checksum is incorrect, the program terminates. Function module GET_PRINT_PARAMETERS calculates the checksum and returns it with out_parameters.

Function module GET_PRINT_PARAMETERS provides users with a print parameters screen that can be used to modify the print parameters and then determine a complete new set of print parameters. The set is returned using output parameter out_parameters. In successful cases, output parameter "valid" contains the value 'X'. If the system cannot create a complete set record of print parameters, the structure transferred with out_parameters is empty and valid contains the value "space".

You can transfer print parameters to the function module GET_PRINT_PARAMETERS. The print parameters appear as default values in the print parameters screen.The print parameters screen of function module GET_PRINT_PARAMETERS offers the option of canceling the filling of print parameters. In this case, the structure transferred with out_parameters is empty and valid contains the value "space".

One application could be to send a list to several recipients.This has been implemented in the above example. To send a list to several recipients, you have to distribute it among several spool requests. To do this, you use parameter NEW_LIST_ID and then NEW-PAGE PRINT OFF to end the spool request.

When a program converts large data sets and requires a long run time, it makes sense to start it in the background.Background runs take place without user dialogs, and can take place in parallel to online operations.The dialog work processes are available for online processing. Background job runs are performed by special work processes (background processes), which enables distributed processing.

To start a program in the background, you must first add it to a job.Use the job definition to determine which programs (steps) will run during this job. You can specify print parameters and set the start time for the job.

The job overview tells you the current status of the job.Define job is located under menu path STL-2. First assign a name (of your choice) and define the priority (job class) and the destination (F4 help).

Then determine the individual steps of the job. If you want the program to run with a selection screen, you also have to specify a variant. The list can be stored in the spool or printed immediately.This depends on the specified print parameters. When you have defined all the steps, save them and return to the initial screen of the job definition.Once you have defined the steps, you can determine the start date for the job. For example, you can start the job on a certain day at a certain time.

Once you have defined the start date, save your entries and return to the initial screen of the job definition. Now save the job, which releases it to run at the specified time.



Customer Relationship Management and mysap an introduction
CRM Management and sales and service strategy of mysap crm
MySAP CRM and customer as business partner

Data Formatting and Control Level Processing Lesson Thirty Two

You can use control level processing to create structured lists. Control levels are determined by the contents of the fields that are to be displayed. there is a control level change whenever the content of a field changes. This means that there is no point in creating control levels unless the data are sorted.The data to be displayed must be saved temporarily if you want to use control level processing. You can also use internal tables and intermediate data sets.You can use an array fetch in a SELECT statement to fill an internal table in one go.

You can use the APPEND statement to insert table entries at the end of an internal table. The variant of the APPEND statement on the slide is permitted only for standard or sorted tables. After an APPEND statement, system field SY-TABIX contains the index value of the newly inserted table entry.

You use the COLLECT statement to generate unique or compressed data sets. The contents of the work area of the internal table are recorded as a new entry at the end of the table or are added to an existing entry. The latter occurs when the internal table already contains an entry with the same key field values as those currently in the work area. The numeric fields that do not belong to the key are added to the corresponding fields of the existing entry.When the COLLECT statement is used, all the fields that are not part of the key must be numeric.The SORT statement sorts the entries in internal table in ascending order. If the addition BY ..., is missing, then the key assigned when the table was defined is used.

If addition BY ... is used, then fields , , ... are used as sort keys. The fields can be of any type.

You can use the additions ASCENDING and DESCENDING with the SORT statement to determine whether the fields are sorted in ascending (default) or descending order.

You can use the loop statement LOOP AT ... ENDLOOP to process an internal table. The data records in the internal table are processed sequentially.The CONTINUE statement can be used to prematurely exit the current loop pass and skip to the next pass.The EXIT statement can be used to exit loop processing.

At the end of loop processing (after ENDLOOP), return value sy-subrc indicates whether the loop was passed or not.

SY-SUBRC = 0: The loop was passed at least once
SY-SUBRC = 4: The loop was not passed because no entry was available.

You can use special control structures for control level processing. All the structures begin with AT and end with ENDAT. These control structures can only be used within a LOOP.The statement blocks AT FIRST and AT LAST are run exactly once: at the first AT FIRST and at the last AT LAST loop.The statements within AT NEW ... ENDAT are executed when the value of field changes within the current LOOP (start of a control level) or the value of one of the fields in the table definition (further to the left).

The statements within AT END OF ... ENDAT are executed when the value of field changes during the next LOOP (end of a control level) or the value of one of the fields in the table definition (further to the left).At entry of the control level (directly after AT), - all fields with the same character types after (to the right of) the current control level key are filled with "*" - all other fields after (to the right of) the current control level key are set to default values.

When a control structure is exited (at ENDAT), all fields of the query area are filled with the data from the current loop pass.The SUM statement supplies the respective group totals in the query area of the LOOP in all fields of TYPE I, F and P.

The control level structure in internal tables is static. It corresponds exactly to the sequence of columns in the internal table (from left to right). In particular, the control level structure for internal tables is independent of the criteria used to sort the internal table. The table must be sorted according to the internal table fields.

When you implement control level processing, you must follow the sequence of individual control levels within the LOOP as illustrated in the slide. The sequence follows the sequence of fields in the internal table and is therefore also the sort sequence.

The processing block between AT FIRST and ENDAT is executed before processing of the single lines begins. The processing block AT LAST and ENDAT is executed after all single lines have been processed.


SAP Financial Payment Cards