NCO 2.0 and UNICODE compatibility

[rcvt]

Hi all

We are still running ECC 6 EHP 7 non-UNICODE and busy with HANA readiness exercise and thus UNICODE conversion. During testing it came to light that a critical app that integrates with SAP via NCO 2.0 is not working. 

I am unable to locate any documentation for NCO 2.0 and opened a ticket to request the same (hopefully answered as it is already out of support). 

In general is NCO 2.0 UNCODE aware/enabled? When I check I can only see librfc32.dll present in the application install folder. When the app is doing the RFC call to SAP, the call makes it to SAP, but it seems like the service is then failing when SAP returns the requested information.

I have tried some of the 3.0 UNICODE parameters (e.g. PCS) in the app.config, but no luck thus far. Alternative seems to have the app rewritten to use 3.0 which is a huge task. 

Any help or guidance would be appreciated.

[HAL9000 · Accepted solution]

In general, NCo 2.0 was capable to communicate with Unicode ABAP backends. However, NCo 2.0 pursued a proxy-based approach, which means that the proxy classes also must have been generated from a Unicode ABAP system. I assume this is not the case for your old solution.

Please also see https://support.sap.com/nco with regards to the new design concept as of NCo 3.0:

---

NCo 3.0 no longer distinguishes between a design time and a runtime. Instead of proxy classes and generated coding, you now program RFC calls dynamically. This has advantages (less and more easily understandable coding; robustness against changes on backend side — e.g. it is no longer necessary to re-generate the proxies and re-compile your application if the backend moves from non-Unicode to Unicode; no dependency on a fixed Visual Studio release) as well as disadvantages (no IntelliSense support; you need to know how the ABAP side looks when consuming RFMs in .NET).

---

So, to get your old NCo 2.0 application to work now, you would at least have to regenerate your proxy classes with your new Unicode ABAP backend system, and then recompile it. Simply specifying a different logon parameter for Unicode won't do it here.

Considering the fact that you need an old Microsoft Visual Studio .NET 2003 for installing the NCo 2.0 Proxy Wizard (which is out of support since 2009 already), and that the target platform for NCo 2.0 was only .NET Framework 1.1, which is also out of support, I can only strongly recommend to rewrite your app with using NCo 3.1 now, or to migrate it to a different runtime environment and SAP Connector (like SAP JCo). Even if this means to put more efforts into this, this is the only future-proof way to go forward here.

[Ulrich_Schmidt · Accepted solution]

Not only the Microsoft components (Visual Studio .NET 2003, .NET Framework 1.1) have been out of support for a long time -- also NCo 2.0 has been out of support for more than a decade. So in order to get back to a supported solution, I strongly recommend to put in the effort and migrate to NCo 3.1 and an up-to-date .NET Framework.

(E.g. just think about that none of the above components got any security fixes for like 10-15 years...!)

[Ulrich_Schmidt · Accepted solution]

PS: another idea for a temporary workaround, until you manage to get the permanent solution done: instead of regenerating the proxy classes in Unicode-format, it may be possible to set the connection to Non-Unicode?! The Unicode backend system should still be able to communicate in Non-Unicode, and if there is an NCo 2.0 parameter to prevent the automatic switch to Unicode, it might still work?

Stefan knows the NCo 2.0 better than me, so perhaps something like CODEPAGE=1100 would force a Non-Unicode communication, for which case the proxy classes would still match?

[HAL9000 · Accepted solution]

No, as far as I know: Simply specifying a different logon parameter won't do it here.