Modifications after Unicode conversion (ASP)

[Former Member]

Hello experts,

Our system recently got converted to Unicode.

There are some traditional asp applications which communicate with the SAP R/3 system.

After the conversion, there are some errors while connecting.

I searched through and I have a clue that we need to include librfc32u.dll file with librfc32.dll file.

Can someone guide me step by step as to where do we need to include the files? And is there any other registry updates that I need to perform.

Any help in this regard would be appreciated,

Regards

Shubhendu

[Ulrich_Schmidt1]

Hi Shubhendu,

> I searched through and I have a clue that we need to include librfc32u.dll file with librfc32.dll file.

This is not completely correct. librfc32u does not have to be used in addition to librfc32, but instead of it.

So what you need to do, is to replace the librfc32.dll with librfc32u.dll. However, this is not so simple: in the non-Unicode library all input/output data is handled as 1-byte char types, while in the "u-version" it is handled as 2-byte wchar_t type. Also the layout of the structures used by the ABAP function modules needs to be changed. So it means code changes in a few places and then re-compiling the application.

And now comes the really bad news: both, librfc32.dll as well as librfc32u.dll have reached their end-of-life 2 months ago... See Support for Classic RFC Library Ends March 2016

So instead of replacing librfc32.dll with librfc32u.dll, you would need to replace it with the "new" RFC library sapnwrfc.dll. This also needs a few code changes and re-compilation of the application.

So much as a short introduction to the topic... Now I want to point out a few things, which are not quite clear to me yet:

1. First of all, a Unicode system is also capable of communicating in non-Unicode! So actually your old ASP applications should work fine just as before the conversion to Unicode! What errors do you get? Can you activate RFC trace to see what's going wrong?
2. I can't believe that an ASP application is communicating directly with the librfc32.dll. Is it not rather the case, that the ASP application is using the old .NET Connector 2.0 (which is using librfc32.dll internally)? In that case it would perhaps be best to convert your ASP application to the new .NET Connector 3.0, if you really want to Unicode-enable it!

Best Regards, Ulrich

[Former Member]

Hello Ulrich,

Thanks for your reply. As for your question,

1. The error is weird. When there are no parameters, the RFC call is perfect and successful. However, when there are parameters, it is unable to read them properly, e.g., SUBRC is read as UBRC and therefore the structure of the parameter is not fetched and the addItem function fails.

I hope you understand why I am trying to explain here. Even I am fairly new to this.

2. What worked out for me is, installing SAPGUI on the server ( a quick hack ). This seemed to have installed proper dll files at their desired locations and the RFC started to function properly. Since we had to meet deadline, we used this method but I am still researching about what exactly could have happened. The server initially did not have the librfc32u.dll file at all.

I hope I answered your queries.

Please feel free if you have more suggestions or questions.

Regards

Shubhendu

[Ulrich_Schmidt1]

Hello Shubhendu,

I assume with "parameter" you mean a structured parameter with several fields? In that case the symptom you describe is quite common: some field offsets (the byte position inside the structure, where a certain field starts) are calculated incorrectly (e.g. a missing alignment byte or wrong fields lengths of some previous fields) and so the field is truncated.

However, I don't believe that an application that has been using librfc32.dll before, suddenly starts using librfc32u.dll, only because you install it on the server... As I said, in order to replace librfc32.dll with librfc32u.dll, code changes in the application (and consequently a re-compilation) are necessary.

Much more likely the reason is the following: your ASP application already has the correct parameters for communicating with the backend system in Non-Unicode mode. (As the backend has been Non-Unicode so far, this is quite likely.) But up to now there was a very old version of librfc32.dll on that server, that still had bugs in the Non-Unicode communication with a Unicode backend. (I think I remember that some of the older librfc32.dll versions had various problems when communicating with a Unicode backend.) By installing a recent SAPGui version, that buggy librfc32.dll got replaced with a newer version of librfc32.dll, where these bugs are now fixed! The explanation may be as simple as that...

Best Regards, Ulrich