Application based on .NET framework 1.1 using NCo 2.0 to be upgraded to .NET framework 4.0 and NCo 3.0.
In this case study only the upgrade to NCo 3.0 part is covered.
To understand the constraints a little better I would first explain in brief the structure of the application to be upgraded.
The web service application comprises of two parts (projects) one containing the web services and other containing the old connector SAP RFC proxy classes and types. The proxy types are being referenced from web services and removing all the generated types and classes would have meant writing the entire application from scratch.
There were 100s of web services which was invoking approximately 120 SAP RFC to pull and push data from SAP system.
There were dozens of consumer applications based on different technologies consuming these services and changing anything on consumer application side was not being considered considering the development and deployment effort it would have required.
These poses another challenge as the client proxies generated using Framework 1.1 web services was not fully compatible with Framework 4.0 web services as SOAP standard is changed.
Source Application Architecture
Target Application Architecture
After initial deliberation it became quickly clear that we need to somehow automate the process of generating proxy classes and types compatible to new NCo 3.0. There were approximate 120 RFCs and writing codes to populate and invoke proxies would have taken considerable amount of time.
The output was a .NET based utility which took all the existing classes and types and converted to types and methods compatible with new NCo. During the runtime it connected to SAP system to get the RFC’s metadata and generated the codes required for invoking RFCs through new connector.
The next issue was to map the .NET types to the types understandable by new connector namely RFCTable, RFCStructure and other basic types. Couple of generic conversion routines were written to convert .NET type Tables and structures to Connector ‘s RFCTable and RFCStructure types. These routines converted these types at runtime when the RFCs were invoked.
Similarly we required other set of generic routines to convert the export parameters from RFCTable and RFCStructure to .NET data types.
And at last to overcome the incompatibility issue in SOAP definitions we had to overwrite the incoming SOAP request at web server side.
Keeping the implementation constraints, the performance improvement achieved was only slightly better. However, in terms of technical upgrade it was significant achievement. No change in client application and no consumer application roll out required. Only downtime needed was for server deployment.
There is scope for further improvement if more framework 4.0 functionality is utilized and conversion routines are removed.
There is an excellent blog on NCo 3.0 by Thomas Weiss A Spotlight on the New .NET Connector 3.0 which I found very helpful.