The procedures described in this section are designed to help you analyze problems that arise when configuring reporting services.
This can happen for a number of reasons:
Session may have timed out. Press F5 to refresh.
Check if you have correctly created all methods in your feeder class. Empty is sufficient for all bar the GET_DEFINITION
method, where you must at least have filled the exporting parameters ET_FIELD_CATALOG
and the ET_FIELD_DESCRIPTION
.
If in your feeder class you have calls to methods in the FPM factory class (that your class instantiates at INITIALIZE
via the super method) you must remember that the methods INITIALIZE
, GET_PARAMETER_LIST
and GET_DEFINITION
are
called not only at run time, but also at design time by the FPM configurator. However, this FPM factory class cannot be instantiated except at run time. Thus in these 3 methods, you must encapsulate any actual calls to the methods of this class, see also the following example.
Syntax
if go_fpm is bound.
<your code>
endif.
See also Problem 4: User variants can cause dumps. You can delete these settings by running Web Dynpro Application WD_ANALYZE_CONFIG_USER
in test mode. Enter your user and the application gives you a list of your user variants. Delete these from the
list and retest.
Canadian Tax Form Reprint
service is an example of this: The recommendation from FPM is to implement one feeder class, which you assign to both FORM and LIST GUIBB configurations in your application, so that the class has all data for the form input and list
output available locally together.
Your class should inherit from the super class AC_HRGRT_REPORTING_LIST_FEEDER
. This super class has services which are more extensive than those in the FORM super class, In addition you should add the FPM interface IF_FPM_GUIBB_FORM
directly
to your feeder class, so that you can assign this class to your FORM configuration. If you need services from the other super class AC_HRGRT_REPORTING_FORM_FEEDER
, you can call these methods statically from your feeder class.
If you use a search help, this appears to be what the output is. If you use fixed values and set the type of field in the configuration to input field
the text appears instead.
It may happen that you make changes to the configuration of a list or form UIBB, and these changes are not visible when you test your application.
During testing of your scenario in the development system, sometimes user variants are saved automatically by the system. To prevent this, you can add a parameter to your application:
WDDISABLEUSERPERSONALIZATION
, value ‘X’.
Caution
Make sure you remove this parameter before you release it to the test systems. It should not be part of standard delivery.
You may find that despite setting this parameter, a user variant is created, and you still cannot see changes you have made to your configuration. This even applies to Event IDs that you might change in the configuration and in the code, and are not correctly recognized at run time, because
the old name is stored in the user configuration and is expected. Obviously a user will never encounter this, but during development you need to see your changes. The solution is to delete your user configuration by running the application configuration for WD component WD_ANALYZE_CONFIG_USER
.
Call up transaction SE80
and select WD component WD_ANALYZE_CONFIG_USER
.
In the tree, select the
.Enter your user as parameter, and select Display
.
Delete the user configuration for the component configuration you are developing.
Recommendation
Alternatively you can delete user variants inside your application by running it in test, then choosing Edit
at the top right part of the screen, then choosing Reset to Defaults
.
When you test your application, it may be that the headers of your form or list UIBB or the Document Container do not display, so you are unable to see if your title is correctly showing in the header, or indeed buttons in the header are appearing. Check that the Rendering Type
of
the UIBBs is always Tray.