Tips for Note 1823174

Note 1823174 explains the changes delivered with BW Release 7.4 SPS2 above. Therefore customer code also needs some adjustment accordingly.

This page provides the FAQ and useful tips for the adjustment after upgrade the system (KBA  1943752 ).

About the Change

The main purpose of the change is to expand the limit of characteristic value (and text) of 60 characters to 250 characters. Statistically most characteristic values are less than 60 char, so directly using CHAR250 consumes too much memory. Because it will always use 500 bytes (in a unicode system) even for a very short characteristic value. Therefore SSTRING 1333 is used since string only allocates memory it needs.

Such a data type change may lead to some adjustment in customer programs.

SCI

As explained by the note, SCI (Code Inspector) is a good tool to massively adjust programs system wise. See attachments in Note 1823174 for detailed steps. 

The note also lists the error message code in SCI result so that you can map your syntax error with the list in the note to reach a solution.

If you get ad-hoc syntax error related to SSTRING 1333, you can also use SCI in transaction se37, se38 etc. You can check variable exit code in this way.

A Simple Example to Use SCI in SE38

Customer Exit Variables 

In section 'Efficient conversion of the variable exit program', Note 1823174 explains how to massive adjust customer exit variable codes.

However it doesn't mean you only need to read this section if you hit an syntax error in the exit variable codes.

If the volume of customer exit variable codes are not too big, you can adjust the codes just like normal customer programs. That is: To solve the syntax error, search in section 'Syntax error', all possible syntax errors caused by the change to SSTRING 1333 are listed there with code change recommendations.

If there are really massive customer code changes needed, you also have the option of calling the exit function module with the CL_RSROA_VAR_SMOD_DIFF_TYPE implementation (follow the steps in section 'Efficient conversion of the variable exit program'). With this implementation, values are exchanged between SAP codes and exit codes with parameters of  I_T_VAR_RANGE_C and E_T_RANGE_C. These parameters use type CHAR 250 inside the structure instead of SSTRING 1333. So they are compatible with your old exit codes using type CHAR local variables. However, with this CL_RSROA_VAR_SMOD_DIFF_TYPE implementation, system will use more memory for variable handling than the standard SSTRING 1333 implementation. Because type CHAR250 means, even the variable only contains value 'A', it still needs 500 bytes memory.

2088758 - Customer Exit Variables not transferred after BW740 upgrade (make sure this note is applied if you use CL_RSROA_VAR_SMOD_DIFF_TYPE implementation)

Virtual Characteristics or Virtual Key Figures

