2_08 dynpro trace 8

No Slide TitleDynpro Trace
Exercise: Recording a trace of transaction VA01
3
Learn how to record traces of the screen processor and to
use them to understand the processing of dynpros better
Learn how to use the Dynpro Trace
In this chapter, we will show how traces of the screen processor (also called DYNPRO processor) can be recorded and how these trace files can be used to obtain detailed information about the processing of dynpros.
SAP AG 1999 Debug_WS_2_08 (E.S.,B.G.,K.K.) / *
Dynpro Trace - Overview
Trace analysis list
Y ->module VBAK-ORGDATEN_PRUEF
Y <module
Y - 0x20202020
Y ->output: VBAK-AUART
Y - intern: tab(46)-fld(65)
Y NO subscreens
Y field = VBAK-AUART
Y offs_in_field = 0
Y Fri Jun 16 09:29:19 2000
Y send data to SAPGUI
Screen processor trace files offer a huge amount of information. To interpret them it is useful to recall the basic processing steps of dynpros in the R/3 system. We will do this in a brief technical summary.
Trace information can be requested at different levels of content. We will show which information can be obtained at different trace levels.
We will show how to record trace files for dialog and background work processes.
The major part of this chapter will show comprehensive examples of how to read recorded trace files.
Dynpro Trace - Technical Summary
send
receive
SAPGUI
Screen
processor
trace
The flow of screens is controlled by the dynpro processor runtime and is triggered, e.g., by statements like ‚leave to screen ...‘ in an ABAP program.
The screen processor trace contains information about screen flow and all processing steps of a single screen. The processing of a screen involves several steps in addition to PBO, PAI and processes on value and help requests that are accessible to a normal application program.
The screen processor trace also contains information about other tasks of the dynpro runtime like field transport, message handling, batch input processing, and communication with SAPGUI.
Dynpro Trace - Screen processing steps in detail
PBO - Process before output
DCO - Data comm. output
Resizing (subscreens, tab strips, table views)
Processing of PBO modules and loops
Field transport of all loop fields
Field transport of all non-loop fields
Communication with SAPGUI
and fields without explicit transport
Remaining field transports
Processing of PAI modules
Before a dynpro is sent to SAPGUI, several processing steps are carried out by the screen processor. Before any PBO modules, all resizable screen elements are resized. Field transport is done in the PBO or DCO steps, depending on field type.
Before sending data to SAPGUI, screen compression is carried out.
Special system functions are performed in modules %_ctl_output and %_ctl_input. This involves communication with GUI controls that are not handled by the dynpro processor itself - also the setting of transaction variants during output is done here.
Dynpro Trace - Information
Trace level 2
Trace level 3
Trace level 1
severe errors only
screen resize
screen compression
subscreen tree
Three different ‚verbosity‘ levels can be set for the screen processor trace.
Level 2 is sufficient if no information on field transport or batch input is required.
Level 3 traces can become very large because they record all field contents during output and input. They also contain more ‚technical‘ details on screen compression and resize.
Batch input processing is only traced in level 3.
Dynpro Trace - Trace recording: Report RSTRC000
1. Start report RSTRC000
2. Select trace level
3. Keep work process
4. Select trace component
7. Start your transaction
in the same window
When recording a trace it is necessary to lock a work process exclusively so that no other users can interfere. This can be done with report RSTRC000. This reports links a certain dialog process to an external mode and prevents a rollout.
Dynpro Trace - RSTRC000: Stopping and displaying the trace
8. Press Default val.
9. Press Change
10. Press Display
Do not forget to release the work process again after the trace has been recorded, because the work process is blocked for other users!
Dynpro Trace - How to trace a batch process?
You cannot lock a batch process
You need to ‚guess‘ which batch process will run your
background job
Use transaction SM50 (Process Overview)
Traces of batch processes can be recorded as well, but report RSTRC000 cannot be used (no lock possible).
If a background job is submitted, it usually runs in the first free batch work process (the one with the lowest index number).
You can change the trace level and trace components in transaction SM50. In SM50, you can also display the trace file.
Alternatively, you can use transaction ST11 for display.
Since no time stamp is available here, the whole work process trace file will be displayed.
Dynpro Trace - Example: Starting transaction VA01
M WP_LOCK_SET 990617140308
Y GETfocus in MAIN-screen: RSTRC000 1010
Y field = TRC_LEVEL
Y offs_in_field = 0
Y OK-code "/NVA01"
Y <load dynpro
focus
OK-code
After receiving data from SAPGUI, the screen processor first traces the focus position (cursor) and the OK-Code that was entered by the user.
Since a new transaction shall be started, screen SAPMSYST 0040 is processed next. This is one of several system dynpros which are normally processed dark.
Generally, the start of a certain processing step is marked with ‚->‘.
The end of a processing step is marked with ‚<‘.
Dynpro Trace - Example: VA01 - output
...
Y ----------------------------------------
...
Y <module
- field content as text
load program / load dynpro
After processing SAPMSYST 0040 with suppressed dialog, the initial screen of a transaction is loaded and PBO modules are executed.
Applications often set or get parameter id‘s and perform dynamic screen modifications in the PBO step.
The trace only records that a certain screen field has been modified, but the actual screen parameters still need to be inspected in the ABAP debugger - they are not listed in the trace.
Dynpro Trace - Example: VA01 - input
...
...
Y - 0x20202020
- modified flag
- empty flag
When a screen comes back from SAPGUI, the trace displays on which screen/subscreen data was received (sy-datar = X).
For all fields, additional flags indicate whether the field is empty and/or modified.
Dynpro Trace - Example: Input with conversion and field exit
Y ->input: VBAK-AUART
Y - intern: tab(46)-fld(65)
Y - (4)<ta >
Y - 0x20202020
field content before exits
- conversion exit <data element>
- field exit <data element>
field <...> module <...> statement
conversion exits and field exits cannot be debugged at runtime
they are only visible in the screen processor trace
When a field transport is carried out by the dynpro processor, some additional ABAP function modules may be called. These are conversion exits and field exits. They cannot be debugged at runtime. They are listed only in the screen processor trace.
In the example above you can see how an incorrectly programmed users field exit erases the content of field VBAK-AUART.
Field exits are called only at input. Conversion exits may be called at output and at input.
At output, the screen processor can also set global field settings (user modification via transaction SHDG. They can be seen in the trace by statements like - set global field value or - set global field invisible.
Dynpro Trace - Example: Transaction with standard variant
T-Code is SM35
variant
is loaded
Field modifications due to the variant
are carried out in module
%_CTL_OUTPUT
...
Y modify screen field D0100-SPERR
By defining a transaction variant, it is possible to modify field attributes of the transaction screens. One can make fields invisible, e.g., or preselect field values.
Transaction variants can be created via transaction SHD0.
If a variant is active for a transaction, program SAPMSHD0 is processed dark before the transactions is actually started.
Field contents and screen modifications due to a variant are set by the screen processor in module %_ctl_output. If a variant sets a field content, this is traced as -simulated input. Screen modifications are traced as -modify screen field.
Dynpro Trace - Example: Messages
Very often you need a quick way to find out where a certain message is output by an application and in which context this happened.
You can use the dynpro trace level 2 to gain an overview of message processing.
This information helps you to effectively set breakpoints in the ABAP debugger.
Still the old R2 keys for the message type are used in the trace:
SET means set message (type S)
NAT means information (type I)
DIA means warning (type W)
ERX means error message (type E)
ABE means abend message (type A)
ABAP coding:
Y ->PAI SAPMV45A 4701
Y ===> Var_1<1000000015>
type
class
id
All application and system messages are traced at trace level 2. One can see message type, class, id and message variables.
You can quickly locate the PBO or PAI module in which a certain message is output. With this information, you can set a debugger breakpoint in the corresponding application coding.
Alternatively, you can use the ABAP runtime analysis (SE30) for finding out in which function or form the message is output.
Finding messages by simply placing a breakpoint at statement ‚message‘ may be quite time consuming, because many messages are raised but not actually put out in a complex application.
Transaction SE91 displays all messages belonging to a certain message class. You can try to locate the application coding via the ,where-used‘ list in SE91. This does not work when the application sets message class and id dynamically.
Dynpro Trace - Example: Subscreens
loading the main screen
...
Y <load dynpro
..
...
calling a subscreen of a subscreen
When the screen processor loads a dynpro with resizable subscreens, it first calculates the new size of these subscreen areas.
After resizing, the PBO modules are processed and subscreeens are called.
Dynpro Trace - Example: Subscreen tree
compression of all screens
Y ->subscreen tree
Y SUBSCREEN_HEADER (1,2) ->5
Y SUBSCREEN_BODY (8,3) ->2
Y SUBSCREEN_TC (10,2) ->3
Y SUBSCREEN_BUTTONS (19,2) ->4
Y PART-SUB (2,2) ->6
Y <subscreen tree
Y field = KUAGV-KUNNR
Y offs_in_field = 0
trace of subscreen hierarchy
- main screen (screen 1)
focus information
In level 3 of the screen processor trace, the hierarchy of all subscreens of a main screen is recorded as subscreen tree. This makes it easier to track the calling chain of subscreens in complex applications.
The subscreen tree is usually written into the trace file after screen compression, right before focus information and before the complete screen is sent to SAPGUI.
Dynpro Trace - Tracing batch input sessions (BDC)
...
Y *** BDC - BDC_START_GROUP
Y *** BDC - Mappeninformationen:
Y start BDC transaction
Start of the first BDC transaction
Level 3 of the screen processor trace contains extensive information about batch input processing.
Note that trace file entries by the batch input runtime are in german language at this time.
Dynpro Trace - Tracing BDC: Processing a single screen
...
Y ---------------------------------------------
Y *** BDC -
Y *** BDC - Aktuelles Dynpro: <SAPMV45A 0101>
Y *** - noch nicht prozessiert
Y *** BDC - default window size exist
Y *** BDC -
Y *** BDC - BDC_OKCODE: <=ENT2>
Y *** BDC - Feldwert: <ta>
BDC data output
- BDC field value
Transfer of batch input data to a dynpro is performed after screen compression is finished.
The batch input processor compares the actual screen of the application with the actual screen in the batch input data and checks whether the former was already processed.
If the screen was not yet processed, batch input data are transferred to the corresponding screen fields.
The trace also displays OK-Code and cursor position as they are set by batch input.
Dynpro Trace - Tracing BDC: Screens that are skipped
Y *** BDC - Aktuelles Dynpro: <SAPMSDYP 0010>
Y *** - Info-Dialog im aktuellen Dynpro
Y *** - Kein Einmischen der Daten erlaubt
Y *** BDC - Aktuelles Dynpro: <SAPMV45A 4001>
Y *** - Err./Warn.-Dialog im aktuellen Dynpro
Y *** - Kein Einmischen der Daten erlaubt
Y *** BDC - Aktuelles Dynpro: <SAPMSSY0 0120>
Y *** - Meldungs- oder Hilfedialog
The BDC runtime does not process screens within
F1 / F4 excursions
error-, warning- or info dialogs
In some special situations, the batch input runtime does not transfer data to the present screen. These are screens that are processed in dialogs after error messages or warnings, in F1 or F4 help dialogs or information popup windows.
Dynpro Trace - Tracing BDC: COMMIT WORK
Y COMMIT WORK: imode= , vb=X, vbmode=S, bdc=X
Y Mon May 31 16:52:59 1999
...
Y *** - TRANS# qcb: <1>
...
COMMIT WORK always means ‚successful end‘. BDC processing stops.
COMMIT WORK by application
(successfully processed)
stops with message 00 345
Sometimes a batch input does not behave as expected because the application sets more than one COMMIT WORK statements. At the first one, BDC processing will stop and the transaction will be marked as ‚successfully finished‘.
Dynpro Trace - Tracing BDC: ‚out-of-sync‘ situations
...
Y ->(res) module OK_CODE
Y ->load dynpro SAPLSPO1 0100
...
...
Y *** BDC - Aktuelles Dynpro: <SAPLSPO1 0100>
Y *** - noch nicht prozessiert
Y ===> Var_1<SAPLSPO1>
Y ===> Var_2<0100>
application, but ..
different one!
‚No batch input data for screen ..‘
One of the most common errors in batch input processing occurs when the application called a different screen than was expected in the batch input data. This leads to the famous message S00 344.
In the screen processor trace it can be easily seen which screen was expected by the BDC processor and which screen is actually processed. By going back in the trace one can find the coding where this screen has been called by the application program.
Dynpro Trace - Exercise
Make yourself familiar with recording a dynpro trace of a dialog work process
Lock the work process with report RSTRC000
Start transaction VA01 (sample data for the first screen are, e.g., TA/0001/01/01). You may also use a transaction that is more familiar to you
Unlock the work process and display the trace with RSTRC000
Compare traces recorded with level 2 and 3
Evaluate which level of information you normally need to solve a problem
See how level 2 can be used to obtain an overview of the flow of screens and level 3 for a more detailed analysis
In the screen processor trace it can be easily seen which screen was expected by the BDC processor and which screen is actually processed. By going back in the trace one can find the coding where this screen has been called by the application program.
Dynpro Trace - Summary
You learned how you record traces of the dynpro processor
You obtained an overview of the information in different trace levels

2_08 dynpro trace 8

Documents