The change in the structures by changing the domain RSCHAVL does not necessarily cause the customer-specific implementations need to be adjusted. By changing the domain RSCHAVL all structures in which one or more components on the data element RSCHAVL based on deep structures. Figure 1.2 shows coding examples of the lead after the conversion to syntax errors.
Okay, now we know what implementations cause syntax errors and in what areas we need to look.
- 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.
The variant Code Inspector pre post can be performed before the upgrade and after the upgrade. Using the report ZSAP_SCI_DELTA the delta of the two races can be determined and compared.
The second version of the Code inspector CodeInspector_Post is described in the Note may be used if the syntax check before upgrading could not be carried out.
Figure 1.3 shows he result of the Code inspector variants
The syntax errors found can be accessed directly from the result of the report code inspector out using forward navigation and corrected.
When correcting errors that occur within the customer exit variables, customers are supported by SAP. In the blog New BAdI RSROA_VARIABLES_EXIT_BADI (7.3) I have the new BAdI presented for processing customer exit variable was introduced in BW 7.3. With SAP BW 7.4 has extended the delivery, the default implementations for an additional BAdI implementation. In addition to the standard BAdI implementation SMOD_EXIT_CALL (Implementation: BAdI for Filling Variables) with BW 7.4, the BAdI implementation CL_RSROA_VAR_SMOD_DIFF_TYPE (SMOD Exit Call with different Tables and Types) as inactive version is shipped. The default BAdI implementation SMOD_EXIT_CALL will continue to be delivered as active implementation.
- What is the difference of the two implementations?
- When to use which implementation has to be activated?
- Can both implementations to be active?
Both implementations serve as a wrapper / mediator / conciliator call the customer exit. Customers who start on a fresh system and no customer exit implementations can have a “legacy” in their system and should include new implementations for the processing of exit variables have their own BAdI implementations implement, see New BAdI RSROA_VARIABLES_EXIT_BADI (7.3).
To explain the difference between the two implementations, we first look at the parameters of the customer exit EXIT_SAPLRRS0_001. In Figure 1.4 in the lower part shows the Importing and Exporting parameters of the function block. In addition to the two parameters I_T_VAR_RANGE and E_T_RANGE the two parameters I_T_VAR_RANGE_C and E_T_RANGE_C have been added. The two parameters I_T_VAR_RANGE and E_T_RANGE the components LOW and HIGH are based on the data element RSCHAVL (see above) and thus are of data type SSTRING fields.
The two parameters I_T_VAR_RANGE_C and E_T_RANGE_C the components LOW and HIGH are based on the data element RSCHAVL_MAXLEN and thus are of data type CHAR. The parameters I_T_VAR_RANGE_C E_T_RANGE_C and can therefore be used analogously to the above original parameters I_T_VAR_RANGE and E_T_RANGE, they are based on flat structures.
Figure 1.4: Optional Customer Exit Parameter
The parameter pairs I_T_VAR_RANGE_C, E_T_RANGE_C and I_T_VAR_RANGE, E_T_RANGE are two options. Which option is used depends on the currently active BAdI implementation. Figure 1.4 shows the relationship between the two of the SAP delivered BAdI implementations SMOD_EXIT_CALL and CL_RSROA_VAR_SMOD_DIFF_TYPE and the parameter pairs used. The BAdI implementation SMOD_EXIT_CALL (default) works with the parameters I_T_VAR_RANGE and E_T_RANGE and the BAdI implementation CL_RSROA_VAR_SMOD_DIFF_TYPE operate with the parameters I_T_VAR_RANGE_C and E_T_RANGE_C.
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.
Figure 1.5: Switch BAdI Implementation
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.
Table 1 List of reimbursable object name
The adaptation and conversion of the implementation described here is used only makes sense if the code inspector (see above) Syntax error found was due to to the conversion of the data element RSCHAVL back.
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.2.2 Transformationen / DTPs / InfoPackages
In the third area, transformations / DTP / InfoPackages, it depends on how implementation is implemented here. From technical perspective transformation are reports also referred to as a generated program! Figure 1.6 shows how to get the corresponding generated program of the transformation. Next Figure 1.6 shows what happens when trying the generated program using the code inspector to investigate syntax error
Figure 1.6: Code Inspector and Transformations
The generated program is an SAP object and cannot be investigated by the code inspector.
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.
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.
Using the report RSDHA_TRFN_CHECK_HANA_PROCESS can check what transformations are potentially useful for a code pushdown.