SAP is announcing a new version of SAP Connector for Microsoft .NET 3.0 (now called “NCo 3.0”). A beta program for selected customers and partners is currently underway (Q3, 2010) with the general release of the software coming soon thereafter. I will highlight some of the major differences between the SAP Connector for Microsoft .NET 2.0 and NCo 3.0 (besides the obvious, and much-needed name-shortening).
EDITOR’S NOTE: NCo 3.0 has now been released. Read more details here.
NCo 3.0 Logon
- The unauthorized reading of sensitive logon data from the .NET configuration file (e.g. app.config).
- The potential to create a malevolent application which replaces the customized logon data with it’s own logon data to obtain backend user sessions with different authorizations.
- The potential to create a malevolent application which gains access to an open connection that was originally intended for a different application.
One of the new features implemented to combat the malevolent for RFC client attacks is the interface IDestinationConfiguration. This interface contains method IDestinationConfiguration.GetParameters(string destinationName) which allows .NET programmers to provide their own secure method for storing and retrieving logon information, be it encrypted database, encrypted file, or even LDAP. There is also a corresponding interface and method to secure NCo 3.0 RFC servers.
Additionally, there is updated functionality to support single sign-on (SSO) and X.509 certificates.
Say Goodbye to Data Containers and Generated Code
In SAP Connector 2.0, working with RFCs required the generation of proxy code via the SAP .NET Connector design-time tool. This tool would convert the IMPORTING, EXPORTING, CHANGING, and TABLES parameters from the RFC you were calling/serving to .NET representations of the same. With NCo 3.0 there is no longer any kind of generated code. Instead of one generated proxy method for each function module, there is one single RfcFunction class, whose Invoke() method dynamically executes every given ABAP function module. Additionally, all ABAP parameters will be represented by the class RfcStructure instead of a dedicated generated class for every structure; All tables will be represented by class RfcTable. So, instead of hard-coding all of the data and variable bindings statically at design time, NCo 3.0 now handles everything dynamically at runtime.
NCo 3.0 uses SAP’s data dictionary to determine the function interface for the called RFCs. While this data is cached locally for performance reasons, NCo 3.0 is robust enough to detect changes in RFC interface signatures so your code will still execute if you’ve added, deleted, or changed RFC parameters. If there arises a situation where the dynamic lookup of RFC interface signature is not wanted, there is also an option to hard code the RFC parameter metadata.
The biggest benefit of NCo 3.0’s new dynamic function handling is that NCo 3.0 no longer has a design-time component. This releases the Visual Studio version restriction that .NET 2.0 had. Let me rephrase that, NCo 3.0 will work with any version of Visual Studio you like! The only requirement is that at runtime, a .NET Framework version is installed that is compatible with the NCo 3.0 libraries.
NCo 3.0 figures to be a much-needed update to a vital SAP integration technology. I, for one, cannot wait for the new functionality to be generally released. Once NCo 3.0 is released we’ll be posting blogs highlighting the new features. We’ll also include helpful information regarding a .NET Connector 2.0 to NCo 3.0 upgrade. In the meantime, if you have any leave any questions or comments you have regarding NCo 3.0 below.