The SAP .Net Connector 3.0 (NCo 3.0) offers many improvements over SAP .NET Connector 2.0. Unfortunately, SAP no longer offers example .NET code.  This blog attempts to fill that gap by describing how to build a simple RFC Client using SAP .Net Connector (NCo) 3.0 with VB.NET.  Click here to request a .zip file containing a copy of the source code.

The sample program displays details about companies defined by SAP. There are two BAPI calls involved, BAPI_COMPANY_GETLIST and BAPI_COMPANY_GETDETAIL.
Along with the SAP .Net Connector 3.0, we are using Microsoft Visual Studio 2010 and the Microsoft .Net Framework 4.0 to build our sample.  Prior to starting, you will have to download and install NCo 3.0 (OSS login required).

Setting up the Project

Using Visual Studio 2010, create a new Windows Form project. In the project properties, be sure to set the Target Framework to .Net Framework 4.0.  To change the target .NET framework version on a VB.NET project, first open the project’s property page.  Click on the “Compile” tab in the property page.  Then click on the “Advanced Compile Options..” button.

In the ensuing dialog window, change the target framework version.

Next, add references to the SAP .Net Connector 3.0. There are two DLLs, sapnco.dll and sapnco_utils.dll.

Design the Form

Add two controls to the form. The first is a List Box, which will contain the list of available SAP companies. The second control to add is a Property Grid control, which is used to display the details of a particular SAP company when the user selects one from the List Box.

Using App.Config to define the SAP Connections

There are several methods you can use in your solutions to define a particular SAP host. For this example, we are using an app.config file to define our SAP host.
The SAP .Net Connector 3.0 includes sample app.config files. For the RFC client, be sure there is a sectionGroup definition for <ClientSettings>.
The SAP host is defined by the destinations section. Within the destination, the Name field identifies this app.config entry to our program code. Specify the appropriate user name, password, SAP host name, client and system number in the destination section.

The BAPIs

Use the SAP transaction SE37 to determine the parameters for functions BAPI_COMPANY_GETLIST and BAPI_COMPANY_GETDETAIL. This will tell us what parameters need to be passed in and where to find the results that are returned to our code.

The Code

During the form load event, we want to populate our List Box with the defined companies from SAP.

1. Acquire a valid RfcDestination to use. Use method RfcDestinationManager.GetDestination() to do this. GetDestination() requires a parameter to determine which SAP host to refer to. Pass in the Name of the SAP host you previously defined in the app.config file. (Line 39)
2. Now that we have a valid RfcDestination object, we need access to the SAP Repository. The repository contains information about the BAPI calls we are going to make. The RfcRepository is an attribute of an RfcDestination object. (Line 42)
3. Using the RfcRepository object, acquire a reference to the SAP BAPI by calling method RfcRepository.CreateFunction() method. Pass in the name of the desired function as a string parameter to CreateFunction(). This method returns an object we can use to setup parameters, invoke the function, and retrieve results.
4. Now we can make the RFC calls into SAP. Using the IRfcFunction object returned by CreateFunction(), call the Invoke() method, passing in our RfcDestination object as parameter. This will make the RFC call into SAP, and provides the results via our IRfcFunction object. (Line 48)
5. SAP function BAPI_GET_COMPANYLIST returns a table of company records. We use an instance of an IRfcTable object that we retrieve by calling the GetTable() method on the IRfcFunction object. To get a desired table, pass in the table name to the GetTable() method. (Line 50)
6. We now have an instance of an IRfcTable object that contains company information through which we can iterate. It is possible to iterate through the data by setting the CurrentIndex property on the returned table. For a particular row in the table, it is possible to access values using the GetString() method. (Lines 55-59)
7. For each company, get the CompanyNumber, and use that as a parameter to SAP function BAPI_COMPANY_GETDETAIL. BAPI_COMPANY_GETDETAIL returns detailed information about that particular SAP company. The techniques are the same as before, with the additional step of using the SetValue() method on the IRfcFunction object to pass in the company number as a parameter. (Lines 60-67)
8. BAPI_COMPANY_GETDETAIL returns data as an instance of the IRfcStructure interface. Access individual field data of the company record, using the GetString() method of the IRfcStructure object instance. (Lines 67-78)
9. Extract the company details as desired. Add them to some object you create and then add that object to the List Box control. (Line 80)

The rest of the code is regular Windows Forms programming. Your code will need to wire up the List Box changed events so that the Property Grid will display the details of the selected company.

