Special character issue while loading data from SAP HR through VDS

[Former Member]

Hello,

We have a special character issue, while loading data from SAP HR to IdM, using a VDS and following the standard documentation: http://www.sdn.sap.com/irj/scn/go/portal/prtroot/docs/library/uuid/e09fa547-f7c9-2b10-3d9e-da93fd15d...

French accent like (é,à,è,ù), are correctly loaded but Turkish special ones (like : Ş, İ, ł ) are transformed into u201C#u201D in Idm.

The question is : does someone know any special setting to do in the VDS or in IdM for special characters to solve this issue??

Our SAP HR version is ECC6.0 (ABA/BASIS7.0 SP21, SAP_HR6.0 SP54) and we are using a VDS 7.1 SP5 and SAP NW IdM 7.1 SP5 Patch1 on oracle 10.2.

Thanks

[Former Member]

Are you importing as a CSV file or you have directly imported to the HR staging area?

In case you can save it as a CSV file in another location and open the file , see how the character appears before import.

I am also thinking may be your OS language , CODEPAGE of SAP(WAS) APPS also might be making this scramble

also it can be that the data is coming from a Non unicode system

Edited by: Franklin Jayasim on Jul 21, 2010 9:26 PM

[Former Member]

We are importing directly to the HR staging area, using the transactions/programs "HRLDAP_MAP", "LDAP" and "/RPLDAP_EXTRACT", then we have a job which extract data from the staging area to a CSV file.

So before the import, the character appears correctly in SAP HR, but by the time it comes through the VDS to the IDM's temporary table, it becomes "#".

Yes, our data is coming from a Unicode system.

So, could it be a java parameter to change / add in the VDS??

Regards.

[Former Member]

Please check the following on both

Source and destination systems

OS language support, CODEPAGE of SAP(WAS) APPS also might be making this scramble

[Former Member]

Hi,

We install Ethereal on the IDM server (2k8).

We catched LDAP packets comming from HCM server (unicode).

The packets show us that special caracters where not well encoded in LDAP packet.

Does someone have any idea why RPLDAP_EXTRACT does not send correctly "very special" caraters ?

For exemple "Ñ" is well received wherea "Ş" is not !

Thx,

Benjamin

[Former Member]

Problem solved,

The RFC was not checked as UNICODE !

Benjamin