SAP AG 1999 Debug_WS_2_08 (E.S.,B.G.,K.K.) / 1 Dynpro Trace Goal: 1 1 2 2 Information provided by the trace Example: Traces of transaction VA01 Exercise: Recording a trace of transaction VA01 3 3 rn how to record traces of the screen processor and them to understand the processing of dynpros bette Learn how to use the Dynpro Trace
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.
SAP AG 1999 Debug_WS_2_08 (E.S.,B.G.,K.K.) / *
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.
SAP AG 1999 Debug_WS_2_08 (E.S.,B.G.,K.K.) / *
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.
SAP AG 1999 Debug_WS_2_08 (E.S.,B.G.,K.K.) / *
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.
SAP AG 1999 Debug_WS_2_08 (E.S.,B.G.,K.K.) / *
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.
SAP AG 1999 Debug_WS_2_08 (E.S.,B.G.,K.K.) / *
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!
SAP AG 1999 Debug_WS_2_08 (E.S.,B.G.,K.K.) / *
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.
SAP AG 1999 Debug_WS_2_08 (E.S.,B.G.,K.K.) / *
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 ‚<‘.
SAP AG 1999 Debug_WS_2_08 (E.S.,B.G.,K.K.) / *
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.
SAP AG 1999 Debug_WS_2_08 (E.S.,B.G.,K.K.) / *
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.
SAP AG 1999 Debug_WS_2_08 (E.S.,B.G.,K.K.) / *
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.
SAP AG 1999 Debug_WS_2_08 (E.S.,B.G.,K.K.) / *
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.
SAP AG 1999 Debug_WS_2_08 (E.S.,B.G.,K.K.) / *
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.
SAP AG 1999 Debug_WS_2_08 (E.S.,B.G.,K.K.) / *
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.
SAP AG 1999 Debug_WS_2_08 (E.S.,B.G.,K.K.) / *
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.
SAP AG 1999 Debug_WS_2_08 (E.S.,B.G.,K.K.) / *
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.
SAP AG 1999 Debug_WS_2_08 (E.S.,B.G.,K.K.) / *
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.
SAP AG 1999 Debug_WS_2_08 (E.S.,B.G.,K.K.) / *
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.
SAP AG 1999 Debug_WS_2_08 (E.S.,B.G.,K.K.) / *
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‘.
SAP AG 1999 Debug_WS_2_08 (E.S.,B.G.,K.K.) / *
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.
SAP AG 1999 Debug_WS_2_08 (E.S.,B.G.,K.K.) / *
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
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.
SAP AG 1999 Debug_WS_2_08 (E.S.,B.G.,K.K.) / *
Dynpro Trace - Summary
You learned how you record traces of the dynpro processor
You obtained an overview of the information in different trace
levels
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.