Sometimes you may also hit SYNTAX_ERROR dump in virtual characteristic or virtual key figure processing in query generation. (Method IF_RSROA_SMOD_COMP_MEDIATOR~OLAP_BADI_DEFINE CL_RSROA_SMOD_COMP_MEDIATOR, CALL FUNCTION 'EXIT_SAPMRSRU_001'）.

This call stack might be confusing. Because perhaps your virtaul characteristic/ virtual key figure code might not contains code related to domain RSCHAVL change.

The real syntax error is actually pointing to ZXRSRU01 for exit variable processing.

This is because both virtual characteristics/virtual key figures and exit variables are handled in CL_RSROA_SMOD_COMP_MEDIATOR as they are all exit code handling. When virtual characteristic code is called, exit code syntax check is also performed for variable exit codes.

Therefore please correct such syntax error as explained in Section 'Customer Exit Variables' above.

BI_CONT dependency

Please make sure the system also updated with compatible BI_CONT SPs. (See Note 1853775 - Errors when using BI Content 7.47 SP04 on SAP BW 7.40 SP02).

With BI_CONT SP updated to higher level, you can avoid issues such as syntax error in SAP exit variable codes in standard queries delivered in BI Content.

The impact of 0TCTIOBJVAL: See Note 1978243 - Changes to content 0TCT* due to RSCHAVL conversion.

2184825 - Field TCTIOBJVAL: Date type change from SSTRING to CHAR not possible

Upgrade

•  RSD_PREXPRA_TO_740

In some cases the upgrade to BW7.40 get stuck in the DDIC-activation phase. To avoid this, the pre-upgrade program RSD_PREXPRA_TO_740 has to be executed before the upgrade starts.

1879618 - Pre-upgrade measures for upgrade/update to 7.4 (Note: This note should be applied on the system before upgrade, don't transport it into a 740 system after upgrade.)

1983745 - Error in RSD_PREXPRA_TO_740 (Note: This note should be applied on the system before upgrade, don't transport it into a 740 system after upgrade.)

2117771 - Primary index "/BI0/K...-0" does not exist in database

RSD_PREXPRA_TO_740 exchanges in some selected tables the dataelement RSCHAVL with RSCHAVL_MAXLEN or RSCHAVL60. Both new data elements are of type CHAR60 so that from DB point of view nothing changes. During the upgrade RSCHAVL will become SSTRING, RSCHAVL_MAXLEN will become CHAR250 and RSCHAVL60 remains CHAR60. With this "trick" the DDIC-activate runs through.

Whether the DDIC-activate phase get stuck depends on the start release and on the kind of the upgrade/update.

But if the upgrade has finished and the XPRAs RSD_XPRA_REPAIR_CHAVL_740 and RSD_XPRA_REPAIR_0TCTIOBJVL_740 have been performed, the final state of the 7.40 system does not depend whether you performed program RSD_PREXPRA_TO_740 or not. The XPRAs exchange the same data elements in the same tables after the upgrade if this has not happend before.

Therefore if the upgrade finished successfully, then report RSD_PREXPRA_TO_740 is not relevant anymore. It only avoids problems during the upgrade.

After upgrade, the RSCHAVL SAP standard coding will work fine. If it is in the generated coding then this coding is adjusted by the next use by regenerating the coding from the BW 7.40 template adjustments. You can ignore all usage of RSCHAVL in the SAP standard coding in your syntax check failure list. This coding is able to work with old and new RSCHAVL length.

The only code that needs adjustment is customer code and how it could be done is described in note 1823174.

All customer code corrections need only done once in the development system when it is on 7.40. Then you can start with the upgrade of the production system and import the corrections from the development

• SCI check

Before upgrade, please run the SCI check for the system as recommended by Note 1823174 if the source release support it. (steps in the note attachments) 
This will help you to get a list of check failure before the upgrade since some customer code may already have some defects in the system. After upgrade, rerun the SCI check and get the list again. The difference of the two lists makes a working list for you to adjust code issues caused by this characteristic value data type change.

Customer Code in Update Rule/Transfer Rule/Transformation/DTP/Infopackage

The code inspector provides a list of custom programs that need to correct. It does not cover customer coding in update rule/transfer rule/transformation/dtp/infopackage

To handle them, do the following:

First please clean up customer code with the help of the code inspector and correct the variable exit include which is not covered by the code inspector tool. After that you can active all of your update- and transfer- rules with the help of the programs RSDG_TRFN_ACTIVATE and RS_TRANSTRU_ACTIVATE_ALL. This will regenerate the code so that you will get a list of errors which you have to solve. See details in note 1823174, section Symptom.

Hierarchy Tables

In the upgrade, hierarchy tables are not touched. The nodename will keep as CHAR60 after upgrade until the next activation of the info object. After reactivation, it will be converted to SSRTING (1333). This won't affect the system function as the standard code will take care of it.

2123143 CX_SY_DYNAMIC_OSQL_SEMANTICS in CL_RSR_HIERARCHY_BUFFER

Planning Locks

The planning lock entries in SM12 is also changed to work with CHAR250 after upgrade 7.4x. However you can still read the entry with the method below:

2128372 Planning Lock Entry can't be Interpreted in SM12

Related Corrections

1956909 Query with restriction on one characteristic greater than 60 characters fails. (Truncated charval filter values in SQL statement, truncated at 60 chars, 68 chars, or 70 chars)

2082459 InfoObject master data maintenance - collective corrections as of 7.40 SP 8 - #1

1997971 740SP8: Incorrect processing of conversion exits in Transformation

How to Search Lastest Corrections for this Topic

You could search with key word RSCHAVL