November 24, 2014 10 minute read

Migration of customer’s own implementation for BW 7.4

The original blog can be found here: ekessler.de

In this blog I describe the conversion of customer-specific implementation that may be necessary by changes to SAP standard data types.

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?

Due to the expansion of key information objects previously max. 60 characters to 250 characters was now in BW 7.4, the data type of the domain RSCHAVL (which is used by the data element RSCHAVL) changed from CHAR 60 to SSTRING.

The data type STRING is a dynamic data type of a variable length of up to 1333 characters (see http://help.sap.com/abapdocu_731/en/abenbuilt_in_types_dictionary.htm).

The data element RSCHAVL is used in several BW structures in the framework of selection options (Range tables). Figure 1.1 shows the two selection structures which are used to process BEx variables used in the context of the customer exits. The import parameter I_T_VAR_RANGE based on the structure RRRANGEEXIT (BW: Simplified structure for variable exit variable) and the export parameters E_T_RANGE based on the structure RRRANGESID (range expanded around SID). Internal access both structures back to the include structure RRRANGE (range table in brain).

Figure 1.1: Selection Structure in customer exit EXIT_SAPLRRS0_001

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.

Figure 1.2: Invalid ABAP Syntax in BW 7.4

The declaration of local structures using theTABLES statement is allowed only for tables based on flat structures. This also applies to the declaration by DATA and LIKE.

The LIKE operator can easily be replaced by the type-specific operatorTYPE here. For the declaration by
the TABLES statement, the coding on the declaration byDATA must be changed.

The typical types CHAR use of offsets and lengths as ls_e_range–low + 6 (2) is based on string types are not allowed and will lead to syntax errors.

The use of offset and length specifications can be replaced by string operations (concatenation) or by the use of string templates, see Figure 1.2.

Other examples of implementations that run in NW 7.4 syntax errors are in Note 1823174 – BW 7.4 lists changes and customer-specific programs in the section syntax error.

1.1 What and where changes are necessary?

Customerexit forvariables
Customer-SpecificPrograms
Transformations / DTP / InfoPackages

1.2 How can the job be with the syntax error found

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 Note 1823174 – BW represents 7.4 changes and customer-specific programs two Word documents are available in which is described as using the code
inspector (transaction SCI) customer-specific implementations can be examined for syntax errors. The reference here offers two variants of the code inspector.

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.

Old	New
i_t_var_range	i_t_var_range_c
e_t_range	e_t_range_c
rrrangeexit	rrs0_s_var_range_c
rrs0_s_var_range	rrs0_s_var_range_c
rrrangesid	rrs0_s_range_c
rsr_s_rangesid	rrs0_s_range_c

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.

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.