There are limitations when recording Web Dynpro for ABAP applications using the eCATT driver WEBDYNPRO. This note contains a list of the supported controls and the known limitations.
- Even though eCATT already supported the testing of Web Dynpro ABAP applications as of Release SAP_BASIS 6.40, due to the chosen design, this support was very prone to errors.
- Due to the high number of problems, the decision was made to completely revise the design, which was only possible with an incompatible change. eCATT now uses the XBCML log renderer to record Web Dynpro ABAP applications. However, the XBCML log implementation is not officially supported until Release SAP_BASIS 7.02 or SAP_BASIS 7.20 (also see Note 1157611).
- Therefore, within SAP, the eCATT support for Web Dynpro ABAP is used with the following release combinations only:
SAP_BASIS 7.02 or higher
SAP_BASIS 7.20 or higher
- eCATT system:
SAP_BASIS 7.00 Support Package 20 or higher
SAP_BASIS 7.01 Support Package 05 or higher
SAP_BASIS 7.02 Support Package 01 or higher
SAP_BASIS 7.10 Support Package 09 or higher
SAP_BASIS 7.11 Support Package 03 or higher
- We recommend the following procedure for SAP customers:
Use the eCATT support for Web Dynpro ABAP applications only in the release combinations specified above (or higher).
If you have a different (older) release combination and you are already using eCATT support for Web Dynpro ABAP applications without any problems, you can continue to use this combination.
If you have a different (older) release combination and you have not yet used eCATT support for Web Dynpro applications, we recommend that you use the test tools of an external supplier (for example, HP Quicktest Professional or Compuware TestPartner) to test the Web Dynpro applications. You can then use the eCATT command REFEXT (see the eCATT documentation) to include these test scripts in eCATT procedures again, and you also have the option to include these "external test scripts" in the SAP Test Workbench or in eCATT test runs.
- eCATT uses the SmartClient together with the XBCML log renderer to record Web Dynpro ABAP applications. Note that SmartClient and browser rending (HTML) are different. It is possible that incorrectly implemented Web Dynpro ABAP applications seem to run correctly in the browser, but cannot be executed in SmartClient. This usually indicates an error in the implementation of the Web Dynpro application. To be able to record eCATT test scripts successfully, the Web Dynpro ABAP applications must be executable in SmartClient (SapWDGui.exe). In particular, the application may not be programmed for side effects of the HTML rendering.
- Web Dynpro IDs: So that a Web Dynpro ABAP test script that was recorded using eCATT can run in a way that is stable and can be reproduced, you must ensure that the IDs (Window IDs, component IDs, and so on) of the Web Dynpro application are stable. This means, for example, that these IDs may not be changed if the application has not been changed, or has been changed in small details only. Unstable IDs may be caused by, for example, dynamic programming, the reconfiguration of the screen, or dynamic embedding of Web Dynpro ABAP components. The developer of the Web Dynpro application must therefore ideally ensure that all of the operation-relevant user interface (UI) elements have fixed names or IDs.
- Web Dynpro actions: eCATT support for Web Dynpro ABAP records only actions that actually trigger server communication (a roundtrip).
- Web Dynpro messages: eCATT support for Web Dynpro ABAP can support only messages that are from T100, and that are generated using one of the following methods (for details about this limitation, also see related Note 1360408):
- You should avoid using input helps during a running eCATT recording. If you must use input helps in the recorded scenario, you are not subsequently allowed to change the script so that the sequence or the number of input helps that were called is changed.
- Web Dynpro applications with embedded IFrames: Applications with embedded IFrames (UI element IFrame) can only be recorded with restrictions. During the recording, note that only the external applications (external sessions) are recorded. The embedded applications (internal session) are not recorded. The internal application must therefore be recorded separately. In general, eCATT cannot navigate to other sessions.
- Web Dynpro contexts and supply functions: To record Web Dynpro applications, you must ensure that the context supply functions correspond to the documented requests (SAP Library: Web Dynpro ABAP -> Web Dynpro ABAP: Development in Detail -> Basics -> Programming Controller Methods -> Methods of the Local Controller Interface -> Supply Function).
The most common errors are that temporally interdependent supply functions access the data of view elements and/or global variables. When you record using eCATT, the time at which a supply function was called may differ from the time at which the HTML renderer was called. This may result in malfunctions that are difficult to reproduce, or the termination of the Web Dynpro recording. The documentation contains the relevant notes:
1. Since supply functions are called only by the runtime, no statement can be made as to the time of your call.
2. Supply functions may access only such context data that is either in the related parent node or in another node that is in the hierarchy directly above the node that is supplied via the relevant supply function.
3. No exception should be triggered if possible in a supply function or in a method called by a supply function. Since supply functions are often called only during rendering, such exceptions can no longer be processed sufficiently.
- Web Dynpro phase model: To record Web Dynpro applications, you must ensure that the phase model has been adhered to correctly (also see: SAP Library: Web Dynpro ABAP -> Web Dynpro ABAP: Development in Detail -> Basics -> Programming Controller Methods -> Phase Model). You cannot record Web Dynpro applications that are based on side effects of HTML rendering. The side effects could, for example, be browser roundtrips that are not based on an explicitly specified action and that manipulate the context or the view definition in the controller methods WDDOBEFORE* or WDDOAFTER*. In general, a data transport during SmartClient rendering (such as that used by eCATT for recording) is triggered only in the case of explicitly modeled actions.
- Web Dynpro applications that utilize the side effects of the HTML renderer must either be corrected by the application developer so that they can also be executed in SmartClient, or alternatively, they can be recorded using external test tools such as Quick Test Professional (QTP).
- Performance: With eCATT support for Web Dynpro ABAP, all of the application data is always recorded and run. There is no delta handling. This means that the performance of Web Dynpro support in eCATT depends to a large extent on the amount of data in the application. For optimal performance, the application to be tested should work with as few data records as possible (for example, it should not use any tables with thousands of data records).
- Web Dynpro applications that are based on Web Dynpro components (for example, applications that were created using the Floor plan Manager): eCATT Web Dynpro test scripts may be invalidated when a single component is updated because in such a case, all or some of the IDs are regenerated and therefore, the recorded IDs are no longer valid.
- Web Dynpro parameters: Some URL parameters that are relevant for browser/HTML rendering are not supported by eCATT (for example, WDDELTARENDERING is set to ON).
- Supported controls: Due to the architecture of Web Dynpro ABAP, we cannot provide a general statement of the supported controls. Therefore, the list of supported controls specified below is incomplete. Since controls can be used in various contexts (for example, a button in the context of a table), a supported control may function correctly on the screen, but it may not function correctly when it is used in a tree. The list of supported controls and the list of controls with limitations will therefore be extended and enhanced over time.
- The context menu is not supported in eCATT mode.
- Drag and drop is not supported in eCATT mode.
- BreadCrumb and BreadCrumbStep
- Button and ButtonRow
- Checkbox and CheckboxGroup
- DropdownByIndex and DropdownByKey
- Radiobutton, RadiobuttonGroupByIndex and RadiobuttonGroupByKey
Controls with limitations:
SingleMarkableCell does not work because you cannot map the binding in the XBCML log.
The column parameter is not set during sorting.
Recursive Tree is supported to a certain extent only.
The expanded state of a tree node must be bound.
- MessageArea: Only the SmartClient MessageArea is supported.
Web Dynpro ABAP has a special MessageArea implementation that is different to the SmartClient MessageArea.
- RowRepeater is not supported.
Controls that are not supported:
- Active Component controls (Office Control, Gantt and Network)
- ActiveX Control, ACF Execute, ACF Upload/Download
- Adobe control (Interactive Form)
- BusinessGraphics controls (BusinessGraphics and GeoMap)
- BusinessIntelligence controls (BIApplicationFrame)
- FlashIsland or Silverlight control
- Pattern controls (Message Area, Pattern Sequence, Pattern Tabstrip, Pattern Tray and Contextual Panels)
- Calendar control
- Timed Trigger control
Scenarios that are not supported:
- Portal and OBN navigation
- POWLs with navigation to new applications