Tuesday, December 16, 2014

Possible issues in RFC call between (non)UniCode systems

We can assume that nowadays most of SAP systems are running as UniCode enabled systems. However this wasn’t the case in past. Unicode conversions of SAP systems started around year 2005. As of NetWeaver 70 all SAP systems are shipped as UniCode. 0And still you may experience SAP system running as none UniCode complaint. Whole point of having UniCode SAP system is to enable cross language character set for international data processing. Basically this was driven by companies going multinational and pursuing of globalization.

What are the things one can face in case there are interfaces running between systems which all are not Unicode? A case can be that there is a function module (RFC one - BAPI) placed in SAP system A. The function module is called remotely from another SAP system – B. Systems A and B are not both Unicode complaint. While RFC data transfer between the two a character data based on different code pages are damaged. This is caused because partners are not both UniCode. In case conversion of particular character didn't succeed then the character is replaced e.g. by #.  This basically means that data is not readable in target system; it is damaged and therefore not usable.

How to solve such a situation? The RFC data transfer converts data depending on the transport code page only. The transport code page is independent of the code page the data are encoded in. What is the transport code can be set up in TA SM59 -> particular RFC -> UniCode tab. So basically by specifying of what the transport code is and how character conversion is supposed to take place we can avoid such issues.

PS: If you ever wonder how System Status popup is build I have information for you. Whole dynpro is coded by FM STATUS_ANZEIGEN screen no 700.

Further info:
547444 - RFC Enhancement for Unicode ./. non-Unicode Connections

No comments: