creating dialog (abap dynpro ) programs

Download Creating Dialog (ABAP  Dynpro ) Programs

Post on 14-Feb-2016




5 download

Embed Size (px)


Creating Dialog (ABAP Dynpro ) Programs. Types of ABAP Programs (1). A program’s technical attributes and capabilities are determined by its type Type 1 programs are executable programs They do not need to be controlled by screens Type 1 programs are often called reports - PowerPoint PPT Presentation



Creating Dialog (ABAP Dynpro) ProgramsSlide #IntroductionAll of the ERP systems operate similarly with regard to transactional integrityThey all operate on the notion of a Unit of Work (UOW)They all have similar commit / rollback scenariosThey all have some form of screen processorSlide #Types of ABAP Programs (1)A programs technical attributes and capabilities are determined by its typeType 1 programs are executable programsThey do not need to be controlled by screensType 1 programs are often called reportsYou have been creating these so farType M programs are controlled through screen flow logic and must be started from a transaction code (called a dialog program or Dynpro)These are called Module Pools

Slide #Types of ABAP Programs (2)Module Pool Illustration

Slide #What is a Dialog (M) Program (1)They form the basis for transactions (transaction codes)Dialog programs implement a UOW We introduced a unit of work at the beginning of thecourse

Slide #What is a Dialog (Type M) Program (2)They consist of a single screen or multiple screens connected togetherScreens are created with the screen painter Code blocks (event handlers) execute as users navigate from screen to screenCode is still created with the ABAP Editor but the Object Navigator does a bit of workWe will use the Object Navigator in this section

Slide #Transaction InternalsDialog steps in an application program is executed by a work processUser interaction is controlled by screens (screen processor)The processing logic is executed by the ABAP processorThe ABAP processor, in turn, communicates with the database interfaceSlide #Work Process (Illustration)

Slide #Work Processes (Details)Dialog processes work with users to execute dialog stepsA screen in a dialog is considered a dialog stepUpdate processes execute database update requestsPart of an SAP LUW to bundle database operationsBackground processes execute without user interactionEnqueue processes administer a shared database lock tableMore about locks laterSlide #Work Processes (Details)

Slide #The SAP LUWIt takes several database LUWs and group them into a logical SAP LUW through a process called bundlingYou use explicit COMMIT WORK and ROLLBACK WORK statementsYou can bundle using function modules (CALL FUNCTION IN UPDATE TASK)The function module then gets committedSlide #11Object Navigator (Introduction)The object navigator wraps features of theABAP editor,Screen painterABAP dictionaryAnd a few other items we have not mentioned

Slide #Object Navigator (Introduction)You can search for things based onProgram namePackageFunction groups and function modulesThese are generally callable proceduresDevelopment objects (things used for development no release)Slide #Object Navigator (Development Objects)

Slide #Object Navigator (Development Objects)The demonstration transaction we will use tonight

Slide #Parts of a Dialog ProgramTransaction codeABAP programPAI / PBO / IncludesScreen(s)UI statusScreen flow logicGUI Title

Slide #Transaction Code (Part 1)We think of a transaction as a sequence of actions that logically belong togetherAdd a materialPost an accounting transactionWe are back to the notion of the logical unit of workIts the Dynpro application mentioned earlierSo far, you have created simpler reportsA transaction code is bound to an ABAP dialog program and CAN appear on the Easy Access menu

Slide #An SAP TransactionAccess through the Object Navigator

Slide #An SAP TransactionA transaction has an associated program and screen number

Trans TZ40Prog SAPMTZ40Screen 100

Slide #The ABAP Dialog Program (Part 2)Think of it as a very well-structured .net projectEach screen and GUI status belongs to an ABAP program

There are different ways to call an ABAP programBy default, its the dialog module (MODULE POOL)Slide #ABAP Dialog Program (Characteristics)The program has a type (M) Module Pool It typically contains 3-4 includesGlobal DataPBO modulesPAI modulesSlide #ABAP Dialog Program (Top Level Program)Global program includes the top / PBO / and PAI modules (Includes and separate files are not required but a way of doing things)

Slide #ABAP Dialog Program (Top Include)Declare global data (PROGRAM) statement appears

Slide #ABAP Dialog Program (PBO Module)PBO event triggers (fires) before the screen is displayedBefore SAP outputs the screen to the userInitialize screen values herePBO modules are declared inside of a MODULE block designated as OUTPUTIts really just a procedure / event handlerCalled by screen logic in PROCESS BEFORE OUTPUTSlide #ABAP Dialog Program (PBO Module)MODULE OUTOUT (PBO) Setup for program run

Slide #ABAP Dialog Program (PBO Module)The command SET PF-STATUS sets the program function statusMore in a moment when we cover GUI statusThe command SET TITLEBAR sets the titlebar screen