Additional Information

Follow these links for more information about NCo 3.0 programming:

• Webinar: SAP NCo 3.0 – Best Practice Guide for Upgrade from .NET Connector 2.0
• Source Code: RFC Client with NCo 3.0 for VB.NET
• C# version of this example: Build an RFC Client with NCo 3.0 – A Step-By-Step Guide

When two software systems integrate, we also have to deal with the “dropped call” problem.  SAP NCo 3.0 offers a few different levels of  data recovery options depending on whether NCo is the client or the server.  But before any data recovery can happen, the first step is to call the other party back.  This blog post describes the general process to reconnect an NCo RfcServer to an SAP gateway host.

I have read in other blogs that SAP claims their RfcServer object will automatically reconnect if it detects a dropped connection.  While this may be true, I have not seen this automatic reconnection occur in all the testing that I have done.  So, left to my own devices, I set out to figure out the best way to reconnect an RfcServer.

The first thing I did was to map out the “dropped call” process diagram.

I know that some of you are thinking that after a call is dropped it is not necessary to hang up.  This is true.  But the connection needs to be cleaned up.  In the mobile phone analogy, the phone automatically detects the dropped call and hangs up for you.  What I found during my research is that NCo 3.0 doesn’t automatically clean up broken connections, nor does it automatically clean up failed connection attemps.

Armed with this flow chart, my new found understanding of NCo 3.0, some Diet Mountain Dew, and a bag of Skittles, I decided to tackle coding a similar solution in C# using NCo 3.0.

But first, I tweaked my flow chart:

The result was a RfcServer NCo 3.0 project that would automatically recover from connection errors.  The key concept is to call the Shutdown() method of the RfcServer object after each connection failure.  Add in an event handler for the RfcServerError Event and a timer, and the rest falls into place.

Download RfcServer Reconnection Sample NCo 3.0 Project

A full sample C# project is available for download here: SAP NCo 3.0 RFC Server Reconnection Sample

Additional SAP NCo 3.0 Information

Follow these links for more information about SAP NCo 3.0 programming:

• Webinar: SAP NCo 3.0 – Best Practice Guide for Upgrade from .NET Connector 2.
• Build an RFC Client with NCo 3.0 – A Step-By-Step Guide
• Build an RFC Server with NCo 3.0 – A Step-By-Step Guide

SAP .NET Connector 2.0 offered a couple of different sample projects that were instrumental in my learning process.  As I mentioned in my post detailing the steps to build an RFC client, SAP no longer supplies code samples with SAP .NET Connector (NCo) 3.0.  So, I decided to make available some code examples created by my colleague, Terry DeBruicker.

This blog describes how to build a simple RFC Server using the SAP NCo 3.0. The sample program implements RFC STFC_CONNECTION.  STFC_CONNECTION is a good example to use because it contains both importing and exporting parameters.

Click here to request a .zip file containing a copy of the source code.

Along with the SAP .Net Connector 3.0, we are using Microsoft Visual Studio 2010 and the Microsoft .Net Framework 4.0 to build our sample. Prior to starting, you will have to download and install NCo 3.0 (OSS login required).

Setting up the Project

Using Visual Studio 2010, create a new console project. In the project properties, be sure to set the Target Framework to .Net Framework 4.0.

Next, add references to the SAP .Net Connector 3.0. There are two DLLs, sapnco.dll and sapnco_utils.dll.

Using App.Config to define the SAP Connections

There are several methods you can use in your solutions to define a particular SAP host. For this simple example, we are using an app.config file to define our SAP host connection information.

One of the biggest differences between NCo 3.0 and NCo 2.0 is how function metadata is retrieved and stored.  With NCo 2.0 the function metadata was downloaded from an SAP system at design  time and persisted as proxy objects that were compiled with the rest of your solution.  NCo 3.0 needs to access this metadata at runtime.  There are two methods for providing this metadata.  One method is to create the metadata in your .NET code.  The other method is to rely on the metadata stored in the SAP system.  For this example, we will rely on the SAP system to provide RFC metadata.  This metadata is retrieved using special built-in RFCs.  Therefore, not only will our program act as an RFC server, it will also need to act as an RFC client.

For basic RFC server configuration, there are two configuration sections that are used, <ClientSettings> and <ServerSettings>.  Ensure that the app.config file has a <sectionGroup> tag for both client and server settings.

