Abap slides set1

  • 1,471 views
Uploaded on

 

More in: Technology
  • Full Name Full Name Comment goes here.
    Are you sure you want to
    Your message goes here
    Be the first to comment
No Downloads

Views

Total Views
1,471
On Slideshare
0
From Embeds
0
Number of Embeds
0

Actions

Shares
Downloads
117
Comments
0
Likes
1

Embeds 0

No embeds

Report content

Flagged as inappropriate Flag as inappropriate
Flag as inappropriate

Select your reason for flagging this presentation as inappropriate.

Cancel
    No notes for slide

Transcript

  • 1. ABAP Workshop 2009 - Part1
  • 2. Topics• Program Types• Dialog Program and DYNPROs• Program Flow and Flow Events• DYNPRO data elements Vs. ABAP data elements• FIELD Command and Conditional Module Calls• CHAIN Command• TAB controls• Field, Data Element and Domains• Input Help (List of Values) –demo/coding• Field Help (F1 Help) –demo/coding• Understanding Menu Bar, Application Toolbar and Function keys• Menu Control and Function Keys• Context Menu• Title Bar• Demo• Hands-on Practice 2
  • 3. Program Types Program type First statement in Processing blocks Can this have or program (After the supported support its own include statements are DYNPROS resolved)Executable (1) REPORT (or All - except function Yes PROGRAM) modulesClass pool (K) CLASS-POOL Methods only NoFunction group (or FUNCTION-POOL All except event Yesfunction pool) (F) blocks for reporting eventsInterface pool (J) INTERFACE-POOL None NoModule pool (M) PROGRAM Event block LOAD-OF- Yes PROGRAM, subroutines, methodsSubroutine pool (S) PROGRAM Event block LOAD-OF- No PROGRAM, subroutines, methodsType group or Type TYPE-POOL None Nopool (T)Includes (I) N/A All except event blocks No 3 for reporting events
  • 4. Dialog Programs and DYNPRO• DYNPRO is a basic component (screen and flow logic) of Dialog programs• DYNPRO (DYNamic PROgram’s) are also called Transactions• Sometimes the terms DYNPRO and Dialog Program are used interchangingly• The procedure for creating dialog programs is different to that for reports• A Dialog Program consists of one or more screens• Screen consists of a Layout (buttons, frames, labels, edit fields etc) and its Flow Logic – code to handle user events• Collectively, a screen, its layout and flow logic is called a DYNPRO• When a dialog program is run, screens are the objects called, not programs or subroutines• In Dialog programs the system displays a screen for the user to enter or request information and it responds to user input or request by 1) Branching to next screen 2) Displaying an output 3) Running a report 4) Updating the database 4
  • 5. Passing Control Between Layers• Database Layer 5
  • 6. Explain Dialog Programming• In Dialog programming, control of the program is continually passed backwards and forwards between the presentation layer (SAP GUI) and application layer (application Server)• When we start the screen is ready for input (presentation layer is active and application layer is not active)• Once the user has entered data on the screen, program control passes back to the application layer• Now, the presentation layer is inactive (the SAP GUI is still visible, but it cannot accept user input)• The SAP GUI does not become active again until the application program has called a new screen and sent it to the presentation server.• Basically, in Dialog programming we divide programs into dialog steps, with each of these steps comprising of the programming logic between two successive screens. 6
  • 7. Flow Events• PROCESS BEFORE OUTPUT (PBO) – Fires before a screen is displayed. Can be used to initialize fields• PROCESS AFTER INPUT (PAI) – Fires on an user action (menu/buttons/function-keys)• PROCESS ON VALUE REQUEST (POV) – Fires when a set of possible values is requested (F4)• PROCESS ON HELP REQUEST (POH) – Fires when general help is requested (F1) 7
  • 8. Program Flow 8
  • 9. Dialog Processor• Dialog processor controls the display of the screen and execution of the ABAP program. The Dialog processor processes screen after the screen, thereby triggering the appropriate flow events of each screen• After each screen is displayed, it waits for the appropriate user input and then executes the flow logic• The controls passes from screen flow logic to ABAP code and back along with the values of the program elements 9
  • 10. Program Flow Design 10
  • 11. Dynpro (screen) Logic 11
  • 12. ABAP code (include file) 12
  • 13. Function Definition 13
  • 14. Dynpro data elements Vs. ABAP data elements and Data Transport 14
  • 15. FIELD Command and Conditional Module Calls• FIELD NAME – Value Transported• FIELD NAME MODULE ChangesDetectModule on REQUEST. – Value changed• FIELD NAME MODULE ChangesDetectModule on INPUT. – Non blank value• FIELD NAME MODULE ChangesDetectModule. – Custom check for format, etc 15
  • 16. CHAIN CommandCHAIN FIELD: Name1, Name2 MODULE ChangesDetectModule on CHAIN-REQUEST. "Value changed?ENDCHAIN. 16
  • 17. TAB controls1) Scrolling at application server Only one subscreen area with two subscreens. (see program 5)2) Scrolling at Local SAPGUI Two subscreens areas/Two subscreens. (see program 5A) 17
  • 18. Data Element & Domains of Fields • Domain depicts the technical attributes of a Domain field – its data type, field length, no. of decimal places, appearance on the screen • Data Element denotes the semantic attributes – short description, label names for a field thatData Element Data Element uses this. • Data Elements are directly attached to the Fields • Data Element has an underlying Domain (optional) Field Field • Domains are not directly attached to the fields • A single Domain can be under many Data Elements. • Within Domain - value range of a field can be described. Whereas within the Data Element parameter id and search help for a particular field can be assigned. 18
  • 19. Input Help (List of Values)1) Fixed Value (DOMAIN LEVEL) - Hard coded list in Data Dictionary – Using domain (of the Data Element) of the field2) Check Tables (FIELD LEVEL) – Specifying the Check table on the Field level3) Assigning the "Search Help" repository object (DATA ELEMENT LEVEL) – Create a "Search Help" Object [as an independent step] and then assign it to data element of the field.4) Assigning the "Search Help" repository object (SCREEN ELEMENT LEVEL) – Create a "Search Help" Object [as an independent step] and then assign it to dynpro screen element in screen painter.5) Self defined Dropdown List Boxes (SCREEN ELEMENT LEVEL) – Most flexible but requires simple SQL to populate the list. 19
  • 20. (1) Fixed Value (Domain Level) Domain of the Data ElementData Element of a Field 20
  • 21. (2) Check Tables (Field Level) Click on the Foreign Keys Icon 21
  • 22. (3 & 4) Search Help (Object) Create ‘Srch Helps’ Object(s) And attach to the Data Element Or attach directly to the Dynpro fieldLPos:Field OrderSPos:Search Order 22
  • 23. Search Help Field OrderLPos: Field OrderSPos: Search Order 23
  • 24. (5) Self defined Dropdown MODULE create_dropdown_box INPUT. dynpro_utilities1=>value_help( ). ENDMODULE.… DATA city_list TYPE STANDARD TABLE OF city_line. SELECT distinct ZCITY ZCITYDESCR from ZCITY_TBL into corresponding fields of table city_list where ZCITY like %O% order by ZCITY. Select Listbox CALL FUNCTION F4IF_INT_TABLE_VALUE_REQUEST or EXPORTING retfield = ZCITY Listbox value_org = S TABLES with key value_tab = city_list EXCEPTIONS … 24
  • 25. Field Help (F1 Help)1) Documentation - (only one) can be attached to the Data Element of the Field needing help documentation.2) Additional Documentation - (multiple can be attached to the Data Element of the Field needing help ‘additional documentation’), Dynpro screen field can call just one - the one relevant to its context using ‘PROCESS ON HELP- REQUEST’ Flow Logic.• PROCESS ON HELP-REQUEST. (assuming 0001 and 0002 are ‘additional documentation’ help is entered/exists) – FIELD ZBC400_S_HDR_CURR-CITYTO WITH 0001. » Or – FIELD ZBC400_S_HDR_CURR-CITYTO WITH 0002. etc3) Uses the Process on Help Request (POH) event. 25
  • 26. Field Help - Documentation Click here in Change Mode to modify (display mode shown) Data Element 26
  • 27. Field Help - Additional DocumentationData Element Click here. Add as many as you wish Call any one Additional help PROCESS ON HELP-REQUEST. FIELD field1 WITH 0001. Or FIELD field1 WITH 0002. 27
  • 28. Menu Control• Create GUI Status object (Interface Component)• Command: SET PF-STATUS ZTEST1.• Each screen can have same or different menu (set this in PROCESS BEFORE OUTPUT)• Various menus are: Menu Bar, Standard Tool Bar, Application Toolbar• Function Keys are generally related to Menu• Context Menu is inherited from Function Keys,so is same for all fields on screen by default, but…• Context Menu – each field can be made different(program 10 and 10A) 28
  • 29. Bars in the SAP GUI Menu Bar Standard Tool Bar Title Bar Related ItemApplication Toolbar Function Keys F1, F2… 29
  • 30. Menu Painter 30
  • 31. Menu Painter Screen 1/2• Screen 2/2GUI Status -> ZTEST1Note: Standard tool bar isshown at the top of theFunction Keys Setup! 31
  • 32. Function KeysThe following Function Keys are reserved and are handled at run time • F1 (field help), • F4 (Input Help) • F10 (positions the cursor in the (top) menu bar)Double Click automatically gets the functionality of whatever F2 is setup to do – applies to all fields by default. (see subsequent slides)F2 or Double Click can be setup so that different logic can be mapped to individual fields (see program 10C & subsequent slides) 32
  • 33. Double Click (all fields)• When we map a/any functionality to F2, the same functionality is automatically executed when we Double Click the object.• Example: If we set the F2 to say “BACK1” (also the Function code), the F2 as well as the Double Click get the functionality from the usual ABAP CASE statement logic. …. CASE ok_code. When BACK or BACK1. SET SCREEN 100. …. 33
  • 34. Double Click (individual fields)• The Function Code for F2 is set to CS (CURSOR- SELECTION) and TYPE to S (System Function). In PAI use the FIELD statement to call a module.• … PROCESS AFTER INPUT. FIELD Field1 MODULE C1 AT CURSOR-SELECTION. FIELD Field2 MODULE C2 AT CURSOR-SELECTION. Actual module defn: MODULE C1 INPUT. CALL TRANSACTION SE13. ENDMODULE. 34
  • 35. Context MenuThe Context Menu for a SCREEN is ‘automatically’ defaulted from the ‘function keys’ MENU setup done using menu designer – i.e., GUI STATUSThe Context Menu for individual fields is done using the ON_CTMENU_ field as explained in the subsequent slide. 35
  • 36. Context Menu (of field)Using the ON_CTMENU_ field of screen ElementsFORM on_ctmenu_my_input2 USING l_menu TYPE REF TO cl_ctmenu.CALL METHOD l_menu->add_function EXPORTING fcode = MY_CONTEXT_MENU7’ text = My Context Menu 7.…CASE save_ok.… WHEN MY_CONTEXT_MENU7. CALL TRANSACTION SE92.…ENDCASE. 36
  • 37. Title Bar• THE GUI TITLE is Interface Component• SET TITLEBAR title. >> Command Create Here Use/Call Here 37
  • 38. Upcoming Topics• Character Sets/Unicode Format [UTF-8,etc]• Data Clusters• File Access• Authorization Checks• Lock Concept and Enqueue 38