Slide #ABAP Dialog Program (PAI Module)PAI triggers after user interactionDeclare using a MODULE block as INPUTHere we do the real work

Slide #The ABAP Dialog Program Screens (Part 3)Screens form an applications visual interfaceA program might have many screensScreen flow logic controls the navigation path between screens. As the user moves from screen to screen, those PAO and PAI events fireSlide #The SAP LUW Big Picture

Slide #Program Screen (Contents)A program screen has a number to uniquely identify itFlow logic to call our PAI and PAO modulesAttributes that describe the type of screenElements containing the visible screen controls

Slide #Program Screen (Flow Logic)The flow logic of a screen calls the various PAO and PAI modules created earlierWe handle the PROCESS BEFORE OUTPUT and PROCESS AFTER INPUT EVENTS using the MODULE statement to call the appropriate module (function)

Slide #Program Screen (Flow Logic)PBO and PAI events call the modules we created in the program

Slide #Program Screen (Attributes)Audit trail infoThe screen type and configuration settingsWe will work with normal screens hereSubscreens are screens within screensSelection screens are what you have been working withModal dialog boxes are custom popupsThe next screen in the screen sequenceSize (lines and columns)Slide #Program Screen (Attributes)Attributes screen

Slide #Program Screen (Elements)Think of them as VB controlsThey bind to our underlying tablesThey have a typeThey have a positionThey have formattingThey have I/O characteristicsSlide #Program Screen (Element Types)Elementary types:Text Text field (field text)I/OInput/output field (template)Graphical field element typesPush PushbuttondHelpPushbutton for dialog helpRadioRadio buttonCheckCheckboxBoxBoxSubscSubscreen (area for an include screen)TableTable controlACtrlABAP controlFdCtrField controlSlide #Program Screen (Elements)Illustration

Slide #Program Screen (Elements)Element list / Texts I/O templates contain prompts and edit masks

Slide #Program Screen (Layout Editor)The Layout Editor is similar to the Windows Forms DesignerIt just a visual interface into the screen editor

Slide #Program Screen (Layout Editor)

Slide #The ABAP Dialog GUI Status (Part 4)It is here that we control the behavior ofThe menu barApplication toolbarFunction keysEach GUI status function has a codeWhen the user chooses the function, the PAI event firesIts assigned to the OK_CODE field AND SY-UCOMMSlide #The ABAP Dialog GUI Status (Illustration)

Slide #The ABAP Dialog GUI Status (Types)There are three types of GUI statuses

Slide #The ABAP Dialog (Connecting the Dialog Status to a Screen)We see the dialog status in the PBO module of a screenThis is how we wire the screen to the menu systemUse the SET PF-STATUS statement

Slide #The ABAP Dialog (Connecting the Dialog Status to a Screen)

Slide #The ABAP Dialog GUI Status (Menu Painter)It is here we create the menu for the programThe code maps to a function that is calledThis is the status field in the previous dialog box

Slide #The ABAP Dialog GUI Status (Application Toolbar)Associate a function and icon to the toolbar

Slide #The ABAP Dialog GUI Status (Function Keys)

Slide #Database LUWAn inseparable sequence of database operations that ends with a database commitThe LUW is fully executed or not at allThe database will always be in a consistent stateIf the LUW fails, all changes are rolled backLUWs can be committed implicitly or explicitlySlide #Database LUW (Illustration)

Slide #Database LUW (Implicit Commit)Happens whenA dialog step is completed and control passes from the Update work process to the GUIWhen control is passed from one work process to another (function call)

A work process can only execute one LUW

Slide #Database LUW (Explicit Commit)Call the function module DB_COMMITUse the ABAP statement COMMIT WORKSlide #Database LUW (Implicit Rollback)Cause by a runtime error in an applicationDivide by 0 for exampleABAP termination messageMESSASE with message type A or XSlide #Database LUW (Explicit Rollback)Call ROLLBACK WORKSlide #The SAP Lock Concept (Introduction)The problemTwo of us try to book a flight at the same timeWhen Im recording my transaction, you cannot record yoursThe number of seats available, therefore, remains accurateThe problem is solved via locksSlide #The SAP Lock MechanismLocks are set for database change statements (INSERT, UPDATE, MODIFY, DELETE)Locks are released when the change is committedLocks are available, therefore, for only one database UOWSAP locks live on top of database locks allowing you to set locks that span multiple dialog steps (These are logical locks)Slide #The SAP Lock MechanismSAP implements what is called SAP lock objectYou can lock entries in one or more database tablesYou create a lock object in the SAP data dictionarySAP creates to functions to set and release the locksENQUE