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.

[MarkusTolksdorf]

Hi rcvt, 

NCo 2.0 has been out of support for more than 10 years now. You should no longer run an application with this version. I can only strongly recommend to spend the "huge" effort to get to a supported version of your app that runs with NCo 3.1. Then, also Unicode system communication is not a problem

Best regards
Markus

[rcvt]

Thank you Markus - I completely agree with your sentiment. There is a project in flight to change the complete tech stack of the application in general but this was delayed due to other priorities. In the interim is there any suggested mechanism/workaround to enable the communication whilst the development change is ongoing?

[rcvt]

Hi all

Just in case it may help anyone in the future - what we did as a workaround, in this case, is redirect the non-compliant NCO application to a non-UNICODE SAP system to act as a proxy to the UNICODE system.

Hence we adapted the RFC calls on the proxy system to just be wrappers calling the needed target RFCs on the UNICODE system.

We had to revert to this temporary workaround as the rewrite of the non-compliant NCO application did not fit into you needed UNICODE project timeline. 

[Ulrich_Schmidt]

Actually, that's a brilliant idea... But it is a bit "shooting sparrows with cannons", isn't it... 🙂
Maintaining an entire R/3 system just to use it as a "call forwarder"...

[MarkusTolksdorf]

Actually, I don't think that this is a good idea. You should plan for an upgrade of the application to the latest NCo version (3.1) to get rid of outdated and unsecure old .NET framework and NCo versions.

Best regards,
Markus