An RFC server configuration is linked to a RFC repository by use of the REPOSITORY_DESTINATION attribute.  To be able to access function metadata, this attribute must match the name of a destination configuration in the client settings section.

All SAP NCo 3.0 RFC servers communicate with SAP through a SAP service called the gateway.  The server settings configuration section  defines how the program connects to the SAP gateway.  In the servers section, the NAME field identifies this app.config entry to our  program. The SAP .Net Connector 3.0 will use the values in the GWHOST, GWSERV, and PROGRAM_ID fields to register our program on the SAP Application Gateway. The PROGRAM_ID specified here must match the Registered Server Program ID specified in the RFC destination.

The SAP RFC Function Interface

SAP transaction SE37 can be used to determine the parameters for the STFC_CONNECTION function. This describes what parameters will be passed to our function, and what results are expected.

In this example, we expect to receive parameter REQUTEXT, which will be returned to the caller in ECHOTEXT. We also return a text string to the caller in field RESPTEXT.

SAP transactoin SM59 is used to configure the SAP RFC Destination. In this example, the name of the RFC Destination (NIMBUS) is the name of the development computer that is running the RFC Server. The registered program ID (NCO3_RFC_SERVER) matches our app.config file.

The Code

As an Nco developer, one of my favorite changes brought about by Nco 3.0 is how RFC server functionality is implemented. Instead of overriding generated stub method, we need to implement one or more class methods that will process the incoming RFC calls. For this there are several possibilities:

• The first option is to create one static method corresponding to each SAP function module to be implemented.  Assigning a SAP function module to a method is done by decorating the method with the RfcServerFunction attribute.
• The second method is to create one static method for that handles all SAP function modules. This is called the “default” method. Use the same RfcServerFunction method decoration as the previous option, but denote that the method is the defualt RFC handler. The Name attribute is irrelevant in this case.  These two methods for RFC Function handling can be combined in the same project.

It is also possible to use either of the two previous options with instance methods instead of static methods.  For the purposes of this example, we will use a static method to implement our RFC Server.

We will create a class that exposes a method that can be called via SAP RFC.  In our example that class is named DxsRfcServer and it contains one method that will supply the STFC_CONNECTION functionality.  Now perform the following steps to implement class.

1. Provide the RFC callable code. This is done in our DxsRfcServer class, where we have a method defined. The RfcServerFunction code attribute on line 59 identifies this function to the SAP .Net Connector as the method that implements SAP function STFC_CONNECTION. On line 60 is where we are passed two parameters that contain all of the information we need to execute our function. The IRfcFunction interface provides access to parameter values. In this case we use the .GetString() method on line 69 to extract the value of the REQUTEXT parameter. We also can return values to the RFC caller using the IRfcFunction interface by using the .SetValue() method as seen in lines 69-70.
   
2.  Create an array of types, with just one element that refers to our DxsRfcServer class.
   
3. Register the array with an RfcServer object.  Notice that on line 22, the first parameter to the .GetServer() method is the NAME field of the servers section in app.config.
   
4. Start the RFC server.
   
5. At this time, the SAP system has visibility of our program running on the application gateway. (SAP transaction SMGW Goto menu->Logged On Clients)
   
6. Use the test function screen in transaction SE37 to test the new function. The RFC Target System is set to the name of the RFC destination created in the previous step (in this case it is our development system name).
   
   Here are the results:
   
7. The command console will also display some useful information:
   

The rest of the code is regular Windows Console programming and is very straight forward.

Additional Information

Follow these links for more information about NCo 3.0 programming:

• Webinar: SAP NCo 3.0 – Best Practice Guide for Upgrade from .NET Connector 2.0
• Source Code: RFC Server with NCo 3.0

The sample program displays details about companies defined by SAP. There are two BAPI calls involved, BAPI_COMPANY_GETLIST and BAPI_COMPANY_GETDETAIL.
Along with the SAP .Net Connector 3.0, we are using Microsoft Visual Studio 2010 and the Microsoft .Net Framework 4.0 to build our sample.  Prior to starting, you will have to download and install NCo 3.0 (OSS login required).

Setting up the Project

Using Visual Studio 2010, create a new Windows Form project. In the project properties, be sure to set the Target Framework to .Net Framework 4.0.

Add references to the SAP .Net Connector 3.0. There are two DLLs, sapnco.dll and sapnco_utils.dll.

Design the Form

Add two controls to the form. The first is a List Box, which will contain the list of available SAP companies. The second control to add is a Property Grid control, which is used to display the details of a particular SAP company when the user selects one from the List Box.

