The standard eCATT commands are designed to allow you to process all the usual operations required for testing applications. In practice however, there are circumstances where these commands are not entirely satisfactory and you would like to be able to create help functions to perform complex tasks – for example, for selects requiring more than a single record access, or which are formed dynamically. Another example is when you want to access information that is not stored in a database, such as in the memory area.
If the special requirements were to be covered by means of separately created function modules or reports, the major disadvantage would be that the help functions (called by FUN or TCD) would need to be distributed to all of the target systems affected, and this distribution would be fully outside the eCATT development environment. The eCATT construct "inline ABAP" avoids this very disadvantage.
You insert the ABAP code that is to be executed into the eCATT script between the eCATT commands ABAP and ENDABAP.
A FORM routine is generated in the designated remote system at runtime. The routine is called practically context-free by an external PERFORM.
By practically context-free execution we mean that the FORM routine is not part of a module pool, function group, ABAP objects class, or report. Therefore, there is no global data that you can refer to in the ABAP code. However, you do have the session context that is determined by the eCATT commands executed before and afterwards in the same remote system. This means that you have access to the same SPA/GPA and memory areas.
The list of variables in the generated FORM routine corresponds to the local variables defined in the current eCATT script. It certainly does not contain the import and export parameters of the script. In order to understand this, consider eCATT's versioning concept. A test script can have different versions that are intended for use in different releases where, for example, the database interfaces and basic ABAP Dictionary references are different. In eCATT test scripts, the local variables are the data definitions which can refer version-dependently to the various releases. The import and export parameters are never version-dependent and act as the version-independent interface to the outside for eCATT scripts. If the import and export parameters were also included in the transfer interface of the inline ABAP, generation errors would be unavoidable from one release to the other. Carefully restricting the selection to local variables ensures, as far as possible, that the references to the ABAP Dictionary objects are appropriate in the respective remote systems.
In practice, your programming of the eCATT script containing the inline ABAP determines which data should be transferred to the remote system. The interface is created in the eCATT script as local variables with the ABAP Dictionary references that are effective in the remote system. The data transfer from import parameters and to export parameters must still be programmed outside the inline ABAP using eCATT commands.
We recommended that you create a separate eCATT script for each inline ABAP routine and call them using REF. Unlike other eCATT commands (such as FUN, SAP GUI, and TCD), no explicit target system can be specified with the ABAP command. You can only specify the target system in which the inline ABAP is executed by using the REF call on a test script containing the inline ABAP or by setting the global destination for the execution..
In principle, the entire ABAP instruction set is available for use within inline ABAP. However, there are things to be aware of.
You use DATA statements to declare locally usable variables, though you must remember that TYPE references become effective in the respective target system. Database accesses are possible at any time under these references.
You can use all CALL mechanisms to call their corresponding objects – CALL FUNCTION ..., CALL TRANSACTION (USING ...) ..., SUBMIT REPORT ...AND RETURN, CREATE OBJECT ..., and CALL METHOD ....
Since you are within a FORM routine, you cannot define additional FORM routines. However, external PERFORM calls to other existing FORM routines are possible.
A substantial part of ABAP code outside of eCATT deals with dialog programming. You should avoid this in inline ABAP. Inline ABAP was created to improve the design of tests. Most of these tests are mass tests that are supposed to run repeatedly without any intervention by the user. Any dialog triggered by a help function would be highly disruptive. In the case of collective execution in the background or in background-similar environments, dialogs would cause program terminations. This is the reason for the guideline of not calling any functions that initiate dialogs.
There are also restrictions to do with commands that control program execution. You should not use commands like LEAVE (TO TRANSACTION, SCREEN), MESSAGE with type ‘E’ or ‘A’, or SUBMIT REPORT without the AND RETURN extension. These commands destroy the call stack and therefore cut of the RFC connection to the system under test.
As with normal ABAP programming, inline ABAP offers all the possibilities for faulty programming.
Syntax errors will occur if references to the ABAP Dictionary do not exist. They may have existed for local variables in the maintenance system but not in the current target system for execution.
Another possibility for syntax errors is simply incomplete programming by the eCATT developer.
There is a syntax checker within eCATT for inline ABAP running against a remote system, called using Testscript ® Check ® Extended. However, when a syntax error occurs, the incorrect code is also stored in the remote system in the program ECATFRAME. To analyze the error:
1. Log on to the target system,
2. Display the program ECATFRAME in SE38
3. Switch from the active to the inactive source
4. Call the Check function.
The syntax check then runs under the correct system conditions that were also in effect during the execution.
If inline ABAP is executed locally, a runtime error would immediately cause the started test to terminate with a dump display.
If inline ABAP is executed remotely and there is a runtime error, the session started remotely is terminated with a dump, the RFC connection terminates, the eCATT command ABAP is marked as having an error, and the error handling runs according to the start options.
After runtime errors have occurred, you can use the transaction ST22, in the system under test, for dump analysis.
Including the statement BREAK-POINT in the ABAP code is a considerable help in the development phase of your inline ABAP. When you execute the code in the target system, all the options of ABAP debugging are available to you. Since this of course causes dialogs in the target system, the BREAK-POINT statements must be deleted before your scripts are used in production.
No authorization problems should arise during normal sensible use of inline ABAP for help functions and check functions in eCATT tests. You can assume that every tester with sufficient authorizations to execute the tests can also execute the additional functions in the inline ABAP, without additional authorizations. Execution of eCATT in remote systems is controlled by means of corresponding client settings (table T000). These define in detail whether eCATT can be started in a particular client. This can be restricted to access via a trusted RFC link. One setting option even allows a normal RFC connection to be sufficient for starting some scripts, but a trusted RFC connection to be necessary for scripts with inline ABAP and FUN.
When programming in inline ABAP, you should ensure that the code is usefully executed in the context of tests and not simply as a further programming option. Control of the creation of such eCATT scripts is, to a certain extent, recommended in this case.
Experienced programmers would be aware that an upper limit of 36 applies for dynamically generated programs. That means that a maximum of 36 programs could be generated within a target system by inline ABAP during any one start. To get round this problem, once the limit of 36 generated programs is reached, eCATT closes the RFC destination automatically and immediately opens it again to execute the next generated program.
When a session is automatically terminated and reopened after 36 generations, you lose the context in the session used, (all SPA/GPA and memory areas are initial again), and global variables are initial again in all called function groups. If this causes errors in your own program context, for instance because an inline ABAP block must refer to the data generated by another inline ABAP block, you can still create related blocks of generated programs. You use the eCATT command RESCON to close the RFC destination being used for the current target system. Then you can be certain that the counting of the 36 generated programs will restart from the beginning when you reopen the RFC connection with another eCATT command and therefore this particular context will be applicable to the next 36 generated programs.
If programs are executed locally without a target system, exceeding the limit causes the termination of the eCATT start process. Specifying a target system with the RFC destination NONE, which also causes the local execution, solves this problem.