The original blog can be found here: ekessler.de
The Note 1823174 - BW 7.4 conversions and customer-specific programs is already on this subject and also describes analysis and
solutions. The blog is intended to supplement give the note provides additional background information and assist in the search for the best way for the changeover.
1.1 Why and when is the change necessary?
the TABLES statement, the coding on the declaration byDATA must be changed.
1.1 What and where changes are necessary?
- Customerexit forvariables
- Transformations / DTP / InfoPackages
1.2 How can the job be with the syntax error found
- But as we now find the job in customer own implementations?
- Do all reports / Includes / function modules / classes / ... be reviewed manually?
- What are the options for the correction of errors found?
1.2.1 Customer Exit for variables and user-defined programs
The answer here is not unique. If we looks at the three areas that need, we investigate we can for the first two, customer exit for variables and user-defined programs, make it clear that this can be checked automatically.
inspector (transaction SCI) customer-specific implementations can be examined for syntax errors. The reference here offers two variants of the code inspector.
Figure 1.3 shows he result of the Code inspector variants
- What is the difference of the two implementations?
- When to use which implementation has to be activated?
- Can both implementations to be active?
In the event that the code inspector has many syntax errors found are attributable to the conversion of the data element RSCHAVL recommends you use the optional BAdI implementation CL_RSROA_VAR_SMOD_DIFF_TYPE SAP. Figure 1.5 shows what steps are necessary to use the optional implementation. Start transaction SE18 (BAdI Builder), select the BAdI name option, enter the name RSROA_VARIABLES_EXIT_BADI BAdI and then select Display.
In the enhancement spot (Enhancement Spot) expand the entry RSROA_VARIABLES_EXIT_BADI. Double-clicking on implementations shows the list of the BAdI implementations (1).
The yellow light indicates that the default implementation SMOD_EXIT_CALL is active. The gray lamp indicates that the implementation CL_RSROA_VAR_SMOD_DIFF_TYPE is not active. The definition of the BAdI allows that may be active BAdI implementations several parallel. Therefore, the order of step (2) and (3) is arbitrary.
In step two, we first disable the default implementation. Double-clicking on the implementation in the list on the right of (1) opens the BAdI implementation (2). To disable the implementation of the indicator IMPLEMENTATION IS ACTIVE must be de-selected. Subsequently, the implementation must be enabled.
In step three, we activate the optional BAdI implementation CL_RSROA_VAR_SMOD_DIFF_TYPE. Double-clicking on the implementation in the list on the right of (1) opens the BAdI implementation (2). To activate the implementation of the indicator IMPLEMENTATION IS ACTIVE must be selected. Subsequently, the implementation must be enabled.
After the default implementation deactivated and the optional deployment is enabled, the colors of the lamps should have according to (4). If this is not the case, you must update the display policy.
Now that the optional BAdI implementation must now be adapted to the active user-defined coding. For this purpose, only the names of the objects used (structures, table types) must be replaced within the customer's own implementations, as listed in Table 1. For this, the editor function Search and Replace can be used.
Has the Code inspector found no such error or the number of errors is very low, it is recommended that the syntax error in the client implementations to correct and use the default BAdI implementation.
Principle for custom programs are the same as for custom implementations within the customer exits. Here is the fact that there are other structures in which the data element RSCHAVL is used as in Table 1 (see above) listed. For these structures no CHAR-based alternatives. If, for example, the structure RSDRD_S_RANGE (Single Selection for a at InfoObject in a deletion Criterion) in the context of a customer-defined program used must be determined if it comes here to syntax errors. This can be checked similarly to exit variables using the code inspector.
Eventually, the object list in the Code inspector must be adjusted. This is the case if the implementation for the variable exit is organized in another development package as for example the maintenance programs for Housekeeping.
1.1.1 Transformationen / DTPs / InfoPackages
For the sake of maintainability and reusability many customers are changing over implementations start-, end-, field- or experts routines. Here you will find different approaches to the simple use of includes too complex class models. Outsourced implementations, since they're all here is customized implementations using the Code Inspector (transaction SCI) are reviewed.
Is being implemented directly within the transformation take place it must be manually checked the corresponding transformation.
|Generated program transformation|
|From a technical perspective transformation is a report in which a local ABAP OO class is defined. Basis for the report and the local class templates. These templates are the basis of the generated program. The program code is added within the definition of transformation as start, end, field or expert routine is generated in the local class.|
To not be able to check each transformation individually and manually transformations using the report RSDG_TRFN_ACTIVATE be automatically activated. The report can be scheduled this as a background job.
About the selection screen of the report RSDG_TRFN_ACTIVATE can be controlled if a single transformation, a list of transformations or transformation with specific source or target objects to be activated. Figure 1.7 shows how the report is run for a transformation. If all transformations are to be tested by re-activation for syntax errors must be released all selection fields.
When selecting a transformation, the generated program is regenerated (this happens only when necessary) and checked for syntax errors. That contains a transformation faulty code cannot enable it features this.
Figure 1.7: Re-Aktivierung von Transformationen
The log-result on the right side of Figure 1.7 shows that become inactive by activation of the transformation of the first or the associated DTP. The report then activated the dependent DTP.
In the inactive transformations must now be checked manually why they could not be activated. As an entry for the reworking of the outcome of the application logs can be (transformations) is used (see Figure 1.7) or the table RSTRAN.
|Code pushdown transformations and DTP|
|A positive side effect of the re-activation of the transformations is that thereby implicitly a code pushdown is performed transformations if this is possible. This of course assumes that the database is a SAP HANA.|
Using the report RSDHA_TRFN_CHECK_HANA_PROCESS can check what transformations are potentially useful for a code pushdown.
|Routines in the DTP filter and in the InfoPackage|
|The structures that are used in the context of selection by BEx variables of type Customer Exit or ABAP routines in DTP and / or information packages from the SAP does not currently affected. That is to say here is only when action within its own implementation of a structure is used for the one component to the data element RSCHAVL based.|
1 SAP Notes
1943752 - SYNTAX_ERROR Dump Occurs when Executing a BW Query with Customer Exit Variable after Upgrading to BW7.4
2098262 - SAP HANA Execution: Only RownumFunction() calculated attributes are allowed