cancel
Showing results for 
Search instead for 
Did you mean: 

DSO activation failing due to invalid character

Former Member
0 Kudos

Hi everyone,

Can someone please help me in figuring out how I can avoid DSO activation from failing? The activation fails with the following error message:

Value '5314crédit' (hex. '350033003100340063007200E900640069007400') of characteristic 0REF_KEY3 contains invalid characters

It even gives me the Data Package where the potentially incorrect value might be. I checked RSKC and it has "ALL_CAPITALS" in it. I read a post somewhere and added _AND_HEX to it but still the same problem. So I went and manually changed the record in the PSA (in QA) and tried it again. It failed again and this time on a different package. So it seems there are many such records that have this é symbol.

I don't want to take the shortcut of editing the PSA record as this problem might come again in the future. Can someone please tell me how I can put that symbol é in RSKC and not have this error?

Please give step by step instructions as I am not clear on how to add different symbols.

Thanks.

Accepted Solutions (0)

Answers (4)

Answers (4)

sander_vanwilligen
Active Contributor
0 Kudos

Hi,

Characteristic 0REF_KEY3 does not allow lower case. I think this is causing the problem.

A simple solution is to use a formula: TOUPPER( <source_field> ).

Alternatively, you can write a small ABAP routine: TRANSLATE <char_string> TO UPPER CASE.

Alternatively (and in my opinion a generic and solid approach) is to use the Character String Cleansing Add-on which I developed. Please refer to my blog for an introduction and a link to the document with detailed implementation instructions.

All three approached can also be used in 3.x data flows.

Best regards,

Sander

Former Member
0 Kudos

Thanks Sander. Can you please give me step by step instructions on where to put the formula or write the ABAP routine? Please keep in mind that it is a 3.x data model. I believe the ABAP code is a little different in 3.x transfer rules/update rules versus 7.x transformations, right?

sander_vanwilligen
Active Contributor
0 Kudos

Hi,

Once you are in the 3.x Update Rule, select the respective rule for 0REF_KEY3. Double click on the rule and select either Formula or Routine.

Formula:

  1. Create a new Formula
  2. Enter a description
  3. Choose formula TOUPPER
  4. Choose the source field REF_KEY3

The result of the formula should look like this:

TOUPPER( REF_KEY3 )

Routine:

  1. Create a new Routine
  2. Enter a description
  3. Write the ABAP coding

The routine should look like this:

* result value of the routine

  result = comm_structure-ref_key3.

  TRANSLATE result TO UPPER CASE.

* if the returncode is not equal zero, the result will not be updated

  returncode = 0.

* if abort is not equal zero, the update process will be canceled

  abort = 0.

Best regards,

Sander

former_member186053
Active Contributor
0 Kudos

Hi,

You can find the details in note 173241 - Allowed characters in the BW System". 

Please go through the blog related to cleansing character stings

Regards,

Vengal.

Former Member
0 Kudos

Hi,

The RSKC setting that we commonly use is

1.ALL_CAPITAL

2.ALL_CAPITAL_PLUS_HEX

Still if you are having issues then you need to get the list of allowed characters from the function module RSKC_ALLOWED_CHAR_GET and then you can manually input these in RSKC together with the special characters which is creating the issue.

Regards

Vivek

KodandaPani_KV
Active Contributor
0 Kudos

HI,

every one have same issues with special char and hexa decimal places.

please apply the below sample it will avoid the special char issue.

below code change the source field name which field you required. ex- RESULT = SOURCE_FIELDS-STUDENTEMAILID.

DATA: l_d_length like sy-index.
DATA: l_d_offset LIKE sy-index.

DATA: CharAllowedUpper(60) TYPE C.
DATA: CharAllowedLower(60) TYPE C.
DATA: CharAllowedNumbr(60) TYPE C.
DATA: CharAllowedSondr(60) TYPE C.
DATA: CharAllowedAll(240) TYPE C.

CharAllowedUpper = 'ABCDEFGHIJKLMNOPQRSTUVWXYZÄÜÖ'.
CharAllowedLower = 'abcdefghijklmnopqrstuvwxyzäüöß'.
CharAllowedNumbr = '0123456789'.

CharAllowedSondr = '!"§$%&/()=?{[]}\u00B4`*+~;:_,.-><|@'''.

CONCATENATE CharAllowedUpper CharAllowedLower CharAllowedNumbr
CharAllowedSondr INTO CharAllowedAll.

RESULT = SOURCE_FIELDS-STUDENTEMAILID.
l_d_length = strlen( RESULT ).

IF NOT RESULT CO CharAllowedAll.

DO l_d_length TIMES.

l_d_offset = sy-index - 1.

IF NOT RESULT+l_d_offset(1) CO CharAllowedAll.

RESULT+l_d_offset(1) = ''.
CONDENSE RESULT NO-GAPS.

ENDIF.

ENDDO.

endif.

CONDENSE RESULT NO-GAPS.
TRANSLATE RESULT TO UPPER CASE.

hope it will help.

Thanks,

Phani.

Former Member
0 Kudos

Thanks every one for your suggestions.

Phani - does the code you mentioned work for 3.x data flows? There are no transformations in this dataflow since it is 3.x. Would you be able to provide the code that would work for 3.x? Also, can you give me the steps on where to put the code and how to go about doing it?

Will the code handle accented letters? Such as the ones that appear in French.

Former Member
0 Kudos

Hi,

you can write the code in update rules (either on start routine or field routine), I attached images for easy reference

you can follow the code given by phani (or) you can follow my blog which explains the steps with an example.

http://scn.sap.com/community/data-warehousing/bw/blog/2010/12/23/removing-invalid-characters-using-f...

replace <source_fields> with <data_package> in 3.x