Using App.Config to define the SAP Connections

There are several methods you can use in your solutions to define a particular SAP host. For this example, we are using an app.config file to define our SAP host.
The SAP .Net Connector 3.0 includes sample app.config files. For the RFC client, be sure there is a sectionGroup definition for <ClientSettings>.
The SAP host is defined by the destinations section. Within the destination, the Name field identifies this app.config entry to our program code. Specify the appropriate user name, password, SAP host name, client and system number in the destination section.

The BAPIs

Use the SAP transaction SE37 to determine the parameters for functions BAPI_COMPANY_GETLIST and BAPI_COMPANY_GETDETAIL. This will tell us what parameters need to be passed in and where to find the results that are returned to our code.

The Code

During the form load event, we want to populate our List Box with the defined companies from SAP.

1. Acquire a valid RfcDestination to use. Use method RfcDestinationManager.GetDestination() to do this. GetDestination() requires a parameter to determine which SAP host to refer to. Pass in the Name of the SAP host you previously defined in the app.config file. (Line 60)
2. Now that we have a valid RfcDestination object, we need access to the SAP Repository. The repository contains information about the BAPI calls we are going to make. The RfcRepository is an attribute of an RfcDestination object. (Line 62)
3. Using the RfcRepository object, acquire a reference to the SAP BAPI by calling method RfcRepository.CreateFunction() method. Pass in the name of the desired function as a string parameter to CreateFunction(). This method returns an object we can use to setup parameters, invoke the function, and retrieve results.
4. Now we can make the RFC calls into SAP. Using the IRfcFunction object returned by CreateFunction(), call the Invoke() method, passing in our RfcDestination object as parameter. This will make the RFC call into SAP, and provides the results via our IRfcFunction object. (Line 68)
5. SAP function BAPI_GET_COMPANYLIST returns a table of company records. We use an instance of an IRfcTable object that we retrieve by calling the GetTable() method on the IRfcFunction object. To get a desired table, pass in the table name to the GetTable() method. (Line 70)
6. We now have an instance of an IRfcTable object that contains company information through which we can iterate. It is possible to iterate through the data by setting the CurrentIndex property on the returned table. For a particular row in the table, it is possible to access values using the GetString() method. (Lines 75-79)
7. For each company, get the CompanyNumber, and use that as a parameter to SAP function BAPI_COMPANY_GETDETAIL. BAPI_COMPANY_GETDETAIL returns detailed information about that particular SAP company. The techniques are the same as before, with the additional step of using the SetValue() method on the IRfcFunction object to pass in the company number as a parameter. (Lines 78-84)
8. BAPI_COMPANY_GETDETAIL returns data as an instance of the IRfcStructure interface. Access individual field data of the company record, using the GetString() method of the IRfcStructure object instance. (Lines 88-99)
9. Extract the company details as desired. Add them to some object you create and then add that object to the List Box control. (Line 101)

The rest of the code is regular Windows Forms programming. Your code will need to wire up the List Box changed events so that the Property Grid will display the details of the selected company.

Additional Information

Follow these links for more information about NCo 3.0 programming:

• Webinar: SAP NCo 3.0 – Best Practice Guide for Upgrade from .NET Connector 2.0
• Source Code: RFC Client with NCo 3.0

Included in the downloads are documents that discuss the notable changes from .NET Connector 2.0 and a very comprehensive help file (in .chm format).  Noticeably absent are complete samples, although SAP claims that the included tutorial will be updated.

Additionally, I already have my first NCo 3.0 project under way, so check back soon for more information about NCo 3.0!

Happy Coding!

[UPDATED]

Additional Information

Follow these links for more information about NCo 3.0 programming:

• Webinar: SAP NCo 3.0 – Best Practice Guide for Upgrade from .NET Connector 2.0
• Build an RFC Client with NCo 3.0 – A Step-By-Step Guide
• Build an RFC Server with NCo 3.0 – A Step-By-Step Guide

Pure Fishing, Inc. – Integration with SAP .Net Connector Pure Fishing needed a new and standardized solution to allow seamless interaction between their SAP systems and third-party warehouse management software that was more reliable and flexible then custom integration approach used in the past.

View More Case Studies

EDITOR’S NOTE: NCo 3.0 has now been released.  Read more details here.

NCo 3.0 Logon

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.

Anxiously Waiting

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.  You may also email me directly at csta...@dataxstream.com if you’d like to set up a detailed